Где хранить API-ключи, токены и сервисные учётные данные
Почему технические ключи нельзя держать в коде и документации. Как устроить хранение секретов, доступы и управление сервисными учётными данными так, чтобы утечка не превращалась в аварию.
Условный кейс: как обычно начинается проблема
Компания внедряет обмен между CRM и внешней платформой.
Для запуска нужен API-ключ. Его кладут в конфиг, чтобы «быстрее проверить». Потом конфиг попадает в репозиторий. Репозиторий — в архив для подрядчика. Подрядчик через полгода больше не работает с проектом, но архив остаётся.
Через 11 месяцев ключ всплывает в неожиданном месте.
Дальше начинается не «безопасность», а пожар: отзыв ключа, срочный выпуск нового, проверка всех интеграций, разбор, не было ли обращений извне, объяснения бизнесу.
Почти всегда цепочка одна и та же:
Что является секретом
Секрет — это любое значение, которое позволяет системе или человеку выполнить действие, недоступное без него.
Почему код и документация — плохие места хранения
Код
Исходники копируются. Их клонируют, архивируют, отдают подрядчикам, переносят между машинами.
Даже приватный репозиторий — это не сейф, а файл с историей.
Документация и чаты
README, Confluence, Notion, Telegram, почта, таблицы доступов.
Там секрет читают люди, которым он часто не нужен.
Его невозможно гарантированно удалить из всех копий, бэкапов и пересылок.
И почти никогда не включают в процедуру ротации.
[Вставил в код]
[Запись в истории]
[Внешняя копия]
[Аварийный контекст]
Главный дефект обоих вариантов
Секрет начинает жить своей жизнью.
> Он отделяется от системы контроля: кто выдал, кому, зачем, до какого срока, как отозвать.
Где секреты должны храниться
Рабочая модель строится вокруг одного принципа:
секрет имеет единственный источник истины, а всё остальное — только временная выдача.
Отдельный контур, который:
- › хранит значения в зашифрованном виде
- › выдаёт доступ по политикам
- › пишет аудит
- › умеет ротировать и отзывать
- › интегрируется с CI/CD и средой исполнения
Это не «удобный сейф». Это система управления секретами.
Просто положить пароль в Kubernetes Secret без шифрования at rest и без жёстких политик — ещё не решение. Это лишь объект конфигурации.
Допустимо, когда секрет в момент запуска подставляется в runtime.
Недопустимо, когда .env с боевыми значениями лежит в репозитории, на общем диске или в домашней папке «чтобы не забыть».
Для баз данных и части внутренних сервисов лучше не использовать пароли, которые живут месяцами.
сервис запрашивает доступ
получает временные учётные данные
работает
по истечении TTL данные автоматически становятся недействительными
Утечка в такой модели ограничена по времени.
Украденный пароль через 20–60 минут уже бесполезен.
Сервисные учётные записи
Сервисная учётка — это не «пользователь, под которым удобно всё запускать».
- › одна учётка на CRM, базу, файлы и внешние API
- › права уровня администратора «на всякий случай»
- › люди входят под сервисной учёткой, потому что так быстрее
- › отдельная учётка под конкретный контур ответственности
- › минимально необходимые права
- › запрет интерактивного входа, если платформа это позволяет
- › понятный владелец
- › отдельный регламент ротации
Чем шире права сервисной учётки, тем дороже стоит её компрометация.
Как секрет должен попадать в приложение
Три рабочих паттерна.
На диске в открытом виде секрета быть не должно.
В логах — тоже.
Если секрет уже оказался в Git
- › Отозвать ключ в системе-источнике
- › Выпустить новый
- › Обновить все потребители
- › Проверить историю репозитория, CI-логи, архивы, тикеты
- › Закрыть путь, которым секрет снова может попасть в код
Удалить строку из текущего файла недостаточно.
> История сохраняет значение.
[fn]сканеры секретов в pre-commit и CI
[fn]запрет коммита .env, ключей, credential-файлов
[fn]регулярный аудит репозиториев
Ротация
Секрет, который никто не меняет, со временем становится обязательствами, а не защитой.
Причины ротации прозаические:
- › увольнения
- › смена подрядчиков
- › «временный» доступ, который забыли
- › старые интеграции, которые уже не нужны, но ключ жив
- › у каждого секрета есть владелец
- › есть срок жизни или дата пересмотра
- › процедура смены описана и выполняется
- › после ротации старое значение гарантированно не работает
Для критичных контуров проектируют окно параллельной работы двух ключей: новый уже принимают, старый ещё короткое время действует, затем отключается.
Побочные каналы утечки
Даже правильное хранение не помогает, если секрет всплывает рядом:
[!]логи приложения
[!]тексты ошибок
[!]debug-режим
[!]CI-артефакты
[!]бэкапы конфигураций
[!]дампы и снимки дисков
Правило простое:
секрет не должен появляться ни в одном канале, который читают люди или сохраняют системы наблюдаемости.
Рабочая модель для команды
Реакция на инцидент готова:
отозвать, заменить, проверить следы
Почему отговорки не работают
«Репозиторий приватный»
Приватность не отменяет копирование, историю и расширение списка доступа.
«Команда небольшая, все свои»
Большинство утечек происходят без злого умысла: отладка, архив, смена подрядчика, забытый токен.
«Потом сделаем правильно»
Потом секретов уже десятки, они размазаны по местам, и наведение порядка стоит дороже, чем нормальная схема с самого начала.
«Нам пока рано»
Именно на раннем этапе секреты чаще всего кладут в код «временно». Временное становится постоянным.
Короткий вывод
Секрет нельзя считать просто строкой настройки.
Это privileged access, у которого должны быть:
[attr]место хранения
[attr]политика выдачи
[attr]владелец
[attr]срок жизни
[attr]способ отзыва
Если API-ключ можно случайно закоммитить, переслать в чат или найти в старом архиве, система управления доступами ещё не построена.
> Есть только набор значений, которые ждут своего инцидента.
Чеклист на одну минуту
- › Секретов нет в Git и документации
- › Есть единое хранилище
- › Сервисные учётки разделены и ограничены по правам
- › Dev/test/prod не делят боевые ключи
- › Ротация и отзыв реально выполняются
- › Логи и CI не содержат секретов
- › Понятно, кто владелец каждого критичного ключа
API, Webhook или очередь сообщений?
Когда API есть, а интеграция всё равно не работает
Как соединить производство и корпоративные системы
Все инженерные материалы и экспертные статьи
Полный алфавитный справочник ИТ-терминов
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870