DevSecOps in servizio Azure Kubernetes (servizio Azure Kubernetes)

Azure Boards

Azure DevOps

Monitoraggio di Azure

Azure Pipelines

Criteri di Azure

DevSecOps, detto anche Secure DevOps, si basa sulla pratica di DevOps incorporando la sicurezza in diverse fasi di un ciclo di vita devOps tradizionale. Alcuni dei vantaggi della creazione di sicurezza nelle procedure DevOps includono:

Rendere più sicure le applicazioni e i sistemi offrendo visibilità sulle minacce alla sicurezza e impedendo alle vulnerabilità di raggiungere gli ambienti distribuiti
Aumentare la consapevolezza della sicurezza con i team operativi e di sviluppo
Incorporando processi di sicurezza automatizzati nel ciclo di vita di sviluppo software
Riduzione dei costi per la correzione individuando i problemi di sicurezza nelle fasi iniziali di sviluppo e progettazione

Quando DevSecOps viene applicato a servizio Azure Kubernetes (servizio Azure Kubernetes), i diversi ruoli dell'organizzazione possono avere considerazioni diverse per l'implementazione della sicurezza. Ecco alcuni esempi di questi diversi ruoli dell'organizzazione:

Sviluppatori che creano applicazioni sicure in esecuzione nel servizio Azure Kubernetes
Ingegneri cloud che creano un'infrastruttura del servizio Azure Kubernetes sicura
Vari team operativi che potrebbero gestire i cluster o monitorare i problemi di sicurezza

Questo articolo è suddiviso in diverse fasi del ciclo di vita di DevOps con considerazioni e consigli per l'incorporamento di controlli di sicurezza e procedure consigliate per la sicurezza. Questa guida include processi e strumenti comuni da incorporare in pipeline di integrazione continua e recapito continuo (CI/CD), optando per strumenti predefiniti facili da usare, se disponibili.

Come prerequisito per questo articolo, è consigliabile esaminare Compilare e distribuire app nel servizio Azure Kubernetes usando DevOps e GitOps.

Flusso del processo

Scaricare un file di Visio di questa architettura.

Nota

Anche se questo articolo fa riferimento al servizio Azure Kubernetes e a GitHub, queste raccomandazioni si applicano a qualsiasi piattaforma di orchestrazione dei contenitori o CI/CD. Anche se i dettagli di implementazione possono variare, la maggior parte dei concetti e delle procedure menzionate in ogni fase è ancora pertinente e applicabile.

Azure Active Directory (Azure AD) è configurato come provider di identità per GitHub. Configurare l'autenticazione a più fattori (MFA) per garantire una maggiore sicurezza di autenticazione.
Gli sviluppatori usano Visual Studio Code o Visual Studio con estensioni di sicurezza abilitate per analizzare in modo proattivo il codice per individuare le vulnerabilità di sicurezza.
Gli sviluppatori eseguono il commit del codice dell'applicazione in un repository GitHub Enterprise di proprietà dell'azienda e regolamentato.
GitHub Enterprise integra l'analisi automatica della sicurezza e delle dipendenze tramite GitHub Advanced Security.
Le richieste pull attivano compilazioni di integrazione continua (CI) e test automatizzati tramite GitHub Actions.
Il flusso di lavoro di compilazione CI tramite GitHub Actions genera un'immagine del contenitore Docker archiviata in Registro Azure Container.
È possibile introdurre approvazioni manuali per le distribuzioni in ambienti specifici, ad esempio la produzione, come parte del flusso di lavoro di recapito continuo (CD) in GitHub Actions.
GitHub Actions abilita la distribuzione continua nel servizio Azure Kubernetes. Usare GitHub Advanced Security per rilevare segreti, credenziali e altre informazioni riservate nei file di origine e configurazione dell'applicazione.
Microsoft Defender viene usato per analizzare Registro Azure Container, cluster del servizio Azure Kubernetes e Azure Key Vault per individuare le vulnerabilità di sicurezza.
1. Microsoft Defender per contenitori analizza l'immagine del contenitore per individuare le vulnerabilità di sicurezza note al momento del caricamento nel Registro Container.
2. È anche possibile usare Defender per contenitori per eseguire analisi dell'ambiente del servizio Azure Kubernetes e fornire la protezione dalle minacce in fase di esecuzione per i cluster del servizio Azure Kubernetes.
3. Microsoft Defender per Key Vault rileva tentativi dannosi e insoliti e sospetti di accedere agli account dell'insieme di credenziali delle chiavi.
Criteri di Azure possono essere applicati a Registro Container e servizio Azure Kubernetes (servizio Azure Kubernetes) per la conformità e l'imposizione dei criteri. I criteri di sicurezza comuni per Registro Container e servizio Azure Kubernetes sono integrati per l'abilitazione rapida.
Azure Key Vault viene usato per inserire in modo sicuro segreti e credenziali in un'applicazione in fase di esecuzione, separando le informazioni riservate dagli sviluppatori.
Il motore dei criteri di rete del servizio Azure Kubernetes è configurato per proteggere il traffico tra i pod dell'applicazione usando i criteri di rete kubernetes.
È possibile configurare il monitoraggio continuo del cluster del servizio Azure Kubernetes usando Monitoraggio di Azure e Informazioni dettagliate sui contenitori per inserire le metriche delle prestazioni e analizzare i log di sicurezza e delle applicazioni.
1. Informazioni dettagliate sui contenitori recuperano le metriche delle prestazioni e i log dell'applicazione e del cluster.
2. I log di diagnostica e dell'applicazione vengono estratti in un'area di lavoro Log Analytics di Azure per eseguire query di log.
Microsoft Sentinel, una soluzione SIEM (Security Information and Event Management) può essere usata per inserire e analizzare ulteriormente i log del cluster del servizio Azure Kubernetes per individuare eventuali minacce alla sicurezza in base a modelli e regole definiti.
È possibile usare strumenti open source come ZAP (Zed Attack Proxy) per eseguire test di penetrazione per applicazioni Web e servizi.
Defender per DevOps, un servizio disponibile in Defender per il cloud, consente ai team di sicurezza di gestire la sicurezza devOps in ambienti multi-pipeline, tra cui GitHub e Azure DevOps.

