Configurare la rete di un cluster regolamentato di AKS per PCI-DSS 3.2.1 (parte 3 di 9)

Questo articolo descrive le considerazioni relative alla rete per il servizio Azure Kubernetes (AKS) configurato in base allo standard Pci-DSS 3.2.1 di Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

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

Il tema principale dello standard PCI-DSS 3.2.1 è la sicurezza. 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 un Kubernetes, non è sufficiente basarsi su costrutti di rete tradizionali, ad esempio le regole del firewall. 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.

Creare e mantenere una rete e sistemi sicuri

Requisito 1—Installare e gestire una configurazione del firewall per proteggere i dati dei titolari delle schede di credito.

Supporto per le funzionalità dell'AKS

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 schede. 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, consultare la sezione Creazione di un cluster di Servizio Azure Kubernetes.

Firewall di Azure può essere integrato con AKS e può limitare il traffico in uscita dal cluster, che è un componente chiave dell'ambiente CDE. La configurazione è semplificata con un tag FQDN di AKS. Il processo consigliato è disponibile nella sezione Uso di Firewall di Azure per proteggere le distribuzioni di servizio Azure Kubernetes (AKS).

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, consultare la sezione: Controllare il traffico in uscita per i nodi del cluster nel servizio Azure Kubernetes (AKS).

AKS supporta facoltativamente la possibilità di definire un proxy HTTP, che può essere usato 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 AKS, sono disponibili diverse opzioni per il plug-in criteri di rete, tra cui Calico, Gestione 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). I plug-in Criteri di rete di Azure e Calico sono open source. Per maggiori informazioni su Project Calico, consultare il white paper completo sulla soluzione PCI, che soddisfa molti dei requisiti del firewall seguenti.

Responsabilità

Requisito	Responsabilità
Requisito 1.1	Stabilire e implementare gli standard di configurazione di firewall e router.
Requisito 1.2	Creazione di configurazioni di firewall e router che limitano le connessioni tra reti non attendibili e i componenti di sistema nell'ambiente dei dati di titolari di schede.
Requisito 1.3	Proibire l'accesso pubblico diretto tra Internet e qualsiasi componente di sistema nell'ambiente dei dati di titolari di schede.
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 CDE.
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 testing di tutte le connessioni di rete e delle modifiche alle configurazioni di firewall e router.

Responsabilità

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 versioning. 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 il rilevamento, l'implementazione e la distribuzione sicura delle 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 aggiornato che identifica tutte le connessioni tra l'ambiente dei titolari di schede e altre reti, tra cui eventuali reti wireless

Responsabilità

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.

Questa immagine mostra il diagramma di rete dell'implementazione di riferimento.

Scaricare un file Visio di questo diagramma.

Figura 1.1.2 - Flusso di rete

La descrizione di questo flusso è disponibile 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 in una rete virtuale, le risorse associate alle risorse in una rete virtuale e le relazioni tra le risorse.

Requisito 1.1.3

Diagramma aggiornato che mostra tutti i flussi dei dati di titolari di schede all'interno di sistemi e reti.

Responsabilità

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 come parte del processo di gestione delle modifiche per aggiornare il diagramma del flusso di dati.

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

Requisito 1.1.4

Presenza di un firewall per ogni connessione a Internet e tra qualsiasi rete perimetrale (DMZ) e la zona della rete interna.

Responsabilità

Avere una definizione chiara di ciò che definisce il limite di una DMZ. Ad esempio, l'ambiente dei dati dei titolari di schede (CDE) potrebbe trovarsi all'interno di una DMZ protetta da firewall, criteri di rete e altri controlli. Per maggiori informazioni, consultare la sezione DMZ 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 in entrambe le direzioni, da e verso il cluster che ospita l'ambiente CDE:

• Gateway applicazione di Azure viene usato come router del traffico e viene usato il web application firewall integrato (WAF) per proteggere il traffico in ingresso (in ingresso) al cluster.

• Firewall di Azure viene usato per proteggere 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 vengono aggiunti per proteggere 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 sulle comunicazioni nel cluster, a partire da una rete senza attendibilità e aprendo i percorsi in base alle esigenze. L'implementazione di riferimento illustra le reti senza 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) hanno criteri di rete restrittivi applicati. 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à

Sarà 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à

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.

Ecco alcuni esempi in cui è possibile consentire il traffico:

