Сначала определите тип и полномочия ключа
Название API key не задает одинаковую секретность у всех поставщиков. Нужно знать тип, аккаунт, окружение и доступные действия. Ключ для рабочего сервиса и учебного режима может иметь разную область, а секрет подписи вебхука является отдельным объектом.
Stripe различает publishable, secret и restricted ключи. Публичный вариант предназначен для определенных клиентских сценариев, а ограниченный серверный ключ не становится публичным из-за меньших прав. Для другого провайдера используйте его собственные определения и актуальную документацию.
Составьте реестр без самих значений: владелец, назначение, потребитель, разрешения, окружение и способ отзыва. Не присылайте секреты в обычную форму и не копируйте их в рабочую таблицу для удобства описания задачи.
Путь от исходника до браузера и журналов
Секрет может раскрыться не только в файле исходного кода. Значение бывает встроено в статическую сборку, публичную конфигурацию, образ, диагностический вывод, скриншот или архив. Отдельно проверьте, какая часть данных реально доступна пользователю браузера.
Перенос строки в переменную окружения не гарантирует безопасность. Значение может попасть в клиентский пакет при сборке или быть доступно лишним процессам и журналам. Нужны поддерживаемый серверный путь, ограничения доступа и отсутствие ненужного раскрытия.
OWASP рассматривает управление секретами как жизненный цикл и описывает ограничения разных способов передачи в окружение. Выбирайте механизм по своей платформе, а не считайте любой файл с названием env универсальным защищенным хранилищем.
Карта хранения и потребителей
Следующая таблица является рабочим шаблоном CyberFixCrew. Она помогает найти владельца и границу проверки, не собирая сами ключи в отчет. Это не результат поиска секретов в клиентском проекте и не рекомендация одной технологии для всех систем.
Для каждого потребителя определите необходимые права и независимость учебного режима. Общий секрет многих интеграций затрудняет ограниченный отзыв. Если поддерживается отдельный ключ с нужной областью, его применение согласуют с владельцем сервиса.
| Место или этап | Что проверить | Нужный результат |
|---|---|---|
| Исходный код | Нет ли серверного секрета в файлах проекта? | Разрешенный поддерживаемый источник значения |
| Сборка и браузер | Какая конфигурация доставляется посетителю? | Только предназначенные публичные данные |
| Серверный потребитель | Какие операции и аккаунт доступны? | Минимально нужные права |
| Журналы и диагностика | Не выводится ли значение или его копия? | Полезные события без секретов |
| Учебная среда | Не использует ли рабочие полномочия? | Изолированный разрешенный путь |
| Замена и отзыв | Кто обновляет всех потребителей? | Приемка и прекращение старого доступа |
Что делать при возможном раскрытии
Установите тип ключа, его область и наблюдаемые места раскрытия. Уполномоченный владелец оценивает доступную историю и необходимость срочного ограничения. Нельзя объявлять отсутствие чужого использования только потому, что его не видно в доступном журнале.
Удаление строки из текущего файла не отменяет уже раскрытый секрет. Копии могут оставаться в истории, сборках и чужом доступе. Требуется поддерживаемая замена или отзыв и проверка потребителей, а очистка доступных артефактов является отдельной задачей.
Условный пример: секрет убран из исходника, но старая клиентская сборка еще доступна. Изменился один файл, доступ к прежнему значению не закрыт. Пример вымышленный: реальные ключи, репозитории и рабочие аккаунты не исследовались.
Ротация зависит от провайдера и срочности
Для плановой замены составьте перечень потребителей, поддерживаемую процедуру, приемку нового ключа и условие прекращения старого. Возможность периода совместной работы зависит от провайдера. Нельзя обещать одинаковое перекрытие для любого API или секрета подписи.
При подтвержденном опасном раскрытии скорость ограничения может быть важнее обычного комфортного перехода. Решение принимает уполномоченный владелец с учетом последствий. Не сохраняйте старый секрет бесконечно только потому, что часть зависимостей еще неизвестна.
Stripe описывает отдельные действия жизненного цикла своих ключей; они не заменяют правила других сервисов. После замены проверьте нужную интеграцию и отсутствие прежнего использования в доступной области. Не выполняйте реальную транзакцию или массовую отправку ради проверки.
- Установить тип, владельца и потребителей.
- Согласовать срочность и поддерживаемый порядок.
- Подготовить новое значение в разрешенном серверном пути.
- Принять безопасные рабочие сценарии.
- Отозвать прежнее по плану и проверить ограничения.
Поддержка и передача управления
Реестр пересматривают при смене подрядчика, приложения, окружения и владельца сервиса. В отчет включают факт замены, область и приемку, а не сами значения. У компании должен быть понятный защищенный путь восстановления управления.
CyberFixCrew - израильская компания по защите сайтов и цифровой инфраструктуры. Помогаем русскоязычным бизнесам по всему миру связывать израильские знания в области кибербезопасности с управлением доступами и интеграциями. Чтобы начать обсуждение, достаточно назвать сервис, окружение и проблему; сами значения ключей в форму обращения передавать не нужно.
