Orientações para Criptografia de Dados do Atlas

Criptografia em trânsito

A criptografia em trânsito protege os dados durante a transmissão entre clientes e servidores, garantindo que seus dados não possam ser inspecionados enquanto estão em movimento. No Atlas, todo o tráfego de rede para clusters é protegido pelo TLS (Transport Layer Security), que está habilitado por padrão e não pode ser desabilitado. Os dados transmitidos para e entre nós são criptografados em trânsito usando TLS, garantindo uma comunicação segura por toda parte.

Você pode selecionar qual versão do TLS usar no Atlas. TLS 1.2 e um comprimento mínimo de chave de 128 bits são as configurações padrão recomendadas. Toda criptografia em trânsito é suportada pelo módulo de objetoFIPS do OpenSSL .

clique para ampliar

Criptografia em descanso

A encryption at rest garante que todos os dados em disco sejam criptografados e visíveis apenas quando descriptografados por um processo ou aplicação autorizado. No Atlas, os dados do cliente são automaticamente criptografados em repouso usando AES-256. Esse processo utiliza a criptografia de disco do seu fornecedor de nuvem, com o fornecedor gerenciando as chaves de criptografia. Este processo não pode ser desabilitado.

Por padrão, a criptografia em descanso é feita em nível de volume.

Além disso, você pode habilitar a criptografia em nível de banco de dados levando sua própria chave gerenciada pelo cliente (CMK) a um KMS (KMS) como o Amazon Web Services KMS, o Google Cloud Platform KMS ou o Azure Key Vault. Esse recurso oferece criptografia em nível de arquivo e é equivalente à criptografia de dados transparente (TDE), atendendo aos requisitos de TDE empresariais. A criptografia com gerenciamento de chaves de cliente adiciona outra camada de segurança para maior confidencialidade e segmentação de dados.

Para saber mais, consulte Encryption at Rest usando o Gerenciamento de chaves do cliente.

clique para ampliar

Criptografia em uso

A criptografia em uso protege os dados enquanto estão sendo processados. O MongoDB possui dois recursos de criptografia em uso para atender às suas necessidades de proteção de dados: criptografia no nível do campo do lado do cliente e Queryable Encryption.

Criptografia no nível de campo do cliente

A criptografia no nível do campo do lado do cliente (CSFLE) é um recurso de criptografia em uso que permite que um aplicação cliente criptografe dados confidenciais antes de armazená-los no banco de dados MongoDB . Os dados confidenciais são criptografados de forma transparente, permanecem criptografados durante todo o seu ciclo de vida e só são descriptografados no lado do cliente .

Você pode criptografar seletivamente campos individuais dentro de um documento, vários campos dentro do documento ou o documento inteiro. Você pode, opcionalmente, proteger cada campo com sua própria chave e descriptografá-los de forma transparente no cliente usando um driver do MongoDB. O CSFLE utiliza AES-256 no modo CBC autenticado para criptografar dados.

Além disso, você pode selecionar a criptografia aleatória, que não pode ser consultada, mas pode ser necessária para determinados requisitos de segurança.

O diagrama a seguir demonstra um fluxo de trabalho CSFLE em que os registros de usuário são armazenados em um banco de dados MongoDB e consultados pelo cliente. O número de segurança social (SSN) do usuário é criptografado antes de ser armazenado no banco de dados. Quando o aplicação envia uma query básica de igualdade no campo, o driver do MongoDB usa a chave para criptografar a query no lado do cliente e envia a query criptografada para o servidor. O servidor retorna os resultados criptografados para o cliente, que descriptografa os resultados antes de devolvê-los ao cliente autenticado como texto simples legível.

O CSFLE é compatível com todos os principais serviços de gerenciamento de chaves na nuvem e on-premises.

clique para ampliar

Queryable Encryption

Queryable Encryption ajuda as organizações a proteger dados sensíveis quando são consultados. Assim como o CSFLE, ela permite que os aplicativos criptografem seus dados no lado do cliente antes de armazená-los no banco de dados do MongoDB. Também permite que os aplicativos executem consultas expressivas, como as de igualdade, diretamente nos dados criptografados, utilizando um algoritmo de pesquisa criptografado. A Queryable Encryption garante a proteção de informações confidenciais sem sacrificar a capacidade de realizar consultas sobre elas. A Queryable Encryption sempre utiliza criptografia não determinística.

Para saber mais sobre os algoritmos usados na Queryable Encryption, consulte o whitepaper da Queryable Encryption.

O diagrama a seguir demonstra um fluxo de trabalho de Queryable Encryption em que os registros do usuário são armazenados em um banco de dados MongoDB e consultados pelo cliente. A data de nascimento (DOB) do usuário é criptografada antes de ser armazenada no banco de dados. Quando o aplicativo submete uma consulta de intervalo expressiva no campo, o driver do MongoDB utiliza a chave para criptografar a consulta e envia um token criptográfico junto com ela para o servidor MongoDB. O servidor utiliza o algoritmo de pesquisa criptografada para processar a query sem ter acesso aos dados reais. Por fim, o driver utiliza a chave para decifrar os resultados da consulta e os devolve ao cliente autenticado como texto simples legível.

clique para ampliar

Criptografia com gerenciamento de chaves de cliente

Você habilita a criptografia com o gerenciamento de chaves de cliente no nível do projeto. Depois de habilitá-la, a configuração é aplicada automaticamente a todos os clusters criados no projeto, o que garante uma proteção de dados consistente em seu ambiente. Recomendamos que você use um KMS (KMS) como Amazon Web Services KMS, Google Cloud Platform KMS ou Azure Key Vault.

Para ambientes de preparo e produção, recomendamos que você habilite a criptografia com o gerenciamento de chaves do cliente ao provisionar seus clusters para evitar depender de equipes de desenvolvimento de aplicação para configurá-la posteriormente.

Para ambientes de desenvolvimento e teste, considere ignorar a criptografia com o gerenciamento de chaves do cliente para economizar custos. No entanto, se você armazenar dados confidenciais no Atlas, como para os setores de saúde ou serviços financeiros, considere habilitar a criptografia com o gerenciamento de chaves do cliente também em ambientes de desenvolvimento e teste.

Use os seguintes métodos para habilitar a criptografia com gerenciamento de chaves de cliente:

• IU do Atlas

• API de administração do Atlas

• Terraform

Para aprender a configurar a criptografia com o gerenciamento de chaves do cliente ao provisionar uma nova organização, projeto e cluster do Atlas, consulte Exemplos de Automação: Organizações, Projetos e Clusters do Atlas.

Classificação de Dados

Durante o processo de provisionamento, também recomendamos avaliar a sensibilidade de determinados campos em seus dados e classificá-los para determinar quais dados exigem criptografia e quais restrições globais devem ser aplicadas a esses grupos. Como diretriz geral, recomendamos que você aplique a Queryable Encryption em todos os campos sensíveis, além de seguir as práticas recomendadas de modelagem de dados.

Considere os seguintes níveis de classificação de dados como ponto de partida :

• Dados públicos: dados que representam pouco ou nenhum risco para a empresa se ocorrer difusão, alteração ou destruição não autorizada de dados. Embora a confidencialidade seja menos preocupação, você ainda deve aplicar controles de autorização para evitar a modificação ou destruição não autorizada de dados públicos.

  Exemplos: produtos, livretos, informações de treinamento

• Dados Privados: dados que representam um risco moderado para a empresa caso ocorra divulgação, alteração ou destruição não autorizada de dados. Por padrão, todos os dados institucionais que não são explicitamente classificados como dados restritos ou públicos devem ser considerados como dados privados. Aplique CSFLE ou Queryable Encryption em quaisquer campos que contenham dados privados, como PII.

  Exemplos: informações do cliente, contratos, custos do produto

• Dados restritos: dados que representam um risco significativo para a empresa se ocorrer difusão, alteração ou destruição não autorizada de dados. Aplique o mais alto nível de controles de segurança a dados restritos, incluindo CSFLE ou Queryable Encryption em todos os campos e criptografia com gerenciamento de chaves do cliente para segurança adicional.

  Exemplos: informações de receita, folha de pagamento, riscos de segurança

Configurar criptografia com o gerenciamento de chaves do cliente

Para habilitar a criptografia com o gerenciamento de chaves do cliente usando o Terraform, crie os seguintes recursos. Altere os IDs e nomes para usar os seus valores:

resource "mongodbatlas_cloud_provider_access_setup" "setup_only" {
  project_id    = var.atlas_project_id
  provider_name = "AWS"
}
resource "mongodbatlas_cloud_provider_access_authorization" "auth_role" {
  project_id = var.atlas_project_id
  role_id    = mongodbatlas_cloud_provider_access_setup.setup_only.role_id
  aws {
    iam_assumed_role_arn = aws_iam_role.test_role.arn
  }
}
resource "mongodbatlas_encryption_at_rest" "test" {
  project_id = var.atlas_project_id
  aws_kms_config {
    enabled                = true
    customer_master_key_id = aws_kms_key.kms_key.id
    region                 = var.atlas_region
    role_id                = mongodbatlas_cloud_provider_access_authorization.auth_role.role_id
  }
}
data "mongodbatlas_encryption_at_rest" "test" {
  project_id = mongodbatlas_encryption_at_rest.test.project_id
}
output "is_aws_kms_encryption_at_rest_valid" {
  value = data.mongodbatlas_encryption_at_rest.test.aws_kms_config.valid
}

 resource "mongodbatlas_encryption_at_rest" "test" {
  project_id = var.atlas_project_id
  azure_key_vault_config {
    enabled           = true
    azure_environment = "AZURE"
    tenant_id       = var.azure_tenant_id
    subscription_id = var.azure_subscription_id
    client_id       = var.azure_client_id
    secret          = var.azure_client_secret
    resource_group_name = var.azure_resource_group_name
    key_vault_name      = var.azure_key_vault_name
    key_identifier      = var.azure_key_identifier
  }
}
data "mongodbatlas_encryption_at_rest" "test" {
  project_id = mongodbatlas_encryption_at_rest.test.project_id
}
output "is_azure_encryption_at_rest_valid" {
  value = data.mongodbatlas_encryption_at_rest.test.azure_key_vault_config.valid
}

resource "mongodbatlas_encryption_at_rest" "test" {
  project_id = var.atlas_project_id
  google_cloud_kms_config {
    enabled                 = true
    service_account_key     = "{\"type\": \"service_account\",\"project_id\": \"my-project-common-0\",\"private_key_id\": \"e120598ea4f88249469fcdd75a9a785c1bb3\",\"private_key\": \"-----BEGIN PRIVATE KEY-----\\nMIIEuwIBA(truncated)SfecnS0mT94D9\\n-----END PRIVATE KEY-----\\n\",\"client_email\": \"my-email-kms-0@my-project-common-0.iam.gserviceaccount.com\",\"client_id\": \"10180967717292066\",\"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\",\"token_uri\": \"https://accounts.google.com/o/oauth2/token\",\"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\",\"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/my-email-kms-0%40my-project-common-0.iam.gserviceaccount.com\"}"
    key_version_resource_id = "projects/my-project-common-0/locations/us-east4/keyRings/my-key-ring-0/cryptoKeys/my-key-0/cryptoKeyVersions/1"
  }
}

Para mais opções de configuração e informações sobre este exemplo, consulte a documentação do Terraform.