DevOps vs DevSecOps: hoe dit gelyk het in een bank

Die bank kontrakteer sy projekte aan baie kontrakteurs uit. "Eksterne" skryf kode, stuur dan die resultate in 'n nie baie gerieflike vorm. Spesifiek, die proses het so gelyk: hulle het 'n projek oorhandig wat funksionele toetse saam met hulle geslaag het, en toe binne die bankomtrek getoets is vir integrasie, vrag, ensovoorts. Daar is dikwels ontdek dat toetse misluk. Toe is alles terug na die eksterne ontwikkelaar. Soos u kan raai, het dit lang leitye vir foutoplossings beteken.

Die bank het besluit dit is moontlik en nodig om die hele pyplyn onder sy vlerk te sleep, van commits tot release. Sodat alles eenvormig en onder beheer is van die spanne wat verantwoordelik is vir die produk in die bank. Dit wil sê asof die eksterne kontrakteur bloot êrens in die volgende vertrek van die kantoor gewerk het. Op die korporatiewe stapel. Dit is 'n gewone devops.

Waar het Sec vandaan gekom? Die bank se sekuriteit het hoë eise gestel oor hoe ’n eksterne kontrakteur in die netwerksegment kan werk, watter toegang iemand het, hoe en wie met die kode werk. Dit is net dat IB nog nie geweet het dat wanneer kontrakteurs buite werk, min bankstandaarde gevolg word nie. En dan oor 'n paar dae moet almal hulle begin waarneem.

Die eenvoudige onthulling dat die kontrakteur volle toegang tot die produkkode gehad het, het reeds hul wêreld omgekeer.

Op hierdie oomblik het die storie van DevSecOps begin, waarvan ek jou wil vertel.

Watter praktiese gevolgtrekkings het die bank uit hierdie situasie gemaak?

Daar was baie omstredenheid oor die feit dat alles op die verkeerde manier gedoen word. Die ontwikkelaars het gesê dat sekuriteit net besig is om te probeer inmeng met ontwikkeling, en hulle, soos wagte, probeer om te verbied sonder om te dink. Op hul beurt het sekuriteitspesialiste gehuiwer tussen die keuses tussen die standpunte: "ontwikkelaars skep kwesbaarhede in ons kring" en "ontwikkelaars skep nie kwesbaarhede nie, maar is hulle self." Die dispuut sou vir 'n lang tyd voortgeduur het as nie vir nuwe markvereistes en die opkoms van die DevSecOps-paradigma nie. Dit was moontlik om te verduidelik dat hierdie einste outomatisering van prosesse met inagneming van inligtingsekuriteitsvereistes "uit die boks" almal sal help om gelukkig te bly. In die sin dat die reëls onmiddellik neergeskryf word en nie tydens die speletjie verander nie (die inligtingsekuriteit sal iets nie onverwags verbied nie), en die ontwikkelaars hou die inligtingsekuriteit op hoogte van alles wat gebeur (die inligtingsekuriteit kom nie skielik iets teë nie). . Elke span is ook verantwoordelik vir uiteindelike veiligheid, en nie sommige abstrakte ouer broers nie.

1. Aangesien eksterne werknemers reeds toegang tot die kode en 'n aantal interne stelsels het, is dit waarskynlik moontlik om die vereiste “ontwikkeling volledig op die bank se infrastruktuur uitgevoer te word” uit die dokumente te verwyder.
2. Aan die ander kant moet ons beheer versterk oor wat gebeur.
3. Die kompromie was die skepping van kruisfunksionele spanne, waar werknemers nou saamwerk met eksterne mense. In hierdie geval moet u seker maak dat die span aan gereedskap op die bank se bedieners werk. Van die begin tot die einde.

Dit wil sê, kontrakteurs kan toegelaat word, maar hulle moet aparte segmente kry. Sodat hulle nie een of ander infeksie van buite in die bank se infrastruktuur inbring nie en sodat hulle nie meer sien as wat nodig is nie. Wel, sodat hul aksies aangeteken word. DLP vir beskerming teen lekkasies, dit alles is ingesluit.

In beginsel kom alle banke vroeër of later hiertoe. Hier het ons op die gebaande pad gegaan en ooreengekom oor die vereistes vir sulke omgewings waar “eksterne” werk. Daar het 'n maksimum reeks toegangsbeheerinstrumente, nutsmiddels vir kwesbaarheidkontrolering, antivirusanalise op stroombane, samestellings en toetse verskyn. Dit word DevSecOps genoem.

Skielik het dit duidelik geword dat as banksekuriteit voor DevSecOps geen beheer gehad het oor wat aan die ontwikkelaar se kant gebeur nie, dan word sekuriteit in die nuwe paradigma op dieselfde manier beheer as gewone gebeure op die infrastruktuur. Eers nou is daar waarskuwings oor samestellings, beheer van biblioteke, ensovoorts.

