Секреты под контролем: как компании выстраивают безопасное управление ключами, паролями и токенами

Цифровые сервисы, автоматизация и DevOps изменили подход к тому, как компании хранят и защищают свои данные. Сегодня «секреты» — пароли, ключи, токены, сертификаты — стали важнейшей частью любой инфраструктуры, а их управление напрямую влияет на устойчивость бизнеса и доверие пользователей.

Редакция CISOCLUB пообщалась с Александром Гусевым, техническим директором Haspbox, — о том, какие угрозы стоят за неуправляемыми секретами, как компании выстраивают безопасную инфраструктуру хранения и ротации, какие подходы работают в гибридных средах, как оценить зрелость процессов и почему управление секретами становится не просто элементом безопасности, а стандартом зрелой DevSecOps-культуры.

Какие угрозы управления секретами вы считаете наиболее критичными сегодня?

Как человек, который занимается разработкой системы для управления секретами, самая большая угроза – это отсутствие централизованного управления секретами, когда каждый отдел или команда использует собственные подходы, возникает хаос и множатся уязвимости. Как бы это громко не звучало, но именно в тех случаях, когда нет механизмов централизованного управления, хранения и контроля как секретов, так и парольной политики возникает ситуация, когда каждый «сам себе на уме». Это на мой взгляд основные причины.

А вот сами угрозы, связанные с этим, это угрозы человеческого фактора:

• Небезопасное хранение или «захардкоженные секреты», кстати, это одна из самых популярных причин утечек и как следствие атак на заказчиков. Это относится и к небезопасному стилю разработки, когда секреты хранятся в коде или же в переменных окружения. Как это не парадоксально, но сюда же можно отнести хранение паролей в текстовых файлах, таблицах на компьютере пользователя, в заметках телефона или стикерах на мониторе. Это всё в той или иной мере «открытое хранение».
• Долгоживущие статичные секреты. В данном случае даже надежное хранилище может не спасти, если ротация секретов не производится на регулярной основе и, соответственно, нужно лишь время для компрометации. Хорошее решение этой проблемы – динамические секреты, то есть те, что создаются в момент запроса, «just-in-time» в мире управления секретами. При этом, стоит понимать, что автоматизированная ротация паролей со стороны сервиса, например, когда сервис принудительно заставляет человека сменить пароль на новый по истечению срока действия, часто приводит фактически к тому, что человек использует старый пароль, делая лишь перестановки символов или групп символов, что уменьшает энтропию самого пароля.
• Получение «нулевого секрета» или как выдать первый секрет безопасно. Технологии решения этой проблемы, разумеется, существуют, нужно только их использовать.
• «Криптографическая гигиена». Угрозы могут быть как на этапе передачи секрета, так и при хранении его. Если применяемые алгоритмы шифрования недостаточно надежные (или вообще не применяются), то риск компрометации возрастает кратно.

Есть еще ряд угроз более практического характера при использовании сервисов (kubernetes, git и т.п.), но так или иначе их все можно уложить в описанное выше.

Как можно избежать компрометации секрета в масштабируемых инфраструктурах с сотнями сервисов?

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

• Использование секретов из Git и артефактов разработки.
• Использование короткоживущих секретов с автоматической ротацией или использование динамических секретов.
• Централизация и уход к удостоверениям через OIDC.
• Применение шифрования секретов и контейнеров при обмене, а также использование endpoint-шифрования при передаче, чтобы исключить возможность MITM.
• Ротация TLS-сертификатов.

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

Какие подходы к ротации и управлению секретами наиболее эффективны в гибридных средах?

Я бы предложил подход, сочетающий в себе централизацию политик, максимальную автоматизацию и интеграцию, а также высокого уровня механизмы аудита и отказоустойчивости. И хоть это звучит достаточно «пафосно», но всё более чем «материально»:

• Единый центр хранения и доверия позволит избежать дублирования секретов и сложностей эксплуатации при создании ролей и самих секретов.
• Динамическая выдача секретов или же статические, но с достаточной частотой ротации. При этом важно учесть, что ротация может быть реализована не только по расписанию — лучший вариант будет по событиям или контексту событий.
• Интеграция с DevOps-инфраструктурой. Это позволит избежать проблем с утечкой секретов из кода, и в целом встроить управление секретов в процесс разработки и деплоя.
• Сегментация прав. Разделение прав доступа к секретам и хранилищам, ориентация на RBAC-политику доступа.
• Всё должно логироваться и фиксироваться. Когда речь идет о «ключах к королевству» важно понимать кто, когда и для какой цели получил доступ к секрету и сам секрет. Добавляем анализ работы с секретом по поведенческой аналитике и получаем достаточно точную картинку аномалий при их возникновении.
• Отказоустойчивость. Без нее никуда. Падение централизованного сервиса управления секретами может оказать крайне негативные последствия, поэтому при выборе как механизмов управления, так и конечных решений – этот фактор должен быть одним из определяющих выбор.

Как выбрать стратегию хранения секретов: централизованную, распределённую или комбинированную?

Единого совета, разумеется, нет. Выбор должен быть основан как на зрелости компании по части инфраструктуры и ИБ в целом, так и на более «приземленных» требованиях компании.

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

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

Ну и, конечно, никто не запрещает их комбинировать под конкретные задачи. Используя централизацию для основного контура и выделенные небольшие инсталляции для вынесенных во вне контуров, в т.ч. облачных систем.

Во всем нужен сбалансированный подход на основе потребностей, а не только на основе «трендов».

