22 KiB
Процесс 15: Обеспечение безопасности используемых секретов
Дата публикации: 15 апреля
Время на чтение: ~11 мин
ТГ канал: Про_SEC_со
В конце октября 2023 года Unit 42 (Palo Alto Networks) опубликовали разбор кампании EleKtra-Leak. Суть в том, что злоумышленники автоматически мониторили публичный GitHub: клонировали репозитории и вытаскивали оттуда открытым текстом утёкшие ключи AWS IAM (Identity and Access Management — механизм в Amazon Web Services, который выдаёт доступ к облачному аккаунту через API: по сути, «логин и пароль» для программного управления ресурсами). Как только ключ оказывался в репозитории, цепочка шла дальше без человека в вашей команде: рекогносцировка (разведка: обход API AWS, чтобы понять регионы, лимиты и что вообще доступно внутри аккаунта) в аккаунте AWS, правки security groups, запуск крупных виртуальных машин EC2 (в отчёте фигурируют, в частности, типы вроде c5a.24xlarge — это семейство и размер ВМ в EC2 с очень высокой почасовой стоимостью в биллинге AWS, то есть майнинг на таких инстансах быстро накручивает счёт) и долгий криптоджекинг (майнинг Monero). Авторы зафиксировали, что actor (сторона атаки: один злоумышленник или связанная группа, threat actor) успевал подхватить и использовать утёкшие учётные данные AWS IAM в течение пяти минут с момента их появления на GitHub; в ходе наблюдения с 30 августа по 6 октября 2023 насчитали 474 уникальных EC2-инстанса, потенциально контролируемых этой операцией, а саму кампанию оценивают как активную как минимум с декабря 2020 года. Отдельный урок из того же материала: часть защиты даёт связка GitHub Secret Scanning и политика AWS AWSCompromisedKeyQuarantine, но исследователи прямо пишут, что не все случаи утечки попадают под автоматическое срабатывание, и ответственность за сканирование репозиториев и порядок с секретами всё равно остаётся на стороне организации.
Сценарий EleKtra-Leak — про то, что один секрет в неправильном месте превращается в чужой дата-центр на вашем биллинге и в долгую операцию, которую вы можете не заметить сразу. ГОСТ Р 56939-2024 не морализирует — он описывает процесс 5.15: регламент, реальное использование по правилам, проверка кода и конфигов на утечки и система управления секретами вместо хранения «где привыкли». В примечании к подразделу 5.15.2 прямо сказано: требования к реализации применяются по усмотрению организации и в нужных объёмах — но если вы вообще игнорируете тему, «усмотрение» быстро превращается в объяснения перед инцидент-командой.
Суть процесса простыми словами
Секрет в смысле этого стандарта — любые данные, которыми можно подтвердить личность, обеспечить целостность или скрыть содержимое: пароли, ключи API, токены, сертификаты, ключи подписи, иногда — параметры криптографии по закону. Процесс 5.15 — не про «запретить разработчикам пароли», а про то, чтобы секреты жили, выдавались и умирали по правилам, а не по памяти и в сторонних каналах.
Он дополняет процесс 8 (правила кодирования: не хардкодить секреты) и процесс 10 (статический анализ и поиск утечек в репозитории). Пятнадцатый процесс добавляет слой операционки: кто имеет право на какой секрет, где он хранится, как ротируется, что делать при компрометации, и как приложение получает значение в рантайме — из vault, из секрет-стора кластера, а не из переменной в docker-compose.yml в git.
Связка с архитектурой (5.6) и моделью угроз (5.7) зашита в сам ГОСТ: при разработке регламента учитываются артефакты из 5.6.3.1, 5.7.3.1 и 5.7.3.3. Проще говоря: регламент секретов не пишется в вакууме — он должен стыковаться с тем, как вы проектируете систему и где у вас реально проходит линия атаки.
Требование 5.15.2.1: Регламент использования секретов
Разрабатывать регламент использования секретов.
Это фундамент. Без документа «как мы живём с ключами» каждый деплой превращается в персональную импровизацию: кто-то кладёт секрет в переменные CI вручную, кто-то — в Kubernetes Secret из plain text в репозитории манифестов, кто-то шлёт DBA пароль в почте.
Артефакт 5.15.3.1: что может быть в регламенте
ГОСТ перечисляет содержание как ориентир — регламент может включать:
- Роли и обязанности сотрудников при работе с секретами
- Основные принципы использования (минимум привилегий, разделение окружений, запрет копирования в личные каналы и т.д.)
- Зоны ответственности подразделений
- Порядок предоставления доступа к секретам (заявка, согласование, срок действия доступа)
- Типы секретов, сроки эксплуатации, действия при компрометации
- Порядок формирования и хранения (как создаём, где лежит «источник правды»)
- Порядок ротации
- Требования к системам хранения секретов
Пример: оглавление и фрагмент регламента
Оглавление (карта документа)
| Раздел | Содержание |
|---|---|
| 1. Область и термины | Что считаем секретом; исключения (публичные ключи, отпечатки сертификатов) |
| 2. Роли | Владелец секрета, администратор vault, разработчик, CI-сервисная учётка |
| 3. Принципы | Нет секретов в VCS; выдача по запросу с аудитом; ротация по календарю и по инциденту |
| 4. Доступ | Матрица: кто может читать / записывать / выдавать временные токены |
| 5. Жизненный цикл | Создание, хранение, использование в приложениях, отзыв, уничтожение |
| 6. Ротация | Периодичность по типам; процедура без простоя |
| 7. Инциденты | Кто объявляет компрометацию, как меняем ключи, кого уведомляем |
| 8. Требования к хранилищу | Шифрование at rest, MFA для админов, аудит чтения, резервирование |
Фрагмент: действия при компрометации
1. Немедленно отозвать скомпрометированный секрет в системе управления секретами.
2. Выпустить замену; обновить все потребители (сервисы, CI, админские клиенты).
3. Проверить журналы доступа за период с момента предполагаемой утечки.
4. Зафиксировать тикет в системе учёта инцидентов; при необходимости —
уведомление владельца информационной системы / ИБ.
5. Ретроспектива: попал ли секрет в git, логи, бэкапы; добавить правило
в SAST/secret scanning при новом классе ошибок.
Такой блок превращает «панику в чате» в повторяемую процедуру. Знакомо, когда без него все бегают к одному человеку, который «помнит, как в прошлый раз чинили»? Регламент как раз против этого.
Требование 5.15.2.2: Использовать секреты
Использовать секреты.
Формулировка короткая, смысл практический: секреты должны реально применяться там, где они нужны для аутентификации, целостности или конфиденциальности — по правилам из того же регламента (артефакт 5.15.3.1). То есть не только «храним в vault», но и «приложение и пайплайн читают оттуда, а не держат копию в Notion».
На практике это выглядит так: сервис при старте получает токен доступа к базе из системы управления секретами (см. требование 5.15.2.4), CI получает deploy-ключ через OIDC или short-lived token, а не через долгоживущий пароль в переменной «навсегда». Если секрет есть в регламенте и в vault, но разработчики всё равно подкладывают копию в локальный config.local.yml и коммитят по привычке — требование 5.15.2.2 и 5.15.2.3 вы ломаете одновременно.
Требование 5.15.2.3: Проверка кода и конфигов на секреты
Проверять код и конфигурационные файлы ПО на предмет включения секретов для вносимых изменений в ПО.
Речь про изменения, которые вы вносите в продукт: каждый MR или каждая поставка должны пройти фильтр «не унесли ли мы наружу ключ». В примечании ГОСТ допускает статический или композиционный анализ — то есть gitleaks, trufflehog, встроенные правила SAST, сканирование артефактов сборки.
Пример: политика в CI
Минимальный набор
Этап pipeline: secret-scan (блокирующий)
Инструмент: gitleaks (или аналог) в режиме --redact
Область: diff текущей ветки к защищённой базе + полный scan периодически на main
Правила:
- Находка высокой уверенности → fail pipeline, merge запрещён
- Ложноположительные → заносим в allowlist с justification в MR
- Исключения только через security review, не «чтобы прошло»
Что ещё проверять кроме .py и .java
docker-compose*.yml, Helm values, Terraform.tf(часто забывают)- Историю: иногда секрет удалили в последнем коммите, но он остался в git — нужен либо scan всей истории при инциденте, либо политика ротации после утечки
Связка с процессом 10 очевидна: тот же сканер может быть частью регламента SAST. Процесс 15 подчёркивает именно секреты как класс риска и требует не надеяться на «ревьюер заметит».
Требование 5.15.2.4: Система управления секретами
Для хранения, управления и предоставления секретов использовать систему управления секретами.
Три глагола — три функции. Хранение: шифрование, контроль доступа. Управление: политики, ротация, версии. Предоставление: API или агент, который выдаёт приложению значение в момент запуска, ideally — краткоживущие учётные данные.
Это не обязательно HashiCorp Vault в датацентре: для облака — любой сервис представленный провайдером облачных услуг; в Kubernetes — внешние провайдеры секретов (CSI driver + vault/cloud), чтобы не хранить base64 plaintext в Secret как единственный барьер. Главное — осознанный выбор централизованного механизма вместо «файл на файловой шаре, доступ по доменной группе».
Пример: схема для микросервиса
Ниже одна и та же идея, что и в тексте выше, но разложена по зонам ответственности. Важный момент, который на схеме нужно увидеть глазами: репозиторий Git ни к какому Vault не подключается и не забирает оттуда секреты при git clone. В Git лежит код и, отдельно, декларации деплоя (куда в рантайме смотреть за значением: secretRef, CSI volume, External Secrets, путь в облачном SM — это контракт, не пароль). Значение секрета запрашивает уже среда исполнения — от имени удостоверенного workload — у хранилища; до этого момента в цепочке «Git → CI → образ → под» секрета как строки подключения нет.
Оператор задаёт в deployment ссылку на путь в vault (или на secret store облака), платформа подставляет значение в рантайме. Разработчик локально использует личный токен с минимальными правами или dev-базу без продовых данных — это тоже прописывается в регламенте из 5.15.3.1.
Артефакт 5.15.3.2: подпись кода (если включили в описание процедуры)
Описание реализации процедуры использования секретов может включать: порядок подписи исполняемого кода ПО; порядок подписи исходного кода.
Секреты здесь — уже ключи подписи и сертификаты: как подписываете артефакт релиза, где лежит private key, кто утверждает выпуск, как связано с безопасной сборкой (процесс 5.12). Отдельно — подпись коммитов (SSH signing, Sigstore/gitsign) для защиты целостности истории.
Пример: краткий чек-лист подписи релиза
- Ключ подписи в HSM или в vault с жёсткой политикой; не на ноутбуке релиз-инженера
- CI вызывает подпись через краткоживущий токен; полный приватный ключ не входит в runner
- Пользователи/системы проверяют подпись перед установкой (политика доверия к цепочке сертификатов)
- Для исходников: включена проверка подписи на защищённой ветке, merge без подписи запрещён политикой платформы
Как это работает вместе
Четыре пункта 5.15.2 — не чеклист «на выбор», а один сквозной контур, если вы серьёзно относитесь к секретам.
- 5.15.2.1 — регламент: кто с чем живёт, как выдают доступ, как ротируют и что делают при компрометации. Без этого остальные три пункта превращаются в набор добрых пожеланий.
- 5.15.2.2 — использование по регламенту: пайплайны и сервисы реально берут значения из положенного места, а не из параллельной «теневой» копии.
- 5.15.2.3 — контроль изменений: в каждую поставку кода и конфигурации встроен поиск утечек; иначе регламент и vault не спасут от ключа в коммите или в Helm values.
- 5.15.2.4 — система управления секретами как единая точка хранения, выдачи и отзыва, а не разрозненные файлы и переменные «у кого попросили».
Описание подписи кода и релиза (5.15.3.2) стыкуется с тем же контуром: ключи подписи — тоже секреты, только с другим жизненным циклом и другими потребителями (сборка, репозиторий, потребитель артефакта).
Процесс 5.15 не заменяет соседние разделы стандарта, а задаёт им опору. Процесс 5.8 фиксирует правила кодирования (в том числе «не хардкодить»). Процесс 5.10 даёт масштабируемую автоматическую проверку, в которую органично входит поиск секретов в диффах и артефактах. Процесс 5.9 добавляет человеческий разбор там, где автоматика слепа к контексту. Пятнадцатый процесс отвечает на вопрос, где лежит источник правды по секретам, как они попадают в рантайм и как вы доказываете себе и аудитору, что цепочка не обходится.
Если регламент написан, система управления секретами введена в эксплуатацию, а команда по-прежнему передаёт значения в обход принятого механизма, проблема уже не в формулировках ГОСТа. Обычно это сочетание трения на официальном пути (долго, сложно, нет self-service) и отсутствия измеримости (merge без скана, нет аудита чтений, никто не смотрит на исключения в allowlist). Стандарт задаёт скелет процесса; довести до рабочей привычки — задача инженерной зрелости и удобства инструментов, а не только ИБ.