自己管理型配置での監査の構成
注意
MongoDB Atlas での監査
MongoDB Atlas は、すべてのM10
以上のクラスターの監査をサポートしています。 Atlas は、 自己管理型配置で監査フィルターの構成に記載されているように JSON 形式の監査フィルターの指定と、簡素化された監査構成のための Atlas 監査フィルタービルダの使用をサポートしています。 詳細については、Atlas のドキュメントデータベース監査の設定 および カスタム監査フィルターの構成 を参照してください。
MongoDB Enterpriseは、さまざまな操作の監査をサポートしています。 完全な監査ソリューションには、すべてのmongod
サーバーとmongos
ルーターのプロセスが含まれている必要があります。
監査機能は、コンソール、 syslog (Windows ではオプションを使用できません)、JSON ファイル、または BSON ファイルに監査するイベントを書き込むことができます。 監査した後の操作と監査ログメッセージの詳細については、「自己管理型配置のシステムイベント監査メッセージ 」を参照してください。
監査出力の有効化と構成
MongoDB Enterprise で監査を有効にするには、--auditDestination
を使用して監査出力先を設定します。
警告
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
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ip
を指定します。
重要
他の 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
を指定します。
重要
他の IP アドレスにバインドする前に、不正アクセスを防ぐため に、 自己管理型配置のセキュリティ チェックリスト に 記載されている アクセス制御 やその他のセキュリティ対策を有効にすること を検討してください。
監査ファイルは、logRotate
コマンドを使用して、サーバー ログと一緒に、または個別にローテーションできます。ローテーションの詳細は、systemLog.logRotate
構成ファイル オプションまたは --logRotate
コマンドライン オプションを使用して構成できます。
構成ファイルで次のオプションを指定することもできます。
storage: dbPath: data/db auditLog: destination: file format: JSON path: data/db/auditLog.json
注意
監査イベントを JSON 形式のファイルに出力すると、BSON 形式のファイルに出力するよりもサーバーのパフォーマンスが低下します。
BSON ファイルへの出力
監査を有効にして、監査イベントを BSON バイナリ形式のファイルに出力するには、次のオプションを指定します。
オプション | 値 |
---|---|
| |
| |
出力ファイル名。完全パス名または相対パス名に対応しています。 |
たとえば、次の例では監査を有効にし、監査イベントを相対パス名 data/db/auditLog.bson
の BSON ファイルに記録します。
mongod --dbpath data/db --auditDestination file --auditFormat BSON --auditPath data/db/auditLog.bson
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ip
を指定します。
重要
他の 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
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
インスタンスを監査するユーザーは、監査フィルターを更新するために、ホスト サーバーのファイル システムへの書き込みアクセス権を持っている必要がありました。ランタイム監査フィルター管理は、監査アクセス権を管理アクセスから分離することでセキュリティを向上させます。
構成ファイルを直接編集する代わりにランタイム監査フィルター管理を使用することは、次のことを意味します。
実行時の構成可能性
MongoDB 5.0 以降では、ランタイム監査フィルター管理が有効になっている場合、mongod
または mongos
インスタンスを再起動せずに、実行時に監査を再構成できます。静的に構成されたインスタンスは、監査設定を更新するために再起動する必要があります。
実行時に行われた監査フィルターの変更は、インスタンスをシャットダウンして再起動しても保持されます。
整合性
クラスター内で、参加しているすべての mongod
ノードと mongos
ノードがランタイム監査フィルター管理を使用するように構成されている場合、すべてのノードは同じ監査フィルターを使用します。一方、各ノードにおいて、独自の監査フィルターがローカルで構成されている場合、ノード間の監査フィルターの整合性は保証されません。
ランタイム監査フィルター管理の有効化
MongoDB 5.0 以降、mongod
ノードとmongos
ノードの監査を実行時に構成することができます。これらのノードのグループを、分散監査構成に含めることができます。
分散監査構成にノードを含めるには、ノードの構成ファイルを次のように更新し、サーバーを再起動します。
Parameter | 値 |
---|---|
| |
設定解除 | |
設定解除 |
次の場合、サーバーはエラーを記録し、起動に失敗します。
runtimeConfiguration
がtrue
で、かつauditLog.filter
またはauditAuthorizationSuccess
のいずれかが設定されている。
実行時に監査フィルターと auditAuthorizationSuccess
パラメーターを変更するには、auditConfig
を参照してください。