Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


18.5.11.2 MySQL Cluster と MySQL 権限

このセクションでは、MySQL Cluster に関連する MySQL 権限システムのしくみ、および MySQL Cluster のセキュリティーを維持するためのこの関わりについて説明します。

MySQL Cluster のテーブルには、標準の MySQL 権限が適用されます。これには、データベース、テーブル、およびカラムのレベルで付与されるすべての MySQL 権限タイプ (SELECT 権限、UPDATE 権限、DELETE 権限など) が含まれます。その他の MySQL サーバーの場合と同様に、ユーザーおよび権限の情報は mysql システムデータベースに格納されます。NDB テーブル、このようなテーブルを含むデータベース、およびこのようなテーブル内のカラムに対する権限を付与および取り消すために使用される SQL ステートメントは、(その他の) MySQL ストレージエンジンを含むデータベースオブジェクトとの接続に使用される GRANT および REVOKE ステートメントとすべての点で同じです。CREATE USER および DROP USER ステートメントについても、同じことが当てはまります。

MySQL 付与テーブルは、デフォルトで MyISAM ストレージエンジンを使用することに留意しておくことが重要です。そのため、MySQL Cluster の SQL ノードとして動作している MySQL サーバー間で、通常これらのテーブルの複製や共有は行われません。言い換えると、デフォルトでは、ユーザーおよびそれらの権限を変更しても自動的に SQL ノード間に反映されません。必要に応じて、MySQL Cluster の SQL ノード間で MySQL ユーザーおよび権限の自動配布を有効化できます。詳細は、セクション18.5.14「MySQL Cluster の配布された MySQL 権限」を参照してください。

逆に、MySQL には権限を拒否する方法がないため (そもそも権限を取り消すことや、付与しないことはできますが、それ自体を拒否することはできません)、ある SQL ノード上の NDB テーブルを別の SQL ノードに対する権限を持つユーザーから保護する特別な手段がありません。このことは、ユーザー権限の自動配布を使用していない場合でも当てはまります。これを示す明確な例として、任意のデータベースオブジェクトに対して任意のアクションを実行できる MySQL の root アカウントが挙げられます。このアカウントを config.ini ファイルの空の [mysqld] または [api] セクションと組み合わせると、著しく危険になる可能性があります。その理由を理解するために、次のようなシナリオを検討します。

  • config.ini ファイルには、少なくとも 1 つの空の [mysqld] または [api] セクションが含まれています。つまり、MySQL Cluster 管理サーバーで、MySQL サーバー (またはその他の API ノード) から MySQL Cluster へのアクセス元のホストのチェックが実行されません。

  • ファイアウォールが存在しないか、またはファイアウォールがネットワーク外部にあるホストから MySQL Cluster へのアクセスに対する保護に失敗します。

  • MySQL Cluster の管理サーバーのホスト名または IP アドレスは既知であるか、またはネットワーク外部から特定できます。

これらの条件に当てはまる場合は、だれでも、どこからでも --ndbcluster --ndb-connectstring=management_host を付けて MySQL Server を起動し、この MySQL Cluster にアクセスできます。MySQL root アカウントを使用すると、このユーザーは次のアクションを実行できます。

  • SHOW DATABASES ステートメント (サーバー上のすべての NDB データベースのリストを取得する) または SHOW TABLES FROM some_ndb_database ステートメントなどのメタデータステートメントを実行して、特定のデータベース内のすべての NDB テーブルのリストを取得します。

  • 検出されたテーブルのいずれかに対して、次のような正当な MySQL ステートメントを実行します。

    • 任意のテーブルからすべてのデータを読み取る SELECT * FROM some_table

    • テーブルからすべてのデータを削除する DELETE FROM some_table

    • テーブルスキーマを確認する DESCRIBE some_table または SHOW CREATE TABLE some_table

    • テーブルカラムに不正データを入力する UPDATE some_table SET column1 = some_value。これは実際に、単にすべてのデータを削除するよりも、はるかに大きな損害が発生する可能性があります

      より狡猾なバリエーションには、次のようなステートメントが含まれることがあります。

      UPDATE some_table SET an_int_column = an_int_column + 1

      または

      UPDATE some_table SET a_varchar_column = REVERSE(a_varchar_column)

      このような悪意のあるステートメントは、攻撃者の想像力でしか制限されません。

    このような種類の攻撃を受けるおそれのない唯一のテーブルは、NDB 以外のストレージエンジンを使用して作成され、そのために不正な SQL ノードから見えないテーブルです。

    また、root としてログインできるユーザーは INFORMATION_SCHEMA データベースおよびそのテーブルにアクセスすることもできるため、データベース、テーブル、ストアドルーチン、スケジュール済みのイベント、およびメタデータが INFORMATION_SCHEMA に格納されているその他のデータベースオブジェクトに関する情報を取得できます。

    また、配布された権限を使用していなければ、MySQL Cluster SQL ノードごとに異なる root アカウントのパスワードを使用することも非常に適切な方法です。

要するに、MySQL Cluster がローカルネットワーク外部から直接アクセスできる場合は、安全性を確保できません。

重要

MySQL の root アカウントのパスワードは空のままにしないでください。これは、MySQL を、MySQL Cluster SQL ノードとして実行している場合も、スタンドアロン (非クラスタ) MySQL サーバーとして実行している場合もまったく同じように当てはまり、MySQL インストールプロセスの一部として、MySQL サーバーを MySQL Cluster の SQL ノードとして構成する前に実行するようにしてください。

MySQL Cluster の権限の配布機能を使用する場合は、単に NDB ストレージエンジンを使用するように、mysql データベース内のシステムテーブルを手動で変換しないでください。代わりに、この目的のために提供されているストアドプロシージャーを使用してください。セクション18.5.14「MySQL Cluster の配布された MySQL 権限」を参照してください。

それ以外の場合、SQL ノード間で mysql システムテーブルを同期する必要がある場合は、標準の MySQL レプリケーションを使用してこれを実行することも、スクリプトを使用して MySQL サーバー間でテーブルエントリをコピーすることもできます。

サマリー  次に、MySQL Cluster に関して、MySQL 権限システムについて覚えておくべきもっとも重要な点を示します。

  1. ある SQL ノード上で確立されたユーザーおよび権限は、クラスタ内のその他の SQL ノードで自動的に存在することも、有効になることもありません。逆に、クラスタ内のある SQL ノード上のユーザーまたは権限を削除しても、その他の SQL ノードからユーザーまたは権限は削除されません。

  2. SQL スクリプトおよびそれに含まれる、MySQL Cluster 配布でこの目的で提供されているストアドプロシージャーを使用して、複数の MySQL ノード間で SQL ユーザーおよび権限を配布できます。

  3. MySQL Cluster 内のある SQL ノードから、MySQL ユーザーに NDB テーブルに対する権限が付与されると、権限配布を使用していない場合でも、そのユーザーは、データの生成元の SQL ノードに関係なく、そのテーブル内のどのデータも参照できます。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.