ApsaraDB RDS for MySQL で SQL Explorer と監査を使用する - ApsaraDB RDS

セキュリティコンプライアンス監査、パフォーマンス分析、およびトラブルシューティングのために、SQL Explorer と監査の有効化を推奨します。この機能を有効にすると、システムはデータベースカーネルによって実行された SQL ステートメントを、実行アカウント、IP アドレス、実行詳細などの関連情報とともに自動的に記録します。この機能はインスタンスのパフォーマンスへの影響が非常に小さく、過去の SQL 実行記録の照会や、その後の分析および監査のための信頼性の高いデータソースを提供します。

前提条件

Database Autonomy Service (DAS) Enterprise Edition をサブスクライブしている必要があります。
SQL Explorer と監査機能を使用するには、Database Autonomy Service (DAS) Enterprise Edition を有効にする必要があります。コンソールでは、現在のリージョンでサポートされている最新バージョンの DAS Enterprise Edition のみを有効にできます。サポートされているリージョンは、DAS Enterprise Edition のバージョンによって異なります。
RAM ユーザーが Audit 機能を使用するには、AliyunRDSReadOnlyWithSQLLogArchiveAccess 権限が必要です。RAM ユーザーに権限を付与する方法の詳細については、「RAM を使用して ApsaraDB RDS インスタンスの権限を制御する」をご参照ください。
カスタムポリシーを使用して、RAM ユーザーに SQL Explorer と監査の検索機能とエクスポート機能を使用する権限を付与することもできます。詳細については、「カスタムポリシーを使用して RAM ユーザーに SQL Explorer と監査の検索機能とエクスポート機能を使用する権限を付与する」をご参照ください。

重要

SQL Explorer と監査は、すべての DQL、DML、および DDL 操作を記録できます。この情報はデータベースカーネルから収集されるため、CPU 使用率への影響は最小限です。

機能概要

SQL Explorer と監査は、監査、SQL Explorer、セキュリティ監査、トラフィック再生とストレステスト、SQL 分析などの機能を提供します。

監査：SQL ステートメントの実行履歴と、データベース、ステータス、実行時間などの関連情報を照会およびエクスポートします。
SQL Explorer：特定の期間内の SQL ステートメントの健全性を診断し、パフォーマンスの問題をトラブルシューティングし、サービストラフィックを分析します。
セキュリティ監査 (レガシー)：高リスクの SQL ステートメント、SQL インジェクション、新しいアクセス元などのリスクを自動的に識別します。
トラフィック再生とストレステスト：トラフィック再生とストレステストを提供し、トラフィックスパイクに対処するためにインスタンス仕様をスケールアップする必要があるかどうかの判断に役立ちます。
SQL 分析：指定された期間内の SQL ステートメントを分析して、異常な SQL ステートメントを特定し、パフォーマンスの問題を特定します。

SQL Explorer と監査は、以下のようなシナリオでよく使用されます。

金融、セキュリティ、証券、政府、保険など、データセキュリティ要件が厳格な業界。
問題のトラブルシューティング、SQL パフォーマンス分析、異常なセッションの識別など、データベース操作の詳細な調査が必要なシナリオ。
データの損失や破損が発生した極端なケースでは、SQL Explorer によって記録された SQL ステートメントを使用して問題を分析し、データを復元できます。

対応リージョン

中国 (杭州)、中国 (上海)、中国 (青島)、中国 (北京)、中国 (張家口)、中国 (フフホト)、中国 (ウランチャブ)、中国 (深セン)、中国 (河源)、中国 (広州)、中国 (成都)、中国 (香港)、シンガポール、日本 (東京)、マレーシア (クアラルンプール)、インドネシア (ジャカルタ)、米国 (シリコンバレー)、英国 (ロンドン)、米国 (バージニア)、ドイツ (フランクフルト)

課金

