DevOps vs DevSecOps: hur det såg ut i en bank

Banken lägger ut sina projekt på många entreprenörer. "External" skriver kod och överför sedan resultaten i en inte särskilt bekväm form. Specifikt såg processen ut så här: de överlämnade ett projekt som klarade funktionstester med dem och sedan testades inom bankomkretsen för integration, belastning och så vidare. Det upptäcktes ofta att testerna misslyckades. Sedan gick allt tillbaka till den externa utvecklaren. Som du kan gissa innebar detta långa ledtider för buggfixar.

Banken beslutade att det var möjligt och nödvändigt att dra hela rörledningen under sina vingar, från commits till release. Så att allt är enhetligt och under kontroll av teamen som ansvarar för produkten i banken. Det vill säga som om den externa entreprenören helt enkelt arbetade någonstans i nästa rum på kontoret. På företagshögen. Detta är en vanlig devops.

Var kom Sec ifrån? Bankens säkerhet har ställt höga krav på hur en extern entreprenör kan arbeta i nätsegmentet, vilken åtkomst någon har, hur och vem som arbetar med koden. Det är bara det att IB ännu inte visste att när entreprenörer arbetar utanför, följs få bankstandarder. Och sedan om ett par dagar måste alla börja observera dem.

Det enkla avslöjandet att entreprenören hade full tillgång till produktkoden hade redan vänt upp och ner på deras värld.

I det här ögonblicket började historien om DevSecOps, som jag vill berätta om.

Vilka praktiska slutsatser drog banken av denna situation?

Det var mycket kontrovers om att allt görs på fel sätt. Utvecklarna sa att säkerheten bara är upptagen med att försöka störa utvecklingen, och de, som väktare, försöker förbjuda utan att tänka. I sin tur tvekade säkerhetsspecialister mellan att välja mellan synpunkterna: "utvecklare skapar sårbarheter i vår krets" och "utvecklare skapar inte sårbarheter, utan är dem själva." Tvisten skulle ha fortsatt under lång tid om inte nya marknadskrav och framväxten av DevSecOps-paradigmet hade funnits. Det var möjligt att förklara att just denna automatisering av processer som tar hänsyn till informationssäkerhetskrav "utanför lådan" kommer att hjälpa alla att förbli nöjda. I den meningen att reglerna skrivs ner omedelbart och inte ändras under spelets gång (informationssäkerheten kommer inte att förbjuda något oväntat), och utvecklarna håller informationssäkerheten informerad om allt som händer (informationssäkerheten stöter inte på något plötsligt) . Varje lag ansvarar också för den ultimata säkerheten, och inte några abstrakta äldre bröder.

1. Eftersom externa medarbetare redan har tillgång till koden och ett antal interna system är det sannolikt möjligt att ta bort kravet ”utveckling ska ske helt på bankens infrastruktur” ur dokumenten.
2. Å andra sidan måste vi stärka kontrollen över vad som händer.
3. Kompromissen var skapandet av tvärfunktionella team, där anställda arbetar nära med externa personer. I det här fallet måste du se till att teamet arbetar med verktyg på bankens servrar. Från början till slutet.

Det vill säga att entreprenörer kan släppas in, men de behöver ges separata segment. Så att de inte för in någon form av smitta utifrån i bankens infrastruktur och så att de inte ser mer än vad som är nödvändigt. Jo, så att deras handlingar loggas. DLP för skydd mot läckor, allt detta ingick.

I princip kommer alla banker till detta förr eller senare. Här gick vi in ​​på den inslagna vägen och kom överens om kraven på sådana miljöer där ”externa” arbetar. Det dök upp ett maximalt utbud av åtkomstkontrollverktyg, verktyg för sårbarhetskontroll, antivirusanalys på kretsar, sammansättningar och tester. Detta kallas DevSecOps.

Plötsligt blev det klart att om innan DevSecOps banksäkerhet inte hade kontroll över vad som händer på utvecklarens sida, så styrs säkerheten i det nya paradigmet på samma sätt som vanliga händelser på infrastrukturen. Först nu finns det varningar om sammanställningar, kontroll av bibliotek och så vidare.

