/ /

Mensajes de auditoría de eventos del sistema

Esta versión de la documentación está archivada y ya no recibe soporte. Para actualizar su implementación 6.0, consulte Procedimientos de actualización de MongoDB.7.0

Nota

Los mensajes de auditoría de eventos del sistema están disponibles en MongoDB Enterprise y MongoDB Atlas.

Para obtener más información sobre esta función en MongoDB Atlas, consulte la documentación de Atlas para Configurar la auditoría de bases de datosy Ver y descargar registros de MongoDB.

Mensaje de auditoría

La función de auditoría de eventos puede registrar eventos en formato JSON. Para configurar la salida de auditoría, consulte Configurar auditoría.

Modificado en la versión 5.0.

Los mensajes JSON grabados tienen la siguiente sintaxis:

{
  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> },
  users : [ { user: <string>, db: <string> }, ... ],
  roles: [ { role: <string>, db: <string> }, ... ],
  param: <document>,
  result: <int>
}

Campo	Tipo	Descripción
`atype`	string	Tipo de acción.Consulte Acciones, detalles y resultados del evento de auditoría.
`ts`	Documento	Documento que contiene la fecha y hora UTC del evento, en formato ISO 8601.
`uuid`	Documento	Un documento que contiene un identificador de mensaje. El ElUUID identifica la conexión de un cliente. Úselo para rastrear los eventos de auditoría conectados a ese cliente. El valor del `$type` campo es de tipo BSON, `04` lo que indica que el `$binary` campo contiene un UUID. Nuevo en la versión 5.0.
`local`	Documento	Un documento que contiene la dirección `ip` y el número `port` de la instancia en ejecución. A partir de MongoDB 5.0, también puede ser un documento con uno de estos campos: `isSystemUser` Esto indica si el usuario que causó el evento era un usuario del sistema. Se registra para trabajos autorreferenciales iniciados por un proceso en segundo plano que se ejecuta en la misma instancia del servidor. `unix` que contiene la ruta del archivo de socket de MongoDB si el cliente se conecta a través de un socket de dominio Unix. Nota A partir de MongoDB,5.0 el `local` campo está obsoleto. En su lugar, utilice `localEndpoint` el campo en el mensaje de auditoría clientMetadata. Modificado en la versión 5.0.
`remote`	Documento	Un documento que contiene la dirección `ip` y el número `port` de la conexión entrante asociada con el evento. A partir de MongoDB 5.0, también puede ser un documento con uno de estos campos: `isSystemUser` Esto indica si el usuario que causó el evento era un usuario del sistema. Se registra para trabajos autorreferenciales iniciados por un proceso en segundo plano que se ejecuta en la misma instancia del servidor. `unix` que contiene la ruta del archivo de socket de MongoDB si el cliente se conecta a través de un socket de dominio Unix. Modificado en la versión 5.0.
`users`	arreglo	Matriz de documentos de identificación de usuario. Dado que MongoDB permite iniciar sesión con diferentes usuarios por base de datos, esta matriz puede contener más de un usuario. Cada documento contiene un campo `user` para el nombre de usuario y un campo `db` para la base de datos de autenticación de ese usuario.
`roles`	arreglo	Matriz de documentos que especifican los roles asignados al usuario. Cada documento contiene un `role` campo para el nombre del rol y un `db` campo para la base de datos asociada.
`param`	Documento	Detalles específicos del evento. Consulte "Acciones, detalles y resultados del evento de auditoría".
`result`	entero	Código de error. Consulta Acciones, detalles y resultados de eventos de auditoría.

Acciones, detalles y resultados de eventos de auditoría

La siguiente tabla enumera para cada atype o tipo de acción, los detalles param asociados y los valores result, si los hay.

atype

param

result

authenticate

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

A partir de MongoDB 5.0, authenticate:

Se registra por intentos de autenticación incompletos.
Incluye el nombre principal y el identificador en mechanism para mecanismos de autenticación externos como x.509 y Amazon Web Services Identity and Access Management (AWS-IAM) authMechanism (consulte).

Modificado en la versión 5.0.

- Success
- Authentication Failed
- Mechanism Unavailable

authCheck

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

ns field is optional.

args field may be redacted.

De forma predeterminada, el sistema de auditoría solo registra los fallos de autorización. Para que el sistema registre las autorizaciones exitosas, utilice el auditAuthorizationSuccess parámetro.

Habilitar degrada el rendimiento más que registrar solo las fallas de auditAuthorizationSuccess autorización.

A partir de MongoDB 5.0, authCheck no se registra para las acciones que se generan internamente.

Modificado en la versión 5.0.

0 - Success

13 - Unauthorized to perform the operation.

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>
      }
   }
}

Contiene los metadatos del cliente. Se registra cuando el cliente ejecuta el hello comando.

Tip

Datos del cliente

Nuevo en la versión 5.0.

0 - Éxito

