Proteggere i dati in un cluster regolamentato del servizio Azure Kubernetes per PCI-DSS 3.2.1 (parte 4 di 9)

Questo articolo descrive le considerazioni relative a un cluster servizio Azure Kubernetes (AKS) che esegue un carico di lavoro 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.

Questa architettura e l'implementazione sono incentrate sull'infrastruttura e non sul carico di lavoro. Questo articolo fornisce considerazioni generali e procedure consigliate per prendere decisioni di progettazione. Seguire i requisiti dello standard UFFICIALE PCI-DSS 3.2.1 e usare questo articolo come informazioni aggiuntive, se applicabile.

Proteggere i dati di titolari di schede

Requisito 3: proteggere i dati dei titolari di schede archiviati

Responsabilità

Requisito 3.1

Ridurre al minimo l'archiviazione dei dati di titolari di schede implementando criteri di conservazione ed eliminazione dei dati, procedure e processi che tengano conto di quanto segue per l'archiviazione di tutti i dati di titolari di schede:

• Limitazione dello spazio di archiviazione dei dati e dei periodi di conservazione a quanto obbligatorio per soddisfare requisiti legali, normativi e aziendali
• Processi per l'eliminazione sicura dei dati quando non sono più necessari
• Requisiti specifici per la conservazione dei dati di titolari di carte
• Processo trimestrale per l'identificazione e l'eliminazione sicura dei dati di titolari di carte archiviati una volta trascorso il periodo di conservazione definito.

Responsabilità

Non archiviare lo stato nel cluster di AKS. Se si sceglie di archiviare chD, esplorare le opzioni di archiviazione sicura. Le opzioni includono Archiviazione di Azure per l'archiviazione file o i database, ad esempio database SQL di Azure o Azure Cosmos DB.

Attenersi rigorosamente alle linee guida standard su quale tipo di CHD può essere archiviato. Definire i criteri di conservazione dei dati in base ai requisiti aziendali e al tipo di archiviazione usato. Alcune considerazioni principali sono:

• Come e dove vengono archiviati i dati?
• I dati archiviati vengono crittografati?
• Qual è il periodo di fidelizzazione?
• Quali azioni sono consentite durante il periodo di conservazione?
• Come si eliminano i dati archiviati dopo la scadenza del periodo di conservazione?

Disporre di criteri di governance per alcune di queste scelte. I criteri predefiniti di Azure applicano queste opzioni. Ad esempio, è possibile limitare i tipi di volume nei pod del cluster o negare le operazioni di scrittura nel file system radice.

Esaminare questo elenco di definizioni di criteri e applicarle al cluster, se applicabile.

Potrebbe essere necessario memorizzare temporaneamente nella cache i dati. È consigliabile proteggere i dati memorizzati nella cache mentre vengono spostati in una soluzione di archiviazione. Valutare la possibilità di abilitare la funzionalità di crittografia basata su host in AKS. Verranno crittografati i dati archiviati nelle VM del nodo. Per maggiori informazioni, consultare la sezione Crittografia basata su host nel servizio Azure Kubernetes (AKS). Abilitare anche criteri di Azure predefiniti che richiedono la crittografia dei dischi temporanei e della cache per i pool di nodi.

Quando si sceglie una tecnologia di archiviazione, esplorare le funzionalità di conservazione. Ad esempio, Archiviazione BLOB di Azure fornisce criteri di conservazione basati sul tempo. Un'altra scelta consiste nell'implementare una soluzione personalizzata che elimina i dati in base ai criteri di conservazione. Un esempio è Gestione del ciclo di vita dei dati (DLM), che gestisce le attività del ciclo di vita dei dati. La soluzione è stata progettata con servizi come Azure Data Factory, Microsoft Entra ID e Azure Key Vault.

Per maggiori informazioni, consultare la sezione Gestione del ciclo di vita dei dati con Azure Data Factory.

Requisito 3.2

Non archiviare dati di autenticazione sensibili dopo l'autorizzazione (anche se crittografati). Se si ricevono dati di autenticazione sensibili, rendere irrecuperabili tutti i dati dopo il completamento del processo di autorizzazione.

Responsabilità

(SI APPLICA A: Requisito 3.2.1, Requisito 3.2.2, Requisito 3.2.3)

L'elaborazione e la protezione dei dati sono un problema del carico di lavoro e non rientrano nell'ambito di questa architettura. Ecco alcune considerazioni generali.

