Chaves do KMS gerenciadas pelo cliente Monitorando a interação do serviço de retenção de dados com AWS KMS

Criptografia inativa

Por padrão, o AWS Wickr Data Retention Service criptografa de forma transparente todas as mensagens retidas e os anexos de arquivos em repouso. Você não precisa realizar nenhuma configuração adicional para garantir que seus dados sejam criptografados em repouso. O Serviço de Retenção de Dados aplica criptografia no lado do servidor para todos os dados do cliente armazenados no Amazon S3.

O serviço de retenção de dados criptografa os dados do cliente em repouso usando uma chave KMS gerenciada pelo cliente (CMK). Quando você implanta o Serviço de Retenção de Dados por meio de AWS Service Catalog, uma CMK simétrica é criada automaticamente em sua conta e configurada como a chave de criptografia padrão para todos os dados retidos. Você mantém controle total sobre essa chave, incluindo a capacidade de auditar o uso, alternar a chave e revogar o acesso.

Criptografar dados em repouso usando chaves KMS gerenciadas pelo cliente para retenção de dados

Como o Serviço de Retenção de Dados usa uma chave KMS gerenciada pelo cliente

Quando o Serviço de Retenção de Dados é implantado, uma chave KMS simétrica gerenciada pelo cliente (RetentionKey) é criada em sua conta. AWS Essa chave é usada para criptografar os seguintes recursos:

Mensagens retidas — Todas as mensagens do Wickr (texto, reações e outras) capturadas pelo bot de retenção de dados são criptografadas com a CMK antes de serem armazenadas em seu bucket do S3. As mensagens são criptografadas dentro de um Nitro Enclave usando o SDK de AWS criptografia e, em seguida, enviadas para o Amazon S3 usando a mesma CMK. SSE-KMS
Anexos de arquivo retidos — Os anexos de arquivo associados às mensagens são descriptografados da criptografia de ponta a ponta do Wickr dentro do Nitro Enclave, recriptografados com a CMK e armazenados no Amazon S3 com. SSE-KMS
Estado da conta criptografada — As chaves privadas criptográficas e o estado da conta do bot de retenção de dados são criptografados com a CMK e armazenados no DynamoDB. A decodificação desse estado requer o atestado do Nitro Enclave.
Criptografia padrão do bucket S3 — O bucket S3 de retenção é configurado com o SSE-KMS uso da CMK como chave de criptografia padrão. Uma política de bucket exige que todos os objetos sejam carregados com criptografia do lado do aws:kms servidor.
Compartimento de saída descriptografado — Quando os clientes acionam a descriptografia sob demanda (por meio da máquina de estado Step Functions), a saída descriptografada também é armazenada em um bucket S3 separado, criptografado com a mesma CMK.

Cross-account arquitetura de funções

O Serviço de Retenção de Dados opera em uma Wickr-managed AWS conta e acessa os recursos do cliente por meio de uma função IAM entre contas ()DRSCustomerCrossAccountRole-{networkId}-{region}. A função Wickr DRS Enclave assume essa função do lado do cliente usando AWS STS um ID externo (wickr-drs-{networkId}) para realizar operações KMS e S3.

Atestado Nitro Enclave

kms:DecryptAs chamadas diretas (fora do S3 SSE-KMS) exigem a certificação do Nitro Enclave. A política de chaves do KMS impõe que as kms:RecipientAttestation:PCR2 condições kms:RecipientAttestation:PCR0kms:RecipientAttestation:PCR1, e estejam presentes, garantindo que a descriptografia de dados confidenciais (estado da conta, conteúdo da mensagem) só possa ocorrer dentro do enclave verificado. Isso impede que qualquer operadora, incluindo a Wickr, decodifique os dados do cliente fora do enclave.

AWS O Nitro Enclaves processa mensagens usando sua chave KMS para descriptografar as chaves privadas do módulo de retenção de dados, descriptografar o conteúdo da mensagem e recriptografá-la com uma chave de dados exclusiva por Wickr-encrypted mensagem antes de armazená-la em seu bucket do S3.

Configurando chaves KMS gerenciadas pelo cliente no Data Retention Service

O serviço de retenção de dados oferece suporte a chaves KMS simétricas com uso ENCRYPT_DECRYPT e especificação de chaves. SYMMETRIC_DEFAULT A rotação automática de chaves é ativada por padrão quando a chave é criada por meio do Service Catalog.

Além disso, uma segunda chave KMS assimétrica (ECC_NIST_P384, KEY_AGREEMENT) é criada para o fluxo de trabalho de recuperação de senha. Essa chave é usada para o acordo de chave ECDH e não pode ser usada para fins gerais. encryption/decryption Essa chave é usada opcionalmente para clientes que migram de uma arquitetura baseada em docker do Data Retention Bot.

nota

Multi-region as chaves não são suportadas atualmente. A chave KMS deve estar na mesma região do bucket S3 e da implantação do Serviço de Retenção de Dados.

