Condividi tramite

Controllo di sicurezza: protezione dei dati

  • Articolo

La protezione dei dati copre il controllo della protezione dei dati inattivi, in transito e tramite meccanismi di accesso autorizzati, tra cui individuare, classificare, proteggere e monitorare gli asset di dati sensibili usando il controllo di accesso, la crittografia, la gestione delle chiavi e la gestione dei certificati.|

DP-1: Individuare, classificare ed etichettare i dati sensibili

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
3.2, 3.7, 3.13 RA-2, SC-28 A3.2

Principio di sicurezza: stabilire e gestire un inventario dei dati sensibili, in base all'ambito dei dati sensibili definito. Usare gli strumenti per individuare, classificare ed etichettare i dati sensibili nell'ambito.

Indicazioni su Azure: usare strumenti come Microsoft Purview, che combina le soluzioni di conformità di Azure Purview e Microsoft 365 e l'individuazione e la classificazione dei dati SQL di Azure per analizzare, classificare ed etichettare centralmente i dati sensibili che risiedono in Azure, in locale, Microsoft 365 e in altre posizioni.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: replicare i dati da varie origini in un bucket di archiviazione S3 e usare AWS Macie per analizzare, classificare ed etichettare i dati sensibili archiviati nel bucket. AWS Macie può rilevare dati sensibili, ad esempio credenziali di sicurezza, informazioni finanziarie, dati PHI e PII o altri modelli di dati basati sulle regole di identificatore dei dati personalizzate.

È anche possibile usare il connettore di analisi multi-cloud di Azure Purview per analizzare, classificare ed etichettare i dati sensibili che risiedono in un bucket di archiviazione S3.

Nota: è anche possibile usare soluzioni aziendali di terze parti dal marketplace AWS allo scopo di classificare ed etichettare i dati.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni per GCP: usare strumenti come Google Cloud Data Loss Prevention per analizzare, classificare ed etichettare centralmente i dati sensibili che risiedono negli ambienti GCP e locali.

Inoltre, usare Google Cloud Data Catalog per usare i risultati di un'analisi DLP (Cloud Data Loss Prevention) per identificare i dati sensibili con i modelli di tag definiti.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-2: Monitorare anomalie e minacce destinate ai dati sensibili

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
3,13 AC-4, SI-4 A3.2

Principio di sicurezza: monitorare le anomalie relative ai dati sensibili, ad esempio il trasferimento non autorizzato dei dati in posizioni esterne alla visibilità e al controllo dell'organizzazione. Ciò comporta in genere il monitoraggio di attività anomale (trasferimenti insoliti o di grandi quantità di dati) che potrebbero indicare un'esfiltrazione di dati non autorizzata.

Indicazioni su Azure: usare Azure Information Protection (AIP) per monitorare i dati classificati ed etichettati.

Usare Microsoft Defender per Archiviazione, Microsoft Defender per SQL, Microsoft Defender per database relazionali open source e Microsoft Defender per Cosmos DB per avvisare il trasferimento anomalo di informazioni che potrebbero indicare trasferimenti non autorizzati di informazioni sensibili.

Nota: se necessario per la conformità della prevenzione della perdita dei dati (DLP), è possibile usare una soluzione DLP basata su host da Azure Marketplace o una soluzione DLP di Microsoft 365 per applicare controlli detective e/o preventivi per impedire l'esfiltrazione dei dati.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare AWS Macie per monitorare i dati classificati ed etichettati e usare GuardDuty per rilevare attività anomale in alcune risorse (S3, EC2 o Kubernetes o risorse IAM). I risultati e gli avvisi possono essere valutati, analizzati e monitorati tramite EventBridge e inoltrati a Microsoft Sentinel o all'hub di sicurezza per l'aggregazione e il rilevamento degli eventi imprevisti.

È anche possibile connettere gli account AWS a Microsoft Defender per il cloud per i controlli di conformità, la sicurezza dei contenitori e le funzionalità di sicurezza degli endpoint.

