DevSecOps in servizio Azure Kubernetes (AKS)

DevSecOps, chiamato anche Secure DevOps, si basa sulla pratica di DevOps incorporando la sicurezza in fasi diverse 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 fornendo visibilità sulle minacce alla sicurezza e impedire che le vulnerabilità raggiungano gli ambienti distribuiti
• Aumento della consapevolezza della sicurezza con i team di sviluppo e operazioni
• Incorporando processi di sicurezza automatizzati nel ciclo di vita dello sviluppo software
• Riduzione dei costi da correggere individuando i problemi di sicurezza nelle fasi 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. Esempi di questi diversi ruoli dell'organizzazione sono:

• Sviluppatori che creano applicazioni sicure in esecuzione nel servizio Azure Kubernetes
• Cloud Engineers building secure AKS infrastructure (Infrastruttura del servizio Azure Kubernetes sicura)
• Vari team operativi che potrebbero gestire i cluster o monitorare i problemi di sicurezza

Questo articolo viene suddiviso in diverse fasi del ciclo di vita di DevOps con considerazioni e raccomandazioni 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 distribuzione continua (CI/CD), optando per strumenti predefiniti facili da usare, dove 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.

1. Azure Active Directory (Azure AD) è configurato come provider di identità per GitHub. Configurare l'autenticazione a più fattori (MFA) per offrire 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 le vulnerabilità di sicurezza.
3. Gli sviluppatori esegue 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 archiviata in Registro Azure Container.
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 abilitare CD in Servizio Azure Kubernetes. Usare GitHub Advanced Security per rilevare segreti, credenziali e altre informazioni riservate nei file di origine e configurazione dell'applicazione.
9. Microsoft Defender viene usato per analizzare Registro Azure Container, cluster del servizio Azure Kubernetes e Key Vault di Azure per le vulnerabilità di sicurezza.
   1. Microsoft Defender per i contenitori analizza l'immagine del contenitore per le vulnerabilità di sicurezza note al caricamento nel Registro contenitori.
   2. È anche possibile usare Defender per contenitori per eseguire analisi dell'ambiente del servizio Azure Kubernetes e fornisce la protezione delle 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.
10. Criteri di Azure può essere applicato al Registro contenitori e servizio Azure Kubernetes (AKS) per la conformità e l'applicazione dei criteri. I criteri di sicurezza comuni per Il Registro contenitori e il servizio Azure Kubernetes sono incorporati per l'abilitazione 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 dei criteri di rete del servizio Azure Kubernetes è configurato per proteggere il traffico tra i pod dell'applicazione usando i criteri di rete Kubernetes.
13. Il monitoraggio continuo del cluster del servizio Azure Kubernetes può essere configurato usando Monitoraggio di Azure e Informazioni dettagliate sui contenitori per inserire le metriche delle prestazioni e analizzare i log delle applicazioni e della sicurezza.
    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 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 eventuali minacce di sicurezza basate su modelli e regole definite.
