Проблема распространения секретов

Расп07олзание секретов — это неконтролируемое распространение конфиденциальных учётных данных по организации. Секрет — это всё, что предоставляет доступ: ключи API, пароли баз данных, токены OAuth, закрытые ключи TLS, ключи SSH и ключи шифрования.

Распозлание происходит, когда эти секреты оказываются разбросаны по местам, где им ни в коем случае не следует находиться:

• Исходный код и файлы конфигурации
• Конвейеры CI/CD и переменные окружения
• Образы контейнеров и инфраструктура как код
• Сообщения в чатах, вики и системы управления заявками

Как только секрет существует во множестве мест, вы теряете возможность надёжно отслеживать, менять или отзывать его.

Наиболее распространённая первопричина — зашитый в коде secret, то есть учётные данные, записанные непосредственно в исходном коде. Во время разработки это кажется удобным, но со временем становится постоянной уязвимостью.

Вот как выглядит пароль базы данных, зашитый в коде приложения:

Теперь любой, у кого есть доступ на чтение к этому файлу, располагает паролем рабочей среды. Это касается каждого разработчика, каждого средства выполнения CI и всех, кто впоследствии клонирует репозиторий.

Критическая опасность зашитых в коде секретов связана с историей системы контроля версий. Даже если удалить secret в следующем коммите, он навсегда останется в истории Git каждой копии репозитория.

В любой момент можно восстановить утёкший secret из истории:

Поэтому удаление secret из последнего коммита не устраняет утечку. Secret следует считать скомпрометированным и немедленно заменить.

Когда репозиторий с зашитыми в коде секретами отправляют на публичный хост вроде GitHub, автоматические боты сканируют его за считаные секунды или минуты.

Реальные последствия включают:

• Огромные счета за облачные сервисы — утёкшие ключи AWS используют для запуска целых ферм по добыче криптовалют, что за одну ночь приводит к расходам в десятки тысяч долларов.
• Утечки данных — раскрытые учётные данные базы данных приводят к полной выгрузке данных.
• Боковое перемещение — один утёкший токен используется для дальнейшего проникновения в инфраструктуру.

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

Контейнеры создают менее заметный канал распространения секретов. Секреты, встроенные в образ во время сборки, сохраняются в слоях образа и отправляются в каждый реестр и на каждый хост, откуда этот образ загружают.

Распространённая ошибка — сначала скопировать файл с secret, а затем удалить его в следующем слое: secret всё равно остаётся в предыдущем слое.

Любой, кто загрузит образ, может извлечь этот слой и прочитать ключ. Вместо этого используйте секреты сборки или внедрение во время выполнения.

Перенос секретов из кода в переменные окружения — это шаг вперёд, но не полноценное решение. Переменные окружения устраняют проблему зашитых в коде секретов, однако создают новые пути раскрытия:

• Они попадают в дампы сбоев и трассировки стека ошибок
• Они видны другим процессам через /proc/<pid>/environ в Linux
• Их записывают инструменты отладки, выводящие всё окружение
• Они хранятся в виде открытого текста в файлах .env, которые случайно добавляют в репозиторий

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

Распространение секретов делает реагирование на инциденты практически невозможным. Когда secret находится повсюду, на два вопроса невозможно ответить:

• Где он находится? Нельзя заменить то, чего нельзя найти.
• Кто им пользовался? Без централизованных журналов доступа невозможно определить масштаб утечки.

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

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

К популярным инструментам с открытым исходным кодом относятся gitleaks, trufflehog и detect-secrets. Типичный хук перед коммитом запускается локально:

Дополните это сканированием на стороне сервера в CI, чтобы разработчик, обошедший локальный хук, всё равно был обнаружен.

Если secret оказался там, где ему быть не следует, действуйте в таком порядке. Сначала замените secret — очистка истории вторична, поскольку копии уже могли появиться.

• 1. Замените — отзовите утёкший secret и немедленно выпустите новый.
• 2. Проведите аудит — проверьте журналы доступа на наличие несанкционированного использования в период раскрытия.
• 3. Очистите — удалите secret из истории, например с помощью git filter-repo, и принудительно отправьте изменения.
• 4. Предотвратите — добавьте сканирование и перенесите secret в менеджер секретов, чтобы утечка не повторилась.

Никогда не пропускайте шаг 1. Secret, оказавшийся в открытом доступе, безусловно скомпрометирован.

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

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

Эти привычки превращают катастрофическую утечку в ограниченный инцидент, последствия которого можно устранить.

Одни инструменты проблему не решат — её решает культура. Зрелая организация воспринимает управление секретами как постоянную дисциплину:

• Исходная установка: ни одного secret в исходном коде.
• Храните секреты централизованно в управляемом хранилище с контролем доступа и журналами аудита.
• Автоматизируйте сканирование на каждом этапе: перед коммитом, в CI и в реестре.
• Сделайте замену секретов обычной процедурой, а не действием только при чрезвычайных ситуациях.
• Обучайте каждого инженера распознавать случаи раскрытия и сообщать о них без обвинений.

Цель — система, в которой утечку secret сложно допустить и легко устранить.

Проверьте, понимаете ли вы, почему удаления утёкшего secret недостаточно.

Вы узнали, почему разбросанные по системе секреты, зашитые в коде, — одна из самых распространённых и опасных уязвимостей безопасности.

• Распространение секретов — это неконтролируемое распределение учётных данных по коду, конвейерам, образам и чатам.
• Секреты, зашитые в коде, навсегда сохраняются в истории Git: их удаление не устраняет утечку.
• Публичные репозитории сканируют за считаные минуты, что приводит к огромным счетам за облачные сервисы и утечкам данных.
• Переменные окружения и слои образов допускают утечки; это не безопасное хранилище.
• Распространение секретов увеличивает радиус поражения и делает замену секретов и реагирование на инциденты невозможными.
• Решение: сканировать до коммита, при утечке сначала заменить secret, централизовать хранение в хранилище и применять принцип минимальных привилегий.

Далее мы правильно централизуем секреты с помощью хранилищ и менеджеров секретов.