In base ai dati di autenticazione sensibili standard, sono costituiti da dati di traccia completi, codice di convalida della scheda o valore e dati PIN. Nell'ambito dell'elaborazione chD, assicurarsi che i dati di autenticazione non siano esposti in origini come:

• Log generati dai pod.
• Routine di gestione delle eccezioni.
• Nomi file.
• Cache.

Come indicazioni generali, i commercianti non dovrebbero archiviare queste informazioni. Se è necessario documentare la motivazione aziendale.

Requisito 3.3

Mascherare il numero PAN in caso di visualizzazione (possono essere visualizzate al massimo le prime sei e le ultime quattro cifre), in modo che solo il personale con un'esigenza professionale legittima possa visualizzare il PAN completo.

Responsabilità

Il numero di account primario (PAN) è considerato dati sensibili e l'esposizione a questi dati deve essere impedita. Un modo consiste nel ridurre le cifre visualizzate tramite mascheramento.

Non implementare la maschera dati nel carico di lavoro. Usare invece costrutti a livello di database. La riga di servizi SQL di Azure, tra cui Azure Synapse Analytics, supporta la maschera dati dinamica, riducendo così l'esposizione a livello di applicazione. Si tratta di una funzionalità di sicurezza basata su criteri che definisce chi può visualizzare i dati non mascherati e la quantità di dati esposti tramite mascheramento. Il metodo di mascheramento integrato Carta di credito espone le ultime quattro cifre dei campi designati e aggiunge una stringa costante come prefisso sotto forma di carta di credito.

Per maggiori informazioni, consultare la sezione Dynamic Data Masking.

Se è necessario inserire dati non mascherati nel cluster, mascherare il prima possibile.

Requisito 3.4

Rendere illeggibile il numero PAN in qualsiasi posizione di archiviazione (inclusi supporti digitali, supporti di backup e log) adottando uno degli approcci seguenti:

