Database Manual / Reference / Database Commands / Auditing

getAuditConfig (database command数据库命令)

Important

Deprecated in version 7.1: Use the auditConfig cluster parameter instead.7.1版本中已弃用:请改用auditConfig集群参数。

Definition定义

getAuditConfig

New in version 5.0.在版本5.0中新增。

getAuditConfig is an administrative command that retrieves audit configurations from mongod and mongos server instances.是一个管理命令,用于从mongodmongos服务器实例检索审计配置。

Compatibility兼容性

This command is available in deployments hosted in the following environments:此命令在以下环境中托管的部署中可用:

  • MongoDB Enterprise: The subscription-based, self-managed version of MongoDB:MongoDB的基于订阅的自我管理版本
  • MongoDB Community: The source-available, free-to-use, and self-managed version of MongoDB:MongoDB的源代码可用、免费使用和自我管理版本

Important

This command is not supported in MongoDB Atlas clusters. MongoDB Atlas集群不支持此命令。For information on Atlas support for all commands, see Unsupported Commands.有关Atlas支持所有命令的信息,请参阅不支持的命令

Syntax语法

The command has the following syntax:该命令具有以下语法:

db.adminCommand(
{
getAuditConfig: 1
}
)

Behavior行为

Auditing must be enabled to use getAuditConfig.必须启用审核才能使用getAuditConfig

Nodes that are not participating in a runtime audit configuration return their current configuration file settings for auditLog.filter and setParameter.auditAuthorizationSuccess.未参与运行时审核配置的节点返回其当前的auditLog.filtersetParameter.auditAuthorizationSuccess配置文件设置。

Nodes that are participating in the runtime audit synthesize their current configuration from memory. 参与运行时审计的节点从内存中合成其当前配置。Configuration updates are distributed via the oplog mechanism which means updates on mongod nodes are distributed to secondary nodes very quickly. 配置更新是通过oplog机制分发的,这意味着mongod节点上的更新会很快分发到辅助节点。However, the distribution mechanism is different on mongos nodes. 然而,mongos节点上的分布机制不同。mongos nodes have to poll the primary server at regular intervals for configuration updates. mongos节点必须定期poll(轮询)primary服务器以获取配置更新。You may see stale data due to polling delay if you run setAuditConfig on the primary server and getAuditConfig on a shard before the shard has polled the primary server for updated configuration details.如果在分片轮询主服务器以获取更新的配置详细信息之前,在primary服务器上运行setAuditConfig并在分片上运行getAuditConfig,则可能会由于轮询延迟而看到过时的数据。

Note

If you are writing automated audit scripts, note that the quoting style and the types used to represent the cluster signature differ between mongosh and the legacy mongo shell. In mongosh the types are Binary and Long. The corresponding types in the legacy shell are BinData and NumberLong.如果您正在编写自动审计脚本,请注意,mongosh和遗留mongoshell之间用于表示集群签名的引用样式和类型不同。在mongosh中,类型是Binary和Long。遗留shell中的相应类型是BinData和NumberLong。

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

// mongo
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : Long(0)
}

Examples示例

Run getAuditConfig on the admin database .admin数据库上运行getAuditConfig

db.adminCommand({getAuditConfig: 1})

The example server is configured to audit read and write operations. It has a filter which captures the desired operations and the auditAuthorizationSuccess value has been set to true.示例服务器被配置为审核读写操作。它有一个筛选器,可以捕获所需的操作,并且auditAuthorizationSuccess值已设置为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)
}