MySQL データベースの監査

このトピックでは、Cloud SQL for MySQL データベースの監査と Cloud SQL for MySQL 監査プラグインについて説明します。データベース監査をすぐに使用するには、MySQL データベースの監査を使用するをご覧ください。

データベース監査とは

データベース監査を使用すると、テーブルの更新、読み取りクエリ、ユーザー権限の付与など、データベース内の特定のユーザー アクションを追跡できます。データベース監査は、セキュリティ上の理由や、さまざまな金融、政府、ISO の規制遵守のために、ユーザー アクティビティの追跡が必要になる組織に役立ちます。データベース監査は、Cloud SQL for MySQL 5.7 と 8.0 でサポートされています。

Cloud SQL for MySQL 監査プラグイン

データベース監査は、Cloud SQL for MySQL 監査プラグインまたは cloudsql_mysql_audit で有効にします。このプラグインは、オープンな MySQL 監査 API を使用して MySQL のアクティビティをモニタリングし、ログに記録します。また、Cloud Logging データアクセス監査ログにログを送信します。データアクセス監査ログは非常に大きくなる可能性があるため、デフォルトでは無効になっています。プラグインを使用するには、明示的にログを有効にする必要があります。

プラグインがアクティブになると、既存の監査ルールが適用され、データベースの監査ログが生成されます。プラグインを無効にすると、監査ログは生成されません。

MySQL プラグインの詳細については、MySQL サーバー プラグインをご覧ください。

データベース監査を使用するユーザー

データベース監査に関わるユーザーは 3 種類あります。

  • 管理者 - データベースを管理するユーザー。管理者は、インスタンスの監査の有効化と無効化、新しいユーザーの作成を行う監査ユーザーです。また、監査者に監査権限を付与することもできます。管理者は、監査ルールの作成、削除、更新も行うことができます。
  • 監査者 - 監査ルールの作成、削除、更新権限を持つユーザー。管理者からアクセス権を付与されます。
  • クライアント - 監査ルールによってアクティビティが監査されるユーザー。監査を実施するユーザーではなく、管理者権限や監査権限はありません。アクセス権は管理者によって管理されます。

管理者と監査者は監査ユーザーともいいます。

監査ルール

データベース監査では、監査ルールを使用して、監査ログの作成をトリガーするユーザー、データベース、オブジェクト、オペレーション、ステータスの組み合わせを定義します。監査ルールには次の情報が含まれます。

  • ID - オートナンバーのルール ID。各監査ルールには、ルールの作成時に自動的に割り当てられる監査 ID があります。作成された監査 ID は変更できません。
  • ユーザー名 - ユーザーの名前またはワイルドカード パターンのカンマ区切りのリスト。ユーザーとホストの両方でワイルドカードとしてアスタリスク（*）を使用できます。アスタリスクをサフィックス、プレフィックス、またはその両方で使用します。また、ワイルドカード文字 % はホストにのみ使用できます。最大文字数は 2,048 文字です。
  • DB 名 - データベースの名前またはワイルドカード パターンのカンマ区切りのリスト。ユーザーとホストの両方でワイルドカードとしてアスタリスク（*）を使用できます。アスタリスクをサフィックス、プレフィックス、またはその両方で使用します。最大 2,048 文字です。
  • オブジェクト: データベース オブジェクト（テーブル、関数、ストアド プロシージャなど）の名前またはワイルドカード パターンのカンマ区切りリスト。ユーザーとホストの両方でワイルドカードとしてアスタリスク（*）を使用できます。アスタリスクをサフィックス、プレフィックス、またはその両方で使用します。最大 2,048 文字です。
  • オペレーション - データベース オペレーションのカンマ区切りのリスト。プラグインは、すべてのオペレーションに対して、グループ オペレーション（DDL、DML など）、単一オペレーション（更新、削除など）、ワイルドカード（*）をサポートしています。サポートされているオペレーションの一覧をご覧ください。プラグインは、オペレーション グループの監査に使用できるオペレーション グループもサポートしています。最大 2,048 文字です。

  • Op_result - オペレーションの結果。

    • S（成功したオペレーションを監査する場合）
    • U（失敗したオペレーションを監査する場合）
    • B（成功したオペレーションと失敗したオペレーションの両方を追跡する場合）
    • E（排他ルールを作成する場合）

オペレーション タイプ

オペレーション タイプは、データベースで監査可能な複数のアクティビティまたはオペレーションのタイプです。

  • DQL - データベースからのデータの読み取り（つまり、SELECT ステートメント）
  • DML - データの追加、削除、変更
  • DDL - データベース内のデータベース オブジェクト構造の作成または変更
  • DCL - データベース内のユーザーの権限の管理
  • Show - データベースのオブジェクト情報またはステータスの取得
  • Call - ストアド プロシージャの呼び出し

監査ロギングに影響する考慮事項

バックアップ

バックアップまたはポイントインタイム リカバリ（PITR）からインスタンスを復元すると、監査ルールもバックアップまたは PITR 時にロールバックされます。これは、監査ルールがデータベースに保存されているデータの一部であり、ルールが監査対象（ユーザーとオブジェクト）に存在するためです。

