Proteção de dados no Amazon Security Lake

O modelo de responsabilidade AWS compartilhada de se aplica à proteção de dados no Amazon Security Lake. Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa todos os Nuvem AWS. Você é responsável por manter o controle sobre seu conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para obter mais informações sobre a privacidade de dados, consulte as Perguntas Frequentes sobre Privacidade de Dados.. Para obter mais informações sobre a proteção de dados na Europa, consulte a postagem do blog AWS LGPD e Modelo de Responsabilidade Compartilhada no AWS Blog de Segurança.

Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com AWS IAM Identity Center ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:

• Use uma autenticação multifator (MFA) com cada conta.

• Use SSL/TLS para se comunicar com os recursos. AWS Exigimos TLS 1.2 e recomendamos TLS 1.3.

• Configure a API e o registro de atividades do usuário com AWS CloudTrail.

• Use soluções de AWS criptografia, juntamente com todos os controles de segurança padrão Serviços da AWS.

• Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sigilosos armazenados no Amazon S3.

• Se você precisar de módulos criptográficos validados pelo FIPS 140-2 ao acessar AWS por meio de uma interface de linha de comando ou de uma API, use um endpoint FIPS. Para ter mais informações sobre endpoints do FIPS disponíveis, consulte Federal Information Processing Standard (FIPS) 140-2.

É altamente recomendável que nunca sejam colocadas informações de identificação confidenciais, como endereços de e-mail dos seus clientes, em marcações ou campos de formato livre, como um campo Nome. Isso inclui quando você trabalha com o Security Lake ou outro Serviços da AWS usando o console, a API ou AWS os SDKs. AWS CLI Quaisquer dados inseridos em tags ou campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, recomendemos fortemente que não sejam incluídas informações de credenciais no URL para validar a solicitação a esse servidor.

Criptografia em repouso

O Amazon Security Lake armazena com segurança seus dados em repouso usando soluções de AWS criptografia. Os dados brutos de log de segurança e eventos são armazenados em um bucket multilocatário do Amazon Simple Storage Service (Amazon S3) em uma conta gerenciada pelo Security Lake. O Security Lake criptografa esses dados brutos usando uma AWS chave própria de AWS Key Management Service (AWS KMS). AWS chaves próprias são uma coleção de AWS KMS chaves que um AWS serviço — nesse caso, o Security Lake — possui e gerencia para uso em várias contas. AWS

O Security Lake executa trabalhos de extração, transformação e carregamento (ETL) em dados brutos de log e eventos. Os dados processados permanecem criptografados na conta de serviços do Security Lake.

Depois que os trabalhos de ETL forem concluídos, o Security Lake cria buckets S3 de inquilino único em sua conta (um bucket para cada um no qual você ativou Região da AWS o Security Lake). Os dados são armazenados no bucket multilocatário do S3 apenas temporariamente até que o Security Lake possa entregar os dados de forma confiável aos buckets de locatário único do S3. Os buckets de locatário único incluem uma política baseada em recursos que dá permissão ao Security Lake para gravar dados de log e eventos nos buckets. Para criptografar dados em seu bucket do S3, você pode escolher uma chave de criptografia gerenciada pelo S3 ou uma chave gerenciada pelo cliente (de). AWS KMS Ambas as opções usam criptografia simétrica.

Como usar uma chave do KMS para criptografia dos dados

Por padrão, os arquivos de log entregues pelo Security Lake ao seu bucket do S3 são criptografados criptografia do servidor da Amazon com chaves de criptografia gerenciadas pelo Amazon S3 (SSE-S3). Para fornecer uma camada de segurança que você gerencia diretamente, você pode usar criptografia do lado do servidor com AWS KMS chaves (SSE-KMS) para seus dados do Security Lake.

O SSE-KMS não é compatível com o console do Security Lake. Para usar o SSE-KMS com a API do Security Lake ou a CLI, primeiro você cria uma chave do KMS ou usa uma chave existente. Você anexa uma política à chave que determina quais usuários podem usar as chaves para criptografar e descriptografar os arquivos de log do Security Lake.