SQL Explorer から SQL Explorer と監査へのアップグレード前にインスタンスを購入し、SQL Explorer 機能を有効にした場合：ApsaraDB RDS は、機能料金を時間単位で課金します。料金はインスタンスのリージョンによって異なります。
- USD 0.0015 / GB / 時間：中国 (香港)、米国 (シリコンバレー)、米国 (バージニア)。
- USD 0.0018 / GB / 時間：シンガポール、日本 (東京)、ドイツ (フランクフルト)、UAE (ドバイ)、マレーシア (クアラルンプール)、インドネシア (ジャカルタ)、英国 (ロンドン)。
- USD 0.0012 / GB / 時間：中国 (杭州)、中国 (上海)、中国 (青島)、中国 (北京)、中国 (張家口)、中国 (フフホト)、中国 (ウランチャブ)、中国 (深セン)、中国 (河源)、中国 (広州)、中国 (成都)。
説明
SQL エクスプローラー タブに表示されるアップグレードダイアログボックスで、[ワンクリックアップグレード] をクリックして SQL Explorer and Audit にアップグレードできます。アップグレード後、料金は DAS によって請求されます。
SQL Explorer からのアップグレード後に SQL Explorer と監査機能を有効にした場合：料金は DAS によって課金されます。SQL Explorer と監査機能を使用するには、Database Autonomy Service (DAS) Enterprise Edition を有効にする必要があります。サポートされているリージョンと課金方法は、エディションによって異なります。詳細については、「各エディションでサポートされているデータベースとリージョン」および「各エディションの課金」をご参照ください。
説明
コンソールでは、現在のリージョンでサポートされている最新バージョンの DAS Enterprise Edition のみを有効にできます。

注意事項

オンラインクエリ：
- 時間範囲：1 回のオンラインクエリでは、最大 24 時間の範囲を指定できます。データ保持期間内の任意の 24 時間分のデータを照会できます。指定した時間範囲が長すぎる場合、クエリがタイムアウトする可能性があります。より長い時間範囲で SQL レコードを照会する必要がある場合は、Simple Log Service (SLS) を使用してエクスプローラーログにアクセスしてください。詳細については、「ApsaraDB RDS for MySQL 監査ログの収集」をご参照ください。
- クエリ方法： オンラインクエリは複合条件をサポートしますが、あいまい検索はサポートしていません。各クエリキーワードは、4 文字以上である必要があります。
SQL Explorer と監査：
- SQL ステートメントの最大長: SQL エクスプローラーと監査によって記録される SQL ステートメントの最大長は 8,192 バイト です。この上限は、loose_rds_audit_max_sql_size パラメーター (MySQL 5.6/5.7 の場合) または loose_rds_audit_log_event_buffer_size パラメーター (MySQL 8.0/8.4 の場合) の影響も受けます。有効な上限は、これらの値の最小値です。情報収集中にプレフィックスが追加されるため、実際に記録される SQL ステートメントの長さは、8,192 バイトまたはパラメーターで指定された値よりわずかに短くなります。
- 監査レコードのクエリ: スレッド ID とトランザクション ID で SQL ステートメントのレコードをクエリできます。トランザクション ID でクエリするには、loose_rds_audit_log_version パラメーターを MYSQL_V3 に設定する必要があります。この機能には最小マイナーエンジンバージョンが必要です。MySQL 8.4 のすべてのバージョンがサポートされており、MySQL 8.0 は 20210930 以降、MySQL 5.7 は 20210630 以降である必要があります。詳細については、「ApsaraDB RDS for MySQL 8.0 インスタンスで利用可能なパラメーター」および「マイナーエンジンバージョンをアップグレードする」をご参照ください。
- SQL Explorer の試用版：SQL Explorer の試用版を使用している場合、DescribeSQLLogRecords および DescribeSQLLogFiles API を呼び出して監査ログを照会することはできません。
- ロック待機時間：エクスプローラーログにはロック待機時間が含まれていますが、スロークエリログには含まれていません。
- アプリケーションが Prepare メソッドを使用する場合、SQL Explorer には 2 つのステートメントが表示されます。1つは疑問符を含むステートメント、もう1つは特定の値を含むステートメントです。
データベースプロキシエンドポイントを使用して ApsaraDB RDS インスタンスに接続し、プロキシのトランザクションレベル接続プールが有効になっている場合、接続が再利用される可能性があります。その結果、show processlist コマンドまたは SQL Explorer に表示される IP アドレスとポートが、クライアントの実際の IP アドレスとポートと一致しない場合があります。
PolarDB-X 1.0 インスタンスに接続された ApsaraDB RDS for MySQL インスタンスで SQL ステートメントが実行されると、水平シャーディングにより、ApsaraDB RDS for MySQL インスタンスで複数の SQL Explorer と監査ログが生成されます。
ログの完全性：以下のような極端な状況では、SQL Explorer と監査ログが不完全になるか、部分的に失われる可能性があります。
- インスタンスの負荷が高く、パフォーマンスのボトルネックが発生している。
- インスタンスが単位時間あたりに大量の SQL リクエストを生成している。
- 監査ログ収集を担当するコントロールサービスコンポーネントが正常に動作していない。