Al wat oorbly is om die spanne na die nuwe model oor te plaas. Wel, skep die infrastruktuur. Maar dit is kleinighede, dit is soos om 'n uil te teken. Eintlik het ons gehelp met die infrastruktuur, en op daardie stadium was die ontwikkelingsprosesse besig om te verander.

Wat het verander

Ons het besluit om dit in klein stappe te implementeer, want ons het verstaan ​​dat baie prosesse uitmekaar sou val, en baie “eksterne” dalk nie die nuwe werksomstandighede onder toesig van almal kan weerstaan ​​nie.

Eerstens het ons kruisfunksionele spanne geskep en geleer om projekte te organiseer met inagneming van nuwe vereistes. In die sin van organisatories het ons bespreek watter prosesse. Die resultaat was 'n diagram van die monteerpyplyn met almal wat verantwoordelik was.

• GI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• toets: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
• aanbieding (verslaggewing, kommunikasie): Grafana, Kibana, Jira, Confluence, RocketChat.
• bedrywighede (instandhouding, bestuur): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Diensbestuurder, Jira, Confluence, MS Project.

Geselekteerde stapel:

• Kennisbasis - Atlassiese samevloeiing;
• Taakspoorder - Atlassian Jira;
• Artefakbewaarplek - "Nexus";
• Deurlopende integrasiestelsel - "Gitlab CI";
• Deurlopende analise stelsel - "SonarQube";
• Toepassing sekuriteit analise stelsel - "Micro Focus Fortify";
• Kommunikasiestelsel - "GitLab Mattermost";
• Konfigurasiebestuurstelsel - "Ansible";
• Moniteringstelsel - “ELK”, “TICK Stack” (“InfluxData”).

Hulle het begin om 'n span te skep wat gereed sou wees om kontrakteurs na binne te sleep. Daar is 'n besef dat daar verskeie belangrike dinge is:

• Alles moet verenig word, ten minste wanneer kode oorgedra word. Omdat daar soveel kontrakteurs was as wat daar soveel verskillende ontwikkelingsprosesse met hul eie eienaardighede was. Dit was nodig om almal in ongeveer een in te pas, maar met opsies.
• Daar is baie kontrakteurs, en handmatige skepping van infrastruktuur is nie geskik nie. Enige nuwe taak moet baie vinnig begin - dit wil sê, die instansie moet byna onmiddellik ontplooi word, sodat ontwikkelaars 'n stel oplossings het om hul pyplyn te bestuur.

Om die eerste stap te neem, was dit nodig om te verstaan ​​wat gedoen word. En ons moes bepaal hoe om daar te kom. Ons het begin deur te help om die argitektuur van die teikenoplossing te teken, beide in infrastruktuur en CI/CD-outomatisering. Toe begin ons hierdie vervoerband monteer. Ons het een infrastruktuur nodig gehad, dieselfde vir almal, waar dieselfde vervoerbande sou loop. Ons het opsies met berekeninge aangebied, het die bank gedink en toe besluit wat gebou gaan word en met watter fondse.

Volgende is die skepping van die kring - installering van sagteware, konfigurasie. Ontwikkeling van skrifte vir infrastruktuur-ontplooiing en bestuur. Volgende kom die oorgang na vervoerbandondersteuning.

Ons het besluit om alles op die vlieënier te toets. Interessant genoeg, tydens die loodsing het 'n sekere stapel vir die eerste keer in die bank verskyn. 'n Binnelandse verkoper van een van die oplossings is onder meer aangebied vir die omvang van die loods vir 'n vinnige bekendstelling. Sekuriteit het hom leer ken terwyl hy gevlieg het, en dit het 'n onvergeetlike indruk gelaat. Toe ons besluit om oor te skakel, is die infrastruktuurlaag gelukkig vervang met 'n Nutanix-oplossing, wat reeds voorheen in die bank was. Boonop was dit voorheen vir VDI, maar ons het dit vir infrastruktuurdienste hergebruik. By klein volumes het dit nie in die ekonomie ingepas nie, maar by groot volumes het dit 'n uitstekende omgewing vir ontwikkeling en toetsing geword.

Die res van die stapel is min of meer bekend aan almal. Outomatiseringsnutsmiddels in Ansible is gebruik, en sekuriteitspesialiste het nou saam met hulle gewerk. Die Atlassin-stapel is voor die projek deur die bank gebruik. Fortinet-sekuriteitsinstrumente – dit is deur die sekuriteitsmense self voorgestel. Die toetsraamwerk is deur die bank geskep, geen vrae gevra nie. Die bewaarplekstelsel het vrae laat ontstaan; ek moes daaraan gewoond raak.

