Banka svoje projekte povjerava mnogim izvođačima. "Vanjski" pišu kod, a zatim prenose rezultate u ne baš prikladnom obliku. Konkretno, proces je izgledao ovako: predali su projekt koji je kod njih prošao funkcionalne testove, a potom je testiran unutar bankovnog 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, to je značilo dugo vrijeme potrebno za ispravljanje grešaka.
Banka je odlučila da je moguće i potrebno povući cijeli cjevovod pod svoje okrilje, od obveza do izdanja. Kako bi sve bilo ujednačeno i pod kontrolom timova zaduženih za proizvod u banci. Odnosno, kao da vanjski izvođač jednostavno radi negdje u susjednoj prostoriji ureda. Na korporativnom stogu. Ovo je običan devops.
Odakle Sec? Sigurnost banke postavlja visoke zahtjeve kako vanjski izvođač može raditi u mrežnom segmentu, kakav pristup ima tko, kako i tko radi s kodom. Samo što IB još nije znao da se malo bankovnih standarda poštuje kad izvođači rade vani. I onda ih za par dana svi trebaju početi promatrati.
Jednostavno otkriće da je izvođač imao potpuni pristup šifri proizvoda već im je okrenulo svijet naglavačke.
U ovom trenutku je počela priča o DevSecOps-u o kojoj vam želim pričati.
Kakve je praktične zaključke banka izvukla iz ove situacije?
Mnogo se polemiziralo o tome da se sve radi na pogrešan način. Programeri su rekli da je sigurnost zauzeta samo pokušajima ometanja razvoja, a oni, poput čuvara, pokušavaju zabraniti bez razmišljanja. Zauzvrat, stručnjaci za sigurnost oklijevali su birajući između stajališta: "programeri stvaraju ranjivosti u našem krugu" i "programeri ne stvaraju ranjivosti, već su oni sami." Spor bi trajao još dugo da nije novih zahtjeva tržišta i pojave paradigme DevSecOps. Bilo je moguće objasniti da će ova sama automatizacija procesa uzimajući u obzir zahtjeve informacijske sigurnosti "izvan okvira" pomoći svima da ostanu zadovoljni. U smislu da su pravila zapisana odmah i ne mijenjaju se tijekom igre (informacijska sigurnost neće nešto neočekivano zabraniti), a programeri obavještavaju informacijsku sigurnost o svemu što se događa (informacijska sigurnost ne naiđe na nešto iznenada) . Svaki tim je također odgovoran za ultimativnu sigurnost, a ne neka apstraktna starija braća.
- Budući da vanjski zaposlenici već imaju pristup kodu i brojnim internim sustavima, vjerojatno je moguće iz dokumenata ukloniti zahtjev "razvoj se mora u potpunosti provoditi na infrastrukturi banke."
- S druge strane, moramo pojačati kontrolu nad onim što se događa.
- Kompromis je bio stvaranje međufunkcionalnih timova, gdje zaposlenici blisko surađuju s vanjskim ljudima. U tom slučaju morate biti sigurni da tim radi na alatima na poslužiteljima banke. Od početka do kraja.
Odnosno, izvođači se mogu pustiti, ali im treba dati zasebne segmente. Da ne unesu nekakvu zarazu izvana u infrastrukturu banke i da ne vide više od onoga što je potrebno. Pa, tako da se njihove radnje bilježe. DLP za zaštitu od curenja, sve je to bilo uključeno.
U principu sve banke prije ili kasnije dođu do toga. Tu smo krenuli utabanim putem i dogovorili zahtjeve za takve sredine u kojima rade “vanjski”. Pojavio se maksimalan raspon alata za kontrolu pristupa, alata za provjeru ranjivosti, antivirusne analize sklopova, sklopova i testova. To 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, tada se u novoj paradigmi sigurnost kontrolira na isti način kao i obični događaji na infrastrukturi. Tek sada postoje upozorenja na skupštine, kontrolu knjižnica i tako dalje.
Ostalo je samo prebaciti timove na novi model. Pa, stvorite infrastrukturu. Ali to su sitnice, to je kao da crtate sovu. Zapravo, pomogli smo u infrastrukturi, au to vrijeme su se mijenjali razvojni procesi.
Što se promijenilo
Odlučili smo to provoditi malim koracima, jer smo shvatili da će se mnogi procesi raspasti, a mnogi “vanjski” možda neće moći izdržati nove uvjete rada pod nadzorom svih.
Prvo smo stvorili međufunkcionalne timove i naučili organizirati projekte uzimajući u obzir nove zahtjeve. U organizacijskom 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, Selenium: 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 snop:
- Baza znanja - Atlassian Confluence;
- Praćenje zadataka - Atlassian Jira;
- Skladište artefakata - “Nexus”;
- Sustav kontinuirane integracije - “Gitlab CI”;
- Sustav kontinuirane analize - “SonarQube”;
- Sustav za analizu sigurnosti aplikacija - “Micro Focus Fortify”;
- Komunikacijski sustav - “GitLab Mattermost”;
- Sustav upravljanja konfiguracijom - “Ansible”;
- Sustav nadzora - “ELK”, “TICK Stack” (“InfluxData”).
Počeli su stvarati tim koji bi bio spreman uvući izvođače radova unutra. Postoji spoznaja da postoji nekoliko važnih stvari:
- Sve bi trebalo biti unificirano, barem kod prijenosa koda. Jer koliko je bilo izvođača radova toliko je bilo i različitih razvojnih procesa sa svojim posebnostima. Trebalo je sve smjestiti otprilike u jednu, ali s opcijama.
- Izvođača je mnogo, a ručna izrada infrastrukture nije prikladna. Svaki novi zadatak trebao bi se pokrenuti vrlo brzo - to jest, instanca bi se trebala implementirati gotovo trenutačno tako da programeri imaju skup rješenja za upravljanje svojim cjevovodom.
Za prvi korak bilo je potrebno razumjeti što se radi. I morali smo odrediti kako do tamo doći. Započeli smo tako što smo pomogli u crtanju arhitekture ciljanog rješenja u infrastrukturi i CI/CD automatizaciji. Zatim smo počeli sastavljati ovaj transporter. Trebala nam je jedna infrastruktura, ista za sve, gdje bi išli isti transporteri. Ponudili smo opcije s izračunima, banka je razmišljala, pa odlučila što će se graditi i s kojim sredstvima.
Slijedi izrada sklopa - instalacija softvera, konfiguracija. Razvoj skripti za postavljanje i upravljanje infrastrukturom. Slijedi prijelaz na potporu pokretne trake.
Odlučili smo sve testirati na pilotu. Zanimljivo je da se tijekom pilotiranja u banci prvi put pojavio određeni hrp. Između ostalog, u sklopu pilota za brzo lansiranje ponuđen je domaći dobavljač jednog od rješenja. Osiguranje ga je upoznalo dok je pilotirao i to je ostavilo nezaboravan dojam. Kad smo se odlučili za prelazak, srećom, infrastrukturni sloj je zamijenjen Nutanix rješenjem koje je već bilo u banci prije. Štoviše, prije toga je bio za VDI, ali smo ga ponovno upotrijebili za infrastrukturne usluge. U malim količinama nije se uklapao u gospodarstvo, ali u velikim količinama postao je izvrsno okruženje za razvoj i testiranje.
Ostatak hrpe je više-manje svima poznat. Korišteni su alati za automatizaciju u Ansibleu, a s njima su blisko surađivali sigurnosni stručnjaci. Banka je prije projekta koristila Atlassin stack. Fortinet sigurnosni alati - predložili su ih sami ljudi iz sigurnosti. Okvir za testiranje izradila je banka, bez pitanja. Sustav repozitorija postavljao je pitanja; morao sam se naviknuti na njega.
Izvođači su dobili novi dimnjak. Dali su nam vremena da ga ponovno napišemo za GitlabCI, i da migriramo Jira u bankarski segment, i tako dalje.
Korak po korak
Korak 1. Prvo smo koristili rješenje domaćeg dobavljača, proizvod smo spojili na novoizgrađeni segment DSO mreže. Platforma je odabrana zbog vremena isporuke, fleksibilnosti skaliranja i mogućnosti potpune automatizacije. Provedeni testovi:
- Mogućnost fleksibilnog i potpuno automatiziranog upravljanja infrastrukturom virtualizacijske platforme (mreža, diskovni podsustav, podsustav računalnih resursa).
- Automatizacija upravljanja životnim ciklusom virtualnog stroja (predlošci, snimke, sigurnosne kopije).
Nakon instalacije i osnovne konfiguracije platforma je korištena kao točka postavljanja podsustava druge etape (DSO alati, nacrti razvoja maloprodajnih sustava). Stvoreni su potrebni skupovi cjevovoda - stvaranje, brisanje, modifikacija, backup virtualnih strojeva. Ovi su cjevovodi korišteni kao prva faza procesa implementacije.
Rezultat toga je da pružena oprema ne ispunjava zahtjeve banke za performansama i tolerancijom na pogreške. DIT banke odlučio je izraditi kompleks temeljen na programskom paketu Nutanix.
Stad 2. Uzeli smo skup koji je definiran i napisali automatizirane instalacijske i postkonfiguracijske skripte za sve podsustave kako bi se sve što je brže moguće prenijelo iz pilota u ciljni krug. Svi sustavi su postavljeni u konfiguraciji otpornoj na greške (gdje ova mogućnost nije ograničena pravilima licenciranja dobavljača) i povezani su s metričkim podsustavima i prikupljanjem događaja. IB je analizirao usklađenost sa svojim zahtjevima i dao zeleno svjetlo.
Stad 3. Migracija svih podsustava i njihovih postavki na novi PAC. Skripte za automatizaciju infrastrukture su ponovno napisane, a migracija DSO podsustava je završena u potpuno automatiziranom načinu rada. Obrise razvoja IP-a rekreirali su projekti razvojnih timova.
Korak 4. Automatizacija instalacije aplikativnog softvera. Te su zadatke postavili voditelji novih timova.
Korak 5. Eksploatacija.
Udaljeni pristup
Razvojni timovi tražili su maksimalnu fleksibilnost u radu sa sklopom, a zahtjev za udaljenim pristupom s osobnih prijenosnih računala postavljen je na samom početku projekta. Banka je već imala daljinski pristup, ali nije bio prikladan za programere. Činjenica je da je shema koristila vezu korisnika na zaštićeni VDI. Ovo je bilo prikladno za one koji su trebali samo poštu i uredski paket na svom radnom mjestu. Programeri bi trebali teške klijente, visoke performanse, s puno resursa. I naravno, morali su biti statični, budući da je gubitak korisničke sesije za one koji rade s VStudiom (na primjer) ili drugim SDK-om neprihvatljiv. Organiziranje velikog broja debelih statičkih VDI-ova za sve razvojne timove uvelike je povećalo trošak postojećeg VDI rješenja.
Odlučili smo raditi na daljinskom pristupu izravno resursima razvojnog segmenta. Jira, Wiki, Gitlab, Nexus, klupe za izradu i testiranje, virtualna infrastruktura. Zaštitari su zahtijevali da se pristup može omogućiti samo uz sljedeće uvjete:
- Korištenje tehnologija koje su već dostupne u banci.
- Infrastruktura ne bi trebala koristiti postojeće kontrolere domene koji pohranjuju zapise produktivnih objekata računa.
- 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 u sustavima.
Kao rezultat toga, za ovaj segment stvorena je zasebna domena. U ovoj su se domeni nalazili svi resursi razvojnog segmenta, kako korisničke vjerodajnice tako i infrastruktura. Životnim ciklusom zapisa u ovoj domeni upravlja se pomoću postojećeg IdM-a u banci.
Izravan daljinski pristup organiziran je na temelju postojeće opreme banke. Kontrola pristupa bila je podijeljena u AD grupe, kojima su odgovarala pravila o kontekstima (jedna grupa proizvoda = jedna grupa pravila).
Upravljanje VM predlošcima
Brzina stvaranja sklopa i petlje testiranja jedan je od glavnih KPI-ja koje postavlja voditelj razvojne jedinice, jer brzina pripreme okruženja izravno utječe na ukupno vrijeme izvršenja cjevovoda. Razmotrene su dvije opcije za pripremu osnovnih VM slika. Prva je minimalna veličina slike, zadana za sve proizvode sustava, maksimalna usklađenost s politikom banke u pogledu postavki. Druga je osnovna slika, koja sadrži instaliran POPPO za teške uvjete rada, čije bi vrijeme instalacije moglo uvelike utjecati na brzinu izvođenja cjevovoda.
Tijekom razvoja također su uzeti u obzir infrastrukturni i sigurnosni zahtjevi - ažuriranje slika (zakrpe, itd.), integracija sa SIEM-om, sigurnosne postavke prema standardima banke.
Kao rezultat toga, odlučeno je koristiti minimalan broj slika kako bi se smanjili troškovi njihovog ažuriranja. Puno je lakše ažurirati osnovni OS nego krpati svaku sliku za nove verzije POPPO-a.
Na temelju rezultata formirana je lista minimalno potrebnog skupa operativnih sustava čiju nadogradnju provodi operativni tim, a skripte iz pipeline-a u potpunosti su zadužene za nadogradnju softvera, te po potrebi mijenjaju verziju instaliranog softvera - samo prenesite potrebnu oznaku u cjevovod. Da, ovo zahtijeva od devops proizvodnog tima da ima složenije scenarije implementacije, ali uvelike smanjuje operativno vrijeme potrebno za podršku osnovnih slika, za koje bi inače moglo biti potrebno više od stotinu osnovnih VM slika za održavanje.
Pristup Internetu
Drugi kamen spoticanja kod bankarske sigurnosti bio je pristup internetskim resursima iz razvojnog okruženja. Štoviše, ovaj se pristup može podijeliti u dvije kategorije:
- Pristup infrastrukturi.
- Pristup programera.
Pristup infrastrukturi organiziran je proxyjem vanjskih repozitorija s Nexusom. Odnosno, izravan pristup s virtualnih strojeva nije bio omogućen. To je omogućilo postizanje kompromisa s informacijskom sigurnošću, koja je bila kategorički protiv pružanja bilo kakvog pristupa vanjskom svijetu iz razvojnog segmenta.
Programerima je bio potreban pristup Internetu iz očitih razloga (stackoverflow). I iako su sve naredbe, kao što je gore spomenuto, imale daljinski pristup krugu, nije uvijek zgodno kada ne možete učiniti ctrl+v s radnog mjesta programera u banci u IDE-u.
S IS-om je postignut dogovor da će se u početku, u fazi testiranja, pristup omogućiti putem bankovnog proxyja na temelju bijele liste. Po završetku projekta, pristup će biti prebačen na crnu listu. Pripremljene su goleme pristupne tablice koje su ukazivale na glavne resurse i repozitorije kojima je bio potreban pristup na početku projekta. Usklađivanje ovih pristupa trajalo je prilično dugo, što je omogućilo inzistiranje na što bržem prijelazu na crne liste.
Nalazi
Projekt je završio prije nešto manje od godinu dana. Čudno je da su svi izvođači na vrijeme prešli na novi dimnjak i nitko nije otišao zbog nove automatizacije. IB ne žuri s pozitivnim povratnim informacijama, ali se niti ne žali, iz čega možemo zaključiti da im se sviđa. Konflikti su se smirili jer se informacijska sigurnost ponovno osjeća pod kontrolom, ali ne ometa razvojne procese. Timovi su dobili više odgovornosti, a ukupni odnos prema informacijskoj sigurnosti postao je bolji. Banka je shvatila da je prijelaz na DevSecOps gotovo neizbježan i učinila je to, po mom mišljenju, na najnježniji i najispravniji način.
Alexander Shubin, arhitekt sustava.
Izvor: www.habr.com