Управління секретами в CI/CD-конвеєрах оборонних систем: Vault, HSM та ротація ключів

Кожна оборонна програмна система залежить від секретів: TLS-сертифікати, що автентифікують ідентичності сервісів, API-ключі, що авторизують доступ до зовнішніх сервісів, паролі баз даних, що захищають оперативні дані, ключі шифрування, що захищають таємну інформацію, та ключі підпису коду, що перевіряють цілісність мікропрограмного забезпечення і програмного коду. Якщо ці секрети обробляються недбало — зберігаються у конфігураційних файлах, потрапляють до репозиторіїв вихідного коду, передаються як змінні середовища у відкритому тексті або залишаються незмінними необмежено — вони стають векторами атак, що обходять усі інші засоби контролю безпеки.

Управління секретами в оборонних CI/CD-конвеєрах стосується не лише запобігання помилкам розробників (хоча й це теж). Йдеться про реалізацію архітектури безпеки, де секрети ніколи не зберігаються у відкритому тексті поза контекстом їх авторизованого використання, де кожне використання секрету фіксується в журналі аудиту, де секрети мають визначений термін дії та автоматично ротуються, а компрометація будь-якого окремого секрету має обмежений радіус ураження завдяки короткому терміну дії та обмеженому доступу.

Типи секретів в оборонних конвеєрах

Оборонні CI/CD-конвеєри стикаються з ширшим спектром типів секретів, ніж комерційні аналоги, оскільки системи, які вони розгортають, мають суворіші вимоги до контролю доступу та автентифікації:

TLS-сертифікати автентифікують ідентичності сервісів у розгортаннях mTLS та захищають мережеві комунікації. У оборонному кластері Kubernetes з сервісною сіткою кожен мікросервіс має власний сертифікат — потенційно тисячі сертифікатів загалом, усі з яких потребують ротації до закінчення терміну дії. Сертифікати для зовнішніх сервісів повинні бути підписані авторизованим ЦС; внутрішні сертифікати сервісів можуть бути підписані внутрішнім ЦС, керованим Vault або площиною управління сервісною сіткою.

API-ключі та токени доступу авторизують виклики між сервісами, доступ до зовнішніх фідів загроз розвідки, доступ до SIEM API та інтеграцію з бекендами засекречених систем. Зазвичай це статичні секрети (не генеруються динамічно), і вони найчастіше потрапляють до репозиторіїв вихідного коду через помилки розробників.

Облікові дані баз даних захищають доступ до оперативних та засекречених баз даних. Статичні облікові дані бази даних — пара імені користувача та пароля, що ніколи не змінюється — є суттєвим ризиком безпеки: якщо облікові дані скомпрометовані, доступ зберігається до їх ручної ротації, що може не відбуватися місяцями чи роками. Динамічні облікові дані з коротким терміном дії є значно безпечнішими.

Ключі підпису коду використовуються для підписання програмних релізів, образів контейнерів, пакетів мікропрограмного забезпечення та пакетів конфігурацій. Ці ключі надзвичайно чутливі — скомпрометований ключ підпису коду дозволяє зловмиснику підписувати шкідливий код, якому довірятимуть усі системи, що довіряють цьому ключу. Ключі підпису коду повинні захищатися апаратним HSM та потребувати багатосторонньої авторизації для використання.

HashiCorp Vault: динамічні секрети та журнал аудиту

HashiCorp Vault є стандартною платформою управління секретами для оборонних середовищ DevSecOps. Vault надає централізоване, аудитоване сховище секретів, уніфікований API для отримання секретів та рушій динамічних секретів, що генерує обмежені в часі, цільові облікові дані замість того, щоб вимагати від застосунків зберігати довгострокові статичні секрети.

Динамічні секрети є найпотужнішою функцією безпеки Vault. Замість зберігання статичного пароля бази даних, який застосунки отримують, Vault динамічно генерує нового користувача бази даних з обмеженими в часі обліковими даними кожного разу, коли застосунок запитує доступ. Облікові дані автоматично закінчуються, а користувач бази даних відкликається після закінчення терміну оренди (зазвичай 1–24 години). Зловмисник, що перехопив динамічні облікові дані бази даних, має вузьке вікно для їх використання до закінчення терміну дії; зловмисник з статичними обліковими даними має необмежений доступ до їх ручної ротації.

Рушії динамічних секретів Vault охоплюють PostgreSQL, MySQL, MSSQL, MongoDB, Cassandra, Elasticsearch (для управління журналами), PKI (видача сертифікатів), AWS IAM (хмарні облікові дані) та інше. Для оборонних середовищ рушій секретів PKI — який дозволяє Vault діяти як проміжний ЦС, видаючи короткострокові TLS-сертифікати на вимогу — є особливо цінним: сертифікати з TTL 24 години усувають вікно для зловживання сертифікатом у разі його компрометації.

Журнал аудиту Vault фіксує кожен API-виклик до Vault: кожен запит секрету, кожну спробу автентифікації, кожен пошук політики. Журнал аудиту є додатковим і не може бути змінений адміністраторами Vault. Для оборонних середовищ журнал аудиту надає доказову базу, необхідну для акредитації: хто отримав доступ до якого секрету, коли і з якої системи. Журнали аудиту Vault слід пересилати до SIEM для кореляції з подіями застосунків та мережі.