• Hash unidirezionali, basati su crittografia avanzata, (l'hashing deve essere applicato all'intero PAN)
• Troncamento (non è possibile usare l'hashing per sostituire il segmento troncato del PAN)
• Token e pad indicizzati (i pad devono essere archiviati in modo sicuro)
• Crittografia avanzata con i processi e le procedure associati per la gestione delle chiavi.

Responsabilità

Per questo requisito, potrebbe essere necessario usare la crittografia diretta nel carico di lavoro. Le linee guida di PCI DSS consigliano l'uso di algoritmi testati dal settore in modo che supportino gli attacchi reali. Evitare di usare algoritmi di crittografia personalizzati.

Anche le tecniche di maschera dati appropriate soddisfano questo requisito. L'utente è responsabile della maschera di tutti i dati PAN (Primary Account Number). La riga di servizi SQL di Azure, tra cui Azure Synapse Analytics, supporta la maschera dati dinamica. Vedere il Requisito 3.3.

Assicurarsi che PAN non sia esposto come parte dei processi del flusso di lavoro. Ecco alcune considerazioni:

• Mantenere PAN fuori dai log, sia i log del flusso di lavoro che i log di gestione delle eccezioni (previsti o imprevisti). Inoltre, i flussi di dati di diagnostica, ad esempio le intestazioni HTTP, non devono esporre questi dati.

• Non usare PAN come chiave di ricerca della cache o come parte di qualsiasi nome file generato da questo processo.

• I clienti potrebbero fornire PAN in campi di testo in formato libero non inoltrati. Assicurarsi che i processi di convalida e rilevamento del contenuto siano applicati per tutti i campi di testo in formato libero, eseguendo lo scrubbing di tutto il contenuto simile ai dati PAN.

Requisito 3.4.1

Se viene usata la crittografia del disco (invece della crittografia del database a livello di file o di colonna), l'accesso logico deve essere gestito separatamente e in modo indipendente dall'autenticazione del sistema operativo e dai meccanismi di controllo di accesso nativi, ad esempio senza usare database degli account utente locali o credenziali di accesso alla rete generali. Le chiavi di decrittografia non devono essere associate ad account utente.

Responsabilità

Come regola generale, non archiviare lo stato nel cluster AKS. Usare un'archiviazione dati esterna che supporta la crittografia a livello di motore di archiviazione.

Tutti i dati archiviati in Archiviazione di Azure vengono crittografati e decrittografati usando la crittografia avanzata. Microsoft gestisce le chiavi associate. Le chiavi di crittografia autogestito sono preferite. Crittografare sempre all'esterno del livello di archiviazione e scrivere solo dati crittografati nel supporto di archiviazione, assicurandosi che le chiavi non siano mai adiacenti al livello di archiviazione.

Con Archiviazione di Azure è anche possibile usare chiavi autogestito. Per maggiori dettagli, consultare la sezione Chiavi gestite dal cliente per la crittografia di archiviazione di Azure.

Sono disponibili funzionalità simili per i database. Per le opzioni SQL di Azure, consultare la sezione Crittografia dati trasparenti SQL di Azure con chiave gestita dal cliente.

Assicurarsi di archiviare le chiavi in un archivio chiavi gestito, ad esempio Azure Key Vault, HSM gestito di Azure o una soluzione di gestione delle chiavi di terze parti.

Se è necessario archiviare temporaneamente i dati, abilitare la funzionalità di crittografia host di AKS per assicurarsi che i dati archiviati nei nodi della VM siano crittografati.

Requisito 3.5

Documentare e implementare procedure per proteggere le chiavi usate per proteggere i dati di titolari di schede archiviati dalla divulgazione o da usi impropri.

Responsabilità

Questi punti sono descritti nelle sottosezioni:

• Mantenere la pratica dell'accesso con privilegi minimi per le chiavi crittografiche.
• Azure Key Vault e Microsoft Entra ID sono progettati per supportare i requisiti di autorizzazione e registrazione di controllo. Per i dettagli, consultare la sezione Richiesta di autenticazione per Azure Key Vault.
• Proteggere tutte le chiavi di crittografia dei dati con una chiave di crittografia della chiave archiviata in un dispositivo di crittografia.
• Se si usano chiavi autogestito (anziché chiavi gestite da Microsoft), è disponibile un processo e una documentazione per la gestione delle attività correlate alla gestione delle chiavi.

Requisito 3.5.1

Requisito aggiuntivo solo per i provider di servizi: mantenere aggiornata una descrizione documentata dell'architettura crittografica che include:

• Dettagli di tutti gli algoritmi, i protocolli e le chiavi usati per la protezione dei dati di titolari di carte, incluse forza della chiave e data di scadenza
• Descrizione dell'utilizzo per ogni chiave
• Inventario di tutti i moduli di protezione hardware di altri dispositivi crittografici sicuri usati per la gestione delle chiavi

Responsabilità

Un modo per archiviare informazioni riservate (chiavi, stringa di connessione e altri) consiste nell'usare la risorsa Kubernetes nativa Secret. È necessario abilitare in modo esplicito la crittografia dei dati inattivi. In alternativa, archiviarli in un archivio gestito, ad esempio Azure Key Vault. Tra i due approcci, è consigliabile usare un servizio di archiviazione gestito. Un vantaggio è la riduzione del sovraccarico nelle attività correlate alla gestione delle chiavi, ad esempio la rotazione delle chiavi.

Per impostazione predefinita, Azure usa chiavi gestite da Microsoft per tutti i dati crittografati, per ogni cliente. Tuttavia, alcuni servizi supportano anche chiavi autogestito per la crittografia. Se si usano chiavi self-managed per la crittografia dei dati inattivi, assicurarsi di tenere conto di un processo e di una strategia che gestisce le attività di gestione delle chiavi.

Come parte della documentazione, includere informazioni relative alla gestione delle chiavi, ad esempio scadenza, posizione e dettagli del piano di manutenzione.

Requisito 3.5.2

Limitare l'accesso alle chiavi crittografiche al minor numero di custodi necessari.

Responsabilità

Ridurre al minimo il numero di persone che hanno accesso alle chiavi. Se si usano assegnazioni di ruolo basate su gruppi, configurare un processo di controllo ricorrente per esaminare i ruoli che hanno accesso. Quando i membri del team di progetto cambiano, gli account che non sono più rilevanti devono essere rimossi dalle autorizzazioni. Solo le persone giuste devono avere accesso. Usare le verifiche di accesso di Microsoft Entra ID per esaminare regolarmente le appartenenze ai gruppi.

Prendere in considerazione la rimozione delle autorizzazioni permanenti a favore delle assegnazioni di ruolo JIT (JUSTT), dell'attivazione dei ruoli basata sul tempo e dell'attivazione dei ruoli basata sull'approvazione. Si consideri, ad esempio, l'uso di Privileged Identity Management.

Requisito 3.5.3

Archiviare i segreti e le chiavi private usati per crittografare/decrittografare sempre i dati di titolari di schede in una o più delle forme seguenti:

• Crittografati con una chiave di crittografia della chiave che abbia almeno la stessa forza della chiave di crittografia dei dati e sia archiviata separatamente dalla chiave di crittografia dei dati
• All'interno di un dispositivo crittografico sicuro, ad esempio, un modulo di protezione hardware (host) o un dispositivo di punto di interazione approvato PTS
• Almeno come due componenti o condivisioni di chiavi a lunghezza integrale, in conformità a un metodo accettato nel settore

Responsabilità

Un carico di lavoro PCI-DSS 3.2.1 dovrà usare più di una chiave di crittografia come parte della strategia di protezione dei dati inattivi. Una chiave DEK (Data Encryption Key) viene usata per crittografare e decrittografare il chD, ma si è responsabili di una chiave di crittografia della chiave aggiuntiva (KEK) per proteggere tale chiave DEK. Si è anche responsabili della verifica dell'archiviazione di KEK in un dispositivo di crittografia.

È possibile usare Azure Key Vault per archiviare la chiave DEK e usare HSM dedicato di Azure per archiviare la chiave di crittografia della chiave. Per informazioni sulla gestione delle chiavi del modulo di protezione hardware, consultare la sezione Informazioni su HSM dedicato di Azure.

Requisito 3.6

Documentare e implementare completamente tutti i processi e le procedure di gestione delle chiavi crittografiche usate per la crittografia dei dati di titolari di schede, incluso quanto segue:

Responsabilità

(SI APPLICA A: Requisito 3.6.1, Requisito 3.6.2, Requisito 3.6.3, Requisito 3.2.4)

Se si usa Azure Key Vault per archiviare segreti come chiavi, certificati e stringa di connessione, proteggerli dall'accesso non autorizzato. Microsoft Defender per Key Vault rileva tentativi di accesso sospetti e genera avvisi. È possibile visualizzare questi avvisi in Microsoft Defender per il cloud. Per maggiori informazioni, consultare la sezione Microsoft Defender per Key Vault.

Seguire le linee guida NIST sulla gestione delle chiavi. Per informazioni dettagliate, vedere:

• Gestione delle chiavi crittografiche.
• SP 800-133 Rev. 2, Raccomandazione per la generazione di chiavi crittografiche
• SP 800-57 Parte 1 Rev. 5, Raccomandazione per la gestione delle chiavi

Consultare anche la sezione Microsoft Defender per Key Vault.

Requisito 3.6.7

Prevenzione dei tentativi di sostituzione non autorizzata delle chiavi crittografiche.

Responsabilità

• Abilitare la diagnostica in tutti gli archivi chiavi. Usare Monitoraggio di Azure per Key Vault. Raccoglie log e metriche e li invia a Monitoraggio di Azure. Per maggiori informazioni, consultare la sezione Monitoraggio del servizio Key Vault con Monitoraggio di Azure per Key Vault.
• Concedere autorizzazioni di sola lettura a tutti i consumer.
• Non disporre delle autorizzazioni permanenti per gli utenti o le entità di gestione. Usare piuttosto le assegnazioni di ruolo just-in-time (JIT), nonché l'attivazione del ruolo basata sul tempo e sull'approvazione.
• Creare una visualizzazione centralizzata integrando log e avvisi in soluzioni SIEM (Security Information and Event Management), ad esempio Microsoft Sentinel.
• Intervenire sugli avvisi e sulle notifiche, soprattutto in caso di modifiche impreviste.

Requisito 3.6.8

Requisito per i custodi delle chiavi crittografiche di riconoscere in modo formale che accettano e confermano di conoscere le proprie responsabilità.

Responsabilità

Gestire la documentazione che descrive le responsabilità delle parti responsabili nelle operazioni di gestione delle chiavi.

Requisito 3.7

Assicurarsi che i criteri di sicurezza e le procedure operative per la protezione dei dati di titolari di schede archiviati siano documentati, applicati e noti a tutte le parti interessate.

Responsabilità

Creare la documentazione come istruzione generale e una serie di guide ai ruoli aggiornate per tutti gli utenti. Eseguire corsi di formazione e formazione in corso.

È fondamentale mantenere una documentazione completa sui processi e sui criteri. Diversi team partecipano per assicurarsi che i dati siano protetti inattivi e in transito. Nella documentazione specificare indicazioni sui ruoli per tutti gli utenti. I ruoli devono includere SRE, supporto clienti, vendite, operazioni di rete, operazioni di sicurezza, ingegneri software, amministratori di database e altri. Il personale deve essere formato in linee guida NIST e strategie di dati inattivi per mantenere aggiornato il set di competenze. I requisiti di formazione vengono risolti nel Requisito 6.5 e nel Requisito 12.6.

Requisito 4—Crittografare la trasmissione dei dati di titolari di schede su reti pubbliche aperte

Responsabilità

Requisito 4.1

Usare la crittografia avanzata e i protocolli di sicurezza (ad esempio, TLS, IPSec, SSH e così via) per proteggere i dati sensibili dei titolari di schede quando vengono trasmessi su reti pubbliche aperte, incluso quando:

Responsabilità

I dati dei titolari di schede (CHD) che transitino su Internet pubblico devono essere crittografati. I dati devono essere crittografati con TLS 1.2 (o versione successiva), con supporto di crittografia ridotto per tutte le trasmissioni. Non supportare reindirizzamenti non TLS a TLS in alcun servizio di trasmissione dati.

La progettazione deve avere una catena strategica di punti di terminazione TLS. Man mano che i dati passano attraverso hop di rete, mantenere TLS a hop che richiedono l'ispezione dei pacchetti. Almeno, avere il punto di terminazione TLS finale nella risorsa di ingresso del cluster. Prendere in considerazione l'ulteriore approfondimento all'interno delle risorse del cluster.

Usare Criteri di Azure per gestire la creazione delle risorse:

• Negare la creazione di qualsiasi risorsa di ingresso non HTTPS.
• Negare la creazione di qualsiasi indirizzo IP pubblico o di qualsiasi servizio di bilanciamento del carico pubblico nel cluster, per assicurarsi che il traffico Web venga sottoposto a tunneling attraverso il gateway.

Per maggiori informazioni, consultare la sezione Panoramica di crittografia di Azure.

Requisito 4.1.1

Garantire che le reti wireless che trasmettono i dati dei titolari di schede o che sono connesse all'ambiente dei dati dei titolari di schede usino le procedure consigliate del settore (ad esempio, IEEE 802.11i) per implementare la crittografia avanzata per l'autenticazione e la trasmissione.

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 4.2

Non inviare mai PAN non protetti tramite le tecnologie di messaggistica degli utenti finali (ad esempio, posta elettronica, messaggistica istantanea, SMS, chat e così via).

Responsabilità

Se il carico di lavoro richiede l'invio di messaggi di posta elettronica, prendere in considerazione la creazione di un gate di quarantena della posta elettronica. Questa convalida consente di analizzare tutti i messaggi in uscita per verificare la conformità e verificare che i dati sensibili non siano inclusi. Idealmente, è consigliabile considerare anche questo approccio per i messaggi di supporto tecnico.

La convalida deve essere eseguita a livello di carico di lavoro e il processo di controllo delle modifiche. I controlli di approvazione devono comprendere il requisito.

Per le considerazioni, consultare le linee guida nello standard ufficiale PCI-DSS 3.2.1.

Requisito 4.3

Assicurarsi che i criteri di sicurezza e le procedure operative per la crittografia delle trasmissioni dei dati di titolari di schede siano documentati, applicati e noti a tutte le parti interessate.

Responsabilità

È fondamentale mantenere una documentazione completa sui processi e sui criteri. Ciò vale soprattutto quando si gestiscono i criteri relativi a Transport Layer Security (TLS). Di seguito sono elencate alcune aree:

• Punti di ingresso Internet pubblici. Un esempio è il supporto Gateway applicazione di Azure per le crittografie TLS.
• Hop di rete tra la rete perimetrale e i pod del carico di lavoro.
• Crittografia da pod a pod (se implementata). Ciò può includere informazioni dettagliate sulla configurazione di una mesh di servizi.
• Eseguire il pod nell'archiviazione (se parte dell'architettura).
• Eseguire il pod a servizi esterni, servizi PaaS di Azure che usano TLS, un gateway di pagamento o un sistema di rilevamento delle frodi.

Le persone che operano in ambienti regolamentati devono essere istruite, informate e incoraggiate a sostenere le garanzie di sicurezza. Questo è particolarmente importante per le persone che fanno parte del processo di approvazione dal punto di vista dei criteri.

Passaggi successivi

Proteggere tutti i sistemi da malware e aggiornare regolarmente il software o i programmi antivirus. Sviluppare e gestire sistemi e applicazioni sicuri.