これはアーカイブされた TiDB のドキュメントであり、更新は行われていません。最新の LTS バージョンのドキュメントを表示する

データベース監査ログ

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

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

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

ノート:

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

前提条件

  • TiDB Cloud Dedicated Tier クラスターを使用しています。監査ログは、 TiDB Cloud Tier クラスターでは使用できません。
  • あなたはTiDB Cloudの組織の監査管理者です。そうしないと、 TiDB Cloudコンソールに監査関連のオプションが表示されません。詳細については、 メンバーの役割を構成するを参照してください。

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

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

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

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

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

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

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

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

ノート:

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

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

    1. TiDB Cloudコンソールで、AWS にデプロイされたプロジェクトとクラスターを選択します。
    2. [**設定]** > [監査設定]を選択します。 [監査ログ] ダイアログが表示されます。
    3. [監査ログ] ダイアログで、[ AWS IAMポリシー設定を表示] をクリックします。対応するTiDB Cloudアカウント ID と TiDB クラスターのTiDB Cloud外部 ID が表示されます。
    4. 後で使用するために、 TiDB Cloudアカウント ID と外部 ID を記録します。
  2. AWS マネジメント コンソールで、[ **IAM]** > [アクセス管理] > [ポリシー] に移動し、 s3:PutObject書き込み専用権限を持つストレージ バケット ポリシーがあるかどうかを確認します。

    • はいの場合は、後で使用するために、一致したストレージ バケット ポリシーを記録します。

    • そうでない場合は、[ **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 > Access Management > Rolesに移動し、以前に記録したTiDB Cloudアカウント ID と外部 ID に対応する信頼エンティティを持つロールが既に存在するかどうかを確認します。

    • はいの場合は、後で使用するために一致した役割を記録します。
    • そうでない場合は、[ロールの作成] をクリックし、信頼エンティティ タイプとして [別の AWS アカウント] を選択し、 TiDB Cloudアカウント ID の値を [アカウント ID]フィールドに入力します。次に、[外部 IDが必要] オプションを選択し、 TiDB Cloudの外部 ID 値を [外部 ID ] フィールドに入力します。
  4. [ IAM ] > [ Access Management ] > [ Roles ] で、前の手順のロール名をクリックして[概要] ページに移動し、次の手順を実行します。

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

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

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

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

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

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

  4. [ Test Connectivity ] をクリックして、 TiDB Cloudがバケットにアクセスして書き込みできるかどうかを確認します。

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

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

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

ノート:

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

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

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

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

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

詳細については、Google Cloud 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 Platform (GCP) 管理コンソールで、[ IAM & Admin ] > [ Roles ] に移動し、ストレージ コンテナーの次の書き込み専用権限を持つロールが存在するかどうかを確認します。

    • storage.objects.create
    • storage.objects.delete

    はいの場合は、後で使用するために、TiDB クラスターの一致した役割を記録します。そうでない場合は、[ IAM & Admin ] > [ Roles ] > [ CREATE ROLE ] に移動して、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. [ **Bucket リージョン ]**フィールドで、バケットが配置されている GCS リージョンを選択します。

  3. [ Test Connectivity ] をクリックして、 TiDB Cloudがバケットにアクセスして書き込みできるかどうかを確認します。

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

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

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

ノート:

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

監査フィルター規則を指定する

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

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

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

ノート:

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

監査ログをビューする

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

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

監査ログを無効にする

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

ノート:

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

監査ログ フィールド

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

ノート:

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

列番号フィールド名TiDB データ型最大長説明
1なしなしなし内部使用のために予約済み
2なしなしなし内部使用のために予約済み
3なしなしなし内部使用のために予約済み
4ID整数一意のイベント ID
5タイムスタンプタイムスタンプ開催時間
6EVENT_CLASSVARCHAR15イベントタイプ
7EVENT_SUBCLASSVARCHAR15イベントのサブタイプ
8STATUS_CODE整数ステートメントの応答ステータス
9COST_TIME整数ステートメントに費やされた時間
10ホストVARCHAR16サーバー IP
11CLIENT_IPVARCHAR16クライアント IP
12ユーザーVARCHAR17ログインユーザー名
13データベースVARCHAR64イベント関連データベース
14テーブルVARCHAR64イベント関連テーブル名
15SQL_TEXTVARCHAR64キロバイトマスクされた SQL ステートメント
16整数影響を受ける行の数 ( 0は影響を受ける行がないことを示します)

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

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

    列番号フィールド名TiDB データ型最大長説明
    17CLIENT_PORT整数クライアントのポート番号
    18CONNECTION_ID整数接続 ID
    19接続タイプVARCHAR12socketまたはunix-socket経由の接続
    20サーバー_ID整数TiDBサーバーID
    21サーバポート整数TiDBサーバーが MySQL プロトコルを介して通信するクライアントをリッスンするために使用するポート
    22サーバーOSログイン_ユーザーVARCHAR17TiDB プロセス起動システムのユーザー名
    23OS_VERSIONVARCHARなしTiDBサーバーが配置されているオペレーティング システムのバージョン
    24SSL_バージョンVARCHAR6TiDB の現在の SSL バージョン
    25PID整数TiDB プロセスの PID
  • EVENT_CLASS 値がTABLE_ACCESSまたはGENERALの場合、データベース イベント レコードには次のフィールドも含まれます。

    列番号フィールド名TiDB データ型最大長説明
    17CONNECTION_ID整数接続 ID
    18指図VARCHAR14MySQL プロトコルのコマンド タイプ
    19SQL_STATEMENTVARCHAR17SQL ステートメントのタイプ
    20PID整数TiDB プロセスの PID