Se você usar uma chave gerenciada pelo cliente para criptografar dados gravados em seu bucket do S3, não poderá escolher uma chave multirregional. Para chaves gerenciadas pelo cliente, o Security Lake cria uma concessão em seu nome enviando uma solicitação CreateGrant para o AWS KMS. As concessões AWS KMS são usadas para dar ao Security Lake acesso a uma chave KMS em uma conta de cliente.

O Security Lake requer a concessão para usar a sua chave gerenciada pelo cliente para as seguintes operações internas:

• Envie GenerateDataKey solicitações AWS KMS para gerar chaves de dados criptografadas pela chave gerenciada pelo cliente.

• Envie RetireGrant solicitações para AWS KMS. Quando você faz atualizações no seu data lake, essa operação permite a retirada da concessão que foi adicionada à chave do AWS KMS para processamento de ETL.

O Security Lake não precisa de permissões Decrypt. Quando os usuários autorizados da chave leem dados do Security Lake, o S3 gerencia a descriptografia, e os usuários autorizados podem ler os dados de modo não criptografado. No entanto, um assinante precisa de permissões Decrypt para consumir os dados da fonte. Para obter mais informações sobre permissões do assinante, consulte Como gerenciar o acesso a dados para assinantes do Security Lake.

Se quiser usar uma chave KMS existente para criptografar dados do Security Lake, você deve modificar a política de chaves para a chave KMS. A política de chaves deve permitir que a função do IAM associada à localização do data lake do Lake Formation use a chave KMS para descriptografar os dados. Para obter instruções sobre como você pode alterar a política de chaves de uma chave KMS, consulte Alteração de uma política de chaves no Guia do AWS Key Management Service desenvolvedor.

Sua chave KMS pode aceitar solicitações de concessão, permitindo que o Security Lake acesse a chave quando você cria uma política de chaves ou usa uma política de chaves existente com as permissões apropriadas. Para obter mais informações sobre como criar uma política de chave, consulte Criar uma política de chave no Guia do desenvolvedor do AWS Key Management Service .

Anexe a seguinte política de chaves à sua chave do 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": "*"
}

Permissões do IAM obrigatórias ao usar uma chave gerenciada pelo cliente

Consulte a seção Conceitos básicos: pré-requisitos para ter uma visão geral dos perfis do IAM que você precisa criar para usar o Security Lake.

Quando você adiciona uma fonte personalizada ou um assinante, o Security Lake cria perfis do IAM em sua conta. Esses perfis devem ser compartilhados com outras identidades do IAM. Eles permitem que uma fonte personalizada grave dados no data lake e que um assinante consuma dados do data lake. Uma política AWS gerenciada chamada AmazonSecurityLakePermissionsBoundary define os limites de permissão para essas funções.

Criptografar filas do Amazon SQS

Quando você cria seu data lake, o Security Lake cria duas filas não criptografadas do Amazon Simple Queue Service (Amazon SQS) na conta delegada do administrador do Security Lake. Você deve criptografar essas filas para proteger os dados. A criptografia do lado do servidor (SSE) padrão fornecida pelo Amazon Simple Queue Service não é suficiente. Você deve criar uma chave gerenciada pelo cliente em AWS Key Management Service (AWS KMS) para criptografar as filas e conceder ao serviço Amazon S3 permissões principais para trabalhar com as filas criptografadas. Para obter instruções sobre como conceder essas permissões, consulte Por que as notificações de eventos do Amazon S3 não são entregues a uma fila do Amazon SQS que usa criptografia do lado do servidor? no Centro de AWS Conhecimento.

Como o Security Lake usa AWS Lambda para suportar trabalhos de extração, transferência e carregamento (ETL) em seus dados, você também deve conceder permissões ao Lambda para gerenciar mensagens em suas filas do Amazon SQS. Para obter mais informações, consulte Permissões de função de execução no Guia do desenvolvedor do AWS Lambda .

Criptografia em trânsito

O Security Lake criptografa todos os dados em trânsito entre os AWS serviços. O Security Lake protege os dados em trânsito, à medida que viajam de e para o serviço, criptografando automaticamente todos os dados entre redes usando o protocolo de criptografia Transport Layer Security (TLS) 1.2. As solicitações HTTPS diretas enviadas às APIs do Security Lake são assinadas usando o AWS Signature Version 4 Algorithm para estabelecer uma conexão segura.