注意
この機能は、
M0
無料クラスター、M2
、M5
クラスターでは使用できません。詳しくは、Atlas M0(無料クラスター)の制限 を参照してください。この機能は現時点では、サーバーレスインスタンスではサポートされていません。 詳細については、「サーバーレス インスタンスの制限 」を参照してください。
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 つの個別のアクションとして実装します。
イベント アクション | 説明 |
---|---|
|
|
|
警告: auditAuthorizationSuccessを有効にすると、クラスターのパフォーマンスに重大な影響を与える可能性があります。 このオプションを有効にする場合は注意が必要です。 |
|
|
|
警告: auditAuthorizationSuccessを有効にすると、クラスターのパフォーマンスに重大な影響を与える可能性があります。 このオプションを有効にする場合は注意が必要です。 |
MongoDB が監査イベントをディスクに書き込む方法については、MongoDB マニュアルの「監査保証」を参照してください。
必要なアクセス権
監査ログを構成するには、更新対象のプロジェクトへのProject Owner
アクセス権または更新対象のプロジェクトを含む組織へのOrganization Owner
アクセス権が必要です。
監査ログの有効化
注意
一時データベース ユーザーのアクションを監査するためのベスト プラクティスについては、「 一時データベースユーザーの監査 」を参照してください。
spec.auditing.enabled
監査ログを有効にするには、true
AtlasProject
カスタム リソース で を に設定します。
例:
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
クラスターでは使用できません。詳細については、Atlas M0(無料クラスター)の制限 を参照してください。この機能は現時点では、サーバーレスインスタンスではサポートされていません。 詳細については、「サーバーレス インスタンスの制限 」を参照してください。
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監査 」を参照してください。