Статья

Безопасность против скорости:

как внедрить Secrets Manager и не поссориться с DevOps 

  • Illustration

    Автор: Максим Ткаченко, Senior Sales Engineer, BAKOTECH

Знаете, какая встреча в компании обычно проходит наиболее эмоционально? Когда в одной переговорной комнате или в Zoom собираются отдел информационной безопасности и команда DevOps, чтобы обсудить, как они теперь будут управлять секретами.

Я, как инженер дистрибьютора, регулярно бываю на таких встречах. С одной стороны стола сидит CISO, которому по ночам снятся взломанные базы данных и хакеры. С другой — Lead DevOps, у которого KPI привязан к 50 деплоям в день и стабильности CI/CD-пайплайнов. Они говорят на разных языках. Отдел говорит: «Мы усиливаем безопасность, теперь все пароли должны храниться в нашем защищенном Enterprise-сейфе». DevOps закатывает глаза и думает: «Ну все, приехали. Сейчас эти безопасники своими соображениями завалят мне весь процесс релиза».

Проблема заключается в следующем. Мы прекрасно научились защищать «живых» — администраторов. Внедрили PAM, настроили двухфакторную аутентификацию, записываем видео их сессий. Но парадокс в том, что на одного живого админа в современной компании приходится 40–50 «роботов»: микросервисов, скриптов, Ansible playbooks, Jenkins jobs.

Им всем тоже нужны пароли, API-ключи и токены для доступа к базам данных или другим сервисам. А откуда они их берут? Чаще всего — из текстовых файлов, переменных окружения (environment variables) или, что хуже всего, эти ключи просто «закодированы» прямо в репозитории на GitHub или GitLab.

Когда ИБ обнаруживает это, начинается паника и попытка «натянуть» классическую PAM на DevOps-процессы. И вот тут происходит самое интересное.

Кейс о «Черной пятнице»

Помню один яркий пример. Крупная финтех-компания решила, что отныне все их контейнеры в Kubernetes будут запрашивать пароли к базе данных через REST API в классическом CyberArk Vault. С архитектурной точки зрения на бумаге всё выглядело отлично. Но наступил день большой распродажи. Нагрузка возросла, кластер Kubernetes автоматически запустил еще тысячу новых контейнеров, чтобы справиться с трафиком. И каждый из этой тысячи контейнеров одновременно «постучал» по API в центральный Vault за своим паролем.

Что произошло дальше? Классическая DDoS-атака на самих себя. «Тяжелый» enterprise-сейф, который идеально работал для сотни администраторов, просто «завис» от тысяч машинных запросов в секунду. Контейнеры не получили пароли, приложение упало, бизнес потерял деньги. DevOps после этого сказали: «Мы же предупреждали», и сделали себе «костыль», который кэшировал пароли в открытом виде.

И что мы получили в результате? Безопасность умножилась на ноль.

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

Secrets Manager: не изменение, а продолжение

Именно поэтому на рынке появился такой класс решений, как Secrets Manager (например, CyberArk Conjur). Это не замена вашему основному PAM, а его логическое продолжение — высокоскоростной курьер.

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

Отдел ИБ получает свой единый «центр правды» — классический Vault. Там они меняют пароли, настраивают политики, проходят аудиты по стандарту ISO 27001. Они довольны. Но вместо того, чтобы заставлять разработчиков заходить в этот Vault, мы размещаем легкий, горизонтально масштабируемый Secrets Manager прямо в их DevOps-среду. Он извлекает секреты из Vault и раздает их контейнерам за миллисекунды.

Причём делает это «нативно». Разработчику не нужно переписывать свой код, чтобы научить его работать с новым API безопасности. Secrets Manager сам подставляет нужный пароль прямо в память контейнера во время его запуска. Разработчик продолжает писать код так, как привык. Пайплайны работают, релизы не останавливаются.

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