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. Integrare la sicurezza nelle procedure devOps per:

• Rendere le applicazioni e i sistemi più sicuri, offrire visibilità sulle minacce alla sicurezza e impedire che le vulnerabilità raggiungano gli ambienti distribuiti.

• Aumentare la consapevolezza della sicurezza tra i team operativi e di sviluppo.

• Incorporare processi di sicurezza automatizzati nel ciclo di vita dello sviluppo software (SDLC).

• Ridurre i costi di correzione individuando i problemi di sicurezza nelle fasi di sviluppo e progettazione.

Quando si applica DevSecOps al servizio Azure Kubernetes, ogni ruolo dell'organizzazione ha considerazioni specifiche sulla sicurezza:

• Gli sviluppatori creano applicazioni sicure in esecuzione su AKS.

• Gli ingegneri cloud costruiscono un'infrastruttura AKS sicura.

• I team operativi possono gestire i cluster o monitorare i problemi di sicurezza.

Questo articolo organizza le linee guida per la fase del ciclo di vita DevOps e fornisce raccomandazioni per i controlli di sicurezza e le procedure consigliate. Vengono trattati processi e strumenti comuni per l'integrazione continua e le pipeline di recapito continuo (CI/CD), con particolare attenzione agli strumenti predefiniti.

Flusso del processo

Il flusso inizia con uno sviluppatore che si connette a Microsoft Entra ID e funziona in strumenti di sviluppo come Visual Studio e Visual Studio Code. Lo sviluppatore esegue il push del codice in GitHub, che funge da sistema di controllo del codice sorgente centrale. Da GitHub, il processo continua in GitHub Actions, in cui vengono eseguiti i passaggi automatizzati. Altre connessioni mostrano pull request, processi di approvazione per le distribuzioni e controlli di sicurezza che vengono inseriti in questa fase. GitHub Advanced Security e Microsoft Defender per DevOps si connettono a GitHub. La pipeline si connette quindi a Registro Azure Container, che si trova tra il processo di compilazione e la destinazione di distribuzione. Controlli di governance e sicurezza, inclusi Microsoft Defender e Criteri di Azure, si collegano sopra e accanto a questa fase. Dal registro, il flusso passa ad AKS, visualizzato all'interno di un'area separata a destra che rappresenta l'ambiente di esecuzione. Intorno all'ambiente Kubernetes, diversi componenti connessi si diramano. Questi componenti includono Azure Policy e Azure Key Vault sopra, Log Analytics e Microsoft Sentinel a destra e strumenti come Criteri di rete, Monitoraggio di Azure per contenitori e Zed Attack Proxy (ZAP) in basso.

Scaricare un file di Visio di questa architettura.

Note

Questo articolo fa riferimento al servizio Azure Kubernetes e a GitHub, ma è possibile applicare queste raccomandazioni a qualsiasi piattaforma di orchestrazione dei contenitori o CI/CD. I dettagli di implementazione possono variare, ma la maggior parte dei concetti e delle procedure per ogni fase è ancora applicabile.

1. L'ID Microsoft Entra è 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à di sicurezza.

3. Gli sviluppatori eseguono il commit del codice dell'applicazione in un repository GitHub Enterprise di proprietà dell'azienda e regolamentato.

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 e la archivia in Registro Azure Container.

7. È possibile aggiungere approvazioni manuali per le distribuzioni ad ambienti specifici, ad esempio la produzione, come parte del flusso di lavoro di consegna continua (CD) in GitHub Actions.

8. GitHub Actions abilita il CD su AKS. Usare GitHub Advanced Security per rilevare segreti, credenziali e altre informazioni riservate nei file di origine e configurazione dell'applicazione.

9. Microsoft Defender analizza registro contenitori, il 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 quando GitHub Actions lo carica nel Registro Container.

   2. Defender per contenitori può anche analizzare l'ambiente del servizio Azure Kubernetes e fornire la protezione dalle minacce di runtime per i cluster del servizio Azure Kubernetes.

   3. Microsoft Defender per Key Vault rileva tentativi insoliti e sospetti di accedere agli account di Key Vault.

