/ /

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. 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. 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.
`intermediates`	conjunto de documentos	A partir de MongoDB 8.1, si una aplicación cliente se conecta a una instancia `mongod` o `mongos` mediante un balanceador de carga, las direcciones IP y los puertos del equipo cliente de origen y del balanceador de carga se incluyen en el registro de auditoría. Puede usar el registro para asociar un evento de auditoría con el equipo cliente de origen. A partir de MongoDB 8.1, para las conexiones a través de un balanceador de carga, `mongod` o `mongos` analizan el encabezado del protocolo proxy y almacenan la dirección IP y el puerto del equipo cliente de origen 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 de la matriz `intermediates` es un documento con los campos `ip` y `port`. Estos campos representan la dirección IP y el puerto de un balanceador de carga o una instancia `mongos` por la que pasa la solicitud del equipo cliente de origen. Si la solicitud del equipo cliente de origen pasa a través de un balanceador de carga: A partir de MongoDB 8.1, el campo `remote` almacena la dirección IP y el puerto del equipo cliente, que se leen del encabezado del protocolo proxy. El documento `intermediates` contiene la dirección IP y el puerto del balanceador de carga. 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 ocurre en un fragmento: 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 versiones de MongoDB anteriores a 8.1, el campo `remote` almacena la dirección IP y el puerto `mongos`. El documento `intermediates` no se encuentra 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 las conexiones a través de un balanceador de carga, `mongod` o `mongos` analizan el encabezado del protocolo proxy y almacenan la dirección IP y el puerto del equipo cliente de origen 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` 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. Cambiado en la versión 8.1.
`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
- 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 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.

Para obtener más detalles, consulte 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

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 se cambia un parámetro debido a:

Propagación de un comando setClusterParameter
Evento de replicación como reversión
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 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>,
}

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

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

startupOptions Contiene todas las opciones que tiene el nodo después del inicio.
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