監査ログの構成
注意
この機能は、次の配置では使用できません。
サーバーレス インスタンス
M0クラスターM2/M5クラスターFlex クラスター
Atlas Kubernetes Operator を使用して監査するログを構成できます。詳しくは、 「データベース監査の設定」を参照してください。
データベース監査により、管理者は複数のユーザーによる配置のシステム アクティビティを追跡できます。 Atlas 管理者は、監査するアクション、データベースユーザー、Atlas ロール、および LDAP グループを選択できます。 Atlas は次の制限付きで、文書化された システム イベント アクション のほとんどの 監査 をサポートしています。
Atlas userがクラスター上のAtlas UI でアクションを実行すると、監査ログと
mongodb.logファイルの両方に、監査可能なアクションを実行しているユーザーとしてmms-automationデータベースユーザーが記録されます。 ただし、プロジェクト アクティビティ フィードには、アクションを担当するAtlas userの実際のユーザー名が記録されます。Atlas はこれらの操作を
adminデータベースで直接実行するので、Atlas 監査ログではユーザーの作成または変更イベントは追跡されません。
重要
完全なデータベース監査の実行
これらの制限があるため、完全な監査を実行するには、監査ログ、 mongodb.log 、およびプロジェクト アクティビティ フィードを組み合わせて使用する必要があります。
authCheck イベント アクションは、プロジェクト内のクラスター内のデータベースに対して読み取りや書込みを試行するユーザーによる承認試行を記録します。Atlas では、次の特定のコマンドが監査されます。
authCheck Reads | authCheck Writes |
|---|---|
| [1] | （1、2、3）MongoDB バージョン 4.2 以降では、これらのコマンドはサポートされていません。 |
Atlas は、authCheck イベント アクションを次の 4 つの個別のアクションとして実装します。
イベント アクション | 説明 |
|---|---|
authChecksReadFailures | authCheck auditAuthorizationSuccess パラメータが false に設定されている、失敗したすべての読み取りに対するイベント アクション。このイベント アクションは、読み取り関連のイベント アクションのデフォルトです。 |
authChecksReadAll |
警告: auditAuthorizationSuccessを有効にすると、クラスターのパフォーマンスに重大な影響を与える可能性があります。 このオプションを有効にする場合は注意が必要です。 |
authChecksWriteFailures | authCheck auditAuthorizationSuccess パラメータが false に設定されている、すべての失敗した書込み (write) に対するイベント アクション。このイベント アクションは、書込み (write) 関連のイベント アクションのデフォルトです。 |
authChecksWriteAll |
警告: auditAuthorizationSuccessを有効にすると、クラスターのパフォーマンスに重大な影響を与える可能性があります。 このオプションを有効にする場合は注意が必要です。 |
MongoDB が監査イベントをディスクに書き込む方法については、MongoDB マニュアルの「監査保証」を参照してください。
必要なアクセス権
監査ログを構成するには、更新対象のプロジェクトへのProject Ownerアクセス権または更新対象のプロジェクトを含む組織へのOrganization Ownerアクセス権が必要です。
監査ログの有効化
注意
一時データベース ユーザーのアクションを監査するためのベスト プラクティスについては、「 一時データベースユーザーの監査 」を参照してください。
spec.auditing.enabled監査ログを有効にするには、trueAtlasProject カスタム リソース で を に設定します。
例:
cat <<EOF | kubectl apply -f - apiVersion: atlas.mongodb.com/v1 kind: AtlasProject metadata: name: my-project spec: name: TestAuditing connectionSecretRef: name: my-atlas-key projectIpAccessList: - cidrBlock: "0.0.0.0/1" comment: "Everyone has access. For test purposes only." - cidrBlock: "128.0.0.0/1" comment: "Everyone has access. For test purposes only." auditing: enabled: true EOF
Atlas で監査ログを検索するには、 MongoDB ログを参照してください。 API を使用して監査ログを検索するには、「ログ 」を参照してください。
カスタム監査フィルターを構成する
注意
この機能は、次の配置では使用できません。
サーバーレス インスタンス
M0クラスターM2/M5クラスターFlex クラスター
Atlas は、MongoDB Auditing をカスタマイズする JSON 形式の監査フィルターの指定をサポートしています。
カスタム監査フィルターを使用すると、ユーザーは管理された Atlas UI監査フィルター ビルダーを使用せずに、イベント監査を手動で細かく制御できるようになります。 Atlas は、カスタム フィルターが有効な JSON 構文を使用しているかどうかのみをチェックし、フィルターの機能を検証またはテストしません。
監査フィルター ドキュメントは、監査イベント メッセージ内の 1 つ以上のフィールドに一致するクエリに解決される必要があります。フィルター ドキュメントでは、必要な監査メッセージを一致させるために、クエリ演算子と等価条件の組み合わせを使用できます。
監査フィルターの例を表示するには、「監査フィルターの例」を参照してください。MongoDB 監査フィルターの構成の詳細については、「監査フィルターの構成」を参照してください。
重要
Atlas は、Atlas プロジェクト内のすべてのクラスターにわたって監査構成設定を有効化または更新するために、ローリング アップグレード戦略を使用します。 ローリング アップグレードでは、レプリカセットごとに少なくとも 1 回の選挙が必要です。
レプリカセットの選挙に対するアプリケーションの回復力をテストする方法の詳細については、 /SON web token（チュートリアル）/ Test-resident/ Test-primary-failoverを参照してください。 Atlas が高可用性を実現する仕組みについて詳しくは、「 Atlas の高可用性 」を参照してください。
カスタム監査フィルタを構成するには、 カスタム リソース でspec.auditing.auditFilter AtlasProject設定を指定します。この設定の値を指定するには、 spec.auditing.enabledをtrueに設定する必要があります。
例:
cat <<EOF | kubectl apply -f - apiVersion: atlas.mongodb.com/v1 kind: AtlasProject metadata: name: my-project spec: name: TestAuditing connectionSecretRef: name: my-atlas-key projectIpAccessList: - cidrBlock: "0.0.0.0/1" comment: "Everyone has access. For test purposes only." - cidrBlock: "128.0.0.0/1" comment: "Everyone has access. For test purposes only." auditing: enabled: true auditFilter: "{"atype": "authenticate"}" EOF
APIから利用できる構成パラメータの詳細については、「 Atlas監査 」を参照してください。