Allt som återstår är att överföra teamen till den nya modellen. Tja, skapa infrastrukturen. Men det här är bagateller, det är som att rita en uggla. Egentligen hjälpte vi till med infrastrukturen och på den tiden förändrades utvecklingsprocesserna.

Vad har förändrats

Vi bestämde oss för att implementera det i små steg, eftersom vi förstod att många processer skulle falla sönder, och många "externa" kanske inte skulle klara de nya arbetsförhållandena under överinseende av alla.

Först skapade vi tvärfunktionella team och lärde oss att organisera projekt med hänsyn till nya krav. I betydelsen organisatoriskt diskuterade vi vilka processer. Resultatet blev ett diagram över monteringsröret med alla ansvariga.

• IC: 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.
• Presentation (rapportering, kommunikation): Grafana, Kibana, Jira, Confluence, RocketChat.
• Verksamhet (underhåll, förvaltning): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Vald stack:

• Kunskapsbas - Atlassian Confluence;
• Uppgiftsspårare - Atlassian Jira;
• Artefaktförråd - "Nexus";
• Kontinuerligt integrationssystem - "Gitlab CI";
• System för kontinuerlig analys - "SonarQube";
• System för applikationssäkerhetsanalys - "Micro Focus Fortify";
• Kommunikationssystem - "GitLab Mattermost";
• Konfigurationshanteringssystem - "Ansible";
• Övervakningssystem - "ELK", "TICK Stack" ("InfluxData").

De började skapa ett team som skulle vara redo att dra in entreprenörer. Det finns en insikt om att det finns flera viktiga saker:

• Allt bör vara enhetligt, åtminstone vid överföring av kod. För det fanns lika många entreprenörer som det fanns så många olika utvecklingsprocesser med sina egna särdrag. Det var nödvändigt att passa in alla i ungefär en, men med alternativ.
• Det finns många entreprenörer och manuellt skapande av infrastruktur är inte lämpligt. Varje ny uppgift bör starta mycket snabbt - det vill säga att instansen ska distribueras nästan omedelbart så att utvecklare har en uppsättning lösningar för att hantera sin pipeline.

För att ta det första steget var det nödvändigt att förstå vad som gjordes. Och vi var tvungna att bestämma hur vi skulle ta oss dit. Vi började med att hjälpa till att rita mållösningens arkitektur både inom infrastruktur och CI/CD-automation. Sedan började vi montera den här transportören. Vi behövde en infrastruktur, samma för alla, där samma transportörer skulle köras. Vi erbjöd alternativ med kalkyler, tyckte banken, och bestämde sedan vad som skulle byggas och med vilka medel.

Nästa är skapandet av kretsen - installation av programvara, konfiguration. Utveckling av skript för utbyggnad och hantering av infrastruktur. Därefter kommer övergången till transportbandsstöd.

Vi bestämde oss för att testa allt på piloten. Intressant nog, under piloteringen dök en viss stack upp i banken för första gången. Bland annat erbjöds en inhemsk leverantör av en av lösningarna för pilotens omfattning för en snabb lansering. Säkerheten lärde känna honom när han lotsade, och det lämnade ett oförglömligt intryck. När vi bestämde oss för att byta ersattes som tur var infrastrukturlagret med en Nutanix-lösning som redan fanns på banken tidigare. Dessutom, innan dess var det för VDI, men vi återanvände det för infrastrukturtjänster. Vid små volymer passade det inte in i ekonomin, men vid stora volymer blev det en utmärkt miljö för utveckling och testning.

Resten av stapeln är mer eller mindre bekant för alla. Automationsverktyg i Ansible användes och säkerhetsspecialister arbetade nära dem. Atlassin-stacken användes av banken innan projektet. Fortinet säkerhetsverktyg - det föreslogs av säkerhetsfolket själva. Testramen skapades av banken, inga frågor ställda. Förvarssystemet väckte frågor, jag var tvungen att vänja mig vid det.