Panoramica e responsabilità dei membri del team

Valutare la possibilità di gestire la complessità di DevSecOps nelle distribuzioni di soluzioni basate su Kubernetes come separazione delle problematiche. Quale team in un ambiente aziendale deve occuparsi di ogni aspetto della distribuzione? Quali strumenti e processi devono essere usati da un team per raggiungere al meglio i propri obiettivi? In questa sezione vengono descritti i ruoli comuni degli sviluppatori, degli operatori dell'applicazione (ingegneri dell'affidabilità del sito), degli operatori del cluster e dei team di sicurezza.

Sviluppatori

Gli sviluppatori sono responsabili della scrittura del codice dell'applicazione. Sono anche responsabili del commit del codice nel repository designato. Una delle responsabilità importanti degli sviluppatori include anche la creazione e l'esecuzione di script per i test automatizzati per garantire che il codice funzioni come previsto e si integra perfettamente con il resto dell'applicazione. Definiscono e creano script per la compilazione di immagini del contenitore come parte della pipeline di automazione.

Operatori dell'applicazione (tecnici dell'affidabilità del sito)

La creazione di applicazioni nel cloud usando contenitori e Kubernetes può semplificare lo sviluppo, la distribuzione e la scalabilità delle applicazioni. Ma questi approcci di sviluppo creano anche ambienti sempre più distribuiti che complicano l'amministrazione. I tecnici dell'affidabilità del sito creano soluzioni per automatizzare la supervisione dei sistemi software di grandi dimensioni. Fungono da ponte tra i team degli operatori di sviluppo e cluster e consentono di stabilire e monitorare gli obiettivi a livello di servizio e i budget degli errori. In questo modo, consentono di gestire le distribuzioni di applicazioni e spesso scrivono file manifesto (YAML) di Kubernetes.

Operatori del cluster

Gli operatori del cluster sono responsabili della configurazione e della gestione dell'infrastruttura del cluster. Spesso usano procedure consigliate e framework di infrastruttura come codice (IaC) come GitOps per effettuare il provisioning e gestire i cluster. Usano vari strumenti di monitoraggio, ad esempio informazioni dettagliate sui contenitori di Monitoraggio di Azure e Prometheus/Grafana, per monitorare l'integrità complessiva del cluster. Sono responsabili dell'applicazione di patch, degli aggiornamenti del cluster, delle autorizzazioni e del controllo degli accessi in base al ruolo nel cluster. Nei team devSecOps, assicurano che i cluster soddisfino i requisiti di sicurezza del team e che collaborano con il team di sicurezza per creare tali standard.