Nota: se necessario per la conformità della prevenzione della perdita dei dati (DLP), è possibile usare una soluzione DLP basata su host da AWS Marketplace.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni per GCP: usare il Centro comandi di Google Cloud Security/Rilevamento minacce eventi/Rilevamento anomalie per avvisare il trasferimento anomalo di informazioni che potrebbero indicare trasferimenti non autorizzati di informazioni riservate.

È anche possibile connettere gli account GCP a Microsoft Defender per il cloud per i controlli di conformità, la sicurezza dei contenitori e le funzionalità di sicurezza degli endpoint.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-3: Crittografare i dati sensibili in movimento

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
3.10 SC-8 3.5, 3.6, 4.1

Principio di sicurezza: proteggere i dati in transito da attacchi "fuori banda", ad esempio l'acquisizione del traffico, usando la crittografia per garantire che gli utenti malintenzionati non possano leggere o modificare facilmente i dati.

Impostare il limite di rete e l'ambito del servizio in cui la crittografia dei dati in transito è obbligatoria all'interno e all'esterno della rete. Sebbene ciò sia facoltativo per il traffico nelle reti private, è fondamentale per il traffico nelle reti esterne e pubbliche.

Linee guida di Azure: applicare il trasferimento sicuro nei servizi, ad esempio Archiviazione di Azure, in cui è incorporata una funzionalità nativa di crittografia dei dati in transito.

Applicare HTTPS per i carichi di lavoro e i servizi delle applicazioni Web assicurandosi che tutti i client che si connettono alle risorse di Azure usino tls (Transport Layer Security) v1.2 o versione successiva. Per la gestione remota delle macchine virtuali, usare SSH (per Linux) o RDP/TLS (per Windows) anziché un protocollo non crittografato.

Per la gestione remota delle macchine virtuali di Azure, usare SSH (per Linux) o RDP/TLS (per Windows) anziché un protocollo non crittografato. Per il trasferimento sicuro dei file, usare il servizio SFTP/FTPS in Archiviazione di Azure BLOB, servizio app app e app per le funzioni, anziché usare il normale servizio FTP.

Nota: la crittografia dei dati in transito è abilitata per tutto il traffico di Azure in viaggio tra data center di Azure. TLS v1.2 o versione successiva è abilitato per la maggior parte dei servizi di Azure per impostazione predefinita. Alcuni servizi, ad esempio Archiviazione di Azure e gateway applicazione, possono applicare TLS v1.2 o versione successiva sul lato server.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: applicare il trasferimento sicuro in servizi come Amazon S3, RDS e CloudFront, in cui è incorporata una funzionalità nativa di crittografia dei dati in transito.

Applicare HTTPS (ad esempio in AWS Elastic Load Balancer) per applicazioni Web e servizi del carico di lavoro (sul lato server o sul lato client o su entrambi) assicurandosi che tutti i client che si connettono alle risorse AWS usino TLS v1.2 o versione successiva.

Per la gestione remota di istanze EC2, usare SSH (per Linux) o RDP/TLS (per Windows) anziché un protocollo non crittografato. Per il trasferimento sicuro dei file, usare il servizio AWS Transfer SFTP o FTPS anziché un normale servizio FTP.

Nota: tutto il traffico di rete tra data center AWS viene crittografato in modo trasparente a livello fisico. Tutto il traffico all'interno di un VPC e tra reti virtuali con peering tra aree geografiche viene crittografato in modo trasparente a livello di rete quando si usano tipi di istanza di Amazon EC2 supportati. TLS v1.2 o versione successiva è abilitato per la maggior parte dei servizi AWS per impostazione predefinita. Alcuni servizi, ad esempio AWS Load Balancer, possono applicare TLS v1.2 o versione successiva sul lato server.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni per GCP: applicare il trasferimento sicuro nei servizi come Google Cloud Storage, in cui è incorporata una funzionalità nativa di crittografia dei dati in transito.

