Configurar registros de auditoria

Nesta página

Acesso necessário

Habilitar registros de auditoria
Configurar um filtro de auditoria personalizado

Observação

Este recurso não está disponível para nenhuma das seguintes implantações:

Instâncias sem servidor
M0 clusters
M2/M5 clusters
Clusters flexíveis

Você pode utilizar o Atlas Kubernetes Operator para configurar logs de auditar . Para saber mais,consulte Configurar auditoria de banco de dados.

A auditoria do banco de dados permite que os administradores acompanhem a atividade do sistema para implantações com vários usuários. Os administradores do Atlas podem selecionar as ações, usuários de banco de dados, funções do Atlas e grupos LDAP que desejam auditar. O Atlas suporta auditoria na maioria das ações de eventos do sistema documentadas, com as seguintes limitações:

Quando um Atlas user executa uma ação na UI do Atlas em um cluster, os logs de auditoria e o arquivo mongodb.log registram o usuário de banco de dados mms-automation como o usuário que executa a ação auditável. No entanto, a Lista de Atividade do Projeto registra o nome de usuário real do usuário Atlas user responsável pela ação.
Os registros de auditoria do Atlas não acompanham eventos de criação ou modificação do usuário porque o Atlas executa essas operações diretamente no banco de dados admin .

Importante

Realizando uma auditoria completa do banco de dados

Devido a essas limitações, é necessário usar uma combinação de logs de auditoria, o mongodb.log e o feed de atividades do projeto para realizar uma auditoria completa.

A ação de evento authCheck registra tentativas de autorização por usuários que tentam ler e escrever em bancos de dados nos clusters do seu projeto. O Atlas audita os seguintes comandos específicos:

`authCheck Reads`	`authCheck Writes`
Agregação	Agregação
Redução de mapa	Redução de mapa
distinto	excluir
eval [1]	eval [1]
contar	encontrar e modificar
geoPerto	insert
geopesquisa	update
grupo, grupo	resetError
find
Obter último erro
pegue mais
getPrevError
parallelCollectionScan [1]

[1]	(1, 2, 3) As versões 4.2 do MongoDB e posteriores não permitem esses comandos.

O Atlas implementa a ação de evento authCheck como as quatro ações separadas a seguir:

Ação de Evento	Descrição
`authChecksReadFailures`	`authCheck` ação de evento para todas as leituras com falha com o parâmetro auditAuthorizationSuccess definido como falso. Essa ação de evento é padrão para ações de eventos relacionadas à leitura.
`authChecksReadAll`	`authCheck` ação de eventos para todas as leituras, tanto sucessos quanto falhas. Essa ação de evento é igual a `authChecksReadFailures`, mas com o parâmetro auditAuthorizationSuccess definido como "true". AVISO: se você ativar o auditAuthorizationSuccess, poderá impacto gravemente o desempenho do cluster. Tenha cuidado ao habilitar essa função.
`authChecksWriteFailures`	`authCheck` ação de evento para todas as gravações com falha com o parâmetro auditAuthorizationSuccess definido como falso. Essa ação de evento é padrão para ações de eventos relacionadas à gravação.
`authChecksWriteAll`	`authCheck` ação de evento para todas as gravações, tanto sucessos quanto falhas. Essa ação de evento é igual a `authChecksWriteFailures`, mas com o parâmetro auditAuthorizationSuccess definido como "true". AVISO: se você ativar o auditAuthorizationSuccess, poderá impacto gravemente o desempenho do cluster. Tenha cuidado ao habilitar essa função.

Para saber como o MongoDB grava eventos de auditoria em disco, consulte Garantia de auditoria no Manual do MongoDB.

Acesso necessário

Para configurar os logs de auditar , é necessário ter Project Owner acesso ao projeto que deseja atualizar ou Organization Owner acesso à organização que contém o projeto que deseja atualizar.

Habilitar registros de auditoria

Observação

Para saber mais sobre as práticas recomendadas para auditoria das ações de usuários temporários do banco de dados de dados, consulte Auditar utilizadores temporários de banco de dados.

Para ativar os registros de auditar , defina spec.auditing.enabled como true no AtlasProject Recurso personalizado.

Exemplo:

cat <<EOF | kubectl apply -f -
apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
spec:
  name: TestAuditing
  connectionSecretRef:
    name: my-atlas-key
  projectIpAccessList:
    - cidrBlock: "0.0.0.0/1"
      comment: "Everyone has access. For test purposes only."
    - cidrBlock: "128.0.0.0/1"
      comment: "Everyone has access. For test purposes only."
  auditing:
    enabled: true
 EOF

Para recuperar os registros de auditoria no Atlas, consulte Registros do MongoDB. Para recuperar os registros de auditoria usando a API, consulte Registros.

Configurar um filtro de auditoria personalizado

Observação

Este recurso não está disponível para nenhuma das seguintes implantações:

Instâncias sem servidor
M0 clusters
M2/M5 clusters
Clusters flexíveis

O Atlas oferece suporte à especificação de um filtro de auditoria formatado em JSON para personalizar a auditoria do MongoDB.

Os filtros de auditoria personalizados permitem que os usuários renunciem ao construtor gerenciado de filtros de auditoria Atlas UI em favor do controle granular personalizado da auditoria de eventos. O Atlas verifica apenas se o filtro personalizado utiliza uma sintaxe JSON válida, e não valida ou testa a funcionalidade do filtro.

O documento do filtro de auditoria deve ser resolvido em uma consulta que corresponda a um ou mais campos na mensagem do evento de auditoria. O documento de filtro pode usar combinações de operadores de consulta e condições de igualdade para corresponder às mensagens de auditoria desejadas.

Para exibir exemplos de filtros de auditoria, consulte Exemplos de filtros de auditoria. Para saber mais sobre como configurar filtros de auditoria MongoDB, consulte Configurar filtro de auditoria.

Importante

O Atlas usa uma estratégia de atualização de rolagem para ativar ou atualizar as configurações de auditar em todos os clusters no projeto Atlas . As atualizações de rolagem exigem pelo menos uma eleição por conjunto de réplica.

Para saber mais sobre como testar a resiliência do aplicativo em relação às eleições de conjuntos de réplicas, consulte /tutorial/test-resilience/test-primary-failover. Para saber mais sobre como o Atlas fornece alta disponibilidade, consulte Alta disponibilidade do Atlas.

Para configurar um filtro de auditoria personalizado, especifique a configuração spec.auditing.auditFilter no Recurso PersonalizadoAtlasProject . Para especificar um valor para esta configuração, você deve definir spec.auditing.enabled como true.

Exemplo:

cat <<EOF | kubectl apply -f -
apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
spec:
  name: TestAuditing
  connectionSecretRef:
    name: my-atlas-key
  projectIpAccessList:
    - cidrBlock: "0.0.0.0/1"
      comment: "Everyone has access. For test purposes only."
    - cidrBlock: "128.0.0.0/1"
      comment: "Everyone has access. For test purposes only."
  auditing:
    enabled: true
    auditFilter: "{"atype": "authenticate"}"
 EOF

Para saber mais sobre os parâmetros de configuração disponíveis a partir daAPI do , consulte a Auditoria do Atlas.

Voltar

Alertas de projeto

Serviços de terceiros