Основи безпеки конвеєрів CI/CD, які треба знати всім (Частина 2)
Втрата або пошкодження даних 💔 Це слова від яких серденько стискається у всіх без винятку. Від виховательки дитсадка, що не може скинути відео зі свята у батьківський чат через його пошкодження. До DevOps-інженера, який не до кінця розібрався у безпеці конвеєрів CI/CD і втратив сон, гроші, а головне — важливу інформацію. Сьогодні мова піде про останніх.
Адміністрування безпеки конвеєрів CI/CD не тільки захищає дані та код від потенційних порушень. Воно допомагає підтримувати відповідність і запобігати випадковим проблемам. Яким саме і яким чином — дізнаєтеся нижче. Там і кроки для ефективного впровадження безпеки CI/CD, і опенсорсні інструменти для спрощення процесу.
Раптом ви пропустили. Ми вже розповідали, як впровадити конвеєри CI/CD на основі Kubernetes. Розглядали поширені загрози безпеки та основи їх захисту. Тепер час поговорити про адміністрування безпеки конвеєрів 👇
Як убезпечити конвеєри CI/CD?
Безпека конвеєра CI/CD вимагає багатостороннього підходу, тому вам потрібно буде розгорнути певні інструменти та процеси. Нижче навели 7 ключових дій, які допоможуть виявити ризики безпеки CI/CD й керувати ними.
То, що ми робимо?
Впроваджуємо жорсткий контроль доступу
Першим кроком до захисту конвеєра є контроль і організація привілеїв доступу. Реєструйте, відстежуйте та керуйте доступом до кожного компонента та ресурсу конвеєра. На основі ролей, часу чи завдань, головне це контролювати.
Проводьте регулярні аудити, щоб надлишкові облікові записи комп’ютерів або служб, а також колишні співробітники мали відкликані дозволи. Вимагайте суворої автентифікації для всіх користувачів та регулярно змінюйте паролі.
Підходи, які допоможуть забезпечити контроль доступу, включають:
- Ідентифікацію та керування доступом (IAM) — допомагає налаштувати цифрові ідентифікатори та застосувати дозволи доступу на рівні об’єкта
- Контроль доступу на основі ролей (RBAC) — обмежує доступ користувачів до даних і ресурсів на основі функцій/завдань, пов’язаних з їхніми ролями
- Принцип найменших привілеїв — обмежує права доступу користувача лише до того, що потрібно для виконання його роботи
Надаємо безпечний доступ до репозиторіїв коду
Захист репозиторіїв — наступний важливий крок. Бо вони діють як центральна система зберігання, перегляду та керування кодом, який використовується в конвеєрі DevOps. Загальнодоступні сховища коду або ті, у яких відсутні безпечні елементи керування, часто стають цілями зловмисників.
Як захистити репозиторій?
- Виберіть надійне сховище від постачальників із репутацією безпечного адміністрування та керування інфраструктурою.
- Застосуйте принцип найменших привілеїв для доступу до сховища.
- Захистіть та відокремте від вихідного коду облікові дані доступу.
- Скасуйте доступ до репозиторію, коли він більше не потрібен.
- Перегляньте всі зміни коду перед злиттям з основною гілкою.
- Приховуйте особисту інформацію під час використання загальнодоступних сховищ.
- Подбайте про резервне копіювання та аварійне відновлення для всього коду, що використовується в системі.
- Виконуйте регулярні аудити за контрольними показниками безпеки.
Уникаємо секретів жорсткого кодування
Наступним кроком стануть жорстко закодовані паролі та секрети. Вони є поширеними цілями атак, які призводять до витоку даних і незаконного доступу до ресурсів конвеєра. Зловмисники зазвичай націлюються на вихідні коди в загальнодоступних сховищах й ідентифікують жорстко закодовані облікові дані шляхом сканування коду, вгадування та вивчення.
Адміністратори безпеки повинні реалізувати політику, що буде регулювати використання жорстко закодованих секретів у коді програми. Якщо секрети потрібно аналізувати, їх слід включити як змінні у файл .gitignore. Ця дія запобігає їх закріпленню в репозиторії.
Наприклад, перш ніж розповсюджувати секрети в кластері Kubernetes, секрети потрібно спочатку зашифрувати в стані спокою, а потім зберегти на сервері ETCD.
Традиційним підходом для досягнення цього є кодування секретів у форматі Base64:
$ username=$(echo -n "default" | base64)
$ password=$(echo -n "a62fjbd37942dcs" | base64)
Далі, визначаємо секрети:
echo "apiVersion: v1
> kind: Secret
> metadata:
> name: darwin-secret
> type: Opaque
> data:
> username: $username
> password: $password" >> secret.yaml
Дотримуючись вищесказаного, тепер ви можете створити секрет за допомогою команди kubectl create:
$ kubectl create -f secret.yaml
Виконуємо тести безпеки програми
Якщо сховища коду захищені, а секрети безпечно керуються, слід переходити до наступного кроку — тестування. Розробники та групи безпеки повинні спільно переконатися, що вихідний код вільний від будь-яких уразливостей. Тут на допомогу прийдуть комбінації тестів, які розгортаються на кожному рівні робочих процесів CI/CD.
До перевірки конвеєрів виробничого класу часто залучають зовнішніх тестувальників. Це допомагає отримати неупереджену оцінку вразливості та виявити недоліки, які могли пропустити автоматизовані тести.
Використовуємо відкат для посилення безпеки у продакшн конвеєрах
Наступний етап зосереджується на мінімізації наслідків успішної атаки. Тут слід сформулювати елементи керування, які допоможуть повернутися до попередніх стабільних версій програми, якщо поточну скомпрометували.
Можливість швидкого відкату незахищеної версії програми також допомагає:
- скоротити час простою програми,
- прискорюючи цикли виправлення для швидшого відновлення.
Окреслюємо план реагування на інцидент
Далі слід подумати про план реагування на інциденти. Вже зіставили потенційні загрози безпеки з відповідними векторами атак? Створіть план реагування на інцидент. Він повинен окреслити інструменти та процеси, які ви будете використовувати для відновлення роботи.
Плани реагування також повинні позначати тегами пов’язані некритичні інциденти. Це важливо, бо вони можуть сигналізувати про потенційні проблеми в програмі. Це допоможе розробникам налаштувати свій код більш безпечно та продуктивно.
Використовуємо SIEM
Фінальний крок стосується системи SIEM (Безпека інформації та керування подіями). Для захисту конвеєрів CI/CD інструменти SIEM виконують три важливі функції:
- Виявлять загрози
- Розслідують події
- Скорочують часу відгуку
Ці інструменти збирають і аналізують телеметричні дані з різних ресурсів конвеєра CI/CD. Зведені дані потім зберігаються, нормалізуються та аналізуються, щоб виявити загрози й проаналізувати тенденції.
Не SIEM єдиною. Аби тестувальники безпеки та розробники швидше виявляли й усували порушення безпеки, слід інтегрувати систему безперервного тестування та моніторингу.
Популярні інструменти з відкритим кодом для захисту конвеєрів CI/CD
Зібрали список популярних безплатних інструментів із відкритим кодом, які спрощують реалізацію безпеки CI/CD і пропонують комплексні рішення захисту.
OWASP SonarQube
SonarQube — це інструмент статичного тестування безпеки додатків (SAST), який перевіряє додатки на відповідність найбільш критичним категоріям ризиків у коді. Це рішення перевіряє кожен фрагмент коду, який надходить у конвеєр, на відмовостійкість загрозам зі списку 10 найпопулярніших уразливостей OWASP.
Інструмент пропонує візуалізатор проблем. Це дозволяє детальніше перевірити, як уразливості проходять у конвеєрі. Тут SonarQube надає вказівки та поради.
OWASP Threat Dragon
OWASP Threat Dragon — це інструмент, який допомагає фіксувати можливі загрози в конвеєрах DevOps і усувати. Це рішення дотримується принципів і цінностей маніфесту моделювання загроз OWASP.
Threat Dragon використовує модель загроз STRIDE для групування загроз у шість категорій:
- Spoofing (Спуфінг, коли особа або програма маскується під іншу за допомогою фальсифікації даних).
- Tampering (Втручання, коли хакер змінює щось у пам’яті, на диску чи в мережі).
- Repudiation (Відмова, коли зловмисник унеможливлює пов’язати незаконну дію з його особою).
- Information disclosure (Розкриття інформації, коли особа порушує конфіденційність даних).
- Denial of Service (Відмова в обслуговуванні, коли хакери порушують доступність системи).
- Escalation of privileges (Підвищення привілеїв, коли зловмисники дозволяють неавторизованій особі отримати доступ до обмеженого файлу тощо).
Project Calico
Project Calico — це програмно визначене безпечне мережеве рішення з відкритим вихідним кодом для розгортання на основі контейнерів. Проєкт забезпечує нульову довіру на рівні кінцевої точки, GlobalNetworkPolicies, щоб захистити як контейнерні хости, так і робочі навантаження.
Інструмент також допомагає захистити внутрішньокластерний трафік модулів за допомогою мережевого шифрування. Це згодом забезпечить цілісність даних без використання спеціального обладнання.
Elastic Stack
Elastic Stack — потужна платформа для повного спостереження за конвеєрами CI/CD. Вона складається з трьох опенсорсних проєктів, кожен з яких спеціалізується на різних областях моніторингу:
- Elasticsearch — система пошуку та аналітики, яка допомагає зберігати та індексувати дані логів.
- Logstash — інструмент обробки даних, який витягує дані логів з кількох компонентів конвеєра CI/CD.
- Kibana — зовнішня структура візуалізації, яка надає інформацію про події безпеки в графічному форматі для простого аналізу.
На відміну від інших інструментів, Elastic Stack пропонує централізовану платформу, яка допомагає перевіряти проблеми з іншими основними індикаторами системи. Завдяки підтримці перевірок коду, тут ви зможете виявляти вразливості та виправляти їх завчасно. Без конфліктів конфігурації або проблем із відповідністю.
Післяслово
Практики DevOps впроваджують все більше компаній, тому фундаментальна безпека конвеєрів CI/CD стала важливим питанням. Все тому, що ці конвеєри часто є шлюзом до кодової бази організації та розгортань, що робить їх мішенню для зловмисників.
Чим надійнішим буде ваш конвеєр CI/CD, тим менше проблем з безпекою вам доведеться вирішувати, коли код буде на проді.
Щоб не втрапити в робочу халепу — покращуйте свої DevOps-скіли в IT Education Center. Обирайте будь-який курс цього рівня та отримуйте навички за вигідною ціною 🎓