Апаратні модулі безпеки: коли програмного Vault недостатньо

HashiCorp Vault захищає власні ключі шифрування (головний ключ, що використовується для розпечатки Vault та шифрування його сховища секретів) за допомогою програмного підходу до шифрування ключів. Для більшості середовищ це є адекватним рівнем безпеки. Для оборонних середовищ з вимогами FIPS 140-2 рівня 3 — що застосовуються до систем національної безпеки та систем, що обробляють засекречений криптографічний ключовий матеріал — кореневі ключі повинні захищатися апаратним, а не програмним забезпеченням.

FIPS 140-2 рівня 3 вимагає захисту від фізичного втручання з індикацією, автентифікації на основі ідентичності для операторів та критичних параметрів безпеки (приватних ключів), що не експортуються у відкритому тексті ніколи. Програмні сховища ключів, якими б добре зашифрованими вони не були, не відповідають цій вимозі, оскільки сам ключ шифрування існує в пам'яті програмного забезпечення, де він потенційно доступний привілейованому зловмисникові.

Автоматичне розпечатування HSM для Vault є стандартною архітектурою: головний ключ Vault обгортається ключем HSM, і Vault автоматично розпечатується, надсилаючи свій загорнутий головний ключ до HSM для розгортання при запуску. HSM виконує розшифрування у своїй захищеній від втручання межі — головний ключ ніколи не існує у відкритому тексті поза HSM. Ця архітектура відповідає вимогам FIPS 140-2 рівня 3 для рівня захисту кореневого ключа.

Підтримувана інтеграція HSM для HashiCorp Vault Enterprise включає Thales (колишній SafeNet) Luna, nCipher nShield, AWS CloudHSM та Azure Dedicated HSM. Для ізольованих оборонних середовищ потрібні локальні варіанти HSM (Thales Luna, nCipher nShield) — хмарні HSM-сервіси недоступні з ізольованих мереж.

Ротація ключів без простою

Ротація ключів — заміна існуючого криптографічного ключа новим — є важливою для гігієни безпеки: вона обмежує вікно впливу у разі компрометації ключа та задовольняє регуляторні вимоги щодо обмежень терміну дії ключів. Але ротація ключів, що вимагає простою застосунків або складної ручної координації, часто відкладається на невизначений термін, зводячи нанівець її цінність для безпеки.

Версіонування ключів Vault забезпечує ротацію без простою для секретів та ключів шифрування. Коли рушій транзитного шифрування Vault (що надає застосункам шифрування як послугу) ротує ключ, він створює нову версію ключа, зберігаючи старіші версії для розшифрування даних, зашифрованих попередніми версіями. Застосунки, що шифрують нові дані, використовують поточну версію ключа; існуючий шифротекст може бути розшифрований за допомогою старої версії до оновлення застосунку для повторного шифрування. Ротація є прозорою для застосунку — він не потребує виведення з ладу.

Пільгові періоди для ротації сертифікатів дозволяють поступово розгортати нові сертифікати: новий сертифікат розповсюджується та отримує довіру до відкликання старого, щоб не було вікна, де деякі сервіси мають новий сертифікат, а інші ще не отримали його. Рушій секретів PKI Vault підтримує налаштування TTL сертифікатів та periodів поновлення для автоматизації цього управління пільговим periodом.

Інтеграція CI/CD: шаблони впровадження секретів

Секрети повинні потрапляти до застосунків та компонентів інфраструктури, яким вони потрібні, без їх розкриття в журналах CI/CD-конвеєра, дампах змінних середовища або шарах образів контейнерів. Три шаблони інтеграції домінують в оборонних CI/CD-середовищах:

Sidecar-агент Vault (у Kubernetes) розгортає контейнер Vault Agent поряд з контейнером застосунку. Vault Agent автентифікується у Vault за допомогою ідентичності облікового запису сервісу Kubernetes пода, отримує налаштовані секрети та записує їх у спільний том у пам'яті або впроваджує їх у середовище контейнера застосунку. Секрети ніколи не з'являються у специфікації пода або образі контейнера — вони впроваджуються під час виконання з Vault.

External Secrets Operator — це оператор Kubernetes, що синхронізує секрети з зовнішніх сховищ секретів (Vault, AWS Secrets Manager, Azure Key Vault) у Kubernetes Secrets. Він забезпечує декларативний, сумісний з GitOps підхід: ресурс ExternalSecret у конфігурації GitLab/Kubernetes оголошує, які секрети потрібні та звідки вони надходять; оператор обробляє отримання та синхронізацію. Kubernetes Secrets, створені оператором, можуть монтуватися у поди нормально.

Для конвеєрів GitLab CI інтеграція GitLab-Vault (інтеграція GitLab CI/CD Vault з використанням JWT-автентифікації) дозволяє завданням конвеєра автентифікуватися у Vault за допомогою їх JWT-ідентичності GitLab та отримувати секрети на тривалість завдання конвеєра. Секрети доступні як змінні середовища в межах завдання та ніколи не зберігаються у конфігурації GitLab CI або репозиторії.