Kontrakteurs het 'n nuwe stapel gekry. Hulle het ons tyd gegee om dit vir GitlabCI te herskryf, en om Jira na die banksegment te migreer, ensovoorts.

stap vir stap

Stadium 1. Eerstens het ons 'n oplossing van 'n binnelandse verkoper gebruik, die produk is gekoppel aan 'n nuwe geskepde DSO-netwerksegment. Die platform is gekies vir sy afleweringstyd, skaalbuigsaamheid en die moontlikheid van volle outomatisering. Toetse uitgevoer:

• Moontlikheid van buigsame en ten volle outomatiese bestuur van die virtualiseringsplatform-infrastruktuur (netwerk, skyfsubstelsel, rekenaarhulpbronsubstelsel).
• Outomatisering van virtuele masjien lewensiklusbestuur (sjabloon, foto's, rugsteun).

Na die installering en basiese konfigurasie van die platform, is dit gebruik as die plasingspunt van die tweede fase substelsels (DSO-gereedskap, kleinhandelstelselontwikkelingsuitsigte). Die nodige stelle pyplyne is geskep - skepping, verwydering, wysiging, rugsteun van virtuele masjiene. Hierdie pypleidings is as die eerste fase van die ontplooiingsproses gebruik.

Die gevolg is dat die verskafde toerusting nie aan die bank se vereistes vir prestasie en foutverdraagsaamheid voldoen nie. Die bank se DIT het besluit om 'n kompleks te skep wat op die Nutanix-sagtewarepakket gebaseer is.

Stadium 2. Ons het die stapel wat gedefinieer is geneem en geoutomatiseerde installasie- en na-konfigurasie skrifte vir alle substelsels geskryf sodat alles so vinnig as moontlik van die vlieënier na die teikenkring oorgedra is. Alle stelsels is in 'n foutverdraagsame opset ontplooi (waar hierdie vermoë nie deur die verskaffer se lisensiëringsbeleide beperk word nie) en gekoppel aan statistieke en substelsels vir gebeurtenisversameling. IB het voldoening aan sy vereistes ontleed en die groen lig gegee.

Stadium 3. Migrasie van alle substelsels en hul instellings na die nuwe PAC. Infrastruktuur-outomatiseringsskrifte is herskryf, en die migrasie van DSO-substelsels is in 'n ten volle outomatiese modus voltooi. Die kontoere van IP-ontwikkeling is herskep deur die pyplyne van die ontwikkelingspanne.

Stadium 4. Outomatisering van toepassing sagteware installasie. Hierdie take is deur die spanleiers van die nuwe spanne opgestel.

Stadium 5. Uitbuiting.

Afstand toegang

Die ontwikkelingspanne het gevra vir maksimum buigsaamheid om met die kring te werk, en die vereiste vir afstandtoegang vanaf persoonlike skootrekenaars is heel aan die begin van die projek geopper. Die bank het reeds afstandtoegang gehad, maar dit was nie geskik vir ontwikkelaars nie. Die feit is dat die skema die gebruiker se verbinding met 'n beskermde VDI gebruik het. Dit was geskik vir diegene wat net pos en 'n kantoorpakket by hul werkplek nodig gehad het. Ontwikkelaars sal swaar kliënte nodig hê, hoë werkverrigting, met baie hulpbronne. En natuurlik moes hulle staties wees, aangesien die verlies van die gebruikersessie vir diegene wat met VStudio (byvoorbeeld) of ander SDK werk, onaanvaarbaar is. Die organisering van 'n groot aantal dik statiese VDI's vir alle ontwikkelingspanne het die koste van die bestaande VDI-oplossing aansienlik verhoog.

Ons het besluit om direk aan afstandtoegang tot die hulpbronne van die ontwikkelingsegment te werk. Jira, Wiki, Gitlab, Nexus, bou en toets banke, virtuele infrastruktuur. Sekuriteitswagte het geëis dat toegang slegs verskaf kan word onderhewig aan die volgende:

1. Gebruik tegnologie wat reeds in die bank beskikbaar is.
2. Die infrastruktuur moet nie bestaande domeinbeheerders gebruik wat rekords van produktiewe rekeningobjekte stoor nie.
3. Toegang moet beperk word tot slegs daardie hulpbronne wat deur 'n spesifieke span vereis word (sodat een produkspan nie toegang tot 'n ander span se hulpbronne kan kry nie).
4. Maksimum beheer oor RBAC in stelsels.

Gevolglik is 'n aparte domein vir hierdie segment geskep. Hierdie domein het alle ontwikkelingsegmenthulpbronne gehuisves, beide gebruikersbewyse en infrastruktuur. Die lewensiklus van rekords in hierdie domein word bestuur deur die bank se bestaande IdM te gebruik.

