Стрімке зростання кількості кіберзагроз та винахідливість тих, хто за ними стоїть, спонукають впроваджувати нові заходи безпеки. Один із них — «безпека як код» (SaC, Security as Code). Він дозволяє враховувати безпековий фактор від початку розробки програмного забезпечення, а не додавати його наприкінці, як це відбувається зазвичай.
SaC стало логічним розвитком підходу «інфраструктура як код» (IaC). Сьогодні DevOps-команди роблять ставку на те, що саме «безпека як код» стане важливою частиною сталого підходу до забезпечення безпеки. До того ж в McKinsey назвали SaC найкращим і, можливо, єдиним шляхом для захисту хмарних застосунків та систем.
Трансформація від DevOps до DevSecOps
Основний принцип SaC полягає у тому, що безпека стає важливою особливістю та атрибутом процесу розробки ПЗ, а не розглядається лише в контексті реакції на інциденти, що несуть загрозу.
Системи, які мають швидко розвиватися, потребують прискореної розробки та розгортання застосунків, а для цього безпекові компоненти мають бути гнучкими, доступними та легко масштабованими. І все це стає можливим завдяки SaC: найкращі безпекові практики, протоколи безпеки та конфігурації не реалізуються вручну, а автоматизуються й інтегруються безпосередньо в кожен етап цикл розробки ПЗ.
Методологія SaC трансформує DevOps до DevSecOps. Тепер методи забезпечення безпеки впроваджуються протягом всього циклу розробки ПЗ, а команди, які відповідають за розробку та безпеку, працюють спільно.
У Gartner визначають DevSecOps як максимально просту та прозору інтеграцію безпеки в DevOps зі збереженням гнучкості та швидкості, але без необхідності виходити за межі звичного середовища розробки.
Володимир Булдижов, CISSP Cybersecurity Expert H-X Technologies, LLC:
«Основна ідея SaC — автоматизація Security DevOps. Це можна розглядати як розширення підходу інфраструктури як коду (IaC), але це трохи інше. Простий приклад SaC — скрипти, які автоматично перевіряють вихідний код на вразливості під час кожного злиття з основною гілкою в репозиторії. Більш просунутий приклад — мультидвигуновий моніторинг безпеки, хмарне рішення для глибокого аудиту та моніторингу безпеки, яке інтегрує в собі Nessus, Acunetix, Netsparker, CheckMarx, SonarQube, ZAP Proxy, OpenVAS, Snyk, Fortify, Arachni та сотні інших подібних інструментів».
Основними компонентами SaC можна назвати контроль доступу і керування політиками: access control and policy management. Так вважає Микола Ільїн, CTO KyivInfoSecurity LLC, https://molfar.biz:
«Винесення політик у конвеєр DevOps та моніторинг політик безпеки у реальному часі може ефективно підвищити захищеність системи, за умови правильного формулювання цих політик та використання кращих практик у SDLC. Це трудомісткий, але добре придатний до автоматизації процес, на відміну від тестування безпеки (security testing) та пошуку вразливостей (vulnerability scanning)».
У чому полягають переваги SaC
Впровадження SaC надає низку суттєвих переваг, які роблять його незамінним інструментом для будь-якої організації, яка прагне досягти найвищого рівня кіберстійкості. Розглянемо основні з них:
- Превентивна реакція на загрози. Це відбувається протягом ксього циклу розробки. Крім кіберзагроз, SaC охоплює помилки та збої, витоки даних, проблеми із продуктивністю та інші проблеми, які не пов’язані із діями зовнішніх зловмисників.
- Зниження ризиків. Зловмисники перебувають у постійному пошуку вразливостей. SaC дозволяє пам’ятати про це та запобігати негативним наслідкам від початку реалізації проєкту.
- Швидкість розробки. Розробники не зацікавлені в тому, щоб заходи безпеки уповільнювали їхню роботу, і SaC повністю відповідає цій вимозі.
- Безперервність. Перевірки на безпеку й тестування потенційно небезпечних фрагментів відбуваються регулярно і стають частиною життєвого циклу розробки.
- Автоматизація. SaC дозволяє автоматизувати процес автентифікації та перевірки коду в той час, як у стандартних робочих процесах DevOps для захисту коду використовується інфраструктура відкритих ключів (PKI) з великою кількістю ручних дій.
- Співпраця між відділами. Відділи розробки та безпеки працюють разом для досягнення спільних цілей.
- Покращення контролю якості. Тестування безпеки в кінці життєвого циклу розробки вимагає багато часу на відстежування помилок у значній кількості коду. Безперервне тестування дозволяє уникнути тієї кількості вразливостей, яка може бути виявлена в самому кінці.
Микола Ільїн говорить:
«Основна цінність впровадження принципів SaC полягає в можливості безперервного моніторингу і забезпечення безпеки середовища, в яке впроваджується програмне рішення. Більшість порушень безпеки на практиці є наслідком не інноваційної атаки з використанням невідомих засобів, а відсутності відомих механізмів контролю, що мали б бути впроваджені, але не працюють. Контроль цих механізмів може бути ефективно реалізований за допомогою SaC».
Крім того, важливим внеском SaC є підвищення ефективності та надійності управління інфраструктурою. Так вважає Максим Даценко, CTO at Cloudfresh:
«Це дозволяє швидше розгортати зміни, зменшувати людські помилки та забезпечувати узгодженість середовищ. SaC значно покращує співпрацю між командами розробки й експлуатації, прискорює час виходу на ринок та підвищує загальну якість продукту, а також сприяє кращому контролю витрат та оптимізації ресурсів».
Основні проблеми впровадження SaC
Попри низку переваг від впровадження SaC і трансформації DevOps у DevSecOps, це відбувається не завжди через низку перепон.
Перш за все DevSecOps потребує повного переосмислення основних процесів, пов’язаних із розробкою та безпекою. Потрібні операційні зміни, впровадження нової культури розробки й дійсно командна робота. Якщо команди розробки та безпеки звикли працювати окремо і деколи мають різне бачення однакових процесів, то зміни можуть бути доволі тривалими.
Проблема з кадрами не є надуманою, що підтверджує Максим Даценко:
«Один із серйозних викликів — це подолання опору персоналу до змін та необхідність їх перекваліфікації. Значні початкові інвестиції в інструменти та автоматизацію також створюють бар'єри. На мою думку, найсерйознішою перешкодою є трансформація мислення команд — перехід від мануального до програмного управління інфраструктурою. Крім того, важливо не нехтувати аспектами безпеки та дотримання нормативних вимог при автоматизації. Подолання цих труднощів потребує часу, лідерства та інвестицій у розвиток персоналу».
Також проблеми можуть виникнути при реалізації кожного з принципів SaC.
«Для компонента контролю доступу та керування політиками це коректне формулювання політики, з урахуванням вимог і реального стану проєкту, — вважає Ільїн Микола. — Немає сенсу контролювати те, що не працює. Компонент тестування безпеки — коректний підбір засобів аналізу, з урахуванням часу, що витрачається на тестування. Баланс ефективності тестів даного компоненту і часу роботи є ключовим, час виконання конвеєра може збільшуватися до меж втрати сенсу DevOps в цілому (десятки годин). Компонент пошуку вразливостей — релевантність тестів безпеки до застосовуваних технологій і платформ, наприклад, тестування SQL injection при застосуванні параметризованих запитів доцільніше проводити засобами аналізу коду».
Не варто розглядати SaC, а з ним і DevSecOps, як чарівну паличку, яка вирішить всі безпекові проблеми. Насправді DevSecOps неможливо використовувати для пошуку помилок бізнес-логіки, які мають великі наслідки, але які виявити складніше, ніж, наприклад, недотримання правил HIPAA. До того ж ви стикнетесь з обмеженням на ручні перевірки безпеки через тотальну автоматизацію підходів у DevSecOps, а отже, не зможете робити ручне тестування на проникнення.
«В цілому SaC не є заміною традиційному аудиту безпеки та тестування на проникнення, наголошує Микола Ільїн. — Є класи вразливостей, які не виявляються автоматичними засобами й пройдуть через конвеєр з елементами SaC у продуктову систему. SaC також не є заміною кваліфікованого персоналу — розробників, інженерів з безпеки застосунків. Залежність рівня безпеки кінцевого застосунку від вартості й кількості засобів SaC не лінійна, впровадження вимагає високого рівня експертизи від інженера з безпеки застосунків».
Як розпочати впровадження SaC
Загальні рекомендації щодо впровадження принципів SaС зазвичай включають рекомендацію розвивати серед команд культуру, яка орієнтована на безпеку. Після потрібно організувати навчання команд та розвивати між ними співпрацю, щоб сформувати єдине бачення процесів розробки та перевірки безпеки коду.
Микола Ільїн вважає, що розпочинати потрібно насамперед із залучення досвідченого інженера з безпеки застосунків:
«Він має бути знайомий зі стеком технологій проєкту. Надалі потрібно буде розробити політики безпеки для компонента access control and policy management та розпочинати їх впровадження».
Катерина Іваненко, Brand Manager CoreWin, надає наступні рекомендації щодо впровадження SaC:
«На початку шляху варто об`єктивно оцінити ефективність наявних заходів безпеки на кожному етапі життєвого циклу розробки. Далі слід створити покроковий план введення змін на основі потреб організації та поступово рухатися у заданому напрямку. Як дистриб'ютор ПЗ, ми знаємо, що це довгий шлях, у якому велику роль відіграє вибір якісних інструментів, що забезпечують автоматизацію та без проблем інтегруються в робочі процеси. Базовими практиками є використання сканерів з технологіями DAST і SAST, тому найкраще почати саме з них».
Крім DAST і SAST слід запропонувати командам інші інструменти, що орієнтовані на безпеку: окремі плагіни, скрипти, системи моніторингу тощо. Серед інших рекомендацій — перевірка та безперервне покращення процесів перевірки на безпеку, зокрема таким чином, щоб вони відповідали потребам кінцевих клієнтів та внутрішнім стандартам компанії. Так само важливим буде впровадження контрольних показників для команд — це допоможе впевнитися, що досягають поставлених цілей.
Раніше ми розповідали, що 60% ІТ-фахівців витрачають чотири дні або більше на усунення вразливостей – опитування JFrog.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
