Funcionalidades para conformidade com padrões externos

Use os seguintes recursos do Atlas para atender aos requisitos de conformidade.

Certificações e conformidade com os regulamentos

Para ajudar você a atender aos requisitos de segurança, conformidade e privacidade, o MongoDB Atlas tem como objetivo oferecer os mais altos níveis de conformidade com os padrões e regulamentações.

A plataforma de dados do Atlas é submetida a auditorias rigorosas e independentes de terceiros para verificar sua segurança, privacidade e controles organizacionais. Essas auditorias ajudam a garantir que a plataforma atenda aos requisitos de compliance e regulamentares, incluindo aqueles específicos para indústrias altamente regulamentadas.

O Atlas adere a frameworks de compliance, incluindo ISO/IEC 27001, SOC2 Tipo II, PCI DSS e outras listadas em nossa Central de Confiança do Atlas. Você pode visualizar e baixar atestações, relatórios e outros documentos de compliance e outros em nosso Portal de Confiança do Cliente.

MongoDB Atlas para o governo

O MongoDB Atlas para o Governo é a primeira plataforma de dados para desenvolvedores multinuvem totalmente gerenciada e autorizada no FedRAMP® Moderate que:

Usa um ambiente FedRAMP® autorizado, seguro, totalmente gerenciado e dedicado.
Oferece suporte aos requisitos e missões únicos do governo dos Estados Unidos.
Oferece um conjunto de recursos e escalabilidade necessários para modernizar aplicativos legados.

Políticas de recursos do Atlas

Para dar suporte aos seus requisitos de compliance, as Políticas de recursos do Atlas oferecem controles abrangentes para toda a organização, com o intuito de configurar e gerenciar recursos do Atlas em conformidade com suas melhores práticas de segurança, compliance e operação. Os Proprietários da Organização podem definir regras que rejam as ações dos usuários ao criar ou modificar recursos, como clusters, configurações de rede e configurações de projeto. Recomendamos a definição de uma política de recursos conforme os padrões da sua empresa no momento da criação da Organização.

As Políticas de recurso do Atlas apoiam seus objetivos de compliance, permitindo:

Exigir a versão mínima do TLS: imponha o uso de protocolos modernos TLS em todas as implantações do Atlas, aumentando a segurança e mitigando os riscos associados a versões mais antigas e menos seguras. Isso garante a adesão aos padrões contemporâneos de criptografia para todos os dados em trânsito.
Personalizar Cifras TLS Padrão: selecione um conjunto específico de cifras TLS permitidas para otimizar a segurança com base nas necessidades operacionais, eliminando vulnerabilidades associadas a métodos de criptografia legados. Isso permite o ajuste fino dos protocolos de criptografia para atender a requisitos específicos de compliance.
Restringir Modificações de Emparelhamento de VPC: habilite a comunicação segura entre redes por meio de conexões de emparelhamento de VPC estabelecidas, enquanto impede alterações de configuração. Os emparelhamentos em nível de projeto atuais permanecem ativos com suas tabelas de roteamento e protocolos de segurança existentes, permitindo que os clientes visualizem, mas não alterem esses relacionamentos VPC um-a-um e seus mecanismos de controle de rede associados.
Restrinja Modificações de Pontos de Extremidade Privados: mantenha a conectividade segura do serviço por meio das configurações existentes de pontos de extremidade privados, com acesso somente leitura. As conexões em nível de projeto permanecem funcionais com o esquema atual de endereçamento IP privado, enquanto os clientes podem visualizar, mas não modificar, esses pontos de conexão de serviço dedicados dentro de sua VPC.
Controlar Listas de Acesso IP: evite modificações não autorizadas nas listas de acesso IP, garantindo acesso consistente e controlado aos seus bancos de dados. Isso fortalece a segurança do banco de dados ao preservar limites de rede cuidadosamente definidos e protege contra alterações acidentais à configuração.
Defina Limites da Camada do Cluster: estabeleça diretrizes de implantação definindo limites máximos e mínimos de tamanho de cluster que os desenvolvedores devem seguir no provisionamento de recursos. Essa abordagem de definição de limites garante que as equipes possam implantar ambientes de tamanho adequado dentro de parâmetros aprovados pela organização, otimizando a utilização da infraestrutura enquanto são forçadas as políticas consistentes de alocação de recursos em todas as cargas de trabalho do projeto.
Definir a Exigência de Período de Manutenção: melhore a estabilidade da plataforma ao exigir um período de manutenção para todos os projetos. Esse controle de administração garante que as organizações estabeleçam um período previsível de atualização (sem ditar um prazo específico) para apoiar a manutenção consistente do sistema de acordo com as necessidades operacionais.
Defina o Provedor de Nuvem e Regiões: configure seu provedor de nuvem e distribua clusters por várias regiões e provedores para cumprir os requisitos de residência de dados e assegurar alta disponibilidade.
Bloquear uso do endereço IP curinga: para manter seu cluster acessível apenas a partir de endereços IP explicitamente permitidos, não inclua o endereço IP curinga na lista de acesso IP ou nas regras de firewall. O endereço IP curinga é 0.0.0.0/0 e permite acesso de qualquer lugar.

