DevOps vs DevSecOps: come appariva in una banca

La banca esternalizza i suoi progetti a molti appaltatori. Gli “esterni” scrivono codice, quindi trasmettono i risultati in una forma non molto conveniente. Nello specifico, il processo è stato questo: hanno consegnato un progetto che ha superato con loro i test funzionali, e poi è stato testato all'interno del perimetro bancario per integrazione, carico e così via. Spesso si scopriva che i test fallivano. Quindi tutto è tornato allo sviluppatore esterno. Come puoi immaginare, ciò significava tempi lunghi per la correzione dei bug.

La banca ha deciso che era possibile e necessario trascinare sotto la sua ala protettrice l'intera pipeline, dagli impegni al rilascio. Affinché tutto sia uniforme e sotto il controllo dei team responsabili del prodotto in banca. Cioè, come se l'appaltatore esterno stesse semplicemente lavorando da qualche parte nella stanza accanto dell'ufficio. Nello stack aziendale. Questo è un normale devops.

Da dove viene Sec? La sicurezza della banca pone requisiti elevati su come un collaboratore esterno può lavorare nel segmento di rete, quale accesso ha qualcuno, come e chi lavora con il codice. È solo che IB non sapeva ancora che quando gli appaltatori lavorano all’esterno, vengono seguiti pochi standard bancari. E poi tra un paio di giorni tutti dovranno iniziare a osservarli.

La semplice scoperta che l'appaltatore aveva pieno accesso al codice del prodotto aveva già sconvolto il loro mondo.

In questo momento è iniziata la storia di DevSecOps, di cui voglio parlarvi.

Quali conclusioni pratiche ha tratto la banca da questa situazione?

