Skip navigation links
4.6.3 セキュリティ関連の mysqld オプション »
Section Navigation      [Toggle]

4.6.2. MySQL のクラッカー対策

MySQL サーバに接続するときは、パスワードを使用します。MySQL 4.1.1 以降、クライアント接続中のパスワード処理に関して、より高度なセキュリティでグレードアップしています。パスワードは平文テキストでは送信していませんが、MySQL 4.1 より前のバージョンでの暗号化アルゴリズムは、新バージョンで採用しているパスワード形式ほど強力なものではありません。そのため、古いパスワード形式を使用している場合は、クライアントとサーバ間のトラフィックを盗聴できれば、クラッカーは少しの努力でパスワードを探り当てることができる可能性があります。パスワードのメカニズムに関しては、項4.7.9. 「MySQL 4.1 のパスワードハッシュ」 を参照してください。

MySQL Enterprise.  The MySQL Network Monitoring and Advisory Service では、サーバ セキュリティの強化に関する情報を提供しています。詳細は http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

パスワード以外の情報はテキスト形式で送信されているため、第三者によって内容を読み盗られる可能性があります。クライアントとサーバ間の接続が信用できないネットワークを経由する場合に、この可能性を懸念するときは、解読が困難な圧縮プロトコルを使用します。接続時のセキュリティをさらに高めるには、MySQL の内部 SSL サポートを使用します。(項4.8.7. 「接続安全」 を参照のこと。) 別の方法としては、MySQL サーバと MySQL クライアント間で暗号化 TCP/IP 接続に SSH を利用することも可能です。Open Source SSH クライアントは http://www.openssh.org/を、商用の SSH クライアントは、http://www.ssh.com/ をそれぞれ参照してください。

MySQL システムのセキュリティを確保するためには、以下の事項を強く推奨します。

  • すべての MySQL ユーザにパスワードを使用する。クライアント プラグラム側では、そのプログラムを実行してる者が誰であるのかを知る必要はなく、クライアント/サーバ型のアプリケーションにおいては、クライアント側で任意のユーザ名を指定できるのが一般的である。たとえば、別の者が接続に mysql プログラムを簡単に使用することができ、つまり、other_user にパスワードが設定されていなければ、だれでも mysql -u other_user db_name として簡単に他人になりすましてログインできる。すべてのユーザにパスワードを使用すれば、他人のユーザ名で接続することが困難になる。

    パスワードのセッティング方法に関する記述は、項4.8.5. 「パスワードの設定」 を参照のこと。

  • MySQL サーバ (デーモン) を Unix root アカウントで実行しないこと。これを行なうと、FILE 権限のあるユーザであれば誰でも root （例： ~root/.bashrc）としてファイルを作成できてしまうので、非常に危険である。これを防ぐために、--user=root オプションを使用して直接指定された場合を除き、mysqld は root として実行することを拒否するようになっている。

    mysqld は、普通のユーザ、つまり権限なしのユーザで実行できる。新しい Unix アカウント mysql を作成してさらにセキュリティを高めることができ、これを、MySQL 管理専用のアカウントとする。別の Unix アカウントで mysqld を開始するには、サーバのデータディレクトリにある my.cnf オプション設定ファイルの [mysqld] グループに、アカウント名を指定する user 行を追加する。次に例を示す。 

    [mysqld]
user=mysql

    これで、サーバを手動で起動した場合も、mysqld_safe または mysql.server を使用して起動した場合でも、指定のアカウントでサーバが起動する。詳細は 項4.6.5. 「ユーザによる MySQL の実行」 を参照のこと。

    mysqld を root ではない Unix ユーザで実行するということは、user テーブルで root というユーザ名を変更する必要がある、という意味ではない。MySQL アカウントのユーザ名と、 Unix アカウントにはお互い何の関係もない。

  • テーブルへのシンボリック リンクをサポートしない。(これは --skip-symbolic-links オプションで無効にできる）。このことは、root で mysqld を実行する場合、mysqld サーバ データ ディレクトリへの書き込み権限があるユーザであれば誰でも、システムのすべてのファイルを削除できることになるので、特に重要である。項6.6.1.2. 「Unix 上のテーブルに対するシンボリックリンクの使用」 を参照のこと。

  • mysqld を実行する Unix アカウントだけに、データベース ディレクトリの読み取り権限と書き込み権限があることを確認する。

  • PROCESS または SUPER の権限を管理側ユーザには以外には与えない。mysqladmin processlist と SHOW PROCESSLIST の出力には、現在実行中のクエリのテキストが表示される。そのため、これらコマンドを実行できるユーザは、UPDATE user SET password=PASSWORD('not_secure') などのクエリを実行して、サーバ プロセス リストを開示してしまう可能性がある。

    mysqld は、SUPER 権限を持つユーザ用に特別接続枠を予約しているので、すべての通常接続が使用中の場合でも、MySQL root ユーザはログインしてサーバの状態をチェックできる。

    SUPER 権限はクライアント接続を中断でき、システム変数を変更することでサーバのオペレーションを変更し、さらに、レプリケーション サーバもコントロールする。

  • FILE 権限をすべてのユーザには与えない。この権限を持つユーザは、mysqld デーモンの権限でファイルシステムのどの場所にでもファイルを書き込める。安全対策として、SELECT ... INTO OUTFILE で生成されるファイルについてはだれでも書き込み可能だが、既存のファイルには書き込めないようになっている。

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

  • DNS を信頼しない場合、権限テーブルで、ホスト名ではなく IP アドレスを使用すること。いずれにしても、ワイルド カードを含むホスト名を使用して権限テーブルを作成する際には特に注意が必要である。

  • 単一ユーザの接続数を制限する場合は、mysqld で max_user_connections 変数を設定する。 GRANT ステートメントでも、ユーザへのサーバ接続を制限するリソース コントロール オプションがある。項12.5.1.3. 「GRANT 構文」 を参照のこと。