Безопасное управление секретами и переменными окружения

Секреты, зашитые в коде — ключи API, пароли баз данных, закрытые ключи TLS и токены OAuth, встроенные непосредственно в исходный код, — являются одними из наиболее распространённых и предотвратимых уязвимостей безопасности. Секреты в исходном коде доступны в истории системы контроля версий (даже после удаления), видимы всем разработчикам с доступом к репозиторию и часто становятся общедоступными, когда репозитории случайно открывают. Инструменты вроде GitGuardian и truffleHog постоянно ищут утёкшие секреты на таких платформах, как GitHub.

Переменные окружения удаляют секреты из исходного кода, передавая их во время выполнения через операционную систему хоста или оркестратор контейнеров. application считывает os.environ['DB_PASSWORD'], а не заранее заданное значение. Это лучше, чем хранить секреты в коде, но у переменных окружения есть недостатки: они отображаются в списках процессов, наследуются дочерними процессами, часто попадают в дампы сбоев и отладочные журналы, а также требуют ручной Rotation. Они подходят для разработки, но сами по себе недостаточны для управления секретами в рабочей среде.

Менеджеры секретов — специализированные системы для хранения, Rotation и аудита доступа к секретам. К ведущим решениям относятся HashiCorp Vault (с открытым исходным кодом и корпоративная версия), AWS Secrets Manager, Azure Key Vault и Google Cloud Secret Manager. application аутентифицируется в менеджере секретов во время выполнения, получает секрет и использует его — секреты никогда не хранятся на диске или в переменных окружения. Весь доступ записывается в журналы, что позволяет проверить, кто, к какому секрету и когда обращался.

Ключевое преимущество менеджеров секретов перед переменными окружения — автоматическая Rotation. AWS Secrets Manager может автоматически менять пароли баз данных RDS по расписанию (например, каждые 30 дней), не требуя повторного развёртывания application. Менеджер секретов одновременно обновляет пароль в базе данных и сохранённый секрет. application, получающее секреты при каждом подключении, автоматически получает новые учётные данные. Это устраняет распространённую практику использования «постоянных» паролей служебных учётных записей, которые никогда не меняются.

Первой линией защиты от секретов, попавших в репозиторий, является правильно поддерживаемый файл .gitignore, исключающий все файлы, которые могут содержать секреты. Однако .gitignore предотвращает только будущие коммиты — секреты, уже добавленные в репозиторий, сохраняются в истории git. Если секреты случайно попали в репозиторий, их необходимо немедленно считать скомпрометированными: замените секрет, а затем при необходимости используйте такие инструменты, как git filter-repo, чтобы переписать историю (это требуется для соблюдения нормативных требований, но само по себе недостаточно, поскольку секрет уже мог быть извлечён).

Файлы инфраструктуры как кода (IaC) — Terraform, CloudFormation и манифесты Kubernetes — часто содержат секреты: строки подключения к базам данных, ключи API в объявлениях переменных окружения и сертификаты TLS. Эти файлы часто добавляют в системы контроля версий, создавая риск раскрытия секретов. Среди решений — динамические секреты Vault (Vault создаёт краткоживущие учётные данные специально для каждого запуска Terraform), Secrets Kubernetes (хранятся в etcd и должны быть зашифрованы при хранении), а также external-secrets-operator, который во время выполнения синхронизирует данные из менеджера секретов с Kubernetes.

Каждое приложение или служба должны получать доступ только к тем секретам, которые им непосредственно необходимы, — это принцип наименьших привилегий, применённый к секретам. Веб-приложению нужен пароль базы данных, но не закрытый ключ CA. Заданию для формирования отчётов нужны учётные данные базы данных только для чтения, а не доступ на запись. Менеджеры секретов обеспечивают это с помощью политик доступа, указывающих, какие идентификаторы (роли IAM, учётные записи служб, AppRoles) могут читать какие секреты; весь доступ записывается в журналы для аудита.

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

Конвейерам CI/CD часто требуются секреты — учётные данные поставщика облачных услуг для развёртывания, токены реестра Docker и ключи подписи. Никогда не храните секреты в скриптах конвейера или файлах конфигурации. Вместо этого используйте встроенное хранилище секретов платформы конвейера (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store) или получайте секреты из централизованного хранилища во время выполнения с помощью удостоверения машины. Помечайте переменные с секретами как замаскированные в журналах, чтобы предотвратить их случайное раскрытие в выводе сборки.

Менеджеры секретов предоставляют подробные журналы аудита каждого события доступа к секрету: какое удостоверение обратилось к какому секрету, с какого IP-адреса, в какое время и был ли доступ разрешён или отклонён. Эти журналы критически важны для соблюдения нормативных требований (SOC 2, PCI-DSS) и реагирования на инциденты. Если есть подозрение, что учётные данные скомпрометированы, журналы аудита показывают, какие системы и когда обращались к ним, что позволяет быстро выявить потенциально затронутые системы и принять решение об их изоляции.

Хуки перед коммитом — это скрипты, которые автоматически запускаются перед завершением каждого коммита git и позволяют обнаружить секреты до их попадания в историю системы контроля версий. Такие инструменты, как detect-secrets (Yelp), GitLeaks и git-secrets (AWS), интегрируются как хуки перед коммитом и сканируют подготовленные файлы на наличие шаблонов ключей API, строк подключения, закрытых ключей и токенов JWT. Если обнаружен секрет, коммит отклоняется, а разработчику предлагается удалить учётные данные. Среда pre-commit упрощает добавление конфигураций хуков и обмен ими между командами.

В этом уроке Вы узнали, что жёстко заданные секреты в исходном коде необходимо устранять и заменять менеджерами секретов, такими как Vault или AWS Secrets Manager; автоматическая ротация устраняет долгоживущие учётные данные, которыми атакующие могли бы воспользоваться даже после первоначальной компрометации; а динамические секреты и политики доступа с наименьшими привилегиями уменьшают ценность любого отдельно взятого раскрытого секрета. Далее мы рассмотрим безопасность зависимостей и анализ состава программного обеспечения.