10. È possibile applicare Criteri di Azure al Registro dei container e ad AKS per garantire la conformità ai criteri. I criteri di Azure includono criteri di sicurezza predefiniti per il Registro contenitori e il servizio Azure Kubernetes (AKS).

11. Key Vault inserisce in modo sicuro segreti e credenziali in un'applicazione in fase di esecuzione senza esporli agli 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. È consigliabile usare Azure CNI Powered by Cilium come motore dei criteri di rete. Fornisce un'applicazione estesa basata su eBPF (Berkeley Packet Filter), i criteri di livello 7 e il filtro del nome di dominio completo (FQDN).

13. È possibile configurare il monitoraggio continuo del cluster del servizio Azure Kubernetes utilizzando Monitoraggio di Azure per raccogliere metriche Prometheus, log container ed eventi Kubernetes. Usare i dashboard di Grafana gestiti di Azure per la visualizzazione e Log Analytics per gli avvisi basati su query.

    1. Monitoraggio di Azure raccoglie le metriche delle prestazioni tramite Prometheus gestito e i log dell'applicazione e del cluster tramite la raccolta di log dei contenitori.

    2. Un'area di lavoro di Log Analytics archivia i log diagnostici e delle applicazioni per eseguire query sui log.

14. Usare Microsoft Sentinel come sistema centralizzato di gestione delle informazioni e degli eventi di sicurezza (SIEM) per correlare i dati di telemetria di Azure Kubernetes Service (AKS) con i segnali provenienti da Microsoft Defender for Cloud, Microsoft Entra ID e risorse di rete. Microsoft Sentinel fornisce rilevamento, indagine e risposta automatica agli eventi imprevisti di sicurezza nell'intero ambiente del servizio Azure Kubernetes.

15. Strumenti open source come Zed Attack Proxy (ZAP) possono 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 multipipeline, 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 dividendo le responsabilità tra i team. Questa sezione descrive i ruoli e le responsabilità degli sviluppatori, degli operatori dell'applicazione, ad esempio ingegneri dell'affidabilità del sito, operatori del cluster e team di sicurezza.

Gli sviluppatori

Gli sviluppatori scrivono il codice dell'applicazione ed eseguono il commit nel repository designato. Creano ed eseguono script per i test automatizzati per assicurarsi che il codice funzioni come previsto e si integra con il resto dell'applicazione. Gli sviluppatori definiscono e scrivono script per la creazione di immagini del container come parte della pipeline di automazione.

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

La creazione di applicazioni 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 che automatizzano il modo in cui i team supervisionano sistemi software di grandi dimensioni. Fungono da ponte tra i team degli operatori di sviluppo e cluster. Consentono di stabilire e monitorare gli obiettivi del livello di servizio (SLO) e gli error budget. I tecnici dell'affidabilità del sito aiutano anche a gestire le distribuzioni delle applicazioni e a scrivere file manifesto (YAML) di Kubernetes.

Operatori del cluster

Gli operatori del cluster configurano e gestiscono l'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 strumenti di monitoraggio come il servizio gestito Azure Monitor per Prometheus e Azure Managed 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 gli operatori del cluster collaborano con i team di sicurezza per stabilire gli standard di sicurezza e assicurarsi che i cluster soddisfino tali requisiti.

Team di sicurezza

Il team di sicurezza sviluppa e applica gli standard di sicurezza. Alcuni team possono creare e selezionare definizioni di Criteri di Azure applicate tra le sottoscrizioni e i gruppi di risorse che contengono i cluster. I team di sicurezza monitorano i problemi di sicurezza e collaborano con altri team per assegnare priorità alla sicurezza durante il processo DevSecOps.

Fasi del ciclo di vita devSecOps