Configurando permissões para usar uma chave KMS gerenciada pelo cliente

A política de chaves a seguir é configurada automaticamente durante a implantação via Service Catalog. Se você precisar configurar manualmente uma chave, use a seguinte política de privilégios mínimos:


{
  "Version": "2012-10-17", 
  "Statement": [
    {
      "Sid": "YourExistingStatements",
      "Effect": "...",
      "...": "..."
    },
    {
      "Sid": "EnclaveGenerateDataKey",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{customer-account-id}:role/DRSCustomerCrossAccountRole-{networkId}-{region}"
      },
      "Action": "kms:GenerateDataKey",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:RecipientAttestation:PCR0": "*",
          "kms:RecipientAttestation:PCR1": "*",
          "kms:RecipientAttestation:PCR2": "*"
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": [
            "aws:wickr:network:id",
            "aws:wickr:app:id"
          ]
        }
      }
    },
    {
      "Sid": "EnclaveDescribeKey",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{customer-account-id}:role/DRSCustomerCrossAccountRole-{networkId}-{region}"
      },
      "Action": "kms:DescribeKey",
      "Resource": "*"
    },
    {
      "Sid": "EnclaveDecryptWithAttestation",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{customer-account-id}:role/DRSCustomerCrossAccountRole-{networkId}-{region}"
      },
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:RecipientAttestation:PCR0": "*",
          "kms:RecipientAttestation:PCR1": "*",
          "kms:RecipientAttestation:PCR2": "*"
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": "aws:wickr:app:id"
        }
      }
  },
    {
      "Sid": "DRSDecryptionLambda",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{customer-account-id}:role/{DecryptionLambdaRoleName}"
      },
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": "aws:wickr:network:id"
        }
      }
    }
  ]
}

Objetivo de cada declaração:

Habilitar políticas do IAM: Permite que o root da sua conta gerencie a chave. Essa é a declaração padrão do administrador de chaves.
EnclaveGenerateDataKey: kms:GenerateDataKey— Invocado pelo Nitro Enclave para gerar chaves de criptografia de dados para criptografar o conteúdo da mensagem e o estado da conta antes de armazená-la no S3. Permitido somente quando o enclave fornece um documento de atestado válido do Nitro Enclave (PCR0/1/2condições) e uma chave de contexto de criptografia de aws:wickr:network:id ou aws:wickr:app:id está presente.
EnclaveDescribeKey: kms:DescribeKey— Permite que o enclave recupere os principais metadados (especificação da chave, uso, status) para validação durante a inicialização.
EnclaveDecryptWithAttestation: kms:Decrypt— Invocado pelo Nitro Enclave para descriptografar o estado da conta (chaves privadas) necessário para a decodificação de mensagens do Wickr. Isso só é permitido quando o enclave fornece um documento de atestado válido do Nitro Enclave (PCR0/1/2 condições) e a chave de contexto de criptografia aws:wickr:app:id está presente, garantindo que a descriptografia não ocorra fora do enclave.
DRSDecryptionLambda: kms:Decrypt— Invocado pelo Lambda de decodificação sob demanda para descriptografar mensagens retidas quando você aciona a máquina de estado de descriptografia. Essa função não pode ser acessada pelo serviço Wickr e existe somente para você decifrar suas próprias mensagens do bucket criptografado do S3.

Se for necessária a migração da instalação anterior de retenção de dados, você deverá fornecer a senha do Docker-bot módulo ao serviço antes que a retenção de dados sem servidor possa ser ativada. Para obter mais informações, consulte, Instrução de recuperação de senha. Para obter detalhes sobre a política necessária para sua chave de recuperação de senha, consulteConfiguração de chave KMS personalizada para serviço de retenção de dados.

Se você precisar configurar manualmente a chave KMS, consulte Configuração de chave KMS personalizada para serviço de retenção de dados a política menos permissiva para sua chave.

Criação de uma nova implantação de retenção de dados com uma chave KMS gerenciada pelo cliente

O Serviço de Retenção de Dados é implantado por meio de AWS Service Catalog. Quando você lança o WickrDataRetentionProduct produto, o CloudFormation modelo automaticamente:

Cria uma CMK simétrica com alias wickr-drs-{networkId}-{region}-{suffix}-key
Cria uma CMK assimétrica (ECC P-384) para recuperação de senha com alias wickr-drs-{networkId}-{region}-{suffix}-password-recovery-key
Cria um bucket S3 com criptografia SSE-KMS padrão usando a CMK simétrica
Cria o DRSCustomerCrossAccountRole com as permissões KMS apropriadas
Registra a chave KMS ARN e o bucket S3 com a API de administração do Wickr por meio de um recurso personalizado Lambda

O ARN da chave KMS também é registrado por meio do endpoint Wickr Admin SDK:


