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

O MongoDB Atlas oferece vários recursos e configurações para ajudá-lo a atender aos requisitos de segurança, conformidade e privacidade.

A plataforma de dados MongoDB Atlas passa por rigorosas auditorias independentes de terceiros para verificar seus controles de segurança, privacidade e organização. O Atlas adere a frameworks de compliance, incluindo ISO/IEC 27001, SOC2 Tipo II, PCI DSS e outras listadas em nosso Central de Confiança Atlas. Você pode visualizar e baixar atestados, relatórios de conformidade e outras documentações de conformidade em nosso Portal de confiança do cliente.

MongoDB Atlas para o governo

O MongoDB Atlas para governo é uma plataforma de dados para desenvolvedores de multinuvem totalmente gerenciada 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, evitando vulnerabilidades associadas a métodos de criptografia legado. Isso permite ajustar protocolos de criptografia para atender a requisitos de conformidade específicos.
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.
Controle as listas de acesso IP: evite modificações não autorizadas nas listas de acesso IP, mantendo o acesso de rede consistente e controlado aos seus bancos de dados. Isso aumenta a segurança do banco de dados , preservando limites de rede cuidadosamente definidos e protegendo contra alterações acidentais de 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 requisito de período de manutenção: Melhore a estabilidade da plataforma exigindo um período de manutenção para todos os projetos. Esse controle de administração permite que as organizações estabeleçam um período de atualização previsível (sem ditar um período de tempo específico) para suportar a manutenção consistente do sistema de acordo com as necessidades operacionais.
Definir fornecedor de nuvem e regiões: defina seu provedor de nuvem e distribua clusters em várias regiões e fornecedores para atender aos requisitos de residência de dados e garantir alta disponibilidade.
Bloquear o uso do endereço IP curinga: limite o acesso ao seu cluster apenas a endereços IP explicitamente permitidos, não incluindo o endereço IP curinga em sua lista de acesso IP ou nas regras de firewall. O endereço IP curinga é 0.0.0.0/0 e permite o 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 ampliar a segurança de dados em todos os estágios do tratamento de dados. A criptografia é um dos requisitos mais comuns para garantir a conformidade com os padrões de segurança do setor, 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. O Atlas exige TLS/SSL para criptografar 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 queries em dados criptografados em um conjunto selecionado de campos confidenciais em um documento armazenado no MongoDB. Com o Queryable Encryption, informações confidenciais permanecem protegidas mesmo quando os usuários executam queries 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.

Regionalização de dados

O Atlas é compatível com mais de 110regiões na AWS, no Azure e no GCP. Essa distribuição global de localizações com suporte permite o provisionamento de clusters e armazenar dados que estejam em conformidade com seus requisitos de localização de dados. Você também pode implantar seus clusters do Atlas em várias regiões. Ao implantar um paradigma de implantação multirregional paradigma de implantação multirregional, você pode particionar seus dados para residir em regiões distintas, cada uma localizada em uma região geográfica diferente. Por exemplo, você pode armazenar dados de cliente europeus na Europa e dados de cliente dos EUA nos EUA Isso permite flexibilidade na escolha da localização 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 em várias regiões. Por exemplo, você pode armazenar backups em diferentes localizações geográficas para habilitar a recuperação de desastre em caso de interrupções regionais ou para manter backups consistentes com suas opções de localização de dados. Para saber mais, veja Distribuição de snapshot.

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. Esse recurso impede 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 ajuda você a garantir que seus backups sejam totalmente compatíveis com WORM (Gravar uma vez, ler muitas vezes). Somente um usuário designado e autorizado pode desativar essa proteção depois de concluir um processo de verificação com o suporte do MongoDB . Isso adiciona um atraso manual obrigatório e um período de resfriamento para que um invasor não possa alterar facilmente a política de backup e exportar os dados. Para saber mais, veja Configure uma Política de compliance de backup.

Voltar

Criptografia de dados

Conformidade