Condividi tramite


Baseline di governance, sicurezza e conformità per Kubernetes con abilitazione di Azure Arc

Questo articolo fornisce considerazioni chiave sulla progettazione e procedure consigliate per la sicurezza, la governance e la conformità da usare per la compilazione della distribuzione di Kubernetes abilitata per Azure Arc. Mentre la documentazione della zona di destinazione su scala aziendale illustra governance e sicurezza come argomenti separati, queste aree di progettazione critiche vengono consolidate in un singolo argomento per Kubernetes abilitato per Azure Arc.

Criteri di Azure e Microsoft Defender per il cloud sono strumenti nativi del cloud che consentono di implementare l'implementazione di protezioni, controlli, report, avvisi e attività di correzione in modo automatizzato su larga scala. Combinandoli con Kubernetes abilitato per Azure Arc, è possibile estendere i criteri di governance e i controlli di sicurezza a qualsiasi cluster Kubernetes nell'ambiente locale e/o multicloud.

Architettura

Il diagramma seguente illustra un'architettura di riferimento concettuale che illustra le aree di progettazione di sicurezza, conformità e governance per Kubernetes con abilitazione di Azure Arc:

Diagramma che mostra la sicurezza, la governance e la conformità su scala aziendale per Kubernetes con abilitazione di Azure Arc.

Considerazioni relative alla progettazione

Man mano che le risorse ibride e multicloud diventano parte di Azure Resource Manager, è possibile gestirle e gestirle da Azure. Questa sezione contiene considerazioni sulla progettazione da tenere presenti durante la pianificazione della sicurezza e della governance delle risorse del cluster Kubernetes abilitate per Azure Arc.

Esaminare le aree di progettazione della sicurezza e della governance delle zone di destinazione di Azure per valutare l'effetto di Kubernetes abilitato per Azure Arc sui modelli di governance e sicurezza complessivi.

Provisioning dell'agente

Definire una strategia per il provisioning dell'agente Kubernetes abilitato per Azure Arc e usare il principio dei privilegi minimi durante la creazione dell'entità servizio di onboarding. È consigliabile usare l'automazione per la registrazione in blocco.

Gestione dell'agente

Gli agenti Kubernetes abilitati per Azure Arc svolgono un ruolo fondamentale nelle operazioni ibride dei cluster Kubernetes abilitati per Azure Arc, in quanto consentono di gestire i cluster da Azure. Implementare soluzioni che tengono traccia dello stato di connettività dell'agente. Assicurarsi di definire un processo per l'aggiornamento degli agenti Kubernetes abilitati per Azure Arc.

Controlli degli accessi in base al ruolo

Definire ruoli amministrativi, operativi e per sviluppatori all'interno dell'organizzazione responsabili delle operazioni quotidiane nei cluster ibridi. Il mapping di ogni team alle azioni e alle responsabilità determina i ruoli di controllo degli accessi in base al ruolo di Azure e il cluster KubernetesRoleBinding e RoleBinding.

Prendere in considerazione l'uso di una matrice RACI per supportare questo sforzo e creare controlli nella gerarchia dell'ambito di gestione definita in base alla coerenza delle risorse e alle indicazioni sulla gestione dell'inventario.

Per altre informazioni, vedere Gestione delle identità e degli accessi per Kubernetes abilitato per Azure Arc.

Gestione dei segreti e dei certificati

Proteggere segreti e certificati usando Azure Key Vault e distribuendone l'estensione nei cluster Kubernetes abilitati per Azure Arc tramite l'interfaccia di archiviazione contenitori (CSI).

Residenza dei dati

Considerare l'area di Azure in cui si prevede di effettuare il provisioning del cluster Kubernetes abilitato per Azure Arc. Comprendere i dati raccolti dalle risorse e pianificare di conseguenza in base ai requisiti di residenza dei dati per l'organizzazione.

Abilitare e proteggere le configurazioni di GitOps

