ApsaraDB RDS for MySQL での SQL Explorer and Audit の使用 - ApsaraDB RDS

セキュリティコンプライアンス監査、パフォーマンス分析、およびトラブルシューティングのために、SQL Explorer and Audit を有効化してください。この機能は、データベースカーネル内で実行されたすべての SQL ステートメントとその関連情報（実行アカウント、IP アドレス、実行情報など）を自動的に記録します。インスタンスのパフォーマンスへの影響は極めて小さく、過去の SQL レコードのクエリやその後の分析・監査に信頼性の高いデータを提供します。

前提条件

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

重要

SQL Explorer and Audit 機能は、すべてのデータクエリ言語 (DQL)、データ操作言語 (DML)、およびデータ定義言語 (DDL) の操作を記録します。この情報はデータベースカーネルから出力され、CPU リソースを最小限に消費します。

機能概要

SQL Explorer and Audit は、検索（監査）、SQL Explorer、セキュリティ監査、本番トラフィック再現によるストレステスト、SQL 分析などの機能を提供します。

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

SQL Explorer and Audit は、以下のシナリオで一般的に使用されます。

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

サポート対象リージョン

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

課金

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

注意事項

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

SQL Explorer and Audit の有効化

説明

Simple Log Service (SLS) の CloudLens for RDS でご利用の ApsaraDB RDS for MySQL インスタンスの監査ログ収集機能を有効化すると、SQL Explorer and Audit 機能が自動的に有効化されます。
SQL Explorer and Audit 機能をまだ有効化していない場合、バイナリログを表示できます。バイナリログを使用すると、バックアップ保持期間内に生成されたデータの追加・削除・変更に関する SQL ステートメントのみをクエリできます。送信元 IP アドレスやアカウント情報は表示されません。

インスタンスページに移動します。上部のナビゲーションバーで RDS インスタンスが配置されているリージョンを選択し、該当の RDS インスタンスを見つけてインスタンス ID をクリックします。
左側のナビゲーションウィンドウで、自律型サービス > SQL Explorer and Audit を選択します。
[DAS Enterprise Edition V3 の有効化] をクリックします。
有効化する機能を選択し、Activate をクリックします。

データ保存期間の変更

警告

SQL Explorer and Audit のデータ保持期間を短縮すると、DAS は新しい期間を超える既存の SQL 監査ログを直ちに削除します。保持期間を短縮する前に、ログをエクスポートして保存してください。

インスタンスページに移動します。上部のナビゲーションバーで RDS インスタンスが配置されているリージョンを選択し、該当の RDS インスタンスを見つけてインスタンス ID をクリックします。
左側のナビゲーションウィンドウで、自律型サービス > SQL Explorer and Audit を選択します。
Service Settings をクリックします。
Service Settings ページで、監査シナリオ のログ保存期間を変更し、提出をクリックします。

SQL Explorer and Audit の無効化

警告

SQL Explorer and Audit を無効化すると、DAS はすべての既存ログをクリアします。機能を無効化する前に、ログをエクスポートして保存してください。再度機能を有効化した場合、ログは再有効化時点から記録されます。

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

Enterprise Edition 間のデータ移行

警告

移行操作は中断またはロールバックできません。実行前に移行手順をよくお読みください。

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

Enterprise Edition V1 と比較して、Enterprise Edition V2 はホットデータとコールドデータのハイブリッドストレージを実現する異なる基盤ストレージアーキテクチャを採用しており、コスト効率を向上させています。Enterprise Edition V3 はこのハイブリッドストレージアーキテクチャに基づいて構築されており、使用する機能ごとに個別に課金することで、より柔軟な課金を実現しています。

よくある質問

Q： ️SQL Explorerlogout! というステートメントが Full Request Statistics セクションに表示されるのは何を意味しますか？

A： logout! は切断を示します。logout! イベントの持続時間は、最後のやり取りの時刻とlogout! イベントが発生した時刻との差です。この持続時間は接続のアイドル時間を表します。1158 のステータスが ステータス 列に表示されている場合、ネットワーク切断を示しており、以下の理由が考えられます。

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

Q： ️SQL Explorer%) が アクセスソース として ソース統計 内に表示されるのはなぜですか？

A：ストアドプロシージャを使用している場合に発生することがあります。以下の例はこのシナリオを再現する方法を示しています。

説明

この例では、データベースインスタンスは ApsaraDB RDS for MySQL、テストアカウントは test_user、テストデータベースは testdb です。

ApsaraDB RDS コンソールで標準権限アカウントとデータベースを作成し、アカウントにデータベースへの権限を付与します。詳細については、「（非推奨、『ステップ 1』にリダイレクト）データベースとアカウントの作成」をご参照ください。
テストアカウントを使用してコマンドラインインターフェイス (CLI) からデータベースインスタンスに接続します。詳細については、「（非推奨、『ステップ 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： ApsaraDB RDS for MySQL インスタンスの監査機能のログ一覧で、データを返す一部の SQL ステートメントのスキャン行数が 0 になるのはなぜですか？

A：データベースインスタンスで query_cache_type パラメーターが有効になっています。ログ一覧では、SQL ステートメントのスキャン行数は InnoDB ストレージエンジンレイヤーでスキャンされた行数を示します。query_cache_type が有効な場合、MySQL はクエリ結果をキャッシュします。後続の同一クエリリクエストが受信され、クエリキャッシュがヒットすると、MySQL は InnoDB レイヤーへのクエリを行わずにキャッシュされた結果を直接返します。そのため、データは返されますが、ログ一覧のスキャン行数が 0 になります。詳細については、「高速クエリキャッシュ」をご参照ください。

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

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

SQL Explorer：データベース内のすべての増分データを取得するのに適しています。ただし、インスタンスが高負荷の状態では少量のレコードが失われる可能性があります。そのため、この機能を使用して収集された増分データの統計は不正確になることがあります。この機能はすべての DQL、DML、および DDL 操作を記録します。この情報はデータベースカーネルから出力され、CPU リソースを最小限に消費します。
バイナリログ：短期間で正確な増分データを取得するのに適していますが、リアルタイムログ情報を取得することはできません。この機能はデータベース内のすべてのデータ追加・削除・変更操作を正確に記録し、ユーザーの増分データを復元するために使用されます。バイナリログファイルは一時的にインスタンス内に保存されます。システムは定期的にインスタンスから完了したバイナリログファイルを Object Storage Service (OSS) に転送し、7 日間保持します。現在書き込み中のバイナリログファイルはアップロードできません。そのため、[Binlog のアップロード] をクリックしても、一部のバイナリログファイルはアップロードされません。詳細については、「ApsaraDB RDS for MySQL インスタンスのバイナリログをリモートで取得および解析する」をご参照ください。

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

A：機能バージョンの更新により、最新バージョンのエントリポイントは SQL Explorer and Audit に変更されました。

Q：以前のバージョンの SQL Explorer を有効化できますか？

A：いいえ。このインスタンスでサポートされている最新バージョンの SQL Explorer and Audit のみ有効化できます。

Q： SQL レコードをエクスポートした後も、元のレコードは保持されますか？

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