Ogni fase di SDLC implementa i controlli di sicurezza. Questi controlli di sicurezza sono fondamentali per DevSecOps e le pratiche di 'shift-left'.

Al centro c'è un hub etichettato come sicurezza, che si connette a ogni fase del ciclo. Cinque fasi circondano questo punto centrale disposto in un ciclo: pianificare, sviluppare, compilare, rilasciare e operare. Ogni fase include esempi di procedure di sicurezza applicabili a tale fase. La modellazione delle minacce, i criteri di sicurezza e le procedure di Azure Well-Architected Framework vengono eseguite durante la pianificazione. Durante lo sviluppo si verificano standard di codifica sicura e plug-in di sicurezza IDE (Integrated Development Environment). I test di sicurezza delle applicazioni statici (SAST), l'analisi della composizione software (SCA) e l'analisi dei segreti vengono eseguite durante la compilazione, i test dinamici di sicurezza delle applicazioni (DAST), i test di penetrazione e le approvazioni del flusso di lavoro durante il rilascio e la registrazione, gli avvisi, siem e il monitoraggio della rete vengono eseguiti durante l'operazione. Le frecce connettono le fasi in sequenza per mostrare un flusso continuo e le connessioni collegano ogni fase alla funzione di sicurezza centrale.

Scaricare un file di Visio di questa architettura.

Fase di pianificazione

La fase del piano ha in genere la minima quantità di automazione, ma ha importanti implicazioni di sicurezza che influiscono sulle fasi successive del ciclo di vita devOps. Questa fase prevede la collaborazione tra team di sicurezza, sviluppo e operazioni. Per garantire di considerare o mitigare i requisiti di sicurezza e i problemi correlati, includere gli stakeholder della sicurezza in questa fase.

Procedura consigliata: Progettare una piattaforma di applicazioni sicura

Per creare un carico di lavoro ospitato dal servizio Azure Kubernetes sicuro, è necessario incorporare la sicurezza 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.

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. È possibile modellare e trovare minacce in un sistema per risolvere le vulnerabilità prima di sviluppare codice o apportare modifiche. I team eseguono la modellazione delle minacce in risposta a modifiche software significative, modifiche dell'architettura della soluzione o eventi imprevisti di sicurezza.

È consigliabile usare il modello di minaccia STRIDE. Questa metodologia inizia con un diagramma del flusso di dati e classifica le minacce usando il mnemonic STRIDE: Spoofing, Manomissione, Ripudio, Divulgazione informazioni, Denial of Service e Elevazione dei privilegi. I team usano queste categorie per identificare, attenuare e convalidare i rischi. Uno strumento di modellazione consente di notare e visualizzare componenti di sistema, flussi di dati e limiti di sicurezza.

La creazione di una modellazione delle minacce in SDLC comporta un sovraccarico del processo e richiede la manutenzione dei modelli di minaccia aggiornati. Tuttavia, risolve la sicurezza all'inizio dello sviluppo, riducendo così il costo di correzione dei problemi individuati in un secondo momento.

Pratica consigliata: Applicare Azure Well-Architected Framework

• Applicare le procedure consigliate per la sicurezza che forniscono indicazioni per la gestione delle identità, la sicurezza delle applicazioni, la protezione dell'infrastruttura, la sicurezza dei dati e DevOps come si applica agli ambienti nativi del cloud.

• Applicare le procedure consigliate per l'eccellenza operativa quando si applica a DevSecOps e al monitoraggio degli ambienti di produzione.

Fase di sviluppo

Lo spostamento a sinistra è un elemento chiave della mentalità devSecOps. Questo processo inizia prima di eseguire il commit del codice in un repository e distribuirlo tramite una pipeline. Per risolvere i problemi di sicurezza in precedenza nel ciclo di vita dello sviluppo, adottare procedure consigliate per la codifica sicura e usare strumenti e plug-in dell'ambiente di sviluppo integrato (IDE) per l'analisi del codice durante la fase di sviluppo.

Procedura consigliata: applicare standard di codifica sicuri

