Protezione dei dati in Amazon Security Lake

Il modello di responsabilità AWS condivisa si applica alla protezione dei dati in Amazon Security Lake. Come descritto in questo modello, AWS è responsabile della protezione dell'infrastruttura globale che gestisce tutti i Cloud AWS. L'utente è responsabile del controllo dei contenuti ospitati su questa infrastruttura. L'utente è inoltre responsabile della configurazione della protezione e delle attività di gestione per i Servizi AWS utilizzati. Per ulteriori informazioni sulla privacy dei dati, vedi le Domande frequenti sulla privacy dei dati. Per informazioni sulla protezione dei dati in Europa, consulta il post del blog relativo al Modello di responsabilità condivisa AWS e GDPR nel Blog sulla sicurezza AWS .

Ai fini della protezione dei dati, consigliamo di proteggere Account AWS le credenziali e configurare i singoli utenti con AWS IAM Identity Center or AWS Identity and Access Management (IAM). In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Ti suggeriamo, inoltre, di proteggere i dati nei seguenti modi:

• Utilizza l'autenticazione a più fattori (MFA) con ogni account.

• Usa SSL/TLS per comunicare con le risorse. AWS È richiesto TLS 1.2 ed è consigliato TLS 1.3.

• Configura l'API e la registrazione delle attività degli utenti con. AWS CloudTrail

• Utilizza soluzioni di AWS crittografia, insieme a tutti i controlli di sicurezza predefiniti all'interno Servizi AWS.

• Utilizza i servizi di sicurezza gestiti avanzati, come Amazon Macie, che aiutano a individuare e proteggere i dati sensibili archiviati in Amazon S3.

• Se hai bisogno di moduli crittografici convalidati FIPS 140-2 per l'accesso AWS tramite un'interfaccia a riga di comando o un'API, utilizza un endpoint FIPS. Per ulteriori informazioni sugli endpoint FIPS disponibili, consulta il Federal Information Processing Standard (FIPS) 140-2.

Ti consigliamo vivamente di non inserire mai informazioni riservate o sensibili, ad esempio gli indirizzi e-mail dei clienti, nei tag o nei campi di testo in formato libero, ad esempio nel campo Nome. Ciò vale anche quando lavori con Security Lake o altri dispositivi Servizi AWS utilizzando la console, l'API o gli SDK. AWS CLI AWS I dati inseriti nei tag o nei campi di testo in formato libero utilizzati per i nomi possono essere utilizzati per i la fatturazione o i log di diagnostica. Quando fornisci un URL a un server esterno, ti suggeriamo vivamente di non includere informazioni sulle credenziali nell'URL per convalidare la tua richiesta al server.

Crittografia dei dati a riposo

Amazon Security Lake archivia in modo sicuro i dati archiviati utilizzando soluzioni di AWS crittografia. I log di sicurezza non elaborati e i dati degli eventi vengono archiviati in un bucket Amazon Simple Storage Service (Amazon S3) multi-tenant in un account gestito da Security Lake. Security Lake crittografa questi dati non elaborati utilizzando una chiave di AWS proprietà di (). AWS Key Management Service AWS KMS AWS le chiavi di proprietà sono una raccolta di AWS KMS chiavi che un AWS servizio, in questo caso Security Lake, possiede e gestisce per l'uso in più account. AWS

Security Lake esegue processi di estrazione, trasformazione e caricamento (ETL) su dati di log ed eventi non elaborati. I dati elaborati rimangono crittografati nell'account del servizio Security Lake.

Una volta completati i processi ETL, Security Lake crea bucket S3 single-tenant nel tuo account (un bucket per ogni bucket in Regione AWS cui hai abilitato Security Lake). I dati vengono archiviati nel bucket S3 multi-tenant solo temporaneamente fino a quando Security Lake non è in grado di consegnarli in modo affidabile ai bucket S3 single-tenant. I bucket single-tenant includono una policy basata sulle risorse che autorizza Security Lake a scrivere dati di log ed eventi nei bucket. Per crittografare i dati nel bucket S3, puoi scegliere una chiave di crittografia gestita da S3 o una chiave gestita dal cliente (da). AWS KMS Entrambe le opzioni utilizzano la crittografia simmetrica.

Utilizzo di una chiave KMS per la crittografia dei dati

Per impostazione predefinita, i dati forniti da Security Lake al tuo bucket S3 sono crittografati mediante crittografia lato server di Amazon con chiavi di crittografia gestite da Amazon S3 (SSE-S3). Per fornire un livello di sicurezza da gestire direttamente, puoi invece utilizzare la crittografia lato server con chiavi (SSE-KMS) per i dati di Security Lake. AWS KMS

