【ITニュース解説】general_log = 1 writes every query to a file, including the passwords in them

MySQLやMariaDBには、「一般クエリログ（general query log）」と呼ばれる機能が存在する。この機能は、データベースサーバーが受け取ったすべてのSQLステートメントを記録するものだ。デフォルトでは無効になっているが、これを有効にすると、サーバーに対して行われたあらゆる操作がテキストファイルとして詳細に記録される。

具体的には、データベースへの接続、実行されたすべてのSQLステートメント、そしてデータベースからの切断といった一連の流れが記録される。ログの出力先はlog_outputという設定によって、ファイル、データベース内のテーブル、あるいはその両方に設定できる。記録される内容は、サーバーが受け取ったSQLステートメントそのままだ。例えば、新しいユーザーを作成し、パスワードを設定するCREATE USER ... IDENTIFIED BY 'password'のようなステートメントや、パスワードを変更するALTER USER ... IDENTIFIED BY、あるいは特定の権限を付与するGRANT ... IDENTIFIED BYといったコマンドは、その中に含まれるパスワードが平文でログに書き出される。これだけでなく、アプリケーションが発行するクエリの中に直接秘密情報（例えばAPIキーや個人情報）が含まれている場合も、それらがそのままログファイルに記録される。セッション固有の値、一時的な認証トークン、個人データなども同様に記録対象となる。

この一般クエリログは、SYSTEM_VARIABLES_ADMINという特別な権限を持つアカウントであれば、データベースが稼働中でも有効にしたり、出力先のファイル（general_log_fileで設定）を変更したりできる。この事実は、ログが有効になっていた場合、「誰がそれを有効にしたのか」「出力はどこに保存されたのか」という監査上の重要な問いにつながる。

このログ設定が、単なるパフォーマンス監視とは異なる深刻な問題を引き起こす理由は主に三つある。

一つ目は、ログファイルが「機密情報（クレデンシャル）の保管場所」として適切に認識されていないことだ。ログに記録されたパスワードは、そのファイルを読み取れる人物であれば誰でも閲覧できてしまう。通常、データベースのデータディレクトリに設定されるファイル権限は、サーバーが正常に動作するために必要な最低限のアクセス権限であることが多く、ログファイルに含まれる情報の機密性に合わせて厳しく設定されているわけではない。そのため、意図しない情報漏洩のリスクが高まる。

二つ目は、記録される情報の「広範囲性」だ。一般クエリログには、監視用のアカウント、レポート作成用のアカウント、そしてアプリケーション本体が使用するアカウントなど、すべてのユーザーが実行したすべてのクエリが記録される。誰かがこのログファイルにアクセスできれば、サーバー全体のあらゆる操作履歴とそれに伴う機密情報が一度に手に入ってしまう可能性がある。

三つ目は、ログの「保持期間」だ。ログファイルは定期的にローテーションされ、過去のログはバックアップシステムや別のストレージにコピーされることがある。そのため、一時的なトラブルシューティング目的でログを有効にしても、記録された機密情報が、本来の目的が終了した後もバックアップ媒体上に長期間残り続ける可能性がある。

他のログについても触れておく。スロークエリログやバイナリログも、特定の条件の下でSQLステートメントを記録する機能だ。これらもステートメントやレプリケーション形式によっては機密情報を記録する可能性があるが、一般クエリログは最も広範囲な情報を記録する。また、急いでいる状況で問題の切り分けのために安易に有効にされやすいのも、この一般クエリログの特徴と言えるだろう。

これらのリスクを避けるために、以下の対策を講じることが重要だ。

まず、現在稼働しているすべてのサーバーで、general_log（一般クエリログの有効/無効）、log_output（出力先）、general_log_file（ログファイルパス）の現在の設定値を確認すること。設定ファイルだけでなく、実行中に動的に変更されている可能性もあるため、必ずランタイムの値を確認する必要がある。

もしログの取得が必要な場合は、その「範囲を限定する」ことが不可欠だ。具体的には、必要な期間のみ一般クエリログを有効にし、出力先を厳重に管理された場所に設定する。使用後は必ずログを無効化し、ログファイルを適切にローテーション（削除またはアーカイブ）すること。これらの操作を行った人物を記録することも重要だ。

次に、一般クエリログを有効にできる「権限を制限する」ことだ。SYSTEM_VARIABLES_ADMIN権限を持つアカウントは、ログの状態や出力先を自由に変更できてしまう。この権限の付与は、実質的に機密情報を漏洩させる能力を与えることと等しいため、本当に必要な人にのみ与えるべきだ。

そして、「出力された情報を機密情報として保護する」必要がある。ログファイルのファイル権限は、その中に含まれるステートメントの機密性に合わせて設定すべきであり、データディレクトリのデフォルトの権限よりも厳しくする必要がある。

さらに、バックアップやログ転送のシステムについても見直し、機密情報を含むステートメントが残っていないか確認すること。もしそのような情報が含まれている場合は、ログの保持期間の前にスクラブ（機密情報を削除または匿名化する処理）を検討することも重要だ。

継続的な診断やパフォーマンス監視が必要な場合は、一般クエリログよりも、デフォルトで記録する情報が少ない「パフォーマンススキーマ」や、「スロークエリログ（long_query_timeを適切に調整したもの）」を利用することを推奨する。これらは、より限定された情報を提供し、診断目的に必要な情報を効率的に取得できる。

一般クエリログは、データベースの診断機能として設計通りに動作する。しかし、この機能が有効になっているか、誰がその出力ファイルを読み取れるか、どのようなSQLステートメントがデータベースに送信されるかによって、機密情報が外部に漏れるリスクが生じることを理解しておくべきだ。