Team di sicurezza

Il team di sicurezza è responsabile dello sviluppo di standard di sicurezza e dell'applicazione. Alcuni team potrebbero essere responsabili della creazione e della selezione di Criteri di Azure applicati nelle sottoscrizioni e nei gruppi di risorse che contengono i cluster. Monitorano i problemi di sicurezza e insieme agli altri team, assicurano che la sicurezza venga portata in primo piano in ogni passaggio del processo DevSecOps.

Fasi del ciclo di vita di DevSecOps

I controlli di sicurezza vengono implementati in ogni fase del ciclo di vita dello sviluppo software (SDLC). Questa implementazione è un elemento chiave di una strategia DevSecOps e dell'approccio di spostamento a sinistra.

Scaricare un file di Visio di questa architettura.

Fase del piano

La fase del piano ha in genere la minima quantità di automazione, ma ha importanti implicazioni per la sicurezza che influiscono significativamente sulle fasi successive del ciclo di vita di DevOps. Questa fase prevede la collaborazione tra team di sicurezza, sviluppo e operazioni. L'inclusione degli stakeholder della sicurezza in questa fase di progettazione e pianificazione garantisce che i requisiti di sicurezza e i problemi di sicurezza siano adeguatamente responsabili o mitigati.

Procedura consigliata: progettare una piattaforma applicativa più sicura

La creazione di una piattaforma ospitata dal servizio Azure Kubernetes è un passaggio importante per garantire che la sicurezza sia integrata nel sistema a ogni livello, a partire dalla piattaforma stessa. La piattaforma può includere componenti interni al cluster (ad esempio agenti di sicurezza e criteri di runtime) e componenti esterni al servizio Azure Kubernetes( ad esempio firewall di rete e registri contenitori). Per altre informazioni, vedere Acceleratore di zona di destinazione del servizio Azure Kubernetes, che include aree di progettazione critiche, ad esempio sicurezza, identità e topologia di rete.

Procedura consigliata: creare la modellazione delle minacce nel processo

La modellazione delle minacce è in genere un'attività manuale che coinvolge i team di sicurezza e sviluppo. Viene usato per modellare e trovare minacce all'interno di un sistema in modo che le vulnerabilità possano essere risolte prima di qualsiasi sviluppo di codice o modifiche a un sistema. La modellazione delle minacce può verificarsi in momenti diversi, attivata da eventi come una modifica software significativa, una modifica dell'architettura della soluzione o eventi imprevisti di sicurezza.
È consigliabile usare il modello di minaccia STRIDE. Questa metodologia inizia con un diagramma di flusso dei dati e usa le categorie di minacce STRIDE mnemonic (Spoofing, Tampering, Info Disclosure, Ripudiation, Denial of Service e Elevazione dei privilegi) per consentire ai team di identificare, attenuare e convalidare i rischi. Include anche uno strumento di modellazione per notare e visualizzare componenti di sistema, flussi di dati e limiti di sicurezza. La creazione di una modellazione delle minacce nei processi SDLC introduce nuovi processi e più lavoro per mantenere i modelli di minaccia aggiornati. Ciò consente tuttavia di garantire che la sicurezza sia stata eseguita in anticipo, riducendo il potenziale costo di gestione dei problemi di sicurezza rilevati nelle fasi successive di SDLC.

Procedura consigliata: applicare Azure Well Architect Framework (WAF)

Applicare le procedure consigliate per il pilastro della sicurezza WAF che forniscono indicazioni su elementi quali gestione delle identità, sicurezza delle applicazioni, protezione dell'infrastruttura, sicurezza data e DevOps in quanto si applica agli ambienti nativi del cloud.
Applicare le procedure consigliate operative WAF quando si applica a DevSecOps e al monitoraggio degli ambienti di produzione.

Fase di sviluppo

"Spostarsi a sinistra" è un tenant chiave della mentalità DevSecOps. Questo processo inizia prima del commit del codice in un repository e distribuito tramite una pipeline. L'adozione di procedure consigliate per la codifica sicura e l'uso di strumenti e plug-in IDE per l'analisi del codice durante la fase di sviluppo possono aiutare a risolvere i problemi di sicurezza in precedenza nel ciclo di vita dello sviluppo quando sono più facili da risolvere.

Procedura consigliata: applicare standard di codifica sicuri

