Architettura di un cluster di regolamentato AKS per PCI-DSS 3.2.1 (parte 2 di 9)

Questo articolo descrive un'architettura di riferimento per un cluster Servizio Azure Kubernetes (AKS) che esegue un carico di lavoro in conformità allo Standard di sicurezza dei dati del settore delle carte di pagamento (PCI-DSS 3.2.1). Questa architettura è incentrata sull'infrastruttura e non sul carico di lavoro PCI-DSS 3.2.1.

Questo articolo fa parte di una serie. Leggere l'introduzione.

Le raccomandazioni e gli esempi sono estratti da questa implementazione di riferimento associata:

Il GitHub: cluster di base del Servizio Azure Kubernetes (AKS) per carichi di lavoro regolamentati illustra l'infrastruttura regolamentata. Questa implementazione fornisce un'applicazione di microservizi. È incluso per facilitare l'esperienza dell'infrastruttura e illustrare i controlli di rete e sicurezza. L'applicazione non rappresenta o implementa un carico di lavoro PCI DSS effettivo.

Scaricare un file di Visio di questa architettura.

L'architettura di rete si basa su una topologia hub-spoke. La rete virtuale hub contiene il firewall per controllare il traffico in uscita, il traffico del gateway dalle reti locali e una terza rete per l'accesso al cluster SRE (site reliability engineer). Esistono due reti virtuali spoke. Uno spoke contiene il cluster di AKS che è un componente dell'ambiente cde (Card-Holder Environment) e ospita il carico di lavoro PCI DSS. L'altro spoke compila immagini di macchine virtuali usate per l'accesso SRE controllato all'ambiente.

Componenti

Di seguito sono elencati i componenti principali usati in questa architettura. Se non si ha familiarità con questi servizi, consultare la sezione Servizi di Azure correlati per i collegamenti alla documentazione del prodotto.

Firewall di Azure

L'istanza del firewall protegge il traffico di rete in uscita. Senza questo livello di sicurezza, il flusso potrebbe comunicare con un servizio di terze parti dannoso che potrebbe esfiltrare dati aziendali sensibili.

Azure Bastion

L'architettura di base ha fornito una subnet per Azure Bastion, ma non ha effettuato il provisioning della risorsa. Questa architettura aggiunge Azure Bastion nella subnet e fornisce accesso sicuro a una jump box.

Azure Image Builder

Con provisioning in una rete virtuale separata, vengono create immagini delle VM con sicurezza e configurazione di base. In questa architettura, viene personalizzata per creare immagini di nodi sicure con strumenti di gestione come l'interfaccia della riga di comando di Azure, kubectle l'interfaccia della riga di comando di Flux preinstallata.

Set di scalabilità di macchine virtuali di Azure per le istanze jump box

La rete spoke include risorse di ambiente di calcolo aggiuntive per un jump box. Questo set di scalabilità deve essere il punto di accesso regolamentato per eseguire gli strumenti nel cluster di AKS, ad esempio kubectl, in base alle esigenze.

Gateway applicazione di Azure con Web Application Firewall (WAF) integrato

Il Gateway applicazione di Azure bilancia il carico di livello 7. WAF protegge il traffico in entrata dagli attacchi comuni al traffico Web. L'istanza ha una configurazione IP front-end pubblica che riceve le richieste utente.

Servizio Azure Kubernetes (AKS)

L'infrastruttura di hosting, che è una parte fondamentale dell'ambiente dei dati dei titolari di carte (CDE). Il cluster AKS viene distribuito come cluster privato. Pertanto, il server API Kubernetes non è esposto alla rete Internet pubblica e il traffico verso il server API è limitato alla rete privata.

Attività del Registro Azure Container

Fornisce un modo automatizzato per compilare e gestire le immagini del contenitore.

Azure Key Vault

Archivia e gestisce i segreti necessari per le operazioni del cluster, ad esempio certificati e chiavi di crittografia.

Configurazione del cluster

Ecco alcune modifiche significative dall'architettura di base:

Segmentazione del pool di nodi

In questa architettura, il cluster ha due pool di nodi utente e un pool di nodi di sistema. La scelta dell'ambiente di calcolo per i pool di nodi rimane invariata nell'architettura di base. A differenza dell'architettura di base, ogni pool di nodi si trova in una subnet dedicata per fornire un limite di isolamento di rete aggiunto tra i livelli di calcolo.

PCI-DSS 3.2.1 richiede l'isolamento del carico di lavoro PCI da altri carichi di lavoro in termini di operazioni e connettività.

