データベース監査ログ

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 アカウント」を選択して、「アカウント ID」フィールドにTiDB Cloudアカウント ID の値を入力します。次に、「外部 ID が必要」オプションを選択し、 「外部 ID」フィールドにTiDB Cloud外部 ID の値を入力します。
  4. IAM >アクセス管理>ロールで、前の手順のロール名をクリックして概要ページに移動し、次の手順を実行します。

    1. 権限」タブで、書き込み専用権限s3:PutObjectを持つ記録されたポリシーがロールにアタッチされているかどうかを確認します。アタッチされていない場合は、 「ポリシーのアタッチ」を選択し、必要なポリシーを検索して、 「ポリシーのアタッチ」をクリックします。
    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 Server アカウント ID を表示]をクリックし、後で使用するためにサービス アカウント ID をコピーします。
  2. Google Cloud コンソールで、 [IAMと管理] > [ロール] に移動し、storageコンテナの次の書き込み専用権限を持つロールが存在するかどうかを確認します。

    • storage.オブジェクト.作成
    • storage.オブジェクト.削除

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

  3. [Cloud Storage] > [**ブラウザ]に移動し、 TiDB Cloudがアクセスする GCS バケットを選択して、 [情報パネルを表示]**をクリックします。

    パネルが表示されます。

  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 行につき 1 つのルール)。各ルールでは、ユーザー式、データベース式、テーブル式、およびアクセス タイプを指定します。

注記:

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

監査ログをビュー

TiDB Cloud監査ログは、クラスター ID、Pod 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 データ型最大長説明
1該当なし該当なし該当なし内部使用のために予約済み
2該当なし該当なし該当なし内部使用のために予約済み
3該当なし該当なし該当なし内部使用のために予約済み
4ID整数一意のイベントID
5タイムスタンプタイムスタンプイベント開催時間
6イベントクラスバルチャー15イベントタイプ
7イベントサブクラスバルチャー15イベントのサブタイプ
8ステータスコード整数声明の回答状況
9コスト_時間フロート声明に費やされた時間
10ホストバルチャー16サーバーIP
11クライアントIPバルチャー16クライアントIP
12ユーザーバルチャー17ログインユーザー名
13データベースバルチャー64イベント関連データベース
14テーブルバルチャー64イベント関連テーブル名
15SQL_TEXTバルチャー64KBマスクされたSQL文
16整数影響を受ける行の数( 0影響を受ける行がないことを示します)

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

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

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

    列番号フィールド名TiDB データ型最大長説明
    17接続ID整数接続ID
    18指示バルチャー14MySQLプロトコルのコマンドタイプ
    19SQL_ステートメントバルチャー17SQL文の種類
    20ピッド整数TiDBプロセスのPID

このページは役に立ちましたか?

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Dedicated
TiDB Serverless
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.