自己管理型配置での監査の構成

syslog への出力

監査を有効にし、監査イベントを JSON 形式で syslog に出力するには（Windows ではオプションは使用できません）、--auditDestination 設定に syslog を指定します。以下に例を挙げます。

mongod --dbpath data/db --auditDestination syslog

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ipを指定します。

構成ファイルで次のオプションを指定することもできます。

storage:
   dbPath: data/db
auditLog:
   destination: syslog

コンソールへの出力

監査を有効にして、監査イベントを標準出力する（つまり、stdout）には、--auditDestination 設定に console を指定します。例:

mongod --dbpath data/db --auditDestination console

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ipを指定します。

構成ファイルで次のオプションを指定することもできます。

storage:
   dbPath: data/db
auditLog:
   destination: console

JSON ファイルへの出力

監査を有効にして、監査イベントを JSON 形式のファイルに出力するには、次のオプションを指定します。

たとえば、次の例では監査を有効にし、監査イベントを相対パス名 data/db/auditLog.json のファイルに記録します。

mongod --dbpath data/db --auditDestination file --auditFormat JSON --auditPath data/db/auditLog.json

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ipを指定します。

監査ファイルは、logRotate コマンドを使用して、サーバー ログと一緒に、または個別にローテーションできます。ローテーションの詳細は、systemLog.logRotate 構成ファイル オプションまたは --logRotate コマンドライン オプションを使用して構成できます。

構成ファイルで次のオプションを指定することもできます。

storage:
   dbPath: data/db
auditLog:
   destination: file
   format: JSON
   path: data/db/auditLog.json

BSON ファイルへの出力

監査を有効にして、監査イベントを BSON バイナリ形式のファイルに出力するには、次のオプションを指定します。

たとえば、次の例では監査を有効にし、監査イベントを相対パス名 data/db/auditLog.bson の BSON ファイルに記録します。

mongod --dbpath data/db --auditDestination file --auditFormat BSON --auditPath data/db/auditLog.bson

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ipを指定します。

監査ファイルは、サーバー ログ ファイルと同時に rotated されます。ローテーションの詳細は、systemLog.logRotate 構成ファイル オプションまたは --logRotate コマンドライン オプションを使用して構成できます。

構成ファイルで次のオプションを指定することもできます。

storage:
   dbPath: data/db
auditLog:
   destination: file
   format: BSON
   path: data/db/auditLog.bson

次の例では、 bsondumpを使用して監査ログを読み取り可能な形式に変換し、その結果を出力します。

bsondump data/db/auditLog.bson

保証の分離

MongoDB 5.0 より前では、MongoDB mongod または mongos インスタンスを監査するユーザーは、監査フィルターを更新するために、ホスト サーバーのファイル システムへの書き込みアクセス権を持っている必要がありました。ランタイム監査フィルター管理は、監査アクセス権を管理アクセスから分離することでセキュリティを向上させます。

構成ファイルを直接編集する代わりにランタイム監査フィルター管理を使用することは、次のことを意味します。

• ファイル システムにアクセスする必要ないため、監査するユーザーは mongod または mongos のホスト サーバーにアクセスする必要がありません。

• mongod または mongos インスタンスの構成ファイルに直接アクセスすることはできません。

• ランタイム監査フィルター管理では、監査フィルターと auditAuthorizationSuccess パラメーターのみが公開されます。

実行時の構成可能性

MongoDB 5.0 以降では、ランタイム監査フィルター管理が有効になっている場合、mongod または mongos インスタンスを再起動せずに、実行時に監査を再構成できます。静的に構成されたインスタンスは、監査設定を更新するために再起動する必要があります。

実行時に行われた監査フィルターの変更は、インスタンスをシャットダウンして再起動しても保持されます。

整合性

クラスター内で、参加しているすべての mongod ノードと mongos ノードがランタイム監査フィルター管理を使用するように構成されている場合、すべてのノードは同じ監査フィルターを使用します。一方、各ノードにおいて、独自の監査フィルターがローカルで構成されている場合、ノード間の監査フィルターの整合性は保証されません。

ランタイム監査フィルター管理の有効化

MongoDB 5.0 以降、mongod ノードとmongos ノードの監査を実行時に構成することができます。これらのノードのグループを、分散監査構成に含めることができます。

分散監査構成にノードを含めるには、ノードの構成ファイルを次のように更新し、サーバーを再起動します。

次の場合、サーバーはエラーを記録し、起動に失敗します。

• runtimeConfiguration が true であり、

• auditLog.filterまたはauditAuthorizationSuccess のいずれかが設定されている。

実行時に監査フィルターと auditAuthorizationSuccess パラメーターを変更するには、setAuditConfig を参照してください。