getAuditConfig
重要
バージョン7.1では非推奨 : 代わりに、 auditConfig
クラスター パラメータを使用してください。
定義
getAuditConfig
バージョン 5.0 で追加
getAuditConfig
は、mongod
とmongos
サーバー インスタンスから監査構成を取得する管理コマンドです。
互換性
このコマンドは、次の環境でホストされている配置で使用できます。
MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン
MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン
重要
このコマンドは、 MongoDB Atlasクラスターではサポートされていません。 すべてのコマンドの Atlas サポートの詳細については、「 サポートされていないコマンド 」を参照してください。
構文
このコマンドの構文は、次のとおりです。
db.adminCommand( { getAuditConfig: 1 } )
動作
を使用するには、 監査getAuditConfig
を有効にする必要があります。
ランタイム監査構成に参加していないノードは、 auditLog.filter
とsetParameter.auditAuthorizationSuccess
の現在の構成ファイル設定を返します。
ランタイム監査に参加しているノードは、メモリから現在の構成を同期します。 構成の更新はoplogメカニズムを介して分散されるため、 mongod
ノードの更新はセカンダリ ノードにすばやく分散されます。 ただし、 mongos
ノードでは分散メカニズムは異なります。 mongos
ノードは、構成更新のために定期的にプライマリ サーバーをpoll
する必要があります。 setAuditConfig
シャードがプライマリgetAuditConfig
サーバーでアップデートされた構成の詳細をポーリングする前に、プライマリ サーバーで を実行し、 シャード で を実行すると、ポーリング遅延により古いデータが表示される可能性があります。
注意
自動監査スクリプトを作成している場合は、引用符のスタイルとクラスター署名を表すために使用される型が、 mongosh
とレガシーのmongo
shell では異なることに注意してください。 mongosh
では、型は Binary と Long、Long です。 レガシー shell で対応する型は、BinData と NumberLong です。
// mongosh signature: { hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0), keyId: Long("0") } // mongo "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) }
例
admin
データベース でgetAuditConfig
を実行します。
db.adminCommand({getAuditConfig: 1})
サンプル サーバーは、読み取りおよび書込み操作を監査するように構成されています。 必要な操作をキャプチャするフィルターがあり、 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) }