データベース監査ログ
TiDB Cloud は、ユーザー アクセスの詳細 (実行された SQL ステートメントなど) の履歴をログに記録するデータベース監査ログ機能を提供します。
注記：
現在、データベース監査ログ機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、 TiDB Cloudコンソールの右下隅にある[?]をクリックし、 [サポートのリクエスト] をクリックします。次に、 [説明]フィールドに「データベース監査ログの申請」と入力し、 [送信]をクリックします。
組織のユーザー アクセス ポリシーやその他の情報セキュリティ対策の有効性を評価するには、データベース監査ログを定期的に分析することがセキュリティのベスト プラクティスです。
監査ログ機能はデフォルトで無効になっています。クラスターを監査するには、まず監査ログを有効にしてから、監査フィルター ルールを指定する必要があります。
注記：
監査ログはクラスターのリソースを消費するため、クラスターを監査するかどうかは慎重に検討してください。
前提条件
- TiDB Cloud Dedicated クラスターを使用しています。監査ログはTiDB Cloud Serverless クラスターでは利用できません。
- 組織内で
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 アクセス構成を実行すると、同じプロジェクト内のすべてのクラスターからの監査ログの保存先として同じバケットを使用できるようになります。
監査ログを有効にするTiDB Cloudアカウント ID と TiDB クラスターの外部 ID を取得します。
- TiDB Cloudコンソールで、AWS にデプロイされたプロジェクトとクラスターを選択します。
- [設定] > [監査設定]を選択します。 [監査ログ]ダイアログが表示されます。
- 監査ログダイアログで、 「AWS IAMポリシー設定を表示」をクリックします。TiDB クラスターの対応するTiDB Cloudアカウント ID とTiDB Cloud外部 ID が表示されます。
- 後で使用するために、 TiDB Cloudアカウント ID と外部 ID を記録します。
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/*"に設定する必要があります。
「IAM」 > 「アクセス管理」 > 「ロール」に移動し、信頼エンティティが先ほど記録したTiDB Cloudアカウント ID と外部 ID に対応するロールが既に存在するかどうかを確認します。
- はいの場合は、後で使用するために一致したロールを記録します。
- そうでない場合は、 「ロールの作成」をクリックし、信頼エンティティタイプとして「別の AWS アカウント」を選択して、「アカウント ID」フィールドにTiDB Cloudアカウント ID の値を入力します。次に、「外部 ID が必要」オプションを選択し、 「外部 ID」フィールドにTiDB Cloud外部 ID の値を入力します。
IAM >アクセス管理>ロールで、前の手順のロール名をクリックして概要ページに移動し、次の手順を実行します。
- 「権限」タブで、書き込み専用権限
s3:PutObjectを持つ記録されたポリシーがロールにアタッチされているかどうかを確認します。アタッチされていない場合は、 「ポリシーのアタッチ」を選択し、必要なポリシーを検索して、 「ポリシーのアタッチ」をクリックします。 - 概要ページに戻り、ロール ARN値をクリップボードにコピーします。
- 「権限」タブで、書き込み専用権限
ステップ3. 監査ログを有効にする
TiDB Cloudコンソールで、 TiDB Cloudアカウント ID と外部 ID 値を取得した監査ログダイアログ ボックスに戻り、次の手順を実行します。
「バケット URI」フィールドに、監査ログファイルが書き込まれる S3 バケットの URI を入力します。
「バケットリージョン」ドロップダウンリストで、バケットが配置されている AWS リージョンを選択します。
「ロール ARN」フィールドに、 ステップ2. Amazon S3アクセスを構成するでコピーしたロール ARN 値を入力します。
「接続のテスト」をクリックして、 TiDB Cloud がバケットにアクセスして書き込むことができるかどうかを確認します。
成功した場合は、 「Pass」と表示されます。それ以外の場合は、アクセス構成を確認してください。
右上隅で、監査設定をオンに切り替えます。
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 アクセス構成を実行すると、同じプロジェクト内のすべてのクラスタからの監査ログの保存先として同じバケットを使用できるようになります。
監査ログを有効にする TiDB クラスタの Google Cloud サービス アカウント ID を取得します。
- TiDB Cloudコンソールで、Google Cloud Platform にデプロイされたプロジェクトとクラスタを選択します。
- [設定] > [監査設定]を選択します。 [監査ログ]ダイアログ ボックスが表示されます。
- [Google Cloud Server アカウント ID を表示]をクリックし、後で使用するためにサービス アカウント ID をコピーします。
Google Cloud コンソールで、 [IAMと管理] > [ロール] に移動し、storageコンテナの次の書き込み専用権限を持つロールが存在するかどうかを確認します。
- storage.オブジェクト.作成
- storage.オブジェクト.削除
はいの場合は、後で使用するために TiDB クラスターの一致したロールを記録します。いいえの場合は、 [IAMと管理] > [ロール] > [ロールの作成] に移動して、TiDB クラスターのロールを定義します。
[Cloud Storage] > [**ブラウザ]に移動し、 TiDB Cloudがアクセスする GCS バケットを選択して、 [情報パネルを表示]**をクリックします。
パネルが表示されます。
パネルで、 「プリンシパルの追加」をクリックします。
プリンシパルを追加するためのダイアログ ボックスが表示されます。
ダイアログ ボックスで、次の手順を実行します。
- [新しいプリンシパル]フィールドに、TiDB クラスタの Google Cloud サービス アカウント ID を貼り付けます。
- [ロール]ドロップダウン リストで、ターゲット TiDB クラスターのロールを選択します。
- [保存]をクリックします。
ステップ3. 監査ログを有効にする
TiDB Cloudコンソールで、 TiDB Cloudアカウント ID を取得した監査ログダイアログ ボックスに戻り、次の手順を実行します。
「バケット URI」フィールドに、完全な GCS バケット名を入力します。
「バケットリージョン」フィールドで、バケットが配置されている GCS リージョンを選択します。
「接続のテスト」をクリックして、 TiDB Cloud がバケットにアクセスして書き込むことができるかどうかを確認します。
成功した場合は、 「Pass」と表示されます。それ以外の場合は、アクセス構成を確認してください。
右上隅で、監査設定をオンに切り替えます。
TiDB Cloud は、指定されたクラスターの監査ログを Amazon S3 バケットに書き込む準備ができました。
注記：
- 監査ログを有効にした後、バケットの URI または場所に新しい変更を加えた場合は、 [再起動]をクリックして変更を読み込み、接続テストチェックを再実行して変更を有効にする必要があります。
- TiDB Cloudから GCS アクセスを削除するには、追加したプリンシパルを削除するだけです。
監査フィルタルールを指定する
監査ログを有効にした後、監査フィルタ ルールを指定して、どのユーザー アクセス イベントをキャプチャして監査ログに書き込むか、どのイベントを無視するかを制御する必要があります。フィルタ ルールが指定されていない場合、 TiDB Cloud は何もログに記録しません。
クラスターの監査フィルター ルールを指定するには、次の手順を実行します。
- 監査ログを有効にする「監査ログ」ダイアログ ボックスで、下にスクロールして「フィルター ルール」セクションを見つけます。
- 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 | 該当なし | 該当なし | 該当なし | 内部使用のために予約済み |
| 4 | ID | 整数 | 一意のイベントID | |
| 5 | タイムスタンプ | タイムスタンプ | イベント開催時間 | |
| 6 | イベントクラス | バルチャー | 15 | イベントタイプ |
| 7 | イベントサブクラス | バルチャー | 15 | イベントのサブタイプ |
| 8 | ステータスコード | 整数 | 声明の回答状況 | |
| 9 | コスト_時間 | フロート | 声明に費やされた時間 | |
| 10 | ホスト | バルチャー | 16 | サーバーIP |
| 11 | クライアントIP | バルチャー | 16 | クライアントIP |
| 12 | ユーザー | バルチャー | 17 | ログインユーザー名 |
| 13 | データベース | バルチャー | 64 | イベント関連データベース |
| 14 | テーブル | バルチャー | 64 | イベント関連テーブル名 |
| 15 | SQL_TEXT | バルチャー | 64KB | マスクされたSQL文 |
| 16 | 行 | 整数 | 影響を受ける行の数（ 0影響を受ける行がないことを示します） |
TiDB によって設定された EVENT_CLASS フィールド値に応じて、監査ログ内のデータベース イベント レコードには次の追加フィールドも含まれます。
EVENT_CLASS 値が
CONNECTION場合、データベース イベント レコードには次のフィールドも含まれます。列番号 フィールド名 TiDB データ型 最大長 説明 17 クライアントポート 整数 クライアントポート番号 18 接続ID 整数 接続ID 19 接続タイプ バルチャー 12 socketまたはunix-socket経由の接続20 サーバーID 整数 TiDBサーバーID 21 サーバーポート 整数 TiDBサーバーがMySQLプロトコル経由でクライアントの通信をリッスンするために使用するポート 22 サーバーOSログインユーザー バルチャー 17 TiDBプロセス起動システムのユーザー名 23 OS_バージョン バルチャー 該当なし TiDBサーバーが配置されているオペレーティング システムのバージョン 24 SSL_バージョン バルチャー 6 TiDBの現在のSSLバージョン 25 ピッド 整数 TiDBプロセスのPID EVENT_CLASS 値が
TABLE_ACCESSまたはGENERAL場合、データベース イベント レコードには次のフィールドも含まれます。列番号 フィールド名 TiDB データ型 最大長 説明 17 接続ID 整数 接続ID 18 指示 バルチャー 14 MySQLプロトコルのコマンドタイプ 19 SQL_ステートメント バルチャー 17 SQL文の種類 20 ピッド 整数 TiDBプロセスのPID