Usando procedure consigliate ed elenchi di controllo di codifica sicuri stabiliti, è possibile proteggere il codice da vulnerabilità comuni, ad esempio l'inserimento e la progettazione non sicura. La fondazione OWASP pubblica raccomandazioni di codifica sicura standard del settore che è consigliabile adottare durante la scrittura di codice. Queste linee guida sono particolarmente importanti quando si sviluppano applicazioni Web o servizi pubblici.
Oltre alle procedure consigliate per la sicurezza generale, è consigliabile esaminare anche procedure di codifica sicure per i runtime specifici del linguaggio di programmazione, ad esempio Java e .NET.
È possibile applicare gli standard di registrazione per proteggere le informazioni riservate dalla perdita di informazioni nei log applicazioni. I framework di registrazione più diffusi, ad esempio log4j e log4net, forniscono filtri e plug-in per mascherare informazioni riservate come numeri di account o dati personali.

Procedura consigliata: usare gli strumenti e i plug-in dell'IDE per automatizzare i controlli di sicurezza

Gli IDE più diffusi, ad esempio Visual Studio, Visual Studio Code, IntelliJ IDEA ed Eclipse, supportano le estensioni che è possibile usare per ottenere feedback immediato e consigli per potenziali problemi di sicurezza che potrebbero essere stati introdotti durante la scrittura del codice dell'applicazione.

SonarLint è un plug-in IDE disponibile per i linguaggi e gli ambienti di sviluppo più diffusi. SonarLint fornisce feedback prezioso e analizza automaticamente il codice per individuare errori di programmazione comuni e potenziali problemi di sicurezza.
Altri plug-in gratuiti e commerciali sono incentrati su elementi specifici della sicurezza, come le prime 10 vulnerabilità comuni di OWASP. Il plug-in Synk , ad esempio, analizza anche l'origine dell'applicazione e le dipendenze di terze parti e avvisa l'utente se vengono rilevate vulnerabilità.
Il plug-in STATIC Analysis Results Interchange Format (SARIF) per Visual Studio e Visual Studio Code consente di visualizzare facilmente le vulnerabilità dagli strumenti di test sast (Static Application Security Testing) più diffusi in modo intuitivo e facile da leggere rispetto all'interpretazione dei risultati dai file di output JSON non elaborati.

Procedura consigliata: stabilire controlli nei repository di codice sorgente

Stabilire una metodologia di diramazione in modo che sia presente un uso coerente della diramazione in tutta l'azienda. Le metodologie come Il flusso di rilascio e il flusso GitHub hanno linee guida strutturate sul modo in cui i rami devono essere usati per supportare il team e lo sviluppo parallelo. Queste metodologie possono aiutare i team a stabilire standard e controlli per i commit e i merge del codice nel flusso di lavoro CI/CD.
Alcuni rami, ad esempio main, sono rami di lunga durata che mantengono l'integrità del codice sorgente dell'applicazione. Questi rami devono avere stabilito criteri di unione prima che le modifiche possano essere unite o sottoposte a commit. Alcune procedure consigliate includono:
- Impedire ad altri sviluppatori di eseguire il commit del codice direttamente nel ramo principale.
- Stabilire un processo di revisione peer e richiedere un numero minimo di approvazioni prima che le modifiche possano essere unite a un ramo principale. È possibile configurare e applicare facilmente questi controlli con GitHub. GitHub consente anche di designare gruppi di responsabili approvazione autorizzati, se necessario per gli ambienti gestiti.
Usare hook di pre-commit per verificare la presenza di informazioni riservate all'interno del codice sorgente dell'applicazione e impedire che si verifichi un commit se viene rilevato un problema di sicurezza.
- Usare gli hook predefiniti di pre-commit forniti da GitHub che possono essere facilmente configurati per un progetto specifico. Ad esempio, esistono hook predefiniti per l'analisi di segreti, chiavi private e credenziali e impedire un commit se vengono rilevati alcuni di questi problemi.
Stabilire il controllo degli accessi in base al ruolo all'interno del sistema di controllo della versione.
- Creare ruoli ben definiti usando il principio dei privilegi minimi. Una pipeline CI/CD è la supply chain per le distribuzioni di produzione.
- Applicare ruoli di utenti o gruppi stabiliti all'interno dell'organizzazione. I ruoli come Amministrazione, Sviluppatore, Amministratore della sicurezza e Operatore devono essere creati per raggruppare utenti in base al proprio ruolo e funzione specifici relativi ai flussi di lavoro CI/CD.
Abilitare il controllo dei flussi di lavoro in modo da garantire trasparenza e tracciabilità per la configurazione e altre modifiche rispetto alle pipeline CI/CD.

