Управление секретами и конфигурацией

12 мин чтения·Для руководителя разработки и лидера безопасности

Пароль от базы данных в конфигурационном файле. Ключ API платёжного сервиса в docker-compose. Токен облачного провайдера в скрипте деплоя, который разработчик добавил «временно» и забыл. Git помнит всё — удаление строки из кода не стирает её из истории коммитов. Через несколько месяцев автоматический сканер найдёт действующий ключ в истории репозитория.

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

Почему это важно для бизнеса

Типичные отговорки — «нас не взломают, мы маленькая компания» и «разберёмся при случае» — ошибочны в обоих случаях.

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

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

Маленькая команда — общий доступ без контроля. Если несколько сотрудников пользуются одним файлом с паролями, переданным через мессенджер, невозможно установить, кто и когда использовал учётные данные. При увольнении сотрудника сменить все пароли чаще всего забывают. Это нарушение принципа разграничения доступа и требований к аудиту, предусмотренных 149-ФЗ и нормами защиты коммерческой тайны (98-ФЗ).

Восстановление обходится дорого. Утечка одного ключа — это дни работы команды: смена всех скомпрометированных учётных данных, аудит логов доступа, уведомление клиентов. Если утекли персональные данные — обязательное уведомление Роскомнадзора в течение 24 часов с момента обнаружения инцидента (152-ФЗ в редакции 2022 года).

Типичный сценарий

Разработчик ИТ-компании добавил ключ API сервиса отправки SMS в конфигурационный файл, чтобы быстро проверить интеграцию. Через несколько месяцев коллега случайно перевёл репозиторий в открытый доступ. Ключ оказался действующим — в течение нескольких часов с него отправили тысячи спам-сообщений, счёт вырос на сотни тысяч рублей. Ключ аннулировали, но деньги уже списались.

Что считается секретом

Любые данные, открывающие доступ к системе или сервису:

Категория	Примеры
Пароли	Учётные данные СУБД, административные аккаунты, пароли сервисных учётных записей
API-ключи и токены	Ключи платёжных сервисов, SMS-шлюзов, токены репозиториев кода, OAuth-секреты
Криптографические материалы	Приватные ключи, TLS-сертификаты, SSH-ключи, ключи подписи JWT
Строки подключения	URL баз данных со встроенными учётными данными, адреса брокеров сообщений
Облачные учётные данные	Ключи доступа Yandex Cloud, сервисные аккаунты VK Cloud, токены Cloud.ru, Selectel

Простой критерий: если данные позволяют аутентифицироваться или получить доступ к ресурсам — это секрет.

Где секреты оказываются не там, где надо

Исходный код. Пароль прямо в строке подключения к базе данных, ключ в заголовке HTTP-запроса, токен в переменной — «на время», которое растянулось на годы.

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

История Git. Ключ удалили из кода, но из истории коммитов он никуда не делся. Автоматические сканеры проверяют именно историю.

Логи CI/CD. Скрипты деплоя, которые выводят переменные окружения в консоль. Лог сборки доступен всем участникам репозитория.

Локальные файлы, переданные по мессенджеру. Файлы с переменными окружения, которые пересылают в Telegram или по почте: никакого журнала доступа, никакого управления правами.

Секрет в клиентском коде — уже не секрет

Ключ, зашитый в JavaScript-сборку или мобильное приложение, извлекается без специальных навыков. Клиентский код нельзя считать местом хранения секретов ни при каких условиях.

Типичные ошибки команды

«Пример» с реальными данными. В репозитории лежит .env.example, а в нём — настоящий пароль от производственной базы, а не очевидная заглушка вроде CHANGE_ME.

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

Передача через мессенджер. «Кинь пароль от базы в Telegram» — пароль навсегда остаётся в истории переписки, доступной всей команде.

Нет ротации при увольнении. Бывший сотрудник знает все пароли, к которым имел доступ. Если их не сменить — доступ фактически сохраняется.

Нет запрета на коммит секретных файлов. Если в .gitignore нет паттернов для .env, *.pem, *.key, credentials.json — рано или поздно кто-то их закоммитит.

Принципы управления секретами

Эти принципы нужно закрепить как обязательные требования к команде разработки:

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