Le configurazioni di GitOps applicano uno stato del sistema desiderato e sono uno strumento importante per tenere traccia della conformità del cluster Kubernetes abilitata per Arc. Quando si utilizzano configurazioni GitOps, è consigliabile proteggere l'accesso al sistema di controllo del codice sorgente tramite controlli di rete e di accesso appropriati.

Gestione e creazione di report dei criteri

Definire un piano di governance per i cluster Kubernetes ibridi che si traducono in criteri di Azure che controllano e applicano standard aziendali su larga scala. Ad esempio, è possibile applicare un criterio sourceControlConfiguration ai cluster Kubernetes per assicurarsi che i cluster ottengano la loro origine di verità per carichi di lavoro e configurazioni da un repository Git definito e tenere traccia della conformità usando Criteri di Azure.

Strategia di gestione dei log

Esaminare le considerazioni e le raccomandazioni per la progettazione dell'area di progettazione critica delle discipline di gestione e pianificare la raccolta di metriche e log dalle risorse ibride in un'area di lavoro Log Analytics per ulteriori analisi e controllo.

Protezione dalle minacce e gestione del comportamento di sicurezza cloud

Applicare la protezione dalle minacce e introdurre controlli per rilevare errori di configurazione della sicurezza e tenere traccia della conformità. Usare l'intelligenza di Azure per proteggere i carichi di lavoro ibridi dalle minacce. Abilitare il monitoraggio delle baseline di sicurezza, la gestione del comportamento di sicurezza e la protezione dalle minacce per tutte le sottoscrizioni contenenti Kubernetes abilitando Microsoft Defender per contenitori.

Proteggere l'accesso al cluster

Pianificare l'accesso sicuro all'API Kubernetes. La funzionalità di connessione del cluster Kubernetes abilitata per Azure Arc offre connettività al server API senza che sia necessaria alcuna porta in ingresso abilitata.

Migliorare l'osservabilità e la sicurezza dei microservizi

L'implementazione di una mesh di servizi può essere utile per l'autenticazione, l'autorizzazione, la sicurezza e la visibilità delle applicazioni basate su microservizi. Kubernetes abilitato per Azure Arc semplifica la distribuzione di Open Service Mesh (OSM) come estensione.

Suggerimenti per la progettazione

Questa sezione contiene raccomandazioni sulla progettazione da seguire durante la pianificazione della sicurezza e della governance delle risorse del cluster Kubernetes abilitate per Azure Arc.

Provisioning dell'agente

  • Definire una strategia per l'onboarding dei cluster in Azure Arc, incluso un metodo di automazione per la registrazione in blocco. Definire un piano formale che tenga conto dell'ambito della distribuzione e includa obiettivi, criteri di selezione, criteri di successo, piani di formazione, rollback e rischi.

  • È possibile usare un'entità servizio per integrare il provisioning degli agenti come parte delle pipeline di integrazione continua e distribuzione continua (CI/CD). È consigliabile limitare i privilegi di questa entità servizio e assegnare solo i ruoli necessari per eseguire l'onboarding di Kubernetes in Azure (il ruolo "Cluster Kubernetes - Onboarding di Azure Arc"), poiché può essere usato solo per eseguire l'onboarding di Kubernetes, non annullare il processo o eliminare la risorsa.

Gestione dell'agente

Gli agenti Di Azure Arc sono componenti chiave di Kubernetes abilitati per Azure Arc, contenenti diversi componenti logici che svolgono un ruolo nelle operazioni di sicurezza, governance e gestione.

Se un agente smette di inviare heartbeat ad Azure, passa offline o perde la connettività ad Azure, non è possibile eseguire attività operative. Sviluppare un piano per ricevere una notifica se si verificano questi scenari e come l'organizzazione deve rispondere.

È possibile usare il log attività di Azure per configurare gli avvisi di integrità delle risorse e rimanere informati sullo stato di integrità corrente e cronologico dei pod dell'agente. Per comprendere come gestire correttamente l'agente, esaminare l'area di progettazione critica per la gestione.

Se il servizio non ha ricevuto un heartbeat dell'agente per 15 minuti, il cluster Kubernetes abilitato per Azure Arc viene visualizzato come offline. Per assicurarsi che l'agente possa connettersi in modo sicuro agli endpoint di Azure Arc, esaminare l'area di progettazione critica per la connettività di Kubernetes abilitata per Azure Arc.

Controlli degli accessi in base al ruolo

Dopo aver eseguito l'onboarding di un cluster Kubernetes, è possibile assegnare il controllo degli accessi in base al ruolo di Azure alla risorsa del cluster Kubernetes abilitata per Azure Arc.

Seguire il principio dei privilegi minimi quando si assegnano ruoli come "Collaboratore" o "Proprietario" che possono eseguire operazioni come la distribuzione di estensioni che eseguono azioni come "ClusterAdmin" e hanno un effetto a livello di cluster. Questi ruoli devono essere usati con cautela per limitare il possibile "raggio di esplosione" o alla fine essere sostituiti da ruoli personalizzati.

È necessario applicare lo stesso principio di controllo degli accessi in base al ruolo ai dati sensibili inviati all'area di lavoro Log Analytics di Monitoraggio di Azure. Kubernetes abilitato per Azure Arc consente di accedere al controllo degli accessi in base al ruolo ai dati di log raccolti dall'agente di Log Analytics, archiviati nell'area di lavoro Log Analytics in cui è registrato il cluster. Per informazioni su come implementare l'accesso granulare all'area di lavoro Log Analytics, vedere Progettazione della distribuzione dei log di Monitoraggio di Azure.

L'integrazione del cluster Kubernetes abilitato per Azure Arc con Microsoft Entra ID consente di usare le assegnazioni di ruolo di Azure per un controllo più granulare su chi può accedere a e autorizzazioni per le risorse del cluster Kubernetes abilitate per Azure Arc.

Nota

Questa integrazione funziona in modo nativo con i tipi di oggetti Kubernetes ClusterRoleBinding e RoleBinding e consolida efficacemente l'autorizzazione per il cluster Kubernetes con Microsoft Entra ID come servizio di gestione centrale delle identità e degli accessi. Usando Microsoft Entra ID, si ottiene il controllo completo e la traccia delle modifiche apportate nel cluster, nonché gli eventi di autorizzazione.

L'integrazione con Microsoft Entra ID consente anche di accedere a funzionalità di sicurezza avanzate, che è consigliabile usare per configurare:

  • Accesso condizionale con Microsoft Entra ID. Altre informazioni sull'accesso condizionale sono disponibili nella panoramica dell'accesso condizionale.
  • Regole di accesso JIT (Just-In-Time) per le attività che richiedono autorizzazioni elevate. L'accesso permanente ad alcuni utenti alle informazioni riservate o alle impostazioni di configurazione di rete critiche in Kubernetes crea un potenziale percorso per gli account compromessi o le attività di minaccia interne. La gestione degli accessi con privilegi consente di proteggere l'organizzazione dalle violazioni e di soddisfare le procedure consigliate di conformità limitando l'accesso permanente ai dati sensibili o l'accesso alle impostazioni di configurazione critiche.

Gestione dei segreti e dei certificati

Non archiviare segreti o certificati nel codice dell'applicazione o nei file system. I segreti devono essere archiviati negli archivi chiavi e forniti ai contenitori in fase di esecuzione secondo necessità.

Prendere in considerazione l'uso dell'estensione Azure Key Vault per gestire segreti e certificati nei cluster Kubernetes abilitati per Azure Arc. L'estensione Key Vault consente di gestire il ciclo di vita del certificato nelle distribuzioni Kubernetes, come illustrato nel diagramma seguente.

Diagramma che illustra l'integrazione di Kubernetes e Key Vault abilitate per Azure Arc.

Abilitare e proteggere le configurazioni di GitOps

GitOps è un componente essenziale di qualsiasi strategia IT che adotta un approccio completamente automatizzato alle operazioni. GitOps offre funzionalità di scalabilità, coerenza, rilevamento e controllo per qualsiasi distribuzione.

L'uso di GitOps consente di semplificare la distribuzione di più applicazioni tra cluster e ambienti durante il rilevamento e l'applicazione dello stato desiderato del sistema in modo dichiarativo con Git. Quando si usa Git come singola origine di verità e come strumento centrale per tutte le distribuzioni, diventa il modo migliore per tenere traccia degli stati del cluster, tenere conto delle modifiche e delle approvazioni nel tempo, facilitare l'analisi degli errori e abilitare l'automazione negli ambienti distribuiti.

Quando si aggiungono configurazioni GitOps, assicurarsi di proteggere l'accesso al repository e alle relative chiavi e impostare le autorizzazioni per i rami. Per altre informazioni, vedere l'area di progettazione critica per GitOps.

Gestione e creazione di report dei criteri

La governance basata su criteri è un principio fondamentale delle operazioni native del cloud e di Microsoft Cloud Adoption Framework per Azure. Criteri di Azure fornisce il meccanismo per applicare gli standard aziendali e valutare la conformità su larga scala. Tramite Criteri di Azure, è possibile implementare la governance per la coerenza delle distribuzioni, della conformità, dei costi di controllo, del comportamento di sicurezza. Nel dashboard di conformità è possibile visualizzare una visualizzazione aggregata dello stato complessivo dell'ambiente su larga scala e trovare funzionalità di correzione a livello di cluster.

Kubernetes abilitato per Azure Arc supporta Criteri di Azure a livello di Gestione risorse di Azure e anche le imposizione dei criteri nel cluster estendendo Gatekeeper per Open Policy Agent. È possibile implementare uno dei criteri predefiniti per ottenere rapidamente conformità e applicazione su larga scala. Il diagramma seguente illustra come Criteri di Azure applica le imposizione e le misure di sicurezza su larga scala ai cluster Kubernetes abilitati per Azure Arc.

Diagramma che mostra i criteri Kubernetes abilitati per Azure Arc.

Comprendere l'ambito dei criteri di Azure e la posizione in cui è possibile applicarla (gruppo di gestione, sottoscrizione, gruppo di risorse o livello di singola risorsa). Usare la libreria predefinita di Criteri di Azure per Kubernetes con abilitazione di Azure Arc. Creare una progettazione di un gruppo di gestione in base alle procedure consigliate descritte nelle linee guida per la scalabilità aziendale di Cloud Adoption Framework.

  • Determinare i criteri di Azure necessari per soddisfare i requisiti aziendali, normativi e di sicurezza dell'organizzazione per Kubernetes abilitato per Azure Arc su larga scala.
  • Applicare l'assegnazione di tag e implementare attività di correzione.
  • Usare Criteri di Azure per applicare GitOps e applicare configurazioni su larga scala.
  • Comprendere e valutare Criteri di Azure definizioni predefinite per Kubernetes con abilitazione di Azure Arc.
  • I criteri DeployIfNotExists di Criteri di Azure distribuiscono a livello di codice gli agenti del servizio di gestione/estensioni nei cluster abilitati per Arc su larga scala, incluso Monitoraggio di Azure.
  • Abilitare Azure Monitor Container Insights per la conformità e il monitoraggio operativo dei cluster Kubernetes abilitati per Azure Arc.

Strategia di gestione dei log

Progettare e pianificare la distribuzione dell'area di lavoro Log Analytics, ovvero l'archiviazione in cui vengono raccolti, aggregati e analizzati in seguito. Poiché l'area di lavoro Log Analytics rappresenta una posizione geografica dei dati, per supportare un livello di isolamento e ambito per configurazioni come la conservazione dei dati, è necessario determinare il numero di aree di lavoro necessarie e il relativo mapping alla struttura organizzativa.

Usare una singola area di lavoro Log Analytics di Monitoraggio di Azure per gestire il controllo degli accessi in base al ruolo, la visibilità e la creazione di report centralizzati, come descritto in Procedure consigliate per la gestione e il monitoraggio di Cloud Adoption Framework.

Per altre informazioni, vedere le procedure consigliate per la progettazione della distribuzione dei log di Monitoraggio di Azure.

