Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / /

Configurar auditoria em sistemas autogerenciados

Nesta página

  • Habilitar e configurar saída de auditoria
  • Gerenciamento de filtros de auditoria em tempo de execução

Observação

Auditoria no MongoDB Atlas

O MongoDB Atlas oferece suporte de auditoria para todos os clusters M10 e maiores. O Atlas oferece suporte à especificação de um filtro de auditar formatado em JSON, conforme documentado em Configurar filtros de auditoria em implementações autogerenciadas e no uso do construtor de filtros de auditar do Atlas para simplificar a configuração de auditoria. Para saber mais, consulte a documentação do Atlas para Configurar auditoria do banco de dados e Configurar um filtro de auditoria personalizado.

O MongoDB Enterprise oferece suporte à auditoria de várias operações. Uma solução de auditoria completa deve envolver todos os processos do servidor mongod e do roteador mongos.

A instalação de auditar pode escrever eventos de auditar no console, o syslog (opção não está disponível no Windows), um arquivo JSON ou um arquivo BSON. Para obter detalhes sobre as operações auditadas e as mensagens de registro de auditar , consulte Mensagens de auditoria de eventos do sistema em implantações autogerenciadas.

Para habilitar a auditoria no MongoDB Enterprise, defina um destino de saída de auditoria com --auditDestination.

Aviso

Para clusters fragmentados, se você habilitar a auditoria em instâncias do mongos, você também deverá habilitar a auditoria nas instâncias do mongod do cluster. Configure a auditoria para mongod em todos os fragmentos e servidores de configuração.

Para habilitar a auditoria e imprimir eventos de auditoria no syslog (a opção não está disponível no Windows) no formato JSON, especifique syslog para a configuração do --auditDestination. Por exemplo:

mongod --dbpath data/db --auditDestination syslog

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip.

Importante

Antes de vincular-se a outros endereços IP, considere ativar o controle de acesso e outras medidas de segurança listadas na Lista de verificação de segurança para implementações autogerenciadas para evitar o acesso não autorizado.

Aviso

O limite de mensagens syslog pode resultar no truncamento de mensagens de auditoria. O sistema de auditoria não detectará o truncamento nem erro na sua ocorrência.

Em um sistema Linux, as mensagens estão sujeitas às regras definidas no arquivo de configuração do Linux /etc/systemd/journald.conf. Por padrão, as intermitências de mensagens de registro são limitadas a 1.000 mensagens em um período de 30 segundos. Para ver mais mensagens, aumente o parâmetro RateLimitBurst em /etc/systemd/journald.conf.

Você também pode especificar estas opções no arquivo de configuração:

storage:
dbPath: data/db
auditLog:
destination: syslog

Para habilitar a auditoria e imprimir os eventos de auditoria para o resultado padrão (ou seja, stdout), especifique console para a configuração --auditDestination. Por exemplo:

mongod --dbpath data/db --auditDestination console

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip.

Importante

Antes de vincular-se a outros endereços IP, considere ativar o controle de acesso e outras medidas de segurança listadas na Lista de verificação de segurança para implementações autogerenciadas para evitar o acesso não autorizado.

Você também pode especificar estas opções no arquivo de configuração:

storage:
dbPath: data/db
auditLog:
destination: console

Para habilitar a auditoria e imprimir eventos de auditoria em um arquivo no formato JSON, especifique as seguintes opções:

Opção
Valor
file
JSON
O nome do arquivo de saída. Aceita o nome completo do caminho ou o nome relativo do caminho.

Por exemplo, o seguinte habilita a auditoria e registra eventos de auditoria em um arquivo com o nome de caminho relativo de data/db/auditLog.json:

mongod --dbpath data/db --auditDestination file --auditFormat JSON --auditPath data/db/auditLog.json

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip.

Importante

Antes de vincular-se a outros endereços IP, considere ativar o controle de acesso e outras medidas de segurança listadas na Lista de verificação de segurança para implementações autogerenciadas para evitar o acesso não autorizado.

O arquivo de auditoria pode ser girado com o comando logRotate, junto com o log do servidor ou de forma independente. As especificações de rotação podem ser configuradas com a opção de arquivo de configuração systemLog.logRotate ou a opção de linha de comando --logRotate.

Você também pode especificar estas opções no arquivo de configuração:

storage:
dbPath: data/db
auditLog:
destination: file
format: JSON
path: data/db/auditLog.json

