La modernizzazione applicativa viene spesso presentata come un progetto di evoluzione tecnologica: trasformare una grande applicazione monolitica in una serie di microservizi, containerizzare i workload e distribuirli attraverso Kubernetes.
In realtà, per molte organizzazioni questa trasformazione rappresenta anche un'importante opportunità per ripensare completamente la cybersecurity del ciclo di vita del software.
Il passaggio da un monolite a un'architettura distribuita non rende automaticamente un'applicazione più sicura. Al contrario, se affrontato senza una strategia adeguata, può moltiplicare il numero di componenti, identità, API, dipendenze e configurazioni da proteggere.
Quando però la migrazione viene accompagnata da un modello DevSecOps, da automazione della sicurezza, segmentazione, controllo della software supply chain, gestione delle vulnerabilità e principi Security by Design, la trasformazione architetturale può diventare un potente strumento per ridurre il rischio.
Il tema assume un'importanza ancora maggiore nel contesto normativo europeo.
La Direttiva NIS2 richiede infatti alle organizzazioni interessate di adottare adeguate misure di gestione del rischio cyber e considera esplicitamente anche la sicurezza della supply chain e delle relazioni con i fornitori.
Parallelamente, concetti come SBOM – Software Bill of Materials, Shift-left Security, Zero Trust, Infrastructure as Code, container security, Kubernetes hardening, SAST, DAST, SCA e Continuous Compliance stanno entrando progressivamente nel vocabolario quotidiano di CIO, CISO, sviluppatori, DevOps engineer e security specialist.
Comprendere come questi elementi interagiscono significa quindi affrontare la modernizzazione non soltanto come progetto software, ma come parte di una più ampia strategia di resilienza digitale.
Dal monolite ai microservizi: perché le aziende modernizzano le applicazioni
Un'applicazione monolitica concentra generalmente molte funzionalità all'interno di un unico sistema.
Business logic, accesso ai dati, autenticazione, interfaccia applicativa e numerose funzioni possono essere sviluppate, distribuite e aggiornate come un unico blocco.
Questo modello offre anche alcuni vantaggi.
Per applicazioni relativamente semplici, il deployment può risultare immediato, le comunicazioni tra componenti sono più facili da controllare e l'ambiente operativo presenta un numero inferiore di elementi distribuiti.
Con il tempo, tuttavia, molti monoliti diventano complessi.
Le dipendenze aumentano.
La codebase cresce.
Un aggiornamento apparentemente limitato può richiedere il deployment dell'intera applicazione.
Team differenti devono coordinarsi sulla stessa base di codice.
Il testing diventa progressivamente più oneroso.
Una vulnerabilità in una componente centrale può avere conseguenze su una parte significativa dell'applicazione.
Anche scalare il sistema può diventare inefficiente: anziché aumentare soltanto le risorse necessarie a una determinata funzione, spesso occorre replicare l'intero monolite.
È in questo scenario che le architetture a microservizi hanno acquisito grande diffusione.
L'applicazione viene suddivisa in servizi più piccoli, ognuno responsabile di una funzione specifica e potenzialmente sviluppabile, aggiornabile e scalabile in maniera indipendente.
Dal punto di vista della cybersecurity questa trasformazione offre possibilità interessanti.
Ma introduce anche nuove responsabilità.
Microservizi: maggiore isolamento, ma anche maggiore complessità
Uno dei principali vantaggi di un'architettura a microservizi è la possibilità di creare confini di sicurezza più granulari.
Nel monolite, una vulnerabilità che consente all'attaccante di ottenere accesso al processo applicativo può potenzialmente esporre una parte molto ampia del sistema.
Nei microservizi, ogni componente può essere progettato con privilegi specifici, accessi limitati e policy dedicate.
Un servizio incaricato dell'invio di notifiche, ad esempio, non dovrebbe necessariamente avere accesso al database contenente informazioni finanziarie.
Un servizio dedicato alla catalogazione dei prodotti non dovrebbe disporre delle stesse autorizzazioni del sistema di gestione degli utenti.
Questa separazione consente di applicare più facilmente il principio del Least Privilege.
In caso di compromissione di un singolo servizio, l'obiettivo è evitare che l'attaccante possa muoversi liberamente all'interno dell'intera infrastruttura.
Questo principio è strettamente collegato alla logica Zero Trust:
non fidarsi automaticamente di un componente semplicemente perché si trova all'interno dell'infrastruttura.
Ogni identità, servizio e comunicazione dovrebbe essere autenticato, autorizzato e, quando necessario, cifrato.
Tuttavia, la maggiore granularità produce inevitabilmente maggiore complessità.
Dieci microservizi significano potenzialmente dieci workload differenti.
Cento microservizi possono significare centinaia di immagini container, API, dipendenze, account di servizio e configurazioni.
La superficie di attacco cambia.
Non scompare.
Kubernetes come piattaforma di orchestrazione
Quando le applicazioni vengono suddivise in microservizi e distribuite attraverso container, emerge rapidamente la necessità di una piattaforma capace di gestirli.
Kubernetes è diventato uno dei principali standard de facto per l'orchestrazione dei workload containerizzati.
La piattaforma permette di gestire deployment, replica dei servizi, networking, scaling, aggiornamenti, health check e numerosi altri aspetti operativi.
Dal punto di vista della cybersecurity, Kubernetes mette inoltre a disposizione diversi meccanismi attraverso i quali costruire controlli granulari.
Tra questi:
- Role-Based Access Control;
- Service Account;
- Namespace;
- Network Policy;
- Secret;
- admission control;
- Pod Security;
- gestione dei certificati;
- audit logging;
- policy applicate ai workload.
La documentazione ufficiale Kubernetes sottolinea però chiaramente che una piattaforma Kubernetes dispone di numerosi controlli di sicurezza, ma che questi devono essere configurati e amministrati correttamente.
In altre parole:
Kubernetes mette a disposizione gli strumenti per costruire un ambiente sicuro, ma non garantisce automaticamente che l'ambiente lo sia.
La differenza è fondamentale.
Perché Kubernetes può migliorare la Cybersecurity
Utilizzato correttamente, Kubernetes può favorire una strategia di sicurezza molto più granulare rispetto a molte architetture monolitiche tradizionali.
Segmentazione dei workload
I diversi servizi possono essere separati logicamente attraverso namespace e policy.
La comunicazione tra servizi può essere limitata alle sole connessioni realmente necessarie.
Questo riduce le possibilità di movimento laterale.
Controllo degli accessi
Attraverso RBAC è possibile stabilire chi può eseguire determinate operazioni su cluster e workload.
Il principio dovrebbe essere sempre quello del minimum necessary privilege.
Un account che deve leggere i log non dovrebbe poter modificare un deployment.
Un'applicazione che deve interrogare un singolo servizio non dovrebbe ottenere privilegi amministrativi.
Workload isolation
I container permettono di separare processi e dipendenze.
Anche in questo caso, l'isolamento non deve essere considerato assoluto, ma rappresenta un ulteriore livello nella strategia di defence in depth.
Deployment riproducibili
La configurazione può essere gestita attraverso manifest e Infrastructure as Code.
Ciò rende possibile effettuare controlli automatici prima dell'applicazione in produzione.
Immutabilità
Anziché modificare manualmente un server in produzione, i modelli containerizzati incoraggiano la creazione di una nuova immagine e un nuovo deployment.
Questo può ridurre configurazioni non documentate e fenomeni di configuration drift.
Rollback e remediation
Quando una nuova release introduce un problema, l'orchestratore permette di gestire più facilmente aggiornamenti progressivi e rollback.
Sono vantaggi significativi.
Ma richiedono disciplina.
DevSecOps: portare la sicurezza dentro il processo di sviluppo
La modernizzazione architetturale produce il proprio valore maggiore quando viene accompagnata da una trasformazione del processo.
È qui che entra in gioco il DevSecOps.
Il concetto deriva dall'integrazione della sicurezza nel modello DevOps.
Tradizionalmente lo sviluppo software seguiva spesso una sequenza relativamente lineare:
- sviluppo;
- testing;
- deployment;
- controllo sicurezza;
- produzione.
Il problema è evidente.
Se la vulnerabilità viene individuata quando l'applicazione è ormai pronta per essere rilasciata, correggerla può essere complesso, costoso e lento.
DevSecOps cerca di cambiare questo paradigma.
La sicurezza deve essere presente dalla progettazione fino all'esecuzione in produzione.
Non deve rappresentare un controllo finale.
Deve diventare una parte integrante del ciclo di vita.
Shift-left Security: individuare i problemi prima
Uno dei concetti più frequentemente associati al DevSecOps è lo Shift-left.
Immaginiamo il ciclo di sviluppo software rappresentato su una linea temporale.
A sinistra troviamo progettazione e scrittura del codice.
Procedendo verso destra troviamo build, test, deployment e produzione.
Fare Shift-left significa spostare parte dei controlli di sicurezza verso le fasi iniziali.
L'obiettivo consiste nell'individuare una vulnerabilità nel momento più vicino possibile alla sua introduzione.
Un problema rilevato mentre lo sviluppatore sta scrivendo il codice può spesso essere corretto rapidamente.
Lo stesso problema identificato diversi mesi dopo all'interno di un'applicazione già distribuita può richiedere analisi, patch urgenti, downtime, coordinamento tra team e gestione del rischio operativo.
Da qui nasce la crescente integrazione degli strumenti security all'interno delle pipeline CI/CD.
SAST, DAST e SCA
Una moderna pipeline DevSecOps può utilizzare differenti categorie di strumenti.
SAST – Static Application Security Testing
Analizza il codice o artefatti derivati dal codice senza eseguire necessariamente l'applicazione.
Può individuare pattern potenzialmente vulnerabili prima del deployment.
DAST – Dynamic Application Security Testing
Analizza il comportamento dell'applicazione durante l'esecuzione.
È utile per individuare vulnerabilità che emergono nel comportamento reale del sistema.
SCA – Software Composition Analysis
Analizza le dipendenze software utilizzate dall'applicazione.
Questo aspetto è diventato particolarmente importante.
Gran parte del software moderno utilizza librerie e componenti open source.
Uno sviluppatore può aver scritto soltanto una parte relativamente piccola dell'applicazione effettivamente distribuita.
Il resto può dipendere da decine o centinaia di package differenti.
La sicurezza deve quindi riguardare non soltanto il codice sviluppato internamente, ma l'intera software supply chain.
Software Supply Chain Security
Ogni applicazione moderna dipende da una catena di componenti.
- Codice sorgente.
- Repository.
- Librerie.
- Package manager.
- Build system.
- Pipeline CI/CD.
- Container image.
- Container registry.
- Sistema di orchestrazione.
- Cloud provider o infrastruttura on-premise.
Ognuno di questi elementi può diventare un punto di attacco.
ENISA ha dedicato crescente attenzione proprio alla sicurezza della software supply chain e nel 2026 ha pubblicato anche indicazioni specifiche relative all'uso sicuro dei package manager, evidenziando rischi e pratiche per selezionare, integrare e monitorare dipendenze di terze parti.
Questo porta direttamente a un altro concetto fondamentale.
SBOM: conoscere gli ingredienti del software
SBOM significa Software Bill of Materials.
L'analogia più semplice è quella dell'etichetta degli ingredienti di un prodotto.
Quando acquistiamo un alimento possiamo sapere quali ingredienti contiene.
Un'SBOM cerca di portare una logica simile nel software.
Permette di descrivere i componenti che costituiscono un prodotto software e le relative informazioni.
Questo diventa estremamente utile quando viene identificata una nuova vulnerabilità.
Supponiamo che venga pubblicata una vulnerabilità critica relativa a una particolare libreria.
La domanda che il CISO o il security team devono poter fare immediatamente è:
utilizziamo questa libreria da qualche parte?
In un ambiente tradizionale la risposta potrebbe richiedere ore o giorni di investigazione.
Se invece l'organizzazione dispone di SBOM aggiornate per le proprie applicazioni, può individuare molto più rapidamente i sistemi potenzialmente interessati.
CISA descrive infatti l'SBOM proprio come uno strumento per aumentare la trasparenza sulla composizione del software e migliorare la gestione del rischio della supply chain. Nel 2025 e nuovamente nel 2026 l'agenzia ha aggiornato gli elementi minimi raccomandati per gli SBOM.
Anche ENISA rileva una crescente adozione della SBOM nel contesto europeo, anche in relazione ai requisiti introdotti dal Cyber Resilience Act.
SBOM e container
Il rapporto tra SBOM e container è particolarmente interessante.
Una container image non contiene soltanto il codice sviluppato dall'organizzazione.
Può includere:
sistema operativo di base;
package;
runtime;
framework;
librerie;
dipendenze transitive;
strumenti aggiuntivi.
Generare una SBOM per ogni image consente quindi di aumentare notevolmente la visibilità sui componenti effettivamente distribuiti.
Questa informazione può successivamente essere collegata ai database delle vulnerabilità.
La pipeline può quindi:
- creare l'applicazione;
- costruire la container image;
- generare la SBOM;
- eseguire vulnerability scanning;
- verificare policy;
- firmare l'artefatto;
- pubblicarlo nel registry;
- consentirne il deployment soltanto se rispetta i requisiti stabiliti.
È un esempio concreto di DevSecOps.
Image Scanning e container registry
Un ambiente Kubernetes dovrebbe evitare di considerare tutte le immagini container come automaticamente affidabili.
Le immagini devono essere analizzate.
Devono provenire da repository autorizzati.
È opportuno sapere chi le ha prodotte.
Quando sono state prodotte.
Quale pipeline le ha generate.
Quale codice sorgente corrisponde alla build.
Quali vulnerabilità contengono.
Quali package sono presenti.
La combinazione di SBOM, vulnerability scanning e firma degli artefatti consente di costruire una vera catena di fiducia.
Il concetto viene spesso descritto come software supply chain integrity.
Policy as Code
Un altro elemento importante della trasformazione DevSecOps è la Policy as Code.
Tradizionalmente molte regole di sicurezza esistono sotto forma di documenti.
“Le applicazioni non devono essere eseguite con privilegi amministrativi.”
“Le immagini devono provenire dal registry autorizzato.”
“I workload devono avere limiti di risorse.”
“Le comunicazioni devono utilizzare TLS.”
Il problema è che una policy scritta in un documento non impedisce automaticamente a qualcuno di violarla.
Policy as Code significa tradurre parte di queste regole in controlli automaticamente verificabili.
Se un deployment non soddisfa una determinata policy, può essere bloccato prima di raggiungere l'ambiente di produzione.
La compliance smette quindi di essere esclusivamente documentale.
Diventa almeno parzialmente eseguibile.
Continuous Compliance
Da questo concetto deriva la Continuous Compliance.
In ambienti moderni, verificare la conformità una volta all'anno è spesso insufficiente.
Un cluster Kubernetes può cambiare ogni giorno.
Nuove immagini vengono distribuite.
Nuovi utenti ricevono privilegi.
Nuove configurazioni vengono applicate.
Nuove vulnerabilità vengono pubblicate.
Per questo motivo la verifica deve diventare continua.
Non significa necessariamente che ogni requisito normativo possa essere completamente automatizzato.
Significa però che numerosi controlli tecnici possono essere monitorati costantemente.
NIS2 e gestione del rischio cyber
La Direttiva europea NIS2 rafforza significativamente l'approccio alla cybersecurity per numerose categorie di organizzazioni.
Il punto fondamentale non è semplicemente “essere conformi”.
La logica della direttiva è più ampia: le organizzazioni devono adottare misure adeguate di cybersecurity risk management, gestione degli incidenti, continuità operativa e sicurezza della supply chain.
La supply-chain security è particolarmente importante.
Un'organizzazione può infatti disporre di sistemi interni molto ben protetti ma dipendere da software, servizi cloud, provider, librerie o Managed Service Provider esterni.
Una vulnerabilità nella catena dei fornitori può diventare una vulnerabilità aziendale.
ENISA ha pubblicato specifiche linee guida proprio sulle buone pratiche di supply chain cybersecurity e successivamente indicazioni tecniche per supportare l'implementazione della NIS2 in alcune categorie di entità.
DevSecOps, SBOM e automazione dei controlli possono quindi diventare strumenti utili anche nell'ambito di una più ampia strategia di gestione del rischio.
NIS2 non significa semplicemente installare più strumenti
È importante evitare un equivoco.
La compliance non deriva automaticamente dall'adozione di Kubernetes, di una piattaforma DevSecOps o di un vulnerability scanner.
NIS2 riguarda governance, gestione del rischio e responsabilità organizzativa oltre alle misure tecnologiche.
La tecnologia permette però di produrre controlli ed evidenze.
Una pipeline può documentare:
- chi ha modificato il codice;
- quali test sono stati eseguiti;
- quale immagine è stata prodotta;
- quali vulnerabilità erano presenti;
- quali policy sono state applicate;
- quando l'artefatto è stato distribuito;
- chi ha autorizzato la modifica.
Questa tracciabilità può diventare estremamente importante.
Infrastructure as Code
L'Infrastructure as Code, o IaC, è un altro pilastro della modernizzazione.
Server, network, cluster e servizi cloud possono essere descritti attraverso configurazioni versionate.
Questo porta numerosi vantaggi.
- Riproducibilità.
- Review.
- Version control.
- Automazione.
- Auditabilità.
- Rollback.
Ma Infrastructure as Code introduce anche un rischio.
Una configurazione sbagliata può essere replicata automaticamente su decine o centinaia di risorse.
Per questo motivo anche il codice infrastrutturale deve essere sottoposto a controlli di sicurezza.
Un errore manuale può creare una singola vulnerabilità.
Un errore automatizzato può crearne mille.
Secrets Management
Un'altra area critica riguarda i secret.
- Password.
- API key.
- Token.
- Certificate private key.
- Credenziali database.
È fondamentale evitare che vengano inseriti direttamente nel codice sorgente, nelle container image o nei repository Git.
La gestione centralizzata dei secret e la loro rotazione rappresentano elementi fondamentali di un ambiente DevSecOps.
In Kubernetes esiste l'oggetto Secret, ma utilizzarlo correttamente richiede comunque configurazioni, controllo degli accessi e gestione delle chiavi adeguati.
Kubernetes RBAC e Least Privilege
RBAC, Role-Based Access Control, permette di controllare le operazioni che utenti e workload possono effettuare all'interno di Kubernetes.
L'errore da evitare è utilizzare privilegi amministrativi come soluzione universale.
Il principio dovrebbe essere sempre:
concedere soltanto le autorizzazioni necessarie e soltanto per il tempo necessario.
Le linee guida Kubernetes sottolineano l'importanza di proteggere l'accesso al cluster e utilizzare meccanismi di autorizzazione adeguati.
Un account compromesso con privilegi minimi crea un impatto potenzialmente limitato.
Un account compromesso con privilegi cluster-admin può compromettere l'intera infrastruttura.
Network Policy e micro-segmentazione
In un ambiente distribuito è importante controllare anche le comunicazioni tra workload.
Il semplice fatto che due container si trovino nello stesso cluster non dovrebbe significare che possano comunicare liberamente.
Le Network Policy permettono di definire quali comunicazioni sono consentite.
Questo consente di applicare concetti di micro-segmentazione.
Frontend → API.
API → specifico backend.
Backend → specifico database.
Tutto ciò che non è necessario può essere bloccato.
Questa strategia riduce il potenziale movimento laterale di un attaccante.
Service Mesh e mTLS
In architetture a microservizi può diventare importante proteggere anche la comunicazione service-to-service.
Una delle tecnologie utilizzabili è il service mesh.
Un service mesh può aiutare a gestire aspetti quali autenticazione reciproca, cifratura e osservabilità delle comunicazioni.
Il concetto di mTLS – mutual TLS consente a entrambi i lati della comunicazione di verificare la rispettiva identità.
Questo permette di avvicinare ulteriormente l'infrastruttura a un modello Zero Trust.
Observability: log, metriche e trace
Un sistema più distribuito deve necessariamente essere anche più osservabile.
In un monolite tradizionale può essere sufficiente analizzare un numero relativamente limitato di log.
In un sistema a microservizi, una singola richiesta utente può attraversare numerosi componenti.
Occorre quindi correlare:
- log;
- metriche;
- distributed tracing;
- eventi Kubernetes;
- audit log;
- telemetria di rete;
- eventi security.
L'observability non deve essere considerata soltanto una funzione operational.
È anche una componente fondamentale della cybersecurity.
Un attacco non rilevabile rimane spesso un attacco non gestibile.
Detection Engineering
Questo porta al concetto di Detection Engineering.
Le organizzazioni mature non si limitano a raccogliere log.
Progettano regole e meccanismi in grado di identificare comportamenti anomali.
Ad esempio:
una service account che improvvisamente tenta di leggere secret;
un workload che comunica con destinazioni mai utilizzate;
un container che avvia una shell;
un deployment modificato fuori dalla pipeline;
un account che richiede privilegi inusuali.
Il DevSecOps collega quindi prevenzione e detection.
Runtime Security
Shift-left è importante.
Ma non basta.
Un'applicazione può superare tutti i test durante la build e venire comunque attaccata in produzione.
Per questo motivo al concetto di Shift-left viene sempre più spesso affiancato quello di runtime security.
La sicurezza deve continuare anche dopo il deployment.
Occorre poter rilevare comportamenti anomali all'interno dei container e del cluster.
L'approccio corretto non è quindi Shift-left oppure runtime security.
Shift-left + runtime protection + continuous monitoring.
Da DevSecOps a Platform Engineering
Un'altra evoluzione importante riguarda il Platform Engineering.
In organizzazioni di grandi dimensioni non è realistico aspettarsi che ogni sviluppatore diventi esperto di Kubernetes security, IAM, networking, container hardening e compliance.
I platform team possono quindi costruire percorsi standardizzati e sicuri attraverso i quali gli sviluppatori distribuiscono applicazioni.
Questi vengono spesso chiamati Golden Paths.
Lo sviluppatore utilizza una piattaforma interna che incorpora automaticamente molte best practice:
- template approvati;
- CI/CD standard;
- scansioni automatiche;
- registry autorizzati;
- logging;
- monitoring;
- policy;
- gestione dei secret.
In questo modo la sicurezza diventa la strada più semplice.
Ed è esattamente ciò che un buon DevSecOps dovrebbe cercare di ottenere.
On-premise o cloud?
La modernizzazione non implica obbligatoriamente il cloud pubblico.
Kubernetes può essere utilizzato in ambienti:
- on-premise;
- public cloud;
- private cloud;
- hybrid cloud;
- multi-cloud;
- edge.
La scelta dovrebbe dipendere dai requisiti dell'organizzazione.
Ogni modello presenta vantaggi e responsabilità differenti.
Kubernetes on-premise
Un cluster Kubernetes on-premise offre all'organizzazione un elevato grado di controllo.
- Hardware.
- Networking.
- Storage.
- Hypervisor.
- Cluster.
- Logging.
- Identity.
- Aggiornamenti.
Questo può rappresentare un vantaggio per aziende con particolari esigenze di sovranità, controllo dei dati o integrazione con sistemi esistenti.
Ma significa anche assumersi una maggiore responsabilità operativa.
Un cloud provider può gestire parte dell'infrastruttura sottostante.
In un ambiente on-premise, l'organizzazione deve generalmente occuparsi di un numero maggiore di livelli.
Controllo significa anche responsabilità.
Managed Kubernetes nel cloud
I principali cloud provider offrono servizi Kubernetes gestiti.
In questi scenari parte della complessità del control plane viene gestita dal provider.
L'organizzazione rimane comunque responsabile di numerosi aspetti:
- workload;
- identità;
- container image;
- configurazioni;
- network policy;
- secret;
- dipendenze;
- dati;
- application security.
È il tradizionale concetto di Shared Responsibility Model.
Passare al cloud non significa trasferire completamente la responsabilità della cybersecurity al provider.
Hybrid Cloud
Per molte aziende la risposta non è “cloud oppure on-premise”.
È entrambi.
Sistemi legacy possono rimanere nel data center aziendale.
Nuove applicazioni possono essere sviluppate nel cloud.
Alcuni workload possono richiedere prossimità ai dati.
Altri possono beneficiare della scalabilità del cloud pubblico.
Kubernetes può fornire una piattaforma relativamente coerente tra differenti ambienti, anche se è importante evitare di sottovalutare le differenze tra infrastrutture.
Multi-cloud: resilienza o complessità?
Il multi-cloud viene spesso presentato come strumento per ridurre la dipendenza da un singolo provider.
In teoria può offrire maggiore libertà.
Nella pratica introduce però una notevole complessità.
IAM differenti.
Networking differente.
Servizi differenti.
Logging differente.
Security tooling differente.
Competenze differenti.
Un ambiente multi-cloud mal progettato può quindi diminuire, anziché aumentare, la resilienza.
La diversificazione tecnologica deve essere confrontata con il costo della complessità.
Sovranità digitale e rischio geopolitico
Negli ultimi anni le decisioni infrastrutturali hanno acquisito anche una dimensione geopolitica.
Le aziende europee devono valutare non soltanto costo e performance, ma anche:
- localizzazione dei dati;
- giurisdizione;
- dipendenza da provider extra-UE;
- supply chain tecnologica;
- continuità dei servizi;
- dipendenza da specifici vendor;
- restrizioni commerciali;
- sanzioni;
- conflitti;
- disponibilità di hardware e componenti;
- evoluzione normativa.
Questi fattori non significano che il cloud pubblico sia intrinsecamente insicuro.
Né che l'on-premise garantisca automaticamente sovranità e resilienza.
Significano che la strategia tecnologica deve includere anche il rischio di concentrazione e dipendenza.
Un'infrastruttura estremamente dipendente da un singolo provider, da una singola regione geografica o da un ristretto numero di tecnologie può presentare un rischio strategico.
Allo stesso tempo, replicare ogni sistema su tre cloud differenti esclusivamente per ragioni teoriche può generare costi e complessità difficili da sostenere.
La risposta deve quindi derivare da un'analisi del rischio.
Portabilità e Kubernetes
Uno dei motivi per cui Kubernetes viene spesso inserito in strategie ibride è la possibilità di utilizzare un modello relativamente uniforme di deployment dei workload.
Un container conforme agli standard può essere eseguito in ambienti differenti.
Questo non significa che un'applicazione Kubernetes sia automaticamente portabile da un cloud all'altro.
Database gestiti, IAM, sistemi di storage, load balancer e servizi proprietari possono creare comunque dipendenza dal provider.
Tuttavia, l'utilizzo di standard aperti e infrastrutture dichiarative può ridurre alcune forme di lock-in.
Dal punto di vista geopolitico e della business continuity, questa capacità può assumere valore strategico.
Resilience Engineering
La cybersecurity moderna non riguarda soltanto impedire gli attacchi.
Riguarda anche continuare a operare quando qualcosa va male.
Nasce da qui il concetto di Cyber Resilience.
Un'organizzazione deve chiedersi:
- cosa succede se un cluster smette di funzionare?
- cosa succede se il cloud provider ha un'interruzione?
- cosa succede se una container image risulta compromessa?
- cosa succede se perdiamo l'accesso a un repository?
- quanto rapidamente possiamo ricostruire l'ambiente?
- abbiamo backup realmente ripristinabili?
- possiamo distribuire l'applicazione in un'altra infrastruttura?
Queste domande collegano cybersecurity, DevOps, business continuity e disaster recovery.
Immutable Infrastructure
Una moderna strategia cloud-native privilegia spesso il concetto di Immutable Infrastructure.
Anziché modificare progressivamente un server, si genera una nuova versione dell'artefatto.
L'infrastruttura viene ricostruita.
Questo riduce il rischio che i sistemi accumulino nel tempo configurazioni manuali difficili da documentare.
È un cambiamento importante anche dal punto di vista forense.
Se l'ambiente è completamente descritto attraverso codice e artefatti versionati, diventa più semplice comprendere quale configurazione dovrebbe essere presente.
GitOps
Il concetto di GitOps porta ulteriormente avanti questa filosofia.
Lo stato desiderato dell'infrastruttura viene dichiarato attraverso file versionati.
Git diventa una delle fonti attraverso cui definire la configurazione.
Questo offre review, version history, approvazioni e auditabilità.
Ma aumenta anche l'importanza di proteggere repository e pipeline.
Se il repository diventa la fonte della configurazione infrastrutturale, comprometterlo può significare compromettere la produzione.
Ancora una volta:
automazione e cybersecurity devono crescere insieme.
DevSecOps e Intelligenza Artificiale
L'AI introduce un ulteriore livello.
Assistenti di coding possono generare rapidamente funzioni, configurazioni Kubernetes, Dockerfile e pipeline.
Questo può aumentare enormemente la produttività.
Ma può anche accelerare la produzione di errori.
Un modello può generare codice apparentemente corretto che contiene vulnerabilità.
Può suggerire una configurazione Kubernetes eccessivamente permissiva.
Può utilizzare una libreria non aggiornata.
Può generare Dockerfile che eseguono i processi come root.
Il DevSecOps diventa quindi ancora più importante nell'era AI.
Se aumenta la velocità con cui produciamo software, deve aumentare anche la velocità con cui siamo in grado di verificarlo.
Dal “trust but verify” al “verify before deploy”
L'architettura moderna porta progressivamente verso un principio semplice:
un artefatto non dovrebbe essere considerato affidabile soltanto perché è stato prodotto internamente.
Deve superare i controlli.
Possiamo immaginare una pipeline ideale:
- developer commit;
- code review;
- SAST;
- secret scanning;
- dependency scanning;
- unit test;
- build;
- SBOM generation;
- container scanning;
- firma dell'immagine;
- policy verification;
- deployment in ambiente di test;
- DAST;
- approval;
- deployment Kubernetes;
- runtime monitoring.
Ogni passaggio aggiunge un elemento di fiducia.
La migrazione dal monolite come opportunità di cybersecurity
Quando un'azienda decide di modernizzare un'applicazione monolitica, ha un'opportunità rara.
Può evitare di replicare nel nuovo ambiente tutti i problemi accumulati nel precedente.
La migrazione può diventare occasione per:
- rivedere le identità;
- ridurre i privilegi;
- separare i servizi;
- proteggere le API;
- inventariare le dipendenze;
- generare SBOM;
- automatizzare il vulnerability scanning;
- introdurre Infrastructure as Code;
- centralizzare i secret;
- implementare logging strutturato;
- applicare Network Policy;
- integrare controlli nella pipeline;
- migliorare disaster recovery;
- documentare la software supply chain.
La trasformazione può quindi essere contemporaneamente:
- applicativa;
- organizzativa;
- operativa;
- security-oriented.
Ma attenzione al distributed monolith
Esiste però un errore frequente.
Spezzare un monolite in cinquanta container non significa automaticamente creare una buona architettura a microservizi.
Se tutti i servizi dipendono strettamente gli uni dagli altri, condividono database, devono essere aggiornati contemporaneamente e non possiedono autonomia, si può creare quello che viene talvolta definito distributed monolith.
Si ottiene la complessità dei microservizi senza i benefici dell'indipendenza.
Dal punto di vista della cybersecurity può essere persino peggio.
Più network communication.
Più API.
Più container.
Più configurazione.
Senza reale segmentazione.
La progettazione architetturale rimane quindi essenziale.
Security by Design
La modernizzazione dovrebbe partire dal principio di Security by Design.
Dobbiamo passare da :
“Come mettiamo in sicurezza questa architettura?”
a
“Come progettiamo questa architettura affinché il comportamento sicuro sia quello predefinito?”
È una differenza fondamentale.
Un'applicazione dovrebbe nascere con:
- identità granulari;
- privilegi minimi;
- segmentazione;
- logging;
- encryption;
- gestione dei secret;
- controlli automatizzati;
- tracciabilità delle dipendenze.
Aggiungere questi elementi successivamente è quasi sempre più difficile.
Security by Default
Accanto al Security by Design troviamo il concetto di Security by Default.
Le configurazioni predefinite dovrebbero favorire lo scenario più sicuro.
Un workload non dovrebbe avere privilegi amministrativi salvo richiesta esplicita.
Una comunicazione non necessaria dovrebbe essere bloccata.
Una container image non verificata dovrebbe essere rifiutata.
Un secret non dovrebbe essere inserito nel codice.
Il principio può essere sintetizzato così:
rendere facile fare la cosa giusta e difficile fare quella sbagliata.
La tecnologia non basta: servono competenze
È qui che si arriva al punto più importante.
Acquistare strumenti DevSecOps non significa adottare DevSecOps.
Installare Kubernetes non significa possedere competenze cloud-native.
Generare una SBOM non significa automaticamente sapere gestire una vulnerabilità.
Adottare il cloud non significa automaticamente migliorare la sicurezza.
La trasformazione tecnologica deve essere accompagnata da formazione.
Sviluppatori, system administrator, security engineer, cloud architect, DevOps e manager devono sviluppare un linguaggio comune.
Lo sviluppatore deve comprendere security.
Il security specialist deve comprendere CI/CD.
Il sistemista deve comprendere container.
Il cloud architect deve comprendere identity.
Il responsabile governance deve comprendere la software supply chain.
Le competenze DevSecOps richieste
Un moderno percorso DevSecOps dovrebbe quindi comprendere almeno:
- container;
- Docker;
- Kubernetes;
- microservizi;
- API security;
- CI/CD;
- Infrastructure as Code;
- SAST;
- DAST;
- SCA;
- SBOM;
- vulnerability management;
- container scanning;
- secrets management;
- IAM;
- RBAC;
- network security;
- cloud security;
- GitOps;
- observability;
- logging;
- runtime security;
- Zero Trust;
- Policy as Code;
- supply chain security;
- incident response;
- compliance.
Non significa che un singolo professionista debba essere massimo esperto in ogni ambito.
Significa che questi concetti devono poter dialogare.
Da infrastruttura a piattaforma sicura
La vera evoluzione DevSecOps non consiste quindi nel distribuire Kubernetes.
Consiste nel costruire una piattaforma applicativa sicura e ripetibile.
Gli sviluppatori dovrebbero poter distribuire software senza dover ricostruire ogni volta tutti i controlli.
La piattaforma dovrebbe fornire automaticamente:
- identity;
- logging;
- monitoring;
- secret;
- pipeline;
- scanning;
- policy;
- networking;
- deployment;
- rollback;
- auditabilità.
È questo il punto in cui Platform Engineering, DevSecOps e Cybersecurity iniziano a convergere.
Conclusioni: modernizzare significa riprogettare la sicurezza
La migrazione da un'applicazione monolitica verso microservizi e Kubernetes non dovrebbe essere considerata esclusivamente come un progetto di modernizzazione software.
È un'occasione per ripensare la cybersecurity dell'intero ciclo di vita applicativo.
Microservizi permettono maggiore granularità.
Kubernetes consente automazione e controllo.
DevSecOps integra la sicurezza nel processo.
Shift-left permette di individuare le vulnerabilità prima.
SBOM aumenta la trasparenza sulla software supply chain.
SAST, DAST e SCA rendono i controlli ripetibili.
Policy as Code consente di tradurre parte delle regole in controlli automatici.
Runtime Security permette di mantenere visibilità anche dopo il deployment.
Zero Trust e Least Privilege riducono implicit trust e privilegi inutili.
Observability e Detection Engineering aumentano la capacità di rilevare anomalie.
NIS2 rafforza infine l'importanza di gestione del rischio, resilienza e supply-chain security nel contesto europeo.
Nessuna di queste tecnologie, presa singolarmente, rappresenta una soluzione definitiva.
Il valore nasce dalla loro integrazione.
On-premise, cloud o hybrid: la sicurezza deve seguire il workload
Allo stesso modo, non esiste una risposta universalmente corretta tra on-premise e cloud.
Alcune organizzazioni necessitano di controllo diretto sull'infrastruttura.
Altre beneficiano dei servizi gestiti del cloud.
Molte adotteranno un modello ibrido.
Altre ancora avranno requisiti multi-cloud.
L'evoluzione geopolitica, la sovranità digitale, la giurisdizione dei dati, il vendor lock-in e la resilienza della supply chain tecnologica renderanno queste decisioni sempre più strategiche.
La domanda quindi non dovrebbe essere:
“Cloud o on-premise?”
Ma:
“Quale architettura ci permette di mantenere sicurezza, resilienza, controllo e capacità di evoluzione in relazione ai nostri rischi?”
Kubernetes e le architetture cloud-native possono offrire strumenti importanti per rispondere a questa domanda.
Ma richiedono competenze.
Formazione DevSecOps, Cloud Native e Cybersecurity con DigitalLab
La trasformazione da monolite a microservizi richiede professionisti capaci di comprendere contemporaneamente infrastruttura, sviluppo software e cybersecurity.
DigitalLab sviluppa percorsi di formazione informatica dedicati alle tecnologie che costituiscono questo ecosistema:
Cybersecurity
DevSecOps
Cloud Computing
AWS
Microsoft Azure
Google Cloud
Cisco e Networking
CompTIA
Kubernetes
Container
Microservizi
Infrastructure Automation
Cloud Security
Software Supply Chain Security
Per le aziende, la formazione può inoltre diventare parte integrante del progetto di modernizzazione, costruendo competenze interne prima e durante l'adozione delle nuove piattaforme.
Non si tratta soltanto di imparare Kubernetes.
Si tratta di capire come progettare, distribuire, proteggere e mantenere applicazioni moderne durante l'intero ciclo di vita.
Scopri i percorsi formativi DigitalLab
Consulta il catalogo dei corsi e individua il percorso più adatto alle competenze che vuoi sviluppare:
https://new.digitallabtraining.it/corsi
Dalla cybersecurity alle architetture cloud-native, dal networking al DevSecOps, DigitalLab supporta professionisti e organizzazioni nello sviluppo delle competenze necessarie per progettare infrastrutture moderne, automatizzate e sicure.
La modernizzazione non consiste semplicemente nel portare un'applicazione nel cloud o dentro Kubernetes.
Significa ripensare il modo in cui il software viene progettato, costruito, verificato, distribuito e protetto.
Ed è precisamente in questo passaggio che DevSecOps e Cybersecurity diventano parte della stessa strategia.