PUT /networks/{networkId}/serverless-resources
{
  "s3BucketName": "wickr-drs-{networkId}-{region}-{suffix}",
  "kmsKeyArn": "arn:aws:kms:{region}:{accountId}:key/{keyId}",
  "passwordRecoveryKmsKeyArn": "arn:aws:kms:{region}:{accountId}:key/{keyId}"
}

O kmsKeyArn parâmetro deve ser um ARN de chave KMS válido. A API valida o formato ARN antes de armazená-lo.

Alterando a configuração de criptografia em uma implantação existente

Atualmente, o Serviço de Retenção de Dados não oferece suporte à alteração da CMK após a implantação. A chave KMS está fortemente acoplada a:

A configuração de criptografia padrão do bucket S3
O estado da conta criptografada armazenado no DynamoDB
A principal política com as condições de certificação do Nitro Enclave

Para alterar a chave de criptografia, você deve:

Implante uma nova instância do Serviço de Retenção de Dados com uma nova chave KMS.
As mensagens retidas anteriormente criptografadas com a chave antiga permanecem acessíveis somente com a chave original.

Importante

Não desative nem exclua a chave KMS original enquanto existirem mensagens criptografadas no intervalo de retenção. Isso tornará essas mensagens permanentemente irrecuperáveis.

Definindo o escopo do acesso à chave KMS gerenciada pelo cliente

Atestado Nitro Enclave (controle de acesso primário)

O principal mecanismo para definir o escopo do acesso à CMK é o atestado do Nitro Enclave. A política principal exigekms:RecipientAttestation:PCR0,PCR1, e PCR2 condições para kms:Decrypt chamadas diretas. Isso garante:

Somente o binário verificado do enclave Wickr DRS pode descriptografar dados confidenciais.
Até mesmo a função entre contas não pode decifrar dados fora do enclave.
CloudTrail os registros incluem os valores reais de PCR para auditoria.

Proteção contra representante confuso

A função entre contas usa uma ID externa (wickr-drs-{networkId}) na AssumeRole chamada STS. Isso evita ataques confusos de delegados em que outro serviço pode tentar usar a função de enclave Wickr DRS para acessar seus recursos.

kms: condição ViaService

As operações de SSE-KMS descriptografia do S3 têm como escopo a condição. kms:ViaService Isso garante que a S3-mediated descriptografia só seja permitida quando a solicitação for enviada pelo serviço S3.

Contexto de criptografia

O S3 inclui SSE-KMS automaticamente o ARN do objeto S3 como contexto de criptografia. A política de chaves usa esse contexto de criptografia para definir o escopo das permissões de descriptografia do S3 para prefixos específicos (por exemplo, o prefixo da ferramenta de senha).

Monitorando a interação do serviço de retenção de dados com AWS KMS

Você pode monitorar todas as chamadas de API do KMS feitas pelo Serviço de Retenção de Dados usando o. CloudTrail Para pesquisar entradas de CloudTrail registro, use o CloudTrail console ou a CloudTrail LookupEvents operação.

Os seguintes campos de CloudTrail eventos podem ser usados para auditar o uso do KMS pelo Serviço de Retenção de Dados:

Campo	Valor esperado
`eventName`	`Encrypt`, `Decrypt`, `GenerateDataKey`
`userIdentity.arn`	`arn:aws:sts::{customerAccountId}:assumed-role/DRSCustomerCrossAccountRole-{networkId}-{region}` ou `drs-create-account` ou `drs-password-recovery`
`requestParameters.keyId`	Seu ARN da CMK (por exemplo,) `arn:aws:kms:{region}:{accountId}:key/{keyId}`
`additionalEventData.recipient.attestationDocument`	Presente para chamadas Decrypt atestadas pelo enclave (contém valores de PCR)
`requestParameters.encryptionContext`	Para S3: SSE-KMS `{"aws:s3:arn": "arn:aws:s3:::{bucketName}/{objectKey}"}`

Principais eventos a serem monitorados:

Criptografar — ocorre quando o enclave criptografa o conteúdo da mensagem ou o estado da conta antes de armazená-la. S3/DynamoDB
GenerateDataKey— Ocorre quando o S3 gera uma chave de dados para criptografia de SSE-KMS envelope durante o upload do objeto.
Descriptografar — ocorre quando o enclave descriptografa o estado da conta (com atestado) ou quando o S3 descriptografa automaticamente objetos na leitura.
DeriveSharedSecret— Ocorre na chave de recuperação de senha quando o enclave executa o acordo de chave ECDH durante o fluxo de recuperação de senha.
GetPublicKey— Ocorre na chave de recuperação de senha quando seu collect.py script recupera a chave pública para criptografia ECDH local.

Além disso, o produto Service Catalog cria um CloudWatch painel (WickrDataRetentionService-{networkId}) que inclui widgets para as principais métricas de sucesso do KMS (operações de criptografia GenerateDataKey, descriptografia) e um alarme de erro de descriptografia que é acionado quando falhas de descriptografia são detectadas.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Considerações sobre segurança

Práticas recomendadas