15. Open-Source strumenti come Open Web Application Security Project (OWASP 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.

Panoramica e responsabilità dei membri del team

Valutare la complessità delle distribuzioni di soluzioni basate su Kubernetes in modo da separare le problematiche. Quale team in un ambiente aziendale deve essere interessato a ogni aspetto della distribuzione? Quali strumenti e processi devono usare un team per raggiungere meglio i propri obiettivi? In questa sezione vengono descritti i ruoli comuni degli sviluppatori, gli operatori dell'applicazione (ingegneri di affidabilità del sito), gli operatori del cluster e i 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 principali responsabilità degli sviluppatori include anche la creazione e l'esecuzione di script per il test automatizzato per garantire che il codice funzioni come previsto e si integra facilmente con il resto dell'applicazione. Definiscono e scriptano anche la compilazione di immagini del contenitore come parte della pipeline di automazione.

Operatori dell'applicazione (ingegneri di affidabilità del sito)

La creazione di applicazioni nel cloud tramite contenitori e Kubernetes può semplificare lo sviluppo, la distribuzione e la scalabilità delle applicazioni. 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. Essi fungono da ponte tra team di sviluppo e operatori del cluster e consentono di stabilire e monitorare gli obiettivi e i budget degli errori a livello di servizio. In questo modo, consentono di gestire le distribuzioni delle applicazioni e spesso scrivere file manifesto kubernetes (YAML).

Operatori del cluster

Gli operatori del cluster sono responsabili della configurazione e della gestione dell'infrastruttura del cluster. Spesso usano le procedure consigliate e i framework dell'infrastruttura come codice (IaC) come GitOps per effettuare il provisioning e gestire i cluster. Usano vari strumenti di monitoraggio, ad esempio informazioni dettagliate di Azure Monitor Container e Prometheus/Grafana per monitorare l'integrità complessiva del cluster. Sono responsabili dell'applicazione di patch, aggiornamenti del cluster, autorizzazioni e 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 lavorano con il team di sicurezza per creare tali standard.

Team responsabile della sicurezza

Il team di sicurezza è responsabile dello sviluppo di standard di sicurezza e dell'applicazione di tali standard. 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, assicurarsi che la sicurezza venga portata all'avanguardia di 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 è una parte fondamentale di una strategia DevSecOps e dell'approccio a sinistra di turno.

Scaricare un file di Visio di questa architettura.

Fase piano

La fase del piano ha in genere la quantità minima di automazione, ma ha importanti implicazioni per la sicurezza che influiscono significativamente sulle fasi successive del ciclo di vita di DevOps. Questa fase comporta la collaborazione tra team di sicurezza, sviluppo e operazioni. Incluse le parti interessate alla sicurezza in questa fase di progettazione e pianificazione, garantisce che i requisiti di sicurezza e i problemi di sicurezza siano in modo appropriato per o ridotti.

Procedura consigliata: progettare una piattaforma applicazione più sicura

La creazione di una piattaforma ospitata dal servizio Azure Kubernetes più sicura è un passaggio importante per garantire che la sicurezza sia incorporata 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: compilare 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 significativa del software, una modifica 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 usa le categorie di minacce STRIDE mnemonic (spoofing, manomissione, manomissione, ripudio, denial of service e elevazione dei privilegi) per consentire ai team di identificare, mitigare e convalidare il rischio. Include anche uno strumento di modellazione per notare e visualizzare componenti di sistema, flussi di dati e limiti di sicurezza. La creazione di modellazione delle minacce nei processi SDLC introduce nuovi processi e un maggiore lavoro per mantenere i modelli di minaccia aggiornati. Tuttavia, aiuta a garantire che la sicurezza sia disponibile in anticipo, che consente di ridurre il potenziale costo di gestire i problemi di sicurezza rilevati nelle fasi successive di SDLC.

Procedura consigliata: applicare Azure Well Architect Framework (WAF)

• Applicare le procedure consigliate per la sicurezza WAF che forniscono indicazioni per gli elementi come 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 che il codice venga eseguito anche il commit 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 le procedure consigliate e gli elenchi di controllo per la codifica sicuri stabiliti, è possibile proteggere il codice da vulnerabilità comuni, ad esempio l'inserimento e la progettazione non sicura. La base OWASP pubblica raccomandazioni di codifica sicura standard del settore che è necessario 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 del linguaggio di programmazione specifici, ad esempio Java e .NET.
• È possibile applicare gli standard di registrazione per proteggere le informazioni riservate dalla perdita di dati 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 strumenti e 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 raccomandazioni 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 se vengono rilevate vulnerabilità.
• Il plug-in SARIF (Static Analysis Results Interchange Format) per Visual Studio e Visual Studio Code consente di visualizzare facilmente le vulnerabilità degli strumenti di test di sicurezza delle applicazioni statiche (SAST) 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 del 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 su come usare i rami per supportare il team e lo sviluppo parallelo. Queste metodologie consentono ai team di definire standard e controlli per i commit e le operazioni di 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 predefiniti forniti da GitHub che possono essere facilmente configurati per un progetto specifico. Ad esempio, sono disponibili hook predefiniti per analizzare i segreti, le chiavi private e le credenziali e impedire un commit se viene rilevato uno 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 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

• Usare immagini leggere con un footprint minimo del sistema operativo per ridurre l'area di attacco di superficie complessiva. Prendere in considerazione immagini minime come Alpine o anche immagini senza distribuzione che contengono solo l'applicazione e il runtime associato. Mariner, la distribuzione Di Linux open source Microsoft, è una distribuzione leggera e 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 richiedono una sicurezza avanzata, prendere in considerazione l'uso di 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 e i team di sicurezza per l'affidabilità del sito per integrare analisi automatizzate dell'origine dell'applicazione all'interno delle pipeline di compilazione CI. Le pipeline sono configurate per abilitare procedure di sicurezza come l'analisi SAST, SCA e 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 GitHub Advanced Security funzionalità di analisi per l'analisi del codice e CodeQL.
  • L'analisi del codice è una funzionalità usata per analizzare il codice in un repository GitHub per individuare 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 degli 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 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 di analisi della composizione software (SCA) per tenere traccia dei componenti open source nella codebase e rilevare eventuali vulnerabilità nelle dipendenze

• La verifica delle dipendenze consente di rilevare le dipendenze non sicure prima di presentarle all'ambiente e di fornire informazioni su licenze, dipendenti e età delle dipendenze. Fornisce una visualizzazione facilmente comprensibile delle modifiche alle dipendenze con una differenza 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: abilitare le analisi di sicurezza dei modelli di infrastruttura come codice (IaC) per ridurre al minimo le configurazioni 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 i 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 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 nell'aggiornamento dell'immagine 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 la notazione Key Vault plug-in (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, in modo da evitare 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.

Fase di distribuzione

Durante la fase di distribuzione, gli sviluppatori, gli operatori delle applicazioni e i team degli operatori del cluster collaborano per stabilire i controlli di sicurezza appropriati 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 i 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 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 una distribuzione in un ambiente di produzione.

Procedura consigliata: proteggere le credenziali di distribuzione

• OpenID Connect (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 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 OWASP ZAP per eseguire test di penetrazione per le vulnerabilità comuni dell'applicazione Web.

Procedura consigliata: distribuire immagini di contenitori 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 dai registri attendibili.

Fase di funzionamento

Durante questa fase, il monitoraggio delle operazioni e le attività di monitoraggio della sicurezza vengono eseguite per monitorare in modo proattivo, analizzare e inviare avvisi 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à con gli 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 l'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 le raccomandazioni sui contenitori cloud (nella sezione Calcolo e app) per eseguire analisi di base per i cluster del servizio Azure Kubernetes. Ricevere una notifica nel dashboard di Microsoft Defender for Cloud quando vengono rilevati problemi di configurazione o vulnerabilità.
  • Usare Microsoft Defender per Cloud e seguire le raccomandazioni sulla protezione della 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 contenitori.
  • Implementare analisi continue per l'esecuzione di immagini nel Registro contenitori abilitando Defender per i contenitori.

Procedura consigliata: mantenere aggiornati i cluster Kubernetes

• Le versioni di Kubernetes vengono implementate di frequente. È importante avere una strategia di gestione del ciclo di vita per assicurarsi di non essere indietro 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 più controllo sulle finestre di manutenzione e sugli aggiornamenti.
• I nodi 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 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 denominati iniziative (chiamati anche set di criteri) nel cluster.
• Usare criteri di Azure predefiniti per scenari comuni, ad esempio impedire l'esecuzione o l'approvazione di 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 consente 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 pod nel servizio Azure Kubernetes. I criteri di rete possono essere usati per i nodi e i pod basati su Linux in Azure Kubernetes.

Procedura consigliata: usare Monitoraggio di Azure per il monitoraggio continuo e l'avviso

• 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 l'attività anormale in anticipo.
  • Il monitoraggio continuo con Monitoraggio di Azure si estende alle pipeline di rilascio alle versioni di gate o rollback in base ai dati di monitoraggio. Monitoraggio di Azure inserisce anche i log di sicurezza e può avvisare l'attività sospetta.
  • Eseguire l'onboarding delle istanze del servizio Azure Kubernetes in Monitoraggio di Azure e configurare le impostazioni di diagnostica per il cluster.
    • Vedere Baseline di sicurezza di Azure per servizio Azure Kubernetes.

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

• Microsoft Defender per Cloud fornisce il monitoraggio delle minacce attivo nel servizio Azure Kubernetes a livello di nodo (minacce della macchina virtuale) e per gli interni.
• Defender per DevOps deve essere usato per la visibilità completa e fornisce team di sicurezza e operatori con 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 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. Sentinel consente l'accesso senza problemi tramite connettori dati.

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

• Usare i log attività per monitorare le azioni nelle risorse del servizio Azure Kubernetes per visualizzare tutte le attività e il relativo stato. Determinare le operazioni eseguite sulle risorse e da chi.
• Abilitare la registrazione delle query DNS applicando la configurazione documentata nella configurazione personalizzata 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 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 di Azure Log Analytics.

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 dettagliate di diagnostica e controllo 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 l'avviso.

Autori di contributi

Questo articolo viene gestito da Microsoft. È stato originariamente scritto dai collaboratori seguenti.

Autore principale:

• Adnan Khan | Sr. Cloud Solution Architect

Altri collaboratori:

• Ayobami Ayodeji | Program Manager 2
• Ahmed Bham | Sr. Cloud Solution Architect
• Chad Kittel | Ingegnere software principale
• John Poole | Sr. Cloud Solution Architect
• Bahram Rushenas | Sr. Solution Architect
• Abed Sau | Sr. Cloud Solution Architect

Passaggi successivi

• Microsoft Defender for Cloud
• Secure DevOps
• Sicurezza in DevOps (DevSecOps)
• GitHub Advanced Security
• GitOps

Risorse correlate

• DevSecOps in GitHub
• DevSecOps per l'infrastruttura come codice (IaC)
• DevSecOps con una strategia di diramazione principale in sequenza
• Spostamento a sinistra