/ /

Auditoria

Mensagens de auditoria

Página inicial do Docs

Gestão

Segurança

Auditoria

Mensagens de auditoria

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 8.3.9
  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	Tipo de ação. Consulte Ações, detalhes e resultados de eventos de auditoria.
`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 `local` campo é preterido. Em vez disso, use o `localEndpoint` campo na mensagem de auditar 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` registra o host 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 por meio de um soquete de domínio Unix, o documento armazenará um campo `unix` em vez dos campos `ip` e `port`. Esse endereço identifica o host que abre a conexão, mesmo quando um balanceador de carga ou proxy reverso afirma um endereço de cliente diferente. O MongoDB aceita conexões de protocolo proxy em uma porta específica. Qualquer host que possa acessar essa porta pode declarar 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 ao 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 repetirá o endereço do cliente que `mongos` encaminha. Se a solicitação vier diretamente de `mongos`, o endereço registrará a instância `mongos`. Novidades na versão 8.3.9.
`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	Código de erro. Consulte Ações, detalhes e resultados de eventos de auditoria.

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

createCollection

{
   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

createIndex

{
  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

dropCollection

{
   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.

dropDatabase

{ ns: <database> }

0 - Sucesso

dropIndex

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

0 - Sucesso

createUser

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

O campo customData é opcional.

0 - Sucesso

dropUser

{
  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

createRole

{
  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

dropRole

{
  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

enableSharding

{ ns: <database> }

0 - Sucesso

shardCollection

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

0 - Sucesso

addShard

{
  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

refineCollectionShardKey

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

0 - Sucesso

removeShard

{ shard: <shard name> }

0 - Sucesso

shutdown

{ }

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

0 - Sucesso

applicationMessage

{ 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

OSCF Schema