このページは機械翻訳したものです。

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

MySQL サーバーに接続するときは、パスワードを使用するようにしてください。 パスワードはクリアテキストとして接続経由で送信されません。

ほかのすべての情報はテキストとして送信され、接続を観察できるすべてのユーザーによって読み取ることができます。 クライアントとサーバーの間の接続が、信頼できないネットワークを介して行われ、そのことに不安がある場合、圧縮されたプロトコルを使用して、トラフィックの解読をさらに困難にすることができます。 また、MySQL の内部 SSL サポートを使用して、接続をさらにセキュアな状態にすることもできます。 セクション6.3「暗号化された接続の使用」を参照してください。 または 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.2.14「アカウントパスワードの割り当て」を参照してください。

• データベースディレクトリ内の読み取りまたは書き込み権限を持つ 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.8「サーバーシステム変数」を参照してください。

• バイナリログファイルとリレーログファイルを暗号化します。 暗号化を使用すると、これらのファイルおよびそのファイルに含まれる機密データを、外部の攻撃者による誤用や、ファイルが格納されているオペレーティングシステムのユーザーによる不正な表示から保護できます。 MySQL サーバーで暗号化を有効にするには、binlog_encryption システム変数を ON に設定します。 詳細は、セクション17.3.2「バイナリログファイルとリレーログファイルの暗号化」を参照してください。

• 管理者以外のユーザーに PROCESS または SUPER 権限を付与しないでください。 mysqladmin processlist および SHOW PROCESSLIST の出力には、現在実行されているステートメントのテキストが表示されるため、サーバープロセスリストの表示を許可されているユーザーは、ほかのユーザーによって発行されたステートメントを表示できます。

  mysqld は、CONNECTION_ADMIN または SUPER 権限を持つユーザーに対して追加の接続を予約するため、MySQL root ユーザーは、通常の接続がすべて使用されている場合でも、ログインしてサーバーアクティビティを確認できます。

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

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

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

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

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

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