Crittografia tenant

Quando viene creato un tenant, Qlik Cloud utilizza diversi livelli di sicurezza per proteggere i dati. Per impostazione predefinita, ogni tenant è separato dagli altri tenant da una serie di chiavi di crittografia generate in modo univoco e gestite dal servizio di crittografia Qlik per crittografare il contenuto del tenant. Le chiavi di ogni tenant sono separate da quelle utilizzate da Qlik per proteggere la comunicazione tra servizi.

Qlik Cloud utilizza i seguenti standard di crittografia:

• In transito: crittografia TLS 1.2

• A riposo: crittografia AES-256-GCM

• All'interno della piattaforma (dopo l'autenticazione con un IdP designato) - Token Web JSON firmati (JWT) per garantire integrità, autenticità e non ripudio

Chiavi gestite dai clienti (CMK)

Alcuni settori altamente regolamentati, come quello sanitario, devono rispettare rigide norme di sicurezza e conformità. Inoltre, molti clienti commerciali utilizzano approcci di classificazione dei dati sensibili al mercato per determinare se sono necessarie tecniche di sicurezza aggiuntive per specifici set di dati. Questi requisiti di sicurezza più severi potrebbero includere l'obbligo di controllare le chiavi di crittografia utilizzate per criptare e decriptare i dati sensibili del cloud. Qlik Cloud consente di utilizzare Chiavi gestite dai clienti per usare la chiave personale (bring your own key) (BYOK) come opzione di crittografia per proteggere i dati del tenant a riposo nel Qlik Cloud.

La crittografia con CMK è applicata a livello di tenant. Gli amministratori tenant possono configurare la crittografia dei tenant per utilizzare un CMK. Qlik Cloud supporta i seguenti provider Key Management Service (KMS):

• Qlik Internal KMS (Predefinito)

• Amazon Web Services (AWS) KMS

Chiavi gestite dai clienti e HIPAA

Qlik Cloud può ospitare informazioni sanitarie personali (PHI) soggette alle normative degli Stati Uniti Health Insurance Portability and Accountability Act del 1996 (HIPAA), a condizione che i clienti utilizzino Chiavi gestite dai clienti e sottoscrivano un accordo di associazione d'impresa (BAA) HIPAA. Anche se Qlik Cloud può supportare i clienti nell'adempimento dei loro requisiti normativi HIPAA, i clienti che utilizzano Qlik Cloud sono responsabili della propria conformità HIPAA. L'uso di Chiavi gestite dai clienti è obbligatorio nei Qlik Cloud.tenant che gestiscono carichi di lavoro PHI. Per ulteriori informazioni, vedere Attendibilità e sicurezza in Qlik.

Panoramica dell'architettura di crittografia Qlik Cloud

Lo schema seguente fornisce una panoramica del servizio di crittografia Qlik Cloud che codifica i dati nel tenant. Per impostazione predefinita, i tenant Qlik Cloud crittografano e decrittografano i dati utilizzando chiavi di crittografia generate dal KMS di Qlik Cloud. Con Chiavi gestite dai clienti, KMS AWS genera le chiavi di crittografia utilizzate dal tenant. Ogni volta che un servizio in Qlik Cloud crittografa o decrittografa i dati, il servizio di crittografia chiama KMS AWS e utilizza la chiave gestita dal cliente.

Responsabilità dei clienti con Chiavi gestite dai clienti

Con CMK, i clienti hanno il pieno controllo delle loro chiavi. L'organizzazione del cliente è responsabile della creazione, della manutenzione e della gestione di tutti gli aspetti del ciclo di vita della chiave, comprese le seguenti aree:

Configurazione chiave in KMS AWS

• Creazione di un account AWS e utilizzo di KMS.

• Creazione di chiavi e definizione di criteri di gestione delle chiavi KMS AWS in base alle autorizzazioni e ai ruoli IAM (Identity and Access Management) e a chi può eseguire funzioni quali la creazione, la disattivazione e l'eliminazione di chiavi.

Gestione delle chiavi in KMS AWS

Una volta configurato il tenant per utilizzare una chiave KMS AWS per crittografare i dati a riposo, l'utente è responsabile della gestione della chiave. È importante proteggere la chiave KMS AWS da eliminazioni o disattivazioni accidentali. Qlik consiglia di stabilire un processo attorno a queste e altre funzioni chiave di gestione. Poiché si tratta di chiavi controllate dal cliente, Qlik Cloud non può impedire all'utente di disabilitare o disattivare la propria CMK.

• Disabilitazione di una chiave KMS AWS. Questa azione impedisce temporaneamente a Qlik Cloud di effettuare chiamate API a KMS AWS per la generazione di chiavi di dati (utilizzate per la crittografia) e per le operazioni di decrittografia. Ad esempio, un ricaricamento pianificato o un'attività che viene eseguita in background in Qlik Cloud e che richiede la crittografia o la decrittografia dei dati non riuscirà se la chiave (o l'accesso alla chiave) è disabilitata. La riabilitazione della chiave ristabilisce l'accesso al tenant.

