Arquitetura

de Segurança
do MongoDB
Índice
Introdução 3
Requisitos para proteção de dados de aplicativos modernos 4
Gerenciamento de Acesso do Usuário – Autenticação 7
Gerenciamento de Direitos do Usuário – Autorização 10
Auditoria 12
Criptografia 13
Controle Ambiental e de Processos 15

Recursos de segurança do MongoDB 16

MongoDB Enterprise Advanced 17
Habilitação de controle de acesso e aplicação de autenticação 18
Autenticação do MongoDB
Autorização do MongoDB 23
Auditoria do MongoDB 28
Criptografia do MongoDB 30
Ambiente e processos 39

MongoDB Atlas: Banco de Dados como um Serviço

para o MongoDB 46
Conclusão 49
Introdução
No mundo rico em dados de hoje, as plataformas de banco de dados estão sob
constante ataque de hackers. A frequência e a gravidade das violações de dados
continuam aumentando. Analistas do setor preveem que crimes cibernéticos
custarão 6 trilhões de dólares à economia global anualmente até 2021.
As organizações enfrentam um ataque de novas classes de ameaças e agentes de
ameaças com phishing, ransomware e roubo de propriedade intelectual crescendo mais
de 50% ano a ano, e infraestrutura base sujeita a interrupções crescentes. Com os
bancos de dados armazenando os ativos de informações mais importantes de uma
organização, protegê-los é uma prioridade para os administradores
Este artigo discute as melhores práticas com relação à segurança no MongoDB.
Primeiramente, examinaremos os requisitos para proteger dados de aplicativos
modernos, seguido de um aprofundamento nos recursos que compõem a abordagem
holística de segurança do MongoDB. Embora o MongoDB Community Server tenha
recursos básicos de segurança, como autenticação e autorização de usuário, você
encontrará recursos avançados de segurança, como criptografia em repouso,
disponíveis no MongoDB Enterprise Advanced e no serviço de banco de dados global
em nuvem totalmente gerenciado MongoDB Atlas.
Como qualquer bom piloto de avião, se você estiver procurando por uma lista de
verificação de coisas a serem consideradas para bloquear sua implantação do MongoDB,
confira a Lista de Verificação de Segurança do MongoDB. Esta lista fornece as melhores
práticas a serem seguidas ao autohospedar clusters do MongoDB. Caso esteja utilizando
o MongoDB Atlas, confira os Recursos e configuração de segurança do MongoDB Atlas
para obter as melhores práticas a serem seguidas ao utilizar o serviço de banco de dados
em nuvem global.
O MongoDB oferece todos os recursos necessários para defender, detectar e controlar
com segurança o acesso a dados valiosos e sigilosos, além de fornecer uma base para
atender às exigências de novas iniciativas de conformidade regulatória.

3
Arquitetura de
segurança do MongoDB

Requisitos para
proteção de dados
de aplicativos
modernos

4
Em face do aumento das ameaças na última década,
juntamente com a preocupação com a privacidade
individual intensificada , indústrias e governos em todo o
mundo iniciaram em uma série de iniciativas destinadas a
aumentar a segurança, reduzir fraudes e proteger
informações de identificação pessoal (PII), incluindo:
o PCI DSS para gerenciamento de informações do titular do cartão
o Padrões HIPAA para gerenciamento de informações de saúde
o GDPR e CCPA para a proteção, respectivamente, da
privacidade de dados dos cidadãos da UE e da
Califórnia
o FISMA para garantir a segurança dos dados no governo federal
o FERPA para proteger a privacidade dos registros educacionais dos
alunos
o O Arranjo Transfronteiriço para a Garantia da Privacidade da
Cooperação Econômica Ásia-Pacífico (CPEA), criando uma
estrutura para cooperação regional na aplicação de leis de
privacidade

Além dessas iniciativas, novos regulamentos estão sendo

desenvolvidos todos os anos para lidar com ameaças
emergentes e novas demandas por controles mais rígidos que
regem o uso de dados.

5
Arquitetura de
segurança do MongoDB

Cada conjunto de regulamentos define exigências de segurança e

auditoria que são exclusivas de um setor ou aplicativo específico,
e a conformidade é avaliada por projeto.
É importante reconhecer que a conformidade só pode ser alcançada
aplicando uma combinação de controles que podemos resumir como
Pessoas, Processos e Plataformas:
o Pessoas define funções,
Pessoas atribuições e
responsabilidades
Controle de Acesso
específicas.
o Processos define
princípios operacionais e
Criptografar Auditoria
práticas de negócios.

Processo Plataformas
o Plataformas define as
tecnologias utilizadas para
Figura 1: Arquitetura de segurança de ponta a ponta do MongoDB
armazenamento e
processamento de dados.

Apesar das diferenças entre os diferentes regulamentos, existem

requisitos fundamentais comuns entre todas as diretivas, incluindo:
o Restrição do acesso a dados, imposto por meio de privilégios e funções predefinidos
o Medidas de proteção contra divulgação, perda, destruição ou dano de dados
pessoais, seja acidental ou maliciosa
o A separação de funções no acesso e tratamento de dados
o Registro de atividade de usuários, funcionários administrativos e aplicativo com um banco de dados

Essas exigências informam a arquitetura de segurança do MongoDB, com as melhores

práticas para a implementação de um ambiente de gerenciamento de dados seguro e
compatível.

6
Uma arquitetura de segurança holística deve cobrir o seguinte:

Gerenciamento de acesso do usuário para restringir o acesso a

dados confidenciais, implementado por meio de controles de
autenticação e autorização

Auditoria de ações de banco de dados para análise forense

Proteção de dados por meio de criptografia de dados em trânsito

na rede, em uso no banco de dados e em repouso em
armazenamento persistente

Proteção ambiental para garantir a segurança do sistema

operacional, rede e outras infraestruturas de banco de
dados do host

As exigências para cada um desses elementos são as seguintes:

Gerenciamento de acesso do usuário –

Autenticação
A autenticação é projetada para confirmar a identidade das entidades que
acessam o banco de dados. Neste contexto, as entidades são definidas como:
o Usuários que precisam acessar o banco de dados como parte da sua
função comercial diária
o Administradores (ou seja, sysadmins, DBAs, equipe de GQ) e desenvolvedores
o Sistemas de software, incluindo servidores de aplicativos, ferramentas de
relatórios e conjuntos de backup e gerenciamento
o Nós físicos e lógicos nos quais o banco de dados é executado. Os bancos de dados
podem ser distribuídos em múltiplos nós para operações de escalonamento e
para garantir a operação contínua em caso de falha ou manutenção do sistema.
7
Arquitetura de
segurança do MongoDB

As melhores práticas para autenticação são as seguintes:

Criar credenciais de segurança
Crie credenciais de login para cada entidade (usuário, processo ou dispositivo)
que precisará de acesso ao banco de dados e evite criar um único login de
“admin” compartilhado por múltiplas entidades.

Ao criar credenciais, é mais fácil definir, gerenciar e rastrear o acesso ao

