15:13 12/09/2014
Guia MongoDB Segurança
Release 2.6.4
MongoDB Documentation Project
08 de setembro de 2014
Guia MongoDB Segurança
Release 2.6.4
MongoDB Documentation Project
08 de setembro de 2014
conteúdo
1 Segurança Introdução, página 4
1.1 Autenticação, página 4
1.2 Role Based Access Control, página 4
1.3 Auditoria, página 4
1.4 Criptografia, página 5
Transport Encryption, página 5
Criptografia em repouso, página 5
1.5 Endurecimento Entregas e Ambientes, página 5
2 Conceitos de segurança, página 6
2.1 Autenticação, página 6
Usuários cliente, página 6
Mecanismos de autenticação, página 6
Comportamento de Autenticação, página 8
2.2 Autorização, página 9
Roles, página 9
Usuários, página 10
Informações adicionais, página 11
2.3 Coleção de nível de controle de acesso, página 11
Privilégios e Scope, página 11
Informações adicionais, página 12
2.4 Rede de exposição e de segurança, na página 12
Opções de configuração, página 12
Firewalls, página 13
Redes Privadas Virtuais, página 13
2.5 Segurança e MongoDB Interfaces da API, página 13
JavaScript e Segurança da Shell mongo, página 14
Interface de Status HTTP, página 14
API REST, página 14
2.6 Auditoria, página 14
Eventos de Auditoria e filtro, página 15
Garantia de Auditoria, página 15
2.7 A autenticação Kerberos, página 15
Visão geral, na página 15
Componentes Kerberos e MongoDB, página 15
Considerações operacionais, página 17
Kerberized MongoDB Ambientes, página 17
3 Segurança Tutoriais, página 18
3.1 Segurança Checklist, página 19
Exigir autenticação, página 19
Configurar Role-Based Access Control, página 19
Comunicação Criptografar, página 19
Limite de Exposição de rede, página 20
Auditoria atividade do sistema, página 20
Criptografar e proteger dados, página 20
Execute MongoDB com um usuário dedicado, página 20
Execute MongoDB com opções seguras de configuração, página 20
3.2 Rede de Segurança Tutoriais, página 20
Configure Linux firewall iptables para MongoDB, página 21
Firewall netsh Configure o Windows para MongoDB, página 24
Configurar mongod e mongos para SSL, página 27
Configuração SSL para Clientes, página 31
Atualizar um cluster para usar SSL, página 34
Configurar MongoDB para FIPS, página 35
3.3 Segurança Implantação Tutoriais, página 36
Implantar conjunto de réplicas e Configurar a autenticação e autorização, página 36
3.4 Controle de Acesso Tutoriais, página 40
Ativar o controle de acesso de cliente, página 40
Habilitar a autenticação em um Sharded Cluster, página 42
Ativar autenticação Depois de criar o usuário Administrador, página 43
Use certificados X.509 para autenticar os clientes, página 44
Use certificado X.509 para autenticação Membership, página 46
Autenticar usando SASL e LDAP com ActiveDirectory, página 50
Autenticar usando SASL e LDAP com o OpenLDAP, página 52
Configurar MongoDB com autenticação Kerberos no Linux, página 55
Configurar MongoDB com autenticação Kerberos no Windows, página 58
Autenticar um MongoDB Instância ou Cluster, página 60
Gerar um arquivo de chave, página 61
Solucionar problemas de autenticação Kerberos no Linux, página 62
Implementar Campo Nível Redação, página 64
Tutoriais 3.5 Gerenciamento de Usuários e Papel, página 66
Crie um Usuário Administrador, página 66
Adicionar um usuário a um banco de dados, página 68
Crie um usuário administrativo com Acesso Irrestrito, página 70
Criar um papel, página 71
Atribuir um usuário um papel, página 73
Verifique privilégios de usuário, página 74
Modificar um acesso do usuário, página 76
Exibir funções, página 77
Alterar a senha de um usuário, página 78
Alterar sua senha e dados personalizados, página 79
3.6 Configurar o Sistema de eventos de auditoria, página 80
Saída de habilitar e configurar de Auditoria, página 81
Filtrar Eventos, página 82
Filtro para a Operação Único Tipo, página 82
Filtro para vários tipos de operação, página 82
Filtre em operações de autenticação em um único banco de dados, página 83
3.7 Criar um relatório Vulnerabilidade, página 83
Criar o relatório no JIRA, página 83
Informação a fornecer, página 83
Enviar o relatório por e-mail, página 84
Avaliação de um relatório Vulnerabilidade, página 84
Divulgação, página 84
Referência 4 Segurança, página 84
4.1 Métodos de Segurança da Shell mongo, página 84
Métodos de Gestão do usuário, página 85
Métodos de Gestão papel, página 85
4.2 Segurança Documentação de referência, página 85
Roles embutidos, página 85
system.roles coleção, página 93
system.users coleção, página 95
Documento de Recursos, na página 97
Ações Privilege, página 99
Padrão MongoDB Porto, página 103
Mensagens de Auditoria do Sistema de Eventos, na página 104
4.3 Segurança Notas de lançamento Alertas, página 109
Notas de Lançamento de Segurança, página 109
Index, página 110
Esta seção descreve as estratégias de segurança e gestão de risco básicos e controle de acesso. Os tutoriais incluídos delineiam tarefas específicas para a configuração de firewalls, autenticação e privilégios de sistema.
Segurança Introdução (página 4) A introdução de alto nível para as instalações de segurança e MongoDB.
Conceitos de Segurança (página 6) A documentação do núcleo de segurança.
Autenticação (página 6) mecanismos de verificação de usuário e acesso a instância MongoDB.
Autorização (página 9) controlar o acesso a instâncias do MongoDB usando autorização.
Exposição de rede e de segurança (página 12) discute potenciais riscos de segurança relacionados com a rede e as estratégias para reduzir possíveis vetores de ataque baseados em rede para MongoDB.
Continue a ler a partir de conceitos de segurança (página 6) para documentação adicional de recursos de segurança do MongoDB e operação.
Tutoriais de segurança (página 18) Tutoriais para habilitar e configurar recursos de segurança para MongoDB.
Checklist de Segurança (página 19) A visão geral de alto nível de consideração a segurança global para os administradores de implementações do MongoDB. Use esta lista se você é novo para a implantação MongoDB na produção e deseja implementar práticas de segurança de alta qualidade.
Rede de Segurança Tutoriais (página 20) Certifique-se de que a configuração de rede subjacente suporta um ambiente operacional seguro para implementações do MongoDB, e limita de forma adequada o acesso a implementações do MongoDB.
Acesso Tutoriais de Controle (página 40) Estes tutoriais descrever os procedimentos relevantes para a configuração, operação e manutenção do sistema de controle de acesso do MongoDB.
Usuário e Função de Gerenciamento de Tutoriais (página 66) sistema de controle de acesso do MongoDB fornece uma base de sistema de controle de acesso flexível, função que você pode usar para limitar o acesso a implementações do MongoDB. Os tutoriais nesta seção descrevem a configuração de uma configuração do sistema de autorização.
Continue a ler a partir de Tutoriais de segurança (página 18) para tutoriais adicionais que abordam a utilização e gestão de implantações MongoDB seguras.
Criar um relatório de Vulnerabilidade (página 83) Relatório uma vulnerabilidade no MongoDB.
Referência de Segurança (página 84) de referência para as funções relacionadas com a segurança.
1 segurança Introdução
A manutenção de uma implantação MongoDB seguro requer que os administradores implementar controles para assegurar que usuários e aplicações têm acesso a apenas os dados que eles necessitam. MongoDB fornece recursos que permitem aos administradores para implementar esses controles e restrições para qualquer implantação MongoDB.
Se você já está familiarizado com as práticas de segurança e de segurança MongoDB, considere o Checklist de Segurança (página 19) para um conjunto de ações recomendadas para proteger a implantação MongoDB.
Autenticação 1.1
Antes de ter acesso a um sistema de todos os clientes devem identificar-se para MongoDB. Isso garante que nenhum cliente pode acessar os dados armazenados no MongoDB sem ser explicitamente permitido.
MongoDB suporta uma série de mecanismos de autenticação (página 6) que os clientes podem usar para verificar sua identidade. MongoDB suporta dois mecanismos: um desafio baseado em senha e certificados de protocolo de resposta e X.509. Além disso, MongoDB Enterprise 1 também fornece suporte para autenticação de proxy LDAP (página 7) e autenticação Kerberos (página 7).
Consulte Autenticação (página 6) para mais informações.
1.2 Baseado em Função de controle de acesso
Controle de acesso, ou seja, autorização (página 9), determina o acesso de um usuário a recursos e operações. Clientes só deve ser capaz de realizar as operações necessárias ao cumprimento das funções aprovados. Este é o "princípio do menor privilégio" e limita o risco potencial de uma aplicação comprometida.
Sistema de controle de acesso baseado em função do MongoDB permite aos administradores controlar todo o acesso e garantir que todos os acessos concedidos aplica-se estreitamente quanto possível. O MongoDB não ativa a autorização por padrão. Quando você ativar a autorização (página 9), MongoDB vai exigir autenticação para todas as conexões.
Sempre que for habilitado, MongoDB controla o acesso de um usuário através dos papéis atribuídos ao usuário. A função consiste em um conjunto de privilégios, onde um privilégio consiste em ações, ou um conjunto de operações, e um recurso em que as ações são permitidas.
Os usuários podem ter uma ou mais função que descrevem o seu acesso. MongoDB oferece diversas funções embutidas (página 85) e os usuários podem construir papéis específicos adaptados às necessidades reais dos clientes.
Veja Authorization (página 9) para mais informações.
1.3 Auditoria
A auditoria fornece aos administradores a capacidade de verificar se as políticas de segurança implementadas estão a controlar a atividade do sistema. Retenção de informações de auditoria assegura que os administradores têm informações suficientes para realizar investigações forenses e cumprir as normas e políticas que exigem dados de auditoria.
Veja Auditoria (página 14) para obter mais informações.
1.4 criptografia
criptografia de Transporte
Você pode usar o SSL para criptografar todo o tráfego de rede do MongoDB. SSL garante que o tráfego da rede MongoDB é legível apenas pelo cliente pretendido.
Consulte Configurar mongod e mongos para SSL (página 27) para obter mais informações.
Criptografia em repouso
Existem duas grandes classes de abordagens para a criptografia de dados em repouso com MongoDB. Você pode usar essas soluções em conjunto ou de forma independente:
Nível de Aplicação de Criptografia
Fornecer criptografia em uma base por campo ou por documento dentro da camada de aplicação. Para criptografar os dados de nível de campo ou de documentos, escrever de criptografia e descriptografia rotinas personalizadas ou usar uma solução comercial, como a Plataforma Vormetric Segurança de Dados 2.
criptografia de Armazenamento
Criptografar todos os dados MongoDB no armazenamento ou sistema operacional para garantir que os processos só autorizados podem acessar dados protegidos. Uma série de bibliotecas de terceiros pode se integrar com o sistema operacional para fornecer criptografia de nível de disco transparente. Por exemplo:
Linux Unified Key Setup (LUKS)
LUKS está disponível para a maioria das distribuições Linux. Para uma explicação de configuração, consulte a documentação do LUKS Red Hat 3.
Criptografia IBM Guardium Data
Criptografia IBM Guardium Data 4 fornece suporte para criptografia em nível de disco para sistemas operacionais Linux e Windows.
Plataforma de Segurança de Dados Vormetric
O Vormetric Data Security Platform 5 fornece disco e em nível de arquivo de criptografia, além de criptografia de nível de aplicativo.
Bitlocker Drive Encryption
Bitlocker Drive Encryption 6 é um recurso disponível no Windows Server 2008 e 2012, que fornece criptografia de disco.
Criptografia de disco configurado corretamente, quando usado juntamente com boas políticas de segurança que protegem contas relevantes, senhas e chaves de criptografia, pode ajudar a garantir o cumprimento das normas, incluindo HIPAA, PCI-DSS e FERPA.
1.5 Endurecimento Entregas e Ambientes
Além da implementação de controles dentro MongoDB, você também deve colocar controles em torno MongoDB para reduzir a exposição ao risco de todo o sistema MongoDB. Esta é uma estratégia de defesa em profundidade.
Endurecimento MongoDB estende as idéias do menor privilégio, auditoria e criptografia de fora do MongoDB. Reduzir o risco inclui: a configuração das regras de rede para garantir que somente hosts confiáveis ??têm acesso ao MongoDB, e que os processos MongoDB só têm acesso a partes do sistema de arquivos necessários para a operação.
2 Conceitos de segurança
Estes documentos vão apresentar conceitos e estratégias de endereços relacionados a práticas de segurança em implementações do MongoDB.
Autenticação (página 6) mecanismos de verificação de usuário e acesso a instância MongoDB.
Autorização (página 9) controlar o acesso a instâncias do MongoDB usando autorização.
Coleção de nível de controle de acesso (página 11) privilégios escopo para coleções específicas.
Exposição de rede e de segurança (página 12) discute potenciais riscos de segurança relacionados com a rede e as estratégias para reduzir possíveis vetores de ataque baseados em rede para MongoDB.
Segurança e MongoDB API Interfaces (página 13) discute os riscos potenciais relacionados com o MongoDB JavaScript, HTTP e REST interfaces, incluindo as estratégias para controlar os riscos.
Auditoria (página 14) a atividade do servidor de Auditoria e cliente para mongod e Mongos instâncias.
Autenticação Kerberos (página 15) a autenticação Kerberos e MongoDB.
16:04 12/09/2014 - acabou meu cigarro.
2.1 Autenticação.
A autenticação é o processo de verificação da identidade de um cliente. Quando controle de acesso, ou seja, autorização (página 9), está habilitado, MongoDB exige que todos os clientes para autenticar-se primeiro, a fim de determinar o acesso para o cliente.
Apesar de autenticação e autorização (página 9) estão intimamente ligados, a autenticação é diferente de autorização.
A autenticação verifica a identidade de um usuário; autorização determina o acesso do usuário verificada a recursos e operações.
MongoDB suporta uma série de mecanismos de autenticação (página 6) que os clientes podem usar para verificar sua identidade. Esses mecanismos permitem MongoDB de integrar em seu sistema de autenticação existente. Veja Mecanismos de autenticação (página 6) para mais detalhes.
Além de verificar a identidade de um cliente, MongoDB pode requerer que os membros de conjuntos de réplicas e clusters Sharded para autenticar a sua adesão (página 8) para seu respectivo conjunto de réplicas ou cluster Sharded. Consulte Autenticação entre instâncias do MongoDB (página 8) para obter mais informações.
Os usuários do cliente
Para autenticar um cliente no MongoDB, você deve adicionar um usuário correspondente ao MongoDB. Ao adicionar um usuário, você cria o usuário em um banco de dados específico. Juntos, o nome e o banco de dados do usuário servir como um identificador único para esse usuário. Ou seja, se dois usuários tenham o mesmo nome, mas são criados em bancos de dados diferentes, eles são dois usuários separados. Para autenticar, o cliente deve autenticar o usuário contra a base de dados do usuário. Por exemplo, se estiver usando o shell mongo como um cliente, você pode especificar o banco de dados para o usuário com o authenticationDatabase opção.
Para adicionar e gerenciar informações do usuário, MongoDB fornece o método db.createUser (), bem como outros métodos de gerenciamento de usuários. Para um exemplo de como adicionar um usuário para MongoDB, consulte Adicionar um usuário a um banco de dados (página 68).
MongoDB armazena todas as informações do usuário, incluindo o nome (página 96), a senha (página 96), e banco de dados do usuário (página 96), nas system.users (página 95) coleta no banco de dados de administração.
Mecanismos de autenticação
MongoDB suporta vários mecanismos de autenticação. Método de autenticação padrão do MongoDB é um desafio e resposta mecanismo (MongoDB-CR) (página 7). MongoDB também suporta a autenticação de certificado x509 (página 7), autenticação de proxy LDAP (página 7), e autenticação Kerberos (página 7).
Esta seção apresenta os mecanismos disponíveis no MongoDB.
Para especificar o mecanismo de autenticação para usar, consulte authenticationMechanisms.
MongoDB-CR Authentication
MongoDB-CR é um mecanismo de resposta que autentica os usuários através de senhas. MongoDB-CR é o mecanismo padrão.
Quando você usa autenticação MongoDB-CR, MongoDB-CR verifica o usuário contra o nome do usuário (página 96), a senha (página 96) e banco de dados (página 96). Banco de dados do usuário é o banco de dados onde o usuário foi criado, e banco de dados do usuário e nome do usuário serve juntos para identificar o usuário.
Usando arquivos de chave, você também pode utilizar a autenticação de MongoDB-CR para a autenticação membro interno (página 8) dos membros do conjunto de réplicas e membros de cluster Sharded. O conteúdo dos arquivos de chave serve como senha compartilhada para os membros. Você deve armazenar o arquivo de chave em cada mongod ou instância mongos para esse conjunto de réplicas ou cluster Sharded.
O conteúdo do arquivo da chave é arbitrário, mas deve ser a mesma em todas as instâncias mongod e mongos que se conectam uns com os outros.
Veja Gerar um arquivo de chave (página 61) para obter instruções sobre como gerar um arquivo de chave e ligar a autenticação arquivo de chave para os membros.
Autenticação de certificado X.509
Novo na versão 2.6.
MongoDB suporta a autenticação de certificado X.509 para o uso com uma conexão segura SSL (página 27).
Para autenticar a servidores, os clientes podem usar certificados X.509 em vez de nomes de usuário e senhas. Veja certificado X.509 do cliente (página 44) para obter mais informações.
Para a autenticação de membros, membros de grupos Sharded e conjuntos de réplicas pode usar certificados X.509 em vez de arquivos importantes. Consulte Uso de certificado X.509 para autenticação de associação (página 46) para obter mais informações.
Autenticação Kerberos
MongoDB Enterprise 7 suporta a autenticação usando um serviço Kerberos. Kerberos é um protocolo de autenticação padrão da indústria para sistemas cliente / servidor de grande porte.
Para usar o MongoDB com Kerberos, você deve ter uma implementação Kerberos configurado corretamente, configurados diretores de serviços Kerberos (página 16) para MongoDB, e acrescentou Kerberos principal do usuário (página 16) para MongoDB.
Veja autenticação Kerberos (página 15) para obter mais informações sobre Kerberos e MongoDB. Para configurar o MongoDB para usar a autenticação Kerberos, consulte Configurar o MongoDB com autenticação Kerberos no Linux (página 55) e configurar o MongoDB com autenticação Kerberos no Windows (página 58).
Autenticação Autoridade Proxy LDAP
MongoDB Enterprise 8 suporta a autenticação de proxy através de um serviço Lightweight Directory Access Protocol (LDAP). Veja autenticar usando SASL e LDAP com o OpenLDAP (página 52) e autenticar usando SASL e LDAP com ActiveDirectory (página 50).
O MongoDB Enterprise para Windows não inclui suporte LDAP para autenticação. No entanto, MongoDB Enterprise para Linux suporta o uso de autenticação LDAP com um servidor ActiveDirectory.
O MongoDB não suporta autenticação LDAP em implementações de cluster Sharded mistas que contêm a versão 2.4 e versão 2.6 fragmentados.
Página 8.
Comportamento de Autenticação
Autenticação do Cliente
Os clientes podem autenticar usando o desafio e resposta (página 7), X.509 (página 7), LDAP Proxy (página 7) e Kerberos (página 7) mecanismos.
Cada conexão cliente deve autenticar como exatamente um usuário. Se um cliente autenticado em um banco de dados como um usuário e, posteriormente, autentica-se no mesmo banco de dados como um usuário diferente, a segunda autenticação invalida a primeira. Enquanto os clientes podem autenticar como vários usuários se os usuários são definidos em diferentes bancos de dados, recomendamos a autenticação como um usuário de cada vez, proporcionando ao usuário com privilégios apropriados sobre os bancos de dados requeridos pelo usuário.
Veja autenticar em um MongoDB Instância ou Cluster (página 60) para obter mais informações.
Autenticação entre instâncias do MongoDB
Você pode autenticar os membros do conjuntos de réplicas e clusters Sharded. Para autenticar os membros de uma única implantação MongoDB para o outro, o MongoDB pode usar o arquivo de chave e X.509 (página 7) mecanismos. Autenticação KEYFILE usando para os membros também permite autorização.
Sempre executar conjuntos de réplicas e clusters Sharded em um ambiente de rede confiável. Certifique-se de que a rede permite apenas o tráfego de confiança para alcançar cada instância mongod e mongos.
Use firewall e roteamento de rede do seu ambiente para garantir que o tráfego somente de clientes e outros usuários podem chegar ao seu mongod e Mongos instâncias. Se necessário, use as redes privadas virtuais (VPNs) para garantir conexões seguras através de redes de longa distância (WANs).
Assegure-se sempre que:
• A configuração da rede vai permitir que todos os membros do conjunto de réplicas ou cluster Sharded entrem em contato com todos os outros membros.
• Se você usar o sistema de autenticação do MongoDB para limitar o acesso à sua infra-estrutura, garantir que você configure um arquivo de chave em todos os membros para permitir a autenticação.
Veja Gerar um arquivo de chave (página 61) para obter instruções sobre como gerar um arquivo de chave e ligar a autenticação arquivo de chave para os membros. Para um exemplo de como usar arquivos de chave para autenticação de cluster Sharded, consulte Habilitar a autenticação em um Sharded Cluster (página 42).
Autenticação em Clusters Sharded
Em clusters Sharded, aplicações autenticar diretamente para instancias Mongos, utilizando as credenciais armazenadas no banco de dados de administração dos servidores de configuração. Os nós do cluster Sharded também têm credenciais, e os clientes podem autenticar diretamente para os nós para realizar a manutenção diretamente sobre os nós. Em geral, as aplicações e os clientes devem ligar para o cluster Sharded através dos mongos.
Alterado na versão 2.6: Anteriormente, as credenciais de autenticação de um banco de dados em um cluster residia na parte primária para esse banco de dados.
Algumas operações de manutenção, como cleanupOrphaned, compacto, rs.reconfig (), requerem conexões diretas com os nós específicos de um cluster Sharded. Para realizar essas operações com autenticação habilitado, você deve ligar diretamente para o nó e autenticar como um nó de usuário administrativo local. Para criar um nó usuário administrativo local, ligar diretamente para o nó e criar o usuário. Lojas MongoDB, nós usuários locais no banco de dados de administração do próprio nó. Esses usuários locais de shard são completamente independentes dos usuários adicionados ao cluster Sharded via mongos. Usuários locais Shard são locais para o fragmento e são inacessíveis por mongos. Conexões diretas com um caco só deve ser para manutenção e configuração específica do nó.
Página 9.
Exceção localhost
A exceção localhost permite ativar autorizações antes de criar o primeiro usuário no sistema. Quando ativo, a exceção localhost permite todas as conexões da interface localhost para ter acesso total a essa instância. A exceção se aplica apenas quando não há usuários criados na instância MongoDB.
Se você usar a exceção localhost ao implantar um novo sistema MongoDB, o primeiro usuário criado deve estar no banco de dados de administração com privilégios para criar outros usuários, como um usuário com o useradmin (página 87) ou userAdminAnyDatabase (página 92) papel. Veja Ativar controle de acesso de cliente (página 40) e criar um usuário do administrador (página 66) para obter mais informações.
No caso de um cluster Sharded, a exceção localhost pode aplicar para o cluster como um todo ou separadamente para cada nó.
A exceção localhost pode aplicar para o cluster como um todo, se não houver informações do usuário armazenadas nos servidores de configuração e clientes acesso via instâncias instancias Mongos.
A exceção localhost pode aplicar separadamente para cada fragmento, se não houver informações do usuário armazenadas no nó em si e os clientes se conectam diretamente ao nó.
Para impedir o acesso não autorizado aos fragmentos de uma fragmentação, você deve criar um administrador em cada nó ou desabilitar a exceção localhost. Para desabilitar a exceção localhost, use setParameter para definir o parâmetro enableLocalhostAuthBypass a 0 durante a inicialização.
2.2 Autorização
MongoDB emprega autorização baseada em função Access Control (RBAC) que regulam o acesso a um sistema MongoDB. Um usuário recebe uma ou mais funções (página 9) que determinam o acesso do usuário aos recursos de banco de dados e operações. Fora de atribuições de função, o usuário não tem acesso ao sistema.
O MongoDB não ativa a autorização por padrão. Você pode ativar a autorização usando o --auth ou as opções --keyFile, ou se estiver usando um arquivo de configuração, com a security.authorization ou as configurações security.keyFile.
MongoDB fornece funções integradas (página 85), cada um com uma finalidade específica para um caso de uso comum. Exemplos incluem a leitura (página 86), ReadWrite (página 86), dbadmin (página 87) e raiz (página 92) funções.
Os administradores também podem criar novas funções e privilégios para atender às necessidades operacionais. Os administradores podem atribuir privilégios escopo como granular como o nível da coleção.
Quando concedido uma função, um usuário recebe todos os privilégios dessa função. Um usuário pode ter vários papéis ao mesmo tempo, caso em que o usuário recebe a união de todos os privilégios das respectivas funções.
Roles (funções)
Uma função consiste em privilégios que os recursos "pair" (não encontrei significado compreensivel para mim) com operações permitidas. Cada privilégio é definida diretamente na função ou herdado de outra função.
Privilégios de uma função se aplicam a banco de dados onde a função é criada. Uma função criada no banco de dados de administração podem incluir privilégios que se aplicam a todos os bancos de dados ou para o cluster (página 98).
Um usuário atribuído uma função recebe todos os privilégios dessa função. O usuário pode ter múltiplas funções e pode ter diferentes papéis em diferentes bancos de dados.
Roles (funções) sempre concedem privilégios e nunca limitam o acesso. Por exemplo, se um usuário tem tanto de leitura (página 86) e readWriteAnyDatabase (página 92) funções no banco de dados, o maior acesso prevalece.
Página 10.
Privilégios
Um privilégio consiste em um recurso especificado e as ações permitidas no recurso.
Um recurso privilégio (página 97) ou é um banco de dados, coleção, grupo de coleções, ou o cluster. Se o cluster, as ações associadas afetar o estado do sistema em vez de um banco de dados ou uma coleção específica.
Uma ação (página 99) é um comando ou método que o usuário tem permissão para executar no recurso. Um recurso pode ter várias ações permitidas. Para ações disponíveis consulte Ações Privilege (página 99).
Por exemplo, um privilégio que inclui a atualização (página 99) ação permite ao usuário modificar documentos existentes sobre o recurso. Para conceder adicionalmente ao usuário permissão para criar documentos no recurso, o administrador adiciona a inserção (página 99) medidas para o privilégio.
Para obter a sintaxe privilégio, consulte admin.system.roles.privileges (página 93).
Herdados privilégios (Inherited Privileges).
A função pode incluir uma ou mais funções existentes na sua definição, caso em que a função herda todos os privilégios das funções incluídos.
Uma função pode herdar privilégios de outras funções em seu banco de dados. Uma função criada no banco de dados de administração pode herdar privilégios de papéis em qualquer banco de dados.
Roles (funções) definidas pelo usuário
Novo na versão 2.6.
Administradores de usuários podem criar funções personalizadas para garantir nível de recolha e de nível de comando granularidade e aderir à política do menor privilégio. Os administradores criam e editam funções usando os comandos de gerenciamento de papel.
MongoDB escopos de uma função definida pelo usuário para o banco de dados em que é criada e exclusivamente identifica a função pelo emparelhamento do seu nome e da sua base de dados. MongoDB armazena as funções em system.roles do banco de dados admin (página 93) coleção. Não acesse esta coleção diretamente, mas sim usar o gerenciamento de funções comandos para visualizar e editar funções personalizadas.
Coleção Nível de Controle de Acesso
Ao criar uma função com privilégios (página 10) que estão no escopo de uma coleção específica em um banco de dados específico, os administradores podem implementar o controle de acesso em nível de coleção.
Veja coleção de nível de controle de acesso (página 11) para obter mais informações.
usuários
MongoDB armazena as credenciais do usuário nos admin.system.users protegidas. Use os métodos de gerenciamento de usuários para visualizar e editar as credenciais do usuário.
Página 11.
Atribuição de funções para usuários
Administradores de usuários criam os usuários que acessam os bancos de dados do sistema. Comandos de gerenciamento de usuários do MongoDB permitem aos administradores criar usuários e atribuir-lhes funções.
MongoDB escopos um usuário ao banco de dados no qual o usuário é criada. MongoDB armazena todas as definições de usuário no banco de dados de administração, não importa qual banco de dados o usuário tem como escopo. MongoDB armazena os usuários em system.users coleção do banco de dados admin (página 95). Não acesse esta coleção diretamente, mas sim usar os comandos de gerenciamento de usuários.
O primeiro papel atribuído em um banco de dados deve ser useradmin (página 87) ou userAdminAnyDatabase (página 92). Este usuário pode, então, criar todos os outros usuários do sistema. Consulte Criar um usuário do administrador (página 66).
Proteger o usuário e a função Coleções
MongoDB armazena papel e os dados do usuário nas admin.system.roles protegidas e admin.system.users coleções, que só são acessíveis através dos métodos de gerenciamento de usuários.
Se você desativar o controle de acesso, não modifique as admin.system.roles e admin.system.users coleções usando insert normal () e update (operações).
Informações adicionais
Consulte a seção de referência para a documentação de todos os built-in-roles (página 85) e todas as ações de privilégios disponíveis (página 99).
Considere também a referência para a forma dos documentos de recursos (página 97).
Para criar os usuários vêem o Create a usuário dUser Administrator (página 66) e adicionar um usuário a um banco de dados (página 68) tutoriais.
2.3 Coleção Nível de Controle de Acesso
Controle de acesso em nível de coleção permite aos administradores conceder aos usuários privilégios que são escopo para coleções específicas.
Os administradores podem implementar o controle de acesso em nível de coleção através de funções definidas pelo usuário (página 10). Ao criar uma função com privilégios (página 10) que estão no escopo de uma coleção específica em um banco de dados específico, os administradores podem provisionar usuários com funções que concedem privilégios em um nível da coleção.
Privilégios e Âmbito/escopo
Um privilégio consiste em ações (página 99) e os recursos (página 97) sobre o qual as ações são permitidas; ou seja, os recursos definir o escopo das ações para esse privilégio.
Ao especificar o banco de dados e a coleção no documento de recursos (página 97) para um privilégio, o administrador pode limitar as ações de privilégios apenas para uma coleção específica em um banco de dados específico. Cada ação privilégio em um papel pode ser delimitado a uma coleção diferente.
Por exemplo, uma função definido pelo usuário pode conter os seguintes privilégios:
privileges: [
{ resource:{ db:"products", collection:"inventory}, actions:["find","update","insert"] },
{ resource:{ db:"products", collection:"orders"}, actions:["find"] }
]
O primeiro privilégio escopos suas ações para a coleta de inventário do banco de dados de produtos. O segundo privilégio escopos de suas ações para a coleta ordens do banco de dados de produtos.
(trecho original) The first privilege scopes its actions to the inventory collection of the products database. The second privilege scopes its actions to the orders collection of the products database.
Página 12.
Informações adicionais
Para obter mais informações sobre funções definidas pelo usuário e modelo de autorização MongoDB, consulte Autorização (página 9). Para um tutorial sobre como criar funções definidas pelo usuário, consulte Criar uma Função (página 71).
2.4 Rede de exposição e de Segurança
Por padrão, os programas MongoDB (ou seja, instancias Mongos, e mongod) irá ligar a todas as interfaces de rede disponíveis (ou seja, endereços IP) em um sistema.
Esta página apresenta diversas opções de execução que lhe permitem limitar o acesso a programas de MongoDB.
Opções de Configuração
Você pode limitar a exposição da rede com o seguinte mongod e opções de configuração instancias Mongos: habilitado, net.http.RESTInterfaceEnabled, bindIp e portuárias. Você pode usar um arquivo de configuração para especificar essas configurações.
nohttpinterface
A configuração ativada para mongod e instancias Mongos desabilita a página de status "home".
Alterado na versão 2.6: As instâncias mongod e instancias Mongos executados com a interface http desativado por padrão.
A interface de status é somente leitura por padrão, e a porta padrão para a página de status é 28017. faz autenticação não controlar ou condicionar o acesso a esta interface.
Importante: Desabilite esta interface para implementações de produção. Se você ativar essa interface, você só deve permitir que os clientes de confiança para acessar essa porta. Veja Firewalls (página 13).
REST
A configuração net.http.RESTInterfaceEnabled para mongod permite uma interface REST administrativa totalmente interativo, que está desativada por padrão. A configuração net.http.RESTInterfaceEnabled faz a interface de status http 9, que é somente leitura por padrão, totalmente interativo. Use a configuração net.http.RESTInterfaceEnabled com a configuração ativada.
A interface REST não suporta qualquer tipo de autenticação e você deve sempre restringir o acesso a esta interface para clientes só permitem confiáveis ??para se conectar a esta porta.
Você também pode permitir que essa interface na linha de comando como mongod --rest --httpinterface.
Importante: Desabilite esta opção para implantações de produção. Se você deixar esta interface habilitada, você só deve permitir que os clientes de confiança para acessar essa porta.
bind_ip
A configuração bindIp para mongod e instancias Mongos limita as interfaces de rede em que os programas MongoDB vai ouvir por conexões. Você também pode especificar um número de interfaces, passando bindIp uma lista separada por vírgulas de endereços IP. Você pode usar o --bind_ip mongod e opção instancias Mongos --bind_ip na linha de comando em tempo de execução para limitar o acesso de rede de um programa MongoDB.
Importante: Certifique-se de que o seu mongod e instancias Mongos são acessíveis apenas em redes confiáveis. Se o seu sistema possui mais de uma interface de rede, ligar programas MongoDB para a interface de rede privada ou interna.
Página 13.
port
A configuração da porta para mongod e instancias Mongos muda o principal porto no qual a instância mongod ou instancias Mongos escuta para conexões. A porta padrão é 27017. Alterando a porta não significativamente reduzir o risco ou limitar a exposição. Você também pode especificar essa opção na linha de comando como mongod --port ou instancias Mongos --port. Configuração da porta também define indiretamente a porta para o interface de status HTTP, que está sempre disponível na porta numerada 1000 maior que a porta mongod primário.
Só permitir que os clientes de confiança para se conectar à porta para as instâncias mongod e instancias Mongos. Veja Firewalls (página 13).
Veja também a configuraçãopadrão de segurança e MongoDB Porto (página 103).
Firewalls
Firewalls permitem que os administradores filtrem e controlem o acesso a um sistema, fornecendo um controle granular sobre as comunicações que de rede. Para os administradores de MongoDB, os seguintes recursos são importantes: limitar o tráfego de entrada em uma porta específica para sistemas específicos, e limitar o tráfego de entrada para máquinas não confiáveis??.
Em sistemas Linux, a interface iptables permite o acesso ao firewall netfilter subjacente. Em sistemas Windows, interface de linha de comando netsh dá acesso ao subjacente Firewall do Windows. Para obter informações adicionais sobre a configuração de firewall, consulte Configurar o Linux firewall iptables para MongoDB (página 21) e configurar o Windows Firewall netsh para MongoDB (página 24).
Para melhores resultados e para minimizar a exposição global, garantir que apenas o tráfego de fontes confiáveis ??pode chegar mongod e instancias Mongos e que as instâncias mongod e instancias Mongos só pode se conectar às saídas confiáveis.
Veja também:
Para MongoDB implementações em serviços web da Amazon, consulte a (página Amazon EC2 10, que trata dos Grupos de Segurança da Amazon e outros recursos de segurança específicos do EC2. http://docs.mongodb.org/ecosystem/platforms/amazon-ec2
Redes Privadas Virtuais
As redes privadas virtuais ou VPNs, tornam possível ligar duas redes através de uma rede criptografada e de acesso limitado de confiança. Normalmente, os usuários que usam o MongoDB VPNs SSL, em vez de usar VPNs IPSec para problemas de desempenho.
Dependendo da configuração e implementação, VPNs fornecem para validação de certificado e uma escolha de protocolos de criptografia, o que exige um nível rigoroso de autenticação e identificação de todos os clientes. Além disso, como VPNs fornecem um túnel seguro, usando uma conexão VPN para controlar o acesso à instância do MongoDB, você pode evitar adulterações e "man-in-the-middle" ataques.
2.5 Segurança e MongoDB Interfaces da API
A seção a seguir contém estratégias para limitar os riscos relacionados com as interfaces disponíveis do MongoDB, incluindo JavaScript, HTTP, e interfaces REST.
Página 14.
JavaScript e Segurança da Shell mongo
Os seguintes comportamentos de avaliação de JavaScript do shell mongo representa exposições ao risco.
JavaScript Expression ou arquivo JavaScript
O programa mongo pode avaliar expressões JavaScript usando a opção --eval linha de comando. Além disso, o programa mongo pode avaliar um arquivo JavaScript (js) passou diretamente a ele (egmongo someFile.js).
Porque o programa mongo avalia o JavaScript diretamente, entradas só devem vir de fontes confiáveis.
.mongorc.js File
Se um arquivo existe .mongorc.js 11, o shell mongo irá avaliar um arquivo .mongorc.js antes de começar. Você pode desativar esse comportamento, passando a opção mongo --norc.
Interface de Status HTTP
A interface de status HTTP fornece uma interface baseada na web, que inclui uma variedade de dados operacionais, logs e relatórios de status em relação à instância mongod ou instancias Mongos. A interface HTTP está sempre disponível na porta numerada 1000 maior do que a porta mongod primário. Por padrão, a porta da interface HTTP é 28017, mas é indiretamente definida usando a opção de porta que lhe permite configurar a porta mongod primário.
Sem a definição net.http.RESTInterfaceEnabled, esta interface é totalmente, somente leitura e de âmbito limitado; no entanto, esta interface pode representar uma exposição. Para desabilitar a interface HTTP, defina a opção de tempo de execução habilitado ou a opção de linha de comando --nohttpinterface. Veja também opções de configuração (página 12).
REST API
A API REST para MongoDB fornece informações adicionais e acesso na parte superior da interface HTTP Status.
Enquanto o REST API não fornece nenhum suporte para inserção, atualização ou remover operações, ele fornece acesso administrativo, e sua acessibilidade representa uma vulnerabilidade em um ambiente seguro. A interface REST é desabilitado por padrão, e não é recomendado para uso em produção.
Se você usar a API REST, por favor, controlar e limitar o acesso à API REST. O REST API não incluir qualquer suporte para autenticação, mesmo quando rodando com autorizações habilitado.
Consulte os seguintes documentos para obter instruções sobre como restringir o acesso à interface API REST:
• Configurar o Linux firewall iptables para MongoDB (página 21)
• Configurar o Windows Firewall netsh para MongoDB (página 24)
2.6 Auditoria
Novo na versão 2.6.
MongoDB Enterprise inclui um recurso de auditoria para mongod e instancias Mongos instâncias. A instalação de auditoria permite que os administradores e usuários para controlar a atividade do sistema para implantações com vários usuários e aplicações. A instalação de auditoria pode gravar eventos de auditoria para o console, o syslog, um arquivo JSON, ou um arquivo BSON. Para mais informações sobre as mensagens de log de ??auditoria, consulte Mensagens de sistema de auditoria de eventos (página 104).
Página 15.
Eventos de Auditoria e Filtro
O sistema de auditoria pode gravar as seguintes operações:
• esquema (DDL),
• conjunto de réplicas,
• autenticação e autorização, e
• operações gerais.
Consulte Ações de Eventos, Detalhes e Resultados (página 104) para as ações específicas gravadas.
Por padrão, o sistema de auditoria registra todas estas operações; no entanto, você pode configurar o --auditFilter opção para restringir os eventos capturados.
Consulte Configurar Sistema de Eventos de Auditoria (página 80) para ativar e configurar a auditoria para MongoDB Enterprise. Para configurar filtros, consulte Filtrar Eventos (página 82).
Garantia de auditoria
O sistema de auditoria escreve todos os eventos de auditoria de 12 a um buffer de memória de eventos de auditoria. MongoDB escreve esse buffer no disco periodicamente. Para eventos coletados a partir de qualquer conexão única, os eventos têm uma ordem total: se MongoDB escreve um evento no disco, o sistema garante que tem escrito todos os eventos anteriores para essa conexão no disco.
Se uma entrada de evento de auditoria corresponde a uma operação que afeta o estado durável do banco de dados, como uma modificação de dados, MongoDB sempre o evento de auditoria para o disco antes de escrever para a revista para essa entrada.
Ou seja, antes de adicionar uma operação para a revista, MongoDB escreve todos os eventos de auditoria sobre a conexão que desencadeou a operação, até e incluindo a entrada para a operação.
Estas garantias de auditoria exigem que MongoDB é executado com o diário (journaling) habilitado.
Aviso: MongoDB pode perder eventos se o servidor termina antes de consolidar os eventos no log de auditoria.
O cliente poderá receber a confirmação do evento antes MongoDB comete no log de auditoria. Por exemplo, enquanto a auditoria uma operação de agregação, o servidor pode falhar depois de retornar o resultado, mas antes as liberações de log de ??auditoria.
2.7 Autenticação Kerberos
Novo na versão 2.4.
Overview
MongoDB Enterprise fornece suporte para autenticação Kerberos de clientes MongoDB para mongod e instancias Mongos.
Kerberos é um protocolo de autenticação padrão da indústria para sistemas cliente / servidor de grande porte. Kerberos permite MongoDB e aplicativos para tirar proveito da infra-estrutura e processos de autenticação existente.
Componentes Kerberos e MongoDB
Principals
Em um sistema baseado em Kerberos, cada participante da comunicação autenticada é conhecida como a "principal", e cada principal deve ter um nome único.
Página 16.
Principals pertencem às unidades administrativas chamados realms. Para cada domínio, o Centro de Distribuição de Chaves Kerberos (KDC) mantém um banco de dados do principal do reino e associados "chaves secretas" dos diretores.
Para a autenticação de cliente-servidor, o cliente solicita do KDC um "bilhete" para o acesso a um ativo específico. KDC usa o segredo do cliente e o segredo do servidor para construir o bilhete que permite que o cliente e o servidor para autenticar-se mutuamente, mantendo os segredos escondidos.
Para a configuração do MongoDB para suporte Kerberos, dois tipos de nomes principais são de interesse: Principals do usuário (página 16) e Principals de serviço (página 16).
User Principal
Para autenticar utilizando Kerberos, você deve adicionar os principais usuário Kerberos para MongoDB para o banco de dados externo $. Nomes de usuário principal tem a forma:
Para cada usuário que deseja autenticar usando Kerberos, você deve criar um usuário correspondente no MongoDB no banco de dados externo $.
Para obter exemplos de como adicionar um usuário para MongoDB, bem como autenticar como aquele usuário, consulte Configurar o MongoDB com autenticação Kerberos no Linux (página 55) e configurar o MongoDB com autenticação Kerberos no Windows (página 58).
Veja também: http://docs.mongodb.org/manualreference/command/nav-gerenciamento de usuários para obter informações gerais sobre como criar e gerenciar usuários em MongoDB.
Principal serviço cada MongoDB mongod e instancias Mongos (ou mongod.exe ou mongos.exe no Windows) deve ter uma entidade de serviço associado. Nomes principais de serviço têm a forma:
Para MongoDB, os
Para especificar um valor diferente para
Nomes principais de serviço deve ser acessível através da rede utilizando a parte do nome de domínio totalmente qualificado (FQDN) de seu nome principal de serviço.
Por padrão, Kerberos tenta identificar hosts usando o arquivo /etc/kerb5.conf antes de usar DNS para resolver hosts.
No Windows, se estiver rodando MongoDB como um serviço, consulte Atribuir nome principal de serviço para MongoDB Serviço do Windows (página 60).
Linux Arquivos Keytab
Sistemas Linux pode armazenar chaves de autenticação Kerberos para uma entidade de serviço (página 16) em arquivos keytab. Cada mongod e mongos exemplo Kerberized rodando em Linux deve ter acesso a um arquivo keytab contendo as chaves para o seu serviço principal (página 16).
Para manter keytab arquivos seguros, permissões de arquivos de uso que restringem o acesso a apenas o usuário que executa o processo mongod ou mongos.
Página 17.
Ingressos
No Linux, os clientes podem usar MongoDB programa kinit do Kerberos para inicializar um cache de credenciais para autenticar o usuário principal para os servidores.
Windows Active Directory
Ao contrário de sistemas Linux, mongod e mongos instâncias em execução no Windows não necessitam de acesso a arquivos keytab. Em vez disso, as instâncias mongod e mongos ler suas credenciais do servidor a partir de um armazenamento de credenciais específicas para o sistema operacional.
No entanto, a partir do Active Directory do Windows, você pode exportar um arquivo keytab para uso em sistemas Linux. Veja Ktpass 13 para obter mais informações.
Autenticação com Kerberos
Para configurar o MongoDB para suporte Kerberos e autenticar, consulte Configurar o MongoDB com autenticação Kerberos no Linux (página 55) e configurar o MongoDB com autenticação Kerberos no Windows (página 58).
Considerações operacionais
O Console HTTP O MongoDB HTTP interface da consola 14 não suporta autenticação Kerberos.
DNS
Cada máquina que executa um mongod ou instância mongos deve ter os registros A e PTR do DNS para fornecer para a frente e de pesquisa inversa.
Sem A e PTR registros de DNS, o anfitrião não pode resolver os componentes do domínio Kerberos ou o Centro de Distribuição de Chaves (KDC).
Sincronização Time System
Para autenticar com sucesso, a hora do sistema para cada instância mongod e mongos deve estar dentro de 5 minutos da hora do sistema dos outros hosts na infra-estrutura de Kerberos.
Kerberizadas MongoDB Ambientes
driver Support
Os seguintes drivers MongoDB suporta a autenticação Kerberos:
• Java - http://docs.mongodb.org/ecosystem/tutorial/authenticate-with-java-driver/
• C# - http://docs.mongodb.org/ecosystem/tutorial/authenticate-with-csharp-driver/
• C++ - http://docs.mongodb.org/ecosystem/tutorial/authenticate-with-cpp-driver/
• Python - http://api.mongodb.org/python/current/examples/authentication.htm
Use com Mecanismo de Autenticação MongoDB adicionais
Embora MongoDB suporta o uso de autenticação Kerberos com outros mecanismos de autenticação, apenas adiciona a outros mecanismos, se necessário. Veja o Incorporar adicionais seção Mecanismos de autenticação em Configurar MongoDB com autenticação Kerberos no Linux (página 55) e configurar o MongoDB com autenticação Kerberos no Windows (página 58) para mais detalhes.
3 Segurança Tutoriais
Os seguintes tutoriais fornecem instruções para habilitar e usar os recursos de segurança disponíveis no MongoDB.
Checklist de Segurança (página 19) A visão geral de alto nível de consideração a segurança global para os administradores de implementações MongoDB. Use esta lista se você é novo para a implantação MongoDB na produção e deseja implementar práticas de segurança de alta qualidade.
Rede de Segurança Tutoriais (página 20) Certifique-se de que a configuração de rede subjacente suporta um ambiente operacional seguro para implementações MongoDB, e limita de forma adequada o acesso a implementações MongoDB.
Configure Linux firewall iptables para MongoDB (página 21) padrões de configuração de firewall básicas e exemplos para iptables em sistemas Linux.
Configure o Windows netsh firewall para MongoDB (página 24) padrões de configuração de firewall básicas e exemplos para netsh em sistemas Windows.
Configurar mongod e mongos para SSL (página 27) SSL permite que os clientes MongoDB para suportar conexões criptografadas para mongod instâncias.
Continue a ler a partir de Tutoriais de Segurança de Rede (página 20) para obter mais informações sobre a execução MongoDB em ambientes seguros.
Segurança Implantação Tutoriais (página 36) Estes tutoriais descrever os procedimentos para a implantação do MongoDB usando autenticação e autorização.
Acesso Tutoriais de Controle (página 40) Estes tutoriais descrever os procedimentos relevantes para a configuração, operação e manutenção do sistema de controle de acesso do MongoDB.
Ativar Cliente de controle de acesso (página 40) descreve o processo para habilitar a autenticação para implementações MongoDB.
Use certificados X.509 para autenticar os clientes (página 44) Utilize X.509 para autenticação do cliente.
Use certificado X.509 para autenticação de associação (página 46) Utilize X.509 para autenticação membro interno para conjuntos de réplicas e clusters Sharded.
Configurar MongoDB com autenticação Kerberos no Linux (página 55) para MongoDB Enterprise Linux, descreve o processo para habilitar a autenticação baseada em Kerberos para implementações MongoDB.
Continue a ler a partir de Controle de Acesso Tutoriais (página 40) para tutoriais adicionais sobre a configuração de sistemas de autenticação do MongoDB.
Ativar autenticação Depois de criar o usuário do administrador (página 43) Descreve um processo alternativo para permitir a autenticação para implementações MongoDB.
Usuário e Função de Gerenciamento de Tutoriais (página 66) do sistema de controle de acesso do MongoDB fornece um sistema de controle de acesso flexível baseada em funções que você pode usar para limitar o acesso a implementações MongoDB. Os tutoriais nesta seção descrevem a configuração de uma configuração do sistema de autorização.
Adicionar um usuário a um banco de dados (página 68) Criar usuários não-administradores que utilizam o sistema de autenticação baseada em funções do MongoDB.
Criar uma função (página 71) Criar papel personalizado.
Modificar o acesso de um usuário (página 76) Modificar as ações disponíveis para um usuário de recursos de bancos de dados específicos.
Exibir Roles (funções) (página 77) Ver os privilégios de uma função.
Continue a ler a partir do usuário e (página 66) Função Tutoriais Gestão para tutoriais adicionais sobre o gerenciamento de usuários e privilégios no sistema de autorização do MongoDB.
Configurar Sistema de Eventos de Auditoria (página 80) Habilitar e configurar o recurso de auditoria de eventos do sistema MongoDB Enterprise.
Criar um relatório de Vulnerabilidade (página 83) Relatório uma vulnerabilidade no MongoDB.
3.1 Segurança Checklist
Este documento fornece uma lista de medidas de segurança que você deve implementar para proteger sua instalação MongoDB.
Exigir autenticação
Ative a autenticação MongoDB e especificar o mecanismo de autenticação. Você pode usar o mecanismo de autenticação MongoDB ou uma estrutura externa existente. A autenticação requer que todos os clientes e servidores de fornecer credenciais válidas antes que eles possam se conectar ao sistema. Em implantações em cluster, ativar a autenticação para cada servidor MongoDB.
Consulte Autenticação (página 6), Ativar controle de acesso de cliente (página 40), e Ativar autenticação em um Sharded Cluster (página 42).
Configurar Controle de acesso baseado em função
Criar funções que definem o acesso exato um conjunto de necessidades dos usuários. Siga o princípio do menor privilégio. Em seguida, criar usuários e atribuir-lhes apenas as funções que necessitam para executar suas operações. Um usuário pode ser uma pessoa ou um aplicativo cliente.
Crie um administrador do usuário em primeiro lugar, em seguida, criar usuários adicionais. Criar um usuário único MongoDB para cada pessoa e aplicativo que acessa o sistema.
Veja Authorization (página 9), criar uma função (página 71), Criar um usuário do administrador (página 66), e adicionar um usuário a um banco de dados (página 68).
Criptografia de comunicação.
Configurar MongoDB para usar SSL para todas as conexões de entrada e saída. Use SSL para criptografar a comunicação entre mongod e componentes Mongos de um cliente MongoDB, bem como entre todos os aplicativos e MongoDB.
Consulte Configurar mongod e mongos para SSL (página 27).
Pagina 20.
Limiter exposição da rede
Certifique-se que o MongoDB é executado em um ambiente de rede confiável e limitar as interfaces em que as instâncias do MongoDB escuta para conexões de entrada. Permitir que os clientes só confiáveis ??para acessar as interfaces de rede e portas nas quais instâncias do MongoDB estão disponíveis.
Veja a configuração bindIp e consulte Configurar Linux firewall iptables para MongoDB (página 21) e configurar o Windows Firewall netsh para MongoDB (página 24).
Atividade Sistema de Auditoria
Acompanhe o acesso e alterações às configurações de banco de dados e dados. MongoDB Enterprise 19 inclui uma instalação de auditoria do sistema que pode gravar os eventos do sistema (por exemplo, operações de usuário, eventos de conexão) em uma instância do MongoDB. Esses registros de auditoria permitem a análise forense e permitem que os administradores para verificar controles adequados.
Veja Auditoria (página 14) e configurar o Sistema de Eventos de Auditoria (página 80).
Criptografar e proteger dados
Criptografar dados MongoDB em cada host usando o sistema de arquivos, o dispositivo, ou criptografia física. Proteja os dados MongoDB usando as permissões do sistema de arquivos. Dados MongoDB inclui arquivos de dados, arquivos de configuração, logs de auditoria e arquivos importantes.
Execute MongoDB com um usuário dedicado
Execute MongoDB com uma conta de usuário do sistema operacional dedicado. Certifique-se de que a conta tem permissões de acesso aos dados, mas sem permissões desnecessárias.
Veja http://docs.mongodb.org/manualinstallation para mais informações sobre a execução MongoDB.
Execute MongoDB com opções de configuração seguros
MongoDB suporta a execução de código JavaScript para certas operações do lado do servidor: MapReduce, o grupo, eval, e US $ onde. Se você não usar essas operações, desativar o script do lado do servidor usando a opção --noscripting na linha de comando.
Use apenas o protocolo fio MongoDB em implementações de produção. Não ative o seguinte, todos os quais permitem que a interface do servidor web: habilitado, net.http.JSONPEnabled e net.http.RESTInterfaceEnabled. Deixe essas pessoas com deficiência, a menos que necessário para a compatibilidade com versões anteriores.
Mantenha a validação de entrada habilitado. MongoDB permite a validação de entrada por padrão através da fixação wireObjectCheck. Isso garante que todos os documentos guardados pela instância mongod são BSON válido.
3.2 Rede de Segurança Tutoriais
Os seguintes tutoriais fornecem informações sobre como manusear segurança de rede para MongoDB.
Configure Linux firewall iptables para MongoDB (página 21) padrões de configuração de firewall básicas e exemplos para iptables em sistemas Linux.
Configure o Windows netsh firewall para MongoDB (página 24) padrões de configuração de firewall básicas e exemplos para netsh em sistemas Windows.
Pagina 21.
Configurar mongod e mongos para SSL (página 27) SSL permite que os clientes do MongoDB para suportar conexões criptografadas para instâncias mongod.
Configuração SSL para Clientes (página 31) Configure os clientes para se conectar a instâncias do MongoDB que usam SSL.
Atualizar um cluster para usar SSL (página 34) processo de atualização sem interrupção para usar SSL.
Configurar MongoDB para FIPS (página 35) Configure para Federal Information Processing Standard (FIPS).
Configurar Linux firewall iptables para MongoDB
Em sistemas Linux contemporâneas, o programa iptables fornece métodos para gerenciar netfilter ou rede capacidades de filtragem de pacotes do kernel Linux. Estas regras de firewall permitem que os administradores controlem quais hosts podem se conectar ao sistema, e a exposição ao risco limite, limitando os anfitriões que podem se conectar a um sistema.
Este documento descreve as configurações de firewall básicas para iptables firewalls em Linux. Use essas abordagens como ponto de partida para a sua organização de rede maior. Para uma descrição pormenorizada das práticas de segurança e gestão de riscos para MongoDB, consulte Conceitos de Segurança (página 6).
Veja também:
Para MongoDB implementações em serviços web da Amazon, consulte a página Amazon EC2, que trata dos Grupos de Segurança da Amazon e outros recursos de segurança específicos do EC2. http://docs.mongodb.org/ecosystem/platforms/amazon-ec2
INPUT (ENTRADA): Controla todo o tráfego de entrada.
OUTPUT (SAÍDA): Controla todo o tráfego de saída.
Dadas as portas padrão (página 12) de todos os processos MongoDB, você deve configurar as regras de redes que permitem necessários apenas a comunicação entre a aplicação e o mongod apropriado e instâncias Mongos.
Esteja ciente de que, por padrão, a política padrão de iptables é permitir que todas as conexões e tráfego, a menos que explicitamente desativado. As alterações de configuração descritas neste documento vai criar regras que permitam explicitamente o tráfego de endereços específicos e em portas específicas, utilizando uma política padrão que ignora todo o tráfego que não é explicitamente permitido. Quando você tiver configurado corretamente suas regras de iptables para permitir apenas o tráfego que você deseja permitir, você pode mudar a política padrão para DROP (página 23).
Padrões
Esta seção contém uma série de padrões e exemplos de configuração de iptables para uso com implantações de MongoDB. Se você tiver configurado portas diferentes usando a configuração da porta, você terá que modificar as regras nesse sentido.
Tráfego de e para Instâncias mongod Este padrão é aplicável a todas as instâncias mongod execução como instâncias independentes ou como parte de um conjunto de réplicas.
O objetivo deste padrão é permitir explicitamente o tráfego para a instância mongod do servidor de aplicativos. Nos exemplos a seguir, substitua
Pagina 22.
iptables -A INPUT -s
iptables -A OUTPUT -d
A primeira regra permite todo o tráfego de entrada de
Opcional
Se você tiver apenas um servidor de aplicativos, você pode substituir
10.10.10.10/24
10.10.10.10/255.255.255.0
Tráfego de instâncias mongos e para instâncias Mongos fornecer roteamento de consulta para clusters Sharded. Os clientes se conectam as instancias Mongos, que se comportam a partir da perspectiva do cliente como instâncias mongod. Por sua vez, os mongos se conectam a todas as instâncias mongod que são componentes do cluster Sharded.
Use o comando same iptables para permitir o tráfego de e para esses casos, como faria a partir das instâncias mongod que são membros do conjunto de réplicas. Pegue a configuração descrita no tráfego de e para Instâncias mongod (página 21) seção como um exemplo.
Configuração do tráfego de e para um servidor MongoDB.
Servidores de configuração, hospedam o banco de dados de configuração que armazena metadados para clusters Sharded. Cada cluster de produção tem três servidores de configuração, iniciado com a opção --configsvr mongod. Servidores de configuração para ouvir conexões na porta 27019. Como resultado, adicione as seguintes regras de iptables para o servidor de configuração para permitir a conexão de entrada e saída na porta 27019, para conexão com os outros servidores de configuração.
iptables -A INPUT -s
iptables -A OUTPUT -d
Substitua
Além disso, os servidores de configuração precisam permitir conexões de entrada de todas as instâncias Mongos no cluster e todas as instâncias mongod no cluster. Adicionar regras semelhantes aos seguintes:
iptables -A INPUT -s
Substitua
Tráfego de e para a MongoDB Shard Server.
Para os servidores de shard, funcionando como mongod --shardsvr Como o número de porta padrão é 27018 quando correr com o valor shardsvr para a definição clusterRole, você deve configurar as seguintes regras de iptables para permitir o tráfego de e para cada fragmento:
iptables -A INPUT -s
iptables -A OUTPUT -d
Substituir o
Pagina 23.
• todas as instâncias mongod em conjuntos de réplicas do shard.
• todas as instâncias mongod em outros shads.
Além disso, shards precisam ser capazes de fazer conexões de saída:
• todas as instâncias Mongos.
• todas as instâncias mongod nos servidores de configuração.
Criar uma regra semelhante à seguinte, e substituir o
iptables -A OUTPUT -d
Fornecer acesso aos sistemas de monitorização
1. A ferramenta mongostat diagnóstico, quando correr com o --discover precisa ser capaz de chegar a todos os componentes de um cluster, incluindo os servidores de configuração, os servidores estilhaço, e as instâncias Mongos.
2. Se as suas necessidades de sistema de monitoramento de acessar a interface HTTP, insira a seguinte regra para a cadeia:
iptables -A INPUT -s
Substitua
Para todas as implantações, você deve restringir o acesso a esta porta somente à ocorrência de monitoramento.
Opcional Para instâncias mongod servidor de configuração em execução com o valor shardsvr para a definição clusterRole, a regra seria semelhante ao seguinte:
iptables -A INPUT -s
Para instâncias mongod servidor configuração atual com o valor configsvr para a definição clusterRole, a regra seria semelhante ao seguinte:
iptables -A INPUT -s
Mudança de política padrão para DROP.
A política padrão para as cadeias do iptables é permitir que todo o tráfego. Depois de concluir todas as alterações de configuração iptables, você deve alterar a política padrão para DROP para que todo o tráfego que não é explicitamente permitido como acima não será capaz de atingir os componentes da implantação MongoDB. Emita os seguintes comandos para alterar esta política:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
Gerenciar e manter a configuração iptables.
Esta seção contém uma série de operações básicas para gerenciamento e uso iptables. Existem várias ferramentas de front-end que automatizam alguns aspectos da configuração do iptables, mas o cerne tudo iptables front-ends fornecer a mesma funcionalidade básica:
Pagina 24.
Faça todas as regras de iptables Persistentes
Por padrão, todas as regras do iptables apenas são armazenados na memória. Quando o sistema for reiniciado, suas regras de firewall será revertida para seus padrões. Quando você testou um conjunto de regras e garantiram que efetivamente controla o tráfego que você pode usar as seguintes operações para que você deve fazer a regra estabelecida persistente.
No Red Hat Enterprise Linux, Fedora Linux e distribuições relacionados você pode emitir o seguinte comando:
service iptables save
No Debian, Ubuntu e distribuições relacionados, você pode usar o seguinte comando para despejar as regras do iptables para o arquivo /etc/iptables.conf:
iptables-save > /etc/iptables.conf
Execute o seguinte procedimento para restaurar as regras de rede:
iptables-restore < /etc/iptables.conf
Coloque este comando no arquivo rc.local, ou no arquivo / etc / network-se up.d / iptables com outras operações similares.
Listar todas as regras de iptables.
Para listar todas as regras de iptables aplicadas atualmente, use a seguinte operação na shell do sistema.
iptables --L
Limpe todas as regras de iptables.
Se você cometer um erro de configuração quando entrar regras de iptables ou simplesmente precisar reverter para o conjunto de regras padrão, você pode usar a seguinte operação na shell do sistema para descarregar todas as regras:
iptables --F
Se você já fez as suas regras de iptables persistente, você terá que repetir o procedimento adequado na seção Marca todas regras de iptables Persistentes (página 24).
Configure o Windows netsh firewall para MongoDB.
Em sistemas Windows Server, o programa netsh fornece métodos para gerenciar o Firewall do Windows. Estas regras de firewall permitem que os administradores controlem quais hosts podem se conectar ao sistema, e a exposição ao risco limite, limitando os anfitriões que podem se conectar a um sistema.
Este documento descreve as configurações básicas do Firewall do Windows. Use essas abordagens como ponto de partida para a sua organização de rede maior. Para um panorama detalhado das práticas de segurança e gestão de riscos para MongoDB, consulte Conceitos de Segurança (página 6).
Veja também:
Documentação Firewall do Windows da Microsoft.
Overview
Firewall do Windows processa as regras de maneira ordenada determinada pelo tipo de regra, e analisado na seguinte ordem:
1. Windows Service Hardening
2. Connection security rules
3. Authenticated Bypass Rules
4. Block Rules
5. Allow Rules
6. Default Rules
Pagina 25.
Por padrão, a política no Firewall do Windows permite que todas as conexões de saída e bloqueia todas as conexões de entrada.
Dadas as portas padrão (página 12) de todos os processos MongoDB, você deve configurar as regras de redes que permitem necessários apenas a comunicação entre a aplicação e o mongod.exe apropriado e mongos.exe instâncias.
As alterações de configuração descritas neste documento vai criar regras que permitam explicitamente o tráfego de endereços específicos e em portas específicas, utilizando uma política padrão que ignora todo o tráfego que não é explicitamente permitido.
Você pode configurar o Firewall do Windows com o uso da ferramenta de linha de comando netsh ou através de um aplicativo do Windows. No Windows Server 2008, esta aplicação é o Firewall do Windows com Segurança Avançada em Ferramentas Administrativas. Em versões anteriores do Windows Server, acessar o aplicativo Firewall do Windows no painel de sistema e controle de segurança.
Os procedimentos descritos neste documento use a ferramenta de linha de comando netsh.
Padrões
Esta seção contém uma série de padrões e exemplos para a configuração do Firewall do Windows para uso com implantações de MongoDB. Se você tiver configurado portas diferentes usando a configuração da porta, você terá que modificar as regras nesse sentido.
Tráfego de e para Instâncias mongod.exe.
Este padrão é aplicável a todas as instâncias mongod.exe execução como instâncias independentes ou como parte de um conjunto de réplicas. O objetivo deste padrão é permitir explicitamente o tráfego para a instância mongod.exe do servidor de aplicativos.
netsh advfirewall firewall add rule name ="Open mongod port 27017"dir=in action=allow protocol=TCP localport=27017
Esta regra permite que todo o tráfego de entrada para a porta 27017, o que permite que o servidor de aplicativos para se conectar à instância mongod.exe.
Firewall do Windows também permite que permite o acesso à rede para um aplicativo inteiro, em vez de uma porta específica, como no seguinte exemplo:
netsh advfirewall firewall add rule name ="Allowing mongod"dir=in action=allow program=" C:\mongodb\bin\mongod.exe"
Você pode permitir que todo o acesso para um servidor mongos.exe, com a seguinte invocação:
netsh advfirewall firewall add rule name ="Allowing mongos"dir=in action=allow program=" C:\mongodb\bin\mongos.exe"
Tráfego de instâncias mongos.exe para instancias mongos.exe, nesses casos fornecer roteamento consulta para clusters Sharded. Os clientes se conectam ao mongos.exe casos, que se comportam a partir da perspectiva do cliente como instâncias mongod.exe. Por sua vez, o mongos.exe conecta a todas as instâncias mongod.exe que são componentes do cluster Sharded.
Use o mesmo comando do Firewall do Windows para permitir o tráfego de e para esses casos, como faria a partir das instâncias mongod.exe que são membros do conjunto de réplicas.
netsh advfirewall firewall add rule name ="Open mongod shard port 27018"dir=in action=allow protocol=TCP localport=27018
Pagina 26.
Configuração do tráfego de e para um servidor MongoDB.
Servidores de configuração, hospedam o banco de dados de configuração que armazena metadados para clusters Sharded. Cada cluster de produção tem três servidores de configuração, iniciado com a opção --configsvr mongod. Servidores de configuração para ouvir conexões na porta 27019. Como resultado, adicione as seguintes regras do Firewall do Windows para o servidor de configuração para permitir a conexão de entrada e saída na porta 27019, para conexão com os outros servidores de configuração.
netsh advfirewall firewall add rule name ="Open mongod config svr port 27019"dir=in action=allow protocol=TCP localport=27019
Além disso, os servidores de configuração precisam permitir conexões de entrada de todas as instâncias mongos.exe no cluster e todas as instâncias mongod.exe no cluster. Adicionar regras semelhantes as seguintes:
netsh advfirewall firewall add rule name = "Open mongod config svr inbound" dir = in action = allow protocol = TCP remoteip =
Substitua
Tráfego de e para um servidor MongoDB Shard
Para os servidores de shard, funcionando como mongod --shardsvr Como o número de porta padrão é 27018 quando correr com o valor shardsvr para a definição clusterRole, você deve configurar as seguintes regras do Firewall do Windows para permitir o tráfego de e para cada fragmento:
netsh advfirewall firewall add rule name = "Open mongod shardsvr inbound" dir = in action = allow protocol = TCP remoteip =
netsh advfirewall firewall add rule name = "Open mongod shardsvr outbound" dir = out action = allow protocol = TCP remoteip =
Substituir o
• todas as instâncias mongod.exe em conjuntos de réplicas do shard.
• todas as instâncias mongod.exe em outros shads.
Além disso, shards precisam ser capazes de fazer conexões de saída:
• todas as instâncias mongos.exe.
• todas as instâncias mongod.exe nos servidores de configuração.
Configuração do tráfego de e para um servidor MongoDB.
Criar uma regra semelhante à seguinte, e substituir o
netsh advfirewall firewall add rule name = "Open mongod config svr outbound" dir = out action = allow protocol = TCP remoteip =
Fornecer acesso aos sistemas de monitorização
1. A ferramenta mongostat tool, quando correr com o --discover precisa ser capaz de chegar a todos os componentes de um cluster, incluindo os servidores de configuração, os servidores estilhaço, e as instâncias mongos.exe.
2. Se as suas necessidades de sistema de monitoramento de acessar a interface HTTP, insira a seguinte regra para a cadeia:
netsh advfirewall firewall add rule name = "Open mongod HTTP monitoring inbound" dir = in action = allow protocol = TCP remoteip =
Substitua
Opcional
Para o servidor de configuração mongod instâncias em execução com o valor shardsvr para a definição clusterRole, a regra seria semelhante ao seguinte:
Pagina 27.
netsh advfirewall firewall add rule name = "Open mongos HTTP monitoring inbound" dir = in action = allow protocol = TCP remoteip =
Para instâncias mongod servidor configuração atual com o valor configsvr para a definição clusterRole, a regra seria semelhante ao seguinte:
netsh advfirewall firewall add rule name = "Open mongod configsvr HTTP monitoring inbound" dir = in action = allow protocol = TCP remoteip =
Configurar e Gerenciar e manter o Firewall do Windows.
Esta seção contém uma série de operações básicas para gerenciamento e uso netsh. Enquanto você pode usar frente a GUI termina para gerenciar o Firewall do Windows, todas as funcionalidades do núcleo é acessível a partir de netsh.
Excluir todas as regras do Firewall do Windows.
Para excluir a regra de firewall que permite o tráfego mongod.exe:
netsh advfirewall firewall delete rule name = "Open mongod port 27017" protocol = tcp localport = 27017
netsh advfirewall firewall delete rule name = "Open mongod shard port 27018" protocol = tcp localport = 27018
Liste todas as regras do Firewall do Windows
Para retornar uma lista de todas as regras do Firewall do Windows:
netsh advfirewall firewall show rule name = all
Redefinir o Firewall do Windows
Para redefinir as regras do Firewall do Windows:
netsh advfirewall reset
Regras de Firewall do Windows Backup e Restauração.
Para simplificar a administração da maior coleção de sistemas, você pode exportar ou importar sistemas de firewall de diferentes servidores) regras muito facilmente no Windows:
netsh advfirewall export "C:\temp\MongoDBfw.wfw"
Substitua "C: \ temp \ MongoDBfw.wfw" com um caminho de sua escolha. Você pode usar um comando da seguinte forma para importar um arquivo criado através desta operação:
netsh advfirewall import "C:\temp\MongoDBfw.wfw"
Configurar mongod e mongos para SSL.
Este documento ajuda a configurar MongoDB para suportar SSL. Clientes MongoDB podem usar SSL para criptografar conexões para mongod e instâncias Mongos.
Nota: A distribuição padrão do MongoDB não contém suporte para SSL. Para usar SSL, você deve construir MongoDB passando localmente a opção --ssl para Scons ou usar MongoDB Enterprise.
Estas instruções pressupõem que você já tenha instalado uma versão do MongoDB que inclui suporte SSL e que o driver cliente suporta SSL. Para obter instruções sobre como atualizar um cluster atualmente não usar SSL para usar SSL, consulte Atualizar um cluster para usar SSL (página 34).
Alterado na versão 2.6: Criptografia SSL de MongoDB só permite o uso de cifras SSL fortes com um mínimo de comprimento de chave de 128 bits para todas as conexões. MongoDB Enterprise para Windows inclui suporte para SSL.
Veja também:
Configuração SSL para Clientes (página 31) para saber mais sobre o suporte SSL para Python, Java, Ruby, e outros clientes.
.pem File
Antes que você possa usar SSL, você deve ter um arquivo .pem contendo um certificado de chave pública e sua chave privada associada MongoDB pode usar qualquer certificado SSL válido emitido por uma autoridade de certificação ou um certificado auto-assinado. Se você usar um certificado auto-assinado, embora o canal de comunicação será criptografada, não haverá a validação da identidade do servidor. Embora tal situação irá evitar a espionagem sobre a conexão, ele te deixa vulnerável a um ataque man-in-the-middle. Usando um certificado assinado por uma autoridade de certificação confiável permitirá motoristas MongoDB para verificar a identidade do servidor.
Em geral, evite o uso de certificados auto-assinados, a menos que a rede é confiável.
Além disso, com relação a autenticação entre conjunto de réplicas / MEMBROS DO CLUSTER SHARDED (tradução duvidavel) (página 8), a fim de minimizar a exposição da chave privada e permitir a validação hostname, é aconselhável a utilização de diferentes certificados em servidores diferentes.
Para fins de teste, você pode gerar um certificado auto-assinado e uma chave privada em um sistema Unix com um comando semelhante à seguinte:
/////////////////////////////////////////////
Pagina 28
/////////////////////////////////////////////
Additionally, with regards to
authentication among replica set/sharded cluster members
(page 8), in order to minimize
exposure of the private key and allow hostname validation, it is advisable to use different certificates on different
servers.
/////////////////////////////////////////////
Nenhum comentário:
Postar um comentário