/ /

Mensajes de auditoría

Docs Home

/ /

Auditoría

Mensajes de auditoría

Mensajes de auditoría

Mensajes de auditoría del esquema mongo

En el mongo Esquema, los mensajes de registro grabados tienen esta 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> },
  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>
}

La siguiente tabla describe los campos del esquema mongo.

Campo	Tipo	Descripción
`atype`	string	Tipo de acción. Ver 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. 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.
`intermediates`	arreglo de documentos	A partir de MongoDB 8.1, si una aplicación cliente se conecta a una instancia `mongod` o `mongos` a través de un balanceador de carga, las direcciones IP y los puertos del computador cliente de origen y del balanceador de carga se incluyen en el registro de auditoría. Puedes utilizar el registro para asociar un evento de auditoría con el ordenador cliente de origen. A partir de MongoDB 8.1, para conexiones a través de un balanceador de carga, `mongod` o `mongos` analiza la cabecera del protocolo proxy y almacena la dirección IP y el puerto de origen de la computadora cliente en el campo `remote`. Además, si se utiliza un balanceador de carga, el documento `intermediates` almacena la dirección IP y el puerto del balanceador de carga. En versiones de MongoDB anteriores a la 8.1, la dirección IP del balanceador de carga y el puerto se almacenan en el campo `remote` y se omite la dirección IP y el puerto del computador cliente de origen. Cada elemento del arreglo en `intermediates` es un documento con los campos `ip` y `port`. Estos campos representan tanto la dirección IP como el puerto de un balanceador de carga o una `mongos` instancia por la que pasa la solicitud de la computadora cliente de origen. Si la solicitud de la computadora cliente de origen pasa por un balanceador de carga: A partir de MongoDB 8.1, el campo `remote` almacena la dirección IP de la computadora cliente y el puerto que se leen del encabezado del protocolo proxy. El documento `intermediates` contiene la dirección IP del balanceador de carga y el puerto. En versiones de MongoDB anteriores a 8.1, el campo `remote` almacena la dirección IP y el puerto del balanceador de carga. El documento `intermediates` no se encuentra en el registro de auditoría. Si el evento de auditoría se produce en una partición: A partir de MongoDB 8.1, el campo `remote` almacena la dirección IP y el puerto del equipo cliente. La dirección y el puerto se leen del encabezado del protocolo proxy o, si el equipo cliente se conecta a `mongos`, se leen de la conexión del equipo cliente de origen. El documento `intermediates` almacena la dirección IP y el puerto `mongos`. Si se utiliza un balanceador de carga, el documento `intermediates` también almacena la dirección IP y el puerto del balanceador de carga. En las versiones de MongoDB anteriores a 8.1, el campo `remote` almacena la dirección IP de `mongos` y el puerto. El documento `intermediates` no está en el registro de auditoría. Nuevo en la versión 8.1.
`remote`	Documento	Un documento que almacena la dirección `ip` y el número `port` de la conexión entrante asociada con el evento. A partir de MongoDB 8.1, para conexiones a través de un balanceador de carga, `mongod` o `mongos` analiza la cabecera del protocolo proxy y almacena la dirección IP y el puerto de origen de la computadora cliente en el campo `remote`. Además, si se utiliza un balanceador de carga, el documento `intermediates` almacena la dirección IP y el puerto del balanceador de carga. En versiones de MongoDB anteriores a la 8.1, la dirección IP del balanceador de carga y el puerto se almacenan en el campo `remote` y se omite la dirección IP y el puerto del computador cliente de origen. 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. Cambiado en la versión 8.1.
`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) (ver authMechanism).

Modificado en la versión 5.0.

- Success
- Authentication Failed
- Mechanism Unavailable
- Authentication Abandoned

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.

Para más detalles, consulte Información 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

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

{
    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 del clúster que tiene el nodo al final del 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

Mensajes de auditoría

OSCF Schema