• Usare procedure consigliate ed elenchi di controllo per la codifica sicura stabiliti per proteggere il codice da vulnerabilità comuni, ad esempio l'inserimento e la progettazione non sicura. La fondazione Open Worldwide Application Security Project (OWASP) pubblica raccomandazioni di codifica sicura standard del settore da adottare quando si scrive codice. Queste linee guida sono particolarmente importanti quando si sviluppano applicazioni Web o servizi pubblici.

• Esaminare le procedure di codifica sicura per i runtime specifici del linguaggio di programmazione, ad esempio Java e .NET.

• 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 Apache Log4j e Apache log4net, forniscono filtri e plug-in per mascherare informazioni riservate, ad esempio 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, VS 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.

• SonarQube per IDE è un plug-in IDE per i linguaggi e gli ambienti di sviluppo più diffusi. SonarQube per l'IDE fornisce commenti e suggerimenti e analizza automaticamente il codice per individuare errori di programmazione comuni e potenziali problemi di sicurezza.

• Altri plug-in gratuiti e commerciali si concentrano su elementi specifici della sicurezza, come le prime 10 vulnerabilità comuni di OWASP. Il plug-in Snyk analizza anche l'origine dell'applicazione e le dipendenze esterne e avvisa se rileva vulnerabilità.

• Il plug-in SARIF (Static Analysis Results Interchange Format) per Visual Studio e VS Code consente di visualizzare facilmente le vulnerabilità degli strumenti comuni di test di sicurezza delle applicazioni statiche (SAST) 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 per la coerenza in tutta l'azienda. Le metodologie come Il flusso di rilascio e il flusso GitHub hanno linee guida strutturate su come usare 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. Stabilire criteri di merge per questi rami prima di eseguire il commit o l'unione delle modifiche. Ad esempio, puoi:

  • Impedire ad altri sviluppatori di eseguire il commit del codice direttamente nel ramo principale.

  • Stabilire un processo di verifica tra pari e richiedere un numero minimo di approvazioni prima di unire le modifiche alla branch principale. Configurare e applicare questi controlli usando GitHub. Usare GitHub per designare gruppi di responsabili approvazione autorizzati, se necessario per gli ambienti gestiti.

• Usare hook precommit per verificare la presenza di informazioni riservate nel codice sorgente dell'applicazione e bloccare i commit quando vengono rilevati problemi di sicurezza.

  • Utilizzare gli hook di pre-commit integrati forniti da GitHub. Configurarli facilmente per progetti specifici. Ad esempio, alcuni hook predefiniti analizzano i segreti, le chiavi private e le credenziali e bloccano un commit se rilevano questi problemi.

• Impostare il controllo degli accessi in base al ruolo (RBAC) nel sistema di controllo della versione.

  • Creare ruoli ben definiti usando il principio dei privilegi minimi. Una pipeline CI/CD funziona come supply chain per le distribuzioni di produzione.

  • Applicare ruoli di utenti o gruppi stabiliti all'interno dell'organizzazione. Per raggruppare utenti in base al proprio ruolo e funzione specifici nei flussi di lavoro CI/CD, creare ruoli come Admin, Developer, Security Admin e Operator.

• Abilitare il controllo dei flussi di lavoro per aggiungere trasparenza e tracciabilità per la configurazione e altre modifiche alle pipeline CI/CD.

Procedura consigliata: Proteggere le immagini del contenitore

• Usare immagini leggere con un footprint minimo del sistema operativo per ridurre la superficie di attacco complessiva. Prendere in considerazione immagini minime come Alpine o immagini senza distribuzione che contengono solo l'applicazione e il runtime associato.

• Usare solo immagini di base attendibili quando si compilano i contenitori. Recuperare queste immagini di base da un registro privato che analizzi frequentemente per vulnerabilità.

• Usare gli strumenti di sviluppo per valutare le vulnerabilità delle immagini in locale. Trivy è uno strumento open source che analizza le vulnerabilità di sicurezza all'interno delle immagini del contenitore.

