Sicurezza di rete per un cluster regolamentato AKS per PCI DSS 4.0.1

Questo articolo descrive le considerazioni relative alla rete per un cluster di Azure Kubernetes Service (AKS) configurato in conformità con il Payment Card Industry Data Security Standard (PCI DSS 4.0.1).

Questo articolo fa parte di una serie. Leggi introduzione.

Il tema principale dello standard PCI DSS 4.0.1 è la sicurezza, con requisiti estesi per la segmentazione di rete, la definizione dell'ambito basato sui rischi e il monitoraggio continuo. La topologia hub-spoke è una scelta naturale per configurare un ambiente di rete regolamentato. È più semplice creare un'infrastruttura che consenta comunicazioni sicure. I controlli di rete vengono posizionati in entrambe le reti hub-spoke e seguono il modello Microsoft zero-trust. I controlli possono essere ottimizzati con privilegi minimi per proteggere il traffico, concedendo l'accesso in base alle esigenze. Inoltre, è possibile applicare diversi approcci di difesa avanzata aggiungendo controlli a ogni hop e livello di rete.

Quando si ospita un carico di lavoro in Kubernetes, non è sufficiente basarsi su costrutti di rete tradizionali, ad esempio le regole del firewall. PCI DSS 4.0.1 enfatizza l'uso di controlli nativi del cloud e Kubernetes per la segmentazione e la comunicazione sicura. Esistono anche costrutti nativi di Kubernetes che controllano il flusso del traffico all'interno del cluster, ad esempio la risorsa NetworkPolicy. È consigliabile fare riferimento alla documentazione di Kubernetes per comprendere i concetti di base relativi ai pod isolati e ai criteri in ingresso e in uscita.

Importante

Le linee guida e l'implementazione associata si basano sull'architettura di base del servizio Azure Kubernetes, basata su una topologia di rete 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 la manutenzione. La rete virtuale spoke contiene il cluster del servizio Azure Kubernetes che fornisce l'ambiente CDE (Card-Holder Environment) e ospita il carico di lavoro PCI DSS.

Implementazione di riferimento presto disponibile: il cluster di riferimento del servizio Azure Kubernetes per carichi di lavoro regolamentati secondo PCI DSS 4.0.1 è attualmente in fase di aggiornamento e sarà presto disponibile. Questa implementazione illustra un'infrastruttura regolamentata che illustra l'uso di vari controlli di rete e sicurezza all'interno dell'ambiente cde. Sono inclusi entrambi i controlli di rete nativi di Azure e i controlli nativi di Kubernetes. Includerà anche un'applicazione per illustrare le interazioni tra l'ambiente e un carico di lavoro di esempio. Il punto focale del presente articolo è l'infrastruttura. L'esempio non sarà indicativo di un carico di lavoro effettivo PCI-DSS 4.0.1.

Creare e mantenere una rete e sistemi sicuri

Requisito 1: Installare e gestire una configurazione del firewall per proteggere i dati dei titolari di carte

Supporto per le funzionalità del servizio Azure Kubernetes

AKS supporta la distribuzione di un cluster in una rete virtuale privata come cluster privato. La comunicazione tra il cluster e il server API Kubernetes gestito da AKS si trova in una rete attendibile. Con un cluster privato è possibile usare Azure Rete virtuale, gruppo di sicurezza di rete (NSG) e altri controlli di rete predefiniti per proteggere l'intero ambiente di dati dei titolari di carte (CDE). Questa configurazione impedisce l'accesso pubblico non autorizzato tra Internet e l'ambiente. Per informazioni dettagliate su come effettuare il provisioning di un cluster di questo tipo, vedere la sezione Creare un cluster di servizio Azure Kubernetes privato.

È possibile integrare Azure Firewall con AKS e limitare il traffico in uscita dal cluster, che rappresenta un componente chiave del CDE. La configurazione è semplificata con un tag FQDN AKS. Il processo consigliato è disponibile in Usare Firewall di Azure per proteggere le distribuzioni del servizio Azure Kubernetes.

I cluster di AKS richiedono un accesso a Internet pubblico. Limitare il traffico in uscita a Internet usando Firewall di Azure e NSG nella subnet del cluster. Per informazioni, vedere Controllare il traffico in uscita per i nodi del cluster nel servizio Azure Kubernetes.

AKS supporta facoltativamente la possibilità di definire un proxy HTTP, che è possibile utilizzare per il controllo e il monitoraggio aggiuntivi del traffico in uscita per il cluster. I nodi del cluster usano la configurazione del proxy HTTP specificata per il routing del traffico in uscita. Inoltre, un oggetto MutatingWebhook viene registrato per inserire le informazioni proxy nei pod in fase di creazione, quindi è consigliabile che i carichi di lavoro possano ereditare le stesse informazioni proxy. I pod possono eseguire l'override delle informazioni proxy, quindi è consigliabile usare un proxy HTTP oltre a un firewall di Azure.

I cluster AS devono essere creati con il plug-in NetworkPolicy. In servizio Azure Kubernetes, sono disponibili diverse opzioni per il plug-in Criteri di rete, tra cui Calico, Gestione dei criteri di rete di Azure e Cilium. Con i criteri di rete Calico è possibile usare Kubenet o Azure CNI. Per Gestione dei criteri di rete di Azure, è possibile usare solo Azure CNI (non Kubenet). Entrambi i plug-in Criteri di rete di Azure e Calico sono open source. Per altre informazioni su Project Calico, vedere il white paper completo sulla soluzione PCI, che soddisfa molti dei requisiti del firewall descritti in PCI DSS 4.0.1.

PCI DSS 4.0.1 espande i requisiti per la segmentazione di rete, la convalida basata sui rischi dell'ambito e la revisione continua delle configurazioni del firewall e del router. Usare strumenti di sicurezza di rete nativi del cloud, ad esempio reti virtuali, gruppi di sicurezza e micro-segmentazione. Assicurati che i carichi di lavoro containerizzati usufruiscano del corretto isolamento dello spazio dei nomi e dei protocolli di comunicazione sicuri. Incorporare la difesa a più livelli usando i criteri di rete Kubernetes o strumenti simili negli ambienti contenitore.

Responsabilità dell'utente