Observação

A impressão de eventos de auditoria em um arquivo no formato JSON degrada mais o desempenho do servidor do que a impressão em um arquivo no formato BSON.

Para habilitar eventos de auditoria e imprimir eventos de auditoria em um arquivo no formato binário BSON, especifique as seguintes opções:

Opção
Valor
file
BSON
O nome do arquivo de saída. Aceita o nome completo do caminho ou o nome relativo do caminho.

Por exemplo, o seguinte permite a auditoria e registra eventos de auditoria em um arquivo BSON com o nome do caminho relativo de data/db/auditLog.bson:

mongod --dbpath data/db --auditDestination file --auditFormat BSON --auditPath data/db/auditLog.bson

Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip.

Importante

Antes de vincular-se a outros endereços IP, considere ativar o controle de acesso e outras medidas de segurança listadas na Lista de verificação de segurança para implementações autogerenciadas para evitar o acesso não autorizado.

O arquivo de auditoria é rotated ao mesmo tempo que o arquivo de log do servidor. As especificações de rotação podem ser configuradas com a opção systemLog.logRotate do arquivo de configuração ou com a opção --logRotate da linha de comando.

Você também pode especificar estas opções no arquivo de configuração:

storage:
dbPath: data/db
auditLog:
destination: file
format: BSON
path: data/db/auditLog.bson

O exemplo a seguir converte o log de auditoria em formulário legível utilizando bsondump e gera o resultado:

bsondump data/db/auditLog.bson

A partir do MongoDB 8.0, O MongoDB pode escrever mensagens de log no formato OCSF . O esquema OCSF fornece logs em um formato padronizado compatível com processadores de log.

Para usar o esquema OCSF para mensagens de log, defina a opção --auditSchema como OCSF. Por exemplo:

mongod --dbpath data/db --auditDestination file --auditFormat JSON --auditPath data/db/auditLog.json --auditSchema OCSF

Você também pode especificar o esquema OCSF na opção de arquivo de configuração auditLog.schema:

storage:
dbPath: data/db
auditLog:
destination: file
format: JSON
path: data/db/auditLog.json
schema: OCSF

Para obter mais informações sobre o esquema OCSF, consulte Mensagens de auditoria do esquema OCSF.

A partir do MongoDB 5.0, os filtros de auditoria podem ser configurados no tempo de execução. O gerenciamento de filtros de auditoria em tempo de execução oferece três benefícios em comparação com as configurações de filtros de auditoria especificadas em um arquivo de configuração local mongod ou mongos:

Antes do MongoDB 50, todos os auditórios de uma instância do MongoDB mongod ou mongos precisavam ter acesso de gravação ao sistema de arquivos do servidor host para atualizar os filtros de auditoria. O Gerenciamento de Filtros de Auditoria em tempo de execução melhora a segurança separando o acesso de auditoria do acesso administrativo.

Usar o Gerenciamento de Filtro de Auditoria em Tempo de Execução em vez de editar arquivos de configuração significa diretamente:

A partir do MongoDB 5.0, quando o Gerenciamento de filtros de auditoria em tempo de execução está ativado, a auditoria pode ser reconfigurada em tempo de execução sem reiniciar a instância mongod ou mongos. Uma instância configurada estaticamente deve ser reiniciada para atualizar suas configurações de auditoria.

As modificações do filtro de auditoria feitas no tempo de execução persistem quando uma instância é desligada e reiniciada.

Em um cluster, se todos os nós mongod e mongos participantes estiverem configurados para usar o Gerenciamento de filtros de auditoria em tempo de execução, todos os nós usarão os mesmos filtros de auditoria. Por outro lado, se cada nó tiver seus próprios filtros de auditoria configurados localmente, não haverá garantia de consistência dos filtros de auditoria entre os nós.

A partir do MongoDB 5.0, as configurações de auditoria para nós mongod e mongos podem ser configuradas em tempo de execução.l Um grupo desses nós pode participar de uma configuração de auditoria distribuída.

Para incluir um nó em uma configuração de auditoria distribuída, atualize o arquivo de configuração do nó da seguinte maneira e reinicie o servidor.

O servidor registra um erro e falha ao iniciar se:

Para modificar os filtros de auditoria e o parâmetro auditAuthorizationSuccess no tempo de execução, consulte auditConfig.

Dica

Veja também:

Voltar

Auditoria