• Ambito: carico di lavoro PCI, ambiente in cui risiede e operazioni.

• Fuori ambito: altri carichi di lavoro che potrebbero condividere i servizi, ma sono isolati dai componenti nell'ambito.

La strategia chiave consiste nel fornire il livello necessario di separazione. Il modo preferito consiste nel distribuire componenti nell'ambito e fuori ambito in cluster separati. Lo svantaggio dell'uso di più cluster è costituito dai costi più elevati per l'infrastruttura aggiunta e il sovraccarico di manutenzione. Questa implementazione consente di individuare tutti i componenti in un cluster condiviso per semplicità. Se si sceglie di seguire il modello a cluster singolo, usare una rigorosa strategia di segmentazione in cluster. Indipendentemente dal modo in cui si sceglie di mantenere la separazione, tenere presente che, man mano che la soluzione evolve, alcuni componenti esterni all'ambito potrebbero diventare inclusi nell'ambito.

Nell'implementazione di riferimento viene illustrato l'approccio del cluster condiviso distribuendo un'applicazione di microservizi in un singolo cluster. I carichi di lavoro nell'ambito e fuori ambito sono segmentati in due pool di nodi utente separati. L'applicazione ha due set di servizi; un set ha pod nell'ambito e l'altro è fuori ambito. Entrambi i set vengono distribuiti in due pool di nodi utente. Usando i contenitori Kubernetes, l'ambito e i pod out-of-scope vengono distribuiti in nodi separati e non condividono mai una macchina virtuale del nodo o lo spazio IP di rete.

Controller di ingresso

Architettura di base usata da Traefik per il controllo in ingresso. In questa architettura di riferimento si usa invece Nginx. Questa modifica illustra che questo componente può essere modificato in base ai requisiti dei carichi di lavoro.

Server API Kubernetes privato

L'architettura di base ha distribuito il cluster del servizio Azure Kubernetes in modalità pubblica. Ciò significa che tutte le comunicazioni con il server API Kubernetes gestito dal servizio Azure Kubernetes si trova su Internet pubblico. Questa architettura non è accettabile perché PCI-DSS 3.2.1 impedisce l'esposizione pubblica a tutti i componenti di sistema. In questa architettura regolamentata il cluster viene distribuito come cluster privato. Il traffico di rete verso il server API Kubernetes è limitato alla rete privata. Il server API viene esposto tramite un endpoint privato nella rete del cluster. La sicurezza è ulteriormente migliorata con l'uso di gruppi di sicurezza di rete e altre funzionalità predefinite. Questi sono descritti in Configurazione di rete.

Sicurezza dei pod

Quando si descrivono le esigenze di sicurezza del carico di lavoro, usare le impostazioni pertinenti securityContext per i contenitori. Sono incluse le impostazioni di base, ad esempio fsGroup, runAsUser / runAsGroup, e l'impostazione allowPrivilegeEscalation su false (a meno che non sia necessario). È chiaro come definire e rimuovere le funzionalità di Linux e definire le opzioni SELinux in seLinuxOptions.

Evitare di fare riferimento alle immagini in base ai tag nei manifesti della distribuzione. Usare invece l'ID immagine effettivo. In questo modo, è possibile eseguire il mapping affidabile dei risultati dell'analisi dei contenitori con il contenuto effettivo in esecuzione nel cluster. È possibile applicarlo tramite Criteri di Azure per il nome dell'immagine in modo da includere il modello di ID immagine nell'espressione regolare consentita. Seguire anche queste indicazioni quando si usa l'istruzione Dockerfile FROM .

Configurazione della rete

Gli hub-spoke vengono distribuiti in reti virtuali separate, ognuna nello spazio indirizzi privato. Per impostazione predefinita, non è consentito traffico tra due reti virtuali qualsiasi. All'interno della rete, la segmentazione viene applicata creando subnet.

Una combinazione di vari servizi e funzionalità di Azure e costrutti Kubernetes nativi fornisce il livello di controllo richiesto. Ecco alcune opzioni usate in questa architettura.

Sicurezza della subnet tramite gruppi di sicurezza di rete (NSG)

Esistono diversi gruppi di sicurezza di rete che controllano il flusso all'interno e all'esterno del cluster. Di seguito sono riportati alcuni esempi.

