De bank besteget har projekten út oan in protte oannimmers. "Eksterne" skriuw koade, stjoer dan de resultaten yn in net heul handige foarm. Spesifyk seach it proses der sa út: se hawwe in projekt oerlevere dat funksjonele tests mei har trochmakke, en dêrnei binnen de bankomtrek hifke waard op yntegraasje, load, ensfh. It waard faak ûntdutsen dat tests mislearre. Doe gie alles werom nei de eksterne ûntwikkelder. Lykas jo kinne riede, betsjutte dit lange leadtiden foar bugfixes.
De bank besleat dat it mooglik en nedich wie om de hiele pipeline ûnder syn fleugel te slepen, fan commits oant frijlitting. Sadat alles is unifoarm en ûnder de kontrôle fan de teams ferantwurdlik foar it produkt yn 'e bank. Dat is, as wie de eksterne oannimmer gewoan earne oan it wurk yn 'e folgjende keamer fan it kantoar. Op de bedriuwstapel. Dit is in gewoane devops.
Wêr kaam Sec wei? De feiligens fan de bank hat hege easken steld oan hoe't in eksterne oannimmer wurkje kin yn it netwurksegment, hokker tagong immen hat, hoe en wa mei de koade wurket. It is gewoan dat IB noch net wist dat wannear't oannimmers bûten wurkje, in pear banknormen wurde folge. En dan oer in pear dagen moat elkenien har begjinne te observearjen.
De ienfâldige iepenbiering dat de oannimmer folsleine tagong hie ta de produktkoade hie har wrâld al op 'e kop set.
Op dit stuit begon it ferhaal fan DevSecOps, dêr't ik jo oer fertelle wol.
Hokker praktyske konklúzjes hat de bank lutsen út dizze situaasje?
Der wie in soad kontroverse oer it feit dat alles op 'e ferkearde manier dien wurdt. De ûntwikkelders seine dat feiligens allinich drok is om te bemuoien mei ûntwikkeling, en se, lykas wachters, besykje te ferbieden sûnder te tinken. Op har beurt twivelen feiligensspesjalisten tusken it kiezen tusken de stânpunten: "ûntwikkelders meitsje kwetsberens yn ús circuit" en "ûntwikkelders meitsje gjin kwetsberens, mar binne se sels." It skeel soe in lange tiid trochgean as net foar nije merkeasken en it ûntstean fan it DevSecOps-paradigma. It wie mooglik te ferklearjen dat dizze automatisearring fan prosessen mei rekken hâldend mei de easken foar ynformaasjefeiligens "út 'e doaze" elkenien sil helpe bliid te bliuwen. Yn 'e sin dat de regels fuortendaliks opskreaun wurde en net feroarje tidens it spultsje (de ynformaasjefeiligens sil wat net ûnferwachts ferbiede), en de ûntwikkelders hâlde de ynformaasjefeiligens op 'e hichte oer alles wat bart (de ynformaasjefeiligens komt net ynienen wat tsjin) . Elk team is ek ferantwurdlik foar ultime feiligens, en net guon abstrakte âldere bruorren.
- Om't eksterne meiwurkers al tagong hawwe ta de koade en in oantal ynterne systemen, is it wierskynlik mooglik de eask "ûntwikkeling moat folslein op 'e ynfrastruktuer fan' e bank wurde útfierd út 'e dokuminten."
- Oan 'e oare kant moatte wy de kontrôle fersterkje oer wat der bart.
- It kompromis wie de oprjochting fan cross-funksjonele teams, dêr't meiwurkers wurkje nau gear mei eksterne minsken. Yn dit gefal moatte jo derfoar soargje dat it team wurket oan ark op 'e servers fan' e bank. Fan it begjin oant de ein.
Dat wol sizze, oannimmers kinne ynlitten wurde, mar se moatte aparte segminten krije. Sadat se net in soarte fan besmetting fan bûten yn de ynfrastruktuer fan de bank bringe en dat se net mear sjogge as wat nedich is. No, sadat har aksjes wurde oanmeld. DLP foar beskerming tsjin lekken, dit alles wie opnommen.
Yn prinsipe komme alle banken hjir ier of let. Hjir gongen wy del en ôfpraat oer de easken foar sokke omjouwings dêr't "ekstern" wurkje. D'r ferskynde in maksimale oanbod fan ark foar tagongskontrôle, ark foar kontrôle fan kwetsberens, anty-firusanalyse op circuits, gearkomsten en tests. Dit wurdt DevSecOps neamd.
Ynienen waard dúdlik dat as foardat DevSecOps bankfeiligens gjin kontrôle hie oer wat bart oan 'e kant fan' e ûntwikkelders, dan wurdt yn it nije paradigma feiligens kontrolearre op deselde manier as gewoane eveneminten op 'e ynfrastruktuer. Allinnich no binne der warskôgings oer gearstallingen, kontrôle fan bibleteken, ensfh.
Alles dat bliuwt is de teams oer te dragen nei it nije model. No, meitsje de ynfrastruktuer. Mar dit binne lytse dingen, it is as in ûle tekenje. Eins holpen wy mei de ynfrastruktuer, en op dat stuit feroaren de ûntwikkelingsprosessen.
Wat is feroare
Wy besletten om it yn lytse stappen út te fieren, om't wy begrepen dat in protte prosessen útinoar falle soene, en in protte "eksternen" miskien net by steat wêze om de nije arbeidsbetingsten ûnder tafersjoch fan elkenien te ferneatigjen.
Earst hawwe wy cross-funksjonele teams makke en leard om projekten te organisearjen mei rekkening mei nije easken. Yn 'e betsjutting fan organisatoarysk hawwe wy besprutsen hokker prosessen. It resultaat wie in skema fan de montagepipeline mei alle ferantwurdliken.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Proef: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- Presintaasje (ferslachjouwing, kommunikaasje): Grafana, Kibana, Jira, Confluence, RocketChat.
- Operations (ûnderhâld, behear): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Selektearre stapel:
- Knowledge Base - Atlassian Confluence;
- Taak tracker - Atlassian Jira;
- Artifact repository - "Nexus";
- Trochrinnende yntegraasjesysteem - "Gitlab CI";
- Trochrinnende analyze systeem - "SonarQube";
- Applikaasjefeiligensanalysesysteem - "Micro Focus Fortify";
- Kommunikaasjesysteem - "GitLab Mattermost";
- Konfiguraasjebehearsysteem - "Ansible";
- Tafersjochsysteem - "ELK", "TICK Stack" ("InfluxData").
Se begûnen in team te meitsjen dat ree soe wêze om oannimmers nei binnen te slepen. D'r is in besef dat d'r ferskate wichtige dingen binne:
- Alles moat ferienige wurde, teminsten by it ferstjoeren fan koade. Want der wiene likefolle oannimmers as safolle ferskillende ûntwikkelingsprosessen mei har eigen eigenaardichheden. It wie nedich om elkenien yn likernôch ien te passen, mar mei opsjes.
- D'r binne in protte oannimmers, en hânmjittich oanmeitsjen fan ynfrastruktuer is net geskikt. Elke nije taak moat heul rap begjinne - dat is, it eksimplaar moat hast direkt wurde ynset, sadat ûntwikkelders in set oplossingen hawwe om har pipeline te behearjen.
Om de earste stap te nimmen, wie it nedich om te begripen wat der dien waard. En wy moasten bepale hoe't wy dêr komme. Wy begûnen mei te helpen de arsjitektuer fan 'e doeloplossing te tekenjen sawol yn ynfrastruktuer as CI / CD-automatisearring. Doe begûnen wy mei it gearstallen fan dizze transportband. Wy hiene ien ynfrastruktuer nedich, itselde foar elkenien, wêr't deselde transportbanden rinne. Wy biede opsjes mei berekkeningen, tocht de bank, en besleat doe wat boud wurde soe en mei hokker fûnsen.
Folgjende is de skepping fan it circuit - ynstallaasje fan software, konfiguraasje. Untwikkeling fan skripts foar ynset en behear fan ynfrastruktuer. Dêrnei komt de oergong nei transportbandstipe.
Wy besletten om te testen alles op de pilot. Nijsgjirrich is dat by de piloting foar it earst in bepaalde stapel yn 'e bank ferskynde. Under oaren waard in ynlânske ferkeaper fan ien fan 'e oplossingen oanbean foar de omfang fan' e pilot foar in flugge lansearring. Feiligens learde him te kennen doe't hy pilote, en it liet in ûnferjitlike yndruk efter. Doe't wy besletten om te wikseljen, gelokkich, waard de ynfrastruktuerlaach ferfongen troch in Nutanix-oplossing, dy't earder al yn 'e bank stie. Boppedat wie it foar VDI, mar wy brûkten it opnij foar ynfrastruktuertsjinsten. By lytse folumes paste it net yn 'e ekonomy, mar by grutte folumes waard it in poerbêste omjouwing foar ûntwikkeling en testen.
De rest fan 'e steapel is min of mear bekend foar elkenien. Automatisearring ark yn Ansible waarden brûkt, en feiligens spesjalisten wurken nau gear mei harren. De Atlassin-stapel waard brûkt troch de bank foar it projekt. Fortinet feiligens ark - it waard foarsteld troch de feiligens minsken sels. It testkader is makke troch de bank, gjin fragen steld. It repositorysysteem rôp fragen op; ik moast der oan wenne.
Oannimmers krigen in nije steapel. Se joegen ús tiid om it oer te skriuwen foar GitlabCI, en om Jira te migrearjen nei it banksegment, ensfh.
stap foar stap
Stage 1. Earst brûkten wy in oplossing fan in ynlânske ferkeaper, it produkt waard ferbûn mei in nij makke DSO-netwurksegment. It platfoarm waard keazen foar syn levertiid, skaalfergrutting en de mooglikheid fan folsleine automatisearring. Utfierde tests:
- Mooglikheid fan fleksibele en folslein automatisearre behear fan de virtualization platfoarm ynfrastruktuer (netwurk, skiif subsysteem, Computing boarnen subsysteem).
- Automatisearring fan libbenssyklusbehear fan firtuele masines (sjabloanen, snapshots, backups).
Nei ynstallaasje en basiskonfiguraasje fan it platfoarm waard it brûkt as plak fan pleatsing fan subsystemen fan 'e twadde etappe (DSO-ark, sketsen foar ûntwikkeling fan retailsystemen). De nedige sets pipelines waarden makke - oanmeitsjen, wiskjen, wizigjen, reservekopy fan firtuele masines. Dizze pipelines waarden brûkt as de earste faze fan it ynsetproses.
It resultaat is dat de levere apparatuer net foldocht oan de bank syn easken foar prestaasjes en skuld tolerânsje. De DIT fan 'e bank besleat in kompleks te meitsjen basearre op it Nutanix-softwarepakket.
Stage 2. Wy namen de steapel dat waard definiearre, en skreau automatisearre ynstallaasje en post-konfiguraasje skripts foar alle subsystemen, sadat alles waard oerdroegen fan de pilot nei it doel circuit sa gau as mooglik. Alle systemen waarden ynset yn in flater-tolerante konfiguraasje (dêr't dizze mooglikheid wurdt net beheind troch de ferkeaper syn lisinsje belied) en ferbûn mei metriken en evenemint kolleksje subsystemen. IB analysearre neilibjen fan syn easken en joech grien ljocht.
Stage 3. Migraasje fan alle subsystemen en har ynstellingen nei de nije PAC. Skripten foar automatisearring fan ynfrastruktuer waarden opnij skreaun, en de migraasje fan DSO-subsystemen waard foltôge yn in folslein automatisearre modus. De kontoeren fan IP-ûntwikkeling waarden opnij makke troch de pipelines fan 'e ûntwikkelingsteams.
Stage 4. Automatisearring fan applikaasje software ynstallaasje. Dizze taken waarden ynsteld troch de teamlieders fan de nije teams.
Stage 5. Eksploitaasje.
Tagong op ôfstân
De ûntwikkelingsteams fregen om maksimale fleksibiliteit by it wurkjen mei it sirkwy, en de eask foar tagong op ôfstân fan persoanlike laptops waard oan it begjin fan it projekt ferhege. De bank hie al tagong op ôfstân, mar it wie net geskikt foar ûntwikkelders. It feit is dat it skema de ferbining fan de brûker brûkte mei in beskerme VDI. Dit wie geskikt foar dyjingen dy't allinnich nedich post en in kantoar pakket op harren wurkplak. Untwikkelders soene swiere kliïnten nedich hawwe, hege prestaasjes, mei in protte boarnen. En fansels moasten se statysk wêze, om't it ferlies fan 'e brûkerssesje foar dyjingen dy't wurkje mei VStudio (bygelyks) of oare SDK is net akseptabel. It organisearjen fan in grut oantal dikke statyske VDI's foar alle ûntwikkelingsteams fergrutte de kosten fan 'e besteande VDI-oplossing sterk.
Wy besletten om te wurkjen oan tagong op ôfstân direkt nei de boarnen fan it ûntwikkelingssegment. Jira, Wiki, Gitlab, Nexus, bouwe en testbanken, firtuele ynfrastruktuer. Feiligenswachten hawwe easke dat tagong allinich kin wurde levere ûnder it folgjende:
- Mei help fan technologyen al beskikber yn 'e bank.
- De ynfrastruktuer moat besteande domeincontrollers net brûke dy't records fan produktive akkountobjekten opslaan.
- Tagong moat beheind wurde ta allinich de boarnen dy't nedich binne troch in spesifyk team (sadat ien produktteam gjin tagong hat ta de boarnen fan in oar team).
- Maksimale kontrôle oer RBAC yn systemen.
As resultaat is in apart domein makke foar dit segmint. Dit domein befette alle boarnen foar ûntwikkelingssegmenten, sawol brûkersbewizen as ynfrastruktuer. De libbenssyklus fan records yn dit domein wurdt beheard mei it IdM besteande yn 'e bank.
Direkte tagong op ôfstân waard organisearre op basis fan de besteande apparatuer fan 'e bank. Tagongskontrôle waard ferdield yn AD-groepen, wêrmei regels oer konteksten oerienkomme (ien produktgroep = ien groep regels).
VM Template Management
De snelheid fan it meitsjen fan in gearkomste- en testloop is ien fan 'e wichtichste KPI's ynsteld troch it haad fan' e ûntwikkelingseenheid, om't de snelheid fan it tarieden fan 'e omjouwing direkt ynfloed hat op' e totale útfieringstiid fan 'e pipeline. Twa opsjes foar it tarieden fan basis VM-ôfbyldings waarden beskôge. De earste is de minimale ôfbyldingsgrutte, standert foar alle systeemprodukten, maksimale neilibjen fan it belied fan 'e bank oangeande ynstellings. De twadde is de basisôfbylding, dy't in swiere POPPO ynstalleare befettet, wêrfan de ynstallaasjetiid de útfieringssnelheid fan 'e pipeline sterk kin beynfloedzje.
Ynfrastruktuer en feiligenseasken waarden ek rekken holden by ûntwikkeling - it bywurkjen fan ôfbyldings (patches, ensfh.), Yntegraasje mei SIEM, feiligensynstellingen neffens banknoarmen.
As resultaat waard besletten om minimale ôfbyldings te brûken om de kosten te minimalisearjen om se by de tiid te hâlden. It is folle makliker om it basis-OS te aktualisearjen dan elke ôfbylding te patchjen foar nije ferzjes fan POPPO.
Op grûn fan 'e resultaten waard in list foarme fan' e minimale fereaske set fan bestjoeringssystemen, wêrfan de fernijing wurdt útfierd troch it operaasjeteam, en skripts fan 'e pipeline binne folslein ferantwurdlik foar it bywurkjen fan' e software, en as it nedich is, feroarje de ferzje fan 'e ynstalleare software - ferpleatse gewoan de fereaske tag nei de pipeline. Ja, dit fereasket dat it produktteam fan devops mear komplekse ynsetsenario's hat, mar it ferminderet de operasjonele tiid dy't nedich is om basisôfbyldings te stypjen, dy't oars mear as hûndert basis VM-ôfbyldings nedich binne om te ûnderhâlden.
ynternet tagong
In oar stroffelblok mei bankfeiligens wie tagong ta ynternetboarnen út 'e ûntwikkelingsomjouwing. Boppedat kin dizze tagong wurde ferdield yn twa kategoryen:
- Ynfrastruktuer tagong.
- Untwikkelders tagong.
Ynfrastruktuer tagong waard organisearre troch proxying eksterne repositories mei Nexus. Dat is, direkte tagong fan firtuele masines waard net levere. Dit makke it mooglik om te kommen ta in kompromis mei ynformaasje feiligens, dat wie categorically tsjin it jaan fan eltse tagong ta de bûtenwrâld út de ûntwikkeling segment.
Ûntwikkelers nedich tagong ta it ynternet foar dúdlike redenen (stackoverflow). En hoewol alle kommando's, lykas hjirboppe neamd, hawwe tagong op ôfstân ta it circuit, it is net altyd handich as jo net kinne dwaan ctrl + v fan 'e wurkplak fan' e ûntwikkelder yn 'e bank yn' e IDE.
In oerienkomst waard berikt mei IS dat yn earste ynstânsje, yn it teststadium, tagong sil wurde levere fia in bankproxy basearre op in wite list. Nei it foltôgjen fan it projekt sil tagong wurde oerbrocht nei de swarte list. Enoarme tagongstabellen waarden taret, dy't de haadboarnen en repositories oanjoegen dêr't tagong wie nedich by it begjin fan it projekt. It koördinearjen fan dizze tagongen naam in flinke tiid, wat it mooglik makke om oan te stean op de fluchst mooglike oergong nei swarte listen.
Resultaten
It projekt einige in bytsje minder as in jier lyn. Nuver genôch gongen alle oannimmers op 'e tiid oer nei de nije steapel en der is gjinien fuortgien troch de nije automatisearring. IB hat gjin haast om positive feedback te dielen, mar klaget ek net, wêrfan wy kinne konkludearje dat se it leuk fine. Konflikten binne bedarre om't ynformaasjefeiligens wer yn kontrôle fielt, mar net bemuoit mei ûntwikkelingsprosessen. De teams krigen mear ferantwurdlikens, en de algemiene hâlding foar ynformaasjefeiligens waard better. De bank begriep dat de oergong nei DevSecOps hast net te ûntkommen wie, en die it, nei myn miening, op 'e meast sêfte en korrekte manier.
Alexander Shubin, systeemarsjitekt.
Boarne: www.habr.com