/ /

Mensajes de auditoría de eventos del sistema

Esta versión de la documentación se archivó y ya no se admite. Para actualizar tu implementación de 6.0, consulta el Procedimientos de actualización de MongoDB.7.0

Nota

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 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 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 `$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` 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 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 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 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	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 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 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 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 de origen por la acción que provocó el createIndex evento de auditoría.
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.
Se descarta lavista ns y el nombre de la vista se registra en el campo.

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

viewOn campo con la base de datos y 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 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 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>,
  maxSize: <maxSize>
}

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 una matriz de documentos que contienen usuarios autenticados en el cliente actual antes de cerrar 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:

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