Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.

Mensagens de auditoria do esquema mongo

No esquema mongo , as mensagens de registro registradas têm esta sintaxe:

{  atype: <string>,  ts : { $date: <timestamp> },  uuid : { $binary: <string>, $type: <string> },  local: { ip: <string>, port: <int> || isSystemUser: <boolean> || unix: <string> },  remote: { ip: <string>, port: <int> || isSystemUser: <boolean> || unix: <string> },  directRemote: { ip: <string>, port: <int> || unix: <string> },   // Added in MongoDB 9.0 *(also available in 8.3.9 and 8.0.33)*  intermediates: [   // Added in MongoDB 8.1     {        // IP address and port for mongos or load balancer        ip: <string>,        port: <int>     }, {        //  IP address and port for mongos or load balancer        ip: <string>,        port: <int>     }  ],  users : [ { user: <string>, db: <string> }, ... ],  roles: [ { role: <string>, db: <string> }, ... ],  param: <document>,  result: <int>}

A tabela seguinte descreve os campos no esquema mongo.

Campo
Tipo
Descrição

atype

string

ts

documento

Documento que contém a data e hora UTC do evento, no formato ISO 8601.

uuid

documento

Um documento que contém um identificador de mensagem.

O UUID identifica uma conexão de cliente. Use o UUID para rastrear eventos de auditoria conectados a esse cliente.

O valor do campo $type é Tipo JSON 04 que indica que o campo $binary contém um UUID.

Novidade na versão 5.0.

local

documento

Um documento que contém o endereço ip e o número port da instância em execução.

A partir do MongoDB 5.0, você pode alternativamente ser um documento com um destes campos:

  • isSystemUser que indica se o usuário que causou o evento era um usuário do sistema. Registrado para trabalhos autorreferenciais iniciados por um processo em segundo plano executado na mesma instância do servidor.

  • unix que contém o caminho do arquivo de soquete MongoDB se o cliente se conectar por meio de um soquete de domínio Unix.

A partir do MongoDB 5.0, o campo local é preterido. Em vez disso, use o campo localEndpoint na mensagem de auditoria ClientMetadata .

Alterado na versão 5.0.

intermediates

matriz de documentos

A partir do MongoDB 8.1, se um aplicação cliente se conectar ao mongos por meio de um balanceador de carga, os endereços IP e portas do computador cliente de origem e do balanceador de carga serão incluídos no registro de auditar . Você pode usar o registro para combinar um evento de auditar com o computador cliente de origem.

A partir do MongoDB 8.1, mongos analisa o cabeçalho do protocolo proxy e armazena o endereço IP e a porta do computador cliente de origem no campo remote. Além disso, se um balanceador de carga for usado, o documento intermediates armazenará o endereço IP e a porta do balanceador de carga.

Nas versões do MongoDB anteriores à 8.1, o endereço IP e a porta do balanceador de carga são armazenados no campo remote, e o endereço IP e a porta do computador cliente de origem são omitidos.

Cada elemento de array em intermediates é um documento com os campos ip e port, que são o endereço IP e a porta de um balanceador de carga, ou mongos pelos quais a solicitação de computador cliente de origem passa.

Se a solicitação do computador cliente de origem passar por um balanceador de carga :

  • A partir do MongoDB 8.1, o campo remote armazena o endereço IP e a porta do computador cliente que são lidos a partir do cabeçalho do protocolo proxy. O documento intermediates contém o endereço IP e a porta do balanceador de carga.

  • Nas versões MongoDB anteriores a 8.1, o campo remote armazena o endereço IP e porta do balanceador de carga. O documento intermediates não está no registro de auditar .

Se o evento de auditar ocorrer em um shard:

  • A partir do MongoDB 8.1, o campo remote armazena o endereço IP e a porta do computador cliente . O endereço e a porta são lidos a partir do cabeçalho do protocolo proxy ou, se o computador cliente se conectar a mongos, o endereço e a porta são lidos a partir da conexão do computador cliente de origem. O documento intermediates armazena o endereço IP e a porta mongos. Se um balanceador de carga for usado, o documento intermediates também armazenará o endereço IP e a porta do balanceador de carga.

  • Nas versões MongoDB anteriores a 8.1, o campo remote armazena o endereço IP e porta do mongos. O documento intermediates não está no registro de auditar .

Novidades na versão 8.1.

remote

documento

Um documento que armazena o endereço ip e o número port da conexão de entrada associada ao evento.

A partir do MongoDB 8.1, mongos analisa o cabeçalho do protocolo proxy e armazena o endereço IP e a porta do computador cliente de origem no campo remote. Além disso, se um balanceador de carga for usado, o documento intermediates armazenará o endereço IP e a porta do balanceador de carga.

Nas versões do MongoDB anteriores à 8.1, o endereço IP e a porta do balanceador de carga são armazenados no campo remote, e o endereço IP e a porta do computador cliente de origem são omitidos.

A partir do MongoDB 5.0, você pode alternativamente ser um documento com um destes campos:

  • isSystemUser que indica se o usuário que causou o evento era um usuário do sistema. Registrado para trabalhos autorreferenciais iniciados por um processo em segundo plano executado na mesma instância do servidor.

  • unix que contém o caminho do arquivo de soquete MongoDB se o cliente se conectar por meio de um soquete de domínio Unix.

O campo directRemote faz o registro do hospedar que abre a conexão quando um balanceador de carga ou proxy reverso afirma o endereço do cliente.

Alterado na versão 8.1.

directRemote

documento

Um documento que armazena o endereço ip e o número port do host que se conecta diretamente à instância. Se o cliente se conectar através de um soquete de domínio Unix, o documento armazena um campo unix em vez dos campos ip e port.

Este endereço identifica o hospedar que abre a conexão, mesmo quando um balanceador de carga ou proxy reverso apresenta um endereço de cliente diferente.

O MongoDB aceita conexões de protocolo proxy em uma porta específica. Qualquer hospedar que possa acessar essa porta pode atribuir um endereço de cliente arbitrário. Para manter o endereço registrado confiável, restrinja o acesso a essa porta ao balanceador de carga ou proxy reverso.

Para eventos de auditar registrados por um shard, o endereço relatado depende de como o shard recebe a solicitação:

  • Se uma instância mongos rotear a solicitação, o endereço repete o endereço do cliente que mongos encaminha.

  • Se a solicitação vier diretamente de mongos, o endereço registrará a instância mongos.

Novidade na versão 9.0: (também disponível a partir de 8.3.9, 8.0.33)

users

array

array de documentos de identificação do usuário. Como o MongoDB permite que uma sessão faça login com um usuário diferente por banco de dados, essa array pode ter mais de um usuário. Cada documento contém um campo user para o nome de usuário e um campo db para o banco de dados de autenticação para esse usuário.

roles

array

Array de documentos que especificam as funções concedidas ao usuário. Cada documento contém um campo role para o nome da função e um campo db para o banco de dados associado à função.

param

documento

Detalhes específicos do evento. Consulte Ações, detalhes e resultados de eventos de auditoria.

result

inteiro

Ações, detalhes e resultados do evento de auditoria

As seguintes listas de tabela para cada atype ou tipo de ação, os detalhes de param associados e os valores de result, se houver.

atype
param
result

authenticate

{  user: <user name>,  db: <database>,  mechanism: <mechanism>}

A partir de MongoDB 5.0, authenticate:

  • Está registado para tentativas de autenticação incompletas.

  • Inclui o nome principal e identificador no mechanism para mecanismos de autenticação externa como X.509 e Amazon Web Services Identity and Access Management (AWS-IAM) (consulte authMechanism).

Alterado na versão 5.0.

0 - Sucesso
18 - Autenticação falhou
334 - Mecanismo indisponível
337 - Autenticação abandonada

authCheck

{  command: <name>,  ns: <database>.<collection>,  args: <command object>}

Registra verificações de autorização para tentativas de usuários de ler ou gravar no banco de dados.

ns o campo é opcional.
o campo args pode ser suprimido.

Por padrão, o sistema de auditoria registra apenas as falhas de autorização. Para habilitar o sistema para registrar os sucessos de autorização, utilize o parâmetro auditAuthorizationSuccess.

Habilitar o auditAuthorizationSuccess degrada o desempenho mais do que registrar somente as falhas de autorização.

Iniciando no MongoDB 5.0, o authCheck não está registrado para ações que são geradas internamente.

Alterado na versão 5.0.

0 - Sucesso
13 - Não autorizado a executar a operação.

clientMetadata

{   localEndpoint : {      ip : <IP address of running instance>,      port : <port of running instance>   } || {      unix : <MongoDB socket file path if connecting through              a Unix domain socket>   },   clientMetadata : {      driver : {         name : <client driver name>,         version : <client driver version>      },      os : {         type : <client operating system type>,         name : <client operating system name>,         architecture : <client operating system architecture>,         version : <client operating system version>      },      platform : <client platform name>,      application : {         name : <client application name>      }   }}

Contém os metadados do cliente. Registrado quando o cliente executa o comando hello.

Para obter mais detalhes,consulte Dados do cliente.

Novidade na versão 5.0.

0 - Sucesso

{   ns: <database>.<collection || view>,   viewOn: <database>.<collection>,   pipeline: [ <pipeline definition> ]}

Registrado quando um:

  • A coleção é criada.eta

  • Visualizar é criado, com o nome de visualização registrado no campo ns.

A partir do MongoDB 5.0, essas informações adicionais são registradas para uma visualização:

  • viewOn campo com o banco de dados e a coleção para a visualização.

  • pipeline com a definição de aggregation pipeline para a visualização.

Alterado na versão 5.0.

0 - Sucesso

createDatabase

{ ns: <database> }

0 - Sucesso

{  ns: <database>.<collection>,  indexName: <index name>,  indexSpec: <index specification>,  indexBuildState: <index build state>}

Os valores possíveis para indexBuildState são:

  • IndexBuildStarted

  • IndexBuildSucceeded

  • IndexBuildAborted

A partir do MongoDB 5.0, createIndex eventos de auditoria são:

  • Registrado no início e fim da criação do índice e inclui uma mensagem indicando se o índice foi criado ou não com sucesso.

  • Atribuído ao usuário de origem para a ação que causou o evento de auditoria createIndex.

  • Registrado para um evento createCollection se a coleção tiver um índice.

Alterado na versão 5.0.

0 - Sucesso
276 - A construção de índice foi interrompida.

A mensagem de auditoria contém o código de resultado 276 para eventos de auditoria createIndex com IndexBuildState definido como IndexBuildAborted. A mensagem de auditoria contém o código de resultado 0 para eventos de auditoria createIndex com IndexBuildState definido como IndexBuildStarted ou IndexBuildSucceeded.

directAuthMutation

{   document: {      <collection modifications>   },   ns: <database>.<collection>,   operation: <database operation>}

Registrado quando uma operação do banco de dados modifica diretamente o conteúdo das coleções do admin.system.users ou admin.system.roles.

Novidade na versão 5.0.

0 - Sucesso

renameCollection

{  old: <database>.<collection>,  new: <database>.<collection>}

0 - Sucesso

{   ns: <database>.<collection || view>,   viewOn: <database>.<collection>,   pipeline: [ <pipeline definition> ]}

Registrado quando um:

  • A coleção foi descartada.

  • Visualizar é descartado, com o nome de visualização registrado no campo ns.

A partir do MongoDB 5.0, essas informações adicionais são registradas para uma visualização:

  • viewOn campo com o banco de dados e a coleção para a visualização.

  • pipeline com a definição de aggregation pipeline para a visualização.

Além disso, a partir do MongoDB 5.0, um evento de auditoria dropCollection é registrado quando ocorre um evento dropDatabase.

Alterado na versão 5.0.

0 - Sucesso
26 - NamespaceNotFound

Se a coleção ou visualização não existir, a mensagem de auditoria mostrará o código de retorno como result: 26.

{ ns: <database> }

0 - Sucesso

{  ns: <database>.<collection>,  indexName: <index name>}

0 - Sucesso

{  user: <user name>,  db: <database>,  customData: <document>,  roles: [     {       role: <role name>,       db: <database>     },     ...  ]}

O campo customData é opcional.

0 - Sucesso

{  user: <user name>,  db: <database>}

0 - Sucesso

dropAllUsersFromDatabase

{ db: <database> }

0 - Sucesso

getClusterParameter

{    requestedClusterServerParameters: <parameters>}

0 - Sucesso

setClusterParameter

{    originalClusterServerParameter: <original parameter value>,    updatedClusterServerParameter": <new parameter value>}

0 - Sucesso

updateCachedClusterServerParameter

{    originalClusterServerParameter: <original parameter value>,    updatedClusterServerParameter": <new parameter value>}

Registrado quando um parâmetro é alterado devido a:

  • Propagação de um comando setClusterParameter

  • Evento de replicação, como reversão

  • Uma atualização dos novos valores de parâmetros do cluster a partir do servidor de configuração em mongos

0 - Sucesso

updateUser

{  user: <user name>,  db: <database>,  passwordChanged: <boolean>,  customData: <document>,  roles: [     {       role: <role name>,       db: <database>     },     ...  ]}

O campo customData é opcional.

0 - Sucesso

grantRolesToUser

{  user: <user name>,  db: <database>,  roles: [     {       role: <role name>,       db: <database>     },     ...  ]}

0 - Sucesso

revokeRolesFromUser

{  user: <user name>,  db: <database>,  roles: [     {       role: <role name>,       db: <database>     },     ...  ]}

0 - Sucesso

{  role: <role name>,  db: <database>,  roles: [     {       role: <role name>,       db: <database>     },     ...  ],  privileges: [    {      resource: <resource document>,      actions: [ <action>, ... ]    },    ...  ]}

Os campos roles e privileges são opcionais.

Para obter detalhes sobre o documento de recurso, consulte Documento de recursos em implementações autogerenciadas. Para uma lista de ações, consulte Ações de Privilégio.

0 - Sucesso

updateRole

{  role: <role name>,  db: <database>,  roles: [     {       role: <role name>,       db: <database>     },     ...  ],  privileges: [    {      resource: <resource document>,      actions: [ <action>, ... ]    },    ...  ]}

Os campos roles e privileges são opcionais.

Para obter detalhes sobre o documento de recurso, consulte Documento de recursos em implementações autogerenciadas. Para uma lista de ações, consulte Ações de Privilégio.

0 - Sucesso

{  role: <role name>,  db: <database>}

0 - Sucesso

dropAllRolesFromDatabase

{ db: <database> }

0 - Sucesso

grantRolesToRole

{  role: <role name>,  db: <database>,  roles: [     {       role: <role name>,       db: <database>     },     ...  ]}

0 - Sucesso

revokeRolesFromRole

{  role: <role name>,  db: <database>,  roles: [     {       role: <role name>,       db: <database>     },     ...  ]}

0 - Sucesso

grantPrivilegesToRole

{  role: <role name>,  db: <database>,  privileges: [    {      resource: <resource document>,      actions: [ <action>, ... ]    },    ...  ]}

Para obter detalhes sobre o documento de recurso, consulte Documento de recursos em implementações autogerenciadas. Para uma lista de ações, consulte Ações de Privilégio.

0 - Sucesso

revokePrivilegesFromRole

{  role: <role name>,  db: <database name>,  privileges: [    {      resource: <resource document>,      actions: [ <action>, ... ]    },    ...  ]}

Para obter detalhes sobre o documento de recurso, consulte Documento de recursos em implementações autogerenciadas. Para uma lista de ações, consulte Ações de Privilégio.

0 - Sucesso

replSetReconfig

{  old: {   _id: <replicaSetName>,   version: <number>,   ...   members: [ ... ],   settings: { ... }  },  new: {   _id: <replicaSetName>,   version: <number>,   ...   members: [ ... ],   settings: { ... }  }}

Para obter detalhes sobre o documento de configuração do conjunto de réplicas, consulte Configuração do conjunto de réplicas autogerenciado.

0 - Sucesso

{ ns: <database> }

0 - Sucesso

shardCollection

{  ns: <database>.<collection>,  key: <shard key pattern>,  options: { unique: <boolean> }}

0 - Sucesso

{  shard: <shard name>,  connectionString: <hostname>:<port>,}

Quando um shard é um conjunto de réplicas, o connectionString inclui o nome do conjunto de réplicas e pode incluir outros membros do conjunto de réplicas.

0 - Sucesso

{  ns: <database>.<collection>,  key: <shard key pattern>}

0 - Sucesso

{ shard: <shard name> }

0 - Sucesso

{ }

Indica o início da desativação do banco de dados.

0 - Sucesso

{ msg: <custom message string> }

Consulte logApplicationMessage.

0 - Sucesso

logout

{  reason: <string>,  initialUsers: [ <document>, ... ],  updatedUsers: [ <document>, ... ],}
reason será:

  • "Desconexão explícita do <database>"

  • "Desconexão implícita devido ao encerramento da conexão com o cliente"

initialUsers é um conjunto de documentos que contêm usuários autenticados no cliente atual antes de sair.

updatedUsers é uma array de documentos que contém usuários que devem ser autenticados no cliente atual após o evento de logout.

Cada documento em initialUsers e updatedUsers contém:

  • user: o nome de usuário

  • db: o banco de dados user é autenticado para

Novidade na versão 5.0.

0 - Sucesso

startup

{    startupOptions: <document>,    initialClusterServerParameter: <array of documents>}

  • startupOptions contém todas as opções que o nó tem após a inicialização

  • initialClusterServerParameters contém os valores iniciais dos parâmetros do servidor de cluster que o nó tem no final da inicialização:

    • depois de terem sido carregados do armazenamento (para mongod)

    • depois de terem sido atualizados no servidor de configuração (para mongos).

Novidade na versão 5.0.

Alterado na versão 6.1.

0 - Sucesso

Voltar
Mensagens de auditoria
Próximo
OSCF Schema
Avalie esta página

Nesta página