My Geocode

Миграция

Безопасный вывод старых API-ключей из эксплуатации после миграции

· 3 мин чтения · My Geocode · #api-ключи#безопасность#планирование-миграции#учётные-данные#после-миграции

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

Самый безопасный процесс рассматривает вывод ключа из использования как отдельный небольшой проект с определённой последовательностью шагов, а не как второстепенное дополнение в конце основной работы по миграции:

  1. Сначала убедитесь, что трафик на старом ключе нулевой, а не просто верьте, что миграция завершена. Большинство провайдеров дают возможность видеть использование конкретного ключа; проверьте это напрямую, а не считайте, что отмеченный как выполненный чек-лист миграции означает, что старый ключ действительно затих на практике.
  1. Оставьте старый ключ действительным, но неиспользуемым на определённый период наблюдения после того, как вы сочли миграцию завершённой, а не отключайте его в тот момент, когда новый провайдер начинает работать. Этот период, обычно несколько недель в зависимости от характера вашего трафика и циклов выпуска, выявит забытое место вызова, запоздавшее обновление мобильного приложения или редко запускаемую пакетную задачу, которая всё ещё ссылается на старые учётные данные.
  1. Сначала деактивируйте старый ключ, а не удаляйте его, если ваш провайдер поддерживает такое различие. Деактивированный ключ, который всё ещё существует как запись, проще временно снова включить, если обнаружится что-то неожиданное, чем полностью удалённый. Это даёт запас надёжности на период наблюдения, не продлевая его бесконечно.
  1. Удалите или полностью отзовите старый ключ в конкретную заранее выбранную дату и задокументируйте это. Бессрочно деактивированный ключ всё равно остаётся поверхностью атаки, которую кто-то может снова активировать, если сам аккаунт когда-нибудь будет скомпрометирован; по-настоящему выведенные из использования учётные данные в итоге должны быть удалены окончательно, а не оставлены в вечном подвешенном состоянии.
  1. Проверьте, где хранился старый ключ, включая системы управления конфигурацией, менеджеры секретов, файлы переменных окружения и любую документацию или материалы для новых сотрудников, которые могут на него ссылаться, поскольку выведенный из использования ключ, который где-то всё ещё записан как «API-ключ», сбивает с толку следующего читателя этой документации, даже спустя долгое время после того, как сам ключ перестал работать.

При миграции на My Geocode новый ключ можно ограничивать и отслеживать с первого дня с помощью заголовков квоты, присутствующих в каждом ответе, таких как X-Quota-Used, X-Key-IPs-Used и других, описанных на /docs/rate-limits/. Благодаря этому легко убедиться, что новый ключ действительно принимает ожидаемый трафик, прежде чем начинать отсчёт до вывода старого из использования. Такой вдумчивый подход к выводу учётных данных требует немного дополнительных действий, но заметно снижает и эксплуатационный риск, и остаточную угрозу безопасности.

Ещё в разделе «Миграция»