Riepilogo del cluster regolamentato del servizio Azure Kubernetes per PCI DSS 4.0.1

Le linee guida fornite in questa serie incorporano principi ben strutturati in tutte le scelte di progettazione. Questo articolo riepiloga tali scelte.

Questo articolo termina questa serie. Leggi l'introduzione .

Implementazione di riferimento del logo GitHub presto disponibile: il cluster di base del servizio Azure Kubernetes per l'implementazione di riferimento dei carichi di lavoro regolamentati per 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.

Framework ben architettato

L'Framework di Microsoft Azure Well-Architected Framework è un set di principi guida che possono essere usati per valutare una soluzione attraverso i pilastri di qualità dell'eccellenza dell'architettura:

I carichi di lavoro PCI DSS 4.0.1 richiedono il rigore di essere una soluzione ben progettata. Anche se l'allineamento dell'infrastruttura ai requisiti PCI è fondamentale, la conformità non si arresta nell'infrastruttura di hosting. Non affrontare i pilastri della qualità, in particolare la sicurezza, può compromettere la conformità. Le soluzioni ben architettate combinano sia l'infrastruttura che le prospettive del carico di lavoro per arrivare al rigore necessario per ottenere risultati conformi. PCI DSS 4.0.1 introduce nuovi requisiti per la conformità continua, la definizione dell'ambito basato sui rischi, il monitoraggio avanzato e lo sviluppo di software sicuro, tutti trattati in questa guida.

I miglioramenti principali in PCI DSS 4.0.1 rilevanti per gli ambienti cloud e contenitori includono:

  • Approccio personalizzato: flessibilità per soddisfare gli obiettivi di sicurezza tramite controlli alternativi adatti alle architetture native del cloud.
  • Autenticazione avanzata: requisiti di autenticazione a più fattori rafforzati per tutti gli accessi all'ambiente dei dati dei titolari di carte.
  • Convalida continua: monitoraggio e convalida continui dei controlli di sicurezza anziché valutazioni temporizzato.
  • Sicurezza automatizzata: integrazione della sicurezza nelle pipeline DevSecOps con analisi automatizzata delle vulnerabilità e test di sicurezza.
  • Sicurezza dei contenitori: linee guida specifiche per carichi di lavoro in contenitori e infrastruttura temporanea.
  • Principi zero trust: enfasi sugli approcci di verifica e sull'accesso con privilegi minimi.

Affidabilità

L'affidabilità degli ambienti regolamentati deve essere prevedibile in modo che possano essere spiegate in modo coerente a scopo di controllo. Seguire le indicazioni fondamentali fornite nei principi di affidabilità. Le sezioni seguenti riepilogano le procedure consigliate per l'affidabilità per un ambiente regolamentato.

Destinazioni di ripristino e ripristino di emergenza

A causa della natura sensibile dei dati gestiti nei carichi di lavoro regolamentati, gli obiettivi di ripristino e gli obiettivi del punto di ripristino (RPO) sono fondamentali da definire. Qual è la perdita accettabile di CHD? Le attività di ripristino all'interno dell'ambiente CDE sono ancora soggette ai requisiti standard. Aspettarsi errori e disporre di un piano di ripristino chiaro per gli errori allineati a ruoli, responsabilità e accesso giustificato ai dati. I problemi del sito live non sono giustificati per la deviazione da qualsiasi normativa. Ciò è particolarmente importante in una situazione di ripristino di emergenza completa. Avere una documentazione chiara sul ripristino di emergenza conforme ai requisiti e ridurre al minimo l'accesso CDE o CHD imprevisto. Dopo il ripristino, esaminare sempre i passaggi del processo di ripristino per assicurarsi che non si sia verificato alcun accesso imprevisto. Documentare le motivazioni aziendali per tali istanze.

Recupero

L'aggiunta di strategie di resilienza e ripristino all'architettura può impedire l'esigenza di accesso ad hoc all'ambiente CDE. Il sistema deve essere in grado di eseguire il ripristino automatico in corrispondenza dell'RPO definito senza la necessità di intervento diretto dell'uomo. In questo modo, è possibile eliminare l'esposizione non necessaria del CHD, anche a coloro che sono autorizzati ad avere accesso di emergenza. Il processo di ripristino deve essere controllabile.

