🥇DevOps vs. DevSecOps: Sådan så det ud i én bank

Banken outsourcer sine projekter til mange entreprenører. "Udenforstående" skriver kode og sender derefter resultaterne i en ikke særlig bekvem form. Helt konkret så processen sådan ud: de overførte et projekt, der havde bestået deres funktionelle tests, og derefter blev det testet inden for bankens perimeter for integration, belastning og så videre. Test viste sig ofte at mislykkes. Så gik alt tilbage til den eksterne udvikler. Som du kan forestille dig, betød det en masse tid at rette fejlene.

Banken besluttede, at det var muligt og nødvendigt at trække hele pipelinen "under sine vinger" fra commits til release. Så alt er ensartet og under kontrol af de teams, der er ansvarlige for produktet i banken. Det er, som om den eksterne entreprenør blot arbejdede i det næste rum på kontoret. På virksomhedens stack. Dette er typisk DevOps.

Hvor kom Sec fra? Banksikkerhed har sat høje krav til, hvordan en ekstern leverandør kan arbejde i netværkssegmentet, hvilken adgang nogen har, hvordan og hvem der arbejder med koden. Det er bare det, at IB endnu ikke vidste, at når entreprenører arbejder udendørs, overholdes der få bankstandarder. Og her, om et par dage, skal alle begynde at observere dem.

En simpel afsløring af, at entreprenøren havde fuld adgang til produktkoden, havde allerede vendt op og ned på deres verden.

Det er her, historien om DevSecOps, som jeg gerne vil fortælle jer om, begyndte.

Hvilke praktiske konklusioner drog banken af denne situation?

Der var megen debat om, hvordan tingene blev gjort forkert på dette område. Udviklerne sagde, at sikkerhedspersonalet kun er travlt optaget af at forsøge at forstyrre udviklingen, og de, ligesom sikkerhedsvagter, forsøger at forbyde uden at tænke. Til gengæld tøvede sikkerhedsspecialister mellem at vælge mellem synspunkterne: "udviklere skaber sårbarheder i vores system" og "udviklere skaber ikke sårbarheder, men er dem selv." Debatten ville have fortsat i lang tid, hvis ikke det var for nye markedskrav og fremkomsten af DevSecOps-paradigmet. Det var muligt at forklare, at netop denne automatisering af processer, der tager hensyn til kravene til informationssikkerhed "out of the box", vil hjælpe alle med at forblive tilfredse. Jeg mener, reglerne bliver skrevet ned med det samme og ændrer sig ikke under spillet (IS vil ikke forbyde noget uventet), og udviklerne holder IS informeret om alt, hvad der sker (IS støder ikke på noget pludseligt). Hvert hold er også ansvarlig for den endelige sikkerhed, og ikke nogle abstrakte ældre brødre.

Da eksterne medarbejdere allerede har adgang til koden og en række interne systemer, er det sandsynligvis muligt at fjerne kravet om, at "udviklingen udelukkende skal udføres på bankens infrastruktur" fra dokumenterne.
På den anden side er vi nødt til at styrke kontrollen over, hvad der sker.
Kompromiset var at skabe tværfunktionelle teams, hvor medarbejderne arbejder tæt sammen med eksterne medarbejdere. I dette tilfælde skal du sørge for, at teamet arbejder på værktøjerne på bankens servere. Fra start til slut.

Det vil sige, at entreprenører kan få adgang, men de skal have separate segmenter. Så de ikke bringer en eller anden form for smitte udefra ind i bankens infrastruktur, og så de ikke ser mere end højst nødvendigt. Nå, og så deres handlinger bliver registreret. DLP til beskyttelse mod lækager, alt dette var inkluderet.

I princippet kommer alle banker til dette før eller siden. Her fulgte de den slagne vej og blev enige om krav til sådanne miljøer, hvor "outsidere" arbejder. Der opstod et maksimalt sæt af adgangskontrolværktøjer, sårbarhedstestværktøjer, antivirusanalyse på konturer, på samlinger og test. Dette er det, der blev kaldt DevSecOps.

Det stod pludselig klart, at hvis DevSecOps-banksikkerheden før denne gang ikke havde kontrol over, hvad der skete på udviklerens side, så styres sikkerheden i det nye paradigme på samme måde som almindelige begivenheder på infrastrukturen. Først nu er der advarsler om builds, bibliotekskontrol og så videre.

Alt, der er tilbage, er at overføre kommandoerne til den nye model. Nå, og skabe infrastruktur. Men det er små ting, det er ligesom at tegne en ugle. Faktisk hjalp vi med infrastrukturen, og på det tidspunkt var udviklingsprocesserne ved at ændre sig.

Hvad ændrede sig

Vi besluttede at implementere det i små skridt, fordi vi forstod, at mange processer ville falde fra hinanden, og at mange "udenforstående" måske ikke ville være i stand til at modstå de nye arbejdsforhold under opsyn af alle, der ønskede det.

Først oprettede vi tværfaglige teams og lærte at organisere projekter under hensyntagen til nye krav. I den forstand at vi organisatorisk diskuterede hvilke processer. Resultatet er et diagram over samlerørledningen med alle ansvarlige parter.

CI: 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.
Præsentation (rapportering, kommunikation): Grafana, Kibana, Jira, Confluence, RocketChat.
Produktion (support, administration): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Valgt stak:

Vidensbase - "Atlassisk sammenløb";
Opgavesporing - "Atlassian Jira";
Artefaktarkiv - "Nexus";
Kontinuerligt integrationssystem - "Gitlab CI";
Kontinuerligt analysesystem - "SonarQube";
System til analyse af applikationssikkerhed - "Micro Focus Fortify";
Kommunikationssystem - "GitLab Mattermost";
Konfigurationsstyringssystem - "Ansible";
Overvågningssystem - "ELK", "TICK Stack" ("InfluxData").

Vi begyndte at oprette et hold, der ville være klar til at trække entreprenører indenfor. Der var en erkendelse af, at der var flere vigtige ting:

Alt bør være samlet, i det mindste i kodeoverførslen. Fordi der var lige så mange forskellige udviklingsprocesser med deres egne specifikke karakteristika, som der var entreprenører. Det var nødvendigt at få plads til alle i cirka én, men med muligheder.
Der er mange entreprenører, og manuel oprettelse af infrastruktur er ikke egnet. Enhver ny opgave bør starte meget hurtigt - det vil sige, at instansen bør startes næsten øjeblikkeligt, så udviklerne har et sæt af løsninger til at administrere deres pipeline.

For at tage det første skridt var det nødvendigt at forstå, hvad der blev gjort. Og vi måtte finde ud af, hvordan vi skulle komme derhen. Vi startede med at hjælpe med at tegne arkitekturen for målløsningen, både inden for infrastruktur og CI/CD-automatisering. Så begyndte vi at samle denne transportør. Det, der var behov for, var én infrastruktur, den samme for alle, hvor de samme transportbånd skulle køre. Vi foreslog muligheder med beregninger, banken overvejede det, og traf derefter en beslutning om, hvad der skulle bygges, og med hvilke midler.

Dernæst kommer oprettelsen af kredsløbet - installation af software, konfiguration. Udvikling af scripts til implementering og administration af infrastruktur. Dernæst kommer overgangen til transportbåndsstøtte.

Vi besluttede at teste alt på pilotprojektet. Interessant nok dukkede en bestemt stak op i banken for første gang under pilotafprøvningen. Blandt andet blev en indenlandsk leverandør af en af løsningerne til en hurtig lancering foreslået til pilotprojektet. Sikkerhed lærte ham at kende, mens han var pilot, og det efterlod et uforglemmeligt indtryk. Da vi besluttede at skifte, blev infrastrukturlaget heldigvis erstattet med en Nutanix-løsning, der allerede var i brug i banken. Desuden var det før dette til VDI, og vi genbrugte det til infrastrukturtjenester. Ved små volumener passede det ikke ind i økonomien, men ved store volumener blev det et fremragende miljø for udvikling og testning.

Resten af stakken er mere eller mindre velkendt for alle. Der blev anvendt automatiseringsværktøjer i Ansible-delen, og sikkerhedsspecialister arbejdede tæt sammen med dem. Atlassian-stakken blev brugt af banken før projektet. Fortinet sikkerhedsværktøjer - det blev foreslået af sikkerhedseksperterne selv. Testrammen blev skabt af banken, uden spørgsmål. Repository-systemet rejste spørgsmål, og jeg måtte vænne mig til det.

