Як можна відмовитися від спільного використання внутрішніх ключів API в компанії?

Ми працюємо над новою послугою - ця послуга потенційно може бути викликана безпосередньо з програм на пристроях користувача. Ці додатки будуть розроблені та підтримані декількома командами розробників з усієї організації, все залежно від даних, які ми надаємо.

Ми прагнемо визначити, які програми надсилають, які запити, щоб ми могли визначити схеми використання та відповідальних розробників. (Щоб уникнути сумнівів, автентифікація користувача обробляється окремо.)

Наше рішення - вимагати ключі API, по одній програмі - тоді ми маємо контактні дані для команди розробників.

Ми не хочемо, щоб ключі API були джерелом тертя, але ми стурбовані тим, що розробники поділять їх колегам в інших командах, тобто ми не можемо більше визначати трафік лише для однієї програми.

Як можна стимулювати розробників не ділитись ключами API внутрішньо?

Для того, щоб поділитися цими ключами між командами, команди повинні поговорити між собою, погодитися поділитися, а потім поділитися ними. На це потрібен час. Тож якщо команда може вимагати ключі API від вас швидше та простіше, не можна стимулювати ділитися.

І найпростіший спосіб запитувати ці ключі - це попередньо видалити їх. Припустимо, що ви знаєте всі інші команди, яким знадобляться ключі API, створіть їх і поділіться ними, перш ніж зробити послугу доступною для них.

Є ще один стимул, який ви можете запропонувати: підтримка налагодження. Ці команди бажають вашої допомоги, коли справи не працюють належним чином, коли вони інтегрують свою роботу з вашими послугами. Ці ключі API дозволяють відстежувати їх конкретні запити і таким чином допомагати налагоджувати те, що відбувається не так. Тож продайте це як причину ключів, а не « визначайте схеми використання та відповідальні розробники », що здається, ви шпигуєте за їх діяльністю.

Хороші відповіді вже, я просто думав про інший підхід, який може чи не може працювати для вас.

Замість того, щоб видавати ключі, ви можете вимагати, щоб заголовок запитів містив ім'я переднього додатка, який повинен бути створений та відформатований розробником програми на передньому кінці, як це роблять веб-браузери. Таким чином, передні кінці все ще можуть претендувати на інше застосування, але не буде користі для цього, що здається малоймовірним. Просто нехай передній кінець ідентифікує себе і прийме будь-яку непусту рядок.

Коротко:

По-перше: полегшення та переваги; При необхідності: тертя та поліція.

Ще кілька слів

Полегшення . По-перше, спростіть команду отримати новий ключ API. Наприклад, додайте нагадування у корпоративних процедурах для запуску нових проектів та запропонуйте просту у користуванні послугу, щоб запитувати нові ключі, не вимагаючи пояснення.

Переваги . Зробіть власний ключ API корисним для команди або власника продукту. Наприклад, запропонуйте відгуки про використання додатків на основі цього ключа.

Тертя : залежно від ключової функції, ви можете створювати тертя, наприклад, якщо ключ пов'язаний із визначеним додатком доменом сомом (тобто повторне використання ключів не обов'язково надасть доступ до всіх бажаних послуг).

Поліцейські дії : Нарешті, можливо, вам потрібно буде передбачити деякі заходи поліції. Наприклад, ви можете відстежувати використання функцій api клавішею api та через певний час встановити базову лінію, запитуючи про використання частин api, яких не очікується з огляду на базову лінію. Або якщо це не реально, просто включіть у контрольні списки огляду корпоративного проекту підтвердження того, що був використаний дійсний ключ.

Зауваження : можливо, вам буде потрібно дуже чітко ознайомитись з ключовою політикою API: Чи потрібна нова нова версія власного ключа API? Що з виделкою, або якщо додаток розділено? що робити, якщо інша команда відповідає тощо.

Як правило, найпростіший спосіб змусити розробників "зробити все правильно" - це зробити їх легким для цього.

З цією метою я б запропонував створити веб-сторінку / сайт, що видає ключ API. У своєму найпростішому вигляді це може бути лише логін (ідеально прив’язаний до вашого корпоративного AD / LDAP) та сторінка, яка просто запитує назву програми та видає ключ.

