Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

getAuditConfig (comando de base de datos)

Importante

Obsoleto en la versión 7.1: Utilice el auditConfig parámetro del clúster en su lugar.

getAuditConfig

Nuevo en la versión 5.0.

getAuditConfig es un comando administrativo que recupera configuraciones de auditoría de mongod y mongos instancias de servidores.

Este comando está disponible en implementaciones alojadas en los siguientes entornos:

  • MongoDB Enterprise: La versión basada en suscripción y autogestionada de MongoDB

  • MongoDB Community: La versión de MongoDB con código fuente disponible, de uso gratuito y autogestionada.

Importante

Este comando no es compatible con los clústeres de MongoDB Atlas. Para obtener información sobre el soporte de Atlas para todos los comandos, consulta Comandos no compatibles.

El comando tiene la siguiente sintaxis:

db.adminCommand(
{
getAuditConfig: 1
}
)

Se debe activar la auditoría para usar getAuditConfig.

Los nodos que no participan en una configuración de auditoría en tiempo de ejecución devuelven la configuración actual de su archivo para auditLog.filter y setParameter.auditAuthorizationSuccess.

Los nodos que participan en la auditoría de ejecución sintetizan su configuración actual a partir de la memoria. Las actualizaciones de configuración se distribuyen a través del mecanismo oplog, lo que significa que las actualizaciones en mongod nodos se distribuyen a nodos secundarios muy rápidamente. Sin embargo, el mecanismo de distribución es diferente en los nodos mongos. Los nodos mongos tienen que poll el servidor primario a intervalos regulares para actualizaciones de configuración. Es posible que veas datos obsoletos debido al retraso en la recopilación si ejecutas setAuditConfig en el servidor principal y getAuditConfig en una partición antes de que la partición haya recabado información nueva del servidor primario.

Nota

Si estás escribiendo scripts de auditoría automatizados, ten en cuenta que el estilo de citado y los tipos usados para representar la firma del clúster difieren entre mongosh y el shell heredado mongo. En mongosh, los tipos son Binary y Long. Los tipos correspondientes en el shell heredado son BinData y NumberLong.

// mongosh
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: Long("0")
}
// mongo
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : Long(0)
}

Ejecute getAuditConfig en la base de datos admin.

db.adminCommand({getAuditConfig: 1})

El servidor de ejemplo está configurado para auditar las operaciones de lectura y guardar. Tiene un filtro que captura las operaciones deseadas y se ha establecido el valor auditAuthorizationSuccess en true.

{
generation: ObjectId("60e73e74680a655705f16525"),
filter: {
atype: 'authCheck',
'param.command': {
'$in': [ 'find', 'insert', 'delete', 'update', 'findandmodify' ]
}
},
auditAuthorizationSuccess: true,
ok: 1,
'$clusterTime': {
clusterTime: Timestamp(1, 1625767540),
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: Long("0")
}
},
operationTime: Timestamp(1, 1625767540)
}

Tip

Volver

fsyncUnlock

En esta página