DevSecOps in Azure Kubernetes Service (AKS)

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 Azure Kubernetes Service (AKS), 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 su AKS (Azure Kubernetes Service)
• Ingegneri cloud che creano un'infrastruttura AKS 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, si consiglia di esaminare Creare e distribuire app su AKS usando DevOps e GitOps.

Flusso di processo

Scaricare un file Visio di questa architettura.

1. Microsoft Entra ID è configurato come provider di identità per GitHub. Configurare l'autenticazione a più fattori (MFA) per garantire una maggiore sicurezza di autenticazione.
2. 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à della sicurezza.
3. Gli sviluppatori eseguono il commit del codice dell'applicazione in un repository aziendale di proprietà e regolamentato GitHub Enterprise.
4. GitHub Enterprise integra l'analisi automatica della sicurezza e delle dipendenze tramite GitHub Advanced Security.
5. Le richieste pull attivano compilazioni di integrazione continua (CI) e test automatizzati tramite GitHub Actions.
6. Il flusso di lavoro di compilazione CI tramite GitHub Actions genera un'immagine del contenitore Docker archiviata in Azure Container Registry.
7. È 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.
8. GitHub Actions abilitano il CD su AKS (Azure Kubernetes Service). Usare GitHub Sicurezza avanzata per rilevare segreti, credenziali e altre informazioni riservate nei file di origine e configurazione dell'applicazione.
9. Microsoft Defender viene usato per analizzare Azure Container Registry, 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 di accedere agli account key vault.
10. Azure Policy può essere applicata al Registro Contenitori e Azure Kubernetes Service (AKS) per garantire la conformità e l'applicazione dei criteri. I criteri di sicurezza comuni per Registro Container e AKS sono integrati per un'integrazione rapida.
11. 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.
12. Il motore delle politiche di rete di AKS è configurato per proteggere il traffico tra i pod dell'applicazione utilizzando le politiche di rete di Kubernetes.
13. È possibile configurare il monitoraggio continuo del cluster del servizio Azure Kubernetes usando Azure Monitor e Container insights per inserire le metriche delle prestazioni e analizzare i log delle applicazioni e della sicurezza.
    1. Approfondimenti sui container recuperano le metriche delle prestazioni e i log delle applicazioni e dei cluster.
    2. I log diagnostici e applicativi vengono raccolti in un'area di lavoro di Azure Log Analytics per eseguire query di log.
14. Microsoft Sentinel, che è 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.
15. Open-Source strumenti come Zed Attack Proxy (ZAP) (ZAP) possono essere usati per eseguire test di penetrazione per applicazioni Web e servizi.
16. Defender per DevOps, un servizio disponibile in Defender for Cloud, consente ai team di sicurezza di gestire la sicurezza devOps in ambienti multi-pipeline, tra cui GitHub e Azure DevOps.

Descrizione dei membri del team e delle loro responsabilità

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.

Gli sviluppatori

Gli sviluppatori sono responsabili della scrittura del codice dell'applicazione. Sono anche responsabili dell'invio del codice nel repository assegnato. 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 creazione di immagini container 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 come Azure Monitor Informazioni dettagliate sui contenitori 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 Azure Policy applicata nelle sottoscrizioni e nei gruppi di risorse in cui sono presenti 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 Visio di questa architettura.

Fase di pianificazione

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 e le problematiche di sicurezza siano adeguatamente presi in considerazione o mitigati.

Procedura consigliata: progettare una piattaforma applicativa più sicura

