Banka svoje projekte povjerava mnogim izvođačima. “Spoljašnji” pišu kod, a zatim prenose rezultate u ne baš zgodnom obliku. Konkretno, proces je izgledao ovako: predali su projekat koji je sa njima prošao funkcionalne testove, a zatim je testiran unutar bankarskog perimetra za integraciju, opterećenje i tako dalje. Često se otkrivalo da testovi nisu uspjeli. Zatim se sve vratilo vanjskom programeru. Kao što možete pretpostaviti, ovo je značilo dugo vremena za ispravke grešaka.
Banka je odlučila da je moguće i potrebno povući cijeli naftovod pod svoje okrilje, od obaveza do oslobađanja. Tako da sve bude ujednačeno i pod kontrolom timova odgovornih za proizvod u banci. Odnosno, kao da vanjski izvođač jednostavno radi negdje u susjednoj prostoriji kancelarije. Na korporativnoj steci. Ovo je običan devops.
Odakle je Sec došao? Sigurnost banke postavila je visoke zahtjeve kako vanjski izvođač može raditi u segmentu mreže, kakav pristup neko ima, kako i ko radi sa kodom. Samo IB još nije znao da se, kada izvođači rade vani, poštuje nekoliko bankarskih standarda. A onda za par dana svi treba da počnu da ih posmatraju.
Jednostavno otkriće da izvođač ima potpuni pristup šifri proizvoda već je okrenulo njihov svijet naglavačke.
U ovom trenutku je počela priča o DevSecOps-u, o kojoj želim da vam ispričam.
Koje je praktične zaključke banka izvukla iz ove situacije?
Bilo je dosta kontroverzi oko činjenice da se sve radi na pogrešan način. Programeri su rekli da je sigurnost zauzeta samo pokušajima da ometa razvoj, a oni, poput čuvara, pokušavaju zabraniti bez razmišljanja. Zauzvrat, stručnjaci za sigurnost oklevali su između izbora između gledišta: „programeri stvaraju ranjivosti u našem krugu“ i „programeri ne stvaraju ranjivosti, već su oni sami“. Spor bi se nastavio još dugo da nije bilo novih zahtjeva tržišta i pojave DevSecOps paradigme. Bilo je moguće objasniti da će upravo ova automatizacija procesa uzimajući u obzir zahtjeve sigurnosti informacija “iz kutije” pomoći da svi ostanu zadovoljni. U smislu da se pravila zapisuju odmah i da se ne mijenjaju tokom igre (informaciona sigurnost neće nešto neočekivano zabraniti), a programeri informiraju informacijsku sigurnost o svemu što se dešava (informaciona sigurnost ne nailazi na nešto iznenada) . Svaki tim je također odgovoran za krajnju sigurnost, a ne neka apstraktna starija braća.
- Budući da eksterni zaposleni već imaju pristup kodeksu i nizu internih sistema, vjerovatno je iz dokumenata moguće ukloniti zahtjev „razvoj se u potpunosti mora odvijati na infrastrukturi banke“.
- S druge strane, moramo pojačati kontrolu nad onim što se dešava.
- Kompromis je bio stvaranje međufunkcionalnih timova, u kojima zaposleni blisko sarađuju sa vanjskim ljudima. U tom slučaju morate biti sigurni da tim radi na alatima na serverima banke. Od početka do kraja.
Odnosno, izvođačima se može dozvoliti ulazak, ali im treba dati posebne segmente. Da ne unose neku zarazu spolja u infrastrukturu banke i da ne vide više od onoga što je potrebno. Pa, tako da se njihove akcije evidentiraju. DLP za zaštitu od curenja, sve je to uključeno.
U principu, sve banke prije ili kasnije dođu do toga. Ovdje smo krenuli utabanim putem i dogovorili zahtjeve za takva okruženja u kojima rade „spoljašnji“. Pojavio se maksimalni raspon alata za kontrolu pristupa, alata za provjeru ranjivosti, antivirusne analize na krugovima, sklopovima i testovima. Ovo se zove DevSecOps.
Odjednom je postalo jasno da ako prije DevSecOps bankarska sigurnost nije imala kontrolu nad onim što se događa na strani programera, onda se u novoj paradigmi sigurnost kontrolira na isti način kao i obični događaji na infrastrukturi. Tek sada postoje upozorenja o sklopovima, kontroli biblioteka i tako dalje.
Ostaje samo da se timovi prebace na novi model. Pa, stvorite infrastrukturu. Ali to su sitnice, to je kao crtanje sove. Zapravo, pomogli smo infrastrukturom, a u to vrijeme su se mijenjali razvojni procesi.
Šta se promenilo
Odlučili smo da to implementiramo malim koracima, jer smo shvatili da će se mnogi procesi raspasti, a mnogi „spoljaši“ možda neće moći da izdrže nove uslove rada pod nadzorom svih.
Prvo smo stvorili međufunkcionalne timove i naučili organizirati projekte uzimajući u obzir nove zahtjeve. U organizacionom smislu razgovarali smo o kojim procesima. Rezultat je bio dijagram montažnog cjevovoda sa svim odgovornima.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- test: Sonarqube, SoapUI, jMeter, Selen: MF Fortify, Performance Center, MF UFT, Ataccama.
- prezentacija (izvještavanje, komunikacija): Grafana, Kibana, Jira, Confluence, RocketChat.
- operacije (održavanje, upravljanje): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Odabrani stog:
- Baza znanja - Atlassian Confluence;
- Task tracker - Atlassian Jira;
- Repozitorijum artefakata - “Nexus”;
- Sistem kontinuirane integracije - “Gitlab CI”;
- Sistem kontinuirane analize - “SonarQube”;
- Sistem za analizu sigurnosti aplikacija - “Micro Focus Fortify”;
- Komunikacijski sistem - “GitLab Mattermost”;
- Sistem za upravljanje konfiguracijom - “Ansible”;
- Sistem za nadzor - “ELK”, “TICK Stack” (“InfluxData”).
Počeli su da stvaraju tim koji bi bio spreman da uvuče izvođače unutra. Postoji spoznaja da postoji nekoliko važnih stvari:
- Sve bi trebalo biti objedinjeno, barem kada se prenosi kod. Zato što je bilo toliko izvođača koliko je bilo različitih razvojnih procesa sa svojim posebnostima. Trebalo je svakog uklopiti otprilike u jedno, ali sa opcijama.
- Postoji mnogo izvođača, a ručno kreiranje infrastrukture nije prikladno. Svaki novi zadatak bi trebao početi vrlo brzo – to jest, instanca bi trebala biti implementirana gotovo trenutno, tako da programeri imaju skup rješenja za upravljanje svojim kanalom.
Za prvi korak bilo je potrebno razumjeti šta se radi. I morali smo da odredimo kako da stignemo tamo. Počeli smo tako što smo pomogli da se nacrta arhitektura ciljnog rješenja kako u infrastrukturi tako iu CI/CD automatizaciji. Onda smo počeli da sklapamo ovaj transporter. Trebala nam je jedna infrastruktura, ista za sve, gdje bi kretali isti transporteri. Ponudili smo opcije sa kalkulacijama, razmišljala je banka, pa odlučivala šta će se graditi i kojim sredstvima.
Sljedeća je izrada kruga - instalacija softvera, konfiguracija. Razvoj skripti za postavljanje i upravljanje infrastrukturom. Slijedi prijelaz na podršku transportera.
Odlučili smo da sve testiramo na pilotu. Zanimljivo je da se tokom pilotiranja u banci prvi put pojavio određeni steck. Između ostalog, domaći dobavljač jednog od rješenja ponuđen je za obim pilota za brzo lansiranje. Obezbeđenje ga je upoznalo dok je pilotirao i ostavilo je nezaboravan utisak. Kada smo odlučili da se prebacimo, na sreću, infrastrukturni sloj je zamenjen Nutanix rešenjem, koje je već bilo u banci. Štaviše, prije toga je bio za VDI, ali smo ga ponovo koristili za infrastrukturne usluge. Pri malim količinama nije se uklapao u ekonomiju, ali u velikim količinama postao je odlično okruženje za razvoj i testiranje.
Ostatak steka je više-manje poznat svima. Korišteni su alati za automatizaciju u Ansibleu, a stručnjaci za sigurnost su blisko sarađivali s njima. Atlassin stack je koristila banka prije projekta. Sigurnosni alati Fortinet-a - to su predložili sami ljudi iz sigurnosti. Okvir za testiranje je kreirala banka, bez pitanja. Sistem repozitorija je postavio pitanja, morao sam se naviknuti na njega.
Izvođači su dobili novi dimnjak. Dali su nam vremena da ga prepišemo za GitlabCI, i da migriramo Jira u segment bankarstva, i tako dalje.
korak po korak
Faza 1. Prvo smo koristili rješenje domaćeg proizvođača, proizvod je spojen na novo kreirani DSO segment mreže. Platforma je odabrana zbog vremena isporuke, fleksibilnosti skaliranja i mogućnosti potpune automatizacije. Sprovedeni testovi:
- Mogućnost fleksibilnog i potpuno automatizovanog upravljanja infrastrukturom platforme virtuelizacije (mreža, diskovni podsistem, podsistem računarskih resursa).
- Automatizacija upravljanja životnim ciklusom virtuelne mašine (templating, snapshots, backup).
Nakon instalacije i osnovne konfiguracije platforme, korišćena je kao mesto postavljanja podsistema druge faze (DSO alati, nacrti razvoja maloprodajnih sistema). Stvoreni su potrebni setovi cjevovoda - kreiranje, brisanje, modifikacija, backup virtualnih mašina. Ovi cjevovodi su korišteni kao prva faza procesa implementacije.
Rezultat je da dostavljena oprema ne ispunjava zahtjeve banke za performanse i toleranciju grešaka. Direkcija banke odlučila je kreirati kompleks baziran na softverskom paketu Nutanix.
Faza 2. Uzeli smo stog koji je bio definisan i napisali automatizovane skripte za instalaciju i postkonfiguraciju za sve podsisteme tako da se sve što je brže prenelo od pilota do ciljnog kola. Svi sistemi su raspoređeni u konfiguraciji otpornoj na greške (gdje ova mogućnost nije ograničena politikama licenciranja dobavljača) i povezani sa metričkim i podsistemima prikupljanja događaja. IB je analizirao usklađenost sa svojim zahtjevima i dao zeleno svjetlo.
Faza 3. Migracija svih podsistema i njihovih postavki na novi PAC. Skripte za automatizaciju infrastrukture su prepisane, a migracija ODS podsistema je završena u potpuno automatizovanom režimu. Konture razvoja IP-a su ponovo kreirane kroz cevovode razvojnih timova.
Faza 4. Automatizacija instalacije aplikativnog softvera. Ove zadatke postavili su čelnici novih timova.
Faza 5. Eksploatacija.
Daljinski pristup
Razvojni timovi su tražili maksimalnu fleksibilnost u radu sa sklopom, a zahtjev za udaljenim pristupom sa ličnih laptopa postavljen je na samom početku projekta. Banka je već imala daljinski pristup, ali nije bio pogodan za programere. Činjenica je da je shema koristila konekciju korisnika na zaštićeni VDI. Ovo je bilo prikladno za one kojima je na radnom mjestu bila potrebna samo pošta i uredski paket. Programerima bi bili potrebni teški klijenti, visoke performanse, sa puno resursa. I naravno, morali su biti statični, jer je gubitak korisničke sesije za one koji rade sa VStudio (na primjer) ili drugim SDK-om neprihvatljiv. Organiziranje velikog broja debelih statičkih VDI-ova za sve razvojne timove uvelike je povećalo cijenu postojećeg VDI rješenja.
Odlučili smo da radimo na daljinskom pristupu direktno resursima razvojnog segmenta. Jira, Wiki, Gitlab, Nexus, klupe za izgradnju i testiranje, virtuelna infrastruktura. Zaštitari su zahtijevali da pristup može biti omogućen samo uz sljedeće:
- Koristeći tehnologije koje su već dostupne u banci.
- Infrastruktura ne bi trebala koristiti postojeće kontrolere domene koji pohranjuju zapise produktivnih objekata naloga.
- Pristup bi trebao biti ograničen samo na one resurse koje zahtijeva određeni tim (tako da jedan proizvodni tim ne može pristupiti resursima drugog tima).
- Maksimalna kontrola nad RBAC-om u sistemima.
Kao rezultat, kreirana je posebna domena za ovaj segment. Ova domena je sadržavala sve resurse razvojnog segmenta, i korisničke vjerodajnice i infrastrukturu. Životnim ciklusom zapisa u ovoj domeni upravlja se korištenjem IdM-a koji postoji u banci.
Direktan daljinski pristup organizovan je na osnovu postojeće opreme banke. Kontrola pristupa je podijeljena u AD grupe, kojima su odgovarala pravila o kontekstima (jedna grupa proizvoda = jedna grupa pravila).
VM Template Management
Brzina kreiranja montažne i ispitne petlje jedan je od glavnih KPI-a koje postavlja šef razvojne jedinice, jer brzina pripreme okruženja direktno utiče na ukupno vrijeme izvršenja cjevovoda. Razmotrene su dvije opcije za pripremu osnovnih VM slika. Prvi je minimalna veličina slike, podrazumevana za sve sistemske proizvode, maksimalna usklađenost sa politikom banke u vezi sa podešavanjima. Druga je osnovna slika, koja sadrži instaliran POPPO za teške uslove rada, čije vrijeme instalacije može u velikoj mjeri utjecati na brzinu izvršavanja cjevovoda.
Infrastrukturni i sigurnosni zahtjevi su takođe uzeti u obzir prilikom razvoja - održavanje slika ažurnim (zakrpe, itd.), integracija sa SIEM-om, sigurnosna podešavanja prema standardima banke.
Kao rezultat toga, odlučeno je da se koriste minimalne slike kako bi se minimizirali troškovi njihovog ažuriranja. Mnogo je lakše ažurirati osnovni OS nego zakrpiti svaku sliku za nove verzije POPPO-a.
Na osnovu rezultata formirana je lista minimalno potrebnog skupa operativnih sistema čije ažuriranje vrši operativni tim, a skripte iz pipeline-a su u potpunosti odgovorne za ažuriranje softvera, a po potrebi i promjenu verzije instaliranog softvera - samo prenesite potrebnu oznaku u cevovod. Da, ovo zahtijeva da tim za devops proizvod ima složenije scenarije implementacije, ali uvelike smanjuje operativno vrijeme potrebno za podršku osnovnih slika, za koje bi inače bilo potrebno više od stotinu osnovnih VM slika za održavanje.
pristup Internetu
Još jedan kamen spoticanja u pogledu bankarske sigurnosti bio je pristup Internet resursima iz razvojnog okruženja. Štaviše, ovaj pristup se može podijeliti u dvije kategorije:
- Pristup infrastrukturi.
- Pristup za programere.
Pristup infrastrukturi organiziran je proxyingom eksternih spremišta sa Nexusom. Odnosno, nije omogućen direktan pristup sa virtuelnih mašina. To je omogućilo postizanje kompromisa oko informacione sigurnosti, koja je bila kategorički protiv pružanja bilo kakvog pristupa vanjskom svijetu iz razvojnog segmenta.
Programerima je bio potreban pristup internetu iz očiglednih razloga (stackoverflow). I iako su sve komande, kao što je gore spomenuto, imale daljinski pristup krugu, nije uvijek zgodno kada ne možete napraviti ctrl+v sa radnog mjesta programera u banci u IDE-u.
Postignut je dogovor sa IS-om da će u početku, u fazi testiranja, pristup biti omogućen preko bankarskog proksija na osnovu bele liste. Po završetku projekta pristup će biti prebačen na crnu listu. Pripremljene su ogromne tabele pristupa koje su ukazivale na glavne resurse i spremišta kojima je pristup bio potreban na početku projekta. Koordinacija ovih pristupa trajala je dosta vremena, što je omogućilo da se insistira na što bržem prelasku na crne liste.
Rezulʹtaty
Projekat je završen prije nešto manje od godinu dana. Čudno je da su svi izvođači na vrijeme prešli na novi dimnjak i niko nije otišao zbog nove automatizacije. IB ne žuri sa dijeljenjem pozitivnih povratnih informacija, ali se ni ne žali, iz čega možemo zaključiti da im se sviđa. Konflikti su se smirili jer se informaciona sigurnost ponovo osjeća pod kontrolom, ali ne ometa razvojne procese. Timovi su dobili više odgovornosti, a ukupni odnos prema informacionoj bezbednosti je postao bolji. Banka je shvatila da je prelazak na DevSecOps gotovo neizbježan i učinila je to, po mom mišljenju, na najnježniji i najkorektniji način.
Aleksandar Šubin, sistemski arhitekta.
izvor: www.habr.com