Requisito	Responsabilità
Requisito 1.1	Stabilire e implementare standard di configurazione firewall e router, inclusa la convalida basata sul rischio dell'ambito e la revisione regolare.
Requisito 1.2	Creare configurazioni di firewall e router che limitano le connessioni tra reti non attendibili e qualsiasi componente di sistema nell'ambiente dei dati del titolare carta.
Requisito 1.3	Proibire l'accesso pubblico diretto tra Internet e qualsiasi componente di sistema nell'ambiente dei dati di titolari di carte.
Requisito 1.4	Installare software firewall personale o funzionalità equivalenti in qualsiasi dispositivo portatile (sia di proprietà dell'azienda che dei dipendenti) che si connette a Internet all'esterno della rete (ad esempio, i computer portatili usati dai dipendenti), e che viene usato anche per accedere all'ambiente dei dati di titolari di carte.
Requisito 1.5	Assicurarsi che i criteri di sicurezza e le procedure operative per la gestione dei firewall siano documentati, applicati e noti a tutte le parti interessate.

Requisito 1.1

Stabilire e implementare standard di configurazione del firewall e del router che includono quanto segue:

Requisito 1.1.1

Processo formale per l'approvazione e il test di tutte le connessioni di rete e delle modifiche apportate alle configurazioni di firewall e router.

Responsabilità dell'utente

Non implementare manualmente le configurazioni, ad esempio usando direttamente il portale di Azure o l'interfaccia della riga di comando di Azure. È consigliabile usare Infrastructure as Code (IaC). Con IaC, l'infrastruttura viene gestita attraverso un modello descrittivo che utilizza un sistema di controllo delle versioni. Il modello IaC genera lo stesso ambiente ogni volta che viene applicato. Esempi comuni di IaC sono Bicep, modelli di Azure Resource Manager (modelli ARM) o Terraform. Se IaC non è un'opzione, è disponibile un processo ben documentato per tenere traccia, implementare e distribuire in modo sicuro le modifiche delle regole del firewall. Maggiori dettagli sono disponibili nel Requisito 11.2.

È necessario usare una combinazione di vari controlli di rete, tra cui Firewall di Azure, gruppi di sicurezza di rete (NSG) e la risorsa KubernetesNetworkPolicy.

Ridurre al minimo il numero di persone che possono accedere e modificare i controlli di rete. Definire i ruoli e chiarisci le responsabilità ai team. Ad esempio, il team di rete di un'organizzazione convaliderà le modifiche in base ai criteri di governance impostati dai team IT. Disporre di un processo di approvazione controllata che coinvolge persone e processi per approvare le modifiche a qualsiasi configurazione di rete. Il processo deve includere un passaggio per testare tutti i controlli di rete. Avere una documentazione dettagliata che descrive il processo.

Requisito 1.1.2

Diagramma di rete corrente che identifica tutte le connessioni tra l'ambiente dei dati del titolare carta e le altre reti, incluse eventuali reti wireless

Responsabilità dell'utente

Come parte della documentazione, gestire un diagramma di flusso di rete che mostra il traffico in ingresso e in uscita con i controlli di sicurezza. Ciò include il flusso di traffico da altre reti, tra cui qualsiasi rete wireless verso la rete CDE. Il diagramma dovrebbe anche mostrare i flussi all'interno del cluster. Esistono alcuni requisiti specifici per i diagrammi, tra cui che devono mostrare sensori di intrusione e tutti i controlli applicati.

L'immagine seguente mostra il diagramma di rete dell'implementazione di riferimento:

Scaricare un file di Visio di questo diagramma.

Figura 1.1.2 - Flusso di rete

La descrizione di questo flusso è descritta nelle sezioni seguenti.

Se si dispone di Azure Network Watcher, è possibile visualizzare la topologia di una rete virtuale di Azure. È possibile visualizzare tutte le risorse presenti in una rete virtuale, le risorse associate a tali risorse e le relazioni tra di esse.

Requisito 1.1.3

Diagramma corrente che mostra tutti i flussi di dati del titolare carta tra sistemi e reti.

Responsabilità dell'utente

Come parte della documentazione, includere un diagramma del flusso di dati che mostra come i dati sono protetti inattivi e in transito.

Il diagramma dovrebbe mostrare in che modo i dati passano da e verso il carico di lavoro e quali informazioni vengono passate da una risorsa a un'altra. Assicurarsi che il diagramma sia mantenuto aggiornato. Aggiungere un passaggio per aggiornare il diagramma del flusso di dati come parte del processo di gestione delle modifiche.

Poiché questa architettura è incentrata sull'infrastruttura e non sul carico di lavoro, qui sono state omesse illustrazioni.

Requisito 1.1.4

Requisiti per un firewall in ogni connessione Internet e tra qualsiasi zona demilitarizzata (DMZ) e la zona di rete interna.

Responsabilità dell'utente

Avere una definizione chiara di ciò che definisce il limite di una rete perimetrale. Ad esempio, l'ambiente dei dati dei titolari di carte (CDE) potrebbe trovarsi all'interno di una rete perimetrale protetta da firewall, criteri di rete e altri controlli. Per altre informazioni, vedere Rete perimetrale cloud.

Per un'infrastruttura PCI DSS, l'utente è responsabile della protezione dell'ambiente CDE usando i controlli di rete per bloccare l'accesso non autorizzato all'interno e all'esterno della rete che contiene la rete CDE. I controlli di rete devono essere configurati correttamente per un comportamento di sicurezza sicuro e devono essere applicati a:

• Comunicazione tra i componenti con percorso condiviso all'interno del cluster.
• Comunicazione tra il carico di lavoro e altri componenti in reti attendibili.
• Comunicazione tra il carico di lavoro e Internet pubblico.

Questa architettura usa tecnologie firewall diverse per controllare il flusso del traffico da e verso il cluster che ospita la rete CDE:

• Il Gateway delle applicazioni di Azure per contenitori funge da router del traffico e il web application firewall integrato (WAF) protegge il traffico in ingresso verso il cluster.

• Firewall di Azure protegge tutto il traffico in uscita (in uscita) da qualsiasi rete e dalle relative subnet.

  Nell'ambito dell'elaborazione di una transazione o di operazioni di gestione, il cluster dovrà comunicare con gli endpoint esterni. Ad esempio, il cluster potrebbe richiedere la comunicazione con il piano di controllo di AKS, la comunicazione con il sistema operativo e i sistemi di aggiornamento dei pacchetti e molti carichi di lavoro interagiscono con le API esterne. Alcune di queste interazioni potrebbero essere su HTTP e devono essere considerate come vettori di attacco. Questi vettori sono obiettivi per un attacco man-in-the-middle che può causare l'esfiltrazione di dati. L'aggiunta di un firewall al traffico in uscita riduce tale minaccia.

  È consigliabile che anche la comunicazione da pod a pod sia crittografata con TLS. Questa procedura viene illustrata nell'implementazione di riferimento con l'uso dell'autenticazione reciproca TLS (mTLS).

• I gruppi di sicurezza di rete proteggono il traffico tra il cluster e altri componenti all'interno dell'infrastruttura. Nell'implementazione di riferimento, ad esempio, nella subnet sono presenti gruppi di sicurezza di rete con pool di nodi che bloccano eventuali tentativi di accesso SSH. Solo il traffico dall'interno della rete virtuale è consentito.

  Quando si aggiungono componenti all'architettura, è consigliabile aggiungere altri gruppi di sicurezza di rete che consentono o negano i tipi di traffico ai limiti della subnet. Poiché ogni pool di nodi si trova in una subnet dedicata, applicare regole più specifiche in base ai modelli di traffico previsti del carico di lavoro.

• Gli oggetti Kubernetes NetworkPolicy vengono usati per controllare le comunicazioni nel cluster.

  Per impostazione predefinita, non esistono restrizioni per la comunicazione da pod a pod. È necessario applicare NetworkPolicy nelle comunicazioni nel cluster, a partire da una rete zero-trust e aprendo i percorsi in base alle esigenze. L'implementazione di riferimento illustra le reti zero-trust negli spazi dei nomi a0005-i e a0005-o. Tutti gli spazi dei nomi (ad eccezione di kube-system, gatekeeper-system e altri spazi dei nomi forniti dal servizio Azure Kubernetes) sono soggetti criteri di rete restrittivi. La definizione dei criteri dipende dai pod in esecuzione in tali spazi dei nomi. Assicurarsi di aprire percorsi per la preparazione, la vivacità e i probe di avvio. Inoltre, aprire il percorso a oms-agent in modo che sia possibile inviare le metriche a livello di nodo. Valutare la possibilità di standardizzare le porte tra i carichi di lavoro in modo che sia possibile fornire un NetworkPolicy coerente e Criteri di Azure per le porte del contenitore consentite.

Requisito 1.1.5

Descrizione di gruppi, ruoli e responsabilità per la gestione dei componenti di rete.

Responsabilità dell'utente

È necessario fornire controlli sui flussi di rete e sui componenti coinvolti. L'infrastruttura risultante avrà diversi segmenti di rete, ognuno con molti controlli e ogni controllo con uno scopo. Assicurarsi che la documentazione abbia un'ampia gamma di copertura, dalla pianificazione di rete a tutte le configurazioni applicate. Deve inoltre includere dettagli sulla proprietà, con linee chiare di responsabilità e i ruoli responsabili.

Ad esempio, sapere chi è responsabile della governance della protezione delle reti tra Azure e Internet. In un'azienda, il team IT è in genere responsabile della configurazione e della manutenzione delle regole di Firewall di Azure, delle regole Web application firewall (WAF), dei gruppi di sicurezza di rete e di altro traffico tra reti. Potrebbero anche essere responsabili dell'allocazione di subnet e della rete virtuale a livello aziendale e della pianificazione degli indirizzi IP.

A livello di carico di lavoro, un operatore del cluster è responsabile della gestione zero-trust tramite i criteri di rete. Inoltre, le responsabilità possono includere la comunicazione con il piano di controllo di Azure, le API Kubernetes e le tecnologie di monitoraggio.

Iniziare sempre con una strategia di negazione. Concedere l'autorizzazione solo quando è necessaria un'azienda o una giustificazione del ruolo.

Requisito 1.1.6

Documentazione delle motivazioni e approvazioni aziendali per l'uso di tutti i servizi, i protocolli e le porte consentiti, inclusa la documentazione delle funzionalità di sicurezza implementate per i protocolli considerati non sicuri.

Responsabilità dell'utente

Avere una documentazione dettagliata che descrive i servizi, i protocolli e le porte usati nei controlli di rete. Nega tutto tranne le porte consentite in modo esplicito. Documentare la motivazione aziendale e le funzionalità di sicurezza documentate se non è possibile evitare l'uso di protocolli non sicuri. Ecco alcuni esempi dell'implementazione di riferimento per Firewall di Azure. Le regole del firewall devono essere limitate esclusivamente alle risorse correlate. Ovvero, solo il traffico proveniente da origini specifiche può passare a destinazioni FQDN specifiche.

La tabella seguente elenca esempi in cui è possibile consentire il traffico:

Regola	Protocol:Port	Fonte	Destinazione	Giustificazione
Consentire la comunicazione sicura tra i nodi e il piano di controllo.	HTTPS:443	Intervalli di indirizzi IP autorizzati assegnati ai pool di nodi del cluster	Elenco di destinazioni FQDN nel piano di controllo di AKS. Viene specificato con il tag FQDN AzureKubernetesService.	I nodi devono accedere al piano di controllo per strumenti di gestione, informazioni sullo stato e sulla configurazione e informazioni su quali nodi possono essere ridimensionati.
Consentire la comunicazione sicura tra Flux e GitHub.	HTTPS:443	Pool di nodi AKS	github.com, api.github.com	Flux è un'integrazione di terze parti eseguita sui nodi. Sincronizza la configurazione del cluster con un repository GitHub privato.

Requisito 1.1.7

Requisito per esaminare i set di regole firewall e router almeno ogni sei mesi.

Responsabilità dell'utente

Disporre di processi almeno ogni sei mesi per esaminare le configurazioni di rete e le regole con ambito. Ciò garantisce che le garanzie di sicurezza siano correnti e valide. Assicurarsi di esaminare le configurazioni seguenti:

• Regole di Firewall di Azure.
• Regole del gruppo di sicurezza di rete.
• Gateway di applicazione Azure per containers e regole WAF.
• Criteri di rete di Kubernetes nativi.
• Controlli del firewall sulle risorse di Azure applicabili. Ad esempio, questa architettura usa una regola per Registro contenitori di Azure che consente solo il traffico da un endpoint privato.
• Tutti gli altri controlli di rete aggiunti all'architettura.

Se sono stati ritirati carichi di lavoro o sono stati modificati la configurazione del cluster dopo la revisione precedente, è importante verificare che eventuali presupposti effettuati sulle eccezioni del firewall necessarie o sulle regole del gruppo di sicurezza di rete siano ancora valide.

Requisito 1.2

Creare configurazioni di firewall e router che limitano le connessioni tra reti non attendibili e qualsiasi componente di sistema nell'ambiente dei dati del titolare carta.

Responsabilità dell'utente

In questa architettura, il cluster del servizio Azure Kubernetes è un componente chiave dell'ambiente di titolari di carte (CDE). È consigliabile distribuire il cluster come cluster privato per una maggiore sicurezza. In un cluster privato, il traffico di rete tra il server API Kubernetes gestito da AKS e i pool di nodi è privato. Il server API viene esposto tramite un endpoint privato nella rete del cluster.

È anche possibile scegliere un cluster pubblico, ma questa progettazione non è consigliata per i cluster contenenti carichi di lavoro regolamentati. Il server API verrà esposto a Internet e il record DNS sarà sempre individuabile, quindi è necessario disporre di controlli per mantenere l'API del cluster protetta dall'accesso pubblico. Se è necessario usare un cluster pubblico, l'approccio consigliato consiste nell'avere controlli rigorosi tramite i controlli degli accessi in base al ruolo (RBAC) di Kubernetes, associati alla funzionalità Intervalli IP autorizzati di AKS per limitare chi può accedere al server API AKS. Tuttavia, questa soluzione non è consigliata per i cluster contenenti carichi di lavoro regolamentati.

Durante l'elaborazione dei dati dei titolari di schede (CHD),il cluster deve interagire con le reti considerate attendibili e non attendibili. In questa architettura, entrambe le reti hub-spoke all'interno del perimetro del carico di lavoro PCI DSS 4.0.1 vengono considerate reti attendibili.

Le reti non attendibili sono reti esterne al perimetro. Le reti non attendibili includono:

• Gli altri hub e spoke che potrebbero trovarsi nella stessa infrastruttura, ma che si trovano all'esterno del perimetro del carico di lavoro.
• Internet pubblico.
• Rete aziendale.
• Altre reti virtuali in Azure o in un'altra piattaforma cloud.

In questa architettura, la rete virtuale che ospita il generatore di immagini non è attendibile perché non ha alcuna parte da svolgere nella gestione CHD. L'interazione dell'ambiente CDE con tali reti deve essere protetta in base ai requisiti. Con questo cluster privato, è possibile usare reti virtuali, gruppi di sicurezza di rete e altre funzionalità predefinite per proteggere l'intero ambiente.

Per informazioni sui cluster privati, vedere Creare un cluster del servizio Azure Kubernetes privato.

Requisito 1.2.1

Limitare il traffico in ingresso e in uscita a quanto necessario per l'ambiente dei dati del titolare carta e rifiutare in modo esplicito tutti gli altri tipi di traffico.

Responsabilità dell'utente

Per impostazione predefinita, le reti virtuali di Azure non possono essere raggiunte direttamente dalla rete Internet pubblica. Tutto il traffico in ingresso (o ingresso) deve attraversare un router di traffico intermedio. Per impostazione predefinita, tuttavia, tutti i componenti della rete possono raggiungere gli endpoint pubblici. È possibile disabilitare questo comportamento configurando una subnet privata o usando una route definita dall'utente (UDR) per instradare tutto il traffico in uscita attraverso un firewall. Il traffico in uscita (o uscita) deve essere protetto in modo esplicito per consentire solo crittografie sicure e TLS 1.2 o versione successiva.

• Il gateway delle applicazioni di Azure per container con WAF integrato intercetta tutto il traffico HTTP(S) in ingresso e instrada il traffico ispezionato al cluster.

  Questo traffico può provenire da reti attendibili o non attendibili. Il Gateway applicativo per contenitori viene provvisto in una subnet della rete spoke e protetto da un gruppo di sicurezza di rete. Con il flusso del traffico, le regole WAF consentono o negano, e Gateway applicativo per contenitori instrada il traffico al back-end configurato. Ad esempio, Gateway applicativo per contenitori protegge l'ambiente CDE negando i tipi di traffico seguenti:

  • Tutto il traffico non crittografato con TLS.
  • Traffico esterno all'intervallo di porte per la comunicazione del piano di controllo dall'infrastruttura di Azure.
  • Richieste probe di integrità inviate da entità diverse dal servizio di bilanciamento del carico interno nel cluster.

• Firewall di Azure protegge tutto il traffico in uscita (in uscita) da reti attendibili e non attendibili.

  Il provisioning di Firewall di Azure viene effettuato in una subnet della rete hub. Per applicare Firewall di Azure come singolo punto di uscita, le route definite dall'utente (UDR) vengono usate nelle subnet in grado di generare traffico in uscita. Sono incluse le subnet in reti non attendibili, ad esempio la rete virtuale del generatore di immagini. Dopo che il traffico raggiunge Firewall di Azure, vengono applicate diverse regole con ambito che consentono al traffico da origini specifiche di passare a destinazioni specifiche.

  Per altre informazioni, vedere Usare Firewall di Azure per proteggere le distribuzioni del servizio Azure Kubernetes.

• Facoltativamente, è possibile usare un proxy HTTP per il monitoraggio e la protezione del traffico in uscita (in uscita) dal cluster alle risorse esterne.

  Oltre a un firewall, alcune organizzazioni potrebbero voler usare un proxy HTTP per avere controlli aggiuntivi in uscita. È consigliabile che le route definite dall'utente continuino a passare attraverso il firewall e che il traffico in uscita sia limitato a passare esclusivamente attraverso il proxy HTTP. Con questa configurazione, se un pod tenta di eseguire l'override del proxy, il firewall può comunque bloccare il traffico in uscita.

  Per altre informazioni, vedere Supporto proxy HTTP nel servizio Azure Kubernetes.

Il cluster potrebbe richiedere l'accesso ad altri servizi tramite Internet pubblico. Ad esempio, se si usa un software antimalware di terze parti, sarà necessario ottenere le definizioni di virus da un server su Internet pubblico.

Le interazioni con gli endpoint di altri servizi di Azure si trovano nel backbone di Azure. Ad esempio, come parte delle normali operazioni, il cluster dovrà ottenere i certificati dall'archivio chiavi gestito, estrarre immagini da un registro contenitori e così via. Assicurarsi che tali interazioni siano private e sicure usando Collegamento privato di Azure.

Oltre alle regole del firewall e alle reti private, i flussi di traffico vengono protetti anche tramite regole di NSG. Gli esempi seguenti illustrano questa architettura in cui la rete CDE è protetta negando il traffico:

• Gli NSG nelle subnet con pool di nodi negano l'accesso SSH ai nodi. Assicurarsi di disporre di un processo per l'accesso just-in-time per gli interventi di emergenza mantenendo comunque il principio di negazione.
• Un NSG nella subnet con jump box per l'esecuzione degli strumenti di gestione nega tutto il traffico tranne Azure Bastion nella rete hub.
• I gruppi di sicurezza di rete nelle subnet che hanno gli endpoint privati per Azure Key Vault e Registro contenitori di Azure negano tutto il traffico, ad eccezione del servizio di bilanciamento del carico interno e del traffico su collegamento privato di Azure.

Requisito 1.2.2

Proteggere e sincronizzare i file di configurazione dei router.

Responsabilità dell'utente

Disporre di un meccanismo per rilevare il delta tra lo stato distribuito effettivo e lo stato desiderato. L'infrastruttura distribuita come codice (IaC) è un'ottima scelta a tale scopo. Ad esempio, i file Bicep o i modelli di Azure Resource Manager (modelli ARM) mantengono un record dello stato desiderato.

Gli asset di distribuzione, ad esempio i file Bicep, devono essere controllati dal codice sorgente in modo da avere la cronologia di tutte le modifiche. Raccogliere informazioni dai log attività di Azure, dai log della pipeline di distribuzione e dai log di distribuzione di Azure. Queste origini consentono di tenere traccia degli asset distribuiti.

Nel cluster, anche i controlli di rete, ad esempio i criteri di rete Kubernetes, devono seguire il flusso controllato dall'origine. In questa implementazione, Flux viene usato come operatore GitOps. Quando si sincronizza una configurazione del cluster, ad esempio i criteri di rete, la cronologia Git combinata con Flux e i log API può essere un'origine della cronologia di configurazione.

Requisito 1.2.3

Installare firewall perimetrali tra tutte le reti wireless e l'ambiente dati dei titolari di carte e configurare questi firewall per negare o consentire solo il traffico autorizzato tra l'ambiente wireless e l'ambiente dei dati dei titolari di carte se il traffico è necessario per scopi aziendali.

Responsabilità dell'utente

I nodi di AKS e i pool di nodi non devono essere raggiungibili dalle reti wireless. Inoltre, le richieste al server API Kubernetes devono essere negate. L'accesso a tali componenti è limitato alle subnet autorizzate e protette.

In generale, limitare l'accesso dal traffico locale alla rete spoke.

Requisito 1.3

Proibire l'accesso pubblico diretto tra Internet e qualsiasi componente di sistema nell'ambiente dei dati di titolari di carte.

Responsabilità dell'utente

I pool di nodi del cluster di AKS operano all'interno della rete virtuale e sono isolati da reti pubbliche come Internet. Mantenere l'isolamento impedendo l'associazione di indirizzi IP pubblici ai nodi del cluster e applicando le regole del gruppo di sicurezza di rete nelle subnet del cluster per assicurarsi che il traffico Internet sia bloccato. Per informazioni sull'accesso controllato, vedere la sezione Rete perimetrale.

Il cluster di AKS include pool di nodi di sistema che ospitano pod di sistema critici. Anche nei pool di nodi utente sono presenti pod che eseguono altri servizi che partecipano alle operazioni del cluster. Ad esempio, i pod potrebbero eseguire Flux per sincronizzare la configurazione del cluster in un repository GitHub o il controller di ingresso per instradare il traffico ai pod del carico di lavoro. Indipendentemente dal tipo di pool di nodi, tutti i nodi devono essere protetti.

Un altro componente di sistema critico è il server API usato per eseguire attività Kubernetes native, ad esempio mantenere lo stato del cluster e della configurazione. Un vantaggio dell'uso di un cluster privato è che l'endpoint del server API non è esposto per impostazione predefinita. Per informazioni sui cluster privati, vedere Creare un cluster del servizio Azure Kubernetes privato.

Anche le interazioni con altri endpoint devono essere protette. Un modo consiste nel limitare le comunicazioni su una rete privata. Ad esempio, fare in modo che le immagini di pull del cluster provengano da Registro contenitori di Azure tramite un collegamento privato.

Requisito 1.3.1

Implementare una rete perimetrale per limitare il traffico in ingresso solo ai componenti di sistema che forniscono porte, servizi e protocolli autorizzati accessibili pubblicamente.

Responsabilità dell'utente

Esaminare le procedure consigliate seguenti per l'implementazione di una rete perimetrale:

• Non configurare indirizzi IP pubblici nei nodi del pool di nodi.
• Usare Azure Policy per assicurarsi che Kubernetes non esponga un bilanciamento del carico pubblico. Il traffico all'interno del cluster deve essere instradato tramite servizi di bilanciamento del carico interni.
• Esporre solo i bilanciatori di carico interni al Gateway di Azure per Applicazioni per i contenitori integrato con WAF.
• Tutti i controlli di rete devono specificare restrizioni di origine, destinazione, porta e protocollo, se applicabile.
• Non esporre il server API a Internet. Quando si esegue il cluster in modalità privata, l'endpoint non viene esposto e la comunicazione tra i pool di nodi e il server API si trova in una rete privata.

È possibile implementare una rete perimetrale per proteggere i cluster del servizio Azure Kubernetes (AKS). Per altre informazioni, vedere Rete perimetrale cloud.

Requisito 1.3.2

Limitare il traffico Internet in ingresso verso indirizzi IP all'interno della rete perimetrale.

Responsabilità dell'utente

Nella rete del cluster, avere un NSG nella subnet con servizio di bilanciamento del carico interno. Configurare le regole per accettare solo il traffico dalla subnet che ha Gateway applicativo per contenitori di Azure integrato con WAF. All'interno del cluster di servizio Azure Kubernetes, usare Kubernetes NetworkPolicies per limitare il traffico in ingresso ai pod.

Requisito 1.3.3

Implementare misure anti-spoofing per rilevare indirizzi IP di origine contraffatti e impedirne l'ingresso nella rete.

Responsabilità di Azure

Azure implementa l'applicazione di filtri alla rete per impedire il traffico falsificato e limitare il traffico in ingresso e in uscita ai componenti attendibili della piattaforma.

Requisito 1.3.4

Non consentire il traffico in uscita non autorizzato dall'ambiente dei dati dei titolari di carta verso Internet.

Responsabilità dell'utente

È possibile bloccare il traffico in uscita non autorizzato usando le procedure consigliate seguenti:

• Applicare tutto il traffico in uscita (in uscita) dal cluster di AKS per passare attraverso Firewall di Azure usando route definite dall'utente in tutte le subnet del cluster. Sono incluse le subnet con pool di nodi di sistema e utente.
• Limitare il traffico in uscita aggiungendo NSG nelle subnet con pool di nodi.
• Usare Kubernetes NetworkPolicies per limitare il traffico in uscita dai pod.
• Usare una mesh di servizi per gestire criteri aggiuntivi. Ad esempio, se si consente solo il traffico crittografato TLS tra pod, il proxy mesh del servizio può gestire la verifica TLS. Questo esempio è illustrato in questa implementazione. Envoy viene distribuito come proxy.
• Impedire l'aggiunta di indirizzi IP pubblici alle reti all'interno della rete CDE, a meno che le subnet non siano autorizzate in modo esplicito, ad esempio le subnet del firewall.
• Usare un proxy HTTP, oltre a Firewall di Azure, per limitare il traffico in uscita (in uscita) dal cluster di AKS a Internet.
• Usare Servizio collegamento privato di Monitoraggio di Azure (AMPLS) per fare in modo che i log di Informazioni dettagliate sui contenitori siano inviati tramite una connessione privata sicura a Monitoraggio di Azure. Comprendere l'impatto dell'abilitazione di AMPLS.

Annotazioni

È possibile usare Kubernetes NetworkPolicies per limitare il traffico in ingresso e in uscita verso e dai pod.

Per i dettagli, vedere Controllare il traffico in uscita per i nodi del cluster nel servizio Azure Kubernetes.

Requisito 1.3.5

Consentire solo connessioni "stabilite" nella rete.

Responsabilità di Azure

Azure implementa l'applicazione di filtri alla rete per impedire il traffico falsificato e limitare il traffico in ingresso e in uscita ai componenti attendibili della piattaforma. La rete di Azure è segregata in modo da separare il traffico dei clienti dal traffico di gestione.

Requisito 1.3.6

Posizionare i componenti di sistema che archiviano i dati dei titolari di carta, ad esempio un database, in una zona di rete interna, separati dalla rete perimetrale e da altre reti non attendibili.

Responsabilità dell'utente

Esporre i sistemi di archiviazione solo su una rete privata, ad esempio usando collegamento privato. Limitare inoltre l'accesso dalle subnet del pool di nodi che lo richiedono. Mantenere lo stato fuori dal cluster e nella propria zona di sicurezza dedicata.

Requisito 1.3.7

Non divulgare indirizzi IP privati e informazioni di routing a parti non autorizzate.

Responsabilità dell'utente

Per soddisfare questo requisito, un cluster AKS pubblico non è un'opzione. Un cluster privato mantiene i record DNS fuori dalla rete Internet pubblica usando una zona DNS privato. Tuttavia, è comunque possibile creare un cluster del servizio Azure Kubernetes privato con un indirizzo DNS pubblico. È consigliabile disabilitare questa funzionalità in modo esplicito configurando enablePrivateClusterPublicFQDN a false per impedire la divulgazione dell'indirizzo IP privato del piano di controllo. È consigliabile usare Criteri di Azure per applicare l'uso di cluster privati senza record DNS pubblici.

Usare anche una zona DNS privata per il routing tra la subnet con Azure Application Gateway per contenitori integrato con WAF e la subnet con il bilanciatore di carico interno. Assicurarsi che nessuna risposta HTTP includa informazioni IP private nelle intestazioni o nel corpo. Verificare che tutti i log che potrebbero contenere record IP e DNS non siano esposti al di fuori delle esigenze operative.

Un servizio di Azure connesso tramite collegamento privato non dispone di un record DNS pubblico che espone gli indirizzi IP privati. L'infrastruttura deve usare in modo ottimale collegamento privato.

Requisito 1.4

Installare il software firewall personale o una funzionalità equivalente su qualsiasi dispositivo informatico portatile che si connette a Internet quando si trova all'esterno della rete e che viene utilizzato anche per accedere al CDE.

Responsabilità dell'utente

Il cluster privato viene gestito dal piano di controllo di AKS. Non si ha accesso direttamente ai nodi. Per le attività amministrative, è necessario usare strumenti di gestione come kubectl da una risorsa di calcolo separata. Un'opzione consiste nell'usare una jump box isolato in cui è possibile eseguire i comandi. Anche il traffico in ingresso e in uscita dalla jump box deve essere limitato e sicuro. Se la VPN viene usata per l'accesso, assicurarsi che il computer client sia gestito dai criteri aziendali e che siano presenti tutti i criteri di accesso condizionale.

In questa architettura, tale jump box si trova in una subnet separata nella rete spoke. L'accesso in ingresso alla jump box è limitato tramite un NSG che consente l'accesso solo tramite Azure Bastion tramite SSH.

Per eseguire determinati comandi nella jump box, è necessario raggiungere gli endpoint pubblici. Ad esempio, gli endpoint gestiti dal piano di gestione di Azure. Il traffico in uscita deve essere sicuro. Analogamente ad altri componenti della rete spoke, il traffico in uscita dalla jump box è limitato tramite una route definita dall'utente che forza il traffico HTTPS a passare attraverso Firewall di Azure.

Requisito 1.5

Assicurarsi che i criteri di sicurezza e le procedure operative per la gestione dei firewall siano documentati, applicati e noti a tutte le parti interessate.

Responsabilità dell'utente

È fondamentale conservare una documentazione completa sul processo e sui criteri. Ciò vale soprattutto quando si gestiscono Firewall di Azure regole che segmentano il cluster di AKS. Le persone che operano in ambienti regolamentati devono essere istruite, informate e incoraggiate a sostenere le garanzie di sicurezza. Ciò è particolarmente importante per gli utenti con account a cui vengono concessi ampi privilegi amministrativi.

Requisito 2: Non usare le impostazioni predefinite fornite dal fornitore per le password di sistema e altri parametri di sicurezza

Responsabilità dell'utente

Requisito	Responsabilità
Requisito 2.1	Modificare sempre i valori predefiniti dei fornitori e rimuovere o disabilitare gli account predefiniti non necessari prima di installare un sistema in rete.
Requisito 2.2	Elaborare standard di configurazione per tutti i componenti di sistema. Assicurarsi che questi standard tengano conto di tutte le vulnerabilità di sicurezza note e siano coerenti con gli standard di protezione avanzata dei sistemi accettati dal settore.
Requisito 2.3	Crittografare tutti gli accessi amministrativi non eseguiti tramite la console con la crittografia avanzata.
Requisito 2.4	Creare e mantenere aggiornato un inventario dei componenti di sistema che rientrano nell'ambito per PCI DSS.
Requisito 2.5	Assicurarsi che i criteri di sicurezza e le procedure operative per la gestione dei valori predefiniti dei fornitori e gli altri parametri di sicurezza siano documentati, applicati e noti a tutte le parti interessate.
Requisito 2.6	I provider di hosting condivisi devono proteggere l'ambiente ospitato e i dati di titolari di carte di ogni entità.

Non usare le impostazioni predefinite fornite dal fornitore per le password di sistema e altri parametri di sicurezza

Requisito 2.1

Modificare sempre i valori predefiniti dei fornitori e rimuovere o disabilitare gli account predefiniti non necessari prima di installare un sistema in rete.

Responsabilità dell'utente

Le impostazioni predefinite fornite dai fornitori devono essere modificate. Le impostazioni predefinite sono vettori di attacco comuni e rendono il sistema soggetto ad attacchi. Prendere in considerazione le procedure consigliate seguenti:

• Disabilitare l'accesso amministratore nel registro contenitori.
• Assicurarsi che i jump box e gli agenti di compilazione seguano le procedure di gestione degli utenti, rimuovendo gli utenti di sistema non necessari.
• Non generare o fornire l'accesso con chiave SSH ai nodi agli utenti amministratori. Se è necessario l'accesso di emergenza, usare il processo di ripristino di Azure per ottenere l'accesso Just-In-Time.

Responsabilità di Azure

Microsoft Entra ID include criteri password applicati alle nuove password fornite dagli utenti. Se si modifica una password, è necessaria la convalida della password precedente. Una password reimpostata da un amministratore deve essere modificata al successivo accesso dell'utente.

Requisito 2.1.1

Per gli ambienti wireless connessi all'ambiente dati dei titolari di carte o la trasmissione dei dati dei titolari di carte, modificare tutte le impostazioni predefinite del fornitore wireless durante l'installazione, tra cui: chiavi di crittografia wireless predefinite, password e stringhe della community SNMP.

Responsabilità dell'utente

Questa architettura e l'implementazione non sono progettate per eseguire transazioni locali o aziendali da rete a cloud tramite connessioni wireless. Per considerazioni, vedere le linee guida nello standard UFFICIALE PCI DSS 4.0.1.

Requisito 2.2

Elaborare standard di configurazione per tutti i componenti di sistema.

Responsabilità dell'utente

Implementare le raccomandazioni nel benchmark di sicurezza di Microsoft Cloud. Offre una singola visualizzazione consolidata delle raccomandazioni sulla sicurezza di Azure, che copre framework di settore come CIS, NIST e PCI DSS 4.0.1. Usare le funzionalità di Microsoft Defender per il cloud e Criteri di Azure per tenere traccia degli standard. Azure Security Benchmark è l'iniziativa predefinita di Microsoft Defender per il cloud. Valutare la creazione di controlli automatizzati aggiuntivi in Criteri di Azure e nella soluzione Azure Tenant Security (AzTS).

Documentare lo stato di configurazione desiderato di tutti i componenti nell'ambiente CDE, in particolare per nodi di AKS, jump box, agenti di compilazione e altri componenti che interagiscono con il cluster.

Per altre informazioni, vedere il benchmark della sicurezza del cloud Microsoft.

Responsabilità di Azure

Azure offre standard di configurazione della sicurezza coerenti con gli standard di protezione avanzata accettati dal settore. Gli standard vengono rivisti almeno ogni anno.

Requisito 2.2.1

Implementare una sola funzione principale per server per evitare la coesistenza nello stesso server di funzioni che richiedono livelli di sicurezza diversi. Ad esempio, i server Web, i server di database e DNS devono essere implementati in server separati.

Responsabilità dell'utente

La strategia chiave consiste nel fornire il livello necessario di segmentazione. Un modo consiste nel distribuire componenti nell'ambito e out-of-scope in cluster separati. Comprendere che ciò comporta un aumento dei costi per l'infrastruttura aggiunta e il sovraccarico di manutenzione. Un altro approccio consiste nel co-individuare tutti i componenti in un cluster condiviso. Usare strategie di segmentazione per mantenere la separazione. Ad esempio, avere pool di nodi separati all'interno di un cluster.

Nell'implementazione di riferimento, il secondo approccio viene illustrato con un'applicazione di microservizi distribuita in un singolo cluster. 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. Con l'uso di contenitori Kubernetes, l'ambito e i pod out-of-scope vengono distribuiti in pool di nodi separati e non condividono mai una VM del nodo.

Per le tecnologie contenitore, tale segmentazione viene fornita per impostazione predefinita perché solo un'istanza di un contenitore è responsabile di una funzione nel sistema.

Ogni pod del carico di lavoro deve usare la propria identità. Non deve ereditare alcuna identità a livello di cluster o a livello di nodo.

Usare l'archiviazione esterna anziché l'archiviazione su nodo (in cluster) laddove possibile. Mantenere i pod del cluster riservati esclusivamente per il lavoro che deve essere eseguito come parte dell'operazione di elaborazione dei dati del titolare della scheda. Spostare le operazioni esterne all'ambito all'esterno del cluster. Queste indicazioni si applicano agli agenti di compilazione, ai carichi di lavoro non correlati o alle attività, ad esempio la presenza di un jump box all'interno del cluster.

Requisito 2.2.2

Abilitare solo i servizi, i protocolli, i daemon e altri componenti necessari, come richiesto per la funzione del sistema.

Responsabilità dell'utente

Esaminare le funzionalità e le implicazioni prima di abilitarle. Le impostazioni predefinite possono includere funzionalità non necessarie e queste funzionalità potrebbero richiedere visibilità sul carico di lavoro. Un esempio è rappresentato dalle crittografie nella policy TLS predefinita per Azure Application Gateway per i container. Controllare se il criterio è eccessivamente permissivo. È consigliabile creare un criterio personalizzato selezionando solo le crittografie necessarie.

Per i componenti in cui è disponibile il controllo completo, rimuovere tutti i servizi di sistema non necessari dalle immagini. Ad esempio, esaminare le immagini per i jump box e gli agenti di compilazione e rimuovere tutti i componenti non necessari.

Per i componenti in cui è disponibile solo visibilità, ad esempio i nodi di AKS, documentare le installazioni di Azure nei nodi. Prendere in considerazione l'uso di DaemonSets per fornire eventuali controlli aggiuntivi necessari per questi componenti controllati dal cloud.

Requisito 2.2.3

Implementare funzionalità di sicurezza aggiuntive per tutti i servizi, i protocolli o i daemon obbligatori che vengono considerati non sicuri.

Responsabilità dell'utente

Gateway applicativo per contenitori ha un WAF integrato e negozia l'handshake TLS per la richiesta inviata al relativo endpoint pubblico, consentendo solo cifrari sicuri. L'implementazione di riferimento supporta solo TLS 1.2 e crittografie approvate.

Si supponga di avere un dispositivo legacy che deve interagire con la rete CDE tramite Gateway applicazione di Azure. Per soddisfare tale requisito, gateway applicazione deve abilitare un protocollo non sicuro. Documentare l'eccezione e monitorare se tale protocollo viene usato oltre il dispositivo legacy. Disabilitare il protocollo immediatamente dopo l'interruzione dell'interazione legacy.

Gateway applicazione non deve rispondere alle richieste sulla porta 80. Non eseguire reindirizzamenti a livello di applicazione. Questa implementazione di riferimento dispone di una regola del gruppo di sicurezza di rete che blocca il traffico della porta 80. La regola si trova nella subnet con Gateway applicazione.

Se un carico di lavoro nel cluster non può rispettare i criteri dell'organizzazione relativi ai profili di conformità della sicurezza o ad altri controlli (ad esempio, limiti e quote), assicurarsi che l'eccezione sia documentata. È necessario monitorare per assicurarsi che venga eseguita solo la funzionalità prevista.

Requisito 2.2.4

Configurare i parametri di sicurezza del sistema per evitare usi impropri.

Responsabilità dell'utente

Tutti i servizi di Azure usati nell'architettura devono seguire le raccomandazioni fornite dal benchmark di sicurezza di Microsoft Cloud. Questi consigli forniscono un punto di partenza per la selezione di impostazioni di configurazione di sicurezza specifiche. Confrontare anche la configurazione con l'implementazione di base per tale servizio. Per altre informazioni sulle baseline di sicurezza, vedere Baseline di sicurezza per Azure.

Il controller di ammissione Open Policy Agent funziona in combinazione con Criteri di Azure per rilevare e prevenire errori di configurazione nel cluster. Si supponga che siano presenti criteri dell'organizzazione che non consentono allocazioni di indirizzi IP pubblici nei nodi. Quando viene rilevata tale allocazione, viene contrassegnata per il controllo o negata in base all'azione specificata nella definizione dei criteri.

A livello di infrastruttura, è possibile applicare restrizioni al tipo e alla configurazione delle risorse di Azure. Usare Criteri di Azure per evitare errori di configurazione. In questa implementazione di riferimento è presente un criterio che nega la creazione di cluster di AKS non privati.

Verificare che tutte le eccezioni siano documentate ed esaminate regolarmente.

Responsabilità di Azure

Azure garantisce che solo il personale autorizzato possa configurare i controlli di sicurezza della piattaforma Azure, usando controlli di accesso a più fattori e in base a esigenze aziendali documentate.

Requisito 2.2.5

Rimuovere tutte le funzionalità non necessarie, ad esempio script, driver, funzionalità, sottosistemi, file system e server Web non necessari.

Responsabilità dell'utente

Non installare software in jump box o agenti di compilazione che non partecipano all'elaborazione di una transazione o forniscono l'osservabilità per i requisiti di conformità, ad esempio gli agenti di sicurezza. Questa raccomandazione si applica anche alle entità del cluster, ad esempio DaemonSet e ai pod. Assicurarsi che tutte le installazioni vengano rilevate e registrate.

Requisito 2.3

Crittografare tutti gli accessi amministrativi non eseguiti tramite la console con la crittografia avanzata.

Responsabilità dell'utente

Tutti gli accessi amministrativi al cluster devono essere eseguiti usando la console. Non esporre il piano di controllo del cluster.

Responsabilità di Azure

Azure garantisce l'applicazione della crittografia avanzata per l'accesso all'infrastruttura dell'hypervisor. Garantisce che i clienti che usano il portale di Azure siano in grado di accedere ai servizi e alle console host usando la crittografia avanzata.

Requisito 2.4

Creare e mantenere aggiornato un inventario dei componenti di sistema che rientrano nell'ambito per PCI DSS.

Responsabilità dell'utente

Tutte le risorse di Azure usate nell'architettura devono essere contrassegnate correttamente. I tag sono utili per la classificazione dei dati e indicano se il servizio è incluso nell'ambito o nell'ambito esterno. L'assegnazione di tag meticolosa consente di eseguire query per le risorse, mantenere un inventario, tenere traccia dei costi e impostare avvisi. Mantenere periodicamente uno snapshot di tale documentazione.

Evitare l'assegnazione di tag alle risorse nell'ambito o all'esterno dell'ambito a un livello granulare. Man mano che la soluzione si evolve, le risorse esterne all'ambito potrebbero diventare nell'ambito anche se interagiscono indirettamente o sono adiacenti ai dati del titolare della scheda. Queste risorse sono soggette al controllo e potrebbero far parte di un campione rappresentativo durante il controllo. Prendere in considerazione l'assegnazione di tag a un livello superiore, a livello di sottoscrizione e cluster.

Per informazioni sulle considerazioni relative all'assegnazione di tag, vedere Denominazione delle risorse e guida alle decisioni relative all'assegnazione di tag.

Contrassegnare gli oggetti nel cluster applicando etichette Kubernetes. In questo modo, è possibile organizzare gli oggetti, selezionare una raccolta di oggetti e creare report di inventario.

Requisito 2.5

Assicurarsi che i criteri di sicurezza e le procedure operative per la gestione dei valori predefiniti dei fornitori e gli altri parametri di sicurezza siano documentati, applicati e noti a tutte le parti interessate.

Responsabilità dell'utente

È fondamentale conservare una documentazione completa sui processi e sui criteri. Il personale deve essere sottoposto a training nelle funzionalità di sicurezza e nelle impostazioni di configurazione di ogni risorsa di Azure. Le persone che operano in ambienti regolamentati devono essere istruite, informate e incoraggiate a sostenere le garanzie di sicurezza. Questi passaggi sono particolarmente importanti per tutte le persone a cui vengono concessi privilegi amministrativi generali.

Requisito 2.6

I provider di hosting condivisi devono proteggere l'ambiente ospitato e i dati di titolari di carte di ogni entità.

Responsabilità dell'utente

Azure offre garanzie di sicurezza per tutti i componenti dell'ambiente ospitato condivisi. È consigliabile considerare i nodi di AKS come host dedicato per questo carico di lavoro. Ovvero, tutte le risorse di calcolo devono trovarsi in un modello a tenant singolo e non condivise con altri carichi di lavoro che è possibile usare.

Se si desidera un isolamento dell'ambiente di calcolo completo a livello di infrastruttura di Azure, è possibile aggiungere un host dedicato di Azure a un cluster del Servizio Azure Kubernetes. Questa offerta fornisce server fisici dedicati al carico di lavoro, consentendo di inserire i nodi del servizio Azure Kubernetes direttamente in questi host di cui è stato effettuato il provisioning. Questa scelta dell'architettura ha implicazioni significative sul costo e richiede un'attenta pianificazione della capacità. Non è tipico per la maggior parte degli scenari.

Passaggi successivi

Proteggere i dati di titolari di carte archiviati. Crittografare la trasmissione dei dati di titolari di carte su reti pubbliche aperte.

Proteggere i dati di titolari di carte