Entreprenørerne fik en ny skorsten. De gav os tid til at omskrive det til GitlabCI, og til at migrere Jira til banksegmentet, og så videre.

Trin for trin

Trin 1. I starten brugte vi en løsning fra en indenlandsk leverandør; Produktet blev skiftet til et nyoprettet DSO-netværkssegment. Platformen blev valgt ud fra leveringstider, fleksibilitet i skalering og muligheden for fuld automatisering. Der blev udført tests:

Mulighed for fleksibel og fuldt automatiseret styring af virtualiseringsplatformens infrastruktur (netværk, diskundersystem, computerressourceundersystem).
Automatisering af livscyklusstyring virtuel maskine (skabeloner, snapshots, sikkerhedskopier).

Efter installation og grundlæggende konfiguration af platformen blev den brugt som placeringspunkt for delsystemerne i anden fase (DSO-værktøjer, systemudviklingsframeworks til detailhandel). De nødvendige sæt af pipelines blev oprettet - oprettelse, sletning, ændring, sikkerhedskopiering af virtuelle maskiner. Disse pipelines blev brugt som det første trin i implementeringsprocessen.

Resultatet er, at det leverede udstyr ikke opfylder bankens krav til ydeevne og fejltolerance. Bankens DIT har besluttet at oprette et kompleks baseret på Nutanix PAC.

Trin 2. Vi tog den definerede stak og skrev automatiserede installations- og efterkonfigurationsscripts til alle undersystemer, så alt kunne overføres fra piloten til målkredsløbet så hurtigt som muligt. Alle systemer blev implementeret i en fejlsikker konfiguration (hvor denne funktion ikke er begrænset af leverandørens licenspolitikker) og forbundet til undersystemer til metrikker og hændelsesindsamling. IB analyserede overholdelsen af sine krav og gav grønt lys.

Trin 3. Migrering af alle undersystemer og deres indstillinger til den nye PAC. Infrastrukturens automatiseringsscripts blev omskrevet, og migreringen af DSO-undersystemer blev udført i en fuldautomatisk tilstand. Konturerne af IS-udviklingen blev genskabt af udviklingsteamenes pipelines.

Trin 4. Automatisering af installation af applikationssoftware. Disse opgaver blev fastsat af teamlederne for de nye teams.

Trin 5. Udnyttelse.

Fjernadgang

Udviklingsteamene efterspurgte maksimal fleksibilitet i arbejdet med dispositionen, og kravet om fjernadgang fra personlige bærbare computere blev fastsat helt i begyndelsen af projektet. Banken havde allerede fjernadgang, men det var ikke egnet for udviklere. Sagen er, at ordningen brugte en brugerforbindelse til en sikker VDI. Dette var velegnet til dem, der havde nok post og en kontorpakke på deres arbejdsplads. Udviklere ville have brug for tunge klienter, højtydende, med masser af ressourcer. Og selvfølgelig skulle de være statiske, da det er uacceptabelt at miste brugersessionen for dem, der arbejder med VStudio (for eksempel) eller et andet SDK. At tilbyde et stort antal tykke statiske VDI'er til alle udviklingsteams øgede omkostningerne ved den eksisterende VDI-løsning betydeligt.

Vi besluttede at arbejde med fjernadgang direkte til ressourcerne i udviklingssegmentet. Jira, Wiki, Gitlab, Nexus, bygge- og teststande, virtuel infrastruktur. Sikkerhedspersonalet har fastsat krav om, at adgang kun kan gives, hvis følgende er opfyldt:

Brug af teknologier, der allerede er tilgængelige i banken.
Infrastrukturen bør ikke bruge eksisterende domæne- controllere, der lagrer poster over produktive regnskabsobjekter.
Adgang bør begrænses til kun de ressourcer, der kræves af et specifikt team (så ét produktteam ikke kan få adgang til et andet teams ressourcer).
Maksimal kontrol over RBAC i systemer.

Som følge heraf blev der oprettet et separat domæne til dette segment. Dette domæne indeholdt alle udviklingssegmentets ressourcer, både brugerlegitimationsoplysninger og infrastruktur. Livscyklussen for poster i dette domæne styres ved hjælp af bankens eksisterende IdM.

Direkte fjernadgang blev organiseret på basis af bankens eksisterende udstyr. Adgangskontrollen blev fordelt på tværs af AD-grupper, hvilket svarede til regler for kontekster (én produktgruppe = én regelgruppe).

Administration af VM-skabeloner

Hastigheden for oprettelse af bygge- og testkredsløbet er en af de vigtigste KPI'er, der sættes af lederen af udviklingsenheden, fordi hastigheden for forberedelse af miljøet direkte påvirker pipelinens samlede udførelsestid. To muligheder for at forberede basis-VM-billeder blev overvejet. Den første er den minimale billedstørrelse, standard for alle produktsystemer, maksimal overholdelse af bankens indstillingspolitikker. Det andet er et basisbillede, der indeholder en kraftig POPPO installeret, hvis installationstid i høj grad kan påvirke hastigheden af pipeline-udførelsen.

Der blev også taget højde for infrastruktur- og sikkerhedskrav under udviklingen - vedligeholdelse af images opdateret (patches osv.), integration med SIEM, sikkerhedsindstillinger i henhold til bankens accepterede standarder.

I sidste ende blev det besluttet at bruge minimale billeder for at minimere omkostningerne ved at holde dem opdaterede. Det er meget nemmere at opdatere basis-OS'et end at opdatere hvert image til nye versioner af POPPO.

Baseret på resultaterne blev der dannet en liste ud fra det minimum krævede sæt af operativsystemer, hvis opdatering udføres af driftsteamet, og scripts fra pipelinen er fuldt ansvarlige for opdateringen af POPPO, og hvis det er nødvendigt at ændre versionen af den installerede software, er det nok at overføre det nødvendige tag til pipelinen. Ja, dette kræver mere komplekse implementeringsscenarier fra produktteamets devops, men det reducerer driftstiden til understøttelse af basisbilleder betydeligt, som ellers kunne være belastet med at vedligeholde mere end hundrede basis-VM-billeder.

Internetadgang

En anden hindring for banksikkerhed var adgang fra udviklingsmiljøet til internetressourcer. Desuden kan denne adgang opdeles i to kategorier:

Adgang til infrastruktur.
Adgang for udviklere.

Adgang til infrastruktur blev organiseret ved at proxy-koble eksterne lagre til Nexus. Det vil sige, at der ikke blev leveret direkte adgang fra virtuelle maskiner. Dette gjorde det muligt at nå et kompromis med IB, som var kategorisk imod at give enhver adgang til omverdenen fra udviklingssegmentet.

Udviklere havde brug for adgang til internettet af åbenlyse årsager (stackoverflow). Og selvom alle teams, som nævnt ovenfor, havde fjernadgang til kredsløbet, er det ikke altid praktisk, når man ikke kan bruge ctrl+v i IDE'en fra udviklerens arbejdsplads i banken.

Der blev indgået en aftale med informationssikkerhedstjenesten om, at adgangen i første omgang, i testfasen, ville blive givet via en bankproxy baseret på en hvidliste. Ved projektets afslutning vil adgangen blive overført til sortlisten. Der blev udarbejdet store adgangstabeller, som angav de vigtigste ressourcer og lagre, der skulle have adgang til i starten af projektet. Koordinering af adgangsdata tog en anstændig mængde tid, hvilket gjorde det muligt for os at insistere på den hurtigst mulige overgang til sortlister.

Fund

Projektet sluttede for knap et år siden. Mærkeligt nok skiftede alle entreprenører til den nye skorsten til tiden, og ingen forlod stedet på grund af den nye automatisering. IB har ikke travlt med at dele positive anmeldelser, men klager heller ikke, hvoraf vi kan konkludere, at de kan lide det. Konflikterne er aftaget, fordi IB føler sig i kontrol igen, men samtidig ikke blander sig i udviklingsprocesser. Teamene fik mere ansvar, og den generelle holdning til informationssikkerhed blev forbedret. Banken forstod, at overgangen til DevSecOps var nærmest uundgåelig, og gjorde det efter min mening på den mest skånsomme og korrekte måde.