sistema para cada entidade. Caso as credenciais sejam comprometidas, essa
abordagem facilita a revogação do acesso sem interromper outras entidades
que precisam acessar o banco de dados.
Desenvolvedores, administradores e DBAs devem ter credenciais exclusivas
para acessar o banco de dados. Quando os logins são compartilhados, pode ser
impossível
identificar quem tentou diferentes operações e elimina a capacidade de
atribuir permissões refinadas. Com logins exclusivos, os funcionários que
deixam o projeto ou deixam a organização podem ter seu acesso anulado
sem afetar outras contas de usuário.
A criação de credenciais de login separadas para cada aplicativo que acessará
o banco de dados é uma prática recomendada. À medida que novos
aplicativos são introduzidos e aplicativos antigos são removidos, essa
abordagem ajuda a gerenciar o acesso. Alguns clientes do MongoDB criam
múltiplos logins para diferentes serviços em um único aplicativo, que são
registrados em trilhas de auditoria e registros de consulta.
A Autenticação Interna deve ser configurada entre nós em um conjunto de
réplicas e clusters fragmentados. Isso impede que instâncias não autorizadas
ingressem em um cluster de banco de dados, impedindo a cópia ou
movimentação ilícita de dados para nós não seguros.

8
Oferecer suporte ao gerenciamento de
acesso de usuário centralizado e de
banco de dados
Os bancos de dados devem fornecer a capacidade de
gerenciar a autenticação do usuário dentro do próprio banco
de dados, geralmente por meio de um mecanismo de
Desafio/Resposta, ou por meio da integração com sistemas de
gerenciamento de identidade de toda a organização.
A integração do MongoDB à infraestrutura de segurança da
informação existente reforça o controle centralizado e
padronizado sobre o acesso do usuário. Por exemplo, se o
acesso de um usuário precisar ser revogado, a atualização pode
ser feita em um único repositório e aplicada instantaneamente
em todos os sistemas, incluindo o MongoDB.

Aplicar políticas de senha

As senhas devem seguir os requisitos mínimos de
complexidade estabelecidos pela organização e devem ser
redefinidas periodicamente. As senhas de baixa entropia
podem ser fáceis de quebrar, mesmo que sejam
criptografadas. Senhas de alta entropia podem ser
comprometidas com tempo suficiente.

9
Arquitetura de
segurança do
MongoDB

Gerenciamento de Direitos do Usuário –

Autorização
Depois que uma entidade é autenticada, a autorização rege o que
essa entidade tem direito a fazer no banco de dados. Os privilégios
são atribuídos a funções de usuário que definem um conjunto
específico de ações que podem ser executadas no banco de dados. As
melhores práticas incluem:

Conceder acesso mínimo a entidades

As entidades devem receber acesso mínimo ao banco de dados de que
precisam para desempenhar sua função. Se um aplicativo requer acesso
a um banco de dados lógico, ele deve ser restrito a operações somente
nesse banco de dados e impedido de acessar outros bancos de dados
lógicos. Isso ajuda a proteger contra acesso malicioso e acidental ou
modificação não autorizada de dados.

Agrupar privilégios de acesso comum em funções.

As entidades geralmente podem ser agrupadas em "funções", como
"Desenvolvedor", "DBA", "Sysadmin" e "Servidor de aplicativos". As
permissões para uma função podem ser gerenciadas centralmente e os
usuários podem ser adicionados ou removidos das funções conforme
necessário. O uso de funções ajuda a simplificar o gerenciamento do
controle de acesso definindo um único conjunto de regras que se
aplicam a classes específicas de entidades, em vez de defini-las
individualmente para cada usuário.

10
Controlar quais ações uma entidade pode executar.
Ao conceder acesso a um banco de dados, deve-se considerar quais
ações ou comandos específicos cada entidade deve ter permissão
para executar. Por exemplo, um aplicativo pode precisar de
permissões de leitura/gravação no banco de dados, enquanto uma
ferramenta de relatório pode estar restrita a uma permissão somente
de leitura. Alguns usuários podem receber privilégios que lhes
permitem inserir novos dados
ao banco de dados, mas não atualizar ou excluir dados existentes.
Deve-se ter cuidado para garantir que somente o conjunto mínimo
de privilégios seja fornecido. As credenciais das contas mais
privilegiadas podem comprometer todo o banco de dados se forem
hackeadas internamente ou por um invasor externo.

Controlar o acesso a dados confidenciais.

Para evitar o surgimento de silos de dados, deve ser possível
restringir permissões a campos individuais, com base em privilégios
de segurança. Por exemplo, alguns campos de um registro podem
ser acessíveis a todos os usuários do banco de dados, enquanto
outros contendo informações confidenciais, como PII, devem ser
restritos a usuários com autorização de segurança específica.

11
Arquitetura de
segurança do MongoDB

Auditoria
Ao criar trilhas de auditoria, as alterações nos dados e na
configuração do banco de dados podem ser capturadas para cada
entidade que acessa o banco de dados, fornecendo um registro para
conformidade e análise forense. A auditoria também pode detectar
tentativas de acesso a dados não autorizados.

Monitorar as alterações na configuração do banco de dados.

Sempre que uma configuração de banco de dados é alterada, a
ação deve ser registrada em um registro de auditoria que deve
incluir a ação de alteração, a identidade da entidade e um
registro temporal.

Monitorar as alterações nos dados.

Deve ser possível configurar a trilha de auditoria para capturar todas
as consultas ou operações de gravação no banco de dados. No
entanto, deve-se ter cuidado ao configurar essa regra para
aplicativos. Por exemplo, se o aplicativo estiver inserindo dezenas de
milhares de registros por segundo, gravar cada operação no registro
de auditoria irá impor uma sobrecarga de desempenho ao banco de
dados. A equipe do projeto deve determinar quaisquer
compensações entre desempenho e requisitos de auditoria. Deve ser
possível filtrar eventos que são capturados, por exemplo, somente
usuários, endereços IP ou operações específicas.

12
Criptografia
A criptografia é a codificação de dados críticos sempre que
estiverem em trânsito, em repouso ou em uso, permitindo que
apenas entidades autorizadas realizem sua leitura. Os dados serão
protegidos no caso de “bisbilhoteiros” ou hackers obterem acesso
ao servidor, rede, sistema de arquivos ou banco de dados.

Criptografar conexões ao banco de dados.

Todo o acesso de usuários ou aplicativos ao banco de dados deve ser
por meio de canais criptografados, incluindo conexões estabelecidas
por meio de drivers, linha de comando ou shell, bem como sessões
de acesso remoto aos próprios servidores de banco de dados. As
comunicações internas entre os nós do banco de dados também
devem ser criptografadas, ou seja, o tráfego replicado entre os nós
de um cluster de banco de dados.

Criptografar dados em repouso.

Uma das ameaças mais comuns à segurança vem de ataques que
ignoram o banco de dados em si e visam o sistema operacional
subjacente e o armazenamento físico de servidores de teste/GQ e de
produção ou dispositivos de backup, para acessar dados brutos. A
criptografia em disco dos arquivos de dados e backups do banco de
dados atenua essa ameaça.

13
Arquitetura de
segurança do MongoDB

Assinar e alternar as chaves de criptografia.

As chaves de criptografia para criptografia de rede e disco
devem ser alternadas periodicamente. Os canais de
criptografia TLS devem utilizar certificados assinados para
garantir que os clientes possam certificar as credenciais que
recebem dos componentes do servidor.

Aplicar criptografia forte.

O banco de dados deve suportar FIPS (Padrão Federal de
Processamento de Informação) 140-2 para garantir a
implementação de algoritmos de criptografia seguros.

Criptografar os dados em uso.

Quando seus requisitos exigirem o mais alto nível de proteção
de dados, aproveite a criptografia no nível do campo (FLE) do
lado do cliente. A FLE executa a criptografia e a descriptografia
no cliente, garantindo que os dados nunca sejam expostos em
texto simples enquanto estiverem no servidor. Com a FLE,
mesmo uma conta de administrador composta realizando a
leitura despejos de memória não pode descriptografar seus
dados.

