Nell’ambito della software engineering, con il termine security by design si intende un software progettato, fin dalla prima fase di sviluppo, per essere sicuro. Nello scenario attuale le pratiche malevole di attacco e modifica delle componenti software, inerenti alle varie architetture informatiche sia in ambito pubblico che privato, sono in continua crescita. Il concetto alla base dell’applicazione della security by design consiste nel cercare di minimizzare gli impatti su infrastrutture, applicazioni e servizi scaturenti da queste attività, nonché di salvaguardare i dati contenuti al loro interno. Gli strumenti a disposizione degli sviluppatori sono molteplici e possono essere applicati lungo le diverse fasi dello sviluppo, dalla progettazione sino al testing. Tuttavia, nonostante ciò, la maggior parte dei sistemi vengono colpiti da attacchi che sfruttano vulnerabilità dei software. Principalmente tali vulnerabilità possono essere ricondotte ad errori presenti nel codice, errori che possono mettere a rischio la sicurezza dei dati che vengono trattati. Si fa riferimento a vulnerabilità di sicurezza quando ci si trova di fronte ad un problema del software di cui è stato scoperto un metodo (exploit) sfruttabile a vantaggio dell’attaccante; in assenza di tali veicoli di attacco siamo in presenza di un semplice bug. Le vulnerabilità di sicurezza hanno un loro ciclo di vita; dal momento in cui vengono scoperte sino al momento in cui viene applicata la dovuta correzione (la patch) cambia il livello di rischio a cui si è esposti.
In particolare, le fasi più pericolose possono essere ricondotte sostanzialmente all’istante in cui la vulnerabilità viene comunicata al pubblico sino al momento in cui viene effettuato un primo intervento di aggiornamento dei tool necessari all’attuazione della correzione (Fig. 1) )1.
Il problema delle vulnerabilità ed il relativo discorso inerente la sicurezza dei sistemi assume oggi una connotazione particolare se si prendono in consederazione le moderne tecniche di IT Automation e la loro estensione alle principali tecnologie/metodologie presenti nell’infrastrutturaIT aziendale.
La scalabilità senza precedenti richiesta oggi ai moderni e dinamici ambienti IT si può ottenere solo attraverso l’automazione. In particolare, la continua ricerca della riduzione della complessità tramite il ricorso all’automazione all’interno delle strutture software/hardware aziendali richiede un costante e rapido scambio di informazioni tra gli attori impegnati nelle business unit relative ai reparti Development e Operations dell’IT. Questi hanno la necessità di operare uno sviluppo costante degli ambienti software per far fronte, verso una semplificazione della gestione dell’IT da un lato e la ricerca continua della conformità dall’altro. Quest’ultima, che noi chiamiamo confomità adattiva, è quanto riteniamo occorra per far fornte in modo nuovo ed efficace alla crescente minaccia delle azioni malevole intraprese dagli attaccanti nello sfruttare le vulnerabilità dei sistemi.
IL RUOLO DELLA IT AUTOMATION
Con automazione dell’IT, anche detta automazione dell’infrastruttura, si intende l’uso di software per creare istruzioni e processi ripetibili con i quali sostituire o ridurre l’interazione del personale con i sistemi IT (Infrastructure as Code). I software di automazione operano entro i vincoli delle istruzioni, degli strumenti e delle strutture date, per eseguire le attività con un intervento manuale minimo o nullo. Grazie all’impiego dell’automazione i tool software, i framework e gli applicativi in generale riescono a condurre i propri task con il minimo intervento da parte degli addetti ai lavori.
Generalmente essa si basa su strumenti software per riuscire a definire e gestire una serie prescritta di azioni dettagliate immesse manualmente o tramite “trigger” esterno. Con l’automazione sostanzialmente vengono sostituite una serie di azioni che in precedenza venivano svolte manualmente con tempi più lunghi e tassi di errore più alti. L’automazione è una scelta strategica che consente l’ottimizzazione dell’IT e la trasformazione digitale dei processi. Di fatti l’inserimento in azienda di processi automatizzati risulta particolarmente utile quando si vanno a industrializzare quelle attività che un amministratore IT o il suo personale devono eseguire di frequente; la possibilità di poter affidare ad un processo automatizzato determinate mansioni fa guadagnare tempo alle risorse umane e permette una considerevole riduzione degli errori e dei costi per l’impresa (Fig. 2)2.
Ma cosa prevede l’automazione dell’IT e quando risulta essere una pratica indicata?
In linea teorica, è possibile automatizzare qualsiasi processo IT, almeno in parte. L’automazione può essere applicata e integrarsi all’automazione della rete, al provisioning3 di risorse e servizi cloud e infrastrutturali nonché al deployment delle applicazioni e alla gestione delle configurazioni. Inoltre, proprio in virtù del fatto che è possibile automatizzare la maggior parte dei processi, l’automazione può configurarsi come una pratica indicata in qualsiasi scenario; un approccio globale all’automazione dell’IT può evitare al personale di dedicarsi a processi ripetitivi e manuali, consentendo una maggiore produttività, riducendo gli errori, migliorando la collaborazione e offrendo più tempo da destinare ad attività che richiedono maggiori capacità decisionali e di valutazione.
In particolare, in merito all’attività di provisioning, essa è nel complesso un’attività onerosa sia che venga svolta su ambienti fisici che in cloud. Per un più efficiente funzionamento dei sistemi aziendali è indispensabile un’infrastruttura che può essere operata ed orchestrata come se fosse software. I Data Center che ospitano rack, apparati e cavi, oggi rappresentano il luogo fisico di creazione e gestione di risorse virtualizzate come reti, sistemi di storage, container e macchine virtuali. La maggior parte di questi elementi è oggi definita da software (Software Defined Data Center), aspetto questo che ha contribuito ad aumentare la scalabilità e ad aprire la strada a molteplici possibilità di integrazione e gestione. Inoltre, il passaggio al software garantisce (e richiede) la codifica dei processi. Ciò consente di soddisfare in modo preciso e granulare le richieste dell’azienda, che opera quindi con maggiore consapevolezza dei costi e dei vincoli in termini di tempo.
Proprio in questo ambito si colloca l’automazione. Configurare diversi ambienti applicando manualmente i modelli di configurazione è un’attività che porta via molto tempo; problema questo che può essere risolto proprio grazie alla codifica, che permette di eseguire queste operazioni grazie all’applicazione di un modello unico e standard. Una volta sviluppato ed integrato il modello, si potrà impostare l’esecuzione automatica e autonoma delle regole e dei passaggi previsti. Un’automazione che si integra nell’infrastruttura e nei sistemi di gestione esistenti per la gestione dei deployment nel Data Center, consente di usufruire appieno delle risorse che sono già a disposizione per raggiungere obiettivi prefissati.
Tuttavia, non tutte le applicazioni vengono dispiegate nello stesso modo; le stesse possono infatti presentare diverse impostazioni, richiedere diversi file system, abilitare utenti particolari, determinate porte, ecc.. Una volta automatizzato il provisioning, sarà necessario dare istruzioni a tutte queste risorse. Memorizzare le caratteristiche di un ambiente applicativo in un documento, foglio di calcolo, file di testo non aiuta a ottenere un ambiente ripetibile e solido nel quale ospitare le applicazioni. Man mano che i sistemi e le complessità aumentano, diventa indispensabile la possibilità di eseguire una modalità alternativa che consenta di registrare il profilo dei sistemi e di poterli quindi gestire in modo efficace e ripetibile. Per ottenere tale risultato è necessario adottare una solida soluzione che sia in grado di gestire le configurazioni e che consenta agli sviluppatori di definire semplicemente l’infrastruttura (fisica, virtualizzata, in cloud ecc.) in modo che possa essere facilmente compresa da tutto il personale IT4.
Più semplice è l’automazione di script e di pratiche specifiche per la gestione del sistema, più facile risulterà portare a termine le attività. Occorre dunque gestire le configurazioni in modo snello e riproducibile, usando tool e pratiche di automazione di ambienti di sviluppo e produzione. Questi ultimi, al pari di altri elementi software dello stack, vengono gestiti e versionati usando linguaggi che sono contemporaneamente machine-readable e human-readable. Ciò consente una loro istantanea riproduzione in caso di necessità di espansione o di rimedio a disastri di qualsiasi tipo: si è subito pronti con gli ambienti e quindi immediatamente operativi con lo sviluppo. Anche il deployment delle applicazioni diventa un’operazione automatica, infinitamente riproducibile e priva di errori umani. Si parla di auto-documentazione, in quanto la descrizione degli ambienti di sviluppo, test e produzione avviene in modo formale e comprensibile sia dall’essere umano che dalla macchina, potendo essa stessa subire il ciclo di revisione e miglioramento progressivo del software.
Qual è dunque il ruolo della cybersecurity in tale contesto e come muta l’approccio al mantenimento di alti livelli di sicurezza?
Con l’introduzione del Cloud e delle Infrastrutture IT automatizzate, si industrializza e velocizza il rollout di nuovo software e si introduce una Quality of Experience nettamente superiore per gli operatori ed i responsabili della sicurezza. Ogni aspetto della configurazione dei sistemi e delle applicazioni viene messo facilmente sotto controllo, La sfida diventa la ricerca continua di conformità della configurazione delle componenti IT nei diversi livelli di astrazione, di aderenza agli standard industriali, di continua tensione verso le buone prassi in incessante evoluzione. Diversamente dal passato questa ricerca può essere condotta in modo sistematico e non artigianale, senza rinunciare ad usufruire dinamicamente dell’infrastruttura, adattandosi on-demand a richieste di banda/computing e storage comunque mutevoli nel tempo. Ma anzi giovandosi essa stessa di tale dinamicità e diventando quindi una ricerca di conformità adattiva.
Il Software Defined Datacenter ha introdotto un cambio di paradigma nell’implementazione di sistemi di storage, networking, capacità computazionale e security. In passato il networking e la security erano relegate in un unico hardware dedicato. Questo necessariamente portava ad un aumento dei costi operativi e della complessità di gestione. Oggi nelle architetture software-defined cambia il modo in cui i vari elementi interagiscono e l’orchestrazione, ovverosia il dispiegamento su scala temporale dei task che compongono le operazioni, acquisisce un’importanza centrale. Di qui nasce l’attenzione per i framework che supportano la definizione delle modalità in cui la security deve evolvere nelle varie componenti architetturali del datacenter e dei servizi cloud-based. Tali framework dovranno integrarsi sempre di più con le principali piattaforme per il Software Defined Datacenter. I sistemi per il Software Defined Networking, ad esempio, esaltano il concetto di disaccoppiamento tra piano di controllo, che indirizza e dirige i flussi, e piano dati, che trasporta il traffico; concetto che è centrale in ambito di Security Governance.
L’approccio tradizionale alla sicurezza delle infrastrutture, è basato sulla sicurezza perimetrale e sulla protezione dei punti di ingresso. Ma i pattern di traffico all’interno dei Data Center hanno subito una metamorfosi notevole, estendendo la superficie di attacco e aumentando il numero di punti da monitorare. Del resto i Firewall non possono essere collocati ovunque. Né esistono soluzioni tradizionali per progettere le infrastrutture effimere. Di qui nasce il concetto di microsegmentazione in domini virtuali, che coprono tutta la superficie di attacco. Proteggendo ogni dominio microsegmentato, si protegge l’intera infrastruttura sia in direzione Nord-Sud, ossia relativamente al traffico tra il Datacenter e tutto ciò che sta fuori dal Datacenter (come da approccio tradizionale), che in direzione Est-Ovest (traffico inter host all’interno del Datacenter), considerando non trustful anche il traffico intra-host (all’interno del singolo host tra diverse risorse virtualizzate al suo interno). Access Control List e policy di sicurezza vengono così applicate a tutte le risorse fisiche e virtuali del Datacenter, in modo da contenere gli attacchi e minimizzare l’impatto delle intrusioni.
Soluzioni innovative per la Cyber Security in contesti di Software Defined IT devono quindi:
- essere integrate nativamente nei flussi di orchestrazione e automazione;
- essere integrate nativamente nei flussi di orchestrazione e automazione (SDN);
- semplificare l’applicazione delle politiche di sicurezza anche nei flussi di traffico Est-Ovest;
- mantenere il controllo dei canali di comunicazione tra i diversi host virtuali;
- evitare movimenti laterali di agenti malevoli (compromissione o danneggiamento di servizi o sottrazione di dati sensibili).
La microsegmentazione in domini virtuali protetti realizza la cosiddetta Zero Trust security. Zero trust è un modello di sicurezza basato sul principio di mantenere severi controlli di accesso e di non fidarsi di nessuno per impostazione predefinita, anche quelli già all’interno del perimetro della rete, in base al concetto “never trust, always verify”.
Una Zero Trust network deve soddisfare i seguenti requisiti:
- Essere indipendente dalla piattaforma e pronta per l’integrazione di risorse virtuali, e.g. Virtual Machine
- Avere un’architettura orientata al soddisfacimento di obiettivi di conformità adattiva
- Essere scalabile e flessibile
- Avere un’architettura segmentata
- Essere estensibile
Una rete gerarchica tradizionale deve evolvere versa una topologia maggiormente piatta e magliata (meshed).
Deve inoltre essere fabric-friendly ovvero orientata ad un approccio industriale alla sicurezza, il che conduce ad un approccio alla conformità adattiva. Oltre a garantire un accesso sicuro, è necessario poter ispezionare e loggare ogni tipo di traffico, funzione che viene svolta da specifici elementi denominati segmentation gateway che svolgono molteplici funzioni di controllo in diversi livelli di astrazione (firewall, intrusion prevention system, access control, account management, protocolli crittografici).
Infine le reti Zero Trust abilitano meccanismi di ruoli e permessi non solo per gli utenti e per le applicazioni, ma anche per i dati, che vengono trattati come entità viventi per accedere alle quali è necessario utilizzare speciali identificativi denominati Data ID (in analogia con gli User ID e gli Application ID).
TECNOLOGIA DEI CONTAINER E METODOLOGIA DEVOPS
Il processo di automazione dell’IT, viene applicato anche attraverso tecnologie specifiche quali i container e anche ad alcune metodologie come il DevOps.
I container consentono il frazionamento del software in Microservices, ovvero servizi elementari in cui viene decomposto un servizio complesso. I microservizi vengono incapsulati in strutture autoconsistenti, i container appunto. La Service Oriented Architecture (SOA) ha mandato in pensione lo sviluppo di applicazioni monolitiche, ma ha lasciato in piedi dipendenze funzionali pesanti tra i vari strati architetturali (front-end, back-end, DB…) che di fatto non hanno semplificato di molto la gestione di progetti software via via più complessi. Oggi si tende invece a disaccoppiare drasticamente le componenti funzionali elementari, conferendo piena autonomia ad ognuna (es., un DB per ogni microservizio) e coordinandole liberamente in grafi orientati in continua evoluzione. Si sposta quindi la complessità sul networking, gestibile in modo trasversale e generale.
Ognuno di questi microservizi viene containerizzato in modo da renderlo auto-consistente e portabile in altri ambienti. Nelle immagini dei container viene inserito quanto necessario al deployment dei container in un ambiente diverso, portandosi dietro tutte le dipendenze necessarie, le quali non devono quindi essere soddisfatte nel nuovo ambiente. I container sono oggetti leggeri, che favoriscono la scaling orizzontale, ovverosia la creazione di nuovi container identici e messa in batteria per scopi di bilanciamento e affidabilità. Versionando le immagini dei container si ottiene software costantemente aggiornato e, ciononostante, immediatamente disponibile per deployment istantanei su infrastrutture che sono, a loro volta, immutabili e riproducibili in virtù degli strati precedenti.
I container consentono dunque l’esecuzione delle applicazioni e delle relative dipendenze, in processi isolati dalle risorse hardware e software sottostanti e offrono notevoli vantaggi rispetto alle macchine virtuali. La differenza fondamentale tra la tecnologia container e la classica virtualizzazione si trova a livello del sistema operativo. Di fatti nei container, il sistema operativo viene condiviso tra tutte le istanze in esecuzione su di esso, formula questa che garantisce una forte riduzione in termini di risorse computazionali e di memoria utilizzate. I molteplici benefici apportati dall’adozione di soluzioni basate su container stanno spingendo le aziende a pianificare progetti di migrazione verso questa soluzione, specie in contesti cloud-native. In particolare, sono molteplici gli scenari che hanno tipicamente come target le soluzioni a container come ad esempio:
- Creazione di un ambiente multi-cloud: la forte standardizzazione e la portabilità dei container facilitano la creazione di ambienti ibridi e multi-cloud.
- Adozione di metodologie DevOps: i container facilitano l’adozione di metodologie DevOps supportando l’intera pipeline di sviluppo ed abilitando rilasci automatici ed incrementali direttamente nell’ambiente di produzione.
Il vero punto di forza della tecnologia container risiede nel fatto che essa è supportata dalla complementarietà alla classica virtualizzazione e da una serie di benefici garantiti dalla sua adozione quali:
- Implementazione rapida: in quanto ogni applicazione viene compressa all’interno di un singolo componente che può essere in questo modo facilmente configurato e rilasciato tramite riga di comando. Essendo auto consistente, il container non necessita di lunghe procedure di configurazione all’interno degli ambienti di produzione.
- Scalabilità: la scalabilità orizzontale può essere gestita facilmente tramite la riconfigurazione del singolo container grazie all’aumento delle risorse computazionali dedicate. In merito alla scalabilità verticale, essa può essere automatizzata attraverso l’implementazione di un orchestratore che si occuperà della duplicazione del container in esecuzione creando un pool di istanze racchiudibili in cluster definiti.
- Portabilità: grazie alla forte standardizzazione della soluzione, i container facilitano la portabilità delle applicazioni semplificandone il ciclo di sviluppo, test e rilascio.
- Isolamento: in quanto ogni applicazione è isolata rispetto alle altre in esecuzione sulla medesima infrastruttura fisica e tutte le componenti computazionali vengono virtualizzate a livello di sistema operativo.
- Efficienza: in quanto il consumo di risorse viene limitato grazie alla condivisione di un unico sistema operativo e grazie alla virtualizzazione dei soli componenti necessari all’esecuzione dell’applicazione.
Tuttavia, i container non sono esenti da problematiche di sicurezza; vi sono cinque principali problematiche che riguardano l’utilizzo di questa tecnologia:
- Exploit del kernel: la condivisione del kernel della macchina host espone, in caso di attacco che sfrutti vulnerabilità del sistema operativo, tutti i container basati su di essa. In ambito container quindi risulta di fondamentale importanza l’attività di patching (correzione) del sistema operativo host.
- Attacchi Denial of Service (DoS): nel caso in cui ad un container venisse data la possibilità di accedere a risorse illimitate sul sistema host, lo sfruttamento di una vulnerabilità o di un errore di programmazione dell’applicazione, potrebbe monopolizzare le risorse computazionali disponibili impedendo l’accesso di altri container a CPU e RAM causando un attacco DoS. Diviene opportuno quindi configurare in maniera conservativa l’allocazione delle risorse destinate ad ogni specifico container.
- Container breakout: in caso di presenza di un bug interno ad una applicazione, un utente potrebbe scalare la piramide dei privilegi sino alla sua root (origine), riuscendo così ad ottenere un accesso illimitato alla macchina host. E’ necessario quindi verificare la robustezza e la sicurezza dei container tramite controlli periodici.
- Immagini infette: le immagini standard dei container (build) possono essere infettate con malware o presentare vulnerabilità note, per tale motivo è consigliabile tenere aggiornate all’ultima versione disponibile i container e operare opportuni controlli attraverso scansioni frequenti.
- Segreti compromessi: durante l’esecuzione delle applicazioni il container accede periodicamente ad informazioni sensibili, chiavi API e credenziali; l’accesso indesiderato a queste informazioni comprometterebbe l’intera sicurezza dei servizi in esecuzione.
In merito al DevOps, essa è una metodologia di sviluppo del software che sfrutta le nuove logiche della condivisione e della collaboration nonché di un crowdsourching più verticale. Come vedremo maggiormente in dettaglio nel successivo paragrafo, l’obiettivo dietro l’adozione di tale metodologia di sviluppo risiede nella volontà di accelerare i tempi di rilascio dei software ritenuti fondamentali dalle imprese. Il DevOps, infatti, è un set di pratiche e di cambiamenti culturali supportati da strumenti automatici e processi di Lean Management, che consente di automatizzare il rilascio del software rispetto alla sua catena di produzione, permettendo alle organizzazioni di poter contare su un software e applicazioni di qualità superiore e sicura in modo estremamente più rapido, per accontentare i clienti nel modo migliore e più rapidamente.
A muovere le aziende verso questo nuovo modello di lavoro il fatto che molti professionisti ICT lavorano in ambienti configurati per silos, e cercano sistemi più veloci e affidabili a supporto del loro lavoro. Ma come agevolare la messa in produzione del software? Introducendo una strategia DevOps è possibile effettuare test e implementare nuove funzionalità e applicazioni molto più rapidamente rispetto alle modalità di sviluppo tradizionali, senza contare il fatto che gli stessi sviluppatori, lavorando in prima linea sulla programmazione, sono stimolati a scrivere codici di qualità superiore.
LE CARATTERISTICHE PRINCIPALI DELLA METODOLOGIA DI SVILUPPO DEVOPS: AGILE E CI/CD
Un ambiente DevOps ben strutturato è un ambiente basato sulla metodologia “Agile”, ovvero un ambiente che ha al suo interno i principi derivati dal “Manifesto Agile” che nel 2001 ha definito un modello di sviluppo focalizzato sull’obiettivo di consegnare al cliente, in tempi brevi e frequentemente (early delivery – frequent delivery), software funzionante e di qualità. Rispetto ai metodi tradizionali a cascata o ad altri processi software, le pratiche Agile presuppongono la formazione di team di sviluppo di piccole dimensioni, cross-funzionali e auto-organizzati, lo sviluppo iterativo e incrementale, la pianificazione adattiva e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo.
Altre caratteristiche fondamentali di un sistema di sviluppo DevOps sono l’integrazione continua (CI) e l’erogazione continua (CD). Per CI (Continuous Integration) si intende che nel processo di sviluppo i test su una porzione di codice sono continui e automatici, mentre per CD (Continuous Deployment) si intende che il processo di messa in produzione del codice validato dopo il dovuto collaudo diventa automatica.
Una metodologia DevOps in grado di sfruttare tutte le caratteristiche qui elencate può portare in maniera efficace un’accelerazione nei tempi di sviluppo e rilascio dei software5.
La CI/CD rappresenta il suggello delle potenzialità introdotte dall’IT Automation nell’articolazione con il processo di sviluppo in senso stretto. E’a questo livello che si traggono i benefici più tangibili della complessa struttura fin qui descritta. Sviluppare software non si presta bene alla tradizionale separazione tra progetto e realizzazione tipica delle opere di ingegneria. Il software deve poter evolvere continuamente, in base a sopraggiunte o mutate necessità. Attrezzarsi per questo scenario significa evitare di farsi carico del deployment manuale ad ogni step iterativo. Piuttosto, occorre automatizzare il deployment in modo che il tempo che passa tra la scrittura di una nuova linea di codice e la sua esecuzione in produzione, sia prossimo allo zero. Per fare questo, il paradigma CI/CD prevede la definizione e realizzazione di pipeline di sviluppo, test e messa in produzione, in cui i singoli step e la loro sequenza siano codificati in modo formale, ancora una volta attraverso linguaggi adatti ad una descrizione che sia contemporaneamente human-readable e machine-readable. Le regole di esecuzione e gli step della pipeline possono evolvere nel tempo (es., posso aggiungere o modificare i test a cui sottoporre un determinato software), ma saranno sempre eseguiti in modo automatico ad ogni aggiornamento del codice sorgente. Fino ad arrivare al building del software che le ha passate tutte con successo. Building che avverrà in immagini di container che vengono pubblicate in registry (privati o pubblici) da dove possono essere richiamate ed eseguite in qualsiasi momento e su qualsiasi ambiente.
Da un punto di vista di Cyber Security, adottare metodologie e strumenti DevOps impone una integrazione dei controlli di sicurezza all’interno dei processi di sviluppo, testing e integrazione. Andare verso una DevOps security significa superare l’approccio tradizionale a compartimenti stagni e garantire contemporaneamente e in modo sinergico Application security e operation security. Il ciclo di vita dei sistemi (System Development Life Cycle, SDLC) deve evolvere verso un Secure SDLC e quindi includere test di sicurezza attraverso tutto il processo di sviluppo e integrazione. Quando si progetta e si implementa una Tool Chain per la CI/CD occorre aggiungere specifici tool che eseguono automaticamente security test ad ogni ciclo iterativo. In altre parole, occorre considerare la Cyber Security non un optional da aggiungere al DevOps, ma una sua parte integrante.
Teoricamente, la cultura DevOps lavora al miglioramento della sicurezza. Le applicazioni vengono rilasciate con un determinato livello di sicurezza che soddisfa obiettivi predefiniti (conformità adattiva). In pratica, affinché ciò sia vero, la sicurezza deve essere parte del processo DevOps e dunque organico ad esso, non una funzione separata.
Le applicazioni in produzione diventano più sicure in quanto gli ambienti di sviluppo e di produzione sono costruiti allo stesso modo, rispondendo così agli stessi standard di sicurezza. In base alla conformità adattiva, tali standard cresceranno di pari passo negli ambienti di sviluppo e di produzione, incorporando adattativamente i rimedi alle vulnerabilità che vengono incessantemente rilevate e fixate.
CONCLUSIONI
Le infrastrutture IT diventano sempre più complesse e complicate da gestire. Nuove soluzioni software-defined semplificano e automatizzano la loro gestione, riducendo i costi di implementazione. Di contro, per migliorare l’affidabilità e aumentare la sicurezza, la progettazione assume un ruolo centrale e prominente, sul quale occorre quindi prevedere di spendere di più.
NOTE
1- https://www.cybersecurity360.it/nuove-minacce/sicurezza-software-e-vulnerabilita-informatiche-che-ce-da-sapere/
2- https://searchitoperations.techtarget.com/definition/IT-automation
3- Processo mediante il quale un amministratore di sistema assegna risorse e privilegi, non solo agli utenti di una rete ma anche a chi le utilizza da remoto (ad esempio i fornitori).
4- https://www.redhat.com/it/topics/automation/whats-it-automation
5- https://www.zerounoweb.it/techtarget/searchdatacenter/programmazione-software-e-l-ora-degli-it-shop-devops/
Pubblicato su “Ingegnere Italiano”, Consiglio Nazionale degli Ingegneri, 2/2019