2. Единый источник. Все учётные данные хранятся в одном менеджере секретов. Приложения получают их оттуда при запуске — и нигде больше.

3. Наименьшие привилегии. Скрипт деплоя продакшн-окружения получает ключи только к продакшн-ресурсам. Разработчик работает только с ключами dev-окружения. Никто не имеет доступа ко всему сразу.

4. Полный журнал аудита. Система фиксирует, кто и когда обращался к учётным данным. Это требование для расследования инцидентов и соответствия нормам ФСТЭК.

5. Регулярная ротация. Пароли и ключи меняются по расписанию, независимо от инцидентов. При подозрении на утечку — немедленно.

Рекомендуемое решение: Пассворк

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

Пассворк — российский менеджер паролей для бизнеса — закрывает оба направления в одном продукте: управление паролями сотрудников с ролевым доступом и хранилище инфраструктурных секретов с интеграцией в CI/CD через API, CLI и SDK.

Что Пассворк даёт руководителю

Контроль доступа по ролям. Кто к каким секретам имеет доступ — определяет администратор. Разработчики dev-команды не видят ключи продакшна. Сервисные аккаунты CI/CD имеют только право на чтение в своей папке.

Zero-knowledge шифрование. Все операции шифрования происходят на стороне клиента. Сервер хранит только зашифрованные данные — даже при компрометации инфраструктуры злоумышленник получает нечитаемый шифротекст.

API и CLI для автоматизации. Пайплайны деплоя получают нужные ключи из Пассворка непосредственно перед запуском. Секреты не хранятся в переменных CI/CD-системы и не попадают в логи сборки.

Полный журнал аудита. Каждое обращение к учётным данным — кто, когда, с какого адреса — фиксируется. Это необходимо при расследовании инцидентов и соответствии приказам ФСТЭК № 17 (ГИС) и № 21 (ПДн).

Размещение на собственном сервере. Для компаний с требованиями локализации данных (152-ФЗ, 242-ФЗ) Пассворк разворачивается в собственной инфраструктуре — данные не покидают периметр организации.

Облачная версия. Если требований локализации нет — доступна облачная версия с той же архитектурой zero-knowledge.

Подробнее об интеграции с CI/CD и техническое описание — в документации Пассворка.

Как организовать хранилище секретов

Структура папок в Пассворке должна отражать архитектуру окружений:

infrastructure/
├── production/
│   ├── databases/       — ключи к производственным СУБД
│   ├── cloud/           — учётные данные Yandex Cloud, VK Cloud, Selectel
│   └── services/        — ключи платёжных шлюзов, почтовых сервисов
├── staging/
└── development/

Для автоматизации создаются сервисные аккаунты с минимальными правами:

Аккаунт	Назначение	Права
`deploy-prod-svc`	Деплой в продакшн	Чтение `infrastructure/production`
`deploy-staging-svc`	Деплой в staging	Чтение `infrastructure/staging`
`cred-rotator`	Ротация учётных данных	Запись во всех окружениях

В журнале аудита сразу видно разделение: вот что делала автоматика, вот что — конкретный человек.

Интеграция с CI/CD

Принцип работы одинаков для GitLab CI, GitHub Actions, Bitbucket Pipelines или любой другой системы:

В настройках CI/CD хранятся только параметры подключения к Пассворку (хост, сервисный токен).
Перед запуском деплоя пайплайн получает все нужные секреты из Пассворка через CLI или SDK.
Секреты передаются как переменные окружения непосредственно в процесс деплоя — и нигде не сохраняются.
После завершения сессии секреты исчезают из памяти.

Разработчик, у которого нет доступа к продакшн-папке в Пассворке, физически не может получить продакшн-секреты — даже если имеет полный доступ к конфигурации пайплайна.

Экстренный доступ

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

Минимальный план экстренного доступа:

Не менее двух сотрудников с полными правами администратора Пассворка — задокументировано, кто именно
«Аварийный» аккаунт с учётными данными в физическом носителе (запечатанный конверт в сейфе у руководителя)
Письменная инструкция: что делать при компрометации, кому звонить, как документировать

Тестируйте процедуру раз в квартал: убедитесь, что аварийные учётные данные актуальны и что процесс понятен всем ответственным.