• Eliminazione di una chiave KMS AWS. Questa azione disabiliterà permanentemente il tenant Qlik Cloud. Quando si pianifica l'eliminazione di una chiave, il tenant viene immediatamente messo in modalità disabilitata. Questo impedisce l'accesso alle chiavi e blocca il tenant. KMS AWS ha un processo di controllo completo sull'eliminazione delle chiavi che può essere personalizzato in base alle proprie esigenze. Ad esempio, è possibile impostare un periodo di attesa prima che la chiave venga eliminata e utilizzare gli avvisi, nonché annullare l'eliminazione durante il periodo di attesa.

• Rotazione di una chiave in KMS AWS. È possibile selezionare l'opzione Rotazione automatica della chiave KMS AWS quando si definisce la chiave. Questo genererà nuovo materiale crittografico per la chiave KMS una volta all'anno. KMS AWS salva tutte le versioni precedenti del materiale crittografico, in modo da poter decrittare qualsiasi dato crittografato con tale chiave KMS. KMS AWS non elimina il materiale della chiave ruotata finché la chiave KMS non viene eliminata. Poiché KMS AWS effettua la decodifica in modo trasparente con il materiale chiave appropriato, si può tranquillamente utilizzare una chiave KMS ruotata, senza che ciò abbia alcun impatto sull'integrazione Qlik CloudChiavi gestite dai clienti. Notare che questa è differente da quando si utilizza una chiave AWS completamente nuova e si modifica il provider della chiave CMK Qlik in modo che usi la nuova chiave, che forza una nuova crittografia completa del tenant. Vedere Configurazione della crittografia tenant.

• Verifica dell'utilizzo delle chiavi: considerare l'utilizzo di strumenti di monitoraggio delle chiavi KMS, come AWS CloudTrail, per monitorare le operazioni di crittografia.

• Controllo dell'accesso alle chiavi: proteggere il criterio delle chiavi per evitare accessi o modifiche indesiderate.

• Garantire la disponibilità della chiave: mantenere e garantire che la chiave sia attiva. Impedire azioni che potrebbero causare la perdita dell'accesso. Come per altri servizi AWS, i dati del tenant non saranno disponibili se l'accesso a KMS AWS viene interrotto. KMS AWS include la resilienza integrata attraverso regioni e zone ad alta disponibilità per ottenere ridondanze nella loro infrastruttura. Per ulteriori informazioni sulla sicurezza KMS AWS, vedere Resilienza in AWS Key Management Service.

Per ulteriori informazioni, consultare la documentazione KMS AWS:

• Gestione delle chiavi
• Autenticazione e controllo degli accessi
• Sicurezza

CMK opzioni in Qlik Cloud regioni

KMS AWS offre due opzioni di chiave di crittografia, a regione singola e a più regioni, ai Qlik Cloud clienti a seconda della regione in cui il tenant è stato sottoposto a provisioning. Nelle regioni con requisiti specifici di sovranità dei dati che proibiscono l'esfiltrazione dei dati anche per scopi di ripristino di emergenza, Qlik Cloud supporta CMK l'uso con chiavi a regione singola o a più regioni da KMS AWS.

Nelle regioni senza requisiti specifici di sovranità dei dati, i clienti che eseguono il provisioning delle chiavi di crittografia da KMS AWS devono generare una chiave multi-regione corrispondente alla regione primaria e di ripristino di emergenza del tenant. La chiave multi-regione garantisce la continuità aziendale in caso di disastro nella regione primaria del tenant e un failover riuscito alla regione di ripristino di emergenza del tenant.

Transizione dalle chiavi per regioni singole alle chiavi multi-regione

Chiavi gestite dai clienti supporta le chiavi multi-regione per fornire assistenza nei processi di ripristino di emergenza. Se si utilizza una chiave per regioni singole, si consiglia di creare una chiave multi-regione per usare il tenant in una regione di riserva in caso di disservizio nella regione principale.

Per informazioni su come creare una chiave multi-regione, vedere KMS AWS Chiave multi-regione per il Ripristino di emergenza (DR).

Limiti e considerazioni su CMK

La sezione seguente descrive le limitazioni e le considerazioni da fare con CMK in Qlik Cloud:

• Una volta configurato il tenant per l'utilizzo della propria chiave CMK, è possibile tornare indietro per utilizzare la crittografia Qlik Internal KMS o cambiare e utilizzare una chiave CMK differente.

• CMK supporta solo KMS AWS come provider di chiavi esterno.

• CMK supporta solo le chiavi di crittografia simmetriche.

• CMK supporta chiavi a regione singola o multi-regione a seconda della regione in cui risiede il tenant.

• Chiavi gestite dai clienti non è disponibile con Qlik Mobile Client, Data Gateway Direct Access o Qlik Sense Business.