Банк аутсорсит свои проекты многим подрядчикам. «Внешники» пишут код, потом передают результаты в не совсем удобном виде. Конкретно процесс выглядел так: они передавали проект, который прошёл функциональные тесты у них, а затем тестировался уже внутри банковского периметра на интеграцию, нагрузку и так далее. Часто обнаруживалось, что тесты фейлятся. Тогда всё уходило обратно внешнему разработчику. Как вы можете догадаться, это означало большие сроки исправления ошибок.
Banca a decis că este posibil și necesar să tragă întreaga conductă sub aripa sa, de la commit până la eliberare. Pentru ca totul să fie uniform și sub controlul echipelor responsabile cu produsul din bancă. Adică, ca și cum contractorul extern lucra pur și simplu undeva în camera alăturată a biroului. Pe stiva corporativă. Acesta este un devops obișnuit.
Откуда появилось Sec? Безопасность банка выставила высокие требования к тому, как внешний подрядчик может работать в сетевом сегменте, какой у кого доступ, как и кто работает с кодом. Просто ИБ ещё не знала, что когда подрядчики работают снаружи, мало какие банковские стандарты соблюдаются. А тут за пару дней надо их начать соблюдать всем.
Simpla revelație că antreprenorul avea acces deplin la codul produsului le-a dat deja lumea peste cap.
În acest moment a început povestea DevSecOps, despre care vreau să vă povestesc.
Ce concluzii practice a tras banca din această situație?
Au existat multe controverse cu privire la faptul că totul este făcut în mod greșit. Dezvoltatorii au spus că securitatea este ocupată doar să încerce să interfereze cu dezvoltarea, iar ei, ca paznicii, încearcă să interzică fără să se gândească. La rândul lor, specialiștii în securitate au ezitat între a alege între punctele de vedere: „dezvoltatorii creează vulnerabilități în circuitul nostru” și „dezvoltatorii nu creează vulnerabilități, ci sunt ei înșiși”. Disputa ar fi continuat o lungă perioadă de timp dacă nu pentru noile cerințe ale pieței și apariția paradigmei DevSecOps. A fost posibil să explicăm că tocmai această automatizare a proceselor ținând cont de cerințele de securitate a informațiilor „din cutie” îi va ajuta pe toți să rămână fericiți. În sensul că regulile sunt notate imediat și nu se schimbă în timpul jocului (securitatea informațiilor nu va interzice ceva pe neașteptate), iar dezvoltatorii țin securitatea informațiilor la curent cu tot ce se întâmplă (securitatea informațiilor nu întâlnește ceva brusc) . Fiecare echipă este, de asemenea, responsabilă pentru siguranța supremă, și nu niște frați mai mari abstracti.
- Întrucât angajații externi au deja acces la cod și la o serie de sisteme interne, probabil că este posibil să se elimine din documente cerința „dezvoltarea trebuie efectuată în întregime pe infrastructura băncii”.
- Pe de altă parte, trebuie să întărim controlul asupra a ceea ce se întâmplă.
- Compromisul a fost crearea de echipe interfuncționale, în care angajații lucrează îndeaproape cu oameni externi. În acest caz, trebuie să vă asigurați că echipa lucrează cu instrumente de pe serverele băncii. De la început până la sfârșit.
Adică, antreprenorilor li se poate permite, dar trebuie să li se dea segmente separate. Ca să nu aducă vreun fel de infecție din exterior în infrastructura băncii și să nu vadă mai mult decât este necesar. Ei bine, astfel încât acțiunile lor să fie înregistrate. DLP pentru protecție împotriva scurgerilor, toate acestea au fost incluse.
În principiu, toate băncile ajung la asta mai devreme sau mai târziu. Aici am mers pe drumurile bătute și am convenit asupra cerințelor pentru astfel de medii în care lucrează „externii”. A apărut o gamă maximă de instrumente de control al accesului, instrumente de verificare a vulnerabilităților, analiză antivirus pe circuite, ansambluri și teste. Acesta se numește DevSecOps.
Dintr-o dată a devenit clar că, dacă înainte de DevSecOps securitatea bancară nu avea control asupra a ceea ce se întâmplă din partea dezvoltatorului, atunci în noua paradigmă securitatea este controlată în același mod ca evenimentele obișnuite din infrastructură. Abia acum există alerte privind ansamblurile, controlul bibliotecilor și așa mai departe.
Осталось только перевести команды на новую модель. Ну и создать инфраструктуру. Но это уже мелочи, это как нарисовать сову. Собственно, мы помогали с инфраструктурой, а в это время менялись процессы разработки.
Что менялось
Am decis să o implementăm în pași mici, pentru că am înțeles că multe procese se vor destrama, iar mulți „externi” s-ar putea să nu poată rezista noilor condiții de muncă sub supravegherea tuturor.
În primul rând, am creat echipe interfuncționale și am învățat să organizăm proiecte ținând cont de noile cerințe. În sensul organizațional am discutat ce procese. Rezultatul a fost o diagramă a conductei de asamblare cu toți cei responsabili.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- De încercare: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- Despre Institutul Bruno Comby (reportare, comunicare): Grafana, Kibana, Jira, Confluence, RocketChat.
- Operațiuni (întreținere, management): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Stiva selectată:
- Baza de cunoștințe - Atlassian Confluence;
- Task tracker - Atlassian Jira;
- Depozitul de artefacte - „Nexus”;
- Sistem de integrare continuă - „Gitlab CI”;
- Sistem de analiză continuă - „SonarQube”;
- Sistem de analiză a securității aplicației - „Micro Focus Fortify”;
- Sistem de comunicare - „GitLab Mattermost”;
- Sistem de management al configurației - „Ansible”;
- Sistem de monitorizare - „ELK”, „TICK Stack” (“InfluxData”).
Au început să creeze o echipă care ar fi gata să tragă antreprenorii înăuntru. Există o conștientizare că există mai multe lucruri importante:
- Totul ar trebui să fie unificat, cel puțin la transmiterea codului. Pentru că au fost atât de mulți contractori cât au fost atât de multe procese de dezvoltare diferite, cu propriile lor particularități. Era necesar să se încadreze pe toată lumea într-unul aproximativ, dar cu opțiuni.
- Există mulți contractori, iar crearea manuală a infrastructurii nu este potrivită. Orice sarcină nouă ar trebui să înceapă foarte repede - adică instanța ar trebui să fie implementată aproape instantaneu, astfel încât dezvoltatorii să aibă un set de soluții pentru a-și gestiona pipeline.
Pentru a face primul pas, a fost necesar să înțelegem ce se face. Și a trebuit să stabilim cum să ajungem acolo. Am început prin a ajuta la desenarea arhitecturii soluției țintă atât în infrastructură, cât și în automatizarea CI/CD. Apoi am început să asamblam acest transportor. Aveam nevoie de o singură infrastructură, aceeași pentru toată lumea, unde să circule aceleași benzi transportoare. Am oferit opțiuni cu calcule, s-a gândit banca, apoi a decis ce se va construi și cu ce fonduri.
Urmează crearea circuitului - instalarea software-ului, configurarea. Dezvoltarea de scripturi pentru implementarea și managementul infrastructurii. Urmează trecerea la suportul transportoarelor.
Am decis să testăm totul pe pilot. Interesant este că în timpul pilotajului a apărut pentru prima dată în bancă o anumită stivă. Printre altele, a fost oferit un furnizor intern al uneia dintre soluții pentru scopul pilotului pentru o lansare rapidă. Securitatea l-a cunoscut în timp ce pilota el și a lăsat o impresie de neuitat. Când am decis să trecem, din fericire, stratul de infrastructură a fost înlocuit cu o soluție Nutanix, care era deja în bancă înainte. Mai mult decât atât, înainte era pentru VDI, dar l-am refolosit pentru servicii de infrastructură. La volume mici nu s-a încadrat în economie, dar la volume mari a devenit un mediu excelent pentru dezvoltare și testare.
Restul stivei este mai mult sau mai puțin familiar tuturor. Au fost folosite instrumente de automatizare din Ansible, iar specialiștii în securitate au lucrat îndeaproape cu acestea. Stiva Atlassin a fost folosită de bancă înainte de proiect. Instrumente de securitate Fortinet - a fost propus chiar de oamenii de securitate. Cadrul de testare a fost creat de bancă, fără întrebări. Sistemul de depozit a ridicat întrebări; a trebuit să mă obișnuiesc cu el.
Antreprenorilor li s-a dat o nouă stivă. Ne-au dat timp să-l rescriem pentru GitlabCI și să migram Jira pe segmentul bancar și așa mai departe.
pas cu pas
Pasul 1. În primul rând, am folosit o soluție de la un furnizor local, produsul a fost conectat la un nou segment de rețea DSO creat. Platforma a fost aleasă pentru timpul de livrare, flexibilitatea de scalare și posibilitatea de automatizare completă. Teste efectuate:
- Posibilitatea de gestionare flexibilă și complet automatizată a infrastructurii platformei de virtualizare (rețea, subsistem disc, subsistem resurse de calcul).
- Автоматизация управления жизненным циклом виртуальных машин (шаблонизирование, снапшоты, резервные копии).
După instalarea și configurarea de bază a platformei, aceasta a fost folosită ca punct de amplasare a subsistemelor din etapa a doua (instrumente DSO, schițe de dezvoltare a sistemelor de retail). Au fost create seturile necesare de conducte - crearea, ștergerea, modificarea, copierea de rezervă a mașinilor virtuale. Aceste conducte au fost utilizate ca primă etapă a procesului de implementare.
Результат — предоставленное оборудование не отвечает требованиям банка по производительности и отказоустойчивости. ДИТ банка принял решение о создании комплекса на базе ПАК Nutanix.
Etapa 2. Am luat stiva care a fost definită și am scris scripturi automate de instalare și post-configurare pentru toate subsistemele, astfel încât totul să fie transferat de la pilot la circuitul țintă cât mai repede posibil. Toate sistemele au fost implementate într-o configurație tolerantă la erori (în cazul în care această capacitate nu este limitată de politicile de licențiere ale furnizorului) și conectate la subsisteme de metrici și de colectare a evenimentelor. IB a analizat conformitatea cu cerințele sale și a dat undă verde.
Etapa 3. Migrarea tuturor subsistemelor și a setărilor acestora la noul PAC. Scripturile de automatizare a infrastructurii au fost rescrise, iar migrarea subsistemelor DSO a fost finalizată într-un mod complet automatizat. Contururile dezvoltării IP au fost recreate de conductele echipelor de dezvoltare.
Pasul 4. Автоматизация установки прикладного ПО. Эти задачи ставили тимлиды новых команд.
Pasul 5. Exploatare.
Acces de la distanță
Echipele de dezvoltare au cerut flexibilitate maximă în lucrul cu circuitul, iar cerința de acces la distanță de pe laptopuri personale a fost ridicată chiar la începutul proiectului. Banca avea deja acces la distanță, dar nu era potrivită pentru dezvoltatori. Faptul este că schema a folosit conexiunea utilizatorului la un VDI protejat. Acest lucru era potrivit pentru cei care aveau nevoie doar de corespondență și de un pachet de birou la locul lor de muncă. Dezvoltatorii ar avea nevoie de clienți grei, de înaltă performanță, cu multe resurse. Și, desigur, trebuiau să fie statice, deoarece pierderea sesiunii de utilizator pentru cei care lucrează cu VStudio (de exemplu) sau alt SDK este inacceptabilă. Organizarea unui număr mare de VDI-uri static groase pentru toate echipele de dezvoltare a crescut considerabil costul soluției VDI existente.
Am decis să lucrăm la accesul de la distanță direct la resursele segmentului de dezvoltare. Jira, Wiki, Gitlab, Nexus, bancuri de construire și testare, infrastructură virtuală. Agentii de pază au cerut ca accesul să fie asigurat numai în condițiile următoare:
- Folosind tehnologiile deja disponibile în bancă.
- Инфраструктура не должна использовать существующие домен-контроллеры, которые хранят записи о продуктивных учёткахобъектах.
- Accesul ar trebui să fie limitat doar la acele resurse solicitate de o anumită echipă (astfel încât o echipă de produs să nu poată accesa resursele altei echipe).
- Control maxim asupra RBAC în sisteme.
Ca urmare, a fost creat un domeniu separat pentru acest segment. Acest domeniu a găzduit toate resursele segmentului de dezvoltare, atât acreditările de utilizator, cât și infrastructura. Ciclul de viață al înregistrărilor din acest domeniu este gestionat folosind IdM-ul existent în bancă.
Accesul direct de la distanță a fost organizat pe baza echipamentelor existente ale băncii. Controlul accesului a fost împărțit în grupuri AD, cărora le corespundeau regulile privind contextele (un grup de produse = un grup de reguli).
Managementul șabloanelor VM
Viteza creării unei bucle de asamblare și testare este unul dintre principalii KPI-uri stabilite de șeful unității de dezvoltare, deoarece viteza de pregătire a mediului afectează în mod direct timpul general de execuție al conductei. Au fost luate în considerare două opțiuni pentru pregătirea imaginilor VM de bază. Prima este dimensiunea minimă a imaginii, implicită pentru toate produsele de sistem, respectarea maximă a politicilor băncii privind setările. A doua este imaginea de bază, care conține instalat un POPPO rezistent, al cărui timp de instalare ar putea influența foarte mult viteza de execuție a conductei.
Pe parcursul dezvoltării s-au luat în considerare și cerințele de infrastructură și securitate - păstrarea imaginilor la zi (patch-uri etc.), integrarea cu SIEM, setările de securitate conform standardelor bancare.
Ca urmare, s-a decis să se utilizeze imagini minime pentru a minimiza costul menținerii lor la zi. Este mult mai ușor să actualizați sistemul de operare de bază decât să corectați fiecare imagine pentru noile versiuni de POPPO.
Pe baza rezultatelor, s-a format o listă cu setul minim necesar de sisteme de operare, a căror actualizare este efectuată de echipa de operațiuni, iar scripturile din conductă sunt în întregime responsabile pentru actualizarea software-ului și, dacă este necesar, pentru modificarea versiunii. a software-ului instalat - doar transferați eticheta necesară în conductă. Da, acest lucru necesită ca echipa de produse devops să aibă scenarii de implementare mai complexe, dar reduce foarte mult timpul de operare necesar pentru a suporta imaginile de bază, care altfel ar putea necesita mai mult de o sută de imagini de bază VM pentru întreținere.
Acces la internet
O altă piatră de poticnire cu securitatea bancară a fost accesul la resursele de internet din mediul de dezvoltare. Mai mult, acest acces poate fi împărțit în două categorii:
- Инфраструктурный доступ.
- Acces pentru dezvoltatori.
Accesul la infrastructură a fost organizat prin proxy depozite externe cu Nexus. Adică, accesul direct de la mașinile virtuale nu a fost oferit. Acest lucru a făcut posibilă ajungerea la un compromis cu securitatea informațiilor, care a fost categoric împotriva furnizării oricărui acces la lumea exterioară din segmentul de dezvoltare.
Dezvoltatorii aveau nevoie de acces la Internet din motive evidente (stackoverflow). Și, deși toate comenzile, așa cum am menționat mai sus, aveau acces de la distanță la circuit, nu este întotdeauna convenabil atunci când nu puteți face ctrl+v de la locul de muncă al dezvoltatorului din bancă în IDE.
S-a ajuns la un acord cu IS că inițial, în faza de testare, accesul va fi asigurat printr-un proxy bancar bazat pe o listă albă. La finalizarea proiectului, accesul va fi transferat pe lista neagră. Au fost pregătite tabele uriașe de acces, care au indicat principalele resurse și depozite la care era necesar accesul la începutul proiectului. Coordonarea acestor accesări a durat o perioadă considerabilă de timp, ceea ce a făcut posibilă insistarea asupra unei tranziții cât mai rapide la listele negre.
Constatări
Proiectul s-a încheiat cu puțin mai puțin de un an în urmă. În mod ciudat, toți contractorii au trecut la noua stivă la timp și nimeni nu a plecat din cauza noii automatizări. IB nu se grăbește să împărtășească feedback pozitiv, dar nici nu se plânge, din care putem concluziona că le place. Conflictele s-au diminuat deoarece securitatea informațiilor se simte din nou în control, dar nu interferează cu procesele de dezvoltare. Echipele au primit mai multă responsabilitate, iar atitudinea generală față de securitatea informațiilor a devenit mai bună. Banca a înțeles că trecerea la DevSecOps era aproape inevitabilă și a făcut-o, după părerea mea, în cel mai blând și corect mod.
Alexander Shubin, arhitect de sistem.
Sursa: www.habr.com