A maioria dos sistemas de gerenciamento de banco de dados tem várias técnicas para proteger seus dados de um estranho ou de uma pessoa ou aplicativo não autorizado. As técnicas impedem que seus dados sejam lidos ou copiados sem a permissão do usuário.
MongoDB não é diferente, pois possui alguns níveis de insegurança. Nesta postagem do blog, discutiremos os níveis de insegurança no MongoDB e como evitá-los para que você possa proteger sua instalação do MongoDB.
Para a segurança do seu MongoDB, a seguir estão algumas das principais medidas de segurança a serem consideradas estritamente:
-
Autenticação de conexões de usuários.
-
Autorização/Controle de acesso baseado em função.
-
Criptografia de Rede/Criptografia de Transporte.
-
Criptografia de armazenamento/Criptografia em repouso.
-
Auditoria.
Neste artigo, veremos em detalhes as medidas de segurança acima, com muito foco na autenticação e autorização.
Autenticação e autorização
A autenticação e a autorização devem ser ativadas em uníssono. No entanto, eles podem ser usados independentemente um do outro. A autenticação impede que uma pessoa desconhecida que tenha acesso à rede ao servidor de banco de dados copie ou danifique os dados do banco de dados. A autenticação exige que todos os clientes e servidores forneçam credenciais válidas antes de poderem se conectar ao sistema. A autorização, por outro lado, impede que um aplicativo ou usuário leia, altere ou exclua dados diferentes do que deveria.
Para configurar o controle de acesso baseado em função;
-
Crie um administrador de usuário primeiro.
-
Crie usuários adicionais.
-
Em seguida, crie um usuário MongoDB exclusivo para cada pessoa/aplicativo que acessa o sistema.
-
Seguindo o princípio do privilégio mínimo, você deve criar funções que definam os direitos de acesso exatos necessários para um conjunto de usuários.
-
Em seguida, atribua aos usuários apenas as funções que eles precisam desempenhar em suas operações. Um usuário pode ser um aplicativo cliente ou uma pessoa.
Você deve observar que um usuário pode ter privilégios em bancos de dados diferentes ou múltiplos. Nesse cenário, em vez de criar um usuário várias vezes em bancos de dados diferentes, crie um único usuário com funções que concedam privilégios de banco de dados aplicáveis.
Na maioria das vezes, essas duas medidas de segurança podem ser confundidas para significar a mesma coisa. Em alguns cenários, eles são semelhantes entre si, mas também são diferentes.
Semelhanças entre autenticação e autorização
-
Ambos são uma unidade única porque, quando você habilita a autenticação, a autorização é habilitada automaticamente. A autorização é habilitada em uníssono com a autenticação, portanto, as conexões de usuários desconhecidos não terão privilégios para acessar os dados do banco de dados. A autorização também exige que o nome de usuário seja verificado pela Autenticação para saber quais privilégios se aplicam às solicitações de uma conexão. Portanto, também não pode ser habilitado independentemente do outro.
-
Ambos também são semelhantes na nomenclatura infeliz e herdada das opções de configuração. A opção do arquivo de configuração para autenticação é security.authorization em vez de security authentication como seria esperado. No entanto, quando você usa o comando, a autenticação é a primeira a ser habilitada e a autorização é habilitada apenas como efeito posterior. “-auth” é o argumento de linha de comando para habilitar a autenticação que automaticamente força a autorização a ser ativada também.
Diferenças entre autenticação e autorização
-
Esses dois são diferentes porque são duas partes do software que possuem funções diferentes.
Autenticação ==Identidade do usuário, por meio de verificação de credenciais.
Autorização ==Atribuir e impor permissões de objeto de banco de dados e comando de banco de dados.
-
Durante a configuração inicial, a autenticação é desabilitada para conexões de host local. Isso é breve, pois você tem uma oportunidade de criar o primeiro usuário e, em seguida, o privilégio de exceção (para a regra Autenticação e Autorização em conjunto) é descartado.
Como verificar se a autenticação e a autorização estão habilitadas ou não
As primeiras versões do MongoDB tinham “- auth” ativado por padrão e isso é amplamente considerado uma má jogada. Mesmo na versão 4.0 ainda estava desativado por padrão. A configuração em branco ainda equivale à autorização desativada, apesar de ter avisos de inicialização e várias reduções de exposição, como localhost tornando-se o único dispositivo de rede vinculado por padrão no MongoDB v3.6.
Você não está usando Autenticação ou melhor, você não tem Autenticação habilitada se os arquivos de configuração do mongod não:
-
Defina security.authorization como 'ativado'.
-
Inclua um arquivo security.key.
-
Inclua uma configuração security.clusterAuthMode que força a ativação da autenticação.
Para verificar novamente se você tem autenticação e autorização habilitadas ou não, você pode tentar este rápido shell mongo de uma linha (sem argumentos de credencial de usuário definidos):
mongo --host A resposta que você deve obter é um erro “não autorizado”. Mas, por outro lado, se você obtiver uma lista de nomes de banco de dados, automaticamente isso significa que você tem uma implantação simples do MongoDB. Como o nome sugere, a autenticação externa permite que os usuários sejam autenticados em um serviço externo. Como exceção, ele não pode ser usado para o usuário interno do sistema mongodb __, mas usá-lo para qualquer usuário humano real ou conta de serviço de aplicativo cliente é perfeitamente adequado. Simplesmente, o serviço de autenticação externa será um Kerberos KDC ou um servidor ActiveDirectory ou OpenLDAP. Você deve observar que o uso de autenticação externa não impede que você tenha contas de usuário comuns do MongoDB ao mesmo tempo. Pelo contrário, a autenticação interna do MongoDB não significa o oposto da autenticação externa. Isso ocorre porque um nó mongod em execução com autenticação habilitada não confiará que qualquer ponto TCP é outro é outro nó mongod ou mongos apenas porque se comunica como um. Em vez disso, requer que o peer se autentique por prova de segredo compartilhado. Existem dois tipos de mecanismos de autenticação interna no MongoDB: Autenticação interna do arquivo de chave. autenticação interna SCRAM ou x.509. Este é o mecanismo de autenticação interna padrão no MongoDB. O termo “Chave” indica uma chave de criptografia assimétrica, mas no sentido real é apenas uma senha, não importa como você a gerou. O arquivo-chave é salvo em um arquivo idêntico distribuído para cada nó mongod e mongos no cluster. No cenário em que a senha é usada com sucesso, um nó mongod permitirá que comandos vindos do peer autenticado sejam executados como o superusuário “_ _ system”. Se alguém tiver uma cópia do arquivo-chave, ele pode simplesmente retirar os caracteres de controle e não imprimíveis do arquivo-chave para criar a string de senha que permitirá que eles se conectem como o usuário “_ _ system”. No entanto, se isso acontecer e você executar o comando abaixo como usuário mongod (ou root) em um de seus servidores MongoDB e tiver sucesso, não se preocupe, pois não haverá vazamento acidental de privilégios de leitura . Isso ocorre porque o mongod será abortado na inicialização se o arquivo-chave estiver em algo diferente do modo de 400 (ou 600) permissões de arquivo. No entanto, salvar acidentalmente o arquivo-chave em seu controle de origem legível por todo o mundo pode permitir que usuários que não são DBAs (ou administradores de servidor com root) leiam uma cópia do arquivo-chave. Isso é considerado uma falha de segurança. Um risco extremo aumenta quando o arquivo de chave é distribuído com nós mongos pertencentes e executados como um dos usuários unix da equipe de aplicativos em vez de “mongod” ou outro usuário unix de propriedade da equipe DBA. O mecanismo de autenticação interna x.509 realmente usa chaves públicas ou privadas assimétricas e deve ser usado em conjunto com TLS/SSL. Esse mecanismo pode ser usado para conexões de clientes, bem como para autenticação interna. O mecanismo x.509 ou SCRAM tem uma vantagem sobre o mecanismo Keyfile porque no mecanismo x.509, é menos provável que uma das chaves implantadas com nós mongod e mongos possa ser abusada por um intruso que obtém uma cópia dele. No entanto, isso depende de quão estritamente os certificados x.509 são configurados. Para aproveitar o máximo de segurança desse mecanismo, você deve ter uma equipe de segurança dedicada que entenda os conceitos x.509 e as práticas recomendadas. Essas práticas recomendadas incluem restringir em quais hosts ele funcionará e poder revogar e substituir certificados. A criptografia de rede impede que alguém copie os dados que estão sendo transferidos por um link de rede em algum lugar entre dois servidores. A criptografia de rede requer pouca ou nenhuma consideração quando se trata de decidir se deve usá-la, pois é crucial. Mas se, por exemplo, seu cluster MongoDB e todos os seus clientes estiverem dentro de uma rede virtual privada que você acredita não ter falhas em seu firewall e nenhum risco de escalonamento de privilégios de outros aplicativos, você não precisará de criptografia de rede. Para criptografia de rede, você deve configurar o MongoDB para usar TLS/SSL para todas as conexões de entrada e saída. Criptografe a comunicação entre os componentes mongod e mongos de uma implantação do MOngoDB, bem como entre todos os aplicativos e o MongoDB usando TLS/SSL. A partir da versão 4.0; O MongoDB desabilita o suporte para criptografia TLS 1.0 em sistemas onde o TLS 1.1+ está disponível e também usa as seguintes bibliotecas nativas TLS/SSL: Windows - Canal Seguro (Schannel). Linux/BSD - OpenSSL. macOS - Transporte Seguro. Você deve garantir que o MongoDB seja executado em um ambiente de rede confiável e também configurar firewall ou grupos de segurança para controlar o tráfego de entrada e saída para suas instâncias do MongoDB. Mais ainda, configure para permitir que apenas clientes confiáveis acessem as interfaces de rede e portas nas quais as instâncias do MongoDB estão disponíveis. Por exemplo, use a lista de permissões de IP para permitir o acesso de endereços IP confiáveis. MongoDB suporta o código JavaScript de execução para as seguintes operações do lado do servidor: mapReduce. $where. $acumulador. $função. Use a opção -- noscripting na linha de comando para desabilitar o script do lado do servidor se você não usar as operações acima. Mantenha a validação de entrada habilitada, embora o MongoDB habilite a validação de entrada por padrão por meio da configuração net.wireObjectCheck. Isso garante que todos os documentos armazenados pela instância mongod sejam BSON válidos. A criptografia de armazenamento impede que alguém obtenha uma cópia dos arquivos de banco de dados subjacentes. Isso pode acontecer quando alguém invade seu datacenter e rouba o disco rígido do seu servidor. Os dados do MongoDB incluem arquivos de dados, arquivos de configuração, logs de auditoria e arquivos de chave. A partir do MongoDB Enterprise 3.2, você pode criptografar dados na camada de armazenamento com a criptografia em repouso nativa do mecanismo de armazenamento WiredTiger. Os dados do MongoDB devem ser criptografados em cada host usando sistema de arquivos, dispositivo ou criptografia física quando não estiver usando a criptografia em repouso do WiredTiger. Além disso, você deve coletar logs para um armazenamento de log central, pois esses logs contêm tentativas de autenticação de banco de dados, incluindo o endereço IP de origem. No entanto, a criptografia de armazenamento tem um pequeno custo de desempenho. A auditoria ajuda a rastrear um usuário de banco de dados que sabe como encobrir seus rastros após alterar ou alterar os dados do banco de dados. Basicamente, a auditoria rastreia o acesso e as alterações nas configurações e dados do banco de dados. O MongoDB Enterprise tem um recurso de sistema de auditoria que pode registrar eventos do sistema, como operações do usuário e eventos de conexão em uma instância do MongoDB. Esses registros de auditoria ajudam na análise forense e permitem que os administradores verifiquem os controles adequados. A auditoria é de alto valor para alguns usuários, mas só pode sê-lo quando alguns outros riscos são eliminados. Por exemplo, um invasor não pode obter acesso root do Unix nos servidores enquanto executa os nós mongod ativos. Você pode configurar filtros para registrar eventos específicos, como eventos de autenticação. Mas tome cuidado porque quando os filtros de auditoria são muito amplos, seu desempenho será rapidamente bloqueado, levando a custos de alto desempenho. Embora, se a auditoria for usada adequadamente, não haverá muitos custos de desempenho.
Autenticação externa
Autenticação interna
Autenticação interna do arquivo de chave
mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"
Autenticação interna SCRAM ou x.509
Criptografia de Rede/Criptografia de Transporte
Limitar a exposição da rede
Execute o MongoDB com opções de configuração segura
Criptografia de armazenamento do MongoDB/ Criptografia em repouso
Auditoria
Avançando