SQL Explorer と監査の有効化

説明

Simple Log Service (SLS) の CloudLens for RDS で ApsaraDB RDS for MySQL インスタンスの監査ログ収集機能を有効にしている場合、そのインスタンスの SQL Explorer と監査機能が自動的に有効になります。
SQL Explorer と監査を有効にしていない場合、バイナリログを使用して SQL 実行レコードを表示できます。バイナリログには、バックアップ保持期間内の INSERT、DELETE、および UPDATE ステートメントのみが含まれており、送信元 IP アドレスやアカウント情報は提供されません。

RDSインスタンスにアクセスし、上部のリージョンを選択し、対象のRDSインスタンスのIDをクリックします。
左側のナビゲーションペインで、自律型サービス > SQL Explorer and Auditを選択します。
[DAS Enterprise Edition V3 を有効にする] をクリックします。
有効にする機能を選択し、Activate をクリックします。

データ保持期間の変更

警告

SQL Explorer と監査のデータ保持期間を短縮すると、DAS は新しい保持期間を超えたすべての SQL 監査ログを直ちに削除します。データ保持期間を短縮する前に、SQL 監査ログをエクスポートしてローカルマシンに保存することを推奨します。

RDSインスタンスにアクセスし、上部のリージョンを選択し、対象のRDSインスタンスのIDをクリックします。
左側のナビゲーションペインで、自律型サービス > SQL Explorer and Auditを選択します。
Service Settings をクリックします。
Service Settings ページで、監査シナリオ のログの保存期間を変更し、提出をクリックします。

SQL Explorer と監査の無効化

警告

SQL Explorer と監査を無効にすると、すべてのログがクリアされます。まずログをエクスポートして保存することを推奨します。機能を再度有効にすると、再度有効にした時点からログが記録されます。

RDSインスタンスにアクセスし、上部のリージョンを選択し、対象のRDSインスタンスのIDをクリックします。
左側のナビゲーションペインで、自律型サービス > SQL Explorer and Auditを選択します。
Audit タブの Logs セクションで、エクスポート をクリックします。
表示されたダイアログボックスで、エクスポートするフィールドを選択し、エクスポートの時間範囲を指定して、OK をクリックします。
説明
- 1 回の操作で、7 日間の期間を対象として、最大 1,000 万件のデータレコードをエクスポートできます。
- エクスポート期間 を設定すると、より長い期間の SQL レコードをエクスポートできます。
エクスポートが完了したら、エクスポートされたファイルをダウンロードし、安全な場所に保存します。
SQL エクスプローラーと監査を無効にするには、Service Settings をクリックします。
DAS Enterprise Edition V3 を有効にしている場合は、すべての SQL Explorer および Audit 機能のチェックボックスの選択を解除し、提出をクリックします。
説明
SQL Explorer と監査機能を無効にしてから約 1 時間後に、システムは SQL Explorer と監査データが占有していたストレージ領域を解放します。

Enterprise Edition バージョン間のデータ移行

警告

移行操作は中止またはロールバックできません。移行手順を注意深くお読みください。

データベースインスタンスが Enterprise Edition V3 をサポートしている場合、DAS Enterprise Edition V1 または V2 から Enterprise Edition V3 にデータを移行して、より有利な料金体系のメリットを享受できます。詳細については、「DAS Enterprise Edition バージョン間でデータを移行する方法」をご参照ください。

V1 と比較して、DAS Enterprise Edition V2 は、コストを削減するために、基盤となるストレージアーキテクチャをホット/コールドハイブリッドストレージモデルに変更しています。DAS Enterprise Edition V3 は、このハイブリッドストレージをベースに、課金項目を機能ごとにさらに細分化し、より柔軟な課金を提供します。

よくある質問

Q: ️SQL Explorer の logout! ステートメントは、Full Request Statisticsセクションの ️SQL Explorer において何を意味しますか？

A: logout! は切断を示します。logout! イベントの期間は、最後のインタラクションと logout! が発生した時点との時間差です。この期間は、接続アイドル時間として解釈できます。ステータス 列のステータス [1158] はネットワーク切断を示し、これは次の原因によって引き起こされる可能性があります。

