/ /

Mensajes de auditoría de eventos del sistema

Nota

Mensajes de auditoría de eventos del sistema están disponibles en MongoDB Enterprise and MongoDB Atlas.

Para obtener más información sobre esta funcionalidad en MongoDB Atlas, consulta la documentación de Atlas para Configurar la auditoría de la base de datos y Ver y descargar los registros de MongoDB.

Mensaje de auditoría

La funcionalidad de auditoría de eventos puede registrar eventos en formato JSON. Para configurar la salida de auditoría, consulta 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. Consulta Acciones, detalles y resultados del evento de auditoría.
`ts`	Documento	Documento que contiene la fecha y la hora UTC del evento, en formato ISO 8601.
`uuid`	Documento	Un documento que contiene un identificador de mensaje. La UUID identifica una conexión de cliente. Utilice el UUID para rastrear eventos de auditoría conectados a ese cliente. El valor del campo `$type` es tipo BSON `04` que indica que el campo `$binary` 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` que indica si el usuario que causó el evento era un usuario del sistema. Se registra para tareas autoreferenciales iniciadas por un proceso en segundo plano que se ejecuta en la misma instancia del servidor. `unix` que contiene la ruta del archivo del 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 campo `local` está en desuso. Use el campo `localEndpoint` 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` que indica si el usuario que causó el evento era un usuario del sistema. Se registra para tareas autoreferenciales iniciadas por un proceso en segundo plano que se ejecuta en la misma instancia del servidor. `unix` que contiene la ruta del archivo del 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	Arreglo de documentos de identificación de usuario. Debido a que MongoDB permite que una sesión inicie sesión con diferentes usuarios por base de datos, este arreglo puede tener 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	Arreglo de documentos que especifica los roles otorgados al usuario. Cada documento contiene un campo `role` para el nombre del rol y un campo `db` para la base de datos asociada al rol.
`param`	Documento	Detalles específicos del evento. Consulta 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 asociados de param y los valores de result, si los hay.

atype

param

result

authenticate

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

A partir de MongoDB 5.0, authenticate:

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

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.

Por defecto, el sistema de auditoría sólo registra los fallos de autorización. Para permitir que el sistema registre los éxitos de autorización, utilice el parámetro auditAuthorizationSuccess.

Habilitar auditAuthorizationSuccess degrada el rendimiento más que registrar únicamente los fallos de 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 comando hello.

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 un:

La colección está creada.
Se crea Ver, con el nombre de la vista registrado en el campo ns.

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

viewOn campo con la base de datos y la colección para la vista.
pipeline campo con la pipeline de agregación definició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, los eventos createIndex de auditoría son:

Registrado al principio 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 original por la acción que causó el evento de auditoría createIndex.
Registrado para un evento createCollection si la colección tiene un índice.

Modificado en la versión 5.0.

0 - Success

276 - Index build aborted.

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

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 admin.system.users o admin.system.roles colecciones.

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 un:

La colección se ha descartada.
Ver se descarta, y el nombre de la vista se registra en el campo ns.

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

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

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

Modificado en la versión 5.0.

0 - Success

26 - NamespaceNotFound

Si no existe la colección o vista, 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

getClusterParameter

{
    requestedClusterServerParameters: <parameters>
}

0 - éxito

setClusterParameter

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

0 - éxito

updateCachedClusterServerParameter

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

Se registra cuando un parámetro se cambia debido a:

Propagación de un comando setClusterParameter
Evento de replicación como rollback
Una actualización de nuevos valores de parámetros de clúster desde el servidor de configuración en mongos

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 detalles sobre el documento de recursos, consulte el Documento de recursos sobre implementaciones autogestionadas. Para obtener una lista de acciones, consulta Acciones de privilegio.

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.

Para obtener detalles sobre el documento de recursos, consulte el Documento de recursos sobre implementaciones autogestionadas. Para obtener una lista de acciones, consulta Acciones de privilegio.

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>, ... ]
    },
    ...
  ]
}

Para obtener detalles sobre el documento de recursos, consulte el Documento de recursos sobre implementaciones autogestionadas. Para obtener una lista de acciones, consulta Acciones de privilegio.

0 - éxito

revokePrivilegesFromRole

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

Para obtener detalles sobre el documento de recursos, consulte el Documento de recursos sobre implementaciones autogestionadas. Para obtener una lista de acciones, consulta Acciones de privilegio.

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

Cuando una partición es un set de réplicas, el connectionString incluye el nombre del set de réplicas y puede incluir otros nodos del set 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 cierre 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á uno de los siguientes:

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

initialUsers es un arreglo de documentos que contiene usuarios autenticados en el cliente actual antes del cierre de sesión.

updatedUsers es un arreglo de documentos que contiene los usuarios que se espera estén autenticados en el cliente actual después del evento de cierre de sesión.

Cada documento en initialUsers y updatedUsers contiene:

usernombre de usuario
dbla base de datos user está autenticada para

Nuevo en la versión 5.0.

0 - éxito

startup

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

startupOptions contiene todas las opciones que el nodo tiene después de iniciar
initialClusterServerParameters contiene los valores iniciales de los parámetros del servidor de clúster que tiene el nodo tras el inicio:
- después de haberse cargado desde el almacenamiento (para mongod)
- después de que se hayan actualizado desde el servidor de configuración (para mongos).

Nuevo en la versión 5.0.

Cambiado en la versión 6.1.

0 - éxito

Volver

Configurar filtros

mongo esquema