Banka svoje projekte oddaja številnim izvajalcem. "Zunanji" napišejo kodo, nato posredujejo rezultate v ne preveč priročni obliki. Konkretno je proces izgledal takole: predali so projekt, ki je pri njih opravil funkcionalne teste, nato pa je bil testiran znotraj bančnega perimetra za integracijo, obremenitev itd. Pogosto se je izkazalo, da so bili testi neuspešni. Potem se je vse vrnilo k zunanjemu razvijalcu. Kot lahko ugibate, je to pomenilo dolge čase za odpravo napak.
Banka se je odločila, da je možno in potrebno pod svoje okrilje povleči celoten cevovod, od zavez do sprostitev. Tako, da je vse enotno in pod nadzorom ekip, odgovornih za produkt v banki. Se pravi, kot da bi zunanji izvajalec preprosto delal nekje v sosednji sobi pisarne. Na podjetniški lestvici. To je navaden devops.
Od kod Sec? Varnost banke postavlja visoke zahteve, kako lahko zunanji izvajalec deluje v segmentu omrežja, kakšen dostop ima kdo, kako in kdo dela s kodo. Samo IB še ni vedel, da ko izvajalci delajo zunaj, se upošteva nekaj bančnih standardov. In potem jih morajo čez nekaj dni vsi začeti opazovati.
Preprosto razkritje, da je imel izvajalec popoln dostop do kode izdelka, jim je svet obrnilo na glavo.
V tem trenutku se je začela zgodba DevSecOps, o kateri vam želim povedati.
Kakšne praktične zaključke je banka potegnila iz te situacije?
Bilo je veliko polemik o tem, da se vse dela na napačen način. Razvijalci so dejali, da je varnost zaposlena le z motnjami v razvoju, in oni, kot stražarji, poskušajo brez razmišljanja prepovedati. Po drugi strani pa so varnostni strokovnjaki oklevali med izbiro med stališči: "razvijalci ustvarjajo ranljivosti v našem vezju" in "razvijalci ne ustvarjajo ranljivosti, ampak so to sami." Spor bi trajal še dolgo, če ne bi prišlo do novih zahtev trga in pojava paradigme DevSecOps. Možno je bilo razložiti, da bo prav ta avtomatizacija procesov ob upoštevanju zahtev informacijske varnosti "izven škatle" pomagala vsem, da ostanejo zadovoljni. V smislu, da so pravila zapisana takoj in se med igro ne spreminjajo (informacijska varnost ne bo nečesa nepričakovano prepovedala), razvijalci pa informacijsko varnost obveščajo o vsem, kar se dogaja (informacijska varnost ne naleti na nekaj nenadoma) . Za popolno varnost je odgovorna tudi vsaka ekipa in ne kakšni abstraktni starejši bratje.
- Ker zunanji zaposleni že imajo dostop do kode in številnih notranjih sistemov, je verjetno možno iz dokumentov črtati zahtevo »razvoj mora potekati v celoti na infrastrukturi banke«.
- Po drugi strani pa moramo okrepiti nadzor nad dogajanjem.
- Kompromis je bil ustvarjanje medfunkcionalnih timov, kjer zaposleni tesno sodelujejo z zunanjimi ljudmi. V tem primeru se morate prepričati, da ekipa dela na orodjih na strežnikih banke. Od začetka do konca.
Se pravi, izvajalci se lahko dovolijo, vendar jim je treba dati ločene segmente. Da ne prinesejo kakšne okužbe od zunaj v infrastrukturo banke in da ne vidijo več kot je treba. No, tako da se njihova dejanja beležijo. DLP za zaščito pred puščanjem, vse to je bilo vključeno.
Načeloma vse banke prej ali slej pridejo do tega. Tu smo šli po uhojeni poti in se dogovorili o zahtevah za taka okolja, kjer delujejo »zunanji«. Pojavil se je največji obseg orodij za nadzor dostopa, orodij za preverjanje ranljivosti, protivirusne analize na vezjih, sklopih in testih. To se imenuje DevSecOps.
Nenadoma je postalo jasno, da če pred DevSecOps bančna varnost ni imela nadzora nad dogajanjem na strani razvijalca, potem je v novi paradigmi varnost nadzorovana na enak način kot običajni dogodki na infrastrukturi. Šele zdaj so opozorila na skupščine, nadzor knjižnic itd.
Ostaja le prenos ekip na nov model. No, ustvarite infrastrukturo. Ampak to so malenkosti, kot da bi risal sovo. Pravzaprav smo pomagali pri infrastrukturi, takrat pa so se razvojni procesi spreminjali.
Kaj se je spremenilo
Odločili smo se, da ga izvajamo v majhnih korakih, ker smo razumeli, da bo marsikateri proces propadel, številni »zunanji« pa morda ne bodo zdržali novih pogojev dela pod nadzorom vseh.
Najprej smo ustvarili medfunkcionalne ekipe in se naučili organizirati projekte ob upoštevanju novih zahtev. V organizacijskem smislu smo razpravljali o kakšnih procesih. Rezultat je bila shema montažnega plinovoda z vsemi odgovornimi.
- 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.
- predstavitev (poročanje, komuniciranje): Grafana, Kibana, Jira, Confluence, RocketChat.
- operacije (vzdrževanje, upravljanje): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Izbrani sklad:
- Baza znanja - Atlassian Confluence;
- Sledilnik opravil - Atlassian Jira;
- Repozitorij artefaktov - "Nexus";
- Sistem kontinuirane integracije - “Gitlab CI”;
- Sistem za kontinuirano analizo - “SonarQube”;
- Sistem za analizo varnosti aplikacij - “Micro Focus Fortify”;
- Komunikacijski sistem - “GitLab Mattermost”;
- Sistem za upravljanje konfiguracije - “Ansible”;
- Sistem za spremljanje - "ELK", "TICK Stack" ("InfluxData").
Začeli so ustvarjati ekipo, ki bi bila pripravljena noter zvleči izvajalce. Obstaja spoznanje, da je nekaj pomembnih stvari:
- Vse bi moralo biti poenoteno, vsaj pri prenosu kode. Ker je bilo toliko izvajalcev, toliko je bilo različnih razvojnih procesov s svojimi posebnostmi. Vse je bilo treba umestiti v približno enega, vendar z možnostmi.
- Izvajalcev je veliko, ročna izdelava infrastrukture pa ni primerna. Vsaka nova naloga bi se morala začeti zelo hitro – to pomeni, da bi bilo treba primerek razmestiti skoraj v trenutku, tako da imajo razvijalci nabor rešitev za upravljanje svojega cevovoda.
Za prvi korak je bilo treba razumeti, kaj se dela. In morali smo ugotoviti, kako priti tja. Začeli smo s pomočjo pri risanju arhitekture ciljne rešitve v infrastrukturi in avtomatizaciji CI/CD. Nato smo začeli sestavljati ta transporter. Potrebovali smo eno infrastrukturo, enako za vse, kjer bi tekli isti transporterji. Ponudili smo možnosti z izračuni, banka je razmišljala, se nato odločila, kaj se bo gradilo in s kakšnimi sredstvi.
Sledi izdelava vezja - namestitev programske opreme, konfiguracija. Razvoj skriptov za postavitev in upravljanje infrastrukture. Sledi prehod na transportno podporo.
Odločili smo se, da vse preizkusimo na pilotu. Zanimivo je, da se je med pilotiranjem v banki prvič pojavil določen sklad. Med drugim je bil za obseg pilota za hiter zagon ponujen domači ponudnik ene od rešitev. Med pilotiranjem ga je varnostnik spoznal in pustil nepozaben vtis. Ko smo se odločili za zamenjavo, je bil na srečo infrastrukturni sloj zamenjan z rešitvijo Nutanix, ki je bila v banki že prej. Še več, pred tem je bil za VDI, vendar smo ga ponovno uporabili za infrastrukturne storitve. Pri majhnih količinah ni sodil v gospodarstvo, pri velikih pa je postal odlično okolje za razvoj in testiranje.
Preostanek sklada je bolj ali manj znan vsem. Uporabljena so bila orodja za avtomatizacijo v Ansibleu, z njimi pa so tesno sodelovali strokovnjaki za varnost. Sklad Atlassin je banka uporabljala pred projektom. Varnostna orodja Fortinet – predlagali so jih varnostniki sami. Testni okvir je ustvarila banka brez vprašanj. Sistem repozitorija je sprožal vprašanja; moral sem se navaditi nanj.
Izvajalci so dobili nov sklad. Dali so nam čas, da ga prepišemo za GitlabCI in Jira preselimo v bančni segment itd.
korak za korakom
Korak 1. Najprej smo uporabili rešitev domačega ponudnika, izdelek smo priključili na novo ustvarjen segment omrežja DSO. Platforma je bila izbrana zaradi dobavnih rokov, prilagodljivosti skaliranja in možnosti popolne avtomatizacije. Opravljeni testi:
- Možnost fleksibilnega in popolnoma avtomatiziranega upravljanja infrastrukture virtualizacijske platforme (omrežje, diskovni podsistem, podsistem računalniških virov).
- Avtomatizacija upravljanja življenjskega cikla virtualnega stroja (templating, snapshots, backup).
Po namestitvi in osnovni konfiguraciji platforme je bila le-ta uporabljena kot točka umestitve podsistemov druge stopnje (orodja DSO, načrti razvoja maloprodajnih sistemov). Ustvarjeni so bili potrebni nizi cevovodov - ustvarjanje, brisanje, spreminjanje, varnostno kopiranje virtualnih strojev. Ti cevovodi so bili uporabljeni kot prva stopnja postopka uvajanja.
Posledica tega je, da ponujena oprema ne izpolnjuje zahtev banke glede zmogljivosti in tolerance na napake. Banka DIT se je odločila za izdelavo kompleksa na osnovi programskega paketa Nutanix.
Stopnja 2. Vzeli smo sklad, ki je bil definiran, in napisali skripte za avtomatizirano namestitev in post-konfiguracijo za vse podsisteme, tako da je bilo vse čim hitreje preneseno iz pilotnega v ciljno vezje. Vsi sistemi so bili nameščeni v konfiguraciji, odporni na napake (kjer te zmožnosti ne omejujejo prodajalčeve politike licenciranja) in povezani s podsistemi metrik in zbiranja dogodkov. IB je analiziral skladnost s svojimi zahtevami in dal zeleno luč.
Stopnja 3. Migracija vseh podsistemov in njihovih nastavitev na nov PAC. Na novo so bili napisani skripti za avtomatizacijo infrastrukture in v popolnoma avtomatiziranem načinu je bila zaključena migracija podsistemov DSO. Obrise razvoja intelektualne lastnine so poustvarili načrti razvojnih skupin.
Korak 4. Avtomatizacija namestitve aplikativne programske opreme. Te naloge so si zastavili vodje novih ekip.
Korak 5. izkoriščanje.
Oddaljen dostop
Razvojne ekipe so zahtevale maksimalno fleksibilnost pri delu z vezjem, zahteva po oddaljenem dostopu iz osebnih prenosnikov pa je bila izpostavljena že na samem začetku projekta. Banka je že imela oddaljeni dostop, vendar ni bil primeren za razvijalce. Dejstvo je, da je shema uporabila uporabnikovo povezavo z zaščitenim VDI. To je bilo primerno za tiste, ki so na delovnem mestu potrebovali samo pošto in pisarniški paket. Razvijalci bi potrebovali težke stranke, visoko zmogljive, z veliko viri. In seveda so morali biti statični, saj je izguba uporabniške seje za tiste, ki delajo na primer z VStudio ali drugim SDK-jem, nesprejemljiva. Organiziranje velikega števila debelih statičnih VDI-jev za vse razvojne skupine je močno povečalo stroške obstoječe rešitve VDI.
Odločili smo se za oddaljeni dostop neposredno do virov razvojnega segmenta. Jira, Wiki, Gitlab, Nexus, klopi za izdelavo in testiranje, virtualna infrastruktura. Varnostniki so zahtevali, da je dostop mogoč samo ob upoštevanju naslednjega:
- Uporaba tehnologij, ki so že na voljo v banki.
- Infrastruktura ne bi smela uporabljati obstoječih krmilnikov domene, ki shranjujejo zapise proizvodnih objektov računa.
- Dostop mora biti omejen samo na tiste vire, ki jih potrebuje določena ekipa (tako da ena skupina izdelkov ne more dostopati do virov druge ekipe).
- Največji nadzor nad RBAC v sistemih.
Posledično je bila za ta segment ustvarjena ločena domena. V tej domeni so bili vsi viri razvojnega segmenta, tako uporabniške poverilnice kot infrastruktura. Življenjski cikel zapisov v tej domeni se upravlja z IdM, ki obstaja v banki.
Neposredni oddaljeni dostop je bil organiziran na podlagi obstoječe opreme banke. Kontrola dostopa je bila razdeljena na skupine AD, ki so jim ustrezala pravila o kontekstih (ena skupina izdelkov = ena skupina pravil).
Upravljanje predlog VM
Hitrost ustvarjanja montažne in testne zanke je eden glavnih KPI-jev, ki jih določi vodja razvojne enote, saj hitrost priprave okolja neposredno vpliva na skupni čas izvajanja cevovoda. Upoštevani sta bili dve možnosti za pripravo osnovnih slik VM. Prva je najmanjša velikost slike, privzeta za vse sistemske produkte, največja skladnost s politiko banke glede nastavitev. Druga je osnovna slika, ki vsebuje nameščen POPPO za težke obremenitve, katerega čas namestitve bi lahko močno vplival na hitrost izvajanja cevovoda.
Pri razvoju so bile upoštevane tudi infrastrukturne in varnostne zahteve – posodabljanje slik (popravki ipd.), integracija s SIEM, varnostne nastavitve po bančnih standardih.
Posledično je bilo odločeno, da uporabimo čim manj slik, da zmanjšamo stroške njihovega posodabljanja. Veliko lažje je posodobiti osnovni OS, kot pa popravljati vsako sliko za nove različice POPPO.
Na podlagi rezultatov je bil oblikovan seznam minimalno zahtevanega nabora operacijskih sistemov, katerih posodobitev izvaja operativna ekipa, za posodobitev programske opreme pa so v celoti odgovorni skripti iz cevovoda, po potrebi pa tudi spremembo različice. nameščene programske opreme - samo prenesite zahtevano oznako v cevovod. Da, to zahteva, da ima ekipa izdelka devops bolj zapletene scenarije uvajanja, vendar močno zmanjša operativni čas, potreben za podporo osnovnih slik, ki bi sicer lahko zahtevale več kot sto osnovnih slik VM za vzdrževanje.
Dostop do interneta
Drugi kamen spotike pri bančni varnosti je bil dostop do internetnih virov iz razvojnega okolja. Poleg tega lahko ta dostop razdelimo v dve kategoriji:
- Dostop do infrastrukture.
- Dostop za razvijalce.
Dostop do infrastrukture je bil organiziran s proxyjem zunanjih repozitorijev z Nexusom. To pomeni, da neposreden dostop iz virtualnih strojev ni bil zagotovljen. To je omogočilo doseganje kompromisa z informacijsko varnostjo, ki je bila kategorično proti zagotavljanju kakršnega koli dostopa do zunanjega sveta iz razvojnega segmenta.
Razvijalci so potrebovali dostop do interneta iz očitnih razlogov (stackoverflow). In čeprav so vsi ukazi, kot je navedeno zgoraj, imeli oddaljeni dostop do vezja, ni vedno priročno, če ne morete narediti ctrl+v z delovnega mesta razvijalca v banki v IDE.
Z IS je bil dosežen dogovor, da bo na začetku, v fazi testiranja, dostop omogočen preko bančnega proxyja na podlagi bele liste. Po zaključku projekta bo dostop prenesen na črno listo. Pripravljene so bile ogromne tabele dostopa, ki so navajale glavne vire in repozitorije, do katerih je bil potreben dostop na začetku projekta. Usklajevanje teh dostopov je trajalo kar nekaj časa, kar je omogočilo vztrajanje pri čim hitrejšem prehodu na črne liste.
Ugotovitve
Projekt se je zaključil pred nekaj manj kot letom dni. Nenavadno je, da so vsi izvajalci pravočasno prešli na nov sklad in nihče ga ni zapustil zaradi nove avtomatizacije. IB se ne mudi z delitvijo pozitivnih povratnih informacij, vendar se tudi ne pritožuje, iz česar lahko sklepamo, da jim je všeč. Konflikti so se umirili, ker se informacijska varnost spet čuti pod nadzorom, vendar ne posega v razvojne procese. Ekipe so dobile več odgovornosti, splošen odnos do informacijske varnosti pa je postal boljši. Banka je razumela, da je prehod na DevSecOps skoraj neizogiben, in to naredila, po mojem mnenju, na najbolj nežen in pravilen način.
Alexander Shubin, sistemski arhitekt.
Vir: www.habr.com