クライアント接続がタイムアウトした。
サーバーが予期せず切断された。
interactive_timeout または wait_timeout の期間を超えたため、サーバーが接続をリセットした。

Q: ️SQL Explorerソース統計 セクション (️SQL Explorer) で、パーセント記号 (%) が アクセスソース として表示されるのはなぜですか？

A：これは、ストアードプロシージャを使用した場合に発生することがあります。以下の例で、この動作を再現できます：

説明

この例では、ApsaraDB RDS for MySQL インスタンス、test_user という名前のテストアカウント、および testdb という名前のテストデータベースを使用します。

ApsaraDB RDS コンソールで、標準アカウントを作成し、データベースへのアクセス権を付与します。詳細については、「(非推奨、「手順1」にリダイレクト) データベースとアカウントの作成」をご参照ください。
テストアカウントを使用して、コマンドラインからデータベースインスタンスに接続します。詳細については、「(非推奨、「手順2」にリダイレクト) クライアントまたはCLIを使用したApsaraDB RDS for MySQLインスタンスへの接続」をご参照ください。

テストデータベースに切り替え、次のストアードプロシージャを作成します。

-- テストデータベースに切り替え
USE testdb;

-- ストアードプロシージャの作成
DELIMITER $$
DROP PROCEDURE IF EXISTS `das` $$
CREATE DEFINER=`test_user`@`%` PROCEDURE `das`()
BEGIN
SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID();
END $$
DELIMITER;

特権アカウントを使用してデータベースインスタンスに接続します。詳細については、「(非推奨、「手順2」にリダイレクト) クライアントまたはCLIを使用したApsaraDB RDS for MySQLインスタンスへの接続」をご参照ください。

ストアードプロシージャを呼び出します。

-- テストデータベースに切り替え
USE testdb;

-- ストアードプロシージャの呼び出し
CALL das();

+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
| ID     | USER      | HOST   | DB     | COMMAND | TIME | STATE     | INFO                                                                    |
+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
| 487818 | test_user | %:2065 | testdb | Query   |    0 | executing | SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID() |
+--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+

Q：データが返されているのに、スキャンされた行数が 0 になるのはなぜですか?

A: これは、データベースインスタンスで query_cache_type 機能が有効になっているためです。ログリストのスキャンされた行数は、InnoDB エンジンレイヤーでスキャンされた行数を反映しています。query_cache_type が有効になっている場合、MySQL はクエリ結果のキャッシュを試みます。後続の同一クエリリクエストがキャッシュにヒットすると、結果は InnoDB レイヤーにアクセスすることなくキャッシュから直接返されます。したがって、データは返されますが、スキャンされた行数は 0 になります。詳細については、「高速クエリキャッシュ」をご参照ください。

Q：SQL Explorer とバイナリログの違いは何ですか?

SQL Explorer またはバイナリログを使用して、ApsaraDB RDS for MySQL インスタンスの増分データを表示できます。違いは次のとおりです。

SQL Explorer：データベースからすべての増分データをキャプチャするのに適しています。ただし、インスタンスの負荷が非常に高い場合、少数のレコードが失われる可能性があり、増分データ統計が不正確になる可能性があります。すべての DQL、DML、および DDL 操作を記録できます。この情報はデータベースカーネルから収集されるため、CPU 使用率への影響は最小限です。
バイナリログ：短期間で正確な増分データを取得するのに適していますが、リアルタイムのログ情報は提供されません。すべての INSERT、DELETE、および UPDATE 操作を正確に記録し、増分ユーザーデータの復元に使用できます。バイナリログはインスタンスに一時的に保存されます。システムは、完了したバイナリログファイルを定期的に Object Storage Service (OSS) に転送し、7 日間保持します。アクティブに書き込まれているバイナリログファイルはアップロードできません。その結果、アップロードをクリックした後、一部のバイナリログがアップロードされない場合があります。詳細については、「ApsaraDB RDS for MySQL インスタンスのバイナリログをリモートで取得して解析する」をご参照ください。

Q：SQL Explorer のエントリがコンソールから消えたのはなぜですか?

A: 最新バージョンのエントリは SQL Explorer and Audit に名前が変更されました。

Q：古いバージョンの SQL Explorer を有効にできますか?

A：インスタンスでサポートされている最新バージョンの SQL Explorer と監査のみを有効にできます。

Q：エクスポート後も元のレコードは利用できますか?

A：はい。エクスポート操作では、元の監査レコードは削除されません。