Protezione dalle minacce e gestione del comportamento di sicurezza cloud

  • Microsoft Defender per il cloud offre una piattaforma di gestione della sicurezza unificata segmentata come gestione del comportamento di sicurezza cloud (CSPM) e una piattaforma di protezione del carico di lavoro cloud (CWPP). Per aumentare la sicurezza nella zona di destinazione ibrida, è necessario proteggere i dati e gli asset ospitati in Azure e altrove.
  • Microsoft Defender per contenitori estende le funzionalità di Microsoft Defender per il cloud a Kubernetes abilitato per Azure Arc. Per aumentare la sicurezza nella zona di destinazione ibrida, prendere in considerazione:
    • Uso dell'estensione Kubernetes abilitata per Azure Arc per eseguire l'onboarding delle risorse Kubernetes abilitate per Arc in Microsoft Defender per il cloud.
    • Abilitazione del piano Microsoft Defender per contenitori per tutte le sottoscrizioni. Per impostazione predefinita, il piano è configurato per distribuire automaticamente l'estensione Defender in qualsiasi cluster Kubernetes abilitato per Arc di cui viene eseguito l'onboarding nella stessa sottoscrizione. Facoltativamente, è possibile modificare questa configurazione.
    • Verifica che l'estensione Defender sia distribuita nei cluster.
    • Uso dell'integrazione siem (Security Information and Event Management) con Microsoft Defender per il cloud e Microsoft Sentinel.

Il diagramma seguente illustra un'architettura di riferimento concettuale per Microsoft Defender per il cloud in una risorsa cluster Kubernetes abilitata per Azure Arc.

Diagramma che illustra Microsoft Defender per Kubernetes abilitato per Azure Arc.

Se si usa Registro Azure Container come registro Docker privato centrale per l'archiviazione e la gestione delle immagini del contenitore, è consigliabile usare Microsoft Defender per contenitori per analizzare le immagini per individuare le vulnerabilità.

Assicurarsi di esaminare l'area di progettazione critica della topologia di rete e della connettività.

Proteggere l'accesso al cluster

L'API Kubernetes riceve richieste per eseguire azioni nel cluster. Poiché si tratta di un modo centrale per interagire e gestire un cluster, l'API Kubernetes è un elemento chiave da proteggere. Usando la connessione al cluster Kubernetes abilitato per Azure Arc, è possibile connettersi in modo sicuro ai cluster Kubernetes abilitati per Azure Arc ovunque senza dover abilitare alcuna porta in ingresso nel firewall. L'accesso al server API di Kubernetes abilitato per Azure Arc offre i vantaggi seguenti:

  • Abilita il debug interattivo e la risoluzione dei problemi.
  • Consente l'uso di agenti/strumenti di esecuzione ospitati di Azure Pipelines, GitHub Actions o di qualsiasi altro servizio CI/CD ospitato, senza richiedere agenti self-hosted.
  • Fornisce l'accesso al cluster ai servizi di Azure per posizioni personalizzate e altre risorse create sopra di esse.

Osservabilità e sicurezza dei microservizi

L'implementazione di una mesh di servizi consente di introdurre l'autenticazione e l'autorizzazione per le connessioni ai servizi, che applica il principio dei privilegi minimi e crea un ambiente più sicuro. Per impostazione predefinita, i pod si trovano in una rete attendibile flat. In un'implementazione mesh di servizi viene distribuito un set di sidecar che fungono da proxy di rete. Questi sidecar gestiscono la comunicazione east-west, crittografano il traffico e migliorano l'osservabilità complessiva del traffico.

Le implementazioni mesh di servizi possono proteggersi da:

  • Accessi non autorizzati
  • Attacchi di analisi
  • Esfiltrazione di dati
  • Rappresentazioni

Per altre informazioni, vedere l'area di progettazione critica per l'implementazione di Open Service Mesh.

Passaggi successivi

Per altre informazioni sul percorso cloud ibrido e multicloud, vedere gli articoli seguenti.