Regola	Protocollo:Porta	Source (Sorgente)	Destination	Giustificazione
Consentire una 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 di riesame dei set di regole per firewall e router almeno ogni sei mesi

Responsabilità

Disporre di processi almeno ogni sei mesi per esaminare le configurazioni di rete e le regole con ambito. In questo modo si assicurerà che le garanzie di sicurezza siano correnti e valide. Assicurarsi di rivedere queste configurazioni:

• Regole di Firewall di Azure.
• Regole NSG.
• Regole di gateway applicazione di Azure e 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

Creazione di configurazioni di firewall e router che limitano le connessioni tra reti non attendibili e i componenti di sistema nell'ambiente dei dati di titolari di schede.

Responsabilità

In questa architettura, il cluster del servizio Azure Kubernetes è un componente chiave dell'ambiente di titolari di schede (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 alla rete Internet. Il record DNS sarà sempre individuabile. È quindi necessario disporre di controlli per proteggere l'API del cluster 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 3.2.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, consultare la sezione Creazione di un cluster privato del servizio Azure Kubernetes.

Requisito 1.2.1

Limitare il traffico in ingresso e in uscita a quello necessario per l'ambiente dei dati di titolari di schede e negare in modo specifico tutto il restante traffico.

Responsabilità

Per impostazione predefinita, le reti virtuali di Azure non possono essere raggiunte direttamente dalla rete Internet pubblica. Tutto il traffico in ingresso (o in 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 per inviare tutto il traffico in uscita attraverso un firewall. Il traffico in uscita (o in uscita) deve essere protetto in modo esplicito per consentire solo crittografie sicure e TLS 1.2 o versione successiva.

• Il WAF integrato di Gateway applicazione di Azure intercetta tutto il traffico in ingresso HTTP(S) e instrada il traffico controllato al cluster.

  Questo traffico può provenire da reti attendibili o non attendibili. Gateway applicazione viene effettuato il provisioning in una subnet della rete spoke e protetta da un NSG. Man mano che il traffico passa, le regole WAF consentono o negano e gateway applicazione instradano il traffico al back-end configurato. Ad esempio, gateway applicazione protegge l'ambiente CDE negando questo tipo di traffico:

  • 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 load balancer del carico interno nel cluster.

• Firewall di Azure viene usato per proteggere 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 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 maggiori informazioni, consultare la sezione Uso di Firewall di Azure per proteggere le distribuzioni di Servizio Azure Kubernetes (AKS).

• 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 mantenere le route definite dall'utente al firewall e limitare il traffico in uscita per passare semplicemente al 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 maggiori informazioni, consultare la sezione 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. Ecco alcuni esempi di 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à

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 dei dati di titolari di schede, quindi configurare questi firewall per negare il traffico tra l'ambiente wireless e l'ambiente dei dati di titolari di schede oppure, nel caso il traffico sia necessario per scopi aziendali, consentire solo il traffico autorizzato.

Responsabilità

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 schede.

Responsabilità

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 di NSG nelle subnet del cluster per assicurarsi che il traffico Internet sia bloccato. Per informazioni sull'accesso controllato, consultare la sezione DMZ.

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, consultare la sezione Creazione di un cluster privato del servizio Azure Kubernetes.

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 DMZ per limitare il traffico in ingresso ai soli componenti di sistema che forniscono servizi, protocolli e porte autorizzati e accessibili pubblicamente.

Responsabilità

Ecco alcune procedure consigliate:

• Non configurare gli indirizzi IP pubblici nei nodi del pool di nodi.
• Usare Criteri di Azure per assicurarsi che Kubernetes non esponga un servizio di bilanciamento del carico pubblico. Il traffico all'interno del cluster deve essere instradato tramite load balancer interni.
• Esporre solo i servizi di bilanciamento del carico interni al gateway applicazione di Azure 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.

Gli utenti possono implementare una rete perimetrale per proteggere i cluster di AKS. Per informazioni, consultare la sezione DMZ cloud.

Requisito 1.3.2

Limitare il traffico Internet in ingresso agli indirizzi IP all'interno della DMZ.

Responsabilità

Nella rete del cluster, avere un NSG nella subnet con load balancer interno. Configurare le regole per accettare solo il traffico dalla subnet con Gateway applicazione di Azure integrato con WAF. All'interno del cluster di AKS, 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 di titolari di schede a Internet.

Responsabilità

Di seguito i modi in cui è possibile bloccare il traffico in uscita non autorizzato:

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

Per i dettagli, consultare la sezione Controllo del traffico in uscita per i nodi del cluster nel servizio Azure Kubernetes (AKS).

Requisito 1.3.5

Consentire solo connessioni "comprovate" 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 di titolari di schede (ad esempio un database) in una zona della rete interna, separata dalla DMZ e da altre reti non attendibili.

Responsabilità

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 rivelare indirizzi IP privati e informazioni di routing a soggetti non autorizzati.

Responsabilità

Per soddisfare questo requisito, un cluster di 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 di AKS privato con un indirizzo DNS pubblico. È quindi consigliabile disabilitare in modo esplicito questa funzionalità impostando enablePrivateClusterPublicFQDN in 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 privato per il routing tra la subnet con Gateway applicazione di Azure integrato con WAF e la subnet con load balancer interno. Assicurarsi che nessuna risposta HTTP includa informazioni IP private nelle intestazioni o nel corpo. Assicurarsi che 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à

Il cluster privato viene gestito dal piano di controllo di AKS. Non si ha accesso direttamente ai nodi. Per eseguire attività amministrative, è necessario usare strumenti di gestione come kubectl da una risorsa di calcolo separata. Un'opzione consiste nell'usare una jump box con air-gapped 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à

È fondamentale mantenere 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 i valori predefiniti del fornitore per le password del sistema e altri parametri di sicurezza

Responsabilità

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 schede di ogni entità.

Non usare i valori predefiniti del fornitore per le password del 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à

Le impostazioni predefinite fornite dai fornitori devono essere modificate. Le impostazioni predefinite sono vettori di attacco comuni e rendono il sistema soggetto ad attacchi. Ecco alcune considerazioni:

• Disabilitare l'accesso amministratore nel registro contenitori.
• Assicurarsi che i jumpbox 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 alla 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 dei dati di titolari di schede o che trasmettono dati di titolari di schede, modificare TUTTE le impostazioni predefinite del fornitore wireless, incluse a titolo esemplificativo, le chiavi di crittografia wireless predefinite, le password e le stringhe community SNMP.

Responsabilità

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

Requisito 2.2

Elaborare standard di configurazione per tutti i componenti di sistema.

Responsabilità

Implementare le raccomandazioni nel benchmark di sicurezza cloud Microsoft. Offre una singola visualizzazione consolidata delle raccomandazioni sulla sicurezza di Azure, che copre framework di settore come CIS, NIST, PCI-DSS 3.2.1 e altri. 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 benchmark della sicurezza 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à

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, protocolli, daemon e così via necessari per il funzionamento del sistema.

Responsabilità

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 nei criteri SSL predefiniti per il Gateway applicazione di Azure. 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 jumpbox 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 eventuali servizi, protocolli o daemon necessari, considerati non sicuri.

Responsabilità

Gateway applicazione ha un WAF integrato e negozia l'handshake TLS per la richiesta inviata al relativo endpoint pubblico, consentendo solo crittografie sicure. 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à di 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à

Tutti i servizi di Azure usati nell'architettura devono seguire le raccomandazioni fornite dal benchmark di sicurezza del cloud di Microsoft. 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 maggiori informazioni sulle baseline di sicurezza, consultare la sezione 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 sia in grado di configurare i controlli di sicurezza della piattaforma Azure, usando controlli di accesso a più fattori e un'esigenza aziendale documentata.

Requisito 2.2.5

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

Responsabilità

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à

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 dell'uso della crittografia avanzata durante 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à

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, consultare la sezione 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.

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à

È fondamentale mantenere 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 schede di ogni entità.

Responsabilità

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 (AKS). Questa offerta fornisce server fisici dedicati al carico di lavoro, consentendo di inserire i nodi di AKS 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 schede archiviati. Crittografare la trasmissione dei dati di titolari di schede su reti pubbliche aperte.

Risorse correlate

• Progettazione dell'architettura nel Servizio Azure Kubernetes (AKS)
• Introduzione di un cluster di regolamentato AKS per PCI-DSS 3.2.1 (parte 1 di 9)
• Architettura di un cluster di regolamentato AKS per PCI-DSS 3.2.1 (parte 2 di 9)
• Architettura di base per un cluster del servizio Azure Kubernetes (AKS)
• Baseline di AKS per cluster multiarea