El banc externalitza els seus projectes a molts contractistes. Els "externs" escriuen codi i després transmeten els resultats d'una forma poc convenient. Concretament, el procés va quedar així: van lliurar un projecte que va passar proves funcionals amb ells, i després es va provar dins del perímetre bancari per a la integració, la càrrega, etc. Sovint es va descobrir que les proves fallaven. Aleshores, tot va tornar al desenvolupador extern. Com podeu endevinar, això significava llargs terminis de lliurament per a les correccions d'errors.
El banc va decidir que era possible i necessari arrossegar tot el gasoducte sota la seva ala, des dels compromisos fins a l'alliberament. Perquè tot sigui uniforme i sota el control dels equips responsables del producte al banc. És a dir, com si el contractista extern simplement treballés en algun lloc de l'habitació del costat de l'oficina. A la pila corporativa. Aquest és un devops normal.
D'on ha sortit Sec? La seguretat del banc ha posat grans exigències sobre com un contractista extern pot treballar en el segment de la xarxa, quin accés té algú, com i qui treballa amb el codi. És que IB encara no sabia que quan els contractistes treballen fora, es segueixen pocs estàndards bancaris. I després en un parell de dies tothom ha de començar a observar-los.
La simple revelació que el contractista tenia accés total al codi del producte ja havia capgirat el seu món.
En aquest moment va començar la història de DevSecOps, que us vull explicar.
Quines conclusions pràctiques va treure el banc d'aquesta situació?
Hi va haver molta polèmica sobre el fet que tot s'està fent malament. Els desenvolupadors van dir que la seguretat només està ocupada intentant interferir amb el desenvolupament, i ells, com els vigilants, intenten prohibir sense pensar-ho. Al seu torn, els especialistes en seguretat van dubtar entre triar entre els punts de vista: "els desenvolupadors creen vulnerabilitats al nostre circuit" i "els desenvolupadors no creen vulnerabilitats, sinó que són ells mateixos". La disputa hauria continuat durant molt de temps si no fos per les noves demandes del mercat i l'aparició del paradigma DevSecOps. Es va poder explicar que aquesta mateixa automatització dels processos tenint en compte els requisits de seguretat de la informació "fora de la caixa" ajudarà a que tothom estigui content. En el sentit que les regles s'escriuen immediatament i no canvien durant el joc (la seguretat de la informació no prohibirà alguna cosa inesperadament), i els desenvolupadors mantenen la seguretat de la informació informada de tot el que passa (la seguretat de la informació no es troba amb res de sobte) . Cada equip també és responsable de la seguretat màxima, i no d'alguns germans grans abstractes.
- Com que els empleats externs ja tenen accés al codi i a una sèrie de sistemes interns, és probable que sigui possible eliminar dels documents el requisit "el desenvolupament s'ha de dur a terme completament a la infraestructura del banc".
- D'altra banda, hem de reforçar el control sobre el que està passant.
- El compromís va ser la creació d'equips multifuncionals, on els empleats treballen estretament amb persones externes. En aquest cas, cal assegurar-se que l'equip treballa amb eines als servidors del banc. Des del principi fins al final.
És a dir, es pot permetre l'entrada dels contractistes, però cal donar-los segments separats. Perquè no portin cap tipus d'infecció de fora a la infraestructura del banc i perquè no vegin més del que cal. Bé, perquè les seves accions es registrin. DLP per a la protecció contra fuites, tot això s'incloïa.
En principi, tots els bancs hi arriben tard o d'hora. Aquí vam seguir el camí trillat i vam acordar els requisits d'aquests entorns on treballen els "externs". Va aparèixer una gamma màxima d'eines de control d'accés, eines de verificació de vulnerabilitats, anàlisi antivirus en circuits, muntatges i proves. Això s'anomena DevSecOps.
De sobte es va fer evident que si abans de DevSecOps la seguretat bancària no tenia control sobre el que passa per part del desenvolupador, aleshores en el nou paradigma la seguretat es controla de la mateixa manera que els esdeveniments ordinaris a la infraestructura. Només ara hi ha alertes sobre muntatges, control de biblioteques, etc.
Només queda traslladar els equips al nou model. Bé, crear la infraestructura. Però aquestes són petiteses, és com dibuixar un mussol. De fet, vam ajudar amb la infraestructura, i en aquell moment els processos de desenvolupament estaven canviant.
El que ha canviat
Vam decidir implementar-lo en petits passos, perquè enteníem que molts processos es descompondrien, i molts “externs” potser no podrien suportar les noves condicions laborals sota la supervisió de tothom.
En primer lloc, vam crear equips transversals i vam aprendre a organitzar projectes tenint en compte els nous requeriments. En el sentit de l'organització, vam discutir quins processos. El resultat va ser un esquema de la canonada de muntatge amb tots els responsables.
- CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Prova: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- Presentation (informes, comunicació): Grafana, Kibana, Jira, Confluence, RocketChat.
- operacions (manteniment, gestió): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Pila seleccionada:
- Base de coneixement - Atlassian Confluence;
- Seguiment de tasques - Atlassian Jira;
- Repositori d'artefactes - "Nexus";
- Sistema d'integració contínua - "Gitlab CI";
- Sistema d'anàlisi contínua - "SonarQube";
- Sistema d'anàlisi de seguretat d'aplicacions - "Micro Focus Fortify";
- Sistema de comunicació - "GitLab Mattermost";
- Sistema de gestió de la configuració - "Ansible";
- Sistema de monitorització - "ELK", "TICK Stack" ("InfluxData").
Van començar a crear un equip que estaria preparat per arrossegar els contractistes dins. S'adona que hi ha diverses coses importants:
- Tot hauria d'estar unificat, almenys a l'hora de transmetre codi. Perquè hi havia tants contractistes com processos de desenvolupament diferents amb les seves pròpies peculiaritats. Calia encaixar tothom en aproximadament un, però amb opcions.
- Hi ha molts contractistes i la creació manual d'infraestructures no és adequada. Qualsevol tasca nova hauria de començar molt ràpidament, és a dir, la instància s'hauria de desplegar gairebé a l'instant perquè els desenvolupadors tinguin un conjunt de solucions per gestionar el seu pipeline.
Per fer el primer pas, calia entendre què es feia. I vam haver de determinar com arribar-hi. Vam començar ajudant a dibuixar l'arquitectura de la solució objectiu tant en infraestructures com en automatització CI/CD. Després vam començar a muntar aquesta cinta transportadora. Necessitàvem una infraestructura, la mateixa per a tothom, on circulessin els mateixos transportadors. Vam oferir opcions amb càlculs, va pensar el banc, i després va decidir què es construiria i amb quins fons.
El següent és la creació del circuit: instal·lació de programari, configuració. Desenvolupament d'scripts per al desplegament i gestió d'infraestructura. A continuació ve la transició al suport del transportador.
Vam decidir provar-ho tot al pilot. Curiosament, durant el pilotatge, una certa pila va aparèixer al banc per primera vegada. Entre altres coses, es va oferir un proveïdor nacional d'una de les solucions per a l'abast del pilot per a un llançament ràpid. La seguretat el va conèixer mentre pilotava i va deixar una impressió inoblidable. Quan vam decidir canviar, afortunadament, la capa d'infraestructura es va substituir per una solució Nutanix, que abans ja estava al banc. A més, abans era per a VDI, però el vam reutilitzar per a serveis d'infraestructura. En petits volums no encaixava en l'economia, però en grans volums es va convertir en un excel·lent entorn per al desenvolupament i proves.
La resta de la pila és més o menys familiar per a tothom. Es van utilitzar eines d'automatització a Ansible i els especialistes en seguretat van treballar estretament amb ells. El banc va utilitzar la pila Atlassin abans del projecte. Eines de seguretat de Fortinet: la van proposar els mateixos responsables de seguretat. El marc de prova va ser creat pel banc, sense fer cap pregunta. El sistema de repositoris va plantejar preguntes; m'havia d'acostumar.
Els contractistes van rebre una nova pila. Ens van donar temps per reescriure-ho per a GitlabCI i per migrar Jira al segment bancari, etc.
pas a pas
Pas 1. Primer, vam utilitzar una solució d'un venedor nacional, el producte es va connectar a un segment de xarxa DSO nou creat. La plataforma va ser escollida pel seu temps de lliurament, la flexibilitat d'escala i la possibilitat d'automatització total. Proves realitzades:
- Possibilitat de gestió flexible i totalment automatitzada de la infraestructura de la plataforma de virtualització (xarxa, subsistema de disc, subsistema de recursos informàtics).
- Automatització de la gestió del cicle de vida de les màquines virtuals (plantilles, instantànies, còpies de seguretat).
Després de la instal·lació i configuració bàsica de la plataforma, es va utilitzar com a punt de col·locació dels subsistemes de la segona etapa (eines DSO, esquemas de desenvolupament de sistemes comercials). Es van crear els conjunts de pipelines necessaris: creació, supressió, modificació, còpia de seguretat de màquines virtuals. Aquestes canonades es van utilitzar com a primera etapa del procés de desplegament.
El resultat és que l'equip subministrat no compleix els requisits de rendiment i tolerància a errors del banc. El DIT del banc va decidir crear un complex basat en el paquet de programari Nutanix.
Etapa 2. Vam agafar la pila que es va definir i vam escriure scripts d'instal·lació i post-configuració automatitzats per a tots els subsistemes perquè tot es transferís del pilot al circuit objectiu el més ràpidament possible. Tots els sistemes es van implementar en una configuració tolerant a errors (on aquesta capacitat no està limitada per les polítiques de llicència del venedor) i es van connectar a subsistemes de mètriques i recopilació d'esdeveniments. IB va analitzar el compliment dels seus requisits i va donar llum verda.
Etapa 3. Migració de tots els subsistemes i la seva configuració al nou PAC. Els scripts d'automatització d'infraestructura es van reescriure i la migració dels subsistemes DSO es va completar en un mode totalment automatitzat. Els contorns del desenvolupament IP van ser recreats pels pipelines dels equips de desenvolupament.
Pas 4. Automatització de la instal·lació de programari d'aplicació. Aquestes tasques les van fixar els caps d'equip dels nous equips.
Pas 5. Explotació.
Accés remot
Els equips de desenvolupament van demanar la màxima flexibilitat per treballar amb el circuit, i el requisit d'accés remot des d'ordinadors portàtils personals es va plantejar al principi del projecte. El banc ja tenia accés remot, però no era adequat per als desenvolupadors. El fet és que l'esquema utilitzava la connexió de l'usuari a un VDI protegit. Això era adequat per a aquells que només necessitaven correu i un paquet d'oficina al seu lloc de treball. Els desenvolupadors necessitarien clients pesats, d'alt rendiment, amb molts recursos. I per descomptat, havien de ser estàtics, ja que la pèrdua de la sessió d'usuari per als que treballen amb VStudio (per exemple) o un altre SDK és inacceptable. L'organització d'un gran nombre de VDI estàtics gruixuts per a tots els equips de desenvolupament va augmentar molt el cost de la solució VDI existent.
Vam decidir treballar en l'accés remot directament als recursos del segment de desenvolupament. Jira, Wiki, Gitlab, Nexus, bancs de construcció i proves, infraestructura virtual. Els guàrdies de seguretat han exigit que l'accés només es pugui proporcionar d'acord amb el següent:
- Utilitzant tecnologies ja disponibles al banc.
- La infraestructura no hauria d'utilitzar controladors de domini existents que emmagatzemen registres d'objectes de compte productiu.
- L'accés s'ha de limitar només als recursos requerits per un equip específic (de manera que un equip de producte no pot accedir als recursos d'un altre equip).
- Màxim control sobre RBAC en sistemes.
Com a resultat, es va crear un domini independent per a aquest segment. Aquest domini allotjava tots els recursos del segment de desenvolupament, tant les credencials d'usuari com la infraestructura. El cicle de vida dels registres d'aquest domini es gestiona mitjançant l'IdM existent al banc.
L'accés remot directe es va organitzar a partir dels equips existents del banc. El control d'accés es va dividir en grups AD, als quals corresponien regles sobre contextos (un grup de productes = un grup de regles).
Gestió de plantilles de VM
La velocitat de creació d'un bucle de muntatge i prova és un dels principals KPI establerts pel cap de la unitat de desenvolupament, ja que la velocitat de preparació de l'entorn afecta directament el temps d'execució global de la canalització. Es van considerar dues opcions per preparar imatges base de VM. El primer són les mides mínimes d'imatge, per defecte per a tots els productes del sistema, el màxim compliment de les polítiques de configuració del banc. La segona és la imatge base, que conté un POPPO resistent instal·lat, el temps d'instal·lació del qual podria influir molt en la velocitat d'execució de la canonada.
Durant el desenvolupament també es van tenir en compte els requisits d'infraestructura i seguretat: mantenir les imatges actualitzades (pegats, etc.), integració amb SIEM, configuració de seguretat segons els estàndards bancaris.
Com a resultat, es va decidir utilitzar imatges mínimes per tal de minimitzar el cost de mantenir-les actualitzades. És molt més fàcil actualitzar el sistema operatiu base que pegar cada imatge per a noves versions de POPPO.
A partir dels resultats, es va formar una llista del conjunt mínim de sistemes operatius necessaris, l'actualització dels quals la porta a terme l'equip d'operacions, i els scripts del pipeline són totalment responsables d'actualitzar el programari i, si cal, canviar la versió. del programari instal·lat: només cal transferir l'etiqueta necessària a la canalització. Sí, això requereix que l'equip de producte devops tingui escenaris de desplegament més complexos, però redueix molt el temps operatiu necessari per donar suport a les imatges base, que d'altra manera podria requerir més d'un centenar d'imatges de VM base per mantenir-les.
Accés a Internet
Un altre obstacle amb la seguretat bancària va ser l'accés als recursos d'Internet des de l'entorn de desenvolupament. A més, aquest accés es pot dividir en dues categories:
- Accés a la infraestructura.
- Accés per a desenvolupadors.
L'accés a la infraestructura s'ha organitzat mitjançant el proxy de repositoris externs amb Nexus. És a dir, no es va proporcionar accés directe des de les màquines virtuals. Això va permetre arribar a un compromís amb la seguretat de la informació, que era categòricament en contra de proporcionar qualsevol accés al món exterior des del segment de desenvolupament.
Els desenvolupadors necessitaven accés a Internet per raons òbvies (stackoverflow). I tot i que totes les ordres, com s'ha esmentat anteriorment, tenien accés remot al circuit, no sempre és convenient quan no podeu fer ctrl+v des del lloc de treball del desenvolupador al banc a l'IDE.
Es va arribar a un acord amb IS que inicialment, en fase de proves, l'accés es facilitarà a través d'un proxy bancari basat en una llista blanca. Un cop finalitzat el projecte, l'accés es transferirà a la llista negra. Es van preparar enormes taules d'accés, que indicaven els principals recursos i repositoris als quals calia accedir a l'inici del projecte. La coordinació d'aquests accessos va requerir una bona quantitat de temps, cosa que va permetre insistir en la transició més ràpida possible a les llistes negres.
Troballes
El projecte va acabar fa poc menys d'un any. Curiosament, tots els contractistes van canviar a la nova pila a temps i ningú va marxar a causa de la nova automatització. IB no té pressa per compartir comentaris positius, però tampoc es queixa, de la qual cosa podem concloure que els agrada. Els conflictes han disminuït perquè la seguretat de la informació torna a sentir-se controlada, però no interfereix amb els processos de desenvolupament. Es va donar més responsabilitat als equips i l'actitud global cap a la seguretat de la informació va millorar. El banc va entendre que la transició a DevSecOps era gairebé inevitable i, al meu entendre, ho va fer de la manera més suau i correcta.
Alexander Shubin, arquitecte de sistemes.
Font: www.habr.com