Entreprenörerna fick en ny stack. De gav oss tid att skriva om det för GitlabCI, och migrera Jira till banksegmentet och så vidare.

steg för steg

Steg 1. Först använde vi en lösning från en inhemsk leverantör, produkten kopplades till ett nyskapat DSO-nätverkssegment. Plattformen valdes för sin leveranstid, skalningsflexibilitet och möjligheten till full automatisering. Utförda tester:

• Möjlighet till flexibel och helautomatiserad hantering av virtualiseringsplattformens infrastruktur (nätverk, diskdelsystem, datorresursundersystem).
• Automatisering av livscykelhantering för virtuella maskiner (mallar, ögonblicksbilder, säkerhetskopior).

Efter installationen och den grundläggande konfigurationen av plattformen användes den som placeringspunkt för det andra stegets delsystem (DSO-verktyg, skisser för utveckling av detaljhandelssystem). De nödvändiga uppsättningarna av pipelines skapades - skapande, radering, modifiering, säkerhetskopiering av virtuella maskiner. Dessa pipelines användes som det första steget i utbyggnadsprocessen.

Resultatet är att den tillhandahållna utrustningen inte uppfyller bankens krav på prestanda och feltolerans. Bankens DIT beslutade att skapa ett komplex baserat på programpaketet Nutanix.

Steg 2. Vi tog den stack som definierades och skrev automatiserade installations- och efterkonfigurationsskript för alla delsystem så att allt överfördes från piloten till målkretsen så snabbt som möjligt. Alla system distribuerades i en feltolerant konfiguration (där denna förmåga inte är begränsad av leverantörens licenspolicy) och kopplade till mätvärden och undersystem för insamling av händelser. IB analyserade efterlevnaden av sina krav och gav grönt ljus.

Steg 3. Migrering av alla delsystem och deras inställningar till den nya PAC. Skript för automatisering av infrastruktur skrevs om och migreringen av DSO-delsystem slutfördes i ett helt automatiserat läge. IP-utvecklingens konturer återskapades av utvecklingsteamens pipelines.

Steg 4. Automatisering av installation av applikationsprogramvara. Dessa uppgifter sattes av teamledarna för de nya teamen.

Steg 5. Utnyttjande.

Fjärranslutning

Utvecklingsteamen bad om maximal flexibilitet i arbetet med kretsen, och kravet på fjärråtkomst från personliga bärbara datorer höjdes redan i början av projektet. Banken hade redan fjärråtkomst, men det var inte lämpligt för utvecklare. Faktum är att schemat använde användarens anslutning till en skyddad VDI. Detta passade de som bara behövde post och ett kontorspaket på sin arbetsplats. Utvecklare skulle behöva tunga kunder, hög prestanda, med mycket resurser. Och naturligtvis måste de vara statiska, eftersom förlusten av användarsessionen för de som arbetar med VStudio (till exempel) eller annan SDK är oacceptabelt. Att organisera ett stort antal tjocka statiska VDI:er för alla utvecklingsteam ökade kostnaden avsevärt för den befintliga VDI-lösningen.

Vi bestämde oss för att arbeta med fjärråtkomst direkt till utvecklingssegmentets resurser. Jira, Wiki, Gitlab, Nexus, bygg och testa bänkar, virtuell infrastruktur. Säkerhetsvakter har krävt att tillträde endast kan ges med förbehåll för följande:

1. Använder teknik som redan finns på banken.
2. Infrastrukturen bör inte använda befintliga domänkontrollanter som lagrar register över produktiva kontoobjekt.
3. Åtkomsten bör begränsas till endast de resurser som krävs av ett specifikt team (så att ett produktteam inte kan komma åt ett annat teams resurser).
4. Maximal kontroll över RBAC i system.

Som ett resultat skapades en separat domän för detta segment. Denna domän rymde alla utvecklingssegmentresurser, både användaruppgifter och infrastruktur. Livscykeln för poster i denna domän hanteras med det IdM som finns i banken.

