注意
このページは、Atlas InfiniteとAtlas Coreの両方に適用されます。
データベース監査により、管理者は複数のユーザーによる配置のシステム アクティビティを追跡できます。Atlas 管理者は、監査するアクション、データベースユーザー、Atlas ロール、および LDAP グループを選択できます。Atlas は、文書化された システムイベントアクション のほとんどの 監査 をサポートしています。
authCheck イベント アクションは、プロジェクト内のクラスター内のデータベースに対して読み取りや書込みを試行するユーザーによる承認試行を記録します。Atlas では、次の特定のコマンドが監査されます。
authCheck Reads | authCheck Writes |
|---|---|
mapReduce (MongoDB 5.0 で非推奨) | mapReduce (MongoDB 5.0 で非推奨) |
geoNear (MongoDB 4.2 で削除) | |
geoSearch (MongoDB 5.0 で削除) | |
group (MongoDB 4.2 で削除) | resetError (MongoDB 5.0 で削除) |
getLastError (MongoDB 5.1 で削除) | |
getPrevError (MongoDB 4.2 で削除) |
Atlas は、authCheck イベント アクションを次の 4 つの個別のアクションとして実装します。
イベント アクション | 説明 |
|---|---|
|
|
|
警告: auditAuthorizationSuccessを有効にすると、クラスターのパフォーマンスに重大な影響を与える可能性があります。 このオプションを有効にする場合は注意が必要です。 |
|
|
|
警告: auditAuthorizationSuccessを有効にすると、クラスターのパフォーマンスに重大な影響を与える可能性があります。 このオプションを有効にする場合は注意が必要です。 |
MongoDB が監査イベントをディスクに書き込む方法については、MongoDB マニュアルの「監査保証」を参照してください。
必要なアクセス権
監査ログを構成するには、更新するプロジェクトへの Project Owner アクセス権、または更新するプロジェクトを含む組織への Organization Owner アクセス権が必要です。
監査推奨イベントを含む監査とロギングの推奨事項については、Atlas アーキテクチャ センターの「Atlas 監査とログ のガイダンス」を参照してください。
注意
MongoDB Atlas共有責任モデルは、安全で回復力のあるデータ環境を維持するためのMongoDBとそのカスタマーの補完的な役割を定義します。このフレームワークの下、 MongoDB は基礎のプラットフォームのセキュリティと運用上の整合性を管理しますが、カスタマーは特定の配置の構成、管理、データ ポリシーに責任を負います。所有者のセキュリティと運用の優れ性の詳細な内訳については、共有責任モデルを参照してください。
プロジェクト内のすべてのクラスターでデータベース監査が有効になっているように強制するには、 Atlas リソース ポリシー を使用します。クラスターを作成または変更する前に、リソースポリシー を使用して、データベース監査を要求できます。
手順
注意
一時データベース ユーザーのアクションを監査するためのベスト プラクティスについては、「一時データベース ユーザーの監査」を参照してください。
データベース監査を設定するには、次の手順に従います。
Atlas で、プロジェクトの Advanced ページに移動します。
まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。
サイドバーで、 Security見出しの下のDatabase & Network Accessをクリックします。
サイドバーで、Advanced をクリックします。
詳細ページが表示されます。
認証の失敗を監査することを確認します。
デフォルトでは、Atlas は既知ユーザーと不明ユーザーの両方の失敗した認証試行を、プライマリ ノードの監査ログに記録します。
Select users and roles でアクションを監査するデータベース ユーザー、Atlas ロール、および LDAP グループを選択します。
または Use Custom JSON Filter をクリックして、監査フィルターを JSON 文字列として手動で入力します。Atlas でカスタム監査フィルターを構成する方法の詳細については、「カスタム監査フィルターの構成」を参照してください。
Select actions to audit で監査対象のイベント アクションを選択します。
注意
authenticate アクションの選択を解除すると、Atlas は認証失敗を監査できなくなります。
注意
authCheck イベント アクションでの監査の承認成功の粒度を選択する場合、Atlas は読み取りと書込み (write) の異なる選択をサポートしません。たとえば、authCheck Reads の代わりに Successes and Failures を選択したり、authCheck Writes の代わりに Failures を選択したりすることはできません。authCheck Reads と authCheck Writes の両方を選択した場合、Atlas は選択した粒度を両方に自動的に適用します。
Atlas で監査ログを検索するには、MongoDB ログを参照してください。API を使用して監査ログを検索するには、「ログ」を参照してください。
カスタム監査フィルターを構成する
Atlas は、MongoDB Auditing をカスタマイズする JSON 形式の監査フィルターの指定をサポートしています。
カスタム監査フィルターを使用すると、ユーザーは管理さマネージド Atlas UI 監査フィルタービルダーを使用せずに、イベント監査を手動で細かく制御できるようになります。Atlas は、カスタム フィルターが有効な JSON 構文を使用しているかどうかのみをチェックし、フィルターの機能を検証またはテストしません。
監査フィルター ドキュメントは、監査イベント メッセージ内の 1 つ以上のフィールドに一致するクエリに解決される必要があります。フィルター ドキュメントでは、必要な監査メッセージを一致させるために、クエリ演算子と等価条件の組み合わせを使用できます。
監査フィルターの例を表示するには、「監査フィルターの例」を参照してください。MongoDB 監査フィルターの構成の詳細については、「監査フィルターの構成」を参照してください。
重要
Atlas は、Atlas プロジェクト内のすべてのクラスターにわたって監査構成設定を有効化または更新するために、ローリング アップデート 戦略を使用します。ローリング アップデートでは、レプリカセットごとに少なくとも 1 回の選挙が必要です。
レプリカセットの選挙に対するアプリケーションの回復力をテストする方法の詳細については、「プライマリ フェイルオーバーのテスト」を参照してください。Atlas が高可用性を実現する仕組みについて詳しくは、「Atlas の高可用性」を参照してください。
手順
Atlas で、プロジェクトの Advanced ページに移動します。
まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。
サイドバーで、 Security見出しの下のDatabase & Network Accessをクリックします。
サイドバーで、Advanced をクリックします。
詳細ページが表示されます。
Audit authorization successes を切り替えます。
警告
Audit authorization successes を有効にすると、クラスターのパフォーマンスに重大な影響を与える可能性があります。このオプションを有効にする場合は注意が必要です。
authCheck アクション型を指定する監査フィルターは、デフォルトでは監査システムは指定された param.command の承認の失敗のみをログに記録します。Audit authorization successes を有効にすると、監査システムは承認の成功もログに記録するように指示します。auditAuthorizationSuccess を有効にしないと、監査システムは アクションタイプ で指定された CRUD 操作の成功をログに記録できません。詳しくは、「auditAuthorizationSuccess 」を参照してください。
カスタムの監査フィルターを編集する
フィルターはいつでも編集できます。
Atlas で、プロジェクトの Advanced ページに移動します。
まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。
サイドバーで、 Security見出しの下のDatabase & Network Accessをクリックします。
サイドバーで、Advanced をクリックします。
詳細ページが表示されます。
カスタム監査フィルターを表示する
Atlas で、プロジェクトの Advanced ページに移動します。
まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。
サイドバーで、 Security見出しの下のDatabase & Network Accessをクリックします。
サイドバーで、Advanced をクリックします。
詳細ページが表示されます。
監査フィルターの例
独自のフィルターを作成する際のガイドとして、次の監査フィルターの例を使用してください。
重要
これらの例は本番環境での使用を意図したものではなく、MongoDB 監査ドキュメントに関する知識の代替となるものでもありません。
既知のユーザーのすべての認証イベントを監査する
{ "atype": "authenticate"}既知のユーザーのすべての認証イベントと未知のユーザーの認証失敗を監査する
{ "$or": [ { "users": [] }, { "atype": "authenticate" } ]}注意
既知および未知のユーザーからの認証失敗をログに記録するには、authenticate アクションが必要です。
「myClusterAdministrator」ユーザーの認証イベントを監査する
{ "atype": "authenticate", "param": { "user": "myClusterAdministrator", "db": "admin", "mechanism": "SCRAM-SHA-256" }}選択したコマンドを実行する不正な試みを監査する
{ "atype": "authCheck", "param.command": { "$in": [ "insert", "update", "delete" ] }}ユーザーの作成と削除 イベントを監査する
{ "atype": { "$in": [ "createUser", "dropUser", "directAuthMutation" ] }}注意
directAuthMutationアクションは、 admin.system.users コレクションと admin.system.roles コレクションへの直接変更を追跡します。これには、Atlas が adminデータベースで直接実行する SCRAM ユーザーの作成と変更操作が含まれます。
監査するログのモニタリングエージェント クエリ
データベース監査を有効にすると、監査ログに mms-monitoring-agent ユーザーからのクエリが表示される場合があります。これらのクエリは、Atlas がモニタリング機能のメトリクスとパフォーマンス データを収集するために使用する内部操作です。
mms-monitoring-agent ユーザーは clusterMonitor と directShardOperations のロールを持ち、次の Atlas モニタリング機能の代わりにクエリを実行します。
クエリインサイト: クエリパフォーマンスの統計と形状を収集し、低速クエリの特定に役立ちます。
Namespace Insights:
latencyStatsヒストグラムを使用した $collStats 集計パイプラインを使用してコレクションレベルのレイテンシ統計を収集します。その他のパフォーマンス メトリクス: モニタリング ダッシュボードのデータベースとクラスターの統計を検索します。
監査するログのエントリ例
次の例は、Namespace Insights クエリの監査するログエントリを示しています。このクエリは、$collStats ステージを使用してコレクションのレイテンシ統計を収集します。
{ "atype": "authCheck", "ts": { "$date": "2025-11-20T13:44:20.201+00:00" }, "users": [ { "user": "mms-monitoring-agent", "db": "admin" } ], "roles": [ { "role": "clusterMonitor", "db": "admin" }, { "role": "directShardOperations", "db": "admin" } ], "param": { "command": "aggregate", "ns": "test_db.people_1234", "args": { "aggregate": "people_1234", "pipeline": [ { "$collStats": { "latencyStats": { "histograms": true } } } ], "$readPreference": { "mode": "nearest" } } }, "result": 0}これらのクエリは予期される動作であり、アクションは必要ありません。監査ログからモニタリングエージェントのクエリを除外する場合は、カスタム監査フィルターを作成できます。詳細については、カスタム監査フィルターの構成を参照してください。
Atlas CLI によるデータベースの監査を管理する
Atlas CLI を使用して、プロジェクトのデータベース監査構成を管理できます。
監査構成の更新
Atlas CLI で指定したプロジェクトの監査設定を更新するには、次のコマンドを実行します。
atlas auditing update [options]コマンド構文とパラメータの詳細については、Atlas CLI ドキュメントの atlas 監査する 更新 を参照してください。
監査構成の表示
Atlas CLI で指定したプロジェクトの監査構成を取得するには、次のコマンドを実行します。
atlas auditing describe [options]コマンドの構文とパラメータについて詳しくは、Atlas CLI ドキュメントの atlas auditing describe を参照してください。