Esaminare i rischi per la sicurezza perché possono essere una fonte di tempo di inattività del carico di lavoro e perdita di dati. Gli investimenti nella sicurezza hanno anche un impatto sull'affidabilità del carico di lavoro.

Processi operativi

L'affidabilità si estende a tutti i processi operativi in e adiacenti all'ambiente CDE. Processi ben definiti, automatizzati e testati per problemi come la creazione di immagini e il fattore di gestione jump box in una soluzione ben progettata.

Sicurezza

Seguire le indicazioni fondamentali fornite nei principi di progettazione della sicurezza. Le sezioni seguenti riepilogano le procedure consigliate per la sicurezza per un ambiente regolamentato.

Gestione

L'implementazione della governance è basata sui requisiti di conformità in PCI DSS 4.0.1. Ciò influisce sui controlli tecnici per mantenere la segmentazione, l'accesso alle risorse, il rilevamento delle vulnerabilità e la protezione più importante dei dati dei clienti. PCI DSS 4.0.1 sottolinea la responsabilità condivisa, il monitoraggio continuo e l'uso di strumenti automatizzati per la gestione dell'inventario e della configurazione in ambienti cloud e contenitori.

Monitoraggio continuo della conformità: a differenza dell'approccio di valutazione periodico delle versioni precedenti, PCI DSS 4.0.1 richiede la convalida continua dei controlli di sicurezza. Questo è perfettamente allineato alle funzionalità di monitoraggio nativo del cloud, ad esempio Monitoraggio di Azure, Microsoft Defender for Cloud e applicazione automatica dei criteri tramite Criteri di Azure.

Ambito basato sui rischi: lo standard consente ora un ambito più dinamico basato su flussi di dati effettivi e valutazioni dei rischi, particolarmente rilevanti per i carichi di lavoro in contenitori in cui i componenti possono essere temporanei e orchestrati dinamicamente.

Strategia di segmentazione aziendale

Per mantenere l'isolamento completo, è consigliabile distribuire l'infrastruttura regolamentata in una sottoscrizione autonoma. Se sono necessarie più sottoscrizioni per la conformità, è consigliabile raggrupparle in una gerarchia di gruppi di gestione che applica in modo uniforme i criteri di Azure pertinenti nelle sottoscrizioni nell'ambito. All'interno della sottoscrizione applicare i criteri di Azure correlati a livello di sottoscrizione per acquisire i criteri generali che devono essere applicati a tutti i cluster nell'ambiente dei dati dei titolari di schede. Applicare criteri di Azure correlati a livello di gruppo di risorse per acquisire i criteri applicabili a un'istanza del cluster specifica. Questi criteri definiscono le protezioni primarie di una zona di destinazione.