• Impedire l'accesso dell'utente root o il suo contesto a 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 o seccomp 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 tecnici e team di sicurezza per l'affidabilità del sito per integrare analisi automatizzate dell'origine dell'applicazione all'interno delle pipeline di compilazione CI. Teams configura le pipeline per abilitare le procedure di sicurezza usando gli strumenti e le estensioni della piattaforma CI/CD. Queste pratiche includono SAST, analisi della composizione software (SCA) e scansione delle credenziali.

Procedura consigliata: eseguire 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.

  • L'analisi del codice è una funzionalità che analizza il codice in un repository GitHub per individuare le vulnerabilità di sicurezza e gli errori di codifica. Vengono visualizzati i problemi in GitHub Enterprise Cloud.

  • Se l'analisi del codice rileva una potenziale vulnerabilità o un errore nel codice, GitHub visualizza un avviso nel repository.

  • È possibile configurare le regole del ramo per i controlli di stato necessari. Ad esempio, è possibile richiedere che i rami di funzionalità siano aggiornati con il ramo di base prima di unire nuovo codice. Questo requisito garantisce di testare il ramo con il codice più recente.

  • Abilita Copilot Autofix per ricevere suggerimenti di correzione generati dall'intelligenza artificiale per gli avvisi di scansione del codice. Copilot Autofix propone correzioni direttamente nelle pull request, che consentono agli sviluppatori di risolvere rapidamente i problemi di sicurezza.

• Usare strumenti come kube-score per analizzare gli oggetti di distribuzione Kubernetes. Questo strumento esegue l'analisi statica del codice delle definizioni di oggetti Kubernetes. Restituisce un elenco di raccomandazioni per rendere l'applicazione più sicura e resiliente.

Migliore prassi: usare l'analisi dei segreti per rilevare segreti accidentalmente commessi.

• Quando si abilita l'analisi dei segreti per un repository, GitHub analizza il codice per individuare i modelli che corrispondono ai segreti usati da molti provider di servizi.

• GitHub esegue periodicamente 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 compilare l'output.

  • È possibile eseguire l'analisi dei segreti come parte dell'estensione Microsoft Security DevOps per Azure DevOps.

Procedura consigliata: usare gli strumenti SCA per tenere traccia dei componenti open source nella codebase e rilevare le vulnerabilità nelle dipendenze

• La verifica delle dipendenze consente di intercettare le dipendenze non sicure prima di introdurre tali dipendenze nell'ambiente. Fornisce anche informazioni sulla licenza, sui dipendenti e sull'età delle dipendenze. Visualizza le modifiche alle dipendenze tramite una diff avanzata 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 di consulenza GitHub o quando cambia il grafico delle dipendenze per un repository.

Procedura consigliata: Generare un SBOM per le immagini del contenitore

• Un software bill of materials (SBOM) fornisce un inventario completo dei componenti, delle librerie e delle dipendenze che costituiscono le immagini del container. Usare strumenti di generazione SBOM come Microsoft sbom-tool o Syft durante la compilazione CI per produrre un manifesto SPDX o CicloneDX.

• Collegare un SBOM alle immagini del contenitore archiviate nel Registro Contenitori per abilitare l'analisi delle vulnerabilità downstream e il rilevamento della conformità delle licenze nell'intera catena di approvvigionamento.

Procedura consigliata: Analizzare i modelli IaC per rilevare errori di configurazione prima della distribuzione

• Monitorare in modo proattivo le configurazioni delle risorse cloud durante il ciclo di vita dello sviluppo.

• Microsoft Defender per DevOps supporta sia i repository GitHub che Azure DevOps e possono analizzare i modelli IaC per identificare le vulnerabilità IaC.

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 Elastic Container Registry (ECR) per notificare le vulnerabilità note nelle immagini.