Зрештою, ви завжди можете відкликати ключі пізніше, тому все, що вам дійсно потрібно зробити, це записати, хто (ім’я користувача) запитав ключ і що (ім’я програми) вони хочуть зробити з ним - разом з будь-якою інформацією, необхідною для відкликають ключ пізніше.

Ви можете зробити щось подібне із системою продажу квитків, але наприкінці дня мені дуже просто скопіювати та вставити ключ з однієї програми в іншу, тому запитувати новий ключ потрібно дуже просто, щоб уникнути поганого поведінка.

Будьте проактивними.

Заздалегідь визначте ймовірних розробників та надайте їм унікальні ключі API у захищеному каналі. Надайте простий спосіб запиту нових ключів API. Забезпечте простий спосіб для нових людей, які вимагають нових ключів API. Коли нові ординатори або наймачі приєднуються до команди, надайте їм квиток JIRA або подібний «Попросити ключ API», виконуючи кроки в описі.

Слідкуйте за тим, які ключі API були використані, а які - ні. Якщо Боб подав квитки в проект, але він не використовував свої ключі API, він, ймовірно, позичив чужі.

Мати підтримку керівництва. Не будьте Носі Ненсі, збираючись будь-яких правил, які не мають значення. Буквально переконайте керівництво, що це важливо, і тоді вони переконують групу, що це важливо. Не працюйте над тим, щоб переконати всіх.

І найприємніша та схильна до тиранії пропозиція: Будьте в курсі зловживань, і в цей же день виламіть. Та сама година найкраща. Не кажіть, що «Bad Naughty Developer» скажіть «Ось правильні кроки». Якщо вони роблять це неодноразово, вимкніть неправильно використаний ключ. Це турбує і Пайора, і того, хто позичив, і в майбутньому пайовик скаже «Ні, роби це правильно». Уникайте відключення ключів, які перебувають у проектах, що живуть

Як можна стимулювати розробників не ділитись ключами API внутрішньо?

• Створення ключів у результаті реєстрації додатків для самообслуговування .
• Потрібна точка дотику, перш ніж ключі активуються.
• І попросіть їх не ділитися. (Створити умови обслуговування і / або сказати їм , чому це краще для них , щоб не розділити.)

Вам також слід запровадити обмеження ставок . Це само по собі може відмовити спільному користуванню клавішами. Він певною мірою захищає вашу систему від зловживань. (І прямо шкідливі.) І це гарантує, що ви будете дещо поінформовані перед масовим збільшенням справного трафіку. (Даю вам час на додавання потужності, сподіваюся!)

І з обмеженням швидкості, коли програма вимагає більш високої межі, вона відкриває діалог з POC, зареєстрованим для ключа. Ви отримуєте можливість запитати, чи поділяються ключі, поясніть, чому це шкідливо і так далі, і ви можете запропонувати додаткові ключі, коли це доречно замість запитуваних змін ліміту тарифу. І т.д.

Один із способів зробити те, особливо якщо команди використовують спільну систему збирання (або хоча б достатньо поширену) - це налаштувати внутрішній сервер, який створює та видає ключі API (з урахуванням кількох основних бітів інформації про продукт, що використовує його ). Потім використовуйте скрипт, який захоплює новий ключ API від сервера для кожної збірки або для кожного оновлення версії. Дозвольте розробникам запустити сценарій, щоб отримати інший ключ також для своїх локальних збірок. (Де це можливо, автоматизуйте це як частину збірки, щоб їм навіть не потрібно було думати про це.)

Це дозволить вам сказати, чи було це щось у виробництві, QA або dev, і в якій версії / побудові почалися проблеми.

Перше і найкраще, що ви можете зробити - це відформатувати клавіші так, щоб вони містили ім'я програми у легко читабельній формі, а не працювали, якщо ви їх змінили.

Якщо це очевидно, коли команди використовують неправильний ключ, вони намагатимуться цього не робити.

Потім періодично закінчуйте термін дії клавіш. Ви повинні це зробити в будь-якому випадку , і коли ключ наближається до закінчення терміну дії, ви можете надіслати новий команді, яка йому належить. Команда, яка використовує ключ, потім буде мотивована, щоб переконатися, що вони є тією командою, яка володіє ним, так що вони отримають новий, коли термін його дії закінчиться.