“In quanto CTO e cofondatore di DBmaestro, ho speso gli ultimi anni a capire e imparare come ottenere uno sviluppo agile, la continuous delivery e l’integrazione per il database, noto anche come DevOps per il database” afferma Yaniv Yehuda.

Dopo aver sostenuto innumerevoli conversazioni con leader del campo, CIO e CTO, Yehuda ha concluso che la ragione primaria per cui le aziende decidono di non adottare il DevOps per il database è di preservare la sicurezza del database stesso. Se la sicurezza del database avesse un ruolo più importate nel DevOps, le grandi aziende, soprattutto quelle che gestiscono dati sensibili, sarebbero più aperte all’adozione dell’agile e delle pratiche di continuous per il database.

DBmaestro si propone di aiutare le aziende a raggiungere i propri obiettivi di rilascio rapido, gestendo al contempo i rischi. La soluzione è il DevSecOps, che permette ai processi di sviluppo delle applicazioni di essere accelerati, sottoposti a test e rilasciati in modo controllato e organizzato.

Il bisogno di velocità
La sfida del DevSecOps per il database è di aumentare velocità ed efficienza senza perdere il controllo. Com’è possibile per le aziende essere più veloci e restare protetti allo stesso tempo? Chi pratica mountain bike conosce questo problema: per andare veloci, si deve mettere in conto qualche rischio.

Esiste un’ovvia ragione che spiega questo bisogno di velocità: i clienti non hanno pazienza. Ai tempi della metodologia waterfall, le soluzioni per le aziende testate a fondo venivano lanciate una o due volte all’anno. Ora, con l’adozione dell’agile e dei processi continui, hanno tutti fretta. Le aspettative sono alte e il tempo per dedicarsi ai dettagli è poco.

Le aziende che continuano ad avere successo nell’era del DevSecOps hanno imparato a rilasciare rapidamente applicazioni senza intoppi, in modo efficiente e con successo, grazie all’automazione. Tuttavia il database veniva trascurato, continuando a svolgere molte attività in modo manuale. Gli amministratori del database si sono ritrovati a dover svolgere l’incarico impossibile di tenere il passo con i processi continui, usando implementazioni manuali.

L’automazione del database è sicura?
Il problema riscontrato è che automatizzare il database non era come automatizzare il codice. Il database non è una raccolta di file su un file system, perciò, a differenza del codice, il database non può essere copiato. È questa la caratteristica che contribuisce alle inconsistenze tra gli ambienti come le derive di configurazione e le modifiche esterne ai processi. Gli sviluppatori di codice sono incoraggiati a sbagliare in fretta e sbagliare spesso, ma se gli sviluppatori del database adottassero questa filosofia per il database, le aziende ne pagherebbero il prezzo.

A causa di questi rischi il team DBA è diventato un collo di bottiglia. Prima del DevSecOps per il database, i team di sviluppo erano frustrati perché avrebbero voluto essere più agile e autosufficienti. I DBA, responsabili della salute e delle operazioni di continuous del database, dovevano prestare attenzione alla valutazione e alla gestione dei rischi delle modifiche, portando via tempo prezioso.

Quando le aziende applicano il DevSecOps per il database, sia i team di sviluppo, sia i DBA, condividono le responsabilità di custodia dei preziosi dati nel database. Lavorando insieme, possono stabilire delle regole di base e dei controlli dei processi, nonché creare processi ripetibili. Il lavoro collaborativo richiesto dal DevSecOps aiuta le aziende a superare in sicurezza le sfide dell’automazione dello sviluppo e del deploy del database per stare al passo con i sempre più rapidi tempi di rilascio.

DevSecOps in azione
Il DevSecOps per il database crea le condizioni per un rilascio sicuro degli script del database. Ciò significa prepararsi alle derive di configurazione, alle modifiche esterne ai processi, aderire alla conformità normativa e alle richieste di revisione. Tutto ciò permetterà rilasci sicuri e rapidi in ambienti strutturati.

Per prima cosa, i team devono essere conformi alle regole della policy e capire i ruoli di ogni membro. In secondo luogo, è fondamentale impostare le regole per prevenire le modifiche che non sono conformi con la policy organizzativa. Inoltre, i cambiamenti ammessi dalle audit in fase di esecuzione degli aggiornamenti aggiungeranno un’ulteriore linea di difesa per prevenire errori del codice e inattività del database. In altre parole, qui ci si concentra sull’analisi d’impatto e non sul controllo dei danni.

Abilitare il rollback durante questa fase è imperativo per avere modifiche al database sicure. Per ottenere un processo sicuro, rapido e attendibile, questi step devono essere eseguiti alla perfezione. Dopo questo processo, comprendere chi ha fatto quale modifica, quando, dove e perché, è fondamentale per esaminare se questo processo può essere ripetuto (o automatizzato) o se il team DevSecOps deve tornare alla fase di pianificazione.

Non tralasciare il database
Non si tratta semplicemente di avere a che fare col database, ma con le intere applicazioni. La stessa rete di sicurezza costruita per i rilasci del codice può essere applicata al database avendo attivato una giusta pipeline di continuous delivery. Una delle maggiori preoccupazioni per le aziende che hanno a che fare con informazioni sensibili – in particolare il settore finanziario – è l’inattività, costosa sia in termini di denaro, a causa dei milioni di dollari persi, sia in termini di tempo, dovendo l’azienda tornare a ricostruirsi una reputazione.

Aziende che, come può essere comprensibile, non vogliono avvicinarsi all’automazione per evitare questi rischi, verranno superate perché non soddisfano le richieste dei clienti. Le aziende finanziarie devono capire che esiste una soluzione sicura e attuabile per automatizzare i rilasci del database e il ROI che ne deriverà ricompenserà i loro sforzi.

Accedi alla nostra area risorse e scarica il materiale di approfondimento
Accedi alla nostra area risorse e scarica il materiale di approfondimento