Applicare HTTPS per i carichi di lavoro e i servizi delle applicazioni Web per garantire che tutti i client che si connettono alle risorse GCP usino tls (Transport Layer Security) v1.2 o versione successiva.

Per la gestione remota Google Cloud Compute Engine usare SSH (per Linux) o RDP/TLS (per Windows) anziché un protocollo non crittografato. Per il trasferimento sicuro dei file, usare il servizio SFTP/FTPS in servizi come Google Cloud Big Query o Cloud App Engine anziché un normale servizio FTP.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-4: Abilitare la crittografia dei dati inattivi per impostazione predefinita

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
3.11 SC-28 3.4, 3.5

Principio di sicurezza: per integrare i controlli di accesso, i dati inattivi devono essere protetti da attacchi "fuori banda", ad esempio l'accesso all'archiviazione sottostante, usando la crittografia. Ciò consente di garantire che gli utenti malintenzionati non possano leggere o modificare facilmente i dati.

Linee guida di Azure: molti servizi di Azure hanno la crittografia dei dati inattivi abilitata per impostazione predefinita a livello di infrastruttura usando una chiave gestita dal servizio. Queste chiavi gestite dal servizio vengono generate per conto del cliente e ruotate automaticamente ogni due anni.

Se tecnicamente fattibile e non abilitato per impostazione predefinita, è possibile abilitare la crittografia dei dati inattivi nei servizi di Azure o nelle macchine virtuali a livello di archiviazione, a livello di file o di database.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: molti servizi AWS hanno la crittografia dei dati inattivi abilitata per impostazione predefinita a livello di infrastruttura/piattaforma usando una chiave master del cliente gestita da AWS. Queste chiavi master del cliente gestite da AWS vengono generate per conto del cliente e ruotate automaticamente ogni tre anni.

Se tecnicamente fattibile e non abilitato per impostazione predefinita, è possibile abilitare la crittografia dei dati inattivi nei servizi AWS o nelle macchine virtuali a livello di archiviazione, a livello di file o di database.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: molti prodotti e servizi Google Cloud hanno la crittografia dei dati inattivi abilitata per impostazione predefinita a livello di infrastruttura usando una chiave gestita dal servizio. Queste chiavi gestite del servizio vengono generate per conto del cliente e ruotate automaticamente.

Se tecnicamente fattibile e non abilitato per impostazione predefinita, è possibile abilitare la crittografia dei dati inattivi nei servizi GCP o nelle macchine virtuali a livello di archiviazione, a livello di file o di database.

Nota: fare riferimento al documento "Granularità della crittografia per i servizi Google Cloud" per altri dettagli.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-5: Usare l'opzione della chiave gestita dal cliente nella crittografia dei dati inattivi quando necessario

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
3.11 SC-12, SC-28 3.4, 3.5, 3.6

Principio di sicurezza: se necessario per la conformità alle normative, definire il caso d'uso e l'ambito del servizio in cui è necessaria l'opzione chiave gestita dal cliente. Abilitare e implementare la crittografia dei dati inattivi usando chiavi gestite dal cliente nei servizi.

Indicazioni su Azure: Azure offre anche un'opzione di crittografia usando chiavi gestite da se stessi (chiavi gestite dal cliente) per la maggior parte dei servizi.

Azure Key Vault Standard, Premium e HSM gestito sono integrati in modo nativo con molti servizi di Azure per i casi d'uso delle chiavi gestite dal cliente. È possibile usare Azure Key Vault per generare la chiave o usare chiavi personalizzate.

Tuttavia, l'uso dell'opzione chiave gestita dal cliente richiede ulteriori sforzi operativi per gestire il ciclo di vita delle chiavi. Ciò può includere la generazione della chiave di crittografia, la rotazione, la revoca e il controllo di accesso e così via.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: AWS offre anche un'opzione di crittografia che usa chiavi gestite da se stessi (chiave master del cliente gestita dal cliente archiviata in AWS Servizio di gestione delle chiavi) per determinati servizi.