SSE-KMS non è supportato nella console di Security Lake. Per utilizzare SSE-KMS con l'API o la CLI di Security Lake, devi prima creare una chiave KMS o utilizzare una chiave esistente. Alla chiave si allega una policy che determina quali utenti possono utilizzare la chiave per crittografare e decrittografare i dati di Security Lake.

Se utilizzi una chiave gestita dal cliente per crittografare i dati scritti nel tuo bucket S3, non puoi scegliere una chiave multiregionale. Per le chiavi gestite dal cliente, Security Lake crea una concessione per tuo conto inviando una richiesta a. CreateGrant AWS KMS Le sovvenzioni AWS KMS vengono utilizzate per consentire a Security Lake di accedere a una chiave KMS in un account cliente.

Security Lake richiede la concessione per utilizzare la chiave gestita dal cliente per le seguenti operazioni interne:

• Invia GenerateDataKey richieste per AWS KMS generare chiavi dati crittografate dalla chiave gestita dal cliente.

• Invia RetireGrant richieste a AWS KMS. Quando effettui aggiornamenti al tuo data lake, questa operazione consente il ritiro della sovvenzione aggiunta alla chiave AWS KMS per l'elaborazione ETL.

Security Lake non necessita di autorizzazioni. Decrypt Quando gli utenti autorizzati della chiave leggono i dati di Security Lake, S3 gestisce la decrittografia e gli utenti autorizzati sono in grado di leggere i dati in forma non crittografata. Tuttavia, un abbonato necessita delle Decrypt autorizzazioni per utilizzare i dati di origine. Per ulteriori informazioni sulle autorizzazioni degli abbonati, consulta. Gestione dell'accesso ai dati per gli abbonati a Security Lake

Se si desidera utilizzare una chiave KMS esistente per crittografare i dati di Security Lake, è necessario modificare la politica delle chiavi per la chiave KMS. La policy chiave deve consentire al ruolo IAM associato alla posizione del data lake Lake Formation di utilizzare la chiave KMS per decrittografare i dati. Per istruzioni su come modificare la policy chiave per una chiave KMS, consulta Changing a key policy nella Developer Guide. AWS Key Management Service

La tua chiave KMS può accettare richieste di concessione, consentendo a Security Lake di accedere alla chiave, quando crei una politica chiave o utilizzi una politica chiave esistente con le autorizzazioni appropriate. Per istruzioni sulla creazione di una politica chiave, consulta Creazione di una politica chiave nella Guida per gli AWS Key Management Service sviluppatori.

Allega la seguente politica chiave alla tua chiave KMS:

{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/ExampleRole"}
  "Action": [
    "kms:CreateGrant",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Autorizzazioni IAM richieste quando si utilizza una chiave gestita dal cliente

Consulta la sezione Guida introduttiva: prerequisiti per una panoramica dei ruoli IAM che devi creare per utilizzare Security Lake.

Quando aggiungi una fonte personalizzata o un abbonato, Security Lake crea ruoli IAM nel tuo account. Questi ruoli sono destinati a essere condivisi con altre identità IAM. Consentono a una fonte personalizzata di scrivere dati nel data lake e a un abbonato di utilizzare i dati dal data lake. Una policy AWS gestita denominata AmazonSecurityLakePermissionsBoundary definisce i limiti di autorizzazione per questi ruoli.

Crittografia delle code Amazon SQS

Quando crei il tuo data lake, Security Lake crea due code Amazon Simple Queue Service (Amazon SQS) non crittografate nell'account amministratore delegato di Security Lake. È necessario crittografare queste code per proteggere i dati. La crittografia lato server (SSE) predefinita fornita da Amazon Simple Queue Service non è sufficiente. È necessario creare una chiave gestita dal cliente in AWS Key Management Service (AWS KMS) per crittografare le code e concedere al servizio Amazon S3 le autorizzazioni principali per lavorare con le code crittografate. Per istruzioni su come concedere queste autorizzazioni, consulta Perché le notifiche degli eventi di Amazon S3 non vengono recapitate a una coda Amazon SQS che utilizza la crittografia lato server? nel AWS Knowledge Center.

Poiché Security Lake supporta AWS Lambda i processi di estrazione, trasferimento e caricamento (ETL) sui tuoi dati, devi anche concedere le autorizzazioni Lambda per gestire i messaggi nelle code di Amazon SQS. Per informazioni, consulta Autorizzazioni per i ruoli di esecuzione nella Guida per gli sviluppatori.AWS Lambda

Crittografia in transito

Security Lake crittografa tutti i dati in transito tra AWS i servizi. Security Lake protegge i dati in transito, mentre viaggiano da e verso il servizio, crittografando automaticamente tutti i dati tra reti utilizzando il protocollo di crittografia Transport Layer Security (TLS) 1.2. Le richieste HTTPS dirette inviate alle API di Security Lake vengono firmate utilizzando l'algoritmo AWS Signature Version 4 per stabilire una connessione sicura.