Configurar auditoria em sistemas autogerenciados
Nesta página
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.
Habilitar e configurar saída de auditoria
Para habilitar a auditoria no MongoDB Enterprise, defina um destino de saída de auditoria com --auditDestination
.
Aviso
Saída para syslog
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
Saída para Console
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
Saída para Arquivo JSON
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.
Saída para arquivo 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
Mensagens de saída no formato OCSF
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.
Gerenciamento de filtros de auditoria em tempo de execução
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
:
Separação de preocupações
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:
O acesso ao sistema de arquivos não é necessário, portanto, um auditor não precisa acessar o servidor host
mongod
oumongos
.Não há acesso direto ao arquivo de configuração da instância
mongod
oumongos
.O gerenciamento de filtros de auditoria em tempo de execução expõe apenas os filtros de auditoria e o parâmetro
auditAuthorizationSuccess
.
Configuração de tempo de execução
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.
Consistência
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.
Habilitar gerenciamento de filtro de auditoria em tempo de execução
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.
Parâmetro | Valor |
---|---|
true | |
Desconfigurar | |
Desconfigurar |
O servidor registra um erro e falha ao iniciar se:
runtimeConfiguration
étrue
eauditLog.filter
ouauditAuthorizationSuccess
estiver definido.
Para modificar os filtros de auditoria e o parâmetro auditAuthorizationSuccess
no tempo de execução, consulte auditConfig
.