AWS Servizio di gestione delle chiavi (KMS) è integrato in modo nativo con molti servizi AWS per i casi d'uso delle chiavi master del cliente gestite dal cliente. È possibile usare AWS Servizio di gestione delle chiavi (KMS) per generare le chiavi master o usare chiavi personalizzate.

Tuttavia, l'uso dell'opzione chiave gestita dal cliente richiede ulteriori sforzi operativi per gestire il ciclo di vita delle chiavi. Ciò può includere la generazione della chiave di crittografia, la rotazione, la revoca e il controllo di accesso e così via.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni per GCP: Google Cloud offre un'opzione di crittografia che usa chiavi gestite da se stessi (chiavi gestite dal cliente) per la maggior parte dei servizi.

Google Cloud Servizio di gestione delle chiavi (Cloud KMS) è integrato in modo nativo con molti servizi GCP per le chiavi di crittografia gestite dal cliente. Queste chiavi possono essere create e gestite usando il Servizio di gestione delle chiavi cloud e le chiavi vengono archiviate come chiavi software, in un cluster HSM o esternamente. È possibile usare il Servizio di gestione delle chiavi cloud per generare la chiave o fornire chiavi personalizzate (chiavi di crittografia fornite dal cliente).

Tuttavia, l'uso dell'opzione chiave gestita dal cliente richiede ulteriori sforzi operativi per gestire il ciclo di vita delle chiavi. Ciò può includere la generazione della chiave di crittografia, la rotazione, la revoca e il controllo di accesso e così via.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-6: Usare un processo di gestione delle chiavi sicure

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-28 3.6

Principio di sicurezza: documentare e implementare uno standard, processi e procedure di gestione delle chiavi crittografiche aziendali per controllare il ciclo di vita delle chiavi. Quando è necessario usare la chiave gestita dal cliente nei servizi, usare un servizio di insieme di credenziali delle chiavi protetto per la generazione, la distribuzione e l'archiviazione delle chiavi. Ruotare e revocare le chiavi in base alla pianificazione definita e in caso di ritiro o compromissione della chiave.

Linee guida di Azure: usare Azure Key Vault per creare e controllare il ciclo di vita delle chiavi di crittografia, tra cui generazione, distribuzione e archiviazione delle chiavi di crittografia. Ruotare e revocare le chiavi in Azure Key Vault e il servizio in base alla pianificazione definita e in caso di ritiro o compromissione della chiave. Richiedere un determinato tipo di crittografia e dimensioni minime della chiave durante la generazione di chiavi.

Quando è necessario usare la chiave gestita dal cliente (CMK) nei servizi o nelle applicazioni del carico di lavoro, assicurarsi di seguire le procedure consigliate:

  • Usare una gerarchia di chiavi per generare una chiave DEK separata con la chiave di crittografia della chiave (KEK) nell'insieme di credenziali delle chiavi.
  • Assicurarsi che le chiavi siano registrate con Azure Key Vault e implementate tramite ID chiave in ogni servizio o applicazione.

Per ottimizzare la durata e la portabilità del materiale della chiave, usare la propria chiave (BYOK) ai servizi , ad esempio importando chiavi protette dal modulo di protezione hardware dai moduli di protezione hardware locali in Azure Key Vault. Seguire le linee guida consigliate per eseguire la generazione e il trasferimento delle chiavi.

Nota: vedere quanto segue per il livello FIPS 140-2 per i tipi di Azure Key Vault e il livello di conformità/convalida FIPS.

  • Chiavi protette da software negli insiemi di credenziali (SKU Premium e Standard): FIPS 140-2 Livello 1
  • Chiavi protette dal modulo di protezione hardware negli insiemi di credenziali (SKU Premium): FIPS 140-2 Livello 2
  • Chiavi protette dal modulo di protezione hardware in HSM gestito: FIPS 140-2 Livello 3