Procedura consigliata: proteggere le immagini del contenitore

Usare immagini leggere con un footprint minimo del sistema operativo per ridurre l'area complessiva di attacco alla superficie. Si considerino immagini minime come Alpine o anche immagini senza distribuzione che contengono solo l'applicazione e il runtime associato. Mariner, la distribuzione Linux open source Microsoft, è una distribuzione leggera e con protezione avanzata progettata per ospitare carichi di lavoro in contenitori per il servizio Azure Kubernetes.
Usare solo immagini di base attendibili durante la compilazione dei contenitori. Queste immagini di base devono essere recuperate da un registro privato che viene spesso analizzato per individuare le vulnerabilità.
Usare gli strumenti di sviluppo per valutare le vulnerabilità delle immagini in locale.
- Trivy è un esempio di uno strumento open source che è possibile usare per analizzare le vulnerabilità di sicurezza all'interno delle immagini del contenitore.
Impedire l'accesso o il contesto utente radice per un'immagine. Per impostazione predefinita, i contenitori vengono eseguiti come radice.
- Per i contenitori che necessitano di sicurezza avanzata, è consigliabile usare un profilo AppArmor all'interno del cluster Kubernetes per applicare ulteriormente la sicurezza per i contenitori in esecuzione.

Fase di compilazione

Durante la fase di compilazione, gli sviluppatori collaborano con i tecnici dell'affidabilità del sito e i team di sicurezza per integrare analisi automatizzate dell'origine dell'applicazione all'interno delle pipeline di compilazione CI. Le pipeline sono configurate per abilitare procedure di sicurezza, ad esempio SAST, SCA e l'analisi dei segreti usando gli strumenti e le estensioni della piattaforma CI/CD.

Procedura consigliata: eseguire l'analisi del codice statico (SAST) per individuare potenziali vulnerabilità nel codice sorgente dell'applicazione

Usare le funzionalità di analisi della sicurezza avanzata di GitHub per l'analisi del codice e CodeQL.
- L'analisi del codice è una funzionalità usata per analizzare il codice in un repository GitHub per trovare vulnerabilità di sicurezza ed errori di codifica. Tutti i problemi identificati dall'analisi vengono visualizzati in GitHub Enterprise Cloud.
- Se l'analisi del codice rileva una potenziale vulnerabilità o un errore nel codice, GitHub visualizza un avviso nel repository.
- È anche possibile configurare le regole di ramo per i controlli di stato necessari, ad esempio per imporre che un ramo di funzionalità sia aggiornato con il ramo di base prima di unire qualsiasi nuovo codice. Questa procedura garantisce che il ramo sia sempre stato testato con il codice più recente.
Usare strumenti come kube-score per analizzare gli oggetti di distribuzione Kubernetes.
- kube-score è uno strumento che esegue l'analisi statica del codice delle definizioni di oggetti Kubernetes.
- L'output è un elenco di raccomandazioni su ciò che è possibile migliorare per rendere l'applicazione più sicura e resiliente.

Procedura consigliata: eseguire l'analisi dei segreti per impedire l'uso fraudolento di segreti di cui è stato eseguito accidentalmente il commit in un repository

Quando l'analisi dei segreti è abilitata per un repository, GitHub analizza il codice per individuare i modelli che corrispondono ai segreti usati da molti provider di servizi.
GitHub esegue periodicamente anche un'analisi completa della cronologia Git del contenuto esistente nei repository e invia notifiche di avviso.
- Per Azure DevOps, Defender per il cloud usa l'analisi dei segreti per rilevare credenziali, segreti, certificati e altri contenuti sensibili nel codice sorgente e nell'output della compilazione.
- L'analisi dei segreti può essere eseguita come parte dell'estensione Microsoft Security DevOps per Azure DevOps.

Procedura consigliata: usare gli strumenti sca (Software Composition Analysis) per tenere traccia dei componenti open source nella codebase e rilevare eventuali vulnerabilità nelle dipendenze

