6.1.3 攻撃者に対する MySQL のセキュアな状態の維持

MySQL サーバーに接続するときは、パスワードを使用するようにしてください。接続において、パスワードは平文で送信されません。クライアント接続シーケンス中のパスワード処理は、きわめてセキュアな状態を維持するように MySQL 4.1.1 でアップグレードされました。4.1.1 より前の形式のパスワードをまだ使用している場合、暗号化アルゴリズムは新しいアルゴリズムほど強くありません。クライアントとサーバーの間のトラフィックを傍受できる利口な攻撃者は、多少の労力をかければパスワードを解読することができます。(さまざまなパスワード処理方法についての説明は、セクション6.1.2.4「MySQL でのパスワードハッシュ」を参照してください。)

ほかのすべての情報はテキストとして送信され、接続を観察できるすべてのユーザーによって読み取ることができます。クライアントとサーバーの間の接続が、信頼できないネットワークを介して行われ、そのことに不安がある場合、圧縮されたプロトコルを使用して、トラフィックの解読をさらに困難にすることができます。また、MySQL の内部 SSL サポートを使用して、接続をさらにセキュアな状態にすることもできます。セクション6.3.10「セキュアな接続のための SSL の使用」を参照してください。または SSH を使用して、MySQL サーバーと MySQL クライアントの間で暗号化された TCP/IP 接続を実現します。オープンソース SSH クライアントは http://www.openssh.org/ から見つけることができ、オープンソースと商用の SSH クライアントの比較は http://en.wikipedia.org/wiki/Comparison_of_SSH_clients にあります。

MySQL システムをセキュアな状態にするには、次の推奨事項についてよく検討するようにしてください。

• すべての MySQL アカウントがパスワードを持つことを要求します。クライアントプログラムは、それを実行中の人物の ID を必ずしも認識しているわけではありません。クライアント/サーバーアプリケーションでは、ユーザーがクライアントプログラムに任意のユーザー名を指定できることが一般的です。たとえば、other_user にパスワードがない場合、mysql プログラムを mysql -u other_user db_name として呼び出すことによって、すべてのユーザーがこのプログラムを使用してほかのユーザーとして接続することができます。すべてのアカウントにパスワードがある場合、ほかのユーザーのアカウントを使用した接続は、もっと難しくなります。

  パスワードの設定方法についての説明は、セクション6.3.5「アカウントパスワードの割り当て」を参照してください。

• データベースディレクトリ内の読み取りまたは書き込み権限を持つ Unix ユーザーアカウントのみが、mysqld の実行に使用されるアカウントであるようにしてください。

• MySQL サーバーを Unix root ユーザーとして絶対に実行しないでください。これを行うと、FILE 権限を持つすべてのユーザーが、root としてサーバーにファイルを作成させることができるため (~root/.bashrc など)、非常に危険です。これを防ぐために、mysqld は --user=root オプションを使用して明示的に指定された場合を除き、root として実行することを拒否します。

  mysqld は、権限のない普通のユーザーとしても実行できます (また、そのように実行するべきです)。mysql という名前の別の Unix アカウントを作成して、すべてをさらにセキュアな状態にすることができます。このアカウントは、MySQL の管理にのみ使用してください。mysqld を別の Unix ユーザーとして開始するには、サーバーオプションを指定した my.cnf オプションファイルの [mysqld] グループ内のユーザー名を指定する user オプションを追加します。例:

  [mysqld]
  user=mysql

  これにより、サーバーを手動で起動した場合も、mysqld_safe または mysql.server を使用して起動した場合も、指定のユーザーでサーバーが起動します。詳細は、セクション6.1.5「MySQL を通常ユーザーとして実行する方法」を参照してください。

  root 以外の Unix ユーザーとして mysqld を実行しても、user テーブル内の root ユーザー名を変更する必要があるということを意味するわけではありません。MySQL アカウントのユーザー名は、Unix アカウントのユーザー名とは何の関係もありません。

• 管理者以外のユーザーに FILE 権限を付与しないでください。この権限を持つすべてのユーザーは、mysqld デーモンの権限で、ファイルシステムのあらゆる場所のファイルに書き込むことができます。これは、権限テーブルを実装するファイルを格納するサーバーのデータディレクトリを含みます。FILE 権限の操作をもう少し安全にするために、SELECT ... INTO OUTFILE で生成されたファイルは既存のファイルを上書きせず、すべてのユーザーによって書き込み可能になります。

  FILE 権限は、すべてのユーザーが読み取り可能であるか、サーバーを実行している Unix ユーザーがアクセスできる、すべてのファイルを読み取る場合にも使用できます。この権限を使用して、すべてのファイルをデータベーステーブルに読み取ることができます。これは不正使用される可能性があり、たとえば LOAD DATA を使用して /etc/passwd をテーブルにロードし、次に SELECT を使用してこれを表示することができます。

  ファイルを読み取りおよび書き込みできる場所を制限するには、secure_file_priv システムを特定のディレクトリに設定します。セクション5.1.4「サーバーシステム変数」を参照してください。

• 管理者以外のユーザーに PROCESS または SUPER 権限を付与しないでください。mysqladmin processlist および SHOW PROCESSLIST の出力には、現在実行されているすべてのステートメントのテキストが表示されるため、サーバープロセスリストを表示できるすべてのユーザーが、ほかのユーザーによって発行された UPDATE user SET password=PASSWORD('not_secure') などのステートメントを表示できる場合があります。

  mysqld は、SUPER 権限を持つユーザー用に特別な接続を確保しているため、通常の接続がすべて使用中の場合でも、MySQL root ユーザーはログインしてサーバーのアクティビティーを検査することができます。

  SUPER 権限は、クライアント接続を終了したり、システム変数の値を変更することによってサーバー操作を変更したり、レプリケーションサーバーを制御したりするために使用することができます。

• テーブルへのシンボリックリンクを許可しないでください。(この機能は --skip-symbolic-links オプションで無効にできます。)このことは、mysqld を root として実行する場合に特に重要です。これは、サーバーのデータディレクトリへの書き込みアクセス権限があるすべてのユーザーは、システムのすべてのファイルを削除できることになるためです。セクション8.11.3.1.2「Unix 上の MyISAM へのシンボリックリンクの使用」を参照してください。

• ストアドプログラムおよびビューは、セクション20.6「ストアドプログラムおよびビューのアクセスコントロール」に記載されているセキュリティーガイドラインを使用して記述するようにしてください。

• DNS を信頼していない場合、付与テーブル内でホスト名の代わりに IP アドレスを使用するようにしてください。いずれの場合も、ワイルドカードを含むホスト名の値を使用して付与テーブルエントリを作成することについては、十分に注意するようにしてください。

• 単一アカウントに対して許可される接続数を制限するには、mysqld の max_user_connections 変数を設定することによってこれを実行できます。GRANT ステートメントは、アカウントに対して許可されるサーバー使用の範囲を制限するためのリソース制御オプションもサポートします。セクション13.7.1.4「GRANT 構文」を参照してください。

• プラグインディレクトリがサーバーによって書き込み可能な場合、ユーザーは SELECT ... INTO DUMPFILE を使用して、ディレクトリ内のファイルに実行可能コードを書き込むことができます。これを防ぐために、plugin_dir をサーバーに対して読み取り専用にしたり、SELECT 書き込みが安全に実行できるディレクトリに --secure-file-priv を設定したりできます。