Direkte afstandtoegang is georganiseer op grond van die bank se bestaande toerusting. Toegangsbeheer is in AD-groepe verdeel, waarmee reëls oor kontekste ooreenstem (een produkgroep = een groep reëls).

VM-sjabloonbestuur

Die spoed van die skep van 'n samestelling en toetslus is een van die hoof KPI's wat deur die hoof van die ontwikkelingseenheid gestel word, omdat die spoed van voorbereiding van die omgewing die algehele uitvoeringstyd van die pyplyn direk beïnvloed. Twee opsies vir die voorbereiding van basis-VM-beelde is oorweeg. Die eerste is die minimum beeldgroottes, verstek vir alle stelselprodukte, maksimum nakoming van die bank se beleid rakende instellings. Die tweede is die basisbeeld, wat 'n swaardiens-POPPO bevat wat geïnstalleer is, waarvan die installasietyd die uitvoeringspoed van die pyplyn grootliks kan beïnvloed.

Infrastruktuur- en sekuriteitsvereistes is ook in ag geneem tydens ontwikkeling – hou beelde op datum (patches, ens.), integrasie met SIEM, sekuriteitsinstellings volgens bankstandaarde.

As gevolg hiervan is besluit om minimale beelde te gebruik om die koste om dit op datum te hou, te minimaliseer. Dit is baie makliker om die basis-bedryfstelsel op te dateer as om elke prent vir nuwe weergawes van POPPO te pleister.

Op grond van die resultate is 'n lys gevorm van die minimum vereiste stel bedryfstelsels, waarvan die opdatering deur die bedryfspan uitgevoer word, en skrifte van die pyplyn is heeltemal verantwoordelik vir die opdatering van die sagteware, en indien nodig, verander die weergawe van die geïnstalleerde sagteware - dra net die vereiste merker oor na die pyplyn. Ja, dit vereis dat die devops-produkspan meer komplekse ontplooiingscenario's moet hê, maar dit verminder aansienlik die operasionele tyd wat nodig is om basisbeelde te ondersteun, wat andersins meer as honderd basis-VM-beelde kan verg om in stand te hou.

Internettoegang

Nog 'n struikelblok met banksekuriteit was toegang tot internetbronne vanuit die ontwikkelingsomgewing. Boonop kan hierdie toegang in twee kategorieë verdeel word:

1. Toegang tot infrastruktuur.
2. Ontwikkelaar toegang.

Infrastruktuurtoegang is georganiseer deur eksterne bewaarplekke met Nexus in te stel. Dit wil sê, direkte toegang vanaf virtuele masjiene is nie verskaf nie. Dit het dit moontlik gemaak om 'n kompromie te bereik met inligtingsekuriteit, wat kategories teen die verskaffing van enige toegang tot die buitewêreld vanuit die ontwikkelingsegment was.

Ontwikkelaars het om ooglopende redes toegang tot die internet nodig gehad (stackoverflow). En alhoewel alle opdragte, soos hierbo genoem, afstandtoegang tot die stroombaan gehad het, is dit nie altyd gerieflik wanneer jy nie ctrl+v vanaf die ontwikkelaar se werkplek in die bank in die IDE kan doen nie.

'n Ooreenkoms is met IS bereik dat aanvanklik, in die toetsstadium, toegang verskaf sal word deur 'n bankvolmag gebaseer op 'n witlys. Na voltooiing van die projek sal toegang na die swartlys oorgedra word. Groot toegangstabelle is voorberei, wat die hoofbronne en bewaarplekke aangedui het waartoe toegang vereis word aan die begin van die projek. Die koördinering van hierdie toegang het 'n redelike hoeveelheid tyd geneem, wat dit moontlik gemaak het om aan te dring op die vinnigste moontlike oorgang na swartlyste.

Bevindinge

Die projek het 'n bietjie minder as 'n jaar gelede geëindig. Vreemd genoeg het alle kontrakteurs betyds na die nuwe stapel oorgeskakel en niemand het weggegaan nie weens die nuwe outomatisering. IB is nie haastig om positiewe terugvoer te deel nie, maar kla ook nie, waaruit ons kan aflei dat hulle daarvan hou. Konflikte het bedaar omdat inligtingsekuriteit weer in beheer voel, maar nie met ontwikkelingsprosesse inmeng nie. Die spanne het meer verantwoordelikheid gekry, en die algehele houding teenoor inligtingsekuriteit het beter geword. Die bank het verstaan ​​dat die oorgang na DevSecOps byna onvermydelik was, en het dit na my mening op die mees sagte en korrekte manier gedoen.

Alexander Shubin, stelselargitek.

Bron: will.com