Ci sono state molte polemiche sul fatto che tutto venga fatto nel modo sbagliato. Gli sviluppatori hanno affermato che la sicurezza è impegnata solo a cercare di interferire con lo sviluppo e loro, come guardiani, cercano di vietare senza pensare. A loro volta, gli specialisti della sicurezza esitavano tra la scelta tra i punti di vista: “gli sviluppatori creano vulnerabilità nel nostro circuito” e “gli sviluppatori non creano vulnerabilità, ma sono essi stessi”. La disputa sarebbe continuata a lungo se non fosse stato per le nuove richieste del mercato e l’emergere del paradigma DevSecOps. È stato possibile spiegare che proprio questa automazione dei processi, tenendo conto dei requisiti di sicurezza delle informazioni "fuori dagli schemi", aiuterà tutti a rimanere felici. Nel senso che le regole vengono scritte immediatamente e non cambiano durante il gioco (la sicurezza informatica non proibirà qualcosa di inaspettato), e gli sviluppatori tengono informata la sicurezza informatica su tutto ciò che accade (la sicurezza informatica non incontra qualcosa all'improvviso) . Ogni squadra è anche responsabile della sicurezza finale e non di alcuni fratelli maggiori astratti.

1. Poiché i dipendenti esterni hanno già accesso al codice e a una serie di sistemi interni, è probabilmente possibile eliminare dai documenti il ​​requisito “lo sviluppo deve essere effettuato interamente sull’infrastruttura della banca”.
2. D’altra parte, dobbiamo rafforzare il controllo su ciò che sta accadendo.
3. Il compromesso è stata la creazione di team interfunzionali, in cui i dipendenti lavorano a stretto contatto con persone esterne. In questo caso, devi assicurarti che il team lavori sugli strumenti presenti sui server della banca. Dall'inizio alla fine.

Cioè, gli appaltatori possono essere ammessi, ma devono ricevere segmenti separati. Per non portare qualche tipo di infezione dall’esterno nell’infrastruttura della banca e per non vedere più del necessario. Bene, in modo che le loro azioni vengano registrate. DLP per la protezione dalle perdite, tutto questo era incluso.

In linea di principio, prima o poi tutte le banche arrivano a questo punto. Qui abbiamo seguito la strada battuta e abbiamo concordato i requisiti per gli ambienti in cui lavorano gli "esterni". È apparsa una gamma massima di strumenti di controllo degli accessi, strumenti di controllo delle vulnerabilità, analisi antivirus su circuiti, assemblaggi e test. Questo si chiama DevSecOps.

All’improvviso è diventato chiaro che se prima DevSecOps la sicurezza bancaria non aveva alcun controllo su ciò che accade dal lato dello sviluppatore, nel nuovo paradigma la sicurezza viene controllata allo stesso modo degli eventi ordinari sull’infrastruttura. Solo ora ci sono gli avvisi sugli assembramenti, il controllo delle biblioteche e così via.

Non resta che trasferire le squadre al nuovo modello. Bene, crea l'infrastruttura. Ma queste sono sciocchezze, è come disegnare un gufo. In realtà abbiamo aiutato con l'infrastruttura e in quel momento i processi di sviluppo stavano cambiando.

Cosa è cambiato

Abbiamo deciso di implementarlo a piccoli passi, perché abbiamo capito che molti processi sarebbero crollati e molti “esterni” potrebbero non essere in grado di sopportare le nuove condizioni di lavoro sotto la supervisione di tutti.

Innanzitutto, abbiamo creato team interfunzionali e imparato a organizzare i progetti tenendo conto delle nuove esigenze. Nel senso organizzativo abbiamo discusso quali processi. Il risultato è stato uno schema della pipeline di assemblaggio con tutti i responsabili.

• CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• Test: Sonarqube, SoapUI, jMeter, Selenio: MF Fortify, Performance Center, MF UFT, Ataccama.
• Presentazione del concorso (reporting, comunicazione): Grafana, Kibana, Jira, Confluence, RocketChat.
• Operazioni (manutenzione, gestione): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Pila selezionata:

• Base di conoscenza - Confluenza Atlassiana;
• Tracker attività - Atlassian Jira;
• Repository di artefatti - "Nexus";
• Sistema di integrazione continua - “Gitlab CI”;
• Sistema di analisi continua - “SonarQube”;
• Sistema di analisi della sicurezza delle applicazioni - “Micro Focus Fortify”;
• Sistema di comunicazione - “GitLab Mattermost”;
• Sistema di gestione della configurazione - “Ansible”;
• Sistema di monitoraggio: "ELK", "TICK Stack" ("InfluxData").

Cominciarono a creare una squadra pronta a trascinare all'interno gli appaltatori. Ci si rende conto che ci sono diverse cose importanti:

• Tutto dovrebbe essere unificato, almeno durante la trasmissione del codice. Perché c'erano tanti committenti quanti erano i diversi processi di sviluppo con le proprie peculiarità. Era necessario adattare tutti approssimativamente a uno, ma con opzioni.
• Ci sono molti appaltatori e la creazione manuale delle infrastrutture non è adatta. Qualsiasi nuova attività dovrebbe iniziare molto rapidamente, ovvero l'istanza dovrebbe essere distribuita quasi istantaneamente in modo che gli sviluppatori abbiano una serie di soluzioni per gestire la propria pipeline.

Per fare il primo passo era necessario capire cosa si stava facendo. E dovevamo determinare come arrivarci. Abbiamo iniziato aiutando a disegnare l'architettura della soluzione target sia nell'infrastruttura che nell'automazione CI/CD. Quindi abbiamo iniziato ad assemblare questo trasportatore. Avevamo bisogno di un’infrastruttura, uguale per tutti, dove circolassero gli stessi trasportatori. Abbiamo offerto opzioni con calcoli, ha pensato la banca, poi abbiamo deciso cosa sarebbe stato costruito e con quali fondi.

La prossima è la creazione del circuito: installazione del software, configurazione. Sviluppo di script per la distribuzione e la gestione dell'infrastruttura. Poi arriva il passaggio al supporto del trasportatore.

Abbiamo deciso di testare tutto sul pilota. È interessante notare che durante il pilotaggio un certo stack è apparso per la prima volta in banca. Tra le altre cose, per l'ambito del progetto pilota è stato offerto un fornitore nazionale di una delle soluzioni per un lancio rapido. La sicurezza lo ha conosciuto mentre pilotava e ha lasciato un'impressione indimenticabile. Quando abbiamo deciso di cambiare, fortunatamente, il livello infrastrutturale è stato sostituito con una soluzione Nutanix, che già prima era in banca. Inoltre, prima era per VDI, ma lo abbiamo riutilizzato per i servizi infrastrutturali. A piccoli volumi non si adattava all'economia, ma a grandi volumi divenne un ambiente eccellente per lo sviluppo e il test.

Il resto dello stack è più o meno familiare a tutti. Sono stati utilizzati gli strumenti di automazione di Ansible e gli specialisti della sicurezza hanno lavorato a stretto contatto con loro. Lo stack Atlassin è stato utilizzato dalla banca prima del progetto. Strumenti di sicurezza Fortinet: è stato proposto dagli stessi addetti alla sicurezza. Il quadro di prova è stato creato dalla banca, senza fare domande. Il sistema di repository sollevava domande; dovevo abituarmi.

Agli appaltatori è stata assegnata una nuova pila. Ci hanno dato il tempo di riscriverlo per GitlabCI e di migrare Jira nel segmento bancario e così via.

passo dopo passo

Step 1. Innanzitutto, abbiamo utilizzato una soluzione di un fornitore nazionale, il prodotto è stato collegato a un nuovo segmento di rete DSO creato. La piattaforma è stata scelta per i tempi di consegna, la flessibilità di scalabilità e la possibilità di automazione completa. Test condotti:

• Possibilità di gestione flessibile e completamente automatizzata dell'infrastruttura della piattaforma di virtualizzazione (rete, sottosistema dischi, sottosistema risorse di calcolo).
• Automazione della gestione del ciclo di vita delle macchine virtuali (template, snapshot, backup).

Dopo l'installazione e la configurazione di base della piattaforma, è stata utilizzata come punto di posizionamento dei sottosistemi della seconda fase (strumenti DSO, schemi di sviluppo dei sistemi di vendita al dettaglio). Sono stati creati i set necessari di pipeline: creazione, cancellazione, modifica, backup di macchine virtuali. Queste pipeline sono state utilizzate come prima fase del processo di distribuzione.

Il risultato è che le apparecchiature fornite non soddisfano i requisiti della banca in termini di prestazioni e tolleranza ai guasti. Il DIT della banca ha deciso di creare un complesso basato sul pacchetto software Nutanix.

fase 2. Abbiamo preso lo stack definito e scritto script di installazione automatizzata e post-configurazione per tutti i sottosistemi in modo che tutto fosse trasferito dal circuito pilota al circuito di destinazione il più rapidamente possibile. Tutti i sistemi sono stati distribuiti in una configurazione con tolleranza agli errori (dove questa capacità non è limitata dalle politiche di licenza del fornitore) e collegati a parametri e sottosistemi di raccolta eventi. IB ha analizzato la conformità ai requisiti e ha dato il via libera.

fase 3. Migrazione di tutti i sottosistemi e delle relative impostazioni al nuovo PAC. Gli script di automazione dell'infrastruttura sono stati riscritti e la migrazione dei sottosistemi DSO è stata completata in modalità completamente automatizzata. I contorni dello sviluppo IP sono stati ricreati dalle pipeline dei team di sviluppo.

Step 4. Automazione dell'installazione del software applicativo. Questi compiti sono stati stabiliti dai responsabili dei nuovi team.

Step 5. Sfruttamento.

Accesso remoto

I team di sviluppo hanno chiesto la massima flessibilità nell'utilizzo del circuito e già all'inizio del progetto è stata avanzata la richiesta di accesso remoto da laptop personali. La banca disponeva già di un accesso remoto, ma non era adatto agli sviluppatori. Il fatto è che lo schema utilizzava la connessione dell’utente a una VDI protetta. Questo era adatto a coloro che avevano bisogno solo della posta e di un pacco da ufficio sul posto di lavoro. Gli sviluppatori avrebbero bisogno di client pesanti, ad alte prestazioni e con molte risorse. E ovviamente dovevano essere statici, poiché la perdita della sessione utente per chi lavora con VStudio (ad esempio) o altri SDK è inaccettabile. L'organizzazione di un gran numero di VDI statici spessi per tutti i team di sviluppo ha aumentato notevolmente il costo della soluzione VDI esistente.

Abbiamo deciso di lavorare sull'accesso remoto direttamente alle risorse del segmento sviluppo. Jira, Wiki, Gitlab, Nexus, costruisci e testa banchi, infrastrutture virtuali. Le guardie di sicurezza hanno chiesto che l'accesso possa essere fornito solo alle seguenti condizioni:

1. Utilizzando tecnologie già disponibili in banca.
2. L'infrastruttura non deve utilizzare controller di dominio esistenti che archiviano record di oggetti account produttivi.
3. L'accesso dovrebbe essere limitato solo alle risorse richieste da un team specifico (in modo che un team di prodotto non possa accedere alle risorse di un altro team).
4. Massimo controllo su RBAC nei sistemi.

Di conseguenza, per questo segmento è stato creato un dominio separato. Questo dominio ospitava tutte le risorse del segmento di sviluppo, sia le credenziali dell'utente che l'infrastruttura. Il ciclo di vita dei record in questo dominio è gestito utilizzando l'IdM esistente in banca.

L’accesso remoto diretto è stato organizzato sulla base delle dotazioni esistenti della banca. Il controllo degli accessi era suddiviso in gruppi AD, ai quali corrispondevano regole sui contesti (un gruppo di prodotti = un gruppo di regole).

Gestione dei modelli di macchina virtuale

La velocità di creazione di un ciclo di assemblaggio e test è uno dei principali KPI stabiliti dal responsabile dell'unità di sviluppo, poiché la velocità di preparazione dell'ambiente influisce direttamente sul tempo di esecuzione complessivo della pipeline. Sono state prese in considerazione due opzioni per preparare le immagini VM di base. La prima riguarda le dimensioni minime delle immagini, predefinite per tutti i prodotti del sistema, il massimo rispetto delle politiche della banca in merito alle impostazioni. La seconda è l'immagine di base, che contiene un POPPO pesante installato, il cui tempo di installazione potrebbe influenzare notevolmente la velocità di esecuzione della pipeline.

Durante lo sviluppo sono stati presi in considerazione anche i requisiti di infrastruttura e sicurezza: aggiornamento delle immagini (patch, ecc.), integrazione con SIEM, impostazioni di sicurezza secondo gli standard bancari.

Di conseguenza, si è deciso di utilizzare immagini minime per ridurre al minimo il costo di mantenerle aggiornate. È molto più semplice aggiornare il sistema operativo di base piuttosto che applicare patch a ciascuna immagine per le nuove versioni di POPPO.

Sulla base dei risultati, è stato formato un elenco del set minimo richiesto di sistemi operativi, il cui aggiornamento viene effettuato dal team operativo e gli script della pipeline sono interamente responsabili dell'aggiornamento del software e, se necessario, della modifica della versione del software installato: basta trasferire il tag richiesto nella pipeline. Sì, ciò richiede che il team di prodotto devops abbia scenari di distribuzione più complessi, ma riduce notevolmente il tempo operativo necessario per supportare le immagini di base, che altrimenti potrebbero richiedere la manutenzione di più di cento immagini VM di base.

Accesso a Internet

Un altro ostacolo alla sicurezza bancaria era l'accesso alle risorse Internet dall'ambiente di sviluppo. Inoltre, questo accesso può essere suddiviso in due categorie:

1. Accesso alle infrastrutture.
2. Accesso sviluppatore.

L'accesso all'infrastruttura è stato organizzato delegando repository esterni con Nexus. Cioè, non è stato fornito l'accesso diretto dalle macchine virtuali. Ciò ha permesso di raggiungere un compromesso con la sicurezza delle informazioni, che era categoricamente contrario a qualsiasi accesso al mondo esterno da parte del segmento di sviluppo.

Gli sviluppatori avevano bisogno dell'accesso a Internet per ovvi motivi (stackoverflow). E sebbene tutti i comandi, come accennato in precedenza, avessero accesso remoto al circuito, non è sempre conveniente quando non è possibile eseguire ctrl+v dal posto di lavoro dello sviluppatore in banca nell'IDE.

È stato raggiunto un accordo con IS che inizialmente, in fase di test, l'accesso sarà fornito tramite proxy bancario basato su una white-list. Al termine del progetto, l'accesso verrà trasferito alla black-list. Sono state preparate enormi tabelle di accesso, che indicavano le principali risorse e archivi a cui era richiesto l'accesso all'inizio del progetto. Il coordinamento di questi accessi ha richiesto molto tempo, il che ha permesso di insistere su una transizione quanto più rapida possibile alle liste nere.

Giudizio

Il progetto si è concluso poco meno di un anno fa. Stranamente, tutti gli appaltatori sono passati in tempo al nuovo stack e nessuno se ne è andato a causa della nuova automazione. IB non ha fretta di condividere feedback positivi, ma non si lamenta nemmeno, da cui possiamo concludere che gli piace. I conflitti si sono attenuati perché la sicurezza informatica sente di nuovo il controllo, ma non interferisce con i processi di sviluppo. Ai team sono state assegnate maggiori responsabilità e l'atteggiamento generale nei confronti della sicurezza delle informazioni è migliorato. La banca ha capito che il passaggio a DevSecOps era quasi inevitabile e lo ha fatto, a mio avviso, nel modo più delicato e corretto.

Alexander Shubin, architetto di sistema.

Fonte: habr.com