O Atlas oferece diversos recursos de criptografia para proteger dados em trânsito, em repouso e em uso, garantindo a segurança dos dados durante todo o seu ciclo de vida.
Recursos 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 .
Criptografia em descanso
A criptografia em descanso garante que todos os dados no disco sejam criptografados e só possam ser visualizados após serem descriptografados por um processo ou aplicativo autorizado.
No Atlas, os dados dos clientes são automaticamente criptografados em repouso usando AES-256. Este processo utiliza a criptografia de disco do seu provedor de nuvem, com o provedor gerenciando as chaves de criptografia. Este processo não pode ser desativado.
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 trazendo sua própria chave (BYOK). Esta é a chave mestra do cliente (CMK) que você adiciona com um key management service (KMS), como AWS KMS, Google Cloud KMS ou Azure Key Vault. O recurso BYOK oferece criptografia em nível de arquivo e é equivalente à Criptografia transparente de dados (TDE), atendendo aos requisitos corporativos de TDE. A criptografia com gerenciamento de chaves do 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.
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.
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.
Recomendações para o Atlas Data Encryption
Implantações de região única não possuem considerações únicas para criptografia de dados. Veja a próxima seção para "Todas as recomendações do paradigma de implantação".
Em implantações multirregionais e multinuvem, você pode habilitar a criptografia em nível de banco de dados trazendo sua própria chave gerenciada pelo cliente (BYOK).
Alguns provedores KMS oferecem suporte a funcionalidades multirregionais. Por exemplo:
O GCP KMS oferece suporte para implantação multirregional e replicação automática de chaves.
No Amazon Web Services KMS, você precisa definir explicitamente as chaves como multirregional e replicá-las para todas as regiões em que o Atlas é implantado. Para saber mais, consulte Criar chaves de réplica de várias regiões no Amazon Web Services.
No entanto, em caso de uma interrupção regional que afete o ponto de extremidade KMS configurado, a integração do Atlas com um provedor KMS não oferece failover automático do mecanismo de conexão ou acesso ao KMS entre regiões.
Se o provedor KMS configurado se tornar indisponível, o Atlas realiza validações periódicas da configuração do seu KMS. Se as credenciais do provedor KMS se tornarem inválidas ou a chave de criptografia for excluída ou desativada, o Atlas encerrará os processos mongod e mongos na próxima verificação de validação agendada e notificará você por e-mail, refletindo o status na IU do Atlas.
Quando o Atlas não consegue se conectar ao seu provedor de gerenciamento de chaves, ele não interrompe seus processos. Portanto, se o acesso ao KMS for interrompido devido a um problema regional, o cluster poderá continuar em execução até que você o reinicie manualmente ou até que a validação falhe de maneira mais crítica.
Por esse motivo, se o KMS ficar inativo, você pode alterar a configuração. Para recuperar o acesso à chave de criptografia em um cenário de interrupção multirregional, você deve alterar manualmente a configuração no Atlas para apontar para uma instância ou configuração do KMS diferente e acessível.
Se você usar pontos de extremidade privados para se conectar ao KMS, deve estabelecer um ponto de extremidade privado de cada região onde os nós do Atlas estão implantados de volta ao KMS primário. Isso é para garantir que a configuração permaneça válida durante as verificações periódicas e, durante as configurações iniciais ou rotações de chaves, cada nó precisa acessar a chave mestra do cliente armazenada no KMS primário.
Em resumo, a integração do Atlas com os provedores BYOK para criptografia em descanso não suporta failover multirregional automaticamente, e você deve alterar manualmente a configuração.
Todas as Recomendações de Paradigmas de Implantação
As seguintes recomendações se aplicam a todos os paradigmas de implantação.
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:
Para aprender a configurar a criptografia com o gerenciamento de chaves do cliente no provisionamento de 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
Exemplos de Automação: Criptografia de Dados do Atlas
Dica
Para exemplos de Terraform que impõem nossas recomendações em todos os colunas, consulte um dos seguintes exemplos no Github:
Os exemplos seguintes configuram a criptografia com o gerenciamento de chaves do cliente usando as ferramentas Atlas para automação.
Antes de configurar a criptografia com o gerenciamento de chaves do cliente, é necessário criar suas organizações, projetos e clusters. Para aprender mais, veja Exemplos de automação: organizações, projetos e clusters do Atlas.
Configurar criptografia com o gerenciamento de chaves do cliente
Para seus ambientes de desenvolvimento e teste, considere omitir a criptografia com gerenciamento de chaves do cliente para reduzir custos, a menos que você esteja em um setor altamente regulamentado ou armazene dados sensíveis. Para aprender mais, veja Recomendações para organizações, projetos e clusters do Atlas.
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:
Dica
Para um exemplo de configuração completo, consulte Exemplo do Provedor de Terraformes do Atlas.
Como alternativa, para simplificar o processo de configuração, você pode usar o módulo Terraform criptografia em descanso.
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 }
Dica
Para um exemplo de configuração completo, consulte Exemplo do Provedor de Terraformes do Atlas.
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.
Para seus ambientes de staging e produção, recomendamos habilitar a criptografia com gerenciamento de chaves do cliente ao provisionar seus clusters. Para aprender mais, veja Recomendações para organizações, projetos e clusters do Atlas.
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:
Dica
Para um exemplo de configuração completo, consulte Exemplo do Provedor de Terraformes do Atlas.
Como alternativa, para simplificar o processo de configuração, você pode usar o módulo Terraform criptografia em descanso.
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 }
Dica
Para um exemplo de configuração completo, consulte Exemplo do Provedor de Terraformes do Atlas.
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.