14
Controle Ambiental e de Processos
O ambiente no qual o banco de dados e a infraestrutura subjacente
estão sendo executados deve ser protegido com controles físicos e
lógicos. Eles são aplicados no ambiente de implantação subjacente,
em vez de no próprio banco de dados, e incluem:
° Instalação de firewalls
° Configurações de rede
° Definição de permissões do sistema de arquivos
° Criação de controles de acesso físico ao ambiente de TI

LDAP

Diretório de usuários
KERBEROS
corporativos

Figura 2: Integração do MongoDB com controles de acesso de usuário centralizados

Como erros de configuração e sistemas não corrigidos são uma das maiores
causas do sucesso das invasões aos mecanismos de segurança, há uma série
de processos operacionais que devem ser adotados para promover e reforçar
ainda mais a operação segura, incluindo:

° Treinamento de DBA e desenvolvedores

° Provisionamento, monitoramento e backup de banco de dados
° Manutenção do banco de dados, ou seja, aplicação dos patches mais recentes

15
Arquitetura de
segurança do
MongoDB

Recursos de
segurança do
MongoDB

Com controles abrangentes para

gerenciamento de direitos de usuário,
auditoria e criptografia, juntamente com as
melhores práticas de proteção ambiental, o
MongoDB pode atender aos requisitos de
melhores práticas descritos anteriormente.

16
A seção a seguir discute a arquitetura de segurança do
MongoDB. Consulte também a Lista de verificação de
segurança do MongoDB para obter uma lista de medidas
de segurança que você deve implementar para proteger
sua instalação do MongoDB.
MongoDB Enterprise Advanced
O MongoDB Enterprise Advanced é a versão de produção certificada e
com suporte do MongoDB para execução em sua infraestrutura, com
recursos avançados de segurança, incluindo autenticação e
autorização LDAP, suporte a Kerberos, criptografia de dados em
repouso, conformidade com FIPS e manutenção de registros de
auditoria.
Esses recursos estendem a estrutura de segurança já abrangente do
MongoDB, que inclui controle de acesso baseado em função, certificados
PKI, criptografia de transporte de dados TLS, visualizações somente de
leitura e criptografia no nível de campo do lado do cliente. Você pode obter
acesso a todos os recursos do MongoDB Enterprise gratuitamente para
ambientes de avaliação e desenvolvimento.
Embora o MongoDB Enterprise Advanced seja o foco deste artigo, os
principais recursos do MongoDB Atlas estão resumidos na seção “Por que o
MongoDB Atlas?” deste artigo, pois referências ocasionais são feitas ao
Atlas ao longo deste artigo. O MongoDB Atlas é um serviço global de banco
de dados em nuvem disponível em todas as principais plataformas de
nuvem. Baixe o whitepaper Controles de Segurança do MongoDB Atlas para
saber mais sobre a arquitetura de segurança específica do serviço Atlas.

17
Arquitetura de
segurança do MongoDB

Ativação do controle de acesso

e aplicação de autenticação
Da versão 3.6 para cima, o MongoDB só permite conexões originadas do
host local. Por padrão, todas as conexões remotas são negadas, a menos
que o endereço IP ou intervalo CIDR correspondente tenha sido
explicitamente adicionado à Configuração do MongoDB. Esse conceito
de whitelist de IP e desativado por padrão também é utilizado no
MongoDB Atlas.
Antes de vincular a endereços IP externos, você deve habilitar o controle
de acesso e avaliar outras medidas de segurança listadas na Lista de
Verificação de Segurança para evitar acesso não autorizado.

Autenticação do MongoDB
Autenticação é o processo de validação da identidade da entidade
que faz uma conexão com o MongoDB. O MongoDB suporta vários
mecanismos de autenticação, incluindo:
° SCRAM (Padrão)
° Autenticação com Certificado x.509
° Autenticação com proxy LDAP
° Autenticação com Kerberos

Esses mecanismos permitem que o MongoDB se integre

ao seu sistema de autenticação existente e atenda aos
requisitos de diferentes ambientes.

18
Autenticação do banco de dados
Ao adicionar uma entidade como um usuário, você cria o usuário em
um banco de dados específico. Esse banco de dados é conhecido como
“banco de dados de autenticação” para o usuário. Um usuário pode ter
privilégios em diferentes bancos de dados, ou seja, os privilégios de um
usuário não estão limitados ao seu banco de dados de autenticação.

admin de uso
db.createUser(
{
user:
“reportsUser”,
pwd: “12345678”,
roles: [
{ role: “read”, db: “reporting” },
{ role: “read”, db: “products” },
{ role: “read”, db: “sales” },
{ role: “readWrite”, db: “accounts” }
]
}
)|

Se a arquitetura de sua aplicação permitir, é mais fácil, do ponto de

vista do gerenciamento, utilizar um banco de dados específico como
“admin” em vez de criar as entidades dentro de seus respectivos
bancos de dados de aplicação.
Fora o benefício de gerenciamento, não há outra vantagem em
nenhuma das duas estratégias. Se você optar por criar usuários em
bancos de dados diferentes de “admin”, certifique-se de incluir o
componente de banco de dados que identifica o banco de dados de
autenticação na cadeia de caracteres de conexão.

19
Arquitetura de
segurança do MongoDB

Autenticação LDAP
LDAP é amplamente utilizado por muitas organizações para padronizar e simplificar a
maneira como um grande número de usuários é gerenciado em sistemas e aplicativos
internos. Em muitos casos, LDAP também é utilizado como autoridade centralizada
para o controle de acesso do usuário a fim de garantir que as políticas de segurança
interna estejam em conformidade com as diretrizes corporativas e regulatórias. Com a
integração do LDAP, o MongoDB Enterprise Advanced pode tanto autenticar quanto
autorizar usuários diretamente na infraestrutura LDAP existente para aproveitar
arquiteturas de controle de acesso centralizado.

Revise a Documentação de integração LDAP para saber mais sobre

LDAP e MongoDB Enterprise Advanced.

Autenticação com Kerberos

Com o MongoDB Enterprise Advanced, há suporte para autenticação usando um
serviço Kerberos. Kerberos é um protocolo de autenticação padrão do setor para
sistemas cliente/servidor grandes, permitindo que o cliente e o servidor verifiquem a
identidade um do outro. Com suporte a Kerberos, MongoDB pode aproveitar a
infraestrutura e os processos de autenticação existentes, incluindo o Microsoft
Active Directory.

Antes que os usuários possam se autenticar no MongoDB usando Kerberos, eles

devem primeiro ser criados e receber privilégios no MongoDB.

O processo para fazer isso, juntamente com uma lista de verificação de

configuração completa, é descrito no Tutorial do MongoDB e Kerberos.

20
Autenticação com Certificado x.509
Com suporte para certificados x.509, o MongoDB pode ser integrado à
infraestrutura de segurança da informação e autoridades de certificação
existentes, oferecendo suporte de autenticação de usuário e entre nós.
Os usuários podem ser autenticados no MongoDB utilizando
certificados de cliente em vez de senhas mantidas por conta própria.
A autenticação entre clusters e a comunicação entre os nós do MongoDB
podem ser protegidas com certificados x.509 de membro em vez de
arquivos de chave, garantindo controles de participação mais rígidos com
menos sobrecarga administrativa, ou seja, eliminando a senha
compartilhada utilizada pelos arquivos de chave. Os certificados x.509
podem ser usados por nós para verificar sua participação em conjuntos
de réplicas do MongoDB e clusters fragmentados.

