/ /

監査の構成

注意

MongoDB Atlas での監査

MongoDB Atlas は、すべてのM10以上のクラスターの監査をサポートしています。 Atlas は、監査フィルターの構成に記載されているように JSON 形式の監査フィルターの指定と、簡素化された監査構成のための Atlas 監査フィルタービルダの使用をサポートしています。詳細については、Atlas のドキュメントデータベース監査の設定およびカスタム監査フィルターの構成を参照してください。

MongoDB Enterpriseは、さまざまな操作の監査をサポートしています。完全な監査ソリューションには、すべてのmongodサーバーとmongosルーターのプロセスが含まれている必要があります。

監査機能は、コンソール、syslog（Windows ではオプションを使用できません）、JSON ファイル、または BSON ファイルに監査するイベントを書き込むことができます。監査した後の操作と監査ログメッセージの詳細については、「システムイベント監査メッセージ」を参照してください。

監査出力の有効化と構成

MongoDB Enterprise で監査を有効にするには、--auditDestination を使用して監査出力先を設定します。

警告

シャーディングされたクラスターの場合、mongos インスタンスで監査を有効にするには、クラスターの mongod インスタンスでも監査を有効にする必要があります。すべてのシャードとコンフィギュレーションサーバーで mongod の監査を構成します。

syslog への出力

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

mongod --dbpath data/db --auditDestination syslog

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

重要

他の IP アドレスにバインドする前に、不正アクセスを防ぐために、自己管理型配置のセキュリティチェックリストに記載されているアクセス制御やその他のセキュリティ対策を有効にすることを検討してください。

警告

syslog メッセージの制限により、監査メッセージが切り捨てられる可能性があります。監査システムは、切り捨てを検出することも、切り捨て時にエラーを発生させることもありません。

Linux システムでは、メッセージは Linux 構成ファイル /etc/systemd/journald.conf で定義されたルールに従います。デフォルトでは、ログメッセージのバーストの上限は 30 秒間に 1,000 メッセージです。表示されるメッセージ数を増やすには、/etc/systemd/journald.conf の RateLimitBurst パラメータを増やします。

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

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

コンソールへの出力

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

mongod --dbpath data/db --auditDestination console

重要

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

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

JSON ファイルへの出力

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

オプション	値
`--auditDestination`	`file`
`--auditFormat`	`JSON`
`--auditPath`	出力ファイル名。完全パス名または相対パス名に対応しています。

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

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

重要

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

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

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

注意

監査イベントを JSON 形式のファイルに出力すると、BSON 形式のファイルに出力するよりもサーバーのパフォーマンスが低下します。

BSON ファイルへの出力

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

オプション	値
`--auditDestination`	`file`
`--auditFormat`	`BSON`
`--auditPath`	出力ファイル名。完全パス名または相対パス名に対応しています。

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

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

重要

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

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

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

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

bsondump data/db/auditLog.bson

OCSF 形式でのメッセージの出力

MongoDB 8.0 以降、MongoDB はログメッセージを OCSF 形式で書き込むことができます。OCSF スキーマは、ログプロセッサと互換性のある標準化された形式でログを提供します。

ログメッセージに OCSF スキーマを使用するには、--auditSchema オプションを OCSF に設定します。以下に例を挙げます。

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

auditLog.schema 構成ファイルオプションで OCSF スキーマを指定することもできます。

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

OCSF スキーマの詳細については、「OCSF スキーマ監査メッセージ」を参照してください。

ランタイム監査フィルター管理

MongoDB 5.0 以降では、監査フィルターを実行時に構成できます。ランタイム監査フィルター管理には、ローカル mongod または mongos 構成ファイルで指定される監査フィルター構成と比較して、次の 3 つの利点があります。

保証の分離
実行時の構成可能性
整合性

保証の分離

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

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

ファイルシステムにアクセスする必要ないため、監査するユーザーは mongod または mongos のホストサーバーにアクセスする必要がありません。
mongod または mongos インスタンスの構成ファイルに直接アクセスすることはできません。
ランタイム監査フィルター管理では、監査フィルターと auditAuthorizationSuccess パラメーターのみが公開されます。

実行時の構成可能性

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

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

整合性

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

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

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

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

Parameter	値
`auditLog.runtimeConfiguration`	`true`
`auditLog.filter`	設定解除
`auditAuthorizationSuccess`	設定解除

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

runtimeConfiguration が true であり、
auditLog.filterまたはauditAuthorizationSuccess のいずれかが設定されている。

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

Tip

戻る

監査

フィルターを構成する