createCollection

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

Registrado cuando:

Se ha creado la colección.
Se crea lavista ns y el nombre de la vista se registra en el campo.

A partir de MongoDB 5.0, esta información adicional se registra para una vista:

viewOn campo con la base de datos y colección para la vista.
pipeline campo con la definición de la canalización de agregación para la vista.

Modificado en la versión 5.0.

0 - Éxito

createDatabase

{ ns: <database> }

0 - Éxito

createIndex

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

Los valores posibles para indexBuildState son:

IndexBuildStarted
IndexBuildSucceeded
IndexBuildAborted

A partir de MongoDB,5.0 createIndex eventos de auditoría son:

Se registra al inicio y al final de la creación del índice e incluye un mensaje que indica si el índice se creó correctamente o no.
Atribuido al usuario de origen por la acción que provocó el createIndex evento de auditoría.
Se registra para un evento si la colección tiene un createCollection índice.

Modificado en la versión 5.0.

0 - Success

276 - Index build aborted.

El mensaje de auditoría contiene el código de resultado 276 para eventos createIndex de auditoría con IndexBuildState establecido IndexBuildAborted en. El mensaje de auditoría contiene el código de resultado 0 para createIndex eventos de auditoría con IndexBuildState establecido IndexBuildStarted en IndexBuildSucceeded o.

directAuthMutation

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

Se registra cuando una operación de base de datos modifica directamente el contenido de las colecciones admin.system.users admin.system.roles o.

Nuevo en la versión 5.0.

0 - Éxito

renameCollection

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

0 - Éxito

dropCollection

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

Registrado cuando:

La colección se ha abandonado.
Se descarta lavista ns y el nombre de la vista se registra en el campo.

A partir de MongoDB 5.0, esta información adicional se registra para una vista:

viewOn campo con la base de datos y colección para la vista.
pipeline campo con la definición de la canalización de agregación para la vista.

Además, a partir de MongoDB,5.0 se registra un evento dropCollection dropDatabase de auditoría cuando ocurre un evento.

Modificado en la versión 5.0.

0 - Success

26 - NamespaceNotFound

Si la colección o vista no existe, el mensaje de auditoría muestra el código de retorno como result: 26.

dropDatabase

{ ns: <database> }

0 - Éxito

dropIndex

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

0 - Éxito

createUser

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

El campo customData es opcional.

0 - Éxito

dropUser

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

0 - Éxito

dropAllUsersFromDatabase

{ db: <database> }

0 - Éxito

updateUser

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

El campo customData es opcional.

0 - Éxito

grantRolesToUser

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

0 - Éxito

revokeRolesFromUser

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

0 - Éxito

createRole

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

Los campos roles y privileges son opcionales.

Para obtener más información sobre el documento de recursos, consulte el documento de recursos sobre implementaciones autogestionadas. Para obtener una lista de acciones, consulte Acciones de privilegios.

0 - Éxito

updateRole

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

Los campos roles y privileges son opcionales.

0 - Éxito

dropRole

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

0 - Éxito

dropAllRolesFromDatabase

{ db: <database> }

0 - Éxito

grantRolesToRole

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

0 - Éxito

revokeRolesFromRole

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

0 - Éxito

grantPrivilegesToRole

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

0 - Éxito

revokePrivilegesFromRole

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

0 - Éxito

replSetReconfig

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

Para obtener detalles sobre el documento de configuración del set de réplicas, consulte Configuración del set de réplicas autogestionado.

0 - Éxito

enableSharding

{ ns: <database> }

0 - Éxito

shardCollection

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

0 - Éxito

addShard

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

Cuando un fragmento es un conjunto de réplicas, connectionString incluye el nombre del conjunto de réplicas y puede incluir otros miembros del conjunto de réplicas.

0 - Éxito

refineCollectionShardKey

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

0 - Éxito

removeShard

{ shard: <shard name> }

0 - Éxito

shutdown

{ }

Indica el inicio del apagado de la base de datos.

0 - Éxito

applicationMessage

{ msg: <custom message string> }

Consulte logApplicationMessage.

0 - Éxito

logout

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

reason será:

"Cierre de sesión explícito de <database>"
"Cierre de sesión implícito debido al cierre de la conexión del cliente"

initialUsers es una matriz de documentos que contienen usuarios autenticados en el cliente actual antes de cerrar sesión.

updatedUsers es una matriz de documentos que contienen usuarios que se espera que se autentiquen en el cliente actual después del evento de cierre de sesión.

Cada documento en initialUsers y updatedUsers contiene:

user: el nombre de usuario
db:la base de datos user está autenticada

Nuevo en la versión 5.0.

0 - Éxito

startup

{ options: <document> }

El documento options contiene las opciones con las que se inició la instancia.

Nuevo en la versión 5.0.

0 - Éxito

Volver

Configurar filtros

Utilizar una restricción a nivel de campo