Хто такий DevSecOps та чим він відрізняється від DevOps
Привіт всім! Мене звати Михайло, я — DevOps у P2H. Сьогодні хочу розповісти про DevSecOps: хто це, яка його роль і місія в компанії та чому в сучасному ІТ просто DevOps вже недостатньо. Матеріал буде корисний всім, хто планує опанувати цей напрям, уже працює з ним і хоче підсилити знання практичними кейсами.
Контекст
Спочатку заглибимося в історію DevOps. Щоб зрозуміти суть цього напряму, почнемо з циклу життя розробки програмного забезпечення (SDLC).
Так, ще до «ери DevOps» традиційним підходом була Waterfall model (модель каскаду). Це — цикл розробки за прямою лінією, що складається з кількох етапів:
- збір вимог від клієнта;
- проєктування програмного забезпечення відповідно до вимог;
- реалізація дизайну;
- тестування рішення;
- розгортання програмного забезпечення на Production;
- підтримка програмного забезпечення на етапі експлуатації.
Раніше, до Agile та DevOps, від збору вимог до етапу розгортання могло минути від декількох місяців до декількох років. Сьогодні Waterfall усе ще використовується, але рідше за SDLC + Agile-підхід, що зʼявився після нього.
Останній перетворив пряму лінію в коло, що дає гнучкість і змінює процес розробки, роблячи його справжнім циклом. Водночас період часу від однієї точки до іншої значно скорочується.
У застосуванні всіх цих моделей залишалася «стіна непорозуміння» в технічних і управлінських питаннях між розробниками (Developers) та операційним відділом (Operations): розробники бажали змін, а операційні команди — стабільності.
Тож DevOps як культура з набором відповідних практик виникла, щоб їх «подружити».
DevOps і DevSecOps: явище, особа чи процес
DevOps — це набір практик та культура, що спрямовані на скорочення часу між внесенням змін до системи та запуском їх в експлуатацію, водночас вони забезпечують високу якість. Але людина ≠ практика. Відповідно, спеціаліст, до якого звертаються як до DevOps-інженера, володіє набором певних технік. Але в самій назві позиції це не відображається: «DevOps-інженер» історично склалася :)
За набором технік цю роль можна розкласти на такі умовні напрями:
- Infrastructure Engineer: відповідальний за проєктування та взаємодію фізичних або хмарних інфраструктурних об’єктів й мереж;
- Cloud Engineer: працює над розгортанням, управлінням і оптимізацією інфраструктури та послуг на основі Cloud-технологій, як-от AWS, Azure, GCP;
- Automation Engineer: фокусується на розробці та підтримці скриптів та інструментів автоматизації;
- Release Engineer: відповідає за процес релізу, зокрема за тестування, пакетування та розгортання програмного забезпечення, забезпечуючи м’який і контрольований реліз у різних середовищах;
- Configuration Management Engineer: працює з інструментами управління конфігураціями, як-то Puppet, Chef, Ansible, забезпечуючи однорідну та надійну конфігурацію інфраструктури й застосунків;
- Continuous Integration/Continuous Delivery (CI/CD) Engineer: спеціалізується на створенні та підтримці пайплайнів CI/CD, автоматизації процесів збірки, тестування та розгортання програмного забезпечення;
- Monitoring Engineer: відповідає за впровадження та підтримку систем моніторингу та логування, відстежує продуктивність, стан та доступність програми та інфраструктури;
- Security Engineer (~DevSecOps): працює над інтеграцією практик безпеки в процес розробки, зокрема над скануванням на вразливості, тестуванням безпеки та забезпеченням відповідності стандартам та правилам галузі.
Ці напрями зазвичай поєднує в собі одна позиція — DevOps-інженер. Так відбувається, адже всі перераховані ролі та відповідні обов’язки можуть збігатися чи відрізнятися залежно від компанії.
DevSecOps — це одна з частин DevOps, утворена на перетині DevOps (розробка та операція) та Security (безпека операцій). Ця роль більш зосереджена на впровадженні й покращенні безпекових практик у робочих процесах.
Що робить DevSecOps-інженер на практиці, щоб покращити робочий процес DevOps:
- впроваджує сканування безпеки за допомогою методів SCA, SAST, DAST;
- збирає звіти та аналізує їх. Він також може надсилати їх до системи перевірки вразливостей — але це вже «просунутий» рівень;
- створює алерти та налаштовує пайплайни;
- комунікує з розробниками, аби розв’язати виявлені проблеми.
Впровадження практик DevSecOps
До того, як розбиратися далі з задачами DevSecOps, поставимо собі декілька запитань. Вони допоможуть визначитися, з чим вам доведеться працювати як інженеру та які ваші подальші кроки.
- Вразливий компонент не має відомих способів виправлення: що ви зробили б у цьому разі? Проігнорували б його чи створили власний патч?
- Якщо фікса/патчу компонента немає (застарілий код), чи хочете ви створити патч та надалі підтримувати цей компонент? Чи подумали про вартість підтримки?
- Якщо патч є, але ви однаково хочете його проігнорувати, якими були б ваші критерії оцінки ризику? Де б вирішили зберігати виправлену версію?
- Оновлення порушує роботу програми: вразливий компонент має виправлену версію з патчем, але якщо ви його оновите, ваша програма може зламатися — тож чи будете ви оновлювати версію?
- Пряма залежність vs транзитивна залежність (залежність від залежності).
- Аналіз хибнопозитивних результатів: хто має цим займатися, команда безпеки чи команда розробників?
- Чи є у вас механізм для роботи з вразливостями у власних пакетах?
- Коли вам було б зручно використовувати віртуальний патчинг (ModSecurity та CRS)?
- Як би ви намагалися впоратися з великою кількістю проблем? Початкове сканування може виявити як кілька сотень, так і сотні тисяч OAST-проблем; ви займалися б лише найпріоритетнішими, середніми чи всіма проблемами?
- Як часто ви б робили аналіз хибнопозитивних результатів? Як часто ви б поверталися до проігнорованих питань, якщо такі є?
Види сканувань безпеки
Розглянемо такі види сканувань безпеки програм:
SCA< (Software Component Analysis — аналіз компонентів програмного забезпечення)
Зазвичай програми використовують багато сторонніх бібліотек у ролі залежностей. За допомогою SCA можна просканувати ці бібліотеки та виявити серед них вразливі. Такий аналіз легко почати, він досить прямолінійний та, на відміну від SAST, дає менше хибнопозитивних результатів. Але є недоліки, як-от використання контрольних сум файлів та пакетів для виявлення вразливостей. Він не підійде для внутрішніх або невідомих компонентів від виробника.
Нижче наведено приклади інструментів SCA:
SAST (Static Application Security Testing — статичне тестування безпеки застосунків)
Це метод аналізу вихідного коду, двійкового та байт-коду на наявність вразливостей безпеки без запуску самого коду. До статичного аналізу належить як SAST, так і SCA, linting і сканування секретів.
SAST аналізуватиме написаний розробником вихідний код програми. Перевага SAST сканування в тому, що його легко почати. За правильного налаштування, його налаштування також зазвичай досить прямолінійне. Крім того, інструменти SAST також швидко надають зворотний зв’язок команді. Їх можна також налаштувати для зменшення хибнопозитивних результатів за допомогою власних правил. Щобільше, більшість із них підтримують декілька мов і мають багато безкоштовних додаткових інструментів.
З недоліків: за природою статичний аналіз схильний до високого рівня хибнопозитивних результатів і потребує багато часу для сканування. Водночас він не може знайти помилки під час виконання та в бізнес-логіці. Багато його інструментів також не відповідають сучасним стандартам безпеки, а відсутність локальної обробки хибнопозитивних результатів є великим недоліком.
DAST (Dynamic Application Security Testing — динамічне тестування безпеки застосунків)
Це метод аналізу запущеного застосунку на наявність безпекових вразливостей. Як зрозуміло з назви, він перевіряє запущений застосунок в динаміці. DAST корисний для:
- застосунків (ZAP);
- конфігурацій (molecule/knife);
- інфраструктури як коду (ansible/molecule);
- Docker (Docker benchmark security).
Сильна сторона такого сканування в тому, що аналіз легко почати, навіть без глибоких знань мови програмування.
Недолік динамічного аналізу — це схильність до недостатнього охоплення, бо він не може працювати з важкими JavaScript-фреймворками. Багато DAST-інструментів також не вписуються в сучасні CI/CD-пайплайни та потребують підтримки й ручної роботи. Тут на допомогу може прийти ZAP Proxy — це опенсорс-вебсканер вразливостей, який може знайти поширені проблеми безпеки, наприклад, зі списку OWASP Top-10.
Infrastructure as code та його безпека
Про сам підхід Infrastructure as code вже є достатньо матеріалів. Тож одразу розглянемо, який зв’язок між DevSecOps та Ansible.
Якщо коротко, Ansible — це інструмент автоматизації. Ви можете передати йому список серверів, і він виконає всі необхідні налаштування, які ви підготували раніше. Наприклад, щоразу, коли створюється ваш сервер, потрібно встановити Docker, налаштувати потрібний фаєрвол, доступ для користувачів тощо. Усе це можна автоматизувати за допомогою Ansible.
Для DevSecOps-процесів Ansible знадобиться, щоб зміцнити захищеність операційних систем та серверів від потенційних атак відповідно до різних стандартів, як-от PCI, HIPAA тощо. До того ж завдяки тому, що з ним легко будувати відтворювані системи, Ansible дозволяє швидше тестувати патчі безпеки, а також виконувати патчинг систем без даунтаймів.
Зміцнення безпеки (hardening) — це процес посилення захисту системи від потенційних вразливостей та атак. Приклад зміцнення за допомогою Ansible можна подивитися тут.
Працює це так: ви берете одну з наявних ролей Ansible та запускаєте цю роль на вашому сервері. Це має сенс і переважно використовується на серверах, де є суворі вимоги до безпеки, наприклад, платіжні сервіси.
Compliance as code: тестування проведеного зміцнення
Для певних бізнесів дотримання вимог (business compliance) може бути одним з найважливіших аспектів, тож вони впроваджують спеціальні стандарти безпеки, наприклад, PCI-DSS, HIPAA, GDPR, FedRAMP тощо. У такому разі після зміцнення серверів обов’язково проводиться його тестування на відповідність нормам безпеки. Це можна зробити за допомогою інструментів відповідності (compliance tools).
Цей підхід називається Compliance as code — тобто використання коду та інструментів автоматизації для визначення, впровадження та перевірки відповідності вимогам стандартів для ІТ-систем та інфраструктури. Розгляньмо один з таких інструментів.
Inspec — фреймворк для тестування з відкритим кодом. Він призначений для автоматизації тестування на відповідність та безпеку ІТ-інфраструктури та застосунків. Приклад його застосування для Linux можна побачити тут.
Vulnerability management: працюємо з виявленими вразливостями
Ви отримали багато звітів про вразливості вашої системи. Що з ними робити?
Для цього існує управління вразливостями (vulnerability management) — процес виявлення, оцінки, визначення пріоритетів та зменшення вразливостей у програмних системах або мережах. Він передбачає постійний активний моніторинг потенційних загроз безпеки та усунення цих вразливостей.
Як почати процес управління вразливостями:
- запроваджуйте цей підхід повільно і поетапно;
- починайте з інструментів, які дають низький відсоток хибнопозитивних результатів (наприклад, SCA, Baseline Scan тощо);
- підтримуйте комунікацію з Product Owner, розробниками та QA для усунення проблем.
Перевагами такого системного підходу є впровадження програм безпеки та business compliance, що дозволяє визначити пріоритетність вразливостей на основі ризику. Управління вразливостями також покращує рівень зрілості вашої інфраструктури та дає розуміння ефективності програми. Звісно ж, наявність системи управління вразливостями та метрик додає цінності для клієнта та є хорошим показником професіоналізму, а у разі внутрішнього або зовнішнього аудиту — буде джерелом необхідних даних. Це також допомагає створювати метрики для всієї організації та на різних рівнях деталізації.
Які інструменти можна використати в процесі управління вразливостями? Пропоную розглянути Defect Dojo — він може приймати звіти про вразливості в різних форматах та агрегувати їх в одну систему. Тут доступний перегляд того, з якими сканерами його можливо інтегрувати.
Отже, поетапно процес управління вразливостями виглядає так:
- Знайти вразливості за допомогою інструментів (врахуйте, який рівень деталізації вам потрібен).
- Агрегувати результати пошуку різними інструментами в одну систему.
- Опрацювати знайдені проблеми щодо хибних спрацювань.
- Усунути проблеми — занести їх у баг-трекер для виправлення.
- Зробити висновки на майбутнє — створити метрики/дашборди для стейкхолдерів (кількість вразливостей високої/середньої/низької серйозності, топ вразливостей за бізнес-підрозділами, середній час на виявлення (MTTF) та усунення тощо).
DSOMM (DevSecOps Maturity Model)
Щоб зосередити увагу DevOps-спеціалістів на актуальних проблемах безпеки, спільнота OWASP запропонувала DSOMM (DevSecOps Maturity Model) — модель зрілості DevSecOps, що надає можливості для зміцнення стратегій DevOps і показує, як їх можна розташувати за пріоритетами для посилення безпеки.
Ця модель має чотири вісі та п’ять рівнів зрілості, а кожна вісь відповідно до своєї глибини визначає рівень зрілості. Існують:
- статична глибина (наскільки глибокий аналіз статичного коду виконується в рамках DevSecOps CI chain);
- динамічна глибина (динамічні тести виконуються з використанням засобів безпеки).
А також:
- інтенсивність (як часто виконується сканування безпеки в
CI-пайплайні); - консолідація (як обробляються результати).
Зосередимося на перших двох рівнях.
Рівень перший:
- статична глибина — запуск інструменту статичного аналізу як є, без будь-яких змін в інструменті або налаштуваннях;
- динамічна глибина — запуск інструментів DAST як є, з налаштуваннями за замовчуванням;
- інтенсивність — сканування виконується на головній гілці репозиторію, навіть з низькою частотою;
- консолідація — необов’язкова, може бути пропущена.
Перехід з першого рівня на другий може зайняти певний час і потребувати тісної взаємодії з командою розробників.
Рівень другий:
- статична глибина — запуск SAST, інструментів сканування секретів з незначними змінами конфігурацій;
- динамічна глибина — запуск інструментів DAST з невеликими змінами;
- інтенсивність — намагайтеся проводити сканування частіше;
- консолідація — спробуйте зберігати результати інструментів на
CI-сервері.
Детально прочитати про кожний пункт можна тут та навіть спробувати побудувати свою власну матрицю.
Вибір інструменту для роботи
Оскільки маємо багато сканувань, нам потрібно знайти інструмент, що найкраще задовольняє наші потреби. Пропоную під час вибору складати порівняльну таблицю, орієнтуючись на такі критерії:
- Підтримка мови та стеку інструментів, які ви використовуєте.
- Вільне та відкрите програмне забезпечення (FOSS) чи платне.
- Дозвіл проігнорувати знайдену проблему локально — якщо розробники можуть виправити хибнопозитивний результат у коді, тоді їм не потрібно переходити на інший ресурс, щоб позначити цей результат як хибнопозитивний. А це значно заощаджує час на усунення проблем.
- Можливість інструмента керувати обсягом і глибиною сканування.
- Можливість зупинити збірку на підставі результатів сканування (дуже бажано).
- Дозвіл зберігати результати як файл у форматі, який може обробити комп’ютер (JSON, CSV, XML) або який надає API. Це допомагає обмінюватися результатами з іншими системами в організації.
Ось таку порівняльну таблицю можна скласти, наприклад, для SCA-сканера Safety:
«Заповіді» DevSecOps
Поділюся так званими заповідями, тобто правилами, що є необхідними для успішної реалізації DevSecOps:
- спілкуйтеся та координуйте дії з розробниками, QA та командою Operations;
- не зупиняйте пайплайн, якщо ви ще не досягли третього чи четвертого рівня зрілості DevSecOps;
- якщо робота якогось інструменту займає понад 10 хвилин — не використовуйте його в CI/CD-пайплайні;
- використовуйте окремі джоби для кожного інструменту чи сканування;
- упроваджуйте сканування поетапно (ітеративно) — інакше не уникнути хибнопозитивних результатів;
- не купуйте інструменти без API або CLI;
- краще купуйте інструменти, які можливо використовувати за моделлю per-use licensing;
- переконайтеся, що інструмент може виконувати інкрементне/базове сканування;
- не бійтеся створювати власні, кастомні правила сканувань;
- прагніть того, щоб все робити через код — Everything as Code (EaC);
- хибнопозитивні результати сканувань вразливостей також мають бути у вигляді коду — це допомагає контролювати обсяг сканування;
- додавайте посилання на документацію в пайплайн: так ви зможете поділитися експертизою вашої команди з іншими.
Висновок
Підсумувати все викладене в цій статті я хотів би простими й короткими пунктами:
- DevSecOps — це окрема роль і окремий спеціаліст в компанії (в ідеалі).
- Перш ніж починати роботу, варто ставити багато питань та спиратися на рішення й практики DevSecOps, що вже показали свою ефективність.
- Різні типи сканування (SCA, SAST, DAST): почати з простого, додати все в пайплайн, але робити поетапно.
- Впровадження DevSecOps: додавання сканувань не надто складне, але має значення те, хто буде керувати цим процесом — від сканування до обробки результатів та вирішення вразливостей.
Корисні посилання
- DevSecOps University;
- Free video course;
- OWASP Top-10;
- Awesome static analysis reference;
- DSOMM;
- Certified DevSecOps Professional.
Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!
4 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів