Banken outsourcer sine projekter til mange entreprenører. "Eksterne" skriver kode, og send derefter resultaterne i en ikke særlig bekvem form. Helt konkret så processen sådan ud: De afleverede et projekt, der bestod funktionelle tests med dem, og derefter blev testet inde i bankomkredsen for integration, belastning og så videre. Det blev ofte opdaget, at prøver mislykkedes. Så gik alt tilbage til den eksterne udvikler. Som du kan gætte, betød dette lange gennemløbstider for fejlrettelser.
Banken besluttede, at det var muligt og nødvendigt at trække hele rørledningen 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 vil sige, som om den eksterne entreprenør simpelthen arbejdede et sted i det næste rum på kontoret. På virksomhedens stak. Dette er en almindelig devops.
Hvor kom Sec fra? Bankens sikkerhed har stillet høje krav til, hvordan en ekstern entreprenør kan arbejde i netværkssegmentet, hvilken adgang nogen har, hvordan og hvem der arbejder med koden. Det er bare, at IB endnu ikke vidste, at når entreprenører arbejder udenfor, er få bankstandarder fulgt. Og om et par dage skal alle begynde at observere dem.
Den simple afsløring af, at entreprenøren havde fuld adgang til produktkoden, havde allerede vendt op og ned på deres verden.
I dette øjeblik begyndte historien om DevSecOps, som jeg vil fortælle dig om.
Hvilke praktiske konklusioner trak banken af denne situation?
Der var meget uenighed om, at alt bliver gjort på den forkerte måde. Udviklerne sagde, at sikkerhed kun er travlt med at forsøge at forstyrre udviklingen, og de forsøger ligesom vagtmænd at forbyde uden at tænke. Til gengæld tøvede sikkerhedsspecialister mellem at vælge mellem synspunkterne: "udviklere skaber sårbarheder i vores kredsløb" og "udviklere skaber ikke sårbarheder, men er dem selv." Tvisten ville have varet længe, hvis ikke nye markedskrav og fremkomsten af DevSecOps-paradigmet havde været. Det var muligt at forklare, at netop denne automatisering af processer under hensyntagen til krav til informationssikkerhed "ud af boksen" vil hjælpe alle til at forblive glade. I den forstand, at reglerne skrives ned med det samme og ikke ændres under spillet (informationssikkerheden vil ikke forbyde noget uventet), og udviklerne holder informationssikkerheden informeret om alt, hvad der sker (informationssikkerheden støder ikke på noget pludseligt) . Hvert hold er også ansvarlig for den ultimative sikkerhed, og ikke nogle abstrakte ældre brødre.
- Da eksterne medarbejdere i forvejen har adgang til koden og en række interne systemer, er det formentlig muligt at fjerne kravet om, at "udvikling skal ske helt på bankens infrastruktur" fra dokumenterne.
- På den anden side skal vi styrke kontrollen med, hvad der sker.
- Kompromiset var skabelsen af tværgående teams, hvor medarbejderne arbejder tæt sammen med eksterne mennesker. I dette tilfælde skal du sikre dig, at teamet arbejder på værktøjer på bankens servere. Fra begyndelsen til slutningen.
Det vil sige, at entreprenører kan få adgang, men de skal have separate segmenter. Så de ikke bringer en form for smitte udefra ind i bankens infrastruktur, og så de ikke ser mere end nødvendigt. Nå, så deres handlinger bliver logget. DLP til beskyttelse mod lækager, alt dette var inkluderet.
I princippet kommer alle banker til dette før eller siden. Her gik vi ad den slagne vej og blev enige om kravene til sådanne miljøer, hvor "eksterne" arbejder. Der dukkede et maksimalt udvalg af adgangskontrolværktøjer op, værktøjer til kontrol af sårbarhed, antivirusanalyse på kredsløb, samlinger og tests. Dette kaldes DevSecOps.
Pludselig blev det klart, at hvis før DevSecOps banksikkerhed ikke havde kontrol over, hvad der sker på udviklerens side, så styres sikkerheden i det nye paradigme på samme måde som almindelige hændelser på infrastrukturen. Først nu er der advarsler om samlinger, kontrol af biblioteker og så videre.
Tilbage er kun at overføre holdene til den nye model. Nå, skab infrastrukturen. Men det er bagateller, det er som at tegne en ugle. Faktisk hjalp vi med infrastrukturen, og på det tidspunkt var udviklingsprocesserne under forandring.
Hvad har ændret sig
Vi besluttede at implementere det i små trin, fordi vi forstod, at mange processer ville falde fra hinanden, og mange "eksterne" ville måske ikke kunne modstå de nye arbejdsforhold under opsyn af alle.
Først skabte vi tværfunktionelle teams og lærte at organisere projekter under hensyntagen til nye krav. I betydningen organisatorisk diskuterede vi hvilke processer. Resultatet blev et diagram over samlerøret med alle de ansvarlige.
- CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Test: Sonarqube, SoapUI, jMeter, Selen: MF Fortify, Performance Center, MF UFT, Ataccama.
- Præsentation (rapportering, kommunikation): Grafana, Kibana, Jira, Confluence, RocketChat.
- Produktion (vedligeholdelse, ledelse): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Valgt stak:
- Vidensbase - Atlassian Confluence;
- Opgavesporing - Atlassian Jira;
- Artefaktlager - "Nexus";
- Kontinuerligt integrationssystem - "Gitlab CI";
- Kontinuerligt analysesystem - "SonarQube";
- Applikationssikkerhedsanalysesystem - "Micro Focus Fortify";
- Kommunikationssystem - "GitLab Mattermost";
- Konfigurationsstyringssystem - "Ansible";
- Overvågningssystem - "ELK", "TICK Stack" ("InfluxData").
De begyndte at skabe et hold, der ville være klar til at trække entreprenører indenfor. Der er en erkendelse af, at der er flere vigtige ting:
- Alt bør forenes, i det mindste når der sendes kode. For der var lige så mange entreprenører, som der var så mange forskellige udviklingsprocesser med deres egne særheder. Det var nødvendigt at passe alle ind 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 skal installeres næsten øjeblikkeligt, så udviklere har et sæt 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 var nødt til at bestemme, hvordan vi skulle komme dertil. Vi startede med at være med til at tegne målløsningens arkitektur både inden for infrastruktur og CI/CD-automatisering. Så begyndte vi at samle denne transportør. Vi havde brug for én infrastruktur, ens for alle, hvor de samme transportører ville køre. Vi tilbød muligheder med beregninger, mente banken, og besluttede så, hvad der skulle bygges og med hvilke midler.
Næste er oprettelsen af kredsløbet - installation af software, konfiguration. Udvikling af scripts til udrulning og administration af infrastruktur. Dernæst kommer overgangen til transportbåndsstøtte.
Vi besluttede at teste alt på piloten. Interessant nok, under piloteringen, dukkede en bestemt stak op i banken for første gang. Blandt andet blev en indenlandsk leverandør af en af løsningerne tilbudt som pilotformål for en hurtig lancering. Sikkerheden lærte ham at kende, mens han piloterede, og det efterlod et uforglemmeligt indtryk. Da vi besluttede at skifte, blev infrastrukturlaget heldigvis udskiftet med en Nutanix-løsning, som allerede var i banken før. Desuden var det før det til VDI, men vi genbrugte det til infrastrukturtjenester. Ved små mængder passede det ikke ind i økonomien, men ved store mængder blev det et glimrende miljø for udvikling og test.
Resten af stakken er mere eller mindre kendt for alle. Der blev brugt automationsværktøjer i Ansible, og sikkerhedsspecialister arbejdede tæt sammen med dem. Atlassin-stakken blev brugt af banken før projektet. Fortinet sikkerhedsværktøjer - det blev foreslået af sikkerhedsfolkene selv. Testrammen blev oprettet af banken, ingen stillede spørgsmål. Depotsystemet rejste spørgsmål; jeg skulle vænne mig til det.
Entreprenører fik en ny stak. De gav os tid til at omskrive det til GitlabCI og migrere Jira til banksegmentet og så videre.
trin for trin
Trin 1. Først brugte vi en løsning fra en indenlandsk leverandør, produktet blev forbundet til et nyt oprettet DSO-netværkssegment. Platformen blev valgt på grund af sin leveringstid, skaleringsfleksibilitet og muligheden for fuld automatisering. Udførte tests:
- Mulighed for fleksibel og fuldautomatisk styring af virtualiseringsplatformens infrastruktur (netværk, diskundersystem, computerressourceundersystem).
- Automatisering af styring af virtuel maskine livscyklus (skabeloner, snapshots, sikkerhedskopier).
Efter installation og grundlæggende konfiguration af platformen blev den brugt som placeringspunkt for undersystemer i anden fase (DSO-værktøjer, skitser for detailsystemudvikling). De nødvendige sæt pipelines blev oprettet - oprettelse, sletning, ændring, backup af virtuelle maskiner. Disse rørledninger blev brugt som den første fase af implementeringsprocessen.
Resultatet er, at det udleverede udstyr ikke lever op til bankens krav til ydeevne og fejltolerance. Bankens DIT besluttede at skabe et kompleks baseret på Nutanix-softwarepakken.
Trin 2. Vi tog stakken, der var defineret, og skrev automatiserede installations- og post-konfigurationsscripts til alle undersystemer, så alt blev overført fra piloten til målkredsløbet så hurtigt som muligt. Alle systemer blev implementeret i en fejltolerant konfiguration (hvor denne mulighed ikke er begrænset af leverandørens licenspolitikker) og forbundet til metrics og hændelsesindsamlingsundersystemer. IB analyserede overholdelse af sine krav og gav grønt lys.
Trin 3. Migrering af alle undersystemer og deres indstillinger til den nye PAC. Infrastrukturautomatiseringsscripts blev omskrevet, og migreringen af DSO-undersystemer blev fuldført i en fuldautomatisk tilstand. Konturerne af IP-udvikling blev genskabt af udviklingsholdenes pipelines.
Trin 4. Automatisering af installation af applikationssoftware. Disse opgaver blev sat af teamlederne for de nye teams.
Trin 5. Udnyttelse.
Fjernadgang
Udviklingsteamene bad om maksimal fleksibilitet i arbejdet med kredsløbet, og kravet om fjernadgang fra personlige bærbare computere blev rejst helt i begyndelsen af projektet. Banken havde allerede fjernadgang, men den var ikke egnet til udviklere. Faktum er, at ordningen brugte brugerens forbindelse til en beskyttet VDI. Dette var velegnet til dem, der kun havde brug for post og en kontorpakke på deres arbejdsplads. Udviklere ville have brug for tunge kunder, høj ydeevne, med mange ressourcer. Og selvfølgelig skulle de være statiske, da tabet af brugersessionen for dem, der arbejder med VStudio (for eksempel) eller andre SDK, er uacceptabelt. Organisering af et stort antal tykke statiske VDI'er for alle udviklingsteams øgede i høj grad prisen på den eksisterende VDI-løsning.
Vi besluttede at arbejde på fjernadgang direkte til ressourcerne i udviklingssegmentet. Jira, Wiki, Gitlab, Nexus, byg og test bænke, virtuel infrastruktur. Sikkerhedsvagter har krævet, at adgang kun kan gives med forbehold af følgende:
- Brug af teknologier, der allerede er tilgængelige i banken.
- Infrastrukturen bør ikke bruge eksisterende domænecontrollere, der gemmer registreringer af produktive kontoobjekter.
- Adgang bør begrænses til kun de ressourcer, der kræves af et specifikt team (så et produktteam ikke kan få adgang til et andet teams ressourcer).
- Maksimal kontrol over RBAC i systemer.
Som et resultat blev der oprettet et separat domæne for dette segment. Dette domæne husede alle udviklingssegmentressourcer, både brugeroplysninger og infrastruktur. Livscyklussen for poster i dette domæne styres ved hjælp af det IdM, der findes i banken.
Direkte fjernadgang blev organiseret på basis af bankens eksisterende udstyr. Adgangskontrollen var opdelt i AD-grupper, som regler om sammenhænge svarede til (én produktgruppe = én gruppe af regler).
VM skabelonstyring
Hastigheden til at skabe en samling og testsløjfe er en af de vigtigste KPI'er, der er fastsat af lederen af udviklingsenheden, fordi hastigheden til at forberede miljøet direkte påvirker den samlede udførelsestid for pipelinen. To muligheder for at forberede basis VM-billeder blev overvejet. Den første er minimum billedstørrelser, standard for alle systemprodukter, maksimal overholdelse af bankens politikker vedrørende indstillinger. Det andet er basisbilledet, som indeholder en kraftig POPPO installeret, hvis installationstid i høj grad kan påvirke udførelseshastigheden af rørledningen.
Der blev også taget hensyn til infrastruktur og sikkerhedskrav under udviklingen - holde billeder opdateret (patches osv.), integration med SIEM, sikkerhedsindstillinger i henhold til bankstandarder.
Som et resultat blev det besluttet at bruge minimale billeder for at minimere omkostningerne ved at holde dem opdaterede. Det er meget nemmere at opdatere basisoperativsystemet end at lappe hvert billede for nye versioner af POPPO.
Baseret på resultaterne blev der dannet en liste over det mindst nødvendige sæt af operativsystemer, hvis opdatering udføres af driftsteamet, og scripts fra pipelinen er helt ansvarlige for at opdatere softwaren og om nødvendigt ændre versionen af den installerede software - overfør blot det nødvendige tag til pipelinen. Ja, dette kræver, at devops-produktteamet har mere komplekse implementeringsscenarier, men det reducerer i høj grad den driftstid, der kræves for at understøtte basisbilleder, som ellers kunne kræve mere end hundrede basis VM-billeder at vedligeholde.
Internetadgang
En anden anstødssten med banksikkerhed var adgang til internetressourcer fra udviklingsmiljøet. Desuden kan denne adgang opdeles i to kategorier:
- Adgang til infrastruktur.
- Udvikleradgang.
Infrastrukturadgang blev organiseret ved at give eksterne arkiver proxy med Nexus. Det vil sige, at der ikke blev givet direkte adgang fra virtuelle maskiner. Dette gjorde det muligt at indgå et kompromis med informationssikkerheden, som kategorisk var imod at give nogen adgang til omverdenen fra udviklingssegmentet.
Udviklere havde brug for adgang til internettet af indlysende årsager (stackoverflow). Og selvom alle kommandoer, som nævnt ovenfor, havde fjernadgang til kredsløbet, er det ikke altid praktisk, når du ikke kan lave ctrl+v fra udviklerens arbejdsplads i banken i IDE.
Der blev indgået en aftale med IS om, at der i første omgang, i testfasen, vil blive givet adgang via en bankproxy baseret på en hvidliste. Når projektet er afsluttet, vil adgangen blive overført til sortlisten. Der blev udarbejdet enorme adgangstabeller, som indikerede de vigtigste ressourcer og arkiver, som der var behov for adgang til ved projektets start. Koordinering af disse adgange tog en del tid, hvilket gjorde det muligt at insistere på den hurtigst mulige overgang til sorte lister.
Fund
Projektet sluttede for lidt mindre end et år siden. Mærkeligt nok skiftede alle entreprenører til den nye stak til tiden, og ingen gik af på grund af den nye automatisering. IB har ikke travlt med at dele positiv feedback, men klager heller ikke, hvoraf vi kan konkludere, at de kan lide det. Konflikterne er aftaget, fordi informationssikkerheden igen føles i kontrol, men ikke forstyrrer udviklingsprocesser. Holdene fik mere ansvar, og den overordnede holdning til informationssikkerhed blev bedre. Banken forstod, at overgangen til DevSecOps næsten var uundgåelig, og gjorde det efter min mening på den mest skånsomme og korrekte måde.
Alexander Shubin, systemarkitekt.
Kilde: www.habr.com