• I pool di nodi del cluster vengono posizionati in subnet dedicate. Per ogni subnet sono presenti gruppi di sicurezza di rete che bloccano qualsiasi accesso SSH alle macchine virtuali del nodo e consentono il traffico dalla rete virtuale. Il traffico dai pool di nodi è limitato alla rete virtuale.

• Tutto il traffico in ingresso da Internet viene intercettato da Gateway applicazione di Azure. Ad esempio, le regole NSG assicurano che:

  • Solo il traffico HTTPS è consentito.
  • Il traffico dal piano di controllo di Azure è consentito usando i tag di servizio. Per maggiori informazioni, consultare la sezione Consentire l'accesso ad alcuni indirizzi IP di origine.

• Nelle subnet con agenti Registro contenitori di Azure, i gruppi di sicurezza di rete consentono solo il traffico in uscita necessario. Ad esempio, il traffico è consentito ad Azure Key Vault, Microsoft Entra ID, Monitoraggio di Azure e altri servizi a cui deve comunicare il registro contenitori.

• La subnet con il jump box è destinata alle operazioni di gestione. La NSG nella subnet jump box consente solo l'accesso SSH da Azure Bastion nell'hub e connessioni in uscita limitate. I jumpbox non dispongono dell'accesso a Internet universale e sono controllati sia nella NSG della subnet che in Firewall di Azure.

Man mano che vengono distribuiti i carichi di lavoro, gli agenti di sicurezza del sistema e altri componenti, aggiungere altre regole di NSG che consentono di definire il tipo di traffico che deve essere consentito. Il traffico non deve attraversare i limiti della subnet. Poiché ogni pool di nodi si trova nella propria subnet, osservare i modelli di traffico e quindi applicare regole più specifiche.

Sicurezza da pod a pod con criteri di rete

Questa architettura tenta di implementare i principi "zero trust" di Microsoft il più possibile.

Esempi di reti zero trust come concetto sono illustrati nell'implementazione, all'interno degli spazi dei nomi forniti dall'utente a0005-i e a0005-o. A ogni spazio dei nomi del carico di lavoro deve essere applicato un oggetto NetworkPolicy restrittivo. Le definizioni dei criteri dipendono dai pod in esecuzione in tali spazi dei nomi. Assicurarsi di essere responsabili della conformità, della vivacità e dei probe di avvio e di consentire le metriche raccolte dall'agente di Analisi dei log. Valutare la possibilità di standardizzare le porte tra i carichi di lavoro in modo da poter fornire un NetworkPolicy coerente e Criteri di Azure per le porte contenitore consentite.

In alcuni casi, questo non è pratico per la comunicazione all'interno del cluster. Non tutti gli spazi dei nomi forniti dall'utente possono usare una rete senza attendibilità ( ad esempio, cluster-baseline-settings non può usarne una).

Crittografia TLS

L'architettura di base fornisce traffico crittografato TLS fino al controller di ingresso nel cluster, ma la comunicazione da pod a pod non è chiara. In questa architettura TLS si estende al traffico da pod a pod, con convalida dell'autorità di certificazione (CA). Tale protocollo TLS viene fornito da una mesh di servizi, che applica le connessioni mTLS e la verifica prima di consentire la comunicazione.

L'implementazione usa mTLS. Il supporto mTLS può essere implementato con o senza una mesh di servizi. Se si usa una mesh, assicurarsi che sia compatibile con l'autorità di certificazione di propria scelta. Questa implementazione usa Open Service Mesh.

Il controller di ingresso in questa implementazione usa un certificato con caratteri jolly per gestire il traffico predefinito quando una risorsa di ingresso non contiene un certificato specifico. Potrebbe essere accettabile, ma se i criteri dell'organizzazione non consentono l'uso di certificati con caratteri jolly, potrebbe essere necessario modificare il controller di ingresso in modo da non usare un certificato con caratteri jolly.

Restrizioni di rete di Azure Key Vault

Tutti i segreti, le chiavi e i certificati vengono archiviati in Azure Key Vault. Key Vault gestisce le attività di gestione dei certificati, ad esempio la rotazione. La comunicazione con Key Vault è collegamento privato di Azure. Il record DNS associato a Key Vault si trova in una zona DNS privato in modo che non possa essere risolto da Internet. Anche se questo migliora la sicurezza, esistono alcune restrizioni.