• È possibile abilitare Criteri di Azure per eseguire una valutazione della vulnerabilità sulle immagini archiviate in Registro Container e fornire informazioni dettagliate su ogni ricerca.

Procedura consigliata: Creare automaticamente nuove immagini sugli aggiornamenti delle immagini di base

• Le attività del Registro Container individuano dinamicamente le dipendenze dell'immagine di base quando compila un'immagine del contenitore. Quando rileva un aggiornamento dell'immagine di base di un'immagine dell'applicazione, è possibile configurare un'attività di compilazione per ricompilare automaticamente le immagini dell'applicazione che fanno riferimento a tale immagine di base.

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

• Key Vault archivia le chiavi di firma usate dallo strumento di notazione . Il plug-in Key Vault per la notazione (azure-kv) accede a queste chiavi per firmare e verificare le immagini dei container e altri artefatti. È possibile allegare queste firme alle immagini del Registro Container usando i comandi dell'interfaccia della riga di comando di Azure.

• I contenitori firmati assicurano che le distribuzioni provengano da un'origine attendibile e che gli artefatti non vengano manomessi 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.

  • Ratify verifica i metadati di sicurezza degli artefatti e applica le politiche di ammissione prima della distribuzione nei cluster Kubernetes. AKS Image Integrity utilizza Ratify come verificatore integrato per validare le firme delle immagini e le attestazioni SBOM prima che i pod vengano ammessi al cluster.

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 cd. Questi controlli consentono di distribuire il codice in un ambiente di produzione in modo 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 i push nel ramo, ad esempio il passaggio di controlli di stato o una cronologia di commit lineare.

• Usare gli ambienti per la distribuzione per configurare le regole di protezione e i segreti.

• Usare le funzionalità di approvazione e gate 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 eseguire la 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.

• Usare un approccio basato sul pull per CI/CD con GitOps per spostare le credenziali di sicurezza nel cluster Kubernetes. Questo approccio riduce la superficie di rischio e sicurezza rimuovendo le credenziali dagli 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 DAST per individuare le vulnerabilità nell'applicazione in esecuzione

• Usa GitHub Actions nei flussi di lavoro di distribuzione per eseguire test di sicurezza delle applicazioni dinamiche (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 i container per abilitare il componente aggiuntivo Criteri di Azure per Kubernetes.

• Configurare Azure Policy per Kubernetes per limitare le implementazioni di immagini del container a registri attendibili.

Fase operativa

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

Procedura consigliata: usare Defender for Cloud per analizzare e monitorare automaticamente le 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 sui contenitori in Defender for Cloud (nella sezione Calcolo e app) per eseguire scansioni di riferimento per i cluster di Azure Kubernetes Service. Defender for Cloud visualizza eventuali problemi di configurazione o vulnerabilità nel dashboard.

  • Usare Defender for Cloud e seguire le raccomandazioni sulla protezione di rete per proteggere le risorse di rete del cluster AKS.

• Eseguire una valutazione della vulnerabilità per le immagini archiviate nel Registro Container.

  • Implementare analisi continue delle immagini in esecuzione nel Registro dei Contenitori abilitando Defender per Contenitori.

Procedura consigliata: Mantenere aggiornati i cluster Kubernetes

• Kubernetes rilascia frequentemente nuove versioni. Mantenere una strategia di gestione del ciclo di vita per mantenere i cluster supportati e aggiornati. AKS fornisce strumenti per gestire gli aggiornamenti del cluster. Usare le funzionalità di manutenzione pianificata del servizio Azure Kubernetes per controllare quando si verificano finestre di manutenzione e aggiornamenti.

• Aggiorna frequentemente i nodi agenti di AKS. Azure rilascia aggiornamenti settimanali del sistema operativo e del runtime. Applicare questi aggiornamenti automaticamente tramite la modalità automatica o manualmente tramite l'interfaccia della riga di comando di Azure per un maggiore controllo.

Procedura consigliata: usare Azure Policy per proteggere e gestire i cluster AKS

• Dopo aver installato il componente aggiuntivo Criteri di Azure per AKS, è possibile applicare singole definizioni di criteri o gruppi di definizioni di criteri, denominati iniziative o set di criteri, al cluster.

• Usare criteri predefiniti di Azure per scenari comuni, ad esempio impedire l'esecuzione di container privilegiati o limitare gli indirizzi IP esterni a un elenco consentito. È anche possibile creare criteri personalizzati per casi d'uso specifici.

• Applicare le definizioni dei criteri al cluster e verificare che Azure Policy applichi tali assegnazioni.

• 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).

  • Usare Azure CNI Powered by Cilium come motore delle politiche di rete. Cilium usa un piano dati basato su eBPF e supporta i criteri nativi di Kubernetes, i criteri di livello 7 e il filtro FQDN.

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