Para saber mais, consulte Políticas de recursos do Atlas.

O exemplo a seguir de política de recursos permite a criação de clusters na AWS:

{
  "name": "Only Allow Clusters on AWS",
  "policies": [
    {
      "body": "forbid ( principal, action == cloud::Action::\"cluster.createEdit\", resource) unless { context.cluster.cloudProviders   == [cloud::cloudProvider::\"aws\"] };"
    }
  ]
}

O exemplo a seguir cria um arquivo de políticas de recurso do Terraform que você pode usar para impor políticas de recurso em seu aplicativo. O arquivo impõe as seguintes políticas:

Restringe a modificação do cluster a apenas um provedor de nuvem especificado.
Proíbe o acesso ao cluster a partir de um endereço IP curinga.
Especifica um tamanho mínimo e máximo de cluster.
Impede a modificação de pontos de extremidade privados.

resource "mongodbatlas_resource_policy" "restrict_cloud_provider" {
  org_id = var.org_id
  name   = "restrict-cloud-provider"
  policies = [
    {
      body = <<EOF
        forbid (
            principal,
            action == ResourcePolicy::Action::"cluster.modify",
            resource
        )
        unless
          { context.cluster.cloudProviders == [ResourcePolicy::CloudProvider::"<cloud provider name>"] };
      EOF
    },
  ]
}
resource "mongodbatlas_resource_policy" "forbid_project_access_anywhere" {
  org_id = var.org_id
  name   = "forbid-project-access-anywhere"
  policies = [
    {
      body = <<EOF
        forbid (
            principal,
            action == ResourcePolicy::Action::"project.ipAccessList.modify",
            resource
        )
        when {context.project.ipAccessList.contains(ip("0.0.0.0/0"))};
    EOF
    },
  ]
}
resource "mongodbatlas_resource_policy" "restrict_cluster_size: {
    org_id = var.org_id
    name   = "restrict-cluster-size"
    policies = [
        {
            // restrict cluster size to a minimum of M30 and a maximum of M60
            body = <<EOF
               forbid (
                   principal,
                   action == ResourcePolicy::Action::"cluster.modify",
                   resource
               )
               when {
                   (context.cluster has minGeneralClassInstanceSizeValue && context.cluster.minGeneralClassInstanceSizeValue < 30)
                   || (context.cluster has maxGeneralClassInstanceSizeValue && context.cluster.maxGeneralClassInstanceSize > 60)
               };
            EOF
        },
    ]
}
resource "mongodbatlas_resource_policy" "prevent-modifications-private-endpoints" {
  org_id = var.org_id
  name   = "prevent-modifications-private-endpoints"
  policies = [
    {
      body = <<EOF
        forbid (
            principal,
            action == ResourcePolicy::Action::"privateEndpoint.modify",
            resource
        )
        when {context.project.privateEndpoints == [
                \"aws:<VPC_ENDPOINT_ID>",
                \"azure:<PRIVATE_ENDPOINT_RESOURCE_ID>:<PRIVATE_ENDPOINT_IP_ADDRESS>",
                \"gcp:<GCP_PROJECT_ID>:<VPC_NAME>"
            ]};
        EOF
    },
  ]
}

Criptografia

Você pode implementar a criptografia para garantir a segurança e a conformidade dos dados em todos os estágios do tratamento de dados. A criptografia é um dos requisitos mais comuns para garantir a conformidade com determinados padrões e o Atlas oferece um conjunto robusto de opções de criptografia para satisfazer os requisitos.

