Про DevSecOps: основні підходи, практики, інструменти

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

«Про кібербезпеку задумуються, коли вже сталась халепа», — саме це я часто чую від своїх колег кібербезпеки.

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

У площині DevOps існує DevSecOps, який є відгуком на сучасні виклики у сфері безпеки та одночасно на швидкість розробки програмного забезпечення. Далі я б хотів навести основні практики в кібербезпеці, які застосовні відносно DevOps-практик.

Думайте про безпеку інфраструктури у різних площинах, зокрема 4Cs

З точки зору інфраструктури, варто ввести всі можливі заходи безпеки у всіх її площинах, як-от:

1. Code security.
2. Container security.
3. Cluster security.
4. Cloud security.

На кожному рівні повинні бути інтегровані практики для покращення безпеки системи загалом, про які поговоримо далі.

Автоматизація безпеки в CI/CD

DevSecOps містить автоматизацію тестування безпеки в процес конвеєру релізу коду. Це означає, що засоби тестування безпеки та інші інструменти інтегруються в пайплайни CI/CD, щоб виявляти та виправляти потенційні уразливості на кожному етапі розробки.

Один з White-box security testing підходів називається SAST (Static Application Security Testing). Ось основні принцими цього підходу:

• рання фаза знаходження вразливостей;
• виявлення недоліків на рівні коду;
• інтеграція із середовищами розробки;
• підтримка Compliance-стандартів (CIS, PCI-DSS, etc);
• автоматичне сканування.

Нижче ще приведу декілька популярних інструментів для аналізу коду:

• Sonarqube: платформа з відкритим кодом для постійної перевірки якості коду.
• Bandid: SAST-інструмент, орієнтований на Python.
• SpotBugs: інструмент статичного аналізу з відкритим кодом для Java.

Також варто зазначити, що базуючись на принципі 4Cs до автоматизації безпеки входять інструменти сканування докер імеджей, Kubernetes-кластерів та Cloud-інфраструктури.

Управління конфігураціями середовища, секретами

Важливим елементом є ефективне управління паролями та секретними даними. Недостатній контроль над цими елементами може призвести до серйозних безпекових проблем. Використання інструментів, як-от AWS secret manager або HashiCorp Vault, може значно полегшити цей процес.

Ось основні функції які, до прикладу, HashiCorp Vault може взяти на себе:

• зберігання та управління секретами;
• динамічні ролі доступу;
• версіювання в секретах;

Незалежно від розміру проєкту практика управління секретів повинна бути впроваджена, адже це дає можливість централізовано змінювати паролі, контролювати до них доступ та трамити логи запитів до них.

Керування ідентифікацією та доступом

Централізоване управління доступами, підключення MFA, застосування ролей та регулярне оновлення паролів є обовʼязковим коли мова йде про безпеку. Тут важливо дотримуватись принципу Least privilege, де правила * або 0777 перебувають по інший бік барикад від вас.

Кількість доступів повинна бути мінімальним і покривати тільки ті потреби які потрібні саме зараз.

Також щоб запобігти випадкам, коли колега вже рік як не працює на проєкті, а в нього ще є доступи на сервіс, впроваджуйте систему централізованого управління доступами. Напевно одні з найпоширеніших це Keycloak (opensource) та Okta.

Моніторинг та журналювання

Коли йдеться про моніторінг, зазвичай говорять про збір основних метрик навантаження (CPU, Memory, Disk, etc) серверів, середовища. До цих показників важливо ще додавати моніторінг уразливості системи.

До ваших системи моніторингу та логування Prometheus-grafana або AWS CloudWatch, додавайте ще системи журналювання API-дій для виявлення потенційних загроз в Cloud-провайдері.

Наприклад, це може бути CloudTrail для AWS або Cloud Audit Log в GCP.

Окрім того, існують бази даних, complience frameworks, які агрегують всі відомі вразливості систем залежно від їхніх версій.

На основі цих даних секьюріті моніторінг інструменти перевіряють інфраструктурне середовище. Наприклад, для хмари є опенсорс-інструмент prowler (github.com/prowler-cloud/prowler), він проінспектує конфігурацію вашого cloud-провайдера (AWS, GCP та Azure). Його основні фреймворки (бази) сканування: CIS, PCI-DSS, ISO27001, GDPR.

Для автоматичної перевірки Kubernetes-кластерів можна використовувати секʼюріті-сканер kube-bench. Його інтегрують в сам кластер через куб. оператор або використовують самостійно через CLI.

Взагалі в цього вендора ще є ультимативний CLI-інструмент перевірки інфраструкрути на всіх рівнях 4Сs (Code repository, Container, Cluster, Cloud) — trivy.

Ідентифікація та управління ризиками

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

Визначення та оцінка ризиків є ключовою частиною безпеки інфраструктури. Застосовуючи методології, як-от Threat Modeling, команди можуть ідентифікувати потенційні ризики та ухвалювати відповідні заходи забезпечення безпеки. Нижче наведу декілька основних кроків цього підходу:

• Створіть огляд системи. Створіть повне розуміння архітектури інфраструктури, компонентів і потоків даних.
• Визначте загрози та вразливі місця. Проведіть мозковий штурм щодо потенційних загроз і вразливостей, які можуть вплинути на безпеку системи.
• Mitigation Strategies. Створіть та задокументуйте стратегії пом’якшення для кожної виявленої загрози.
• Інтегруйте в Development Lifecycle (SDLC). Додайте до ваших пайплайнів кроки перевірки коду, образів на знаходження вразливостей.

Культура безпеки

Як всім відомо, найслабша ланка в безпеці будь-якої інфраструктури є саме людина.

Усі вище наведені принципи просто не будуть діяти, якщо всі члени команди не будуть дотримуватись банальних правил безпеки: від написання превентивно безпечного коду (тули типу SonarQube — не панацея, адже кількість нових вразливостей тільки зростає) до всім відомих правил на кшталт «не проходь за підозрілими лінками, які тобі вислали на пошту».

Необхідно з певною періодичністю нагадувати ці прості істини своїй команді, а також на власному прикладі показувати, що таке безпека та чому вона потрібна.

Сподіваюсь, стаття була інформативною та трохи прояснила базові принципи DevSecOps з можливим інструментарієм. А які заходи безпеки використовуєте ви у своїх проєктах? Діліться в коментарях 🙂

P.S. Друзі, якраз збираю групу для менторства у напрямі DevOps. Якщо ти організований, відповідальний, і в тебе є базовий досвід в програмуванні або в адмініструванні — пропоную долучитись. За деталями пиши мені в особисті.