Безпека проти швидкості: як впровадити Secrets Manager і не посваритися з DevOps

Знаєте, яка зустріч у компанії зазвичай проходить найемоційніше? Коли в одній переговорці або в зумі збираються відділ інформаційної безпеки та команда 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 не терпить «милиць». Якщо безпека створює тертя — її обійдуть. Успішні проєкти, які ми бачимо в дистрибуції, будуються не на заборонах, а на інтеграції. Коли інструмент безпеки працює «під капотом» і розмовляє з розробником його мовою — конфлікт закінчується, і починається нормальна інженерна робота.

Напишіть нам для отримання консультації: [email protected]