Банк аутсорсить свої проекти багатьом підрядникам. "Зовнішники" пишуть код, потім передають результати в не зовсім зручному вигляді. Саме процес виглядав так: вони передавали проект, який пройшов функціональні тести у них, а потім тестувався вже всередині банківського периметра на інтеграцію, навантаження тощо. Часто виявлялося, що випробування фейляться. Тоді все йшло назад зовнішньому розробнику. Як ви можете здогадатися, це означало значні терміни виправлення помилок.
Банк вирішив, що можна і потрібно перетягнути весь пайплайн до себе під крильце від коммітів до випуску. Щоб все було однаково і під контролем команд, які відповідають за продукт у банку. Тобто ніби зовнішній підрядник просто працював десь у сусідній кімнаті офісу. На корпоративному стеку. Це традиційний девопс.
Звідки виникло Sec? Безпека банку виставила високі вимоги до того, як зовнішній підрядник може працювати в мережевому сегменті, який доступ, як і хто працює з кодом. Просто ІБ ще не знала, що коли підрядники працюють зовні, мало які банківські стандарти дотримуються. А тут за пару днів треба їх почати дотримуватися всіх.
Одне просте одкровення, що підрядник має повний доступ до коду продукту, вже перевернув їхній світ.
У цей момент і розпочалася історія DevSecOps, про яку я хочу розповісти.
Які банк зробив практичні висновки із цієї ситуації
Було багато суперечок про те, що все робиться у сфері не так. Розробники говорили, що безпека зайнята лише спробами перешкодити розробці, і вони, як вахтери, намагаються забороняти, не думаючи. У свою чергу, безпечники вагалися між тим, щоб вибрати між точками зору: «розробники створюють уразливості в нашому контурі» і «розробники не створюють уразливості, а самі ними є». Суперечка тривала б довго, якби не нові вимоги ринку і поява парадигми DevSecOps. Вдалося пояснити, що ця автоматизація процесів з урахуванням вимог ІБ «з коробки» допоможе всім залишитися задоволеними. У сенсі, що правила записуються відразу і не змінюються по ходу гри (ІБ не заборонятиме щось несподівано), а розробники тримають в курсі ІБ про те, що відбувається (ІБ не стикається з чимось раптово). За кінцеву безпеку відповідає ще й кожна команда, а не абстрактні старші брати.
- Якщо зовнішні співробітники вже мають доступ до коду і низки внутрішніх систем, напевно, можна прибрати з документів вимогу «розробка повинна вестися повністю на інфраструктурі банку».
- З іншого боку, треба посилити контроль за тим, що відбувається.
- Компромісом стало створення крос-функціональних команд, коли працівники тісно працюють із зовнішніми людьми. І тут потрібно зробити те щоб команда працювала на інструментах на серверах банку. Від початку до кінця.
Тобто підрядників можна пускати, але потрібно зробити окремі сегменти. Щоб вони не притягли зовні якусь заразу до інфраструктури банку і щоб не бачили більше, ніж потрібно. Та й щоб їхні дії логувалися. DLP для захисту від «сливів», все це прикладалося.
У принципі, до цього приходять усі банки рано чи пізно. Тут пішли второваною доріжкою та погодили вимоги до таких середовищ, де працюють «зовнішники». Там з'явився максимальний набір засобів контролю доступу, засобів перевірок уразливостей, антивірусний аналіз на контурах, зборках та тестах. Це назвали DevSecOps.
Раптово з'ясувалося, що якщо раніше DevSecOps банківська безпека не мала контролю над тим, що відбувається на стороні розробника, то в новій парадигмі безпека контролюється так само, як звичайні події на інфраструктурі. Тільки тепер є алерти на збірках, контроль бібліотек тощо.
Залишилося лише перевести команди на нову модель. Та й створити інфраструктуру. Але це вже дрібниці, це як намалювати сову. Власне ми допомагали з інфраструктурою, а в цей час змінювалися процеси розробки.
Що змінювалося
Вирішили впроваджувати невеликими кроками, бо розуміли, що багато процесів розваляться, а багато «зовнішників» можуть не витримати нових умов праці під наглядом усіх бажаючих.
Спочатку створили крос-функціональні команди та навчилися організовувати проекти з урахуванням нових вимог. У сенсі організаційно обговорили якісь процеси. Вийшла схема пайплайну збірки з усіма відповідальними.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, Junit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Тест: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Centre, MF UFT, Ataсcama.
- Презентація (Звітність, комунікація): Grafana, Kibana, Jira, Confluence, RocketChat.
- операції (супровід, управління): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Вибрали стек:
- База знань - "Atlassian Confluence";
- Таск-трекер - "Atlassian Jira";
- Репозитарій артефактів - Nexus;
- Система безперервної інтеграції - "Gitlab CI";
- Система безперервного аналізу - "SonarQube";
- Система аналізу безпеки додатків - "Micro Focus Fortify";
- Система комунікацій - "GitLab Mattermost";
- Система управління конфігураціями - "Ansible";
- Система моніторингу - "ELK", "TICK Stack" ("InfluxData").
Стали створювати команду, яка буде готова перетягнути підрядників усередину. Настало усвідомлення, що є кілька важливих речей:
- Все має бути уніфіковано хоч би на передачі коду. Бо скільки було підрядників — стільки різних процесів розробки з особливостями. Треба було вкласти всіх приблизно один, але з опціями.
- Підрядників багато і ручне створення інфраструктури не підходить. Будь-яке нове завдання має запускатися дуже швидко — тобто інстанс має розгортатися майже миттєво, щоб розробники отримували набори рішень для керування своїм конвеєром.
Щоб зробити перший крок, треба було зрозуміти, що взагалі робиться. А ми мали визначити, як до цього перейти. Почали ми з того, що допомогли намалювати архітектуру цільового рішення як в інфраструктурі, так і з автоматизації CI/CD. Потім ми почали збирати цей конвеєр. Потрібна була одна інфраструктура, однакова для всіх, де б бігали ті самі конвеєри. Ми пропонували варіанти з розрахунками, банк думав, потім ухвалював рішення, що і на яких коштах буде побудовано.
Далі створення контуру - встановлення ПЗ, налаштування. Розробка скриптів з деплою інфраструктури та з управління. Далі вже перехід на підтримку конвеєра.
Вирішили обкатати все на пілоті. Що цікаво, під час пілотування певний стек з'явився у банку вперше. Серед іншого на обсяг пілота було запропоновано вітчизняний вендор одного з рішень для якнайшвидшого запуску. Безпека знайомилася з ним під час пілотування, і це залишило незабутні враження. Коли вирішили перейти, на щастя, інфраструктурний шар замінили на нутаніксове рішення, яке вже крутилося до цього банку. До того ж воно було для VDI, а ми перевикористовували для інфраструктурних сервісів. На малих обсягах воно не вписувалося в економіку, а на великих стало чудовим середовищем для розробки та тестування.
Решта стек більш-менш знайома всім. Засоби автоматизації у частині Ansible використовувалися, із нею щільно працювали безопасники. Атласинівський стек використовувався банком і до проекту. Засоби безпеки Fortinet — вони були запропоновані самими безпеками. Фрейм для тестування створювався банком, жодних питань. Запитання викликала система репозиторіїв, довелося звикати.
Підрядникам дали новий стек. Дали час на переписування під GitlabCI і на те, щоб мігрувати Jira в сегмент банку і так далі.
За кроками
Етап 1. Спочатку використовували рішення вітчизняного вендора, продукт було скомутовано в новий створений мережевий сегмент DSO. Платформу обрали за термінами постачання, гнучкості масштабування та можливості повної автоматизації. Провели тести:
- Можливість гнучкого та повністю автоматизованого управління інфраструктурою платформи віртуалізації (мережа, дискова підсистема, підсистема обчислювальних ресурсів).
- Автоматизація керування життєвим циклом віртуальних машин (шаблонізація, снапшоти, резервні копії).
Після встановлення та базової конфігурації платформи вона була використана як точка розміщення підсистем другого етапу (інструменти DSO, контури розробки роздрібних систем). Було створено необхідні набори пайплайнів - створення, видалення, зміна, резервне копіювання віртуальних машин. Дані пайплайни використовували як перший етап процесу деплою.
Результат — надане обладнання не відповідає вимогам банку щодо продуктивності та відмовостійкості. ДІТ банку ухвалив рішення про створення комплексу на базі ПАК Nutanix.
етап 2. Взяли стек, який був визначений, і для всіх підсистем написали скрипти автоматизованої установки та постконфігурації, щоб з пілота до цільового контуру все перенеслося якнайшвидше. Усі системи були розгорнуті у стійкій від відмови (де ця можливість не обмежується ліцензійними політиками вендора), підключені до підсистем збору метрик і подій. ІБ проаналізувала відповідність своїм вимогам та дала зелене світло.
етап 3. Міграція всіх підсистем та їх налаштувань на новий ПАК. Скрипти автоматизації інфраструктури були переписані, і перенесення підсистем DSO було виконано повністю автоматизованому режимі. Контури розробки ІВ були перетворені пайплайн команд розробки.
Етап 4. Автоматизація установки прикладного ПЗ. Ці завдання ставили тимліди нових команд.
Етап 5. Експлуатація.
Віддалений доступ
Команди розробки просили максимальної гнучкості в роботі з контуром, і вимога віддаленого доступу з особистих ноутбуків була поставлена на початку проекту. У банку вже був доступ, але він не підходив для розробників. Справа в тому, що схема використовувала підключення користувача до захищеного VDI. Це підходило для тих, кому на робочому місці було достатньо пошти та пакету офісу. Розробникам були б потрібні важкі клієнти, високопродуктивні, з великою кількістю ресурсів. І звичайно, вони повинні були бути статичними, оскільки втрата сесії для тих, хто працює з VStudio (наприклад) або іншим SDK, неприпустима. Організація великої кількості товстих статичних VDI для всіх команд розробки дуже дорожчала існуюче рішення VDI.
Вирішили опрацьовувати віддалений доступ безпосередньо до ресурсів сегмента розробки. Jira, Wiki, Gitlab, Nexus, стенди складання та тестування, віртуальна інфраструктура. Безпеки виставили вимоги, що доступ може бути організований лише за умови дотримання наступного:
- З використанням технологій, що вже є в банку.
- Інфраструктура не повинна використовувати існуючі домен-контролери, які зберігають записи про продуктивні облікові об'єкти.
- Доступ повинен бути обмежений лише тими ресурсами, які потрібні певній команді (щоб команда одного продукту не могла отримати доступ до ресурсів іншої команди).
- Максимальний контроль за RBAC'ом у системах.
У результаті було створено окремий домен даного сегмента. У цьому домені були всі ресурси сегмента розробки як облікові дані користувачів, так і інфраструктура. Управління життєвим циклом записів у цьому домені відбувається з використанням існуючого в банку IdM.
Безпосередньо віддалений доступ було організовано з урахуванням існуючого устаткування банку. Управління доступами було розведено за групами AD, яким відповідали правила на контекстах (одна продуктова група = одна група правил).
Керування шаблонами VM
Швидкість створення контуру складання та тестування — один із основних KPI, поставлених керівником блоку розробки, адже швидкість підготовки середовища безпосередньо впливає на загальний час виконання пайплайну. Розглядалися два варіанти підготовки базових образів VM. Перший - мінімальні розміри образу, дефолтні для всіх продуктів систем, максимальна відповідність політикам банку за налаштуваннями. Другий - базовий образ, що містить у собі встановлене великовагове ПОППО, час установки якого могло сильно впливати на швидкість виконання пайплайну.
Вимоги інфраструктури та безпеки також враховувалися під час розробки — підтримка образів в актуальному стані (патчі тощо), інтеграція з SIEM, налаштування безпеки за прийнятими у банку стандартами.
У результаті було прийнято рішення використати мінімальні образи з метою мінімізації витрат на підтримку в актуальному стані. Набагато простіше оновити базову ОС, ніж ставити патчі в кожний образ нових версій ПОППО.
За результатами було сформовано список з мінімально необхідного набору операційних систем, чиє оновлення проводиться командою експлуатації, а за оновлення ПОППО повністю відповідають скрипти з пайплайну, а при необхідності змінити версію ПЗ — достатньо в пайплайн передати потрібний тег. Так, це вимагає від devops'a продуктової команди складніших сценаріїв деплою, але сильно скорочує час експлуатації на підтримку базових образів, яким могло б звалитися на обслуговування більше сотні базових образів VM.
Доступ в Інтернет
Ще одним каменем спотикання з банківською безпекою став доступ із середовища розробки до інтернет-ресурсів. Причому цей доступ можна розбити на дві категорії:
- Інфраструктурний доступ.
- Доступ до розробників.
Інфраструктурний доступ був організований шляхом проксування зовнішніх репозиторіїв Nexus'ом. Тобто, прямого доступу з віртуальних машин — не передбачалося. Це дозволило вийти на компроміс із ІБ, яка була категорично проти надання будь-якого доступу до зовнішнього світу із сегменту розробки.
Доступ розробникам до інтернету був потрібний з цілком зрозумілих причин (stackoverflow). І хоча у всіх команд, як було сказано вище, був віддалений доступ до контуру, не завжди зручно, коли з робочого місця розробника в банку в IDE ти не можеш зробити ctrl+v.
З ІБ було досягнуто домовленості, що спочатку, на етапі тестування, доступ буде надано через банківський проксі на базі white-list. Після закінчення проекту доступ переведуть на black-list. Були підготовлені величезні таблиці доступів, у яких було вказано основні ресурси та репозиторії, яких потребував доступ на старті проекту. Узгодження даних доступів займало чималий час, що дозволяло наполягати на максимально швидкому переході на блек-листи.
Результати
Проект закінчився трохи менше року тому. Хоч як це дивно, але всі підрядники вчасно перейшли на новий стек і ніхто не пішов через нову автоматизацію. ІБ не поспішає ділитися позитивними відгуками, але й не скаржиться, з чого можна дійти невтішного висновку, що їм подобається. Конфлікти стихли, тому що ІБ знову відчуває контроль, але при цьому не заважає процесам розробки. На команди потрапило більше відповідальності, і загалом ставлення до ІБ стало краще. Банк розумів, що перехід на DevSecOps майже неминучий, і зробив це, як на мене, найбільш м'яко і правильно.
Олександр Шубін, системний архітектор.
Джерело: habr.com