Gateway applicazione di Azure non supporta l'origine di certificati TLS per il listener HTTP dalle istanze di Key Vault esposte con collegamento privato. L'implementazione distribuisce quindi Key Vault in un modello ibrido. Usa ancora collegamento privato per le connessioni che lo supportano, ma consente anche l'accesso pubblico per l'integrazione gateway applicazione. Se questo approccio ibrido non è adatto per la distribuzione, spostare il processo di gestione dei certificati in gateway applicazione. In questo modo, si aggiungerà un sovraccarico di gestione, ma l'istanza di Key Vault sarà completamente isolata. Per informazioni, vedere:

• Integrazione del Gateway applicazione di Azure e dell'insieme di credenziali delle chiavi
• Creare un gateway applicazione con la terminazione TLS tramite l'interfaccia della riga di comando di Azure.

Protezione DDoS

Se sono presenti reti virtuali con indirizzi IP pubblici, abilitare Protezione di rete DDos di Azure. In questa architettura di riferimento, la subnet che contiene gateway applicazione ha un indirizzo IP pubblico collegato, quindi è nell'ambito della protezione DDoS.

Protezione di rete DDoS di Azure protegge l'infrastruttura e il carico di lavoro da richieste fraudolente di massa. Tali richieste possono causare interruzioni del servizio o mascherare un altro attacco simultaneo. Protezione di rete DDoS di Azure comporta un costo significativo e viene in genere ammortizzato in molti carichi di lavoro che si estendono su molti indirizzi IP. Collaborare con il team di rete per coordinare la copertura per i carichi di lavoro.

Gestione delle identità e dell'accesso

Definire i ruoli e impostare il controllo di accesso in base ai requisiti del ruolo. Eseguire il mapping dei ruoli alle azioni Kubernetes con un ambito limitato come pratico. Evitare ruoli che si estendono su funzioni multiple. Se più ruoli vengono compilati da una sola persona, assegnare a tale persona tutti i ruoli rilevanti per le funzioni di lavoro equivalenti. Pertanto, anche se una persona è direttamente responsabile sia del cluster che del carico di lavoro, creare gli oggetti Kubernetes ClusterRolecome se fossero presenti individui separati. Assegnare quindi tale singolo ruolo pertinente.

Ridurre al minimo l'accesso permanente, in particolare per gli account ad alto impatto, ad esempio le interazioni SRE/Ops con il cluster. Il piano di controllo del servizio Azure Kubernetes supporta sia Microsoft Entra ID Privileged Access Management (PAM) just-in-time (JIT) che criteri di accesso condizionale, che fornisce un livello aggiuntivo di convalida dell'autenticazione necessaria per l'accesso con privilegi, in base alle regole compilate.

Per maggiori informazioni sull'uso di PowerShell per configurare l'accesso condizionale, vedere New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy e Remove-MgIdentityConditionalAccessPolicy.

Crittografia del disco

Quando si progetta la crittografia per i dati inattivi, prendere in considerazione dischi di archiviazione, macchine virtuali del nodo dell'agente di AKS, altre macchine virtuali ed eventuali dischi temporanei e del sistema operativo.

Dischi di archiviazione

Per impostazione predefinita, i dischi di Archiviazione di Azure vengono crittografati inattivi con chiavi gestite da Microsoft. Se si usano dischi del sistema operativo non temporanei o si aggiungono dischi dati, è consigliabile usare chiavi gestite dal cliente per controllare le chiavi di crittografia. Crittografare all'esterno del livello di archiviazione e scrivere solo dati crittografati nel supporto di archiviazione. Assicurarsi inoltre che le chiavi non siano mai adiacenti al livello di archiviazione. Per maggiori informazioni, consultare la sezione Usare le chiavi personali (BYOK) con i dischi di Azure.

Prendere in considerazione l'uso di BYOK per tutti gli altri dischi che potrebbero interagire con il cluster, ad esempio i jump box front-in Azure Bastion. Se si sceglie BYOK, la scelta dello SKU per le macchine virtuali e la disponibilità a livello di area saranno limitate perché questa funzionalità non è supportata in tutti gli SKU o in tutte le aree.

Host di VM

È consigliabile abilitare la funzionalità encryption-at-host. Verrà crittografato l'host della macchina virtuale e qualsiasi sistema operativo temporaneo o dischi dati memorizzati nella cache in un host di VM. Maggiori informazioni sul supporto delle VM per la crittografia basata su host.

Questa funzionalità viene estesa ai dati archiviati nell'host di macchine virtuali dei nodi dell'agente del servizio Azure Kubernetes tramite la funzionalità Crittografia basata su host. Analogamente a BYOK, questa funzionalità potrebbe limitare le scelte relative allo SKU e all'area della VM.

