Надайте кожній інтеграції власний ключ.

Визначте обсяги перед створенням

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

Розкривайте обережно й зберігайте приватно

Справжній ключ слід показувати через захищений процес створення, захищати під час зберігання та виключати з URL, браузерних пакетів і систем контролю версій. Записуйте власника, призначення та час створення, не розкриваючи сам секрет.

Зробіть відкликання практичним

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

Перевірте ліміти

Корисний тест запуску включає дозволену операцію, заборонену операцію, прострочений або відкликаний ключ і запит поза межами ресурсів ключа. Сама автентифікація не є авторизацією.

Політика кандидатних ключів

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

Аудит без розкриття запиту

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

Надайте кожній автоматизації власні облікові дані

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

Створення, зберігання та ротація

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

Відкликайте доступ, а не докази

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

Трохи більше ясності.