De bank besteedt haar projecten uit aan vele aannemers. "Externals" schrijven code en verzenden de resultaten vervolgens in een niet erg handige vorm. Concreet zag het proces er als volgt uit: ze droegen een project over dat samen met hen de functionele tests doorstond en vervolgens binnen de bancaire perimeter werd getest op integratie, belasting, enzovoort. Vaak werd ontdekt dat tests faalden. Daarna ging alles terug naar de externe ontwikkelaar. Zoals je kunt raden, betekende dit lange doorlooptijden voor bugfixes.
De bank besloot dat het mogelijk en noodzakelijk was om de gehele pijpleiding onder haar hoede te slepen, van commits tot release. Zodat alles uniform is en onder controle van de teams die verantwoordelijk zijn voor het product op de bank. Dat wil zeggen, alsof de externe contractant gewoon ergens in de volgende kamer van het kantoor aan het werk was. Op de bedrijfsstapel. Dit is een gewone devops.
Waar komt Sec vandaan? De beveiliging van de bank stelt hoge eisen aan hoe een externe opdrachtnemer in het netwerksegment kan werken, welke toegang iemand heeft, hoe en wie met de code werkt. Alleen wist IB nog niet dat wanneer aannemers buiten werken, er weinig banknormen worden gevolgd. En dan moet iedereen ze over een paar dagen gaan observeren.
De simpele onthulling dat de aannemer volledige toegang had tot de productcode had hun wereld al op zijn kop gezet.
Op dit moment begon het verhaal van DevSecOps, waarover ik je wil vertellen.
Welke praktische conclusies trok de bank uit deze situatie?
Er was veel controverse over het feit dat alles op de verkeerde manier wordt gedaan. De ontwikkelaars zeiden dat de beveiliging alleen bezig is met het verstoren van de ontwikkeling, en dat zij, net als wachters, proberen te verbieden zonder na te denken. Beveiligingsspecialisten aarzelden op hun beurt tussen de standpunten: “ontwikkelaars creëren kwetsbaarheden in ons circuit” en “ontwikkelaars creëren geen kwetsbaarheden, maar zijn ze zelf.” Het dispuut zou nog lang hebben voortgeduurd als er geen nieuwe markteisen en de opkomst van het DevSecOps-paradigma waren geweest. Het was mogelijk uit te leggen dat juist deze automatisering van processen, waarbij ‘out of the box’ rekening wordt gehouden met informatiebeveiligingseisen, iedereen zal helpen tevreden te blijven. In de zin dat de regels direct worden opgeschreven en niet veranderen tijdens het spel (de informatiebeveiliging zal niet onverwachts iets verbieden), en de ontwikkelaars de informatiebeveiliging op de hoogte houden van alles wat er gebeurt (de informatiebeveiliging komt niet plotseling ergens tegen) . Elk team is ook verantwoordelijk voor de uiteindelijke veiligheid, en niet enkele abstracte oudere broers.
- Omdat externe medewerkers al toegang hebben tot de code en een aantal interne systemen, is het waarschijnlijk mogelijk om uit de documenten de eis ‘de ontwikkeling moet geheel op de infrastructuur van de bank plaatsvinden’ te schrappen.
- Aan de andere kant moeten we de controle over wat er gebeurt versterken.
- Het compromis was de oprichting van cross-functionele teams, waarin medewerkers nauw samenwerken met externe mensen. In dit geval moet u ervoor zorgen dat het team aan tools op de servers van de bank werkt. Van het begin tot het eind.
Dat wil zeggen dat aannemers toegelaten kunnen worden, maar dat ze aparte segmenten moeten krijgen. Zodat ze niet een of andere infectie van buitenaf in de infrastructuur van de bank brengen en zodat ze niet meer zien dan nodig is. Nou ja, zodat hun acties worden geregistreerd. DLP voor bescherming tegen lekken, dit alles zat erbij.
In principe komen alle banken hier vroeg of laat mee in aanraking. Hier zijn we de gebaande paden bewandeld en zijn we het eens geworden over de vereisten voor dergelijke omgevingen waarin ‘externen’ werken. Er verscheen een maximaal scala aan tools voor toegangscontrole, tools voor het controleren van kwetsbaarheden, antivirusanalyse op circuits, assemblages en tests. Dit heet DevSecOps.
Plotseling werd het duidelijk dat als de bankbeveiliging vóór DevSecOps geen controle had over wat er aan de kant van de ontwikkelaar gebeurt, de beveiliging in het nieuwe paradigma op dezelfde manier wordt gecontroleerd als gewone gebeurtenissen op de infrastructuur. Alleen nu zijn er waarschuwingen over vergaderingen, controle over bibliotheken, enzovoort.
Het enige dat overblijft is het overbrengen van de teams naar het nieuwe model. Welnu, creëer de infrastructuur. Maar dit zijn kleinigheden, het is alsof je een uil tekent. Eigenlijk hielpen we met de infrastructuur, en in die tijd waren de ontwikkelingsprocessen aan het veranderen.
Wat is er veranderd
We besloten het in kleine stapjes te implementeren, omdat we begrepen dat veel processen uiteen zouden vallen en dat veel ‘externen’ de nieuwe werkomstandigheden onder toezicht van iedereen misschien niet zouden kunnen weerstaan.
Ten eerste creëerden we cross-functionele teams en leerden we projecten te organiseren, rekening houdend met nieuwe vereisten. In de zin van organisatorisch hebben we besproken welke processen. Het resultaat was een diagram van de assemblagepijplijn met alle verantwoordelijken.
- IC: 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.
- Presentatie (rapportage, communicatie): Grafana, Kibana, Jira, Confluence, RocketChat.
- Operations (onderhoud, beheer): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Geselecteerde stapel:
- Kennisbank - Atlassian Confluence;
- Taaktracker - Atlassian Jira;
- Artefactopslagplaats - "Nexus";
- Continu integratiesysteem - “Gitlab CI”;
- Continu analysesysteem - “SonarQube”;
- Analysesysteem voor applicatiebeveiliging - “Micro Focus Fortify”;
- Communicatiesysteem - “GitLab Mattermost”;
- Configuratiebeheersysteem - “Ansible”;
- Monitoringsysteem - "ELK", "TICK Stack" ("InfluxData").
Ze begonnen een team te creëren dat klaar zou staan om aannemers naar binnen te slepen. Er is een besef dat er verschillende belangrijke dingen zijn:
- Alles moet verenigd zijn, tenminste bij het verzenden van code. Want er waren evenveel opdrachtnemers als er zoveel verschillende ontwikkelprocessen waren met hun eigen bijzonderheden. Het was nodig om iedereen ongeveer in één te passen, maar met opties.
- Er zijn veel aannemers en het handmatig aanleggen van infrastructuur is niet geschikt. Elke nieuwe taak zou zeer snel moeten starten, dat wil zeggen dat de instantie vrijwel onmiddellijk moet worden geïmplementeerd, zodat ontwikkelaars over een reeks oplossingen beschikken om hun pijplijn te beheren.
Om de eerste stap te zetten, was het noodzakelijk om te begrijpen wat er werd gedaan. En we moesten bepalen hoe we daar moesten komen. We zijn begonnen met het helpen tekenen van de architectuur van de doeloplossing, zowel op het gebied van infrastructuur als CI/CD-automatisering. Vervolgens zijn we begonnen met het monteren van deze transportband. We hadden één infrastructuur nodig, voor iedereen hetzelfde, waar dezelfde transportbanden zouden lopen. Wij boden opties aan met berekeningen, dacht de bank, en beslisten vervolgens wat er gebouwd zou worden en met welke middelen.
Het volgende is het creëren van het circuit - installatie van software, configuratie. Ontwikkeling van scripts voor de implementatie en het beheer van de infrastructuur. Vervolgens komt de overgang naar transportbandondersteuning.
We besloten om alles tijdens de pilot te testen. Interessant is dat tijdens de pilot voor het eerst een bepaalde stapel op de bank verscheen. Voor een snelle lancering werd onder meer een binnenlandse leverancier van een van de oplossingen aangeboden in het kader van de pilot. De beveiliging leerde hem kennen terwijl hij piloot was, en het liet een onvergetelijke indruk achter. Toen we besloten om over te stappen werd de infrastructuurlaag gelukkig vervangen door een Nutanix-oplossing, die al eerder op de bank stond. Bovendien was het voorheen voor VDI, maar we hergebruikten het voor infrastructuurdiensten. Bij kleine volumes paste het niet in de economie, maar bij grote volumes werd het een uitstekende omgeving voor ontwikkeling en testen.
De rest van de stapel is voor iedereen min of meer bekend. Er werd gebruik gemaakt van automatiseringstools in Ansible en beveiligingsspecialisten werkten nauw met hen samen. De Atlassin-stack werd vóór het project door de bank gebruikt. Fortinet-beveiligingstools - het werd voorgesteld door de beveiligingsmensen zelf. Het testframe is door de bank gemaakt, zonder dat er vragen werden gesteld. Het repositorysysteem riep vragen op, ik moest eraan wennen.
Aannemers kregen een nieuwe stapel. Ze gaven ons de tijd om het voor GitlabCI te herschrijven en Jira naar het banksegment te migreren, enzovoort.
stap voor stap
Stap 1. Eerst gebruikten we een oplossing van een binnenlandse leverancier, het product werd aangesloten op een nieuw gecreëerd DSO-netwerksegment. Het platform werd gekozen vanwege de levertijd, schaalflexibiliteit en de mogelijkheid tot volledige automatisering. Uitgevoerde tests:
- Mogelijkheid tot flexibel en volledig geautomatiseerd beheer van de infrastructuur van het virtualisatieplatform (netwerk, schijfsubsysteem, subsysteem computerbronnen).
- Automatisering van het levenscyclusbeheer van virtuele machines (sjablonen, snapshots, back-ups).
Na installatie en basisconfiguratie van het platform werd het gebruikt als plaatsingspunt voor de subsystemen van de tweede fase (DSO-tools, ontwikkelingsoverzichten voor retailsystemen). Er zijn de nodige sets pijplijnen gemaakt - creatie, verwijdering, wijziging, back-up van virtuele machines. Deze pijpleidingen werden gebruikt als de eerste fase van het implementatieproces.
Het gevolg is dat de geleverde apparatuur niet voldoet aan de eisen die de bank stelt aan prestatie en fouttolerantie. De DIT van de bank besloot een complex te creëren op basis van het softwarepakket Nutanix.
Stage 2. We namen de gedefinieerde stapel en schreven geautomatiseerde installatie- en post-configuratiescripts voor alle subsystemen, zodat alles zo snel mogelijk van het pilot- naar het doelcircuit werd overgebracht. Alle systemen zijn geïmplementeerd in een fouttolerante configuratie (waarbij deze mogelijkheid niet wordt beperkt door het licentiebeleid van de leverancier) en verbonden met metrische gegevens en subsystemen voor het verzamelen van gebeurtenissen. IB analyseerde de naleving van haar eisen en gaf groen licht.
Stage 3. Migratie van alle subsystemen en hun instellingen naar de nieuwe PAC. De scripts voor de automatisering van de infrastructuur werden herschreven en de migratie van DSO-subsystemen werd volledig geautomatiseerd voltooid. De contouren van de IP-ontwikkeling werden opnieuw gecreëerd door de pijplijnen van de ontwikkelingsteams.
Stap 4. Automatisering van de installatie van applicatiesoftware. Deze taken werden vastgelegd door de teamleiders van de nieuwe teams.
Stap 5. Exploitatie.
Toegang op afstand
De ontwikkelingsteams vroegen om maximale flexibiliteit bij het werken met het circuit, en de eis voor externe toegang vanaf persoonlijke laptops werd al aan het begin van het project gesteld. De bank had al toegang op afstand, maar die was niet geschikt voor ontwikkelaars. Feit is dat het schema gebruik maakte van de verbinding van de gebruiker met een beschermde VDI. Dit was geschikt voor wie op de werkplek alleen post en een kantoorpakket nodig had. Ontwikkelaars zouden zware clients nodig hebben, hoge prestaties, met veel middelen. En natuurlijk moesten ze statisch zijn, omdat het verlies van de gebruikerssessie voor degenen die met VStudio (bijvoorbeeld) of een andere SDK werken onaanvaardbaar is. Het organiseren van een groot aantal dikke statische VDI's voor alle ontwikkelingsteams verhoogde de kosten van de bestaande VDI-oplossing aanzienlijk.
We besloten om rechtstreeks te werken aan externe toegang tot de bronnen van het ontwikkelingssegment. Jira, Wiki, Gitlab, Nexus, bouw- en testbanken, virtuele infrastructuur. Beveiligers hebben geëist dat toegang alleen kan worden verleend op voorwaarde van het volgende:
- Gebruikmakend van technologieën die al beschikbaar zijn bij de bank.
- De infrastructuur mag geen gebruik maken van bestaande domeincontrollers die records van productieve accountobjecten opslaan.
- De toegang moet worden beperkt tot alleen de bronnen die een specifiek team nodig heeft (zodat het ene productteam geen toegang heeft tot de bronnen van een ander team).
- Maximale controle over RBAC in systemen.
Hierdoor is er voor dit segment een apart domein ontstaan. Dit domein huisvestte alle bronnen van het ontwikkelingssegment, zowel gebruikersreferenties als infrastructuur. De levenscyclus van records in dit domein wordt beheerd met behulp van de IdM die in de bank aanwezig is.
Directe toegang op afstand werd georganiseerd op basis van de bestaande apparatuur van de bank. De toegangscontrole werd opgedeeld in AD-groepen, waarmee regels over contexten correspondeerden (één productgroep = één groep regels).
Beheer van VM-sjablonen
De snelheid waarmee een assemblage- en testlus wordt gemaakt, is een van de belangrijkste KPI's die door het hoofd van de ontwikkelingseenheid zijn vastgesteld, omdat de snelheid waarmee de omgeving wordt voorbereid rechtstreeks van invloed is op de algehele uitvoeringstijd van de pijplijn. Er zijn twee opties overwogen voor het voorbereiden van basis-VM-images. De eerste is de minimale afbeeldingsgrootte, standaard voor alle systeemproducten, maximale naleving van het beleid van de bank met betrekking tot instellingen. De tweede is de basisimage, waarop een krachtige POPPO is geïnstalleerd, waarvan de installatietijd de uitvoeringssnelheid van de pijplijn sterk zou kunnen beïnvloeden.
Tijdens de ontwikkeling werd ook rekening gehouden met infrastructuur- en beveiligingsvereisten: het up-to-date houden van afbeeldingen (patches, etc.), integratie met SIEM, beveiligingsinstellingen volgens bankstandaarden.
Als gevolg hiervan werd besloten om minimale afbeeldingen te gebruiken om de kosten voor het up-to-date houden ervan te minimaliseren. Het is veel eenvoudiger om het basisbesturingssysteem bij te werken dan elke image te patchen voor nieuwe versies van POPPO.
Op basis van de resultaten werd een lijst gevormd van de minimaal vereiste set besturingssystemen, waarvan de update wordt uitgevoerd door het operatieteam, en scripts uit de pijplijn zijn volledig verantwoordelijk voor het updaten van de software en het indien nodig wijzigen van de versie van de geïnstalleerde software - breng gewoon de vereiste tag over naar de pijplijn. Ja, dit vereist dat het devops-productteam complexere implementatiescenario's heeft, maar het vermindert de operationele tijd die nodig is om basisimages te ondersteunen aanzienlijk, waarvoor anders meer dan honderd basis-VM-images nodig zouden zijn om te onderhouden.
Toegang tot internet
Een ander struikelblok bij de beveiliging van banken was de toegang tot internetbronnen vanuit de ontwikkelomgeving. Bovendien kan deze toegang in twee categorieën worden verdeeld:
- Toegang tot infrastructuur.
- Toegang voor ontwikkelaars.
Toegang tot de infrastructuur werd georganiseerd door externe opslagplaatsen te proxyen met Nexus. Dat wil zeggen dat er geen directe toegang vanaf virtuele machines werd geboden. Dit maakte het mogelijk een compromis te bereiken op het gebied van informatiebeveiliging, dat categorisch tegen het bieden van enige toegang tot de buitenwereld vanuit het ontwikkelingssegment was.
Ontwikkelaars hadden om voor de hand liggende redenen toegang tot internet nodig (stackoverflow). En hoewel alle commando's, zoals hierboven vermeld, externe toegang tot het circuit hadden, is het niet altijd handig als je ctrl+v niet kunt doen vanaf de werkplek van de ontwikkelaar in de bank in de IDE.
Met IS is overeengekomen dat in eerste instantie, in de testfase, toegang zal worden verleend via een bankproxy op basis van een witte lijst. Na voltooiing van het project wordt de toegang overgebracht naar de zwarte lijst. Er werden enorme toegangstabellen opgesteld, waarin de belangrijkste bronnen en opslagplaatsen werden aangegeven waartoe bij de start van het project toegang nodig was. Het coördineren van deze toegangen kostte behoorlijk wat tijd, wat het mogelijk maakte om aan te dringen op de snelst mogelijke overgang naar zwarte lijsten.
Bevindingen
Het project eindigde iets minder dan een jaar geleden. Vreemd genoeg schakelden alle aannemers op tijd over op de nieuwe stapel en vertrok er niemand vanwege de nieuwe automatisering. IB heeft geen haast met het delen van positieve feedback, maar klaagt ook niet, waaruit we kunnen concluderen dat ze het leuk vinden. Conflicten zijn afgenomen omdat de informatiebeveiliging weer het gevoel heeft de controle te hebben, maar ontwikkelingsprocessen niet verstoort. De teams kregen meer verantwoordelijkheid en de algehele houding ten opzichte van informatiebeveiliging werd beter. De bank begreep dat de overstap naar DevSecOps vrijwel onvermijdelijk was, en deed dat naar mijn mening op de meest zachte en correcte manier.
Alexander Shubin, systeemarchitect.
Bron: www.habr.com