È possibile applicare queste funzioni tramite Criteri di Azure.

Backup del cluster (stato e risorse)

Se il carico di lavoro richiede l'archiviazione in cluster, è disponibile un processo affidabile e sicuro per il backup e il ripristino. Prendere in considerazione servizi come Backup di Azure (per Dischi di Azure e File di Azure), per il backup e il ripristino di qualsiasi PersistentVolumeClaim. Il sistema di backup supporta le risorse Kubernetes native. È possibile integrare il metodo principale che riconcilia il cluster con uno stato noto, con il sistema di backup per tecniche critiche di ripristino del sistema. Ad esempio, può essere utile per rilevare e catalogare le modifiche dello stato del sistema nel tempo a livello di risorsa Kubernetes.

I processi di backup devono classificare i dati nel backup, indipendentemente dal fatto che tali dati provenissero dal cluster o siano esterni al cluster. Se i dati rientrano nell'ambito di PCI DSS 3.2.1, estendere i limiti di conformità per includere il ciclo di vita e la destinazione del backup, che si troverà all'esterno del cluster. I backup possono essere un vettore di attacco. Quando si progetta il backup, prendere in considerazione restrizioni geografiche, crittografia dei dati inattivi, controlli di accesso, ruoli e responsabilità, controllo, durata e prevenzione della manomissione.

I sistemi di backup in cluster devono essere eseguiti con privilegi elevati durante le operazioni. Valutare il rischio e il vantaggio di portare un agente di backup nel cluster. La funzionalità dell'agente si sovrappone a un'altra soluzione di gestione nel cluster? Qual è il set minimo di strumenti necessari per eseguire questa attività senza espandere la superficie di attacco?

Considerazioni sui criteri di Azure

In genere, i criteri di Azure applicati non hanno impostazioni ottimizzate per il carico di lavoro. Nell'implementazione si applicano gli standard di sicurezza dei pod del cluster Kubernetes per l'iniziativa basata su Linux, che è una delle iniziative di criteri predefinite. Questa iniziativa non consente l'ottimizzazione delle impostazioni. Valutare la possibilità di esportare questa iniziativa e personalizzarne i valori per il carico di lavoro specifico. È possibile includere tutti i criteri di Azure Gatekeeper deny in un'iniziativa personalizzata e tutti i audit criteri di Azure in un'altra iniziativa. In questo modo si classificano le azioni di blocco dai criteri di sola informazione.

Prendere in considerazione l'inclusione degli kube-system spazi dei nomi e gatekeeper-system ai criteri nei criteri di controllo per ottenere maggiore visibilità. L'inclusione di tali spazi dei nomi nei criteri di rifiuto potrebbe causare un errore del cluster a causa di una configurazione non supportata.

È possibile applicare la crittografia dei dati impostando alcuni avvisi Criteri di Azure. Ad esempio, è possibile applicare BYOK con un avviso che rileva i cluster che non dispongono diskEncryptionSetID della risorsa cluster. Un altro criterio può rilevare se la crittografia basata su host è abilitata in agentPoolProfiles. L'implementazione di riferimento non usa dischi nel cluster e il disco del sistema operativo è temporaneo. Entrambi questi criteri di esempio vengono applicati come promemoria della funzionalità di sicurezza. I criteri sono impostati su audit, non su block.

Gestione delle immagini

Usare immagini di base senza distribuzione per i carichi di lavoro. Con queste immagini, l'area di attacco di sicurezza è ridotta a icona perché vengono rimosse immagini supplementari, ad esempio shell e gestori pacchetti. Un vantaggio è la riduzione dei tassi di successo CVE.

Registro contenitori di Azure supporta immagini che soddisfano la Specifica del formato immagine OCI (Open Container Initiative). In questo modo, abbinato a un controller di ammissione che supporta la convalida delle firme, è possibile assicurarsi di eseguire solo immagini firmate con le chiavi private. Esistono soluzioni open source come SSE Connaisseur o IBM Portieris che integrano tali processi.

Proteggere le immagini del contenitore e altri artefatti OCI perché contengono la proprietà intellettuale dell'organizzazione. Utilizzare le chiavi gestite dal cliente e crittografare il contenuto dei registri. Per impostazione predefinita, i dati inattivi sono crittografati tramite chiavi gestite dal servizio, ma talvolta sono richieste chiavi gestite dal cliente per soddisfare gli standard di conformità alle normative. Archiviare la chiave in un archivio chiavi gestito, ad esempio Azure Key Vault. Poiché si crea e si è proprietari della chiave, si è responsabili delle operazioni correlate al ciclo di vita delle chiavi, inclusa la rotazione e la gestione. Per maggiori informazioni, consultare la sezione Crittografare il Registro di sistema usando una chiave gestita dal cliente.