FUNÇÃO DE SERVIDOR DE APLICATIVO

APLICATIVO
o Ler e gravar no banco de dados dos aplicativos

RELATÓRIO

FUNÇÃO DE BI
o Somente leitura no banco de dados do aplicativo

ETL

FUNÇÃO DE DBA
o Ler e gravar no banco de dados dos aplicativos
DBA
o Administração no banco de dados do aplicativo
o Administração no cluster do MongoDB

Figura 3: Funções de usuário definidas do MongoDB permitem separações de tarefas

21
Arquitetura de segurança
do MongoDB

Você pode aproveitar uma Autoridade de Certificação (CAs) única

ou separada para validação de certificado em uma instância de
servidor com base no tipo de comunicação.
Por exemplo, utilize uma CA entre as comunicações de cliente e
servidor de entrada ou saída e outra CA para comunicações de
cluster internas entre membros do cluster.
Apesar de você estar utilizando certificados ou arquivos de chave,
ambos podem ser modificados sem a necessidade de desativar
seu cluster, mesmo ao modificar o Nome Distinto.

As instruções para configuração estão descritas no

tutorial de certificados x.509 e MongoDB.

22
MongoDB e Microsoft
Active Directory
O MongoDB Enterprise Advanced oferece suporte para
autenticação utilizando o Microsoft Active Directory com
Kerberos e LDAP. O controlador do domínio do Active Directory
autentica os usuários e servidores do MongoDB em execução
em uma rede Windows, novamente para aproveitar o controle
de acesso centralizado.

Autorização do MongoDB
A autorização é o processo de determinar as permissões
específicas que uma entidade tem no banco de dados. O
MongoDB emprega o controle de acesso baseado em função
(RBAC) para controlar o acesso a um sistema MongoDB. Um
usuário recebe uma ou mais funções que determinam o acesso
do usuário aos recursos e operações do banco de dados. Fora
das atribuições de função, o usuário não tem acesso ao
sistema.

23
Arquitetura de segurança
do MongoDB

Controle de acesso baseado em função

MongoDB fornece funções predefinidas prontas para
uso, oferecendo suporte para privilégios comuns de
banco de dados de usuário e administrador, como
dbAdmin, dbOwner, clusterAdmin, readWrite, e
muito mais.
Essas funções podem ser ainda mais personalizadas por meio de
Funções Definidas pelo Usuário, permitindo que os administradores
atribuam privilégios refinados aos clientes, com base em suas
respectivas necessidades de acesso e processamento de dados. Para
simplificar o provisionamento e a manutenção de contas, as funções
podem ser delegadas entre as equipes, garantindo a aplicação de
políticas consistentes em funções específicas de processamento de
dados dentro da organização. MongoDB fornece a capacidade de
especificar privilégios de usuário com granularidade em nível de
banco de dados e coleção.

24
Os privilégios são atribuídos às funções que, por
sua vez, são atribuídas aos usuários.

Por exemplo:
° Classes de usuários e aplicativos podem receber privilégios
para inserir dados, mas não para atualizar ou excluir dados do banco de
dados
° DBAs podem receber privilégios que lhes permitem criar coleções e
índices no banco de dados, enquanto os desenvolvedores estão
restritos a operações CRUD
° Certas funções de administrador podem ter privilégios em todo o
cluster para criar conjuntos de réplicas e configurar fragmentação,
enquanto outras estão restritas à criação de novos usuários ou
inspeção de registro
° Processos de monitoramento de clusters do MongoDB podem ser
restritos a executar apenas os comandos que recuperam o status do
servidor, sem acesso administrativo total para realizar operações de
banco de dados
° Dentro de um ambiente multilocatário, desenvolvedores e administradores
“proprietários” podem receber permissões em bancos de dados físicos,
enquanto desenvolvedores e administradores “inquilinos” podem receber
um conjunto mais limitado de ações em bancos de dados lógicos ou
coleções individuais. Essa funcionalidade permite uma separação clara de
funções e controle, tanto entre as organizações quanto dentro delas.

Revise a Seção de Autorização da Documentação para saber

mais sobre funções no MongoDB.

25
Arquitetura de
segurança do MongoDB

Quando MongoDB Enterprise Advanced é combinado com os

recursos de auditoria disponíveis, os clientes podem definir
ações administrativas específicas por função e, em seguida,
registrar todas essas ações.
Como resultado, a organização é capaz de aplicar o controle operacional de
ponta a ponta e manter insight sobre as ações para conformidade e relatórios.
Discutimos auditoria com mais detalhes posteriormente neste guia.

Autorização LDAP
Além da autenticação LDAP, o MongoDB Enterprise Advanced também suporta
autorização via LDAP. Isso permite que os privilégios de usuário existentes
armazenados no servidor LDAP sejam mapeados para funções do MongoDB,
sem a necessidade de recriar usuários no próprio MongoDB. Quando
configurado com um servidor LDAP para autorização, o MongoDB permitirá a
autenticação do usuário via LDAP, Active Directory, Kerberos ou X.509 sem exigir
documentos do usuário local no banco de dados $external.
Observação: O banco de dados $external é utilizado quando os usuários têm
credenciais armazenadas externamente ao MongoDB. Quando um usuário é
autenticado com sucesso, o MongoDB realizará uma consulta no servidor LDAP
para recuperar todos os grupos dos quais o usuário LDAP é membro e
transformará esses grupos em suas funções equivalentes do MongoDB. A
autenticação e autorização LDAP podem ser configuradas por meio de linha de
comando ou, para conveniência administrativa adicional, por meio da GUI do
Ops Manager.

26
Segurança no nível de campo utilizando
visualizações somente de leitura
Para reforçar a segurança no nível de campo, desenvolvedores e DBAs têm
diversas abordagens disponíveis. Discutiremos a criptografia no nível de campo
do lado do cliente posteriormente, enquanto esta seção se concentra no uso de
visualizações somente de leitura para impor a segurança no nível de campo.

Você pode definir visualizações não materializadas que expõem apenas um subconjunto de
dados de uma coleção subjacente do MongoDB, ou seja, uma visualização que filtra campos
específicos, como Informações de Identificação Pessoal (PII) de dados de vendas ou registros de
saúde. Como resultado, os riscos de exposição de dados são drasticamente reduzidos. Os DBAs
podem definir uma visualização de uma coleção que é gerada a partir de uma agregação sobre
outra(s) coleção(ões) ou visualização. As permissões concedidas à visualização são especificadas
separadamente das permissões concedidas às coleções subjacentes. Esse recurso permite que
as organizações atendam mais facilmente aos padrões de conformidade em setores
regulamentados, restringindo o acesso a dados confidenciais, sem criar os silos que surgem
quando os dados precisam ser divididos para refletir diferentes privilégios de acesso.

As visualizações também podem conter campos computados, por exemplo, resumindo o

valor total e médio de pedido por região, sem expor os dados subjacentes do cliente.
Tudo isso pode ser feito sem afetar a estrutura ou o conteúdo das coleções originais.
Desenvolvedores e DBAs podem modificar o esquema da coleção subjacente sem afetar os
aplicativos que usam a visualização.

As visualizações são definidas utilizando a linguagem de consulta do MongoDB padrão e o