La verifica delle dipendenze consente di intercettare le dipendenze non sicure prima di introdurre tali dipendenze nell'ambiente e fornisce informazioni sulle licenze, sui dipendenti e sull'età delle dipendenze. Offre una visualizzazione facilmente comprensibile delle modifiche alle dipendenze con un'ampia diff nella scheda "File modificati" di una richiesta pull.
Dependabot esegue un'analisi per rilevare le dipendenze non sicure e invia avvisi Dependabot quando viene aggiunto un nuovo avviso al database consultivo GitHub o quando cambia il grafico delle dipendenze per un repository.

Procedura consigliata: abilitare le analisi di sicurezza dei modelli IaC (Infrastructure as Code) per ridurre al minimo gli errori di configurazione del cloud che raggiungono gli ambienti di produzione

Monitorare in modo proattivo le configurazioni delle risorse cloud durante tutto il ciclo di vita dello sviluppo.
Microsoft Defender per DevOps supporta sia GitHub che i repository Azure DevOps.

Procedura consigliata: analizzare le immagini del carico di lavoro nei registri contenitori per identificare le vulnerabilità note

Defender per contenitori analizza i contenitori in Registro Contenitori e Amazon AWS Elastic Container Registry (ECR) per notificare se sono presenti vulnerabilità note nelle immagini.
Criteri di Azure può essere abilitato per eseguire una valutazione della vulnerabilità su tutte le immagini archiviate nel Registro Container e fornire informazioni dettagliate su ogni ricerca.

Procedura consigliata: creare automaticamente nuove immagini in base all'aggiornamento delle immagini di base

Registro Azure Container Attività individua in modo dinamico le dipendenze dell'immagine di base quando compila un'immagine del contenitore. Di conseguenza, può rilevare quando viene aggiornata l'immagine di base di un'immagine dell'applicazione. Con un'attività di compilazione preconfigurata, le attività del Registro Container possono ricompilare automaticamente ogni immagine dell'applicazione che fa riferimento all'immagine di base.

Procedura consigliata: usare Registro Container, Azure Key Vault e notazione per firmare digitalmente le immagini del contenitore e configurare il cluster del servizio Azure Kubernetes per consentire solo immagini convalidate

Azure Key Vault archivia una chiave di firma che può essere usata dalla notazione con il plug-in Key Vault di notazione (azure-kv) per firmare e verificare le immagini del contenitore e altri artefatti. Registro Container consente di allegare queste firme usando i comandi dell'interfaccia della riga di comando di Azure.
I contenitori firmati consentono agli utenti di assicurarsi che le distribuzioni vengano compilate da un'entità attendibile e verificare che un artefatto non sia stato manomesso dopo la creazione. L'artefatto firmato garantisce l'integrità e l'autenticità prima che l'utente esestrae un artefatto in qualsiasi ambiente, evitando così attacchi.
- La ratifica consente ai cluster Kubernetes di verificare i metadati di sicurezza degli artefatti prima della distribuzione e di ammettere solo quelli conformi ai criteri di ammissione creati dall'utente.

Fase di distribuzione

Durante la fase di distribuzione, gli sviluppatori, gli operatori dell'applicazione e i team degli operatori del cluster interagiscono per stabilire i controlli di sicurezza corretti per le pipeline di distribuzione continua (CD) per distribuire il codice in un ambiente di produzione in modo più sicuro e automatizzato.

Procedura consigliata: controllare l'accesso e il flusso di lavoro della pipeline di distribuzione

È possibile proteggere rami importanti impostando le regole di protezione dei rami. Queste regole definiscono se i collaboratori possono eliminare o forzare il push nel ramo. Impostano anche i requisiti per qualsiasi push nel ramo, ad esempio il passaggio di controlli di stato o una cronologia di commit lineare.
Usando gli ambienti per la distribuzione, è possibile configurare gli ambienti con regole di protezione e segreti.
È possibile sfruttare la funzionalità Approvazioni e Gates per controllare il flusso di lavoro della pipeline di distribuzione. Ad esempio, è possibile richiedere approvazioni manuali da un team addetto alla sicurezza o alle operazioni prima di una distribuzione in un ambiente di produzione.

Procedura consigliata: proteggere le credenziali di distribuzione

OpenID Connessione (OIDC) consente ai flussi di lavoro di GitHub Action di accedere alle risorse in Azure senza dover archiviare le credenziali di Azure come segreti GitHub di lunga durata.
Usando gli ambienti per la distribuzione, è possibile configurare gli ambienti con regole di protezione e segreti.
- Un approccio basato sul pull per CI/CD con GitOps consente di spostare le credenziali di sicurezza nel cluster Kubernetes, riducendo così la sicurezza e la superficie di rischio rimuovendo le credenziali dall'archiviazione negli strumenti ci esterni. È anche possibile ridurre le connessioni in ingresso consentite e limitare l'accesso a livello di amministratore ai cluster Kubernetes.