La creazione di una piattaforma ospitata su AKS è un passaggio importante per garantire che la sicurezza sia integrata nel sistema a ogni livello, a partire dalla stessa piattaforma. 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 ulteriori informazioni, vedere AKS in una zona di atterraggio applicativa, che include aree di progettazione critiche come la sicurezza, l'identità e la 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 dello sviluppo di codice o delle modifiche apportate 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 utilizza l'acronimo mnemonico STRIDE (Spoofing, Manomissione, Divulgazione di informazioni, Rifiuto, Negazione del servizio 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 migliori pratiche operative WAF nell'ambito di DevSecOps e nel 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 generali, è 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 commenti e suggerimenti immediati sui potenziali problemi di sicurezza 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à dei comuni strumenti SAST (Static Application Security Testing) 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 Release flow e GitHub flow hanno linee guida strutturate su come usare i rami 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 tra pari e richiedere un numero minimo di approvazioni prima che le modifiche possano essere unite in 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 ganci di pre-commit per verificare la presenza di informazioni riservate all'interno del codice sorgente dell'applicazione e impedire un commit se viene rilevato un problema di sicurezza.
  • Usare gli hook pre-commit integrati 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 catena di fornitura per i rilasci di produzione.
  • Applicare ruoli di utenti o gruppi stabiliti all'interno dell'organizzazione. I ruoli come Amministratore, Sviluppatore, Amministratore della sicurezza e Operatore devono essere creati per raggruppare utenti in base al ruolo e alla 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

• Utilizzare immagini leggere con un impatto minimo sul sistema operativo per ridurre la superficie totale di attacco. Si considerino immagini minime come Alpine o persino immagini distroless che contengono solo l'applicazione e il relativo runtime. Mariner, la distribuzione Linux open source di Microsoft, è una distribuzione leggera e con protezione avanzata progettata per AKS al fine di ospitare carichi di lavoro containerizzati.
• 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 dell'utente root o il contesto di un'immagine. Per impostazione predefinita, i contenitori vengono eseguiti come utente root.
  • 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à avanzate di analisi della sicurezza di GitHub per l'analisi del codice con CodeQL.
  • Code scanning è 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 secret scanning è abilitato 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 for 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 chiara rappresentazione delle modifiche alle dipendenze con un ricco diff nella scheda "File modificati" di una pull request.
• Dependabot esegue un'analisi per rilevare 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 repository GitHub che 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 nel Registro dei Contenitori e in Amazon AWS Elastic Container Registry (ECR) per notificarti se sono presenti vulnerabilità note nelle immagini.
• Azure Policy può essere abilitata per eseguire una valutazione della vulnerabilità su tutte le immagini archiviate nel Registro Contenitori e fornire informazioni dettagliate su ogni ricerca.

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

• Azure Container Registry Tasks individua dinamicamente le dipendenze dell'immagine di base quando compila un'immagine del contenitore. Di conseguenza, è in grado di 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 da notation con il plug-in di notazione Key Vault (azure-kv) per firmare e verificare immagini del contenitore e altri artefatti. Registro Container consente di allegare queste firme usando i comandi Azure CLI.
• 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 eseguire un push forzato al branch. Impostano anche i requisiti per qualsiasi push nel ramo, ad esempio i controlli di stato da superare 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 Connect (OIDC) consente ai flussi di lavoro GitHub Action di accedere alle risorse in Azure senza dover archiviare le credenziali di Azure come segreti di 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 di sicurezza delle applicazioni dinamici (DAST).
• 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 il componente aggiuntivo Azure Policy per Kubernetes.
• Abilitare Azure Policy 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 Azure Monitor 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.
  • Usa le raccomandazioni di Microsoft Defender per il cloud sui contenitori (nella sezione Compute e apps) per eseguire scansioni di base sui cluster AKS. Ricevere una notifica nel dashboard di Microsoft Defender for Cloud quando vengono rilevati problemi di configurazione o vulnerabilità.
  • Usare Microsoft Defender for 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 delle immagini in esecuzione nel Registry di Contenitori mediante l'abilitazione di Defender per Contenitori.

Procedura consigliata: mantenere aggiornati i cluster Kubernetes

• Le versioni di Kubernetes vengono rilasciate frequentemente. È importante disporre di una strategia di gestione del ciclo di vita per assicurarsi di non rimanere indietro e di non essere più supportati. AKS è un'offerta gestita che offre strumenti e flessibilità per gestire questo processo di aggiornamento. È possibile usare le funzionalità di manutenzione pianificata della piattaforma AKS 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. Forniamo aggiornamenti settimanali del sistema operativo e del runtime, che possono essere applicati automaticamente tramite la modalità automatica o tramite il Azure CLI per un maggiore controllo e aggiornamenti completi.

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

• Dopo aver installato il componente aggiuntivo Azure Policy per il servizio Azure Kubernetes, è possibile applicare singole definizioni di criteri o gruppi di definizioni di criteri denominati iniziative (detti anche set di criteri) al cluster.
• Usare i criteri integrati di Azure per scenari comuni, ad esempio impedire l'esecuzione di container privilegiati o approvare solo indirizzi IP esterni consentiti tramite whitelist. È 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. Azure Policy estende Gatekeeper.
• Proteggere il traffico tra i pod dei workload usando i criteri di rete in Azure Kubernetes Service (AKS).
  • Installare il motore delle politiche di rete e creare politiche di rete Kubernetes per controllare il flusso di traffico tra i pod in AKS. La politica di rete può essere utilizzata per nodi e pod basati su Linux o Windows in AKS.

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

• Usare Azure Monitor per raccogliere log e metriche da AKS. 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 Azure Monitor si estende alle pipeline di rilascio per controllare o eseguire il rollback delle versioni in base ai dati di monitoraggio. Azure Monitor inserisce anche i log di sicurezza e può avvisare l'attività sospetta.
  • Esplora le istanze AKS in Azure Monitor e configura le impostazioni di diagnostica per il tuo cluster.
    • Consultare Azure baseline di sicurezza per Azure Kubernetes Service.

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

• Microsoft Defender for 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 key vault 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

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

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 di Azure Kubernetes Service (AKS) per visualizzare tutte le attività e il loro stato. Determinare quali operazioni sono state eseguite sulle risorse e da chi.
• Abilita la registrazione delle query DNS applicando la configurazione documentata nel ConfigMap personalizzato di CoreDNS.
• Monitorare i tentativi di accesso alle credenziali disattivate.
  • Integrare l'autenticazione utente per Azure Kubernetes Service (AKS) con Microsoft Entra ID. Creare impostazioni di diagnostica per Microsoft Entra ID, inviando i log di controllo e di accesso a un'area di lavoro di Azure Log Analytics. Configurare gli avvisi desiderati, ad esempio quando un account disattivato tenta di accedere, all'interno di un'area di lavoro Azure Log Analytics.

Procedura consigliata: abilitare la diagnostica nelle risorse Azure

• Abilitando Azure diagnostica 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 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 collaboratori:

• Ayobami Ayoodeji | Program Manager 2
• Ahmed Bham | Sr. Cloud Solution Architect
• Chad Kittel | Principal Software Engineer - Modelli e Pratiche Azure
• John Poole | Sr. Cloud Solution Architect
• Bahram Rushenas | Sr. Solution Architect
• Abed Sau | Sr. Cloud Solution Architect

Passaggi successivi

• Microsoft Defender for Containers
• DevOps sicuro
• Sicurezza in DevOps (DevSecOps)
• Sicurezza avanzata di GitHub
• GitOps

" output is necessary.)

• DevSecOps for Infrastructure as Code (IaC)
• Maiusc a sinistra