データベース監査ログ

TiDB Cloudは、ユーザー アクセスの詳細 (実行された SQL ステートメントなど) の履歴をログに記録するデータベース監査ログ機能を提供します。

注記：

現在、データベース監査ログ機能はリクエストがあった場合にのみ利用可能です。この機能をリクエストするには、 「?」をクリックしてください。 TiDB Cloudコンソールの右下隅にある[サポートをリクエスト]をクリックします。次に、「説明」フィールドに「データベース監査ログの適用」と入力し、 「送信」をクリックします。

組織のユーザー アクセス ポリシーやその他の情報セキュリティ対策の有効性を評価するには、データベース監査ログの定期的な分析を実行することがセキュリティのベスト プラクティスです。

監査ログ機能はデフォルトでは無効になっています。クラスターを監査するには、まず監査ログを有効にしてから、監査フィルター ルールを指定する必要があります。

注記：

監査ログはクラスターのリソースを消費するため、クラスターを監査するかどうかは慎重に検討してください。

前提条件

• TiDB 専用クラスターを使用しています。監査ログは、TiDB サーバーレス クラスターでは使用できません。
• あなたは組織内でOrganization OwnerまたはProject Owner役割を担っています。そうしないと、 TiDB Cloudコンソールにデータベース監査関連のオプションが表示されません。詳細については、 ユーザーの役割を参照してください。

AWS または Google Cloud の監査ログを有効にする

TiDB Cloud がクラウド バケットに監査ログを書き込めるようにするには、まず監査ログを有効にする必要があります。

AWS の監査ログを有効にする

AWS の監査ログを有効にするには、次の手順を実行します。

ステップ 1. Amazon S3 バケットを作成する

TiDB Cloud が監査ログを書き込む宛先として、企業所有の AWS アカウントの Amazon S3 バケットを指定します。

詳細については、AWS ユーザーガイドのバケットの作成を参照してください。

ステップ 2. Amazon S3 アクセスを構成する

注記：

プロジェクト内の 1 つのクラスターに対して Amazon S3 アクセス設定を実行すると、同じプロジェクト内のすべてのクラスターからの監査ログの宛先として同じバケットを使用できます。

1. TiDB Cloudアカウント ID と、監査ログを有効にする TiDB クラスターの外部 ID を取得します。

   1. TiDB Cloudコンソールで、AWS にデプロイされたプロジェクトとクラスターを選択します。
   2. [設定] > [監査設定]を選択します。 「監査ログ」ダイアログが表示されます。
   3. [監査ログ]ダイアログで、 [AWS IAMポリシー設定を表示]をクリックします。対応する TiDB クラスターのTiDB Cloudアカウント ID とTiDB Cloud外部 ID が表示されます。
   4. 後で使用できるように、 TiDB Cloudアカウント ID と外部 ID を記録します。

