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 ajudá-lo 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 conformidade normativa.

A plataforma de dados da Atlas passa por rigorosas auditorias independentes de terceiros para verificar seus controles de segurança, privacidade e organização. Essas auditorias ajudam a garantir que a plataforma atenda aos requisitos regulatórios e de compliance, incluindo aqueles específicos para setores altamente regulamentados.

O Atlas adere a estruturas de compliance , incluindo ISO/IEC,27001 SOC2 TypeII, PCI DSS e outras listadas em nosso Atlas Trust Center. 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 é a primeira plataforma de dados para desenvolvedores de multinuvem totalmente gerenciada autorizada no FedRAMP Moderate que:

Usa um ambiente autorizado FedRAMP seguro, totalmente gerenciado e dedicado.
Suporta os requisitos e tarefas exclusivos do governo dos EUA.
Oferece um conjunto de funcionalidades e a escalabilidade necessária para modernização de aplicativos legado .

Políticas de recursos do Atlas

Para dar suporte aos seus requisitos de conformidade, as Políticas de Recursos do Atlas oferecem controles em toda a organização para configurar e gerenciar recursos do Atlas em alinhamento com suas práticas recomendadas de segurança, conformidade e operacionais. Os proprietários da organização podem definir regras que regem as ações do usuário ao criar ou modificar recursos como clusters, configurações de rede e configurações de projeto . Recomendamos que você defina uma política de recursos de acordo com os padrões da sua empresa no momento da criação da organização.

As Políticas de Recursos do Atlas suportam seus objetivos de conformidade permitindo que você:

Aplicar a versão mínima do TLS: Obrigar o uso de protocolos TLS modernos em todos os sistemas do Atlas , aumentando a segurança e reduzindo os riscos associados a versões mais antigas e menos seguras. Isso garante a adesão aos padrões de criptografia contemporâneos 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 e, ao mesmo tempo, eliminar as vulnerabilidades associadas aos 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 e evite alterações de configuração. Os atuais peerings de nível de projeto permanecem ativos com suas tabelas de roteamento e protocolos de segurança existentes, permitindo que os clientes visualizem, mas não alterem, esses relacionamentos um-para-um da VPC e seus mecanismos de controle de rede associados.
Restringir modificações em endpoints privados: mantenha a conectividade de serviço segura por meio de configurações de endpoint privado existentes com acesso somente leitura. As conexões de nível de projeto permanecem funcionais com seu esquema de endereçamento IP privado atual, 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, garantindo um 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.
Definirlimites de camada de cluster: defina as proteções da implantação estabelecendo limites máximos e mínimos de tamanho de cluster que os desenvolvedores devem aderir ao provisionar recursos. Essa abordagem de definição de limites garante que as equipes possam implantar ambientes de tamanho adequado dentro dos parâmetros aprovados pela organização, otimizando a utilização da infraestrutura e, ao mesmo tempo, aplicando políticas consistentes de alocação de recursos em todas as cargas de trabalho do projeto .
Definirrequisito de janela de manutenção: Melhore a estabilidade da plataforma exigindo uma período de manutenção para todos os projetos. Esse controle de administração garante que as organizações estabeleçam um período de atualização previsível (sem ditar um período de tempo específico) para dar suporte à 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: certifique-se de que seu cluster esteja acessível somente a partir de endereços IP explicitamente permitidos, não incluindo o endereço IP curinga em sua lista de acesso IP ou 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 de política de recursos a seguir 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 recursos do Terraform que você pode usar para impor políticas de recursos em seu aplicação. O arquivo aplica 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 endpoints 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 dados em trânsito. Para garantir a privacidade dos dados e a conformidade com as normas, 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 a criptografia AES- para256 criptografar todos os dados armazenados em buckets S em seus clusters do Atlas . Além3 disso, o Atlas suporta o uso de AWS 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 a conformidade com a soberania de dados implantando os clusters do Atlas em várias regiões. Ao implantar um paradigma de implantação de multirregional, você pode particionar seus dados para residir em regiões distintas, cada uma localizada em uma região geográfica diferente. Por exemplo, é possível armazenar dados de cliente europeus na Europa e dados de cliente dos EUA nos EUA. Isso permite que você cumpra as normas de soberania de dados e reduz a latência para 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