pipeline de agregação. Elas permitem a inclusão ou exclusão de campos, mascaramento de
valores de campo, filtragem, transformação de esquema, agrupamento, classificação,
limitação e junção de dados utilizando $lookup e $graph Lookup para outra coleção.

Saiba mais sobre visualizações Somente de leitura na documentação do MongoDB.

27
Arquitetura de
segurança do MongoDB

Redação de registro
O MongoDB Enterprise Advanced também pode ser configurado com
redação de registro para evitar que informações potencialmente
confidenciais, como identificadores pessoais, sejam gravados no
registro de diagnóstico do banco de dados.

Desenvolvedores e DBAs que podem precisar acessar os registros para otimização do

desempenho do banco de dados ou tarefas de manutenção ainda obtêm visibilidade
dos metadados, como códigos de erro ou operação, números de linha e nomes de
arquivos de origem, mas não conseguem ver nenhum dado pessoal associado a
eventos do banco de dados.

Auditoria do MongoDB
A estrutura de auditoria do MongoDB Enterprise Advanced registra todos os acessos
e ações executadas no banco de dados. A estrutura de auditoria captura ações
administrativas (DDL), como operações de esquema, bem como atividades de
autenticação e autorização, juntamente com operações de leitura e gravação (DML)
no banco de dados. Os administradores podem criar e filtrar trilhas de auditoria para
qualquer operação no MongoDB, seja DML, DCL ou DDL, sem depender de
ferramentas de terceiros. Por exemplo, é possível registrar e auditar as identidades
de usuários que acessaram documentos específicos e quaisquer alterações feitas no
banco de dados durante a sessão.

Os administradores podem configurar o MongoDB para registrar todas as ações ou

aplicar filtros para capturar apenas eventos, usuários ou funções específicas. O
registro de auditoria pode ser gravado em múltiplos destinos e em vários formatos,
inclusive no console e no syslog (no formato JSON) e em um arquivo (JSON ou
BSON), que pode ser carregado no MongoDB e analisado para identificar eventos
relevantes.

28
Cada servidor MongoDB grava eventos em seu armazenamento anexado. O DBA
pode então usar suas próprias ferramentas para mesclar esses eventos em um
único registro de auditoria, permitindo uma visão de todo o cluster das
operações que afetaram múltiplos nós.

CONSOLE, SYLOG E ARQUIVO

Trilha de
auditoria

Figura 4: MongoDB mantém uma trilha de auditoria de ações administrativas contra o banco de dados

O MongoDB Enterprise Advanced também suporta auditoria baseada em função. É

possível registrar e relatar atividades por função específica, como usuário Admin ou
dbAdmin
– junto à quaisquer funções herdadas que cada usuário tenha – em vez de ter que
extrair atividades para cada administrador individual.

A auditoria adiciona sobrecarga de desempenho a um sistema MongoDB. A quantidade

depende de diversos fatores, incluindo quais eventos são registrados e onde o registro
de auditoria é mantido, como em um dispositivo de armazenamento externo e o
formato do registro de auditoria. Os usuários devem considerar as necessidades
específicas de seu aplicativo para auditoria e suas metas de desempenho para
determinar sua configuração ideal.

Saiba mais na Documentação de auditoria do MongoDB.

29
Arquitetura de segurança
do MongoDB

Criptografia do MongoDB
Os administradores podem criptografar dados do MongoDB em trânsito pela
rede e em repouso em armazenamento e backups permanentes. Os usuários
podem criptografar dados no nível de campo, protegendo informações
confidenciais de administradores e outros usuários legítimos enquanto os
dados estão em uso no servidor.

Criptografia de rede
O suporte para TLS permite que os clientes se conectem ao
MongoDB por meio de um canal criptografado. Os clientes são
definidos como qualquer entidade capaz de se conectar ao
servidor MongoDB, incluindo:
o Usuários e administradores
o Aplicativos
o Ferramentas do MongoDB (por exemplo, mongodump,
mongorestore, mongotop)
o Nós que compõem um cluster do MongoDB, como
membros do conjunto de réplicas, roteadores de
consulta e servidores de configuração.

É possível misturar conexões criptografadas com não criptografadas na

mesma porta, o que pode ser útil ao aplicar controles de criptografia mais
refinados para tráfego interno e externo, além de evitar tempo de inatividade
ao atualizar um cluster do MongoDB para oferecer suporte ao TLS.

30
O protocolo TLS também é compatível com certificados x.509 e
oferece suporte a Forward Secrecy, fornecendo a garantia de que
as chaves de sessão de seus usuários permanecerão seguras
mesmo que a chave privada do servidor seja comprometida.
O MongoDB Enterprise Advanced oferece suporte a criptografia
FIPS 140-2 se executado no modo FIPS com um módulo
criptográfico validado por FIPS. Os processos mongod e mongos
devem ser configurados com “sslFIPSMode”. Além disso, esses
processos devem ser implantados em sistemas com uma
biblioteca OpenSSL configurada com o módulo FIPS 140-2.

A documentação do MongoDB inclui um

tutorial para configurar conexões TLS .

31
Arquitetura de segurança
do MongoDB

Criptografia de dados em repouso

Há diversas maneiras de criptografar dados em repouso com o MongoDB. A criptografia pode
ser implementada no nível do aplicativo ou por meio de sistemas de arquivos externos e
soluções de criptografia de disco. Ao introduzir tecnologia adicional na pilha, ambas as
abordagens podem aumentar o custo, a sobrecarga de desempenho e a
complexidade operacional.

Com o mecanismo de armazenamento criptografado do MongoDB, a proteção de dados em

repouso se torna um recurso integral do banco de dados. Ao criptografar nativamente arquivos de
banco de dados no disco, os administradores eliminam a sobrecarga de desempenho e
gerenciamento de mecanismos de criptografia externos. O mecanismo de armazenamento
criptografado fornece um nível adicional de defesa, permitindo que somente funcionários com as
credenciais de banco de dados apropriadas acessem os dados criptografados.

Utilizando o mecanismo de armazenamento criptografado, o conteúdo bruto do banco de dados,

conhecido como texto simples, é criptografado utilizando um algoritmo que recebe uma chave de
criptografia aleatória como entrada e gera um texto criptografado que só pode ser lido se
descriptografado com a chave de descriptografia. O processo é totalmente transparente para o
aplicativo. O MongoDB suporta uma variedade de esquema de criptografia, com AES-256
(criptografia de 256 bits) no modo CBC sendo o padrão. AES-256 no modo GCM também é
suportado. O esquema de criptografia pode ser configurado para conformidade com FIPS 140-2.
O mecanismo de armazenamento criptografa cada banco de dados com uma chave separada.
O esquema de encapsulamento de chaves no MongoDB encapsula todas as chaves internas
individuais do banco de dados com uma chave mestra externa para cada servidor.

O mecanismo de armazenamento criptografado oferece suporte a duas opções de

gerenciamento de chaves – em ambos os casos, a única chave gerenciada fora do
MongoDB é a chave mestra:
° Gerenciamento de chaves locais através de um arquivo-chave.
° Integração com um dispositivo de gerenciamento de chaves de terceiros
através do protocolo KMIP (recomendado).

32
A maioria das exigências regulatórias exige que as chaves de criptografia
sejam alternadas e substituídas por uma nova chave no mínimo uma vez
ao ano.

O MongoDB pode obter a alternação de chaves sem incorrer em tempo de inatividade