Какие требования регуляторов в сфере защиты секретов влияют на подходы компаний к управлению ими?

Управление паролями в компаниях на текущий момент базируются на основных требованиях к парольной политике и чаще всего определяются для каждой конкретной компании самостоятельно, хоть и с оглядкой на требования регуляторов в части сложности и необходимости регулярной смены. Не на прямую, но все же через подконтрольные акты, требования расписаны в узкоспециализированных нормативных документах, например 17 приказ ФСТЭК России, 187-ФЗ и другие. Ну и, конечно, же есть базовые требования по доступу к информационным системам в зависимости от их класса защищенности — сертификация решений по требованиям безопасности информации и требований к шифрованию данных внутри решения.

Одним словом, все базовые требования прописаны, но каждая из компаний подходит к решению этих задач в меру собственного понимания и зрелости ИБ. И хотелось бы, чтобы она росла и не требовалось каких-то отдельных требований кроме как требований здравого смысла – секретами нужно управлять и делать это безопасно, а не пускать этот процесс на самотек.

Как проверить, что система секретов работает надёжно

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

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

Как защитить секреты для DevOps-процессов без ухудшения CI/CD

Автоматизировать процесс получения секретов из централизованного менеджера секретов. Это если коротко. На практике многие системы безопасности могут быть успешно внедрены в инфраструктуру, не ухудшая при этом процесс привычной работы, но, разумеется, для этого требуется изменение привычек. И тут одно цепляется за другое. Хочешь защитить секреты в DevOps-процессах – не храни секреты в коде и не храни их в переменных окружения, а организуй процесс автоматического получения через внешних менеджер секретов. Хочешь больше безопасности – вводи регулярную ротацию этих секретов или используй возможно по динамической их выдаче. Современных менеджеров секретов это не просто кошелек, который хранит пароли – это система автоматизации смены, хранения и выдачи секретов, и она де-факто строиться, чтобы процесс не ухудшался, при этом повышая безопасность. Ну и, разумеется, разграничение доступа к получению секретов, маскирование или исключение попадание секретов в логи.

Можно, конечно, предложить просто вручную менять сертификаты, api-ключи и пароли, но тогда этот процесс точно хуже, а это уже не удовлетворяет условиям задачи – сделать удобно и безопасно.

Какие метрики применимы, чтобы оценить эффективность системы управления секретами?

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

1. Метрики безопасности

• Снижение числа инцидентов, связанных с компрометацией учётных записей.
• Снижение среднего время жизни пароля и сокращение периода доступности скомпрометированного пароля.
• Снижение доли неуправляемых привилегированных учётных записей.
• Снижение количества hardcoded-секретов.
• Снижение процента сервисов, использующих встроенные секреты для доступа application-to-application

2. Метрики снижения нагрузки на сотрудников и сервис-деск

• Снижение количества обращений в сервис-деск по теме «забыл пароль».
• Уменьшение среднего время восстановления доступа.
• Снижение затрат на поддержку пользователей.
• Снижение числа ручных операций администраторов по управлению паролями сервисных аккаунтов (ротация, обновление, выдача).

3. Метрики пользовательского опыта (UX) и продуктивности

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

4. Финансовые/экономические метрики

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

Прогноз технологий управления секретами. Что станет стандартом через 2–3 года?

Интерес к теме возрастает, но при этом наблюдается в первую очередь интерес к парольным кошелькам, по сути своей частной проблеме безопасного хранения пользовательских секретов. Меньший интерес сейчас видно на рынке управления инфраструктурными паролями и секретами, этим вопросов больше интересуются крупные, зрелые технологические компании, где процесс управления просто не может быть выстроен в ручном режиме, а цена ошибки высока для бизнеса. Если же говорить на интервале 2-3 лет, то мое мнение, что полнофункциональные гибридные системы управления секретами полного цикла, как новый тренд и подход будут превалировать на рынке. Кратно возрастет интегрируемость подобного класса систем не только в процессы devops-а, но и в управление паролями самой инфраструктуры. Интеграция с системами класса PAM и IdM так же будет являться стандартном, либо же сами эти системы станут более глубоко управлять всеми секретами внутри контура заказчика. Этому в том числе поспособствует укоренение концепций just-in-time и zero trust, которые из чисто маркетингового подхода уже стали основой для проектирования множества крупных систем безопасности. Кроме расширения применения и интегрируемости подобных систем считаю, что будет развивать аналитический компонент на базе систем прогнозирования и поведенческой аналитики. Без ИИ нынче никуда.

Какие интеграции и стандарты вы считаете ключевыми для решений управления секретами в будущем?

Ключевыми станут интеграции, обеспечивающие единое управление секретами во всех слоях инфраструктуры. В ближайшие 2–3 года стандартом станет связка Vault + KMS + HSM, где:

• Vault обеспечивает централизованное управление, аудит и динамическую выдачу секретов через унифицированные API (OIDC, JWT, PKCS#11).
• KMS (облачные и локальные, включая отечественные) отвечает за шифрование и контроль ключей в гибридных средах.
• HSM служит аппаратным корнем доверия и обеспечивает криптографическую устойчивость и соответствие требованиям ФСБ, ФСТЭК России.

Всё чаще эти решения интегрируются с DevSecOps-инструментами (Kubernetes, Terraform, GitLab CI/CD) и архитектурами Zero-Trust, где секреты выдаются динамически и с минимальными правами. Поддержка PKCS#11, OpenID Connect и российских криптопровайдеров становится базовым требованием для корпоративных внедрений.