Bankuak bere proiektuak kontratista askoren esku uzten ditu. "Kanpokoek" kodea idazten dute, gero emaitzak oso erosoa ez den moduan transmititzen dituzte. Zehazki, prozesua honelakoa izan zen: haiekin proba funtzionalak gainditu zituen proiektu bat entregatu zuten, eta gero banku-perimetroaren barruan probatu zuten integrazioa, karga eta abar. Askotan aurkitu zen probak porrot egiten ari zirela. Ondoren, dena kanpoko garatzailera itzuli zen. Asma dezakezun bezala, horrek akatsak konpontzeko epe luzeak suposatu zituen.
Bankuak erabaki zuen posible eta beharrezkoa zela hodi osoa bere hegalpean arrastatzea, konpromisoetatik hasi eta askatu arte. Dena uniformea izan dadin eta bankuko produktuaz arduratzen diren taldeen kontrolpean. Hau da, kanpoko kontratistak bulegoko ondoko gelan nonbait lan egingo balu bezala. Pila korporatiboan. Hau devops arrunt bat da.
Nondik atera zen Sec? Bankuaren segurtasunak eskakizun handiak jarri ditu kanpoko kontratistak sarearen segmentuan nola lan egin dezakeen, norbaitek zer sarbide duen, nola eta nork lan egiten duen kodearekin. Besterik da IBk oraindik ez zekiela kontratistak kanpoan lan egiten dutenean, banku-estandar gutxi betetzen direla. Eta gero egun pare batean denek behatzen hasi behar dute.
Kontratistak produktuaren kodearako sarbide osoa zuelako errebelazio soilak dagoeneko hankaz gora jarri zuen euren mundua.
Momentu honetan, DevSecOps-en istorioa hasi zen, zeina kontatu nahi dizuedan.
Zein ondorio praktiko atera ditu bankuak egoera horretatik?
Eztabaida handia izan zen dena modu okerrean egiten ari zelako. Garatzaileek esan zuten segurtasuna garapena oztopatu nahian bakarrik lanpetuta dagoela, eta haiek, zaindariek bezala, pentsatu gabe debekatzen saiatzen dira. Aldiz, segurtasun espezialistak zalantzan jarri ziren ikuspuntuen artean aukeratzearen artean: “garatzaileek ahultasunak sortzen dituzte gure zirkuituan” eta “garatzaileek ez dituzte ahultasunak sortzen, beraiek dira baizik”. Gatazkak denbora luzez jarraituko luke merkatuaren eskakizun berriengatik eta DevSecOps paradigma agertzeagatik ez balitz. Informazioaren segurtasun-eskakizunak kontuan hartuta prozesuen automatizazio honek “kutxatik kanpo” denak pozik egoten lagunduko duela azaldu ahal izan zen. Arauak berehala idazten dira eta jokoan zehar ez dira aldatzen (informazioaren segurtasunak ez du ezer debekatuko ustekabean), eta garatzaileek informazioaren segurtasuna gertatzen den guztiaz informatuta mantentzen dute (informazioaren segurtasunak ez du bat-batean zerbait topatzen). . Talde bakoitza ere azken segurtasunaz arduratzen da, eta ez anaia zahar abstraktu batzuk.
- Kanpoko langileek dagoeneko kodea eta barne sistema batzuetarako sarbidea dutenez, ziurrenik dokumentuetatik kentzea posible da "garapena bankuaren azpiegituran guztiz egin behar da".
- Bestalde, gertatzen ari denaren kontrola indartu behar dugu.
- Konpromisoa funtzio gurutzatuen taldeak sortzea zen, non langileek kanpoko pertsonekin estuki lan egiten duten. Kasu honetan, ziurtatu behar duzu taldeak bankuko zerbitzarietako tresnetan lan egiten duela. Hasieratik amaierara arte.
Hau da, kontratistak sar daitezke, baina segmentu bereiziak eman behar zaizkie. Kanpotik nolabaiteko infekziorik ez ekartzeko bankuaren azpiegituretara eta beharrezkoa dena baino gehiago ikusi ez dezaten. Beno, haien ekintzak erregistratu daitezen. Isurien aurkako babeserako DLP, hori guztia sartu zen.
Printzipioz, banku guztiak etortzen dira horretara goiz edo beranduago. Hemen bide ibiltaritik joan eta “kanpokoak” lan egiten duten horrelako inguruneetarako baldintzak adostu genituen. Sarbide kontrolatzeko tresnak, ahultasunak egiaztatzeko tresnak, birusen aurkako analisiak zirkuituetan, muntaiak eta testak agertu ziren. Honi DevSecOps deitzen zaio.
Bat-batean argi geratu zen DevSecOps bankuaren segurtasunak sustatzailearen aldetik gertatzen denaren gaineko kontrolik ez bazuen, paradigma berrian segurtasuna azpiegiturako gertakari arrunten modu berean kontrolatzen dela. Orain bakarrik daude batzarretan, liburutegien kontrola eta abarrei buruzko alertak.
Taldeak eredu berrira pasatzea besterik ez da geratzen. Tira, azpiegiturak sortu. Baina hauek huskeriak dira, hontza marraztea bezalakoa da. Egia esan, azpiegituretan laguntzen genuen, eta garai hartan garapen prozesuak aldatzen ari ziren.
Zer aldatu den
Pauso txikitan ezartzea erabaki genuen, prozesu asko eroriko zirela ulertzen genuelako, eta “kanpoko” askok ezingo lituzketela jasaten lan baldintza berriak guztion zaintzapean.
Lehenik eta behin, zeharkako taldeak sortu eta proiektuak antolatzen ikasi genuen eskakizun berriak kontuan hartuta. Antolakuntzaren zentzuan zer prozesu eztabaidatu genuen. Emaitza muntaketa-hodiaren diagrama bat izan zen, arduradun guztiekin.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Proba: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- Aurkezpena (erreportajea, komunikazioa): Grafana, Kibana, Jira, Confluence, RocketChat.
- Eragiketak (mantentze-lanak, kudeaketa): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Hautatutako pila:
- Knowledge Base - Atlassian Confluence;
- Zereginen jarraipena - Atlassian Jira;
- Artefaktuen biltegia - "Nexus";
- Etengabeko integrazio sistema - "Gitlab CI";
- Etengabeko analisi sistema - "SonarQube";
- Aplikazioen segurtasuna aztertzeko sistema - "Micro Focus Fortify";
- Komunikazio sistema - "GitLab Mattermost";
- Konfigurazioa kudeatzeko sistema - "Ansible";
- Jarraipen-sistema - "ELK", "TICK Stack" ("InfluxData").
Kontratistak barrura eramateko prest egongo zen talde bat sortzen hasi ziren. Hainbat gauza garrantzitsu daudela konturatzen da:
- Dena bateratu behar da, gutxienez kodea transmititzean. Hainbeste kontratistak baitzeuden garapen prozesu ezberdin eta berezitasun propioekin. Beharrezkoa zen denak gutxi gorabehera batean sartzea, baina aukerekin.
- Kontratista asko dago, eta azpiegitura eskuz sortzea ez da egokia. Edozein zeregin berri oso azkar hasi beharko litzateke, hau da, instantzia ia berehala zabaldu behar da, garatzaileek beren kanalizazioa kudeatzeko irtenbide multzo bat izan dezaten.
Lehen urratsa emateko, zer egiten ari zen ulertu behar zen. Eta nola heldu zehaztu behar genuen. Helburuko irtenbidearen arkitektura marrazten laguntzen hasi ginen, bai azpiegituretan, bai CI/CD automatizazioan. Gero garraiatzaile hau muntatzen hasi ginen. Azpiegitura bat behar genuen, denentzat berdina, non garraiatzaile berdinak ibiliko ziren. Kalkuluekin aukerak eskaintzen genituen, pentsatu zuen bankuak, gero erabaki zuen zer eraikiko zen eta zer funtsekin.
Ondoren, zirkuitua sortzea da - softwarearen instalazioa, konfigurazioa. Azpiegiturak zabaltzeko eta kudeatzeko scriptak garatzea. Ondoren, garraiatzaileen euskarrirako trantsizioa dator.
Dena pilotuan probatzea erabaki genuen. Interesgarria da, pilotalekuan zehar, pila jakin bat agertu zen lehen aldiz bankuan. Besteak beste, irtenbideetako baten etxeko saltzaile bat eskaini zen abiarazte azkarreko pilotuaren esparrurako. Segurtasunak pilotatzen zuen bitartean ezagutu zuen, eta inpresio ahaztezina utzi zuen. Aldatzea erabaki genuenean, zorionez, azpiegitura geruza Nutanix soluzio batekin ordezkatu zen, lehen bankuan zegoena. Gainera, lehenago VDIrako zen, baina azpiegitura zerbitzuetarako berrerabili genuen. Bolumen txikietan ez zen ekonomian sartzen, baina bolumen handietan garapenerako eta probarako ingurune bikaina bihurtu zen.
Gainontzeko pila bat gehiago edo gutxiago ezaguna da guztiontzat. Ansible-n automatizazio-tresnak erabili ziren, eta segurtasun-espezialistek lankidetza estuan aritu ziren haiekin. Atlassin pila proiektuaren aurretik bankuak erabili zuen. Fortinet segurtasun-tresnak - segurtasuneko pertsonek eurek proposatu zuten. Proba markoa bankuak sortu zuen, galderarik egin gabe. Biltegi sistemak galderak sortu zituen; ohitu egin behar izan nuen.
Kontratistari pila berri bat eman zitzaien. Denbora eman ziguten GitlabCIrako berridazteko, eta Jira banku-segmentura migratzeko, etab.
Urratsez urrats
Urratsera 1. Lehenik eta behin, etxeko saltzaile baten soluzio bat erabili genuen, produktua sortu berri den DSO sareko segmentu batera konektatuta zegoen. Plataforma bere entrega denboragatik, eskalatzeko malgutasunagatik eta automatizazio osoa izateko aukeragatik aukeratu zen. Egindako probak:
- Birtualizazio plataformaren azpiegitura (sarea, disko azpisistema, baliabide informatikoen azpisistema) kudeaketa malgua eta guztiz automatizatua egiteko aukera.
- Makina birtualen bizi-zikloaren kudeaketa automatizatzea (txantiloiak, argazkiak, babeskopiak).
Plataformaren instalazioa eta oinarrizko konfigurazioa egin ondoren, bigarren etapako azpisistemen (DSO tresnak, txikizkako sistemen garapenaren eskemak) kokatzeko puntu gisa erabili zen. Beharrezko kanalizazio multzoak sortu ziren - makina birtualen sorrera, ezabapena, aldaketa, babeskopia. Hodi horiek hedapen-prozesuaren lehen fase gisa erabili ziren.
Ondorioz, emandako ekipamenduak ez ditu bankuaren errendimendurako eta akatsen tolerantziarako baldintzak betetzen. Bankuko DIT-ek Nutanix software paketean oinarritutako konplexu bat sortzea erabaki zuen.
2 etapa. Definitutako pila hartu, eta azpisistema guztietarako instalazio eta konfigurazio osteko script automatizatuak idatzi genituen, dena pilotutik helburuko zirkuitura ahalik eta azkarren transferitzeko. Sistema guztiak akatsekiko tolerantzian dagoen konfigurazio batean zabaldu ziren (non gaitasun hori saltzailearen lizentzia-politikek mugatzen ez duten) eta neurketa eta gertaeren bilketa azpisistemetara konektatuta zeuden. IBk bere eskakizunak betetzen diren aztertu eta argi berdea eman zuen.
3 etapa. Azpisistema guztiak eta haien ezarpenak PAC berrira migratzea. Azpiegitura automatizatzeko scriptak berridatzi ziren, eta DSO azpisistemen migrazioa modu guztiz automatizatuan burutu zen. IP garapenaren ingerada garapen taldeen kanalizazioek birsortu zuten.
Urratsera 4. Aplikazio-softwarearen instalazioaren automatizazioa. Zeregin horiek talde berrietako taldeburuek ezarri zituzten.
Urratsera 5. esplotazioa.
Urruneko sarbidea
Garapen taldeek malgutasun handiena eskatu zuten zirkuituarekin lan egiteko, eta ordenagailu eramangarri pertsonaletatik urruneko sarbidea izateko eskakizuna proiektuaren hasieran planteatu zen. Bankuak jada bazeukan urruneko sarbidea, baina ez zen egokia garatzaileentzat. Kontua da eskemak erabiltzailearen konexioa erabili zuela babestutako VDI batekin. Lantokian posta eta bulegoko pakete bat besterik behar ez zutenentzat egokia zen. Garatzaileek bezero astunak beharko lituzkete, errendimendu handikoak, baliabide askorekin. Eta noski, estatikoak izan behar zuten, VStudio (adibidez) edo beste SDK batekin lan egiten dutenentzat erabiltzailearen saioa galtzea onartezina baita. Garapen talde guztientzako VDI estatiko lodi ugari antolatzeak lehendik zegoen VDI irtenbidearen kostua asko handitu zuen.
Garapen-segmentuko baliabideetara zuzenean urrutiko sarbidea lantzea erabaki genuen. Jira, Wiki, Gitlab, Nexus, eraikitzeko eta probatzeko bankuak, azpiegitura birtualak. Segurtasun zaindariek eskatu dute sarbidea honako kasuetan soilik eman daitekeela:
- Bankuan dagoeneko eskuragarri dauden teknologiak erabiliz.
- Azpiegiturak ez du erabili behar kontu produktiboen objektuen erregistroak gordetzen dituzten domeinu-kontrolagailuak erabili behar.
- Sarbidea talde zehatz batek behar dituen baliabideetara mugatu behar da (produktu-talde batek ezingo du beste talde baten baliabideetara sartu).
- Sistemetan RBAC-en gaineko kontrol handiena.
Ondorioz, domeinu bereizi bat sortu zen segmentu honetarako. Domeinu honek garapen-segmentuko baliabide guztiak biltzen zituen, bai erabiltzailearen kredentzialak bai azpiegiturak. Domeinu honetako erregistroen bizi-zikloa bankuaren lehendik dagoen IdM erabiliz kudeatzen da.
Urruneko sarbide zuzena bankuaren lehendik zegoen ekipamenduaren arabera antolatu zen. Sarbide-kontrola AD taldeetan banatu zen, zeinei testuinguruei buruzko arauak zegozkion (produktu talde bat = arau talde bat).
VM txantiloien kudeaketa
Muntaia eta probaren begizta bat sortzeko abiadura garapen-unitateko buruak ezarritako KPI nagusietako bat da, ingurunea prestatzeko abiadurak zuzenean eragiten baitu kanalizazioaren exekuzio-denbora orokorra. Oinarrizko VM irudiak prestatzeko bi aukera kontuan hartu ziren. Lehenengoa irudien gutxieneko tamainak dira, sistemaren produktu guztien lehenetsiak, bankuaren ezarpenei buruzko politikak gehienez betetzea. Bigarrena oinarrizko irudia da, POPPO astun bat instalatuta dagoena, zeinaren instalazio denborak hodiaren exekuzio-abiaduran eragin handia izan dezakeen.
Azpiegitura eta segurtasun eskakizunak ere kontuan hartu ziren garapenean: irudiak eguneratuta mantentzea (adabakiak, etab.), SIEM-ekin integratzea, bankuko estandarren araberako segurtasun ezarpenak.
Ondorioz, gutxieneko irudiak erabiltzea erabaki zen, eguneratuta edukitzearen kostua gutxitzeko. Askoz errazagoa da oinarrizko OS eguneratzea POPPOren bertsio berrietarako irudi bakoitza adabakitzea baino.
Emaitzetan oinarrituta, beharrezkoa den sistema eragileen gutxieneko multzoen zerrenda osatu zen, eta horien eguneratzea eragiketa-taldeak egiten du, eta kanalizazioko script-ak dira softwarea eguneratzearen ardura osoa, eta behar izanez gero, bertsioa aldatzea. instalatutako softwarearen - transferitu behar den etiketa kanalizaziora. Bai, honek devops produktu-taldeak inplementazio-eszenatoki konplexuagoak izatea eskatzen du, baina oinarrizko irudiak onartzeko behar den denbora operatiboa asko murrizten du, bestela ehun oinarriko VM irudi baino gehiago behar baitituzte mantentzeko.
Interneterako sarbidea
Banku-segurtasunaren beste oztopo bat garapen ingurunetik Interneteko baliabideetarako sarbidea izan zen. Gainera, sarbide hau bi kategoriatan bana daiteke:
- Azpiegituretarako sarbidea.
- Garatzaileentzako sarbidea.
Azpiegituretarako sarbidea Nexus-ekin kanpoko biltegiak proxy eginez antolatu zen. Hau da, makina birtualetatik zuzeneko sarbidea ez zen eman. Horri esker, informazioaren segurtasunarekin konpromezu bat lortzea ahalbidetu zen, garapen-segmentutik kanpoko mundura edozein sarbide ematearen aurka zegoena.
Garatzaileek Interneterako sarbidea behar zuten ageriko arrazoiengatik (stackoverflow). Eta komando guztiek, goian aipatu bezala, zirkuiturako urruneko sarbidea zuten arren, ez da beti komenigarria IDEko bankuko garatzailearen lantokitik ctrl+v egin ezin duzunean.
ISrekin akordioa lortu zen hasieran, proba fasean, sarbidea zerrenda zuri batean oinarritutako banku proxy baten bidez emango dela. Proiektua amaitutakoan, sarbidea zerrenda beltzera pasatuko da. Sarbide-taula erraldoiak prestatu ziren, proiektuaren hasieran atzitu behar ziren baliabide eta biltegi nagusiak adierazten zituztenak. Sarbide hauek koordinatzeak denbora dezente behar izan zuen, eta horri esker, zerrenda beltzeko trantsizio azkarrenean tematzea posible zen.
Findings
Proiektua duela urtebete baino pixka bat gutxiago amaitu zen. Bitxia bada ere, kontratista guztiak pila berrira garaiz aldatu ziren eta inor ez zen utzi automatizazio berriaren ondorioz. IBk ez du iritzi positiboak partekatzeko presarik, baina ez da kexatzen ere, eta hortik ondorioztatu dezakegu gustuko dutela. Gatazkak baretu egin dira, informazioaren segurtasunak berriro kontrolatzen duelako, baina ez ditu garapen prozesuak oztopatzen. Taldeei ardura handiagoa eman zitzaien, eta informazioaren segurtasunarekiko jarrera orokorra hobetu zen. Bankuak ulertu zuen DevSecOps-erako trantsizioa ia saihestezina zela, eta, nire ustez, modurik leunen eta zuzenenean egin zuen.
Alexander Shubin, sistema-arkitektoa.
Iturria: www.habr.com