executando reinicializações contínuas do conjunto de réplicas. Ao utilizar um dispositivo KMIP,
os próprios arquivos de banco de dados não precisam ser criptografados novamente, evitando
assim a sobrecarga de desempenho significativa imposta pela alternação de chaves em outros
bancos de dados. Somente a chave mestra é alternada e o repositório de chaves do banco de
dados interno é criptografado novamente.

O mecanismo de armazenamento criptografado foi

projetado para eficiência operacional e desempenho:
° Compatível com compressão e controle de simultaneidade no nível
de documento do WiredTiger.
° Suporte para CPUs equipadas com AES-NI da Intel para aceleração do
processo de criptografia/descriptografia.
° À medida que os documentos são modificados, somente os blocos de
armazenamento atualizados precisam ser criptografados, em vez de todo o
banco de dados.

Com base no teste do usuário, o mecanismo de armazenamento criptografado

minimiza a sobrecarga de desempenho para cerca de 10 a 15% (isso pode variar, com
base nos tipos de dados que estão sendo criptografados), o que pode ser muito
menor do que a sobrecarga observada imposta por algumas soluções de criptografia
de sistema de arquivos.
O mecanismo de armazenamento criptografado é baseado no WiredTiger e está
disponível como parte do MongoDB Enterprise Advanced.

Consulte a documentação para saber mais e veja um tutorial sobre

como configurar o mecanismo de armazenamento.

33
Arquitetura de segurança
do MongoDB

Criptografia no nível de campo do lado do cliente

Sempre que o servidor de banco de dados lida com a criptografia e a
descriptografia de dados, independentemente do fornecedor do banco de dados,
os usuários com privilégios elevados, como administradores, potencialmente
podem ler a memória aproveitada pelo processo do sistema operacional que
hospeda o banco de dados. Para proteger completamente seus dados
de uma conta de administrador comprometida ou de um administrador de
sistema, o mecanismo de banco de dados nunca deve expor o texto simples dos
dados criptografados em nenhum ponto do ciclo de vida da consulta.
Com a Criptografia no Nível de Campo (FLE) do lado do cliente do MongoDB, você
pode criptografar seletivamente campos de documentos individuais, cada um
opcionalmente protegido com sua própria chave. Nossa implementação de
Criptografia no Nível de Campo é totalmente separada do banco de dados,
tornando-a transparente para o servidor, e tratada exclusivamente dentro dos
drivers do MongoDB no cliente. Todos os campos criptografados no servidor –
armazenados na memória, nos registros do sistema, em repouso e em backups –
são renderizados como texto cifrado, tornando-os ilegíveis para qualquer parte
que não tenha acesso de cliente com as chaves necessárias para descriptografar
os dados. Essa é uma abordagem diferente e mais abrangente do que a
criptografia de coluna usada em muitos bancos de dados relacionais. Como a
maioria lida com a criptografia no lado do servidor, os dados ainda podem ser
acessados pelos administradores que têm acesso à própria instância do banco de
dados, mesmo que não tenham privilégios de acesso de cliente.
Ao desenvolver a Criptografia no Nível de Campo do Lado do Cliente, o MongoDB
trabalhou com duas das principais autoridades mundiais em criptografia de
banco de dados, incluindo um co-autor do esboço do grupo de trabalho da rede
IETF sobre criptografia AES autenticada. Procedentes do meio acadêmico e da
indústria, essas equipes forneceram orientação especializada sobre nosso
projeto de FLE e revisaram a implementação do software de FLE.

34
A Criptografia no Nível de Campo serve como uma adição
importante à sua estratégia de segurança de defesa em
profundidade. Considere uma implantação típica do MongoDB
de uma perspectiva de gerenciamento de risco:
• Apenas com a criptografia do sistema de arquivos, os administradores de
sistema ou invasores que elevam os privilégios de usuário no nível do
sistema ainda têm acesso a arquivos de banco de dados de texto simples
no armazenamento do servidor e na memória.
• O Mecanismo de armazenamento criptografado do MongoDB fornece uma
maneira de mitigar os riscos de acesso ao arquivo de backup e ao sistema
de arquivos criptografando todos os dados do MongoDB antes de serem
gravados no disco e garantindo que as chaves não sejam persistentes.
Qualquer invasor que obtiver arquivos do banco de dados do sistema de
arquivos será incapaz de lê-los. No entanto, administradores e usuários de
banco de dados autenticados comprometidos ainda têm acesso aos dados
subjacentes em uma instância em execução.
• Utilizando o MongoDB FLE, agora você pode proteger campos individuais
com todas as operações de gerenciamento, criptografia e descriptografia
de chaves que ocorrem exclusivamente fora do servidor de banco de
dados. Com a FLE ativada, um administrador ou usuário comprometido
que obtém acesso ao banco de dados, ao sistema de arquivos subjacente
ou ao conteúdo da memória do servidor (por exemplo, por meio de
raspagem ou inspeção de processo) verá apenas dados criptografados
ilegíveis. Embora a criptografia do mecanismo de armazenamento e a FLE
possam ser utilizadas de forma independente, elas trazem os maiores
níveis de proteção quando utilizadas em conjunto.

35
Arquitetura de segurança
do MongoDB

As vantagens da criptografia no nível de campo

do lado do cliente MongoDB incluem:
Criptografia automática e transparente: O código do aplicativo pode ser executado
sem modificações para a maioria das operações de leitura e gravação do banco de
dados quando FLE está ativada. Outras abordagens do lado do cliente exigem que os
desenvolvedores modifiquem seu código de consulta para utilizar as funções e
métodos de criptografia explícita em um SDK de linguagem.
Separação de deveres: Os administradores de sistema que tradicionalmente têm
acesso a sistemas operacionais, servidor de banco de dados, registros e backups não
podem ler dados criptografados, a menos que recebam explicitamente acesso de cliente
junto com as chaves necessárias para descriptografar os dados.
Conformidade regulatória: Cumpra as condições de “direito ao esquecimento” das
novas regulamentações de privacidade, como o GDPR – simplesmente destrua a chave do
cliente e os dados pessoais associados se tornarão inúteis.
Penalidade mínima de desempenho: Como a criptografia é tratada no cliente, os
impactos no desempenho do servidor são mínimos ao trabalhar com campos
criptografados.
Para isolamento, cada campo pode ser criptografado com sua própria chave exclusiva
integrada de forma nativa com serviços externos de gerenciamento de chaves apoiados
por Módulos de Segurança de Hardware (HSMs) validados por FIPS 140-2, como o KMS
da Amazon.

36
Para entender mais sobre a implementação da FLE, vamos dar uma
olhada no fluxo de uma consulta enviada por um cliente autenticado,
representado na figura a seguir:

Consulta e
resposta ao
cliente
autenticado

Arquivos
criptografados
sempre
armazenados,
transmitidos e
recuperados como
texto cifrado

Figura 5: Fluxo de dados de criptografia no nível de campo do lado do cliente

Ao receber a consulta, o MongoDB driver utiliza regras de criptografia por campo

especificadas em uma validação de esquema JSON para determinar se algum
campo criptografado está envolvido no filtro. O driver solicita as chaves de
criptografia dos campos do gerenciador de chaves externo.
O gerenciador de chaves retorna as chaves para o driver, que criptografa os
campos confidenciais. O driver envia a consulta ao servidor MongoDB com os
campos criptografados renderizados como texto cifrado. O MongoDB retorna os
resultados criptografados da consulta ao driver. Os resultados da consulta são
descriptografados pelas chaves mantidas pelo driver e retornados ao cliente.

