API-ключи и секреты сайта: хранение, доступ и ротация
Практическая организация доступа к API-ключам: реестр, минимальные права, защищённое хранение, журнал и отзыв токенов.
API-ключи связывают сайт с оплатой, CRM, рассылками и резервным хранилищем. Утечка такого секрета может позволить выполнять действия от имени компании без входа в административную панель. Управляйте ключами как отдельными сервисными удостоверениями.
01. Составьте инвентаризацию без записи секретов
Реестр должен содержать свойства, а не значения ключей.
- Найдите интеграции оплаты, почты, аналитики, облачного хранилища, CI/CD и внешних API.
- Для каждого ключа отметьте владельца, назначение, права, среду, место хранения, дату ротации и процедуру отключения.
- Выделите ключи с правами удаления, выпуска платежей и доступа к персональным данным.
- Результат: понятно, кто отвечает за каждый секрет, без копирования самого секрета в таблицу.
02. Ограничьте права и область действия
У разных задач должны быть разные учётные данные.
- Создавайте отдельные ключи для production и тестовой среды, не используйте один общий токен «на всё».
- Ограничивайте операции чтения/записи, доступные ресурсы и срок действия, если провайдер это поддерживает.
- Не передавайте ключи внешнему подрядчику навсегда; используйте временные роли и отзыв после завершения работ.
- Результат: компрометация одной интеграции не предоставляет права на все системы.
03. Перенесите хранение в защищённое место
Переменные окружения и менеджеры секретов лучше публичных конфигураций.
- Уберите секреты из клиентского JS, HTML, скриншотов, документации и публичных репозиториев.
- Обеспечьте чтение нужным процессом и запрет списочного доступа посторонним пользователям сервера.
- Согласуйте способ получения секрета приложением и поведение при его отсутствии или отзыве.
- Результат: секрет не выдаётся при обычном просмотре сайта, резервных архивов или Git-истории.
04. Подготовьте безопасную ротацию
Замена ключа не должна ломать работающий бизнес-процесс.
- Выясните, поддерживает ли поставщик параллельную работу старого и нового ключа.
- Обновляйте сначала зависимую конфигурацию и проверяйте реальные операции после переключения.
- Отзывайте старый ключ после подтверждения функционирования и проверяйте прекращение его использования.
- Результат: ключ можно заменить без длительного простоя и забытых зависимостей.
05. Реагируйте на утечку
Отсутствие видимых ошибок не означает отсутствия злоупотреблений.
- Определите время возможной утечки, журнал операций и системы, куда ключ имел доступ.
- Сначала ограничьте ущерб согласно регламенту: отзыв или ограничение ключа, ротация и смена доступов.
- Проверьте журналы провайдера и последствия действий, затем устраните путь утечки в коде или процессе.
- Результат: секрет больше не действителен, а причины утечки документированы.
06. Установите контроль жизненного цикла
Ключи не должны переживать свой проект бесконечно.
- Проводите ревизии после увольнений, смены подрядчиков, удаления интеграций и изменения владельца сервиса.
- Отслеживайте просроченные и неиспользуемые учётные данные без хранения значений в журнале.
- Проверяйте, что резервные копии не создают дополнительные неучтённые места с секретами.
- Результат: у каждого активного ключа есть оправданная задача, владелец и способ отзыва.
Редакционный материал, октябрь 2026 года. Проверяйте применимость методов к вашей конфигурации и действующим требованиям.