Accesso operativo al server API Kubernetes

È possibile limitare i comandi eseguiti nel cluster, senza necessariamente creare un processo operativo basato sui jumpbox. Se si dispone di una piattaforma di automazione IT controllata da IAM, usare le azioni predefinite per controllare e controllare il tipo di azioni.

Agenti di compilazione

Gli agenti della pipeline devono essere fuori ambito per il cluster regolamentato perché i processi di compilazione possono essere vettori di minaccia. Ad esempio, i processi di compilazione spesso funzionano con componenti non verificati e non attendibili.

Anche se è comune usare Kubernetes come infrastruttura dell'agente di compilazione elastico, non eseguire tale processo entro il limite del runtime del carico di lavoro regolamentato. Gli agenti di compilazione non devono avere accesso diretto al cluster. Ad esempio, concedere solo agli agenti di compilazione l'accesso alla rete per Registro contenitori di Azure per eseguire il push di immagini del contenitore, grafici Helm e così via. Distribuire quindi tramite GitOps. Come pratica comune, i flussi di lavoro di compilazione e rilascio non devono avere accesso diretto all'API del cluster Kubernetes (o ai relativi nodi).

Monitoraggio delle operazioni

Attività nel cluster

I pod nel cluster omsagent in esecuzione in kube-system sono l'agente di raccolta di Analisi dei log. Raccolgono dati di telemetria, eliminano i log e i contenitori stdout e stderr, e raccolgono le metriche di Prometheus. È possibile ottimizzare le impostazioni della raccolta aggiornando il container-azm-ms-agentconfig.yaml file ConfigMap. In questa implementazione di riferimento la registrazione è abilitata in kube-system tutti i carichi di lavoro. Per impostazione predefinita, kube-system è escluso dalla registrazione. Assicurarsi di modificare il processo di raccolta dei log per raggiungere gli obiettivi di costo di equilibrio, l'efficienza SRE quando si esaminano i log e le esigenze di conformità.

Monitoraggio della sicurezza

Usare Defender per contenitori in Microsoft Defender per il cloud per visualizzare e correggere le raccomandazioni di sicurezza e visualizzare gli avvisi di sicurezza sulle risorse del contenitore. Abilitare i piani di Microsoft Defender quando si applicano a vari componenti dell'ambiente dati dei titolari di carte.

Integrare i log in modo da poter esaminare, analizzare ed eseguire query sui dati in modo efficiente. Azure offre diverse opzioni. È possibile attivare i log di diagnostica del servizio Azure Kubernetes e inviarli a un'area di lavoro Analisi dei log che fa parte di Monitoraggio di Azure. Un'altra opzione consiste nell'integrare i dati nelle soluzioni di gestione delle informazioni e degli eventi di sicurezza (SIEM), ad esempio Microsoft Sentinel.

Come richiesto dallo standard, tutte le aree di lavoro Analisi dei log vengono impostate su un periodo di conservazione di 90 giorni. Valutare la possibilità di configurare l'esportazione continua per l'archiviazione a lungo termine. Non archiviare informazioni riservate nei dati di log e assicurarsi che l'accesso ai dati di log archiviati sia soggetto agli stessi livelli di controlli di accesso dei dati di log recenti.

Per una prospettiva completa, consultare la guida all'onboarding aziendale Microsoft Defender per il cloud Guida. Questa guida illustra la registrazione, le esportazioni di dati nelle soluzioni SIEM, la risposta agli avvisi e la creazione dell'automazione del flusso di lavoro.

Servizi Azure correlati

Di seguito i collegamenti alla documentazione delle funzionalità di alcuni componenti chiave di questa architettura.

• Servizio Azure Kubernetes (AKS)
• Firewall di Azure
• Azure Bastion
• Azure Image Builder
• Set di scalabilità di macchine virtuali di Azure
• Gateway applicazione di Azure con Web Application Firewall (WAF) integrato
• Attività del Registro Azure Container
• Azure Key Vault

Passaggi successivi

Installare e gestire una configurazione del firewall per proteggere i dati dei titolari delle carte di credito. Non usare i valori predefiniti del fornitore per le password del sistema e altri parametri di sicurezza.