Альтернатива: HashiCorp Vault / OpenBao

Для компаний, предпочитающих полностью открытый исходный код без зависимости от коммерческого вендора, существует HashiCorp Vault или его свободный форк OpenBao (развивается сообществом после смены лицензии Vault в 2023 году).

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

Для большинства компаний без выделенной DevOps-команды — начинать стоит с Пассворка. Быстрее в развёртывании, ниже требования к экспертизе, покрывает и пользовательские пароли, и инфраструктурные секреты в одном инструменте.

Аудит репозиториев

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

Инструменты сканирования

gitleaks — сканирует репозитории по шаблонам: пароли, токены, ключи. Проверяет как текущее состояние, так и всю историю коммитов. Поддерживает установку в качестве pre-commit хука.

truffleHog — глубокий анализ с использованием энтропии и шаблонов, проверяет все ветки и историю.

git-secrets — инструмент AWS, предотвращает коммит секретов. Устанавливается как хук перед коммитом.

Что делать с находками

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

Очищать историю Git технически возможно, но трудоёмко. Практичнее: сменить скомпрометированные учётные данные и установить процесс, исключающий рецидив (pre-commit хуки + автоматическое сканирование в CI/CD).

Что требовать от команды

Сканирование запускается автоматически при каждом коммите (pre-commit хуки)
Найденные активные учётные данные ротируются в течение одного рабочего дня
В каждом репозитории есть .gitignore с запретом для файлов с секретами (.env, *.pem, *.key, credentials.json и подобных)

Ротация учётных данных

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

Тип секрета	Рекомендуемая частота
Пароли к производственным СУБД	30–90 дней
Внешние API-ключи	90 дней или по требованию вендора
Сервисные токены	7–30 дней
SSH-ключи	6–12 месяцев
Все учётные данные при увольнении сотрудника	Немедленно

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

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

Миграция: как перейти от текущего хаоса к порядку

Типичная картина до внедрения менеджера секретов: пароли в .env-файлах на ноутбуках, в переменных CI/CD, в чатах команды, в одном общем файле на Google Диске.

Шаг 1: инвентаризация. Составить реестр всех секретов: какие существуют, где хранятся, кто владелец, когда последний раз менялись.

Шаг 2: создать структуру в Пассворке. Папки по окружениям и категориям, сервисные аккаунты для автоматизации.

Шаг 3: перенести секреты. Начать с критических (продакшн-базы, платёжные шлюзы) и постепенно переходить к остальным.

Шаг 4: обновить приложения. Приложения должны читать секреты из переменных окружения, а не из кода. Переменные поставляет Пассворк через CLI при запуске.

Шаг 5: обновить CI/CD. Пайплайны деплоя получают секреты из Пассворка, а не из встроенных переменных CI/CD-системы.

Шаг 6: зачистить. Удалить секреты из переменных CI/CD (оставить только параметры подключения к Пассворку), удалить .env-файлы с продакшн-данными, проверить сканером, что ничего не осталось.

См. также

Управление паролями — корпоративное хранилище учётных данных
Безопасность CI/CD — передача секретов в CI/CD
Плейбуки реагирования — плейбук утечки секретов в коде

Что дальше

Учётные данные убраны из кода, доступ разграничен по ролям, журнал аудита фиксирует каждое обращение. Это закрывает один из самых распространённых путей компрометации.

Следующий шаг: безопасность контейнеров и облачной инфраструктуры — как проверять Docker-образы на уязвимости, безопасно настраивать ресурсы у российских облачных провайдеров и что требовать от команды при работе с Kubernetes.

Почему это важно для бизнеса​

Типичный сценарий​

Что считается секретом​

Где секреты оказываются не там, где надо​

Типичные ошибки команды​

Принципы управления секретами​

Рекомендуемое решение: Пассворк​

Что Пассворк даёт руководителю​

Как организовать хранилище секретов​

Интеграция с CI/CD​

Экстренный доступ​

Альтернатива: HashiCorp Vault / OpenBao​

Аудит репозиториев​

Инструменты сканирования​

Что делать с находками​

Что требовать от команды​

Ротация учётных данных​

Миграция: как перейти от текущего хаоса к порядку​

См. также​

Что дальше​