Direkt fjärråtkomst organiserades på basis av bankens befintliga utrustning. Åtkomstkontrollen delades in i AD-grupper, till vilka regler om sammanhang motsvarade (en produktgrupp = en grupp regler).

VM-mallhantering

Hastigheten för att skapa en monterings- och testslinga är en av de viktigaste KPI:erna som ställts in av chefen för utvecklingsenheten, eftersom hastigheten för att förbereda miljön direkt påverkar pipelinens totala utförandetid. Två alternativ för att förbereda bas-VM-bilder övervägdes. Den första är de minsta bildstorlekarna, standard för alla systemprodukter, maximal överensstämmelse med bankens policyer gällande inställningar. Den andra är basbilden, som innehåller en kraftig POPPO installerad, vars installationstid i hög grad kan påverka rörledningens utförandehastighet.

Infrastruktur och säkerhetskrav togs också i beaktande under utvecklingen - hålla bilder uppdaterade (patchar etc.), integration med SIEM, säkerhetsinställningar enligt bankstandarder.

Som ett resultat beslutades det att använda minimala bilder för att minimera kostnaden för att hålla dem uppdaterade. Det är mycket lättare att uppdatera basoperativsystemet än att korrigera varje bild för nya versioner av POPPO.

Baserat på resultaten bildades en lista över den minsta nödvändiga uppsättningen av operativsystem, vars uppdatering utförs av operationsteamet, och skript från pipelinen är helt ansvariga för att uppdatera programvaran och vid behov ändra versionen av den installerade programvaran - överför bara den nödvändiga taggen till pipeline. Ja, detta kräver att devops produktteam har mer komplexa installationsscenarier, men det minskar avsevärt den driftstid som krävs för att stödja basavbildningar, vilket annars skulle kunna kräva mer än hundra basavbildningar för VM att underhålla.

Tillgång till internet

En annan stötesten med banksäkerhet var tillgången till internetresurser från utvecklingsmiljön. Dessutom kan denna åtkomst delas in i två kategorier:

1. Tillgång till infrastruktur.
2. Utvecklaråtkomst.

Infrastrukturåtkomst organiserades genom att proxyservrar externa arkiv med Nexus. Det vill säga direktåtkomst från virtuella maskiner tillhandahölls inte. Detta gjorde det möjligt att nå en kompromiss med informationssäkerhet, som var kategoriskt emot att ge någon tillgång till omvärlden från utvecklingssegmentet.

Utvecklare behövde tillgång till Internet av uppenbara skäl (stackoverflow). Och även om alla kommandon, som nämnts ovan, hade fjärråtkomst till kretsen, är det inte alltid bekvämt när du inte kan göra ctrl+v från utvecklarens arbetsplats i banken i IDE.

En överenskommelse träffades med IS om att till en början, i teststadiet, kommer tillgång att tillhandahållas genom en bankproxy baserad på en vitlista. När projektet har slutförts kommer tillgången att överföras till den svarta listan. Enorma åtkomsttabeller utarbetades, som angav de huvudsakliga resurserna och förråden till vilka åtkomst krävdes i början av projektet. Att samordna dessa åtkomster tog ganska lång tid, vilket gjorde det möjligt att insistera på snabbast möjliga övergång till svarta listor.

Resultat

Projektet avslutades för lite mindre än ett år sedan. Märkligt nog gick alla entreprenörer över till den nya traven i tid och ingen lämnade på grund av den nya automatiseringen. IB har ingen brådska med att dela positiv feedback, men klagar inte heller, av vilket vi kan dra slutsatsen att de gillar det. Konflikterna har lagt sig eftersom informationssäkerheten åter känns i kontroll, men inte stör utvecklingsprocesser. Teamen fick mer ansvar och den övergripande inställningen till informationssäkerhet blev bättre. Banken förstod att övergången till DevSecOps nästan var oundviklig och gjorde det, enligt min mening, på det mest skonsamma och korrekta sättet.

Alexander Shubin, systemarkitekt.

Källa: will.com