Дайте каждой интеграции собственный ключ.

Определите области доступа до создания

Выдавайте ключу только те действия и ресурсы, которые нужны для его задачи. Интеграции мониторинга может требоваться доступ на чтение; инструменту развёртывания — определённый набор операций жизненного цикла. По возможности отделяйте полномочия по оплате.

Раскрывайте осторожно и храните приватно

Настоящий ключ должен выдаваться через защищённый процесс создания, храниться в защищённом виде и исключаться из URL, браузерных сборок и систем контроля версий. Фиксируйте владельца, назначение и время создания, не раскрывая сам секрет.

Сделайте отзыв практически выполнимым

Выдавайте отдельные учётные данные для каждой интеграции, чтобы одну можно было отозвать, не останавливая всё остальное. Меняйте их осознанно и проверяйте, что старый ключ больше не работает. Расследуйте неожиданное использование с помощью ограниченных записей аудита.

Проверьте пределы

Полезный тест запуска включает разрешённую операцию, запрещённую операцию, истёкший или отозванный ключ и запрос за пределами границ ресурсов ключа. Аутентификация сама по себе не является авторизацией.

Политика кандидатных ключей

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

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

Полезная запись аудита может включать идентификатор ключа, маршрут, время и результат без сохранения паролей или целых тел запросов. Доступ к записи всё равно требует защиты. Определите хранение и экспорт, а не храните конфиденциальную операционную историю бессрочно.

Выдавайте каждой автоматизации отдельные учётные данные

Средство проверки резервных копий, рабочий процесс развёртывания и интеграция с биллингом не должны использовать один и тот же ключ с полным доступом. Назовите ключ по его задаче, предоставьте минимальные права и зафиксируйте, кому он принадлежит. Предполагаемые группы: чтение, серверы, биллинг и полный доступ; точное сопоставление их операций должно быть проверено, когда API станет доступен.

Создание, хранение и ротация

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

Отзывайте доступ, а не доказательства

Отключение ключа должно останавливать будущие запросы, сохраняя ограниченную запись безопасности о его прошлом использовании. Если учётные данные могли утечь, отзовите их незамедлительно, проверьте затронутые ресурсы и замените все связанные секреты. Список ключей должен показывать безопасный идентификатор и метаданные последнего использования, а не восстановимые секреты в открытом виде.

Немного больше ясности.