Isolare il carico di lavoro PCI (nell'ambito) da altri carichi di lavoro (fuori ambito) in termini di operazioni e connettività. È possibile creare l'isolamento distribuendo cluster separati o usando strategie di segmentazione per mantenere la separazione. Ad esempio, i cluster usano pool di nodi separati in modo che i carichi di lavoro non condividono mai una macchina virtuale (VM).

Applicazione dei criteri

Applicare i controlli di sicurezza abilitano i criteri di Azure. In questa architettura regolamentata, ad esempio, è possibile evitare errori di configurazione dell'ambiente dati dei titolari di schede. È possibile applicare criteri di Azure che non consentono allocazioni di indirizzi IP pubblici nei nodi della macchina virtuale. Tali allocazioni vengono rilevate e segnalate o bloccate.

Per informazioni sui criteri che è possibile abilitare per il servizio Azure Kubernetes, vedere Definizioni predefinite di Criteri di Azure per il servizio Azure Kubernetes.

Azure offre diversi criteri predefiniti per la maggior parte dei servizi. Esaminare le definizioni di criteri predefiniti di Criteri di Azure e applicarle in base alle esigenze.

Monitoraggio della conformità

La conformità deve essere sistematicamente monitorata e mantenuta. Vengono eseguite attestazioni regolari della conformità. Sapere se le risorse cloud sono conformi consentirà di prepararsi per le attestazioni e il controllo.

Sfrutta i vantaggi della dashboard di conformità alle normative in Microsoft Defender per il cloud. Monitorando continuamente la dashboard, è possibile tenere traccia dello stato di conformità del carico di lavoro.

Screenshot di un dashboard di monitoraggio della conformità di esempio nel portale di Azure.

Sicurezza della rete

In una topologia hub-spoke, la presenza di reti virtuali separate per ogni entità fornisce la segmentazione di base nel footprint di rete. Ogni rete viene ulteriormente segmentata in subnet.

Il cluster AKS costituisce il nucleo dell'ambiente cde. Non deve essere accessibile dagli indirizzi IP pubblici e la connettività deve essere protetta. I flussi tipici all'ingresso e all'esterno dell'ambiente CDE possono essere classificati come:

  • Traffico in ingresso verso il cluster.
  • Traffico in uscita dal cluster.
  • Traffico in-cluster tra i pod.

Per soddisfare i requisiti di un ambiente regolamentato, il cluster viene distribuito come cluster privato. In questa modalità, il traffico da e verso Internet pubblico è limitato. Anche la comunicazione con il server API Kubernetes gestito dal servizio Azure Kubernetes è privata. La sicurezza è ulteriormente migliorata con controlli di rete rigorosi e regole del firewall IP:

  • Gruppi di sicurezza di rete (NSGs) per aiutare a proteggere la comunicazione tra le risorse all'interno di una rete.
  • Firewall di Azure per filtrare il traffico in uscita tra le risorse cloud, Internet e in locale.
  • Gateway applicazione di Azure integrato con Azure Web Application Framework per filtrare tutto il traffico in ingresso da Internet che Gateway applicazione di Azure intercetta.
  • Kubernetes NetworkPolicy per consentire solo determinati percorsi tra i pod nel cluster.
  • Collegamento privato di Azure per connettersi ad altri servizi PaaS (Platform as a Service) di Azure, ad esempio Azure Key Vault e Registro Azure Container, per le attività operative.

I processi di monitoraggio sono disponibili per assicurarsi che il traffico venga trasmesso come previsto e che eventuali anomalie vengano rilevate e segnalate.

Per altre informazioni sulla sicurezza di rete, vedere Segmentazione di rete.

Sicurezza dei dati

PCI DSS 4.0.1 richiede che tutti i dati dei titolari di carte (CHD) non siano mai chiari, sia in transito che in archiviazione.

Poiché questa architettura e l'implementazione sono incentrate sull'infrastruttura e non sul carico di lavoro, la gestione dei dati non viene illustrata. Le sezioni seguenti illustrano alcuni consigli ben strutturati.

Dati statici

I dati devono essere crittografati tramite algoritmi di crittografia standard del settore.

  • Non archiviare i dati nell'ambiente del titolare della scheda.
  • Crittografare all'esterno del livello di archiviazione.
  • Scrivere solo dati crittografati nel supporto di archiviazione.
  • Non archiviare le chiavi nel livello di archiviazione.

Tutti i dati in Archiviazione di Azure vengono crittografati e decrittografati usando la crittografia avanzata. Le chiavi di crittografia autogestito sono preferite.

Se è necessario archiviare temporaneamente i dati, applicare le stesse considerazioni a tali dati. È consigliabile abilitare la funzionalità di crittografia host di AKS. È possibile applicare la crittografia dei dati temporanei con criteri di Azure predefiniti.

Quando si sceglie una tecnologia di archiviazione, esplorare le funzionalità di conservazione. Assicurarsi che tutti i dati vengano rimossi in modo sicuro alla scadenza del tempo configurato.

Lo standard richiede anche che i dati di autenticazione sensibili (SAD) non siano archiviati. Assicurarsi che i dati non siano esposti in log, nomi di file, cache e altri dati.

Dati in transito

Tutte le comunicazioni con le entità che interagiscono con l'ambiente CDE devono essere su canali crittografati. PCI DSS 4.0.1 rafforza i requisiti di crittografia con suite di crittografia e standard di protocollo aggiornati.

  • È necessario consentire solo il flusso del traffico HTTPS nell'ambiente CDE. In questa architettura, Gateway applicazione di Azure nega tutto il traffico sulla porta 80.
  • Preferibilmente, non crittografare e decrittografare i dati all'esterno dell'ambiente CDE. In tal caso, considerare che l'entità faccia parte dell'ambiente CDE.
  • All'interno dell'ambiente CDE, fornire comunicazioni sicure tra pod con mTLS. A questo scopo, è possibile scegliere di implementare una mesh di servizi.
  • Consentire solo crittografie sicure e TLS 1.2 o versione successiva. PCI DSS 4.0.1 fornisce indicazioni aggiornate sui protocolli di crittografia accettabili e sui pacchetti di crittografia.
  • PCI DSS 4.0.1 richiede una gestione più rigorosa del ciclo di vita delle chiavi, inclusa l'integrazione automatizzata della rotazione delle chiavi e del modulo di protezione hardware (HSM), se applicabile.

Identità

Quando si progettano i criteri di accesso, seguire questi principi di sicurezza:

  • Iniziare con criteri senza attendibilità. Creare eccezioni in base alle esigenze.
  • Concedere i privilegi minimi: basta completare un'attività.
  • Ridurre al minimo l'accesso permanente.

PCI DSS 4.0.1 rafforza significativamente i requisiti di autenticazione, imponendo l'autenticazione a più fattori (MFA) per tutti gli accessi all'ambiente dati dei titolari di carte, inclusi l'accesso amministrativo e l'accesso non console.

Il controllo degli accessi in base al ruolo (RBAC) di Kubernetes gestisce le autorizzazioni per l'API Kubernetes. AKS supporta i ruoli Kubernetes. AKS è completamente integrato con Microsoft Entra ID. È possibile assegnare le identità di Microsoft Entra ai ruoli e sfruttare anche altre funzionalità.

Accesso zero-trust

RBAC di Kubernetes, RBAC di Azure e i servizi di Azure implementano la negazione di tutti per impostazione predefinita. Eseguire l'override di tale impostazione con cautela, consentendo l'accesso solo alle entità che ne hanno bisogno. Un'altra area per l'implementazione di zero trust consiste nel disabilitare l'accesso SSH ai nodi del cluster.

Privilegi minimi

È possibile usare le identità gestite per le risorse e i pod di Azure e definire l'ambito per le attività previste. Ad esempio, Gateway applicazione di Azure deve avere le autorizzazioni per ottenere segreti (certificati TLS) da Azure Key Vault. Non deve disporre delle autorizzazioni per modificare i segreti.

Riduzione dell'accesso permanente

Ridurre al minimo l'accesso permanente usando l'appartenenza al gruppo just-in-time di Microsoft Entra. Rafforzare il controllo con i criteri di accesso condizionale in Microsoft Entra ID. Questa opzione supporta molti casi d'uso, ad esempio l'autenticazione a più fattori, la limitazione dell'autenticazione ai dispositivi gestiti dal tenant di Microsoft Entra o il blocco di tentativi di accesso atipici.

Gestione dei segreti

Archiviare segreti, certificati, chiavi e password all'esterno dell'ambiente CDE. È possibile usare oggetti segreti Kubernetes nativi o un archivio chiavi gestito, ad esempio Azure Key Vault. L'uso di un archivio gestito consentirà di gestire le attività di gestione dei segreti, ad esempio la rotazione delle chiavi e il rinnovo dei certificati.

Assicurarsi che l'accesso all'archivio chiavi abbia una combinazione di controlli di rete e di accesso. Quando si abilitano le identità gestite, il cluster deve eseguire l'autenticazione in Key Vault per ottenere l'accesso. Inoltre, la connettività all'archivio chiavi non deve essere tramite la rete Internet pubblica. Usare una rete privata, ad esempio collegamento privato.

Ottimizzazione dei costi

Seguire le indicazioni fondamentali fornite nei principi di ottimizzazione costi.

A causa dei requisiti di conformità e dei controlli di sicurezza rigorosi, un compromesso chiaro è il costo. È consigliabile stabilire stime iniziali usando il Calcolatore prezzi.

Il diagramma seguente fornisce una rappresentazione generale dell'impatto sui costi delle risorse principali usate da questa architettura:

Diagramma della gestione dei costi nell'architettura.

I driver principali sono i set di scalabilità di macchine virtuali che costituiscono i pool di nodi e Firewall di Azure. Un altro collaboratore è Analisi dei log. Sono inoltre previsti costi incrementali associati a Microsoft Defender per il cloud, a seconda della scelta dei piani.

Avere una chiara comprensione di ciò che costituisce il prezzo di un servizio. Azure tiene traccia dell'utilizzo a consumo. Il diagramma seguente fornisce una suddivisione di Firewall di Azure per questa architettura:

Diagramma che illustra la gestione dei costi in un esempio di Firewall di Azure.

Il costo associato ad alcune risorse, ad esempio Firewall di Azure, può essere distribuito tra più business unit o applicazioni. Un altro modo per ottimizzare i costi potrebbe essere ospitare un cluster multi-tenant all'interno di un'organizzazione, ottimizzando la densità con la diversità dei carichi di lavoro. Tuttavia, non è consigliabile questo approccio per i carichi di lavoro regolamentati. Assegnare sempre priorità alla conformità e alla segmentazione rispetto ai vantaggi dei costi.

Per mantenere i vincoli di budget, alcuni modi per controllare i costi sono modificando l'infrastruttura del gateway applicazione di Azure, impostando il numero di istanze per la scalabilità automatica e riducendo l'output del log purché soddisfino ancora il audit trail richiesto da PCI DSS 4.0.1. Valutare sempre queste scelte rispetto agli altri aspetti della progettazione che consentono di soddisfare il contratto di servizio. Ad esempio, è comunque possibile ridimensionare in modo appropriato per soddisfare i picchi di traffico?

Quando si creano gruppi di risorse di Azure, applicare tag in modo che possano essere monitorati per i costi. Usare strumenti di gestione dei costi come Azure Advisor e Gestione dei costi Microsoft per tenere traccia e analizzare i costi.

Valutare la possibilità di abilitare l'analisi dei costi di AKS per l'allocazione granulare dei costi dell'infrastruttura del cluster da costrutti specifici di Kubernetes.

Eccellenza operativa

Seguire le linee guida fondamentali fornite nei principi di eccellenza operativa. Le sezioni seguenti riepilogano le procedure consigliate per l'eccellenza operativa per un ambiente regolamentato.

Separazione dei ruoli

L'applicazione di una chiara separazione dei compiti per gli ambienti regolamentati è fondamentale. Avere definizioni di ruoli e responsabilità in base alle esigenze del carico di lavoro e all'interazione con l'ambiente CDE. Ad esempio, potrebbe essere necessario un ruolo SRE (Infrastructure Reliability Engineer) per le operazioni correlate al cluster e ai servizi dipendenti. Il ruolo è responsabile della gestione della sicurezza, dell'isolamento, della distribuzione e dell'osservabilità. Formalizzare tali definizioni e decidere le autorizzazioni necessarie per tali ruoli. Ad esempio, le SRE hanno privilegi elevati per l'accesso al cluster, ma richiedono l'accesso in lettura agli spazi dei nomi dei carichi di lavoro.

Isolamento dei carichi di lavoro

PCI DSS 4.0.1 richiede l'isolamento del carico di lavoro PCI da altri carichi di lavoro in termini di operazioni. In questa implementazione, i carichi di lavoro nell'ambito e out-of-scope vengono segmentati in due pool di nodi utente separati. Gli sviluppatori di applicazioni per gli sviluppatori e nell'ambito per carichi di lavoro out-of-scope possono avere set di autorizzazioni diversi. Inoltre, ci saranno controlli di qualità separati. Ad esempio, il codice nell'ambito è soggetto a rispettare la conformità e l'attestazione, mentre il codice non rientra nell'ambito. È anche necessario disporre di pipeline di compilazione e processi di gestione delle versioni separati.

PCI DSS 4.0.1 introduce requisiti completi per lo sviluppo di software sicuro, tra cui:

  • Test di sicurezza automatizzati integrati nelle pipeline CI/CD.
  • Test di sicurezza delle applicazioni statici e dinamici (SAST/DAST).
  • Analisi delle vulnerabilità dell'immagine del contenitore prima della distribuzione.
  • Analisi delle dipendenze per i componenti di terze parti.
  • Processi di revisione del codice con lo stato attivo per la sicurezza.
  • Training di scrittura del codice sicuro per i team di sviluppo.

Metadati operativi

Il requisito 12 dello standard PCI DSS 4.0.1 richiede la gestione delle informazioni sull'inventario dei carichi di lavoro e sulla documentazione sull'accesso al personale. È consigliabile usare i tag di Azure perché è possibile raccogliere informazioni sull'ambiente con risorse, gruppi di risorse e sottoscrizioni di Azure.

Gestire le informazioni sulle soluzioni approvate che fanno parte dell'infrastruttura e del carico di lavoro. Include un elenco di immagini delle VM, database e soluzioni di terze parti preferite dall'utente nell'ambiente CDE. È anche possibile automatizzare il processo creando un catalogo di servizi. Offre la distribuzione self-service usando le soluzioni approvate in una configurazione specifica, che è conforme alle operazioni continue della piattaforma.

Osservabilità

Per soddisfare il Requisito 10, l'osservabilità nell'ambiente CDE è fondamentale per la conformità. I log attività forniscono informazioni sulle operazioni correlate alla gestione di account e segreti, alla gestione delle impostazioni di diagnostica, alla gestione del server e ad altre operazioni di accesso alle risorse. Tutti i log vengono registrati con data, ora, identità e altre informazioni dettagliate. Conserva i log per un massimo di un anno configurando i criteri di conservazione e archiviazione dei dati nei log di Monitoraggio di Azure.

Assicurarsi che i log siano accessibili solo dai ruoli che ne hanno bisogno. Analisi dei log e Microsoft Sentinel supportano vari controlli di accesso in base al ruolo per gestire l'accesso audit trail.

Risposta e correzione

I servizi di monitoraggio di Azure, Monitoraggio di Azure e Microsoft Defender per il cloud, possono generare notifiche o avvisi quando rilevano attività anomale. Questi avvisi includono informazioni sul contesto, ad esempio gravità, stato e tempo di attività. Man mano che vengono generati avvisi, avere una strategia di correzione e rivedere lo stato di avanzamento. È consigliabile centralizzare i dati in una soluzione SIEM (Security Information and Event Management) perché l'integrazione dei dati può fornire un contesto di avviso avanzato.

Dalla vista Avvisi di sicurezza in Microsoft Defender per il cloud, è possibile accedere a tutti gli avvisi rilevati Microsoft Defender per il cloud sulle risorse. Per risolvere il problema, è necessario un processo di valutazione. Collaborare con il team di sicurezza per comprendere in che modo gli avvisi pertinenti verranno resi disponibili ai proprietari del carico di lavoro.

Efficienza delle prestazioni

Seguire le indicazioni fondamentali fornite nei principi di efficienza delle prestazioni. Le sezioni seguenti riepilogano le procedure consigliate per l'efficienza delle prestazioni per un ambiente regolamentato.

Scalabilità

Osservando come l'ambiente si adatta alle richieste mutevoli indicherà il comportamento di runtime previsto dell'ambiente sotto carico elevato. La scalabilità automatica delle risorse nel carico di lavoro ridurrà al minimo l'interazione umana nell'ambiente CDE. Un ulteriore vantaggio di sicurezza riduce sempre la superficie di attacco. È possibile ottimizzare il vantaggio sfruttando le risorse che supportano l'approccio scale-to-zero. Ad esempio, AKS supporta il ridimensionamento dei pool di nodi utente a 0. Per maggiori informazioni, consultare la sezione Ridimensionamento dei pool di nodi utente a 0.

Partizionamento

Il partizionamento è un fattore chiave per l'efficienza delle prestazioni nei carichi di lavoro regolamentati. La presenza di componenti discreti consente una definizione nitida della responsabilità e consente controlli precisi, ad esempio i criteri di rete. Analogamente a qualsiasi strategia di segmentazione, il partizionamento isola i componenti e controlla l'impatto del raggio di esplosione su errori imprevisti o compromissione del sistema.

Architetture di tipo shared-nothing

L'architettura shared-nothing è progettata per rimuovere conflitti tra carichi di lavoro condivisi. Si tratta inoltre di una strategia per rimuovere singoli punti di errore. In un ambiente regolamentato, i componenti devono essere isolati da limiti logici o fisici. In questo modo si allinea all'architettura shared-nothing, con conseguenti vantaggi di scalabilità. Consente di definire la destinazione dei controlli di sicurezza pertinenti e delle funzionalità di controllo più restrittive dei vari componenti.

Carichi di lavoro leggeri

La complessità dei carichi di lavoro è difficile da documentare e controllare. Cercare di semplicità grazie ai vantaggi delle prestazioni e alla facilità di controllo dei requisiti normativi. Riconsiderare le scelte che hanno più ampiezza di quanto necessario, perché aumenta la superficie di attacco e il potenziale di uso improprio o errata configurazione.

Riunire tutto insieme

L'implementazione della conformità PCI DSS 4.0.1 nel servizio Azure Kubernetes richiede un approccio completo che affronti tutti gli aspetti del framework ben progettato rispettando i requisiti specifici dello standard. Questa serie ha fornito indicazioni dettagliate su più domini, dalla sicurezza di rete e dalla protezione dei dati alla gestione delle identità e al monitoraggio continuo.

Punti chiave

Il percorso di conformità a PCI DSS 4.0.1 nel servizio Azure Kubernetes comporta diverse considerazioni critiche:

  • Infrastruttura come base: un'infrastruttura del servizio Azure Kubernetes sicura e conforme è essenziale ma non sufficiente. L'architettura deve supportare i controlli di sicurezza, le funzionalità di monitoraggio e i processi operativi richiesti dallo standard.
  • Conformità continua: a differenza delle versioni precedenti, PCI DSS 4.0.1 enfatizza la convalida e il monitoraggio continui anziché le valutazioni temporizzato. Ciò richiede strumenti automatizzati, avvisi in tempo reale e misure di sicurezza proattive.
  • Responsabilità condivisa: Mentre Azure offre una piattaforma sicura, l'organizzazione rimane responsabile della corretta configurazione e della gestione dei controlli di sicurezza, dell'implementazione dei criteri di accesso appropriati e della conformità in corso.
  • Principi ben strutturati: la sicurezza, l'affidabilità, l'ottimizzazione dei costi, l'eccellenza operativa e l'efficienza delle prestazioni devono tutti essere considerati insieme per creare una soluzione sostenibile e conforme.

Punti di integrazione

I vari componenti illustrati in questa serie interagiscono per creare un framework di conformità completo:

  • La sicurezza di rete costituisce la base per isolare l'ambiente dei dati dei titolari di carte.
  • La protezione dei dati garantisce che chD sia crittografato e gestito correttamente durante il ciclo di vita.
  • La crittografia e la gestione delle chiavi consentono l'archiviazione sicura e la trasmissione di dati sensibili.
  • Gestione delle identità e degli accessi con controlli MFA avanzati che possono accedere all'ambiente cde.
  • La protezione da malware protegge dalle minacce che potrebbero compromettere l'ambiente.
  • Il monitoraggio e la registrazione offrono visibilità su tutte le attività all'interno dell'ambiente cde.
  • Il monitoraggio continuo della sicurezza consente il rilevamento e la risposta delle minacce in tempo reale.
  • I criteri di sicurezza stabiliscono il framework di governance per la conformità in corso.

Passaggi successivi

Per iniziare a implementare la conformità pci DSS 4.0.1 nel servizio Azure Kubernetes, seguire questa procedura consigliata:

Fase 1: Fondazione e pianificazione (settimane 1-4)

  1. Valutare lo stato corrente: valutare l'infrastruttura del servizio Azure Kubernetes esistente rispetto ai requisiti di PCI DSS 4.0.1.
  2. Definire l'ambito: identificare chiaramente i componenti inclusi nell'ambito per la conformità PCI DSS.
  3. Esaminare la guida all'implementazione: Studiare le indicazioni dettagliate fornite in ogni articolo di questa serie.
  4. Pianificare l'architettura: progettare la topologia di rete hub-spoke e i controlli di sicurezza.
  5. Stabilire la governance: definire ruoli, responsabilità e processi di approvazione.

Fase 2: Implementazione dell'infrastruttura (settimane da 5 a 12)

  1. Distribuire l'architettura di riferimento: iniziare con l'architettura di base del servizio Azure Kubernetes e applicare miglioramenti di PCI DSS.
  2. Implementare la sicurezza di rete: configurare cluster privati, firewall e criteri di rete.
  3. Configurare la gestione delle identità: configurare i requisiti di integrazione di Azure AD e MFA.
  4. Distribuire l'infrastruttura di monitoraggio: configurare Monitoraggio di Azure, Log Analytics e Microsoft Defender for Cloud.
  5. Implementare la protezione dei dati: configurare la crittografia dei dati inattivi e in transito.

Fase 3: Sicurezza e conformità (settimane 13-20)

  1. Configurare i criteri di sicurezza: applicare criteri di Azure e criteri Kubernetes per la conformità.
  2. Implementare la gestione delle chiavi: configurare Azure Key Vault e i controlli crittografici.
  3. Distribuire la protezione antimalware: configurare l'analisi della sicurezza e il rilevamento delle minacce.
  4. Stabilire il monitoraggio: implementare il monitoraggio e gli avvisi di sicurezza continui.
  5. Controlli di sicurezza dei test: verificare che tutte le misure di sicurezza funzionino correttamente.

Fase 4: Convalida e manutenzione (settimane 21-24)

  1. Eseguire test di sicurezza: eseguire test di penetrazione e valutazioni delle vulnerabilità.
  2. Convalida conformità: verificare che tutti i requisiti di PCI DSS 4.0.1 siano soddisfatti.
  3. Documentare tutti gli elementi: creare una documentazione completa a scopo di controllo.
  4. Formare il personale: assicurarsi che tutto il personale comprenda i ruoli e le responsabilità.
  5. Stabilire processi in corso: implementare procedure di monitoraggio e manutenzione continue.

Operazioni in corso

Dopo l'implementazione iniziale, mantenere la conformità tramite:

  • Valutazioni regolari della sicurezza: condurre revisioni trimestrali della sicurezza e valutazioni annuali di conformità.
  • Monitoraggio continuo: monitorare tutti i controlli di sicurezza e rispondere tempestivamente agli avvisi.
  • Gestione aggiornamenti: mantenere aggiornati tutti i sistemi e i controlli di sicurezza.
  • Risposta agli eventi imprevisti: gestire e testare le procedure di risposta agli eventi imprevisti.
  • Manutenzione della documentazione: mantenere aggiornata e accessibile tutta la documentazione.

Ottenere assistenza

Per ulteriore supporto nell'implementazione della conformità PCI DSS 4.0.1 nel servizio Azure Kubernetes:

  • Microsoft FastTrack: contattare Microsoft FastTrack per Azure per indicazioni sull'implementazione.
  • Partner Microsoft: collaborare con partner Microsoft certificati specializzati nella conformità.
  • Servizi professionali: è consigliabile coinvolgere servizi professionali per implementazioni complesse.
  • Risorse della community: sfruttare le community di Azure e Kubernetes per le procedure consigliate.

Mantenersi aggiornati

Gli standard PCI DSS si evolvono nel tempo. Rimanere informati sugli aggiornamenti e sulle modifiche:

  • Sottoscrivere le comunicazioni PCI SSC: seguire pci Security Standards Council per gli aggiornamenti.
  • Monitorare gli aggiornamenti di Azure: rimanere aggiornati con le nuove funzionalità e funzionalità di sicurezza di Azure.
  • Interagire con la community: partecipare ai forum di sicurezza e conformità.
  • Formazione regolare: assicurarsi che il team rimanga aggiornato con le procedure consigliate per la sicurezza.

Questa serie fornisce indicazioni complete per implementare la conformità PCI DSS 4.0.1 nel servizio Azure Kubernetes. Per informazioni aggiuntive:

Articoli della serie PCI DSS 4.0.1:

Documentazione di Azure:

Risorse di conformità:

Tenere presente che il raggiungimento e la gestione della conformità PCI DSS 4.0.1 è un processo continuo che richiede un'attenzione continua alla sicurezza, al monitoraggio e all'eccellenza operativa. Le linee guida contenute in questa serie forniscono una base, ma l'implementazione specifica potrebbe richiedere considerazioni aggiuntive in base ai requisiti e all'ambiente specifici.

  • Ultimo aggiornamento: