DevOps+Security, SecDevOps, DevSecOps: в чому різниця і що обрати
Всім привіт, я — Михайло Косинський, Senior DevSecOps Engineer в SoftServe. У цій статті ми розберемося:
- чому DevOps обов’язково повинен включати в себе компонент безпеки;
- на прикладах розглянемо, що відбувається, якщо ці дві фази не пов’язані між собою;
- подивимося, як DevOps взаємодіє з безпекою у нас в компанії.
Постараюся простою мовою описати свій досвід і спостереження.
DevOps без Security в підсумку може обійтися надто дорого
Я починав кар’єру як системний адміністратор. Ця професія передбачає знання передових аспектів безпеки. Потім перейшов у DevOps, де спочатку фокусувався на відповідності обраного для імплементації рішення завданням, які поставив клієнт. Іншими словами, моєю метою було зробити так, щоб наше рішення працювало. Наприклад, якщо мова йде про деплоймент застосунку, моїм завданням було зробити так, щоб компоненти деплоймент-схеми забирали код із репозиторію, обробляли його і в кінцевому підсумку видавали оновлений код на сервері. Якщо ця схема функціонує ідеально, я, будучи фахівцем виключно з DevOps, вважав, що завдання виконане і проект завершений.
Але на момент релізу застосунку часто у нашого відділу з безпеки або у клієнта виникала низка питань, пов’язаних з безпекою:
- чи відповідає рішення HIPAA compliance (Акт про передачу та захист даних установ охорони здоров’я) чи PCI compliance (пов’язано з оплатою в інтернеті);
- чи всі порти закриті і т. д.
Якщо є проблеми з безпекою, як би чудово рішення не працювало, запускати його не можна. І таке на практиці трапляється, причому часто.
Наприклад, я знаю випадки, коли розробники не перевірили, чи шифруються логіни і паролі при передачі на сервер. Траплялося й так, що вони могли просто зберігатися в окремому файлі відкритим текстом або в базі даних у незашифрованому вигляді. Тобто можна було зайти на сервер і легко отримати до них доступ. Бували випадки з мобільним застосунком, коли конфіденційні дані користувачів можна було витягнути файловим редактором. Подібні помилки можуть стати приводом для судових позовів, великих штрафів, втрати компанією репутації перед клієнтами та інвесторами.
Недоробки з безпеки також можуть призвести до прямих фінансових втрат. У нас був великий проект, у рамках якого клієнт не затвердив бюджет на security, що в результаті обійшлося йому значно дорожче. Ми розробили всю інфраструктуру, описавши її як код: запускаєш один скрипт, і за кілька хвилин розгортається багато кластерів, все це працює і взаємодіє між собою. Але під час UAT-тестування клієнт (для зручності) відкрив один з портів в інтернет. На роботі самого застосунку це ніяк не відобразилося, однак хакери отримали можливість зламати кластер, який займався обробкою великого обсягу даних, і почати майнити криптовалюту.
Оскільки за замовчуванням було налаштоване автоматичне розширення в разі збільшення навантаження, процесори були загнані по максимуму і інфраструктура розширилася, досягнувши ліміту хмарних ресурсів. Клієнт помітив це через 2 дні, коли прийшов рахунок на 10+ тис. доларів за використання хмарної інфраструктури.
Чи несе відповідальність за подібні кейси DevOps в чистому вигляді? Найімовірніше ні, оскільки у нього немає компетенцій, які б дозволили якісно проаналізувати роботу програми з точки зору безпеки, знайти всі недоліки і закрити їх. Чи є сенс кожен готовий проект віддавати на опрацювання інженерам з безпеки? Теж, імовірно, ні. Зупинімося на цих питаннях, перш ніж переходити до DevSecOps. Розберемося, у яких випадках зв’язка DevOps-Engineer + Security Engineer — необхідна, а коли — неефективна.
Чому дует DevOps + Security — це не завжди ефективно? І в яких випадках без інженера з безпеки не обійтися?
Передусім залучення Security Engineer збільшує тривалість роботи над проектом. Їм потрібно в середньому кілька тижнів, щоб розібратися, як побудована інфраструктура застосунку, як компоненти взаємодіють між собою, і знайти прогалини в безпеці. Це збільшує бюджет проекту, до чого клієнт зазвичай не готовий.
Основне завдання Security Engineer — закрити конкретні прогалини. Проектування програми та супровід процесу розробки (в який часто клієнт вносить правки і дає нові вхідні дані) — не його компетенція і сфера відповідальності.
Виходячи з цього, Security Engineer залучаються вже після завершення роботи над застосунком на момент penetration testing, коли є необхідність додатково перевірити вразливість через занадто складну інфраструктуру і підвищені ризики. Або якщо з самого початку не була врахована необхідність гарантування безпеки. Також вони потрібні, якщо на проекті немає DevOps, який розбирається в питаннях безпеки.
Механіка така: якщо проектна команда сумнівається в безпеці розробленого рішення, це обговорюється з клієнтом. Якщо у клієнта немає внутрішніх ресурсів для проведення security assessment, погоджуємо з ним окремий бюджет на залучення Security Team. Для скорочення часу, необхідного Security Engineer, щоб розібратися в тонкощах роботи рішення, вони проводять сесії з розробниками, які розповідають, як працює додаток, показують взаємозв’язку між компонентами. Після цього Security Engineers можуть якісно протестувати як веб-, так і мобільний додаток (перевіряють окремо під кожну версію платформи iOS і Android), для виявлення OWASP TOP-10 вразливостей:
- Injection.
- Broken Authentication.
- Sensitive data exposure.
- XML External Entities (XXE).
- Broken Access control.
- Security misconfigurations.
- Cross-Site Scripting (XSS).
- Insecure Deserialization.
- Using Components with known vulnerabilities.
- Insufficient logging and monitoring.
Нещодавно SoftServe придбала програму, яка аналізує повний спектр вразливостей: застосунки, бази даних, зв’язку між компонентами і т. д. Грубо кажучи, програма нацьковує різні вразливості на компоненти програми і аналізує їхню реакцію. Якщо програма виявила пробіли в безпеці, Security Team спільно з розробниками працюють над тим, щоб їх закрити.
Застосунки, в яких ми сумніваємося, перевіряємо через цей сервіс. На жаль, цей процес займає багато часу, тому прогнати через нього кілька тисяч проектів, які знаходяться зараз у роботі, не виходить. До того ж для клієнта це додаткова стаття витрат, до якої він не завжди готовий. Тому ми її використовуємо тільки для складних проектів, коли залучені сотні серверів і мікросервісів, — для компаній, які займаються нафтогазовидобувною промисловістю, банківськими послугами, охороною здоров’я.
На мій погляд, перевірка рішення на стадії розробки неефективна через додаткові витрати часу і фінансових ресурсів. Такий підхід до проекту можливий, лише якщо заздалегідь обговорити з клієнтом бюджет. На початку немає сенсу витрачати час і, наприклад, закривати порти доступу. Адже в процесі розробки часто від клієнта надходять нові запити — додати якусь фічу або ще щось. І кожен раз необхідно переглядати, як ці зміни будуть впливати на безпеку. З цього випливає те, що на початку роботи у нас немає чіткого розуміння, як застосунок буде побудовано, відповідно Security Team не може правильно вибудувати безпеку. Уже ближче до релізу проекту потрібно розуміти всі слабкі місця і знати, що з ними робити.
Більше того, з моєї практики, можу сказати, що сам клієнт рідко замислюється про безпеку, поки не зіткнеться з якоюсь ситуацією.
Вирішенням цієї проблеми є розвиток компетенції DevSecOps, що нині є світовим трендом.
SecDevOps vs. DevSecOps
SecDevOps-підхід передбачає імплементацію елементів безпеки під час розробки проекту. З моєї точки зору, це неефективно з тієї ж причини, чому немає сенсу залучати Security Team: наприкінці може вийти зовсім не те, що планувалося спочатку.
Звичайно, бувають проекти, коли все очевидно з самого початку і ще до старту роботи можна продумати безпеку. Наприклад, це розробка програми, коли у тебе є сервер, база даних, користувачі, які логіняться на веб-застосунку, і цей застосунок працює з цією базою даних. Тобі з самого початку всі дані відомі, тобто клієнт впевнений, що нічого нового додаватися не буде. У таких ситуаціях необхідний просто Continuous Integration & Continuous Delivery процес, щоб запушити код в GitHub або будь-яку іншу Cloud Management System, і він оновить сервер.
Це стандартні рішення, у яких немає жодних підводних каменів. Тут розумієш, що буде шифрування між застосунком і базою даних, а також по SSL сертифікату. Сервери приховуємо в приватній мережі, Loadbalancer відкриваємо у світ, тому що він, по суті, тільки розподіляє навантаження між серверами, які обмінюються даними з єдиною базою. Тут нічого нового не придумаєш.
Ще буває так, що під час розробки додається нова фіча, і ти розумієш, що початковий вибір компонента безпеки покриває цю фічу. Щоб цього досягти спочатку, потрібно розуміти, що, наприклад, медичні компанії пов’язані з безпечним зберіганням індивідуальних даних пацієнтів. Але таке буває дуже рідко, тому що ми стикаємося з дуже незвичайними рішеннями і запитами від клієнтів.
Якось ми розробляли веб-застосунок, який запускався на великому кластері. Клієнт, через відсутність документації, сам не до кінця розумів, як саме воно працювало. Там використовувалися бази даних, Big Data cluster і код, який це все запускав і розгортав. При чому клієнт надав початковий код. Протягом декількох тижнів ми розбиралися з кодом і намагалися відтворити робочий застосунок, паралельно прибираючи баги в коді у вигляді прописаних паролів до бази даних у явному вигляді.
За кілька тижнів ми зіткнулися з блокером, і нічого не залишалося, крім як прийти до клієнта і сказати, що запустити код неможливо, що б ми не робили. Виявилося, що нам просто не повідомили, що потрібен ще додатковий компонент, щоб все запрацювало — analytics engine for big data processing. У таких ситуаціях ти розумієш, що витратив час даремно. Тепер потрібно думати, як його інтегрувати. При чому сам клієнт не знає, як це зробити, оскільки код писало двоє людей, які пішли з компанії, і проконсультуватися з ними можливості немає. Тут явно проблема в самій розробці програми, тобто в DevOps.
А уявіть, якщо б на кожному етапі потрібно було підключати Security Engineer? Наприклад, він скаже, що той же Big Data cluster або analytics engine for big data processing не покривається рішенням, яке обрали спочатку. І тут потрібно думати, яким додатковим компонентом можна закрити цю прогалину, щоб робота інфраструктури була в безпеці. Ви можете спочатку вибрати неправильний інструмент для гарантування безпеки, що може призвести до додаткових проблем і ускладнення інфраструктури.
DevSecOps-підхід, при якому фіналізується архітектура, а вже після цього закриваються прогалини в безпеці, є найбільш раціональним і з точки зору розподілу ресурсів, і для гарантування безпеки готового застосунку.
Як працює DevSecOps
Я з DevOps перекваліфікувався в DevSecOps. Для цього почав відвідувати внутрішні тренінги, які організовують наші Security Engineers, вивчати додаткову інформацію, щоб розуміти, які бувають уразливості, як вони можуть закриватися, на що потрібно звертати увагу, якщо клієнт працює з медичними даними або платіжними картками.
На етапі pre-sale в розмові з клієнтами я вловлюю моменти, які можуть бути не очевидні Architecture, Sales Manager, Project Manager.
На етапі розробки і деплоймента проекту я працюю як стандартний DevOps Engineer, аналізуючи зв’язки між компонентами. Далі, у залежності від масштабів проекту, я або сам імплементую рішення, необхідні для гарантування повної безпеки проекту, або працюю у зв’язці з Security Team. Розглянемо на прикладах.
До нас прийшов клієнт із запитом перенести форум, розроблений сторонньою компанією (який погано працював і зберігався в дата-центрі розробника) у приватний хмарний акаунт клієнта, по можливості, налагодивши роботу форуму для роботи з великою кількістю відвідувачів. Для виконання першої частини завдання я отримав доступ до сховища з кодом і до хмарного аккаунту клієнта, де будуть розгорнуті сервери. Команда клієнта розповіла, як запускається і функціонує застосунок у цілому. Після цього я запустив збірку коду локально, щоб перевірити, чи дійсно він робочий і чи може запуститися на будь-якому іншому сервері.
Успішно запустивши форум локально, я приступив до автоматизації. Це свого роду головоломка. Потрібно продумати, як зв’язати репозиторій зі сховищем, куди буде складатися код, тобто придумати схему, як буде запускатися процес оновлення сервера під час внесення змін до коду.
Коли логічний ланцюжок був побудований і процес автоматизації налагоджений, до проекту долучилися тестувальники, щоб перевірити роботу програми під навантаженням і визначити, чи вистачає обсягу пам’яті, чи справляються процесори, і в разі нестачі ресурсів розширити сервер до необхідних показників. Коли вдалося налагодити роботу форуму і сформувати вимоги для серверів у хмарі, можна було приступати до міграції в хмарний клієнтський акаунт. Краще, якщо це робить той же фахівець, який проектував рішення, оскільки він вже добре його знає.
У цьому випадку не було необхідності вивчати, яким чином була гарантована безпека старого рішення, оскільки я розробив повністю нову схему. Коли я це роблю сам, крок за кроком, згодом можна легко проаналізувати безпеку кінцевого продукту, виявити ризики і закрити їх. У цьому конкретному випадку я розумів, що найголовніше — закрити доступ до системи і усунути ризики злому. Тому залишив можливість підключатися до серверів тільки з офісу клієнта і офісу SoftServe. Департамент з безпеки клієнта перевірив нове рішення на вразливості і слабких місць не виявив.
Цей проект я зміг зробити повністю самостійно, оскільки інфраструктура складалася лише з декількох серверів. Якщо розробляється система, яка складається з безлічі серверів, баз даних, що взаємодіють між собою, необхідна підтримка Security Team. По-перше, в однієї людини це займе дуже багато часу, по-друге, DevSecOps-Engineer не працює щодня з програмами для тестування системи. У таких випадках моя роль — допомогти команді з безпеки зробити роботу швидше і простіше, пояснивши їм структуру програми та взаємозв’язок між її компонентами. Це займає близько 3 днів, після чого за кілька тижнів вони зможуть якісно її протестувати. Якщо вони працюють самостійно з незнайомим проектом, це займає більше місяця.
Висновки
Можу підсумувати, що потрібно думати про безпеку в першу чергу, але застосовувати правила безпеки лише на готову інфраструктуру, коли зрозуміло і наочно видно, як компоненти взаємодіють між собою, а інфраструктура вже не буде змінюватися і перероблятися під нові запити клієнта.