Azure Key Vault Premium usa un'infrastruttura HSM condivisa nel back-end. Il modulo di protezione hardware gestito di Azure Key Vault usa endpoint di servizio riservati dedicati con un modulo di protezione hardware dedicato per quando è necessario un livello superiore di sicurezza delle chiavi.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare AWS Servizio di gestione delle chiavi (KMS) per creare e controllare il ciclo di vita delle chiavi di crittografia, tra cui generazione di chiavi, distribuzione e archiviazione. Ruotare e revocare le chiavi nel Servizio di gestione delle chiavi e nel servizio in base alla pianificazione definita e in caso di ritiro o compromissione della chiave.

Quando è necessario usare la chiave master del cliente gestita dal cliente nei servizi o nelle applicazioni del carico di lavoro, assicurarsi di seguire le procedure consigliate:

  • Usare una gerarchia di chiavi per generare una chiave DEK (Data Encryption Key) separata con la chiave di crittografia della chiave (KEK) nel Servizio di gestione delle chiavi.
  • Assicurarsi che le chiavi siano registrate con il Servizio di gestione delle chiavi e implementare tramite i criteri IAM in ogni servizio o applicazione.

Per ottimizzare la durata e la portabilità del materiale della chiave, usare la propria chiave (BYOK) ai servizi (ad esempio importando chiavi protette dal modulo di protezione hardware dai moduli di protezione hardware locali nel servizio di gestione delle chiavi o nel modulo di protezione hardware cloud). Seguire le linee guida consigliate per eseguire la generazione e il trasferimento delle chiavi.

Nota: AWS KMS usa l'infrastruttura del modulo di protezione hardware condiviso nel back-end. Usare l'archivio chiavi personalizzato del Servizio di gestione delle chiavi AWS supportato da AWS CloudHSM quando è necessario gestire il proprio archivio chiavi e moduli di protezione hardware dedicati (ad esempio, i requisiti di conformità alle normative per un livello superiore di sicurezza delle chiavi) per generare e archiviare le chiavi di crittografia.

Nota: vedere quanto segue per il livello FIPS 140-2 per il livello di conformità FIPS in AWS KMS e CloudHSM:

  • AWS KMS predefinito: convalidato FIPS 140-2 Livello 2
  • AWS KMS con CloudHSM: convalidato FIPS 140-2 Livello 3 (per determinati servizi)
  • AWS CloudHSM: convalidato FIPS 140-2 Livello 3

Nota: per la gestione dei segreti (credenziali, password, chiavi API e così via), usare AWS Secrets Manager.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni per GCP: usare Cloud Servizio di gestione delle chiavi (Cloud KMS) per creare e gestire i cicli di vita delle chiavi di crittografia nei servizi Google Cloud compatibili e nelle applicazioni del carico di lavoro. Ruotare e revocare le chiavi nel Servizio di gestione delle chiavi cloud e nel servizio in base alla pianificazione definita e in caso di ritiro o compromissione della chiave.

Usare il servizio HSM cloud di Google per fornire chiavi basate su hardware al Servizio di gestione delle chiavi cloud (Servizio di gestione delle chiavi) Offre la possibilità di gestire e usare chiavi crittografiche personalizzate pur essendo protette da moduli di protezione hardware completamente gestiti.

Il servizio HSM cloud usa moduli di protezione hardware, che sono convalidati da FIPS 140 a 2 livello 3 e sono sempre in esecuzione in modalità FIPS. FIPS 140-2 Livello 3 convalidato e sempre in esecuzione in modalità FIPS. Lo standard FIPS specifica gli algoritmi di crittografia e la generazione casuale di numeri usati dai moduli di protezione hardware.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-7: Usare un processo di gestione dei certificati sicuro

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-17 3.6