• Usare Azure Monitor per raccogliere log e metriche da AKS. Raccogliere le metriche di Prometheus tramite il servizio gestito di Azure Monitor per Prometheus, eseguire query sui log dei container e della piattaforma in Log Analytics e visualizzare l'integrità del cluster tramite i dashboard di Azure Managed Grafana.

  • Azure Monitor estende il monitoraggio continuo alle pipeline di rilascio. Usare i dati di monitoraggio per approvare o eseguire il rollback dei rilasci. Monitoraggio di Azure inserisce anche log di sicurezza e avvisi su attività sospette.

  • Collegare le istanze di AKS ad Azure Monitor e configurare le impostazioni di diagnostica per il cluster.

    Per altre informazioni, vedere Baseline di sicurezza di Azure per AKS.

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

• Defender for Cloud offre il monitoraggio attivo delle minacce per il servizio Azure Kubernetes a livello di nodo (minacce alle macchine virtuali) e ai carichi di lavoro del cluster.

• Usare Defender per DevOps per ottenere visibilità completa su tutte le pipeline CI/CD. Fornisce ai team addetti alla sicurezza e all'operatore un dashboard centralizzato. Si trae vantaggio soprattutto da questa visibilità centralizzata quando si usano piattaforme con più pipeline come Azure DevOps e GitHub o si eseguono pipeline tra cloud pubblici.

• Defender per Key Vault rileva tentativi insoliti e sospetti di accedere agli account di Key Vault e può inviare avvisi agli amministratori secondo la configurazione.

• Defender per contenitori può avvisare le vulnerabilità rilevate all'interno delle immagini del contenitore archiviate nel Registro Contenitori.

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 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 AKS per visualizzare tutte le attività e il relativo stato. Determinare chi ha eseguito le operazioni sulle risorse.

• Abilitare la registrazione delle query DNS (Domain Name System) applicando la configurazione documentata in CoreDNS custom ConfigMap.

• Monitorare i tentativi di accesso alle credenziali disattivate.

  Integrare l'autenticazione utente per AKS con Microsoft Entra ID. Creare le impostazioni di diagnostica per Microsoft Entra ID e inviare i log di controllo e accesso a un'area di lavoro Log Analytics. Nell'area di lavoro Log Analytics configurare gli avvisi per gli eventi di sicurezza, ad esempio i tentativi di accesso da account disattivati.

Procedura consigliata: Abilitare la diagnostica nelle risorse di Azure

• Abilitare la diagnostica di Azure in tutte le risorse del carico di lavoro per accedere ai log della piattaforma che forniscono informazioni di diagnostica e controllo dettagliate. È possibile inserire questi log in Log Analytics o in una soluzione SIEM come Microsoft Sentinel per il monitoraggio e gli avvisi di sicurezza.

Collaboratori

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

• Adnan Khan | Sr. Cloud Solution Architect

Altri contributori:

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

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Defender per contenitori
• DevOps sicuro
• Sicurezza in DevOps (DevSecOps)
• Sicurezza avanzata di GitHub

Risorse correlate

• GitOps
• DevSecOps per IaC
• Maiusc a sinistra