37
Arquitetura de segurança
do MongoDB

Como o servidor de banco de dados não tem acesso às chaves

de criptografia, certas operações de consulta, como
classificações e consultas baseadas em intervalo em campos
criptografados, não são possíveis, a menos que seja
implementada uma solução do lado do cliente, que pode ter
impactos adicionais no desempenho.
Como resultado, o FLE é melhor aplicado para proteger seletivamente apenas os
campos que contêm dados de identificação pessoal altamente confidenciais,
como informações de cartão de crédito e número doseguro social.

A criptografia no nível de campo do lado do cliente é especialmente poderosa ao

utilizar serviços de banco de dados gerenciados como o MongoDB Atlas. No Atlas,
todos os backups e armazenamento de cluster são criptografados em repouso por
padrão. Você pode fornecer uma camada adicional de criptografia protegendo as
chaves do banco de dados utilizando o serviço de gerenciamento de chaves dos
provedores de nuvem.

Com a adição da FLE, as chaves são protegidas em uma conta do AWS KMS isolada
gerenciada pelo cliente (soluções adicionais de gerenciamento de chaves estarão
online em um futuro próximo). Os Engenheiros de Confiabilidade do Site Atlas e os
Engenheiros de Produto não têm nenhum mecanismo para acessar as chaves de
FLE KMS, tornando os dados ilegíveis para qualquer equipe do MongoDB que
esteja gerenciando o banco de dados ou a infraestrutura subjacente para você.

Ao combinar esses recursos de segurança, você elimina preocupações comuns de

segurança ao mover cargas de trabalho de banco de dados para serviços gerenciados
na nuvem. Isso ocorre porque você controla e gerencia as chaves de criptografia, em
vez de fazer com que o operador do banco de dados gerencie as chaves para você.

Para obter mais informações, consulte as notas de versão e a

documentação do MongoDB Server 4.2 e a Criptografia no nível de
campo do lado do cliente na Documentação do MongoDB.

38
Ambiente e processos
Com base nos controles de segurança do banco de dados
discutidos acima, a execução do MongoDB em um ambiente
confiável, a implementação de um ciclo de vida de
desenvolvimento seguro e a aplicação das melhores práticas de
implantação reduzem ainda mais o risco de violações de
segurança.

Uma abordagem de “Defesa em Profundidade” é recomendada para

complementar as implantações seguras do MongoDB, abordando vários
métodos diferentes para gerenciar riscos e reduzir a exposição.

A intenção de uma abordagem de Defesa em Profundidade é colocar seu

ambiente em camadas para garantir que não haja pontos únicos de falha
exploráveis que possam permitir que um intruso ou parte não confiável
acesse os dados armazenados no banco de dados do MongoDB.

39
Arquitetura de
segurança do MongoDB

Ambientes seguros utilizam as estratégias a seguir para

controlar o acesso, com mais detalhes disponíveis na seção
Segurança e Exposição da Rede da documentação.

Filtro da rede:
Ao utilizar filtros como firewalls e regras de ACL de roteador, as conexões
com o MongoDB de sistemas desconhecidos podem ser bloqueadas. Os
firewalls devem limitar o tráfego de entrada e saída de/para uma porta
específica para sistemas confiáveis e não confiáveis. Para obter melhores
resultados e minimizar a exposição geral, certifique-se de que apenas o
tráfego de fontes confiáveis possa alcançar as instâncias mongod e mongos
e que elas possam se conectar somente à saídas confiáveis. Além disso, os
serviços desnecessários do sistema devem ser desativados.

Endereços IP de ligação:
A configuração bind_ip para instâncias mongod e mongos limita as
interfaces de rede nas quais os programas do MongoDB escutarão
as conexões de entrada.

Execução em VPNs:
Limite os programas do MongoDB a redes locais não públicas e redes
privadas virtuais. As Redes Privadas Virtuais (VPNs) possibilitam vincular
duas redes em uma rede confiável criptografada e de acesso limitado.
Geralmente, os usuários do MongoDB configuram protocolos SSL em vez de
IPSEC para obter vantagens de desempenho.

Conta de usuário de sistema operacional dedicada:

Uma conta de usuário dedicada ao MongoDB deve ser criada e utilizada
para executar executáveis do MongoDB. O MongoDB não deve ser
executado como usuário “raiz”.

40
Permissões do sistema de arquivos:
Os servidores que executam o MongoDB devem implementar permissões de sistema
de arquivos que impeçam os usuários de acessar os arquivos de dados criados pelo
MongoDB. Os arquivos de configuração do MongoDB e o arquivo-chave do cluster
devem ser protegidos para impedir o acesso de usuários não autorizados.

Injeção de consulta:
À medida que um programa cliente monta uma consulta no MongoDB, ele cria um
objeto BSON, não uma cadeia de caracteres. Assim, os ataques tradicionais de
injeção de SQL não devem representar um risco ao sistema para consultas
enviadas como objetos BSON.

No entanto, várias operações do MongoDB permitem a avaliação de expressões

JavaScript arbitrárias e deve-se tomar cuidado para evitar expressões maliciosas.
Felizmente, a maioria das consultas pode ser expressa em BSON e, para casos em que
Javascript é necessário, é possível misturar JavaScript e BSON para que os valores
especificados pelo usuário sejam avaliados como valores e não como código.

O MongoDB também permite que o administrador configure o servidor

MongoDB para impedir a execução de scripts Javascript.

Isso impedirá que os trabalhos do MapReduce sejam executados, mas o pipeline

de agregação pode ser utilizado como alternativa em muitos casos de uso.

Controles de acesso físico:

Além dos controles lógicos discutidos acima, controlar o acesso físico a
servidores, armazenamento e mídia de backup fornece proteção ambiental
crítica.

Impulsione os gerenciadores secretos:

Armazenar senhas em arquivos de configuração complica a
auditoria e aumenta o risco de comprometimento do sistema.

41
Arquitetura de segurança
do MongoDB

Monitoramento e atualização de banco de

dados
O monitoramento proativo de todos os componentes em um ambiente de
TI é sempre uma prática recomendada. O desempenho e a disponibilidade
do sistema dependem da detecção e resolução imediatas de possíveis
falhas antes que apresentem problemas aos usuários.

Do ponto de vista da segurança do banco de dados, o monitoramento é fundamental

para identificar possíveis exploits em tempo real, reduzindo assim o impacto de
qualquer violação. Por exemplo, picos repentinos nas cargas de CPU e memória de
sistemas host e contadores de operações altos no banco de dados podem indicar um
ataque de negação de serviço. O MongoDB é fornecido com uma variedade de
ferramentas, incluindo mongostat e mongotop, que podem ser usadas para monitorar
seu banco de dados.

A solução de monitoramento mais abrangente é fornecida pelo MongoDB Ops Manager,

que é a maneira mais simples de executar o MongoDB em sua própria infraestrutura. O
Ops Manager facilita a monitoração, proteção, backup e escalonamento do MongoDB
pelas equipes de operações. O Ops Manager está disponível com o MongoDB Enterprise
Advanced. O MongoDB Cloud Manager é uma ferramenta de gerenciamento hospedada
para o MongoDB que fornece muitos dos mesmos recursos do Ops Manager.

Figura 6: O Ops Manager oferece gráficos, painéis personalizados e alertas automatizados

42
O MongoDB Cloud Manager é uma ferramenta de gerenciamento
hospedada para o MongoDB que fornece muitos dos mesmos
recursos do Ops Manager.

Apresentando gráficos, painéis personalizados e alertas automatizados,

Ops and Cloud Manager rastreiam mais de 100 métricas-chave de
integridade de bancos de dados e sistemas, incluindo contadores de
operações, utilização de CPU e memória, status de replicação, conexões
abertas, filas e quaisquer status de nós. O Cloud Manager também pode
alertá-lo(a) se algum host estiver exposto à Internet.

As métricas são relatadas com segurança para o Ops Manager, onde são
processadas, agregadas, alertadas e visualizadas em um navegador,
permitindo que os administradores determinem facilmente a integridade do
MongoDB em tempo real. As visualizações podem ser baseadas em
permissões explícitas, para que a visibilidade da equipe do projeto possa ser
restrita a seus próprios aplicativos, enquanto os administradores de
sistemas podem monitorar todas as implantações do MongoDB em toda a
organização.

O Ops Manager permite que os administradores definam alertas

personalizados quando as principais métricas estiverem fora de alcance.
Os alertas podem ser enviados via SMS e e-mail ou integrados a sistemas
de gerenciamento de incidentes existentes, como PagerDuty, Slack,
HipChat, entre outros, para alertar proativamente sobre possíveis
problemas antes que se transformem em interrupções custosas.

O Ops Manager também permite que os administradores implementem

atualizações e patches no banco de dados sem tempo de inatividade do
aplicativo. Utilizando a GUI ou a API, os pacotes atualizados podem ser
enviados e aplicados a cada servidor por meio de uma série de
reinicializações contínuas, tudo sem intervenção do operador.

43
Arquitetura de segurança
do MongoDB

Recuperação do Desastre:
Backups e recuperação em um
momento específico
Os dados podem ser comprometidos por vários eventos
imprevistos: falha do banco de dados ou de sua infraestrutura
subjacente, erro do usuário, atividade maliciosa ou bugs de
aplicativos.

Com uma estratégia de backup e recuperação em vigor, os

administradores podem restaurar as operações de negócios
recuperando rapidamente seus dados, permitindo que a organização
cumpra as obrigações regulatórias e de conformidade.

Os backups do Ops Manager são mantidos continuamente, apenas alguns

segundos atrasado em comparação com o sistema operacional. Se o
MongoDB apresentar uma falha, o backup mais recente estará apenas
alguns momentos atrasado, minimizando a exposição
à perda de dados. O Ops Manager e o Cloud Manager oferecem
recuperação em um momento específico de conjuntos de réplicas e cópias
instantâneas de clusters fragmentados em todo o cluster. Você pode
restaurar com precisão o momento que precisar, com rapidez e segurança,
permitindo que os usuários se recuperem rapidamente de ataques que
corrompem os dados subjacentes.

Os backups que podem ser consultados permitem que você se

conecte a cópias instantâneas de backup e emita consultas somente
para leitura. Isso alivia o fardo de realizar uma restauração completa
do banco de dados para obter registros que podem ter sido excluídos
acidentalmente.

44
Serviços de treinamento e consultoria
O MongoDB oferece amplo treinamento e serviços de
consultoria para ajudar os clientes a aplicar as
melhores práticas de segurança:

• O curso de Segurança do MongoDB é um programa de

treinamento online gratuito de 3 semanas ministrado pela
Universidade MongoDB.
• A Universidade MongoDB também oferece uma variedade de
treinamentos públicos e privados para desenvolvedores e
equipes de operações, abrangendo as melhores práticas de
uso e administração do MongoDB.

• MongoDB Global Consulting Services oferecem uma variedade de

pacotes que abrangem Verificações de Integridade, Avaliações de
Prontidão de Produção e acesso a Engenheiros Consultores
Dedicados. Os engenheiros consultores do MongoDB trabalham
diretamente com suas equipes para orientar o desenvolvimento e as
operações, garantindo a transferência de habilidades para sua equipe.

Mantenha-se atualizado
Sempre certifique-se de estar executando a versão mais recente com
certificação de produção do MongoDB e dos drivers, e de ter aplicado
o conjunto de patches mais recente. Enquanto os clientes do
MongoDB Enterprise Advanced têm acesso a patches de emergência,
correções para vulnerabilidades de segurança estão disponíveis para
todos os usuários do MongoDB assim que são lançadas.

45
Arquitetura de segurança
do MongoDB

MongoDB Atlas:
Banco de Dados
como um Serviço
para o MongoDB

O MongoDB Atlas é um serviço de banco de dados

em nuvem que facilita a implantação, operação e
escalonamento do MongoDB na nuvem,
automatizando tarefas de administração
demoradas, como configuração de banco de dados,
implementação de segurança, escalonamento,
aplicação de patches e muito mais.

46
O MongoDB Atlas está disponível sob demanda por meio de um
modelo de pagamento por utilização e cobrado por hora.

É fácil começar – use uma GUI simples para selecionar

o provedor de nuvem pública, a região, o tamanho da
instância e os recursos de que você precisa. O
MongoDB Atlas fornece:
o Recursos de segurança para proteger seus dados, com controle de
acesso refinado e criptografia de ponta a ponta
o Replicação integrada para disponibilidade sempre ativa.
o Banco de dados geograficamente disperso que pode fornecer gravações
de baixa latência de qualquer lugar do mundo. Os dados também podem
ser facilmente replicados e distribuídos geograficamente, permitindo
tolerância a falhas em várias regiões e leituras rápidas e responsivas.
o Backups completamente gerenciados, contínuos e consistentes com
recuperação em um momento específico para proteção contra corrupção de
dados e a capacidade de consultar backups no local sem restaurações
completas
o Monitoramento minucioso e alertas personalizáveis para
visibilidade abrangente do desempenho
o Escalabilidade vertical, horizontal ou de redução com um clique sob
demanda. O MongoDB Atlas pode fornecer capacidade de
armazenamento adicional conforme necessário sem intervenção
manual.
o Patches automatizados e atualizações com um clique para novas versões
principais do banco de dados, permitindo que você aproveite os melhores e
mais recentes recursos do MongoDB
o Migração em tempo real para mover seus clusters do MongoDB
autogerenciados para o serviço do Atlas com tempo de inatividade
mínimo

47
Arquitetura de segurança
do MongoDB

O MongoDB Atlas pode ser usado para tudo, desde uma

rápida prova de conceito, ambientes de teste/GQ, até
alimentar aplicativos de produção.

A experiência do usuário no MongoDB Atlas, no Cloud Manager e no Ops

Manager é consistente, garantindo que a interrupção seja mínima se você
decidir gerenciar o MongoDB por conta própria e migrar para sua própria
infraestrutura.

Construído e executado pela mesma equipe que projeta o banco de dados, o

MongoDB Atlas é a melhor maneira de executar o MongoDB na nuvem.

Saiba mais ou instale um cluster gratuito agora.

48
Conclusão
Com os bancos de dados armazenando os ativos de
informações mais importantes de uma organização,
protegê-los é um primeiro passo essencial para
combater novas classes e atores de ameaças.
Conforme demonstrado neste whitepaper, com o MongoDB
Enterprise Advanced as organizações se beneficiam de amplos
recursos para defender, detectar e controlar o acesso a dados
valiosos e confidenciais.
Você pode começar revisando a Documentação de segurança
do MongoDB ou baixando o Whitepaper Controles de
Segurança do MongoDB Atlas para saber mais sobre a
arquitetura de segurança específica do serviço Atlas.

Avalie o MongoDB
Enterprise Advanced
Baixe hoje.

49