Principio di sicurezza: documentare e implementare uno standard di gestione dei certificati aziendale, processi e procedure che includono il controllo del ciclo di vita dei certificati e i criteri di certificato (se è necessaria un'infrastruttura a chiave pubblica).

Assicurarsi che i certificati usati dai servizi critici nell'organizzazione vengano inclusi nell'inventario, monitorati, monitorati e rinnovati tempestivamente usando un meccanismo automatizzato per evitare interruzioni del servizio.

Linee guida di Azure: usare Azure Key Vault per creare e controllare il ciclo di vita del certificato, tra cui la creazione/importazione, la rotazione, la revoca, l'archiviazione e l'eliminazione del certificato. Verificare che la generazione del certificato segua lo standard definito senza usare proprietà non sicure, ad esempio dimensioni di chiave insufficienti, periodo di validità eccessivamente lungo, crittografia non sicura e così via. Configurare la rotazione automatica del certificato in Azure Key Vault e i servizi di Azure supportati in base alla pianificazione definita e alla scadenza di un certificato. Se la rotazione automatica non è supportata nell'applicazione front-end, usare una rotazione manuale in Azure Key Vault.

Evitare di usare un certificato autofirmato e un certificato con caratteri jolly nei servizi critici a causa della garanzia di sicurezza limitata. È invece possibile creare certificati firmati pubblici in Azure Key Vault. Le autorità di certificazione seguenti sono i provider partner attualmente integrati con Azure Key Vault.

  • DigiCert: Azure Key Vault offre certificati TLS/SSL OV con DigiCert.
  • GlobalSign: Azure Key Vault offre certificati OV TLS/SSL con GlobalSign.

Nota: usare solo l'autorità di certificazione approvata e assicurarsi che i certificati radice/intermedi noti rilasciati da queste ca siano disabilitati.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare AWS Certificate Manager (ACM) per creare e controllare il ciclo di vita del certificato, tra cui creazione/importazione, rotazione, revoca, archiviazione e ripulitura del certificato. Verificare che la generazione del certificato segua lo standard definito senza usare proprietà non sicure, ad esempio dimensioni di chiave insufficienti, periodo di validità eccessivamente lungo, crittografia non sicura e così via. Configurare la rotazione automatica del certificato in ACM e i servizi AWS supportati in base alla pianificazione definita e alla scadenza di un certificato. Se la rotazione automatica non è supportata nell'applicazione front-end, usare la rotazione manuale in ACM. Nel frattempo, è necessario tenere sempre traccia dello stato di rinnovo del certificato per garantire la validità del certificato.

Evitare di usare un certificato autofirmato e un certificato con caratteri jolly nei servizi critici a causa della garanzia di sicurezza limitata. Creare invece certificati firmati pubblicamente (firmati dall'autorità di certificazione Amazon) in ACM e distribuirlo a livello di codice nei servizi come CloudFront, Load Balancers, Gateway API e così via. È anche possibile usare ACM per stabilire l'autorità di certificazione privata (CA) per firmare i certificati privati.

Nota: usare solo una CA approvata e assicurarsi che i certificati radice/intermedi ca non noti rilasciati da queste ca siano disabilitati.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni per GCP: usare Google Cloud Certificate Manager per creare e controllare il ciclo di vita del certificato, tra cui creazione/importazione, rotazione, revoca, archiviazione e ripulitura del certificato. Verificare che la generazione del certificato segua lo standard definito senza usare proprietà non sicure, ad esempio dimensioni di chiave insufficienti, periodo di validità eccessivamente lungo, crittografia non sicura e così via. Configurare la rotazione automatica del certificato in Gestione certificati e i servizi GCP supportati in base alla pianificazione definita e alla scadenza di un certificato. Se la rotazione automatica non è supportata nell'applicazione front-end, usare la rotazione manuale in Gestione certificati. Nel frattempo, è necessario tenere sempre traccia dello stato di rinnovo del certificato per garantire la validità del certificato.

Evitare di usare un certificato autofirmato e un certificato con caratteri jolly nei servizi critici a causa della garanzia di sicurezza limitata. È invece possibile creare certificati pubblici firmati in Gestione certificati e distribuirlo a livello di codice in servizi come Load Balancer e DNS cloud e così via. È anche possibile usare il servizio autorità di certificazione per stabilire l'autorità di certificazione privata per firmare i certificati privati.

Nota: è anche possibile usare Google Cloud Secret Manager per archiviare i certificati TLS.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-8: Garantire la sicurezza del repository di chiavi e certificati

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-17 3.6

Principio di sicurezza: garantire la sicurezza del servizio key vault usato per la gestione del ciclo di vita della chiave crittografica e del certificato. Rafforzare il servizio key vault tramite il controllo di accesso, la sicurezza di rete, la registrazione e il monitoraggio e il backup per garantire che le chiavi e i certificati siano sempre protetti usando la massima sicurezza.

Linee guida di Azure: proteggere le chiavi crittografiche e i certificati grazie alla protezione avanzata del servizio Azure Key Vault tramite i controlli seguenti:

  • Implementare il controllo di accesso usando i criteri di controllo degli accessi in base al ruolo nel modulo di protezione hardware gestito di Azure Key Vault a livello di chiave per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, assicurarsi che la separazione dei compiti sia attiva per gli utenti che gestiscono le chiavi di crittografia in modo che non abbiano la possibilità di accedere ai dati crittografati e viceversa. Per Azure Key Vault Standard e Premium, creare insiemi di credenziali univoci per applicazioni diverse per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti.
  • Attivare la registrazione di Azure Key Vault per garantire la registrazione del piano di gestione critico e delle attività del piano dati.
  • Proteggere Azure Key Vault usando collegamento privato e Firewall di Azure per garantire un'esposizione minima del servizio
  • Usare l'identità gestita per accedere alle chiavi archiviate in Azure Key Vault nelle applicazioni del carico di lavoro.
  • Quando si eliminano i dati, assicurarsi che le chiavi non vengano eliminate prima che i dati effettivi, i backup e gli archivi vengano eliminati.
  • Eseguire il backup delle chiavi e dei certificati usando Azure Key Vault. Abilitare l'eliminazione temporanea e la protezione dall'eliminazione temporanea per evitare l'eliminazione accidentale delle chiavi. Quando è necessario eliminare le chiavi, è consigliabile disabilitare le chiavi invece di eliminarle per evitare l'eliminazione accidentale delle chiavi e la cancellazione crittografica dei dati.
  • Per i casi d'uso BYOK (Bring Your Own Key), generare chiavi in un modulo di protezione hardware locale e importarle per ottimizzare la durata e la portabilità delle chiavi.
  • Non archiviare mai le chiavi in formato testo non crittografato all'esterno di Azure Key Vault. Le chiavi in tutti i servizi dell'insieme di credenziali delle chiavi non sono esportabili per impostazione predefinita.
  • Usare i tipi di chiave supportati dal modulo di protezione hardware (RSA-HSM) in Azure Key Vault Premium e HSM gestito di Azure per la protezione hardware e i livelli FIPS più avanzati.

Abilitare Microsoft Defender per Key Vault per la protezione avanzata dalle minacce nativa di Azure per Azure Key Vault, fornendo un livello aggiuntivo di intelligence sulla sicurezza.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: per la sicurezza delle chiavi crittografiche, proteggere le chiavi grazie alla protezione avanzata del servizio AWS Servizio di gestione delle chiavi (KMS) tramite i controlli seguenti:

  • Implementare il controllo di accesso usando i criteri chiave (controllo di accesso a livello di chiave) insieme ai criteri IAM (controllo degli accessi in base all'identità) per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, assicurarsi che la separazione dei compiti sia attiva per gli utenti che gestiscono le chiavi di crittografia in modo che non abbiano la possibilità di accedere ai dati crittografati e viceversa.
  • Usare controlli detective come CloudTrails per registrare e tenere traccia dell'utilizzo delle chiavi nel Servizio di gestione delle chiavi e avvisare l'utente sulle azioni critiche.
  • Non archiviare mai le chiavi in formato testo non crittografato all'esterno del Servizio di gestione delle chiavi.
  • Quando è necessario eliminare le chiavi, è consigliabile disabilitare le chiavi nel Servizio di gestione delle chiavi anziché eliminarle per evitare l'eliminazione accidentale delle chiavi e la cancellazione crittografica dei dati.
  • Quando si eliminano i dati, assicurarsi che le chiavi non vengano eliminate prima che i dati effettivi, i backup e gli archivi vengano eliminati.
  • Per i casi d'uso byok (Bring Your Own Key), generare chiavi in un modulo di protezione hardware locale e importarle per ottimizzare la durata e la portabilità delle chiavi.

Per la sicurezza dei certificati, proteggere i certificati grazie alla protezione avanzata del servizio AWS Certificate Manager (ACM) tramite i controlli seguenti:

  • Implementare il controllo di accesso usando criteri a livello di risorsa insieme ai criteri IAM (controllo degli accessi in base all'identità) per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, garantire la separazione dei compiti per gli account utente: gli account utente che generano certificati sono separati dagli account utente che richiedono solo l'accesso in sola lettura ai certificati.
  • Usare controlli detective come CloudTrails per registrare e tenere traccia dell'utilizzo dei certificati in ACM e avvisare l'utente sulle azioni critiche.
  • Seguire le indicazioni di sicurezza del Servizio di gestione delle chiavi per proteggere la chiave privata (generata per la richiesta di certificato) usata per l'integrazione del certificato del servizio.

Implementazione di AWS e contesto aggiuntivo:

Linee guida per GCP: per la sicurezza delle chiavi crittografiche, proteggere le chiavi con la protezione avanzata delle Servizio di gestione delle chiavi tramite i controlli seguenti:

  • Implementare il controllo di accesso usando i ruoli IAM per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, assicurarsi che la separazione dei compiti sia attiva per gli utenti che gestiscono le chiavi di crittografia in modo che non abbiano la possibilità di accedere ai dati crittografati e viceversa.
  • Creare un anello di chiave separato per ogni progetto che consente di gestire e controllare facilmente l'accesso alle chiavi seguendo le procedure consigliate per i privilegi minimi. Consente inoltre di controllare più facilmente chi può accedere alle chiavi in corrispondenza di quando.
  • Abilitare la rotazione automatica delle chiavi per assicurarsi che le chiavi vengano aggiornate e aggiornate regolarmente. Ciò consente di proteggersi da potenziali minacce alla sicurezza, ad esempio attacchi di forza bruta o attori malintenzionati che tentano di ottenere l'accesso alle informazioni riservate.
  • Configurare un sink del log di controllo per tenere traccia di tutte le attività che si verificano all'interno dell'ambiente del Servizio di gestione delle chiavi GCP.

Per la sicurezza dei certificati, proteggere i certificati tramite la protezione avanzata di Gestione certificati GCP e il servizio autorità di certificazione tramite i controlli seguenti:

  • Implementare il controllo di accesso usando criteri a livello di risorsa insieme ai criteri IAM (controllo degli accessi in base all'identità) per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, garantire la separazione dei compiti per gli account utente: gli account utente che generano certificati sono separati dagli account utente che richiedono solo l'accesso in sola lettura ai certificati.
  • Usare controlli detective come i log di controllo cloud per registrare e tenere traccia dell'utilizzo dei certificati in Gestione certificati e avvisare l'utente sulle azioni critiche.
  • Secret Manager supporta anche l'archiviazione del certificato TLS. È necessario seguire la procedura di sicurezza simile per implementare i controlli di sicurezza in Secret Manager.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):