2. AWS マネジメントコンソールで、 [IAM] > [アクセス管理] > [**ポリシー]**に移動し、 s3:PutObject書き込み専用アクセス許可を持つstorageバケット ポリシーがあるかどうかを確認します。

   • 「はい」の場合、後で使用できるように、一致したstorageバケット ポリシーを記録します。

   • そうでない場合は、 [IAM] > [アクセス管理] > [ポリシー] > [ポリシーの作成]に移動し、次のポリシー テンプレートに従ってバケット ポリシーを定義します。

     {
         "Version": "2012-10-17",
         "Statement": [
             {
                 "Effect": "Allow",
                 "Action": "s3:PutObject",
                 "Resource": "<Your S3 bucket ARN>/*"
             }
         ]
     }
     

     テンプレートの<Your S3 bucket ARN>は、監査ログ ファイルが書き込まれる S3 バケットの Amazon リソースネーム (ARN) です。 S3 バケットの[プロパティ]タブに移動し、 [バケットの概要]領域で ARN 値を取得できます。 "Resource"フィールドでは、ARN の後に/*を追加する必要があります。たとえば、ARN がarn:aws:s3:::tidb-cloud-testの場合、 "Resource"フィールドの値を"arn:aws:s3:::tidb-cloud-test/*"として構成する必要があります。

3. [IAM] > [アクセス管理] > [ロール]に移動し、前に記録したTiDB Cloudアカウント ID と外部 ID に対応する信頼エンティティを持つロールが既に存在するかどうかを確認します。

   • 「はい」の場合、後で使用できるように、一致した役割を記録します。
   • そうでない場合は、 [ロールの作成]をクリックし、信頼エンティティ タイプとして[別の AWS アカウント]を選択し、 TiDB Cloudアカウント ID 値を[アカウント ID]フィールドに入力します。次に、 「外部 ID が必要」オプションを選択し、 TiDB Cloud外部 ID 値を「外部 ID」フィールドに入力します。

4. [IAM] > [アクセス管理] > [ロール]で、前の手順のロール名をクリックして[概要]ページに移動し、次の手順を実行します。

   1. [**権限]タブで、 s3:PutObject書き込み専用権限を持つ記録されたポリシーがロールにアタッチされているかどうかを確認します。そうでない場合は、 [Attach Policies]を選択し、必要なポリシーを検索して、 [Attach Policy]**をクリックします。
   2. [概要]ページに戻り、ロール ARN値をクリップボードにコピーします。

ステップ 3. 監査ログを有効にする

TiDB Cloudコンソールで、 TiDB Cloudアカウント ID と外部 ID 値を取得した[監査ログ]ダイアログ ボックスに戻り、次の手順を実行します。

1. 「バケット URI」フィールドに、監査ログ ファイルが書き込まれる S3 バケットの URI を入力します。

2. [バケットリージョン]ドロップダウン リストで、バケットが配置されている AWS リージョンを選択します。

3. [ロール ARN]フィールドに、 ステップ 2. Amazon S3 アクセスを構成するでコピーしたロール ARN 値を入力します。

4. [接続のテスト]をクリックして、 TiDB Cloudがバケットにアクセスしてバケットに書き込むことができるかどうかを確認します。

   成功すると「Pass」と表示されます。それ以外の場合は、アクセス構成を確認してください。

5. 右上隅で、監査設定を[オン]に切り替えます。

   TiDB Cloudは、指定されたクラスターの監査ログを Amazon S3 バケットに書き込む準備ができています。

注記：

• 監査ログを有効にした後、バケット URI、場所、または ARN に新しい変更を加えた場合は、[**再起動]をクリックして変更をロードし、テスト接続**チェックを再実行して変更を有効にする必要があります。
• TiDB Cloudから Amazon S3 アクセスを削除するには、追加した信頼ポリシーを削除するだけです。

Google Cloud の監査ロギングを有効にする

Google Cloud の監査ロギングを有効にするには、次の手順を実行します。

ステップ 1. GCS バケットを作成する

TiDB Cloud が監査ログを書き込む宛先として、企業所有の Google Cloud アカウント内の Google Cloud Storage (GCS) バケットを指定します。

詳細については、Google Cloud Storage ドキュメントのstorageバケットの作成を参照してください。

ステップ 2. GCS アクセスを構成する

注記：

プロジェクト内の 1 つのクラスターに対して GCS アクセス構成を実行すると、同じプロジェクト内のすべてのクラスターからの監査ログの宛先として同じバケットを使用できます。

1. 監査ログを有効にする TiDB クラスターの Google Cloud サービス アカウント ID を取得します。

   1. TiDB Cloudコンソールで、Google Cloud Platform にデプロイされたプロジェクトとクラスターを選択します。
   2. [設定] > [監査設定]を選択します。 「監査ログ」ダイアログ・ボックスが表示されます。
   3. [Google Cloud サービス アカウント ID を表示]をクリックし、後で使用するためにサービス アカウント ID をコピーします。

2. Google Cloud コンソールで、 [IAMと管理] > [ロール]に移動し、storageコンテナの次の書き込み専用権限を持つロールが存在するかどうかを確認します。

   • storage.objects.create
   • storage.オブジェクト.削除

   「はい」の場合は、後で使用できるように、TiDB クラスターの一致したロールを記録します。そうでない場合は、 [IAMと管理] > [ロール] > [ロールの作成]に移動して、TiDB クラスターのロールを定義します。

3. [Cloud Storage] > [Browser]に移動し、 TiDB Cloudがアクセスする GCS バケットを選択して、 [SHOW INFO PANEL]をクリックします。

   パネルが表示されます。

4. パネルで、 「プリンシパルの追加」をクリックします。

   プリンシパルを追加するためのダイアログ ボックスが表示されます。

5. ダイアログ ボックスで、次の手順を実行します。

   1. [新しいプリンシパル]フィールドに、TiDB クラスターの Google Cloud サービス アカウント ID を貼り付けます。
   2. [役割] ドロップダウン リストで、ターゲット TiDB クラスターの役割を選択します。
   3. 「保存」をクリックします。

ステップ 3. 監査ログを有効にする

TiDB Cloudコンソールで、 TiDB Cloudアカウント ID を取得した[監査ログ] ダイアログ ボックスに戻り、次の手順を実行します。

1. [バケット URI]フィールドに、完全な GCS バケット名を入力します。

2. [バケットリージョン]フィールドで、バケットが配置されている GCS リージョンを選択します。

3. [接続のテスト]をクリックして、 TiDB Cloudがバケットにアクセスしてバケットに書き込むことができるかどうかを確認します。

   成功すると「Pass」と表示されます。それ以外の場合は、アクセス構成を確認してください。

4. 右上隅で、監査設定を[オン]に切り替えます。

   TiDB Cloudは、指定されたクラスターの監査ログを Amazon S3 バケットに書き込む準備ができています。

注記：

• 監査ログを有効にした後、バケット URI または場所に新しい変更を加えた場合は、 「再起動」をクリックして変更をロードし、テスト接続チェックを再実行して変更を有効にする必要があります。
• TiDB Cloudから GCS アクセスを削除するには、追加したプリンシパルを削除するだけです。

監査フィルタルールの指定

監査ログを有効にした後、監査フィルタ ルールを指定して、どのユーザー アクセス イベントをキャプチャして監査ログに書き込むか、どのイベントを無視するかを制御する必要があります。フィルター ルールが指定されていない場合、 TiDB Cloudは何も記録しません。

クラスターの監査フィルター ルールを指定するには、次の手順を実行します。

1. 監査ログを有効にする[監査ログ] ダイアログ ボックスで、下にスクロールして[フィルタ ルール]セクションを見つけます。
2. 1 つ以上のフィルター ルールを行ごとに 1 つずつ追加し、各ルールでユーザー式、データベース式、テーブル式、およびアクセス タイプを指定します。

注記：

• フィルター ルールは正規表現であり、大文字と小文字が区別されます。ワイルドカード ルール.*を使用すると、クラスター内のすべてのユーザー、データベース、またはテーブル イベントがログに記録されます。
• 監査ログはクラスター リソースを消費するため、フィルター ルールを指定するときは慎重にしてください。消費量を最小限に抑えるために、可能な場合は、フィルタ ルールを指定して、監査ログの範囲を特定のデータベース オブジェクト、ユーザー、およびアクションに制限することをお勧めします。

監査ログをビュー

TiDB Cloud監査ログは、クラスター ID、ポッド ID、およびログ作成日が完全修飾ファイル名に組み込まれた読み取り可能なテキスト ファイルです。

たとえば、 13796619446086334065/tidb-0/tidb-audit-2022-04-21T18-16-29.529.log 。この例では、 13796619446086334065クラスター ID を示し、 tidb-0はポッド ID を示します。

監査ログを無効にする

クラスターを監査したくない場合は、クラスターのページに移動し、 [設定] > [監査設定]をクリックし、右上隅にある監査設定を [**オフ]**に切り替えます。

注記：

ログ ファイルのサイズが 10 MiB に達するたびに、ログ ファイルはクラウドstorageバケットにプッシュされます。したがって、監査ログが無効になった後は、サイズが 10 MiB 未満のログ ファイルはクラウドstorageバケットに自動的にプッシュされません。この状況でログ ファイルを取得するには、 PingCAPのサポートにお問い合わせください。

監査ログフィールド

監査ログ内のデータベース イベント レコードごとに、TiDB は次のフィールドを提供します。

注記：

次の表で、フィールドの空の最大長は、このフィールドのデータ型が明確に定義された定数 (たとえば、INTEGER の場合は 4 バイト) であることを意味します。

TiDB によって設定された EVENT_CLASS フィールド値に応じて、監査ログ内のデータベース イベント レコードには次のような追加フィールドも含まれます。

• EVENT_CLASS 値がCONNECTIONの場合、データベース イベント レコードには次のフィールドも含まれます。

  列番号	フィールド名	TiDB データ型	最大長さ	説明
  17	CLIENT_PORT	整数		クライアントのポート番号
  18	接続_ID	整数		接続ID
  19	接続タイプ	VARCHAR	12	socketまたはunix-socketによる接続
  20	サーバーID	整数		TiDBサーバーID
  21	サーバポート	整数		TiDBサーバーがMySQL プロトコル経由のクライアント通信をリッスンするために使用するポート
  22	SERVER_OS_LOGIN_USER	VARCHAR	17	TiDB プロセス起動システムのユーザー名
  23	OS_VERSION	VARCHAR	該当なし	TiDBサーバーが配置されているオペレーティング システムのバージョン
  24	SSL_VERSION	VARCHAR	6	TiDB の現在の SSL バージョン
  25	PID	整数		TiDB プロセスの PID

• EVENT_CLASS 値がTABLE_ACCESSまたはGENERALの場合、データベース イベント レコードには次のフィールドも含まれます。

  列番号	フィールド名	TiDB データ型	最大長さ	説明
  17	接続_ID	整数		接続ID
  18	指示	VARCHAR	14	MySQLプロトコルのコマンドタイプ
  19	SQL_STATEMENT	VARCHAR	17	SQL ステートメントのタイプ
  20	PID	整数		TiDB プロセスの PID