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 del servizio Azure Kubernetes (servizio Azure Kubernetes) che esegue un carico di lavoro in conformità allo standard Di sicurezza dei dati del settore delle carte di pagamento (PCI-DSS 3.2.1).

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 carte

Requisito 3: proteggere i dati dei titolari di carte archiviati

Responsabilità dell'utente

Requisito 4: crittografare la trasmissione dei dati dei titolari di carte tra reti pubbliche aperte.

Responsabilità dell'utente

Requisito 3.1

Mantenere l'archiviazione dei dati dei titolari di carte almeno implementando criteri di conservazione e eliminazione dei dati, procedure e processi che includono almeno quanto segue per tutte le risorse di archiviazione dei dati dei titolari di carte:

• 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à dell'utente

Non archiviare lo stato nel cluster del servizio Azure Kubernetes. 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. Di seguito sono riportate alcune considerazioni chiave:

• Come e dove vengono archiviati i dati?
• I dati archiviati sono crittografati?
• Qual è il periodo di conservazione?
• 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 nel servizio Azure Kubernetes. Verranno crittografati i dati archiviati nelle macchine virtuali del nodo. Per altre informazioni, vedere Crittografia basata su host in servizio Azure Kubernetes (servizio Azure Kubernetes). 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 è Data Lifecycle Management (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 altre informazioni, vedere Gestione del ciclo di vita dei dati con Azure Data Factory.

Requisito 3.2

Non archiviare i 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à dell'utente

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

L'elaborazione e la protezione dei dati esula dall'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 di file.
• Cache.

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

Requisito 3.3

Maschera PAN quando viene visualizzata (le prime sei e le ultime quattro cifre sono il numero massimo di cifre da visualizzare), in modo che solo il personale con un'esigenza aziendale legittima possa vedere il PAN completo.

Responsabilità dell'utente

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 maschera carta di credito predefinito espone le ultime quattro cifre dei campi designati e aggiunge una stringa costante come prefisso sotto forma di carta di credito.

Per altre informazioni, vedere Maschera dati dinamica.

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

Requisito 3.4

Eseguire il rendering di PAN illeggibile ovunque sia archiviato (inclusi supporti digitali portatili, supporti di backup e nei log) usando 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à dell'utente

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 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 (anziché la crittografia del database a livello di file o di colonna), l'accesso logico deve essere gestito separatamente e indipendentemente dai meccanismi di autenticazione e controllo di accesso del sistema operativo nativo (ad esempio, non usando i database dell'account utente locale o le credenziali di accesso di rete generali). Le chiavi di decrittografia non devono essere associate ad account utente.

Responsabilità dell'utente

Come regola generale, non archiviare lo stato nel cluster del servizio Azure Kubernetes. 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 informazioni dettagliate, vedere Chiavi gestite dal cliente per la crittografia Archiviazione di Azure.

Sono disponibili funzionalità simili per i database. Per le opzioni sql di Azure, vedere Azure SQL Transparent Data Encryption con chiave gestita dal cliente.

Assicurarsi di archiviare le chiavi in un archivio chiavi gestito (Azure Key Vault, Azure Key Vault Managed Hardware Security Module (HSM) e altri.

Se è necessario archiviare temporaneamente i dati, abilitare la funzionalità di crittografia host del servizio Azure Kubernetes per assicurarsi che i dati archiviati nei nodi della macchina virtuale siano crittografati.

Requisito 3.5

Documentare e implementare procedure per proteggere le chiavi usate per proteggere i dati dei titolari di carte archiviati dalla divulgazione e dall'uso improprio:

Responsabilità dell'utente

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 informazioni dettagliate, vedere Richiedere l'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 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à dell'utente

Un modo per archiviare informazioni riservate (chiavi, stringa di connessione e altri) consiste nell'usare la risorsa Kubernetes Secret nativa. È 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 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 responsabili necessari.

Responsabilità dell'utente

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

Requisito 3.5.3

Archiviare chiavi private e segrete usate per crittografare/decrittografare i dati dei titolari di carte in uno o più dei moduli seguenti in qualsiasi momento:

• 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à dell'utente

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 della chiave di crittografia 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, vedere Informazioni su HSM dedicato di Azure.

Requisito 3.6

Documentare e implementare completamente tutti i processi e le procedure di gestione delle chiavi per le chiavi crittografiche usate per la crittografia dei dati dei titolari di carte, inclusi i seguenti:

Responsabilità dell'utente

(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 altre informazioni, vedere Microsoft Defender per Key Vault.

Seguire le indicazioni 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

Vedere anche Microsoft Defender per Key Vault.

Requisito 3.6.7

Prevenzione della sostituzione non autorizzata delle chiavi crittografiche.

Responsabilità dell'utente

• 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 altre informazioni, vedere 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 tutte le entità servizio di gestione. Usare invece le assegnazioni di ruolo JIT (Just-In-Time), l'attivazione dei ruoli basata sul tempo e l'attivazione dei ruoli basata 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 responsabili della chiave crittografica di riconoscere formalmente che comprendono e accettano le responsabilità del responsabile della chiave.

Responsabilità dell'utente

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 dei titolari di carte archiviati siano documentati, in uso e noti a tutte le parti interessate.

Responsabilità dell'utente

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 i 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.1

Usare protocolli di crittografia e sicurezza sicuri (ad esempio TLS, IPSEC, SSH e così via) per proteggere i dati sensibili dei titolari di carte durante la trasmissione su reti pubbliche aperte, tra cui:

Responsabilità dell'utente

I dati dei titolari di carte (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 di 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 altre informazioni, vedere Panoramica della crittografia di Azure.

Requisito 4.1.1

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

Responsabilità dell'utente

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

Requisito 4.2

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

Responsabilità dell'utente

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 considerazioni, vedere le linee guida contenute nello standard PCI-DSS 3.2.1 ufficiale.

Requisito 4.3

Assicurarsi che i criteri di sicurezza e le procedure operative per crittografare le trasmissioni dei dati dei titolari di carte siano documentati, in uso e noti a tutte le parti interessate.

Responsabilità dell'utente

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

• Punti di ingresso Internet pubblici. Un esempio è il supporto app Azure lication Gateway 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. Ciò è 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 software o programmi antivirus. Sviluppare e gestire sistemi e applicazioni sicuri.