Observação
- Esta funcionalidade não está disponível para clusters
M0e clustersFlex.
You can use Atlas Kubernetes Operator to configure audit logs. To learn more, see Set Up Database Auditing.
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, os usuários de banco de dados, as funções do Atlas e os grupos LDAP que desejam auditar. O Atlas suporta auditoria na maioria das ações de eventos do sistema documentadas, com as seguintes limitações:
When an Atlas user performs an action in the Atlas UI on a cluster, both the audit logs and
mongodb.logfile log themms-automationdatabase user as the user performing the auditable action. However, the Project Activity Feed logs the actual username of the Atlas user responsible for the action.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 |
|---|---|
| [1] | (1, 2, 3) MongoDB versions 4.2 and later don't support these commands. |
O Atlas implementa a ação de evento authCheck como as quatro ações separadas a seguir:
Ação de Evento | Descrição |
|---|---|
|
|
|
AVISO: se você ativar o auditAuthorizationSuccess, poderá impacto gravemente o desempenho do cluster. Tenha cuidado ao habilitar essa função. |
|
|
|
AVISO: se você ativar o auditAuthorizationSuccess, poderá impacto gravemente o desempenho do cluster. Tenha cuidado ao habilitar essa função. |
To learn about how MongoDB writes audit events to disk, see Audit Guarantee in the MongoDB Manual.
Acesso necessário
To configure audit logs, you must have Project Owner access to the project that you want to update or Organization Owner access to the organization that contains the project that you want to update.
Habilitar registros de auditoria
Observação
Para saber mais sobre as melhores práticas para auditar as ações de usuários temporários de banco de dados, consulte Auditar usuários temporários de banco de dados.
Para ativar os log 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
To retrieve the audit logs in Atlas, see MongoDB Logs. To retrieve the audit logs using the API, see Logs.
Configurar um filtro de auditoria personalizado
Observação
- Esta funcionalidade não está disponível para clusters
M0e clustersFlex.
O Atlas oferece suporte à especificação de um filtro de auditoria formatado em JSON para personalizar a auditoria do MongoDB.
Custom audit filters lets users forgo the managed Atlas UI auditing filter builder in favor of hand-tailored granular control of event auditing. Atlas checks only that the custom filter uses valid JSON syntax, and doesn't validate or test the filter's functionality.
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
Atlas uses a rolling update strategy for enabling or updating audit configuration settings across all clusters in the Atlas project. Rolling updates require at least one election per replica set.
To learn more about testing application resilience to replica set elections, see /tutorial/test-resilience/test-primary-failover. To learn more about how Atlas provides high availability, see Atlas High Availability.
Para configurar um filtro de auditoria personalizado, especifique a configuração spec.auditing.auditFilter no AtlasProject Recurso. Para especificar um valor para esta configuração, você deve configurar spec.auditing.enabled para 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
To learn more about the configuration parameters available from the API, see the Atlas Auditing.