Procedura consigliata: eseguire test di sicurezza delle applicazioni dinamici (DAST) per individuare le vulnerabilità nell'applicazione in esecuzione

Usare GitHub Actions nei flussi di lavoro di distribuzione per eseguire test daST (Application Security Testing) dinamici.
Usare strumenti open source come ZAP per eseguire test di penetrazione per individuare vulnerabilità comuni dell'applicazione Web.

Procedura consigliata: distribuire immagini del contenitore solo da registri attendibili

Usare Defender per contenitori per abilitare Criteri di Azure componente aggiuntivo per Kubernetes.
Abilitare Criteri di Azure in modo che le immagini del contenitore possano essere distribuite solo da registri attendibili.

Fase operativa

Durante questa fase, il monitoraggio delle operazioni e le attività di monitoraggio della sicurezza vengono eseguite per monitorare, analizzare e avvisare in modo proattivo su potenziali eventi imprevisti di sicurezza. Gli strumenti di osservabilità di produzione come Monitoraggio di Azure e Microsoft Sentinel vengono usati per monitorare e garantire la conformità agli standard di sicurezza aziendali.

Procedura consigliata: usare Microsoft Defender per il cloud per abilitare l'analisi automatizzata e il monitoraggio delle configurazioni di produzione

Eseguire un'analisi continua per rilevare la deriva nello stato di vulnerabilità dell'applicazione e implementare un processo per applicare patch e sostituire le immagini vulnerabili.
Implementare il monitoraggio automatico della configurazione per i sistemi operativi.
- Usare Microsoft Defender per il cloud raccomandazioni sui contenitori (nella sezione Calcolo e app) per eseguire analisi di base per i cluster del servizio Azure Kubernetes. Ricevere una notifica nel dashboard Microsoft Defender per il cloud quando vengono rilevati problemi di configurazione o vulnerabilità.
- Usare Microsoft Defender per il cloud e seguire le raccomandazioni sulla protezione di rete per proteggere le risorse di rete usate dai cluster del servizio Azure Kubernetes.
Eseguire una valutazione della vulnerabilità per le immagini archiviate nel Registro Container.
- Implementare analisi continue per l'esecuzione di immagini in Registro Contenitori abilitando Defender per contenitori.

Procedura consigliata: mantenere aggiornati i cluster Kubernetes

Le versioni di Kubernetes vengono implementate frequentemente. È importante disporre di una strategia di gestione del ciclo di vita per assicurarsi di non essere dietro e fuori supporto. Il servizio Azure Kubernetes è un'offerta gestita che offre strumenti e flessibilità per gestire questo processo di aggiornamento. È possibile usare le funzionalità di manutenzione pianificata della piattaforma del servizio Azure Kubernetes per avere maggiore controllo sulle finestre di manutenzione e sugli aggiornamenti.
I nodi del ruolo di lavoro del servizio Azure Kubernetes devono essere aggiornati più frequentemente. Sono disponibili aggiornamenti settimanali del sistema operativo e del runtime, che possono essere applicati automaticamente tramite la modalità automatica o tramite l'interfaccia della riga di comando di Azure per un maggiore controllo e aggiornamenti completi.

Procedura consigliata: usare Criteri di Azure per proteggere e gestire i cluster del servizio Azure Kubernetes

Dopo aver installato il componente aggiuntivo Criteri di Azure per il servizio Azure Kubernetes, è possibile applicare singole definizioni di criteri o gruppi di definizioni di criteri denominate iniziative (detti anche set di criteri) al cluster.
Usare i criteri predefiniti di Azure per scenari comuni, ad esempio impedire l'esecuzione o l'approvazione dei contenitori con privilegi solo per gli indirizzi IP esterni elencati. È anche possibile creare criteri personalizzati per casi d'uso specifici.
Applicare le definizioni dei criteri al cluster e verificare che tali assegnazioni vengano applicate.
Usare Gatekeeper per configurare un controller di ammissione che consenta o nega le distribuzioni in base alle regole specificate. Criteri di Azure estende Gatekeeper.
Proteggere il traffico tra i pod del carico di lavoro usando i criteri di rete nel servizio Azure Kubernetes.
- Installare il motore dei criteri di rete e creare criteri di rete Kubernetes per controllare il flusso di traffico tra i pod nel servizio Azure Kubernetes. I criteri di rete possono essere usati per nodi e pod basati su Linux o Windows nel servizio Azure Kubernetes.

Procedura consigliata: usare Monitoraggio di Azure per il monitoraggio e gli avvisi continui

Usare Monitoraggio di Azure per raccogliere log e metriche dal servizio Azure Kubernetes. Si ottengono informazioni dettagliate sulla disponibilità e sulle prestazioni dell'applicazione e dell'infrastruttura. Consente inoltre di accedere ai segnali per monitorare l'integrità della soluzione e individuare in anticipo l'attività anomala.
- Il monitoraggio continuo con Monitoraggio di Azure si estende alle pipeline di rilascio per controllare o eseguire il rollback delle versioni in base ai dati di monitoraggio. Monitoraggio di Azure inserisce anche i log di sicurezza e può inviare avvisi su attività sospette.
- Eseguire l'onboarding delle istanze del servizio Azure Kubernetes in Monitoraggio di Azure e configurare le impostazioni di diagnostica per il cluster.
  - Per servizio Azure Kubernetes, vedere Baseline di sicurezza di Azure.

Procedura consigliata: usare Microsoft Defender per il cloud per il monitoraggio attivo delle minacce

Microsoft Defender per il cloud fornisce il monitoraggio attivo delle minacce nel servizio Azure Kubernetes a livello di nodo (minacce alle macchine virtuali) e per gli interni.
Defender per DevOps deve essere usato per una visibilità completa e offre ai team di sicurezza e operatori un dashboard centralizzato per tutte le pipeline CI/CD. Questa funzionalità è particolarmente utile se si usano piattaforme multi-pipeline come Azure DevOps e GitHub o si eseguono pipeline tra cloud pubblici.
Defender per Key Vault può essere usato per rilevare tentativi insoliti e sospetti di accedere agli account dell'insieme di credenziali delle chiavi e può avvisare gli amministratori in base alla configurazione.
Defender per contenitori può avvisare le vulnerabilità rilevate all'interno delle immagini del contenitore archiviate nel Registro Container.

Procedura consigliata: abilitare il monitoraggio centralizzato dei log e usare i prodotti SIEM per monitorare le minacce alla sicurezza in tempo reale

Connessione log di diagnostica del servizio Azure Kubernetes in Microsoft Sentinel per il monitoraggio centralizzato della sicurezza in base a modelli e regole. Sentinel consente questo accesso senza problemi tramite i connettori dati.

Procedura consigliata: abilitare la registrazione di controllo per monitorare l'attività nei cluster di produzione

Usare i log attività per monitorare le azioni sulle risorse del servizio Azure Kubernetes per visualizzare tutte le attività e il relativo stato. Determinare quali operazioni sono state eseguite sulle risorse e da chi.
Abilitare la registrazione delle query DNS applicando la configurazione documentata nell'oggetto ConfigMap personalizzato CoreDNS.
Monitorare i tentativi di accesso alle credenziali disattivate.
- Integrare l'autenticazione utente per il servizio Azure Kubernetes con Azure Active Directory (Azure AD). Creare Impostazioni di diagnostica per Azure AD, inviando i log di controllo e di accesso a un'area di lavoro Log Analytics di Azure. Configurare gli avvisi desiderati, ad esempio quando un account disattivato tenta di accedere, all'interno di un'area di lavoro Log Analytics di Azure.

Procedura consigliata: abilitare la diagnostica nelle risorse di Azure

Abilitando la diagnostica di Azure in tutte le risorse del carico di lavoro, è possibile accedere ai log della piattaforma che forniscono informazioni di diagnostica e controllo dettagliate per le risorse di Azure. Questi log possono essere inseriti in Log Analytics o in una soluzione SIEM come Microsoft Sentinel per il monitoraggio della sicurezza e gli avvisi.

Contributori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Adnan Khan | Sr. Cloud Solution Architect

Altri contributori:

Ayobami Ayodeji | Program Manager 2
Ahmed Bham | Sr. Cloud Solution Architect
Chad Kittel | Principal Software Engineer
John Poole | Sr. Cloud Solution Architect
Bahram Rushenas | Sr. Solution Architect
Abed Sau | Sr. Cloud Solution Architect