リードレプリカ

監査ルールは、プライマリ インスタンスからリードレプリカに自動的に複製されます。リードレプリカの監査ルールを追加、削除、変更することはできません。レプリカの監査ルールを変更する場合は、プライマリ インスタンスの監査ルールを更新する必要があります。

プライマリ インスタンスの監査ログルールを更新した場合は、レプリカで新しい監査ルールを再度読み込み、リードレプリカでも新しい監査ルールが更新されるようにする必要があります。次のコマンドは、監査ルールを再度読み込みます。

CALL mysql.cloudsql_reload_audit_rule(1)

レプリカの監査ログは、プライマリ インスタンスとは別に有効にできます。プライマリ インスタンスを変更した後、監査ログルールを有効にするには、reload コマンドを実行するか、レプリカ インスタンスを再起動する必要があります。

監査ログの障害発生時のデータベースの可用性

監査オペレーションが失敗しても、Cloud SQL はデータベース アクティビティを停止しません。たとえば、インスタンスのディスク容量が不足し、Cloud SQL で監査ログを生成できない場合、このアクティビティで監査ログが生成されても、ユーザーはデータベースに対して読み取りクエリを実行できます。

読み取り専用インスタンス

インスタンスに read_only フラグが true に設定されている場合、監査ルールがテーブルに保存されているため、監査ルールを追加または更新できません。ルールの作成、更新、削除を行うには、read_only フラグを削除する必要があります。

制限事項と既知の問題

バイナリログを適用する

Cloud SQL for MySQL 監査プラグインは、インスタンスのバイナリログと互換性がありません。

Cloud SQL for MySQL 監査プラグインが有効になっているときにバイナリログを適用しようとすると、データベース インスタンスがクラッシュする場合があります。

mysqlbinlog ユーティリティを使用してバイナリログを適用するには、まず cloudsql_mysql_audit=OFF を設定してデータベース監査を無効にする必要があります。

ログの取り込み率

Cloud SQL が監査ログを Cloud Logging に送信する前に、監査ログはインスタンスのディスクに一時的に書き込まれます（インスタンスのディスク容量が使用されます）。ログは Cloud Logging にアップロードされ、毎秒 4 MB のレートでディスクから削除されます。ログ生成の負荷がアップロード速度を超えると、インスタンスのディスク使用量が増加します。これにより、データベースのディスクが不足し、クラッシュする可能性があります。ディスク ストレージの自動増量が有効になっていても、ディスク使用量の増加には料金が発生します。

この機能を使用する場合は、次のことをおすすめします。

  • ストレージの自動増量を有効にする。
  • 全体的なディスク使用量をモニタリングする。ログ生成の負荷を個別にモニタリングすることはできません。Metrics Explorer で cloudsql.googleapis.com/database/disk/utilization 指標を使用します。
  • 必要に応じて、データベース アクティビティを制限するか、監査を減らすことで、ログの生成レートを下げる。

失敗したオペレーションの監査

失敗したオペレーションの監査が監査ルールに含まれている場合（失敗したオペレーションの場合、op_result が U に設定され、成功と失敗の両方のオペレーションの場合は B に設定されます）、一部のユーザーが失敗したオペレーションを継続的に実行すると、監査ログによりデータベース インスタンスが過負荷状態になる可能性があります。ログの生成速度がログの取り込み速度を超えると、ディスク使用量が不要に増加し、容量不足になる可能性があります。失敗したオペレーションを監査する場合は、次のことを行います。

  • インスタンス レベルでアクセスを制御する。
  • オペレーション ログの異常な増加を検知できるように、モニタリング システムまたはアラート システムを設定する。

監査ルール

1 つのデータベース インスタンスに作成可能な監査ルールの組み合わせは、合計 1,000 個までです。監査ルールの組み合わせは、ユーザー、データベース、オブジェクト、オペレーションの一意のセットです。たとえば、user1,user2、db1,db2、table1,table2、select,delete を監査する監査ルールでは、2 x 2 x 2 x 2 = 16 の組み合わせが生成されます。監査ルールの組み合わせの数が 1,000 を超えると、監査ルールの作成または更新が失敗します。

サポートされていないオペレーション

現在、次のオペレーションはサポートされていません。

  • 説明どおりに使用した場合、次の関数はサポートされません。

    • UNION、INTERSECT、WHERE 句、ネストされたクエリ、サブクエリなどを使用した SELECT クエリ。
    • UPDATE、DELETE、INSERT、REPLACE ステートメント。

    たとえば、オブジェクト func1 を監査する監査ルールがある場合、次のものは監査されません。

    • SELECT func1() FROM table;
    • SELECT * FROM table WHERE a = func1();
    • SELECT func1() != 0;
    • SELECT func1() > 0;
    • SET @x = func1();

    SELECT によって呼び出され、演算子なしで WHERE 句がない関数は監査されます。

    • SELECT func1();
    • SELECT db.func1();

  • 現時点では、IP アドレスによるフィルタリングはサポートされていません。

次のステップ