Por padrão, o Atlas criptografa os dados em trânsito. Para garantir a privacidade dos dados e o compliance regulatório, o Atlas exige TLS/SSL criptografado para as conexões com seus bancos de dados.
Por padrão, o Atlas criptografa todos os dados em repouso usando a criptografia de disco do provedor de nuvem. Ao usar backups na nuvem do Atlas, o Atlas usa criptografia AES-256 para criptografar todos os dados armazenados em buckets S3 em seus clusters do Atlas. Além disso, o Atlas suporta o uso do Amazon Web Services KMS, AKV e GCP para criptografar mecanismos de armazenamento e backups de provedor de nuvem. Para saber mais, consulte Encryption at rest usando o gerenciamento de chaves.
Você pode usar Queryable Encryption para proteger consultas em dados criptografados em campos selecionados e sensíveis em um documento armazenado no MongoDB. Com Queryable Encryption, as informações confidenciais permanecem protegidas mesmo quando os usuários executam consultas nos dados.
Use esquemas de criptografia não determinísticos bem pesquisados para manter um equilíbrio entre segurança e funcionalidade.
Com o Queryable Encryption, você pode executar as seguintes tarefas:
- Criptografe campos de dados confidenciais do lado do cliente.
- Armazene campos de dados confidenciais como dados criptografados totalmente aleatórios no lado do cluster do banco de dados , execute com Atlas.
- Execute queries expressivas nos dados criptografados.
O MongoDB conclui essas tarefas sem que o servidor tenha conhecimento dos dados que está processando.
Ao usar o Queryable Encryption, dados confidenciais são criptografados durante todo o seu ciclo de vida: em trânsito, em repouso, em uso, em registros e backups. Os dados só são descriptografados no lado do cliente, pois somente você tem acesso às chaves de criptografia.
É possível configurar a criptografia consultável usando os seguintes mecanismos:
- A criptografia automática permite que você execute operações de leitura e gravação criptografadas sem precisar adicionar chamadas explícitas para criptografar e descriptografar campos. Recomendamos a criptografia automática na maioria das situações, pois ela simplifica o processo de gravação de seu aplicação cliente . Com a criptografia automática, o MongoDB criptografa e descriptografa automaticamente campos em operações de leitura e gravação.
- Acriptografia explícita permite que você execute operações de leitura e gravação criptografadas por meio da biblioteca de criptografia do driver MongoDB. Você deve especificar a lógica da criptografia com essa biblioteca em todo o seu aplicação. A criptografia explícita fornece controle refinado sobre a segurança, ao custo de maior complexidade ao configurar collections e escrever código para os drivers do MongoDB . Com a criptografia explícita, você especifica como criptografar campos em seu documento para cada operação executada no banco de dados e inclui essa lógica em todo o aplicação.
  Para aprender mais, consulte Usar criptografia explícita.

Data Sovereignty

O Atlas oferece suporte a mais de 110 regiões em AWS, Azure e GCP. Essa distribuição global de localizações suportadas garante que você possa provisionar clusters e armazenar dados que estejam em conformidade com seus requisitos de soberania de dados e compliance. Compreender os requisitos de soberania de dados para qualquer aplicativo sendo criado no Atlas é necessário para garantir a conformidade com a governança adequada.

Você pode simplificar sua conformidade de soberania de dados implantando seus clusters Atlas em várias regiões. Ao implantar um paradigma de implantação multirregional, é possível particionar seus dados para que residam em regiões geográficas distintas. Por exemplo, você pode armazenar dados de clientes europeus na Europa e dados de clientes dos EUA nos EUA. Isso permite que cumprir as normas de soberania de dados e reduz a latência para os usuários que acessam dados de suas respectivas regiões.

Distribuição de snapshots de backup

Você pode distribuir snapshots de backup e dados de oplog por várias regiões. Por exemplo, você pode atender aos requisitos de compliance e armazenar backups em diferentes localizações geográficas para garantir a recuperação de desastre em caso de interrupções regionais. Para saber mais, consulte Distribuição de snapshots.

Política de compliance de backup

Você pode utilizar a Política de Compliance de Backup no Atlas para proteger dados críticos para os negócios. Você pode impedir que todos os snapshots de backup e dados de oplog armazenados no Atlas sejam modificados ou excluídos por um período de retenção predefinido por qualquer usuário, independentemente de sua função no Atlas .

Isso garante que seus backups sejam totalmente compatíveis com WORM (gravar uma vez, ler muitas). Apenas um usuário designado e autorizado pode desativar essa proteção após concluir um processo de verificação com o suporte do MongoDB e o departamento jurídico. Isso adiciona um atraso manual obrigatório e um período de espera para que um invasor não possa alterar a política de backup e exportar os dados. Para aprender mais,consulte Configurar uma Política de Compliance de Backup.

Voltar

Criptografia de dados

Auditoria e registro