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


18.5.11.1 MySQL Cluster のセキュリティーとネットワーク上の問題

このセクションでは、MySQL Cluster に関する基本的なネットワークセキュリティー上の問題について説明します。MySQL Cluster の出荷時状態はセキュアではないことを覚えておくことは、きわめて重要です。ユーザーやネットワーク管理者は、ネットワーク上のクラスタが危険にさらされる可能性がないように、適切なステップを実行する必要があります。

クラスタの通信プロトコルは本質的にセキュアではなく、クラスタ内のノード間の通信では暗号化や同様のセキュリティー対策が使用されません。ネットワークの速度および待機時間によって、クラスタの効率性が直接影響を受けるため、ノード間のネットワーク通信に SSL やその他の暗号化により、事実上通信速度が低下するので、そのようなスキームを採用することはお勧めしません。

MySQL Cluster への API ノードのアクセスを制御する際に、認証が使用されないことも事実です。暗号化と同様に、認証の要件を課すオーバーヘッドによって、クラスタのパフォーマンスが影響を受けることがあります。

さらに、クラスタへのアクセス時に、次のいずれに対するソース IP アドレスのチェックも実行されません。

  • config.ini ファイル内の空の [mysqld] または [api] セクションによって作成される空きスロットを使用している SQL ノードまたは API ノード

    つまり、config.ini ファイル内に空の [mysqld] または [api] セクションがある場合、管理サーバーのホスト名 (または IP アドレス) とポートを認識しているどの API ノード (SQL ノードを含む) でも、制約なしでクラスタに接続し、そのデータにアクセスできます。(このことおよび関連する問題についての詳細は、セクション18.5.11.2「MySQL Cluster と MySQL 権限」を参照してください。)

    注記

    config.ini ファイル内のすべての [mysqld] および [api] セクションに HostName パラメータを指定すると、クラスタへの SQL ノードおよび API ノードのアクセスに対していくらか制御できます。ただし、これは、これまで使用されていないホストからクラスタに API ノードを接続する場合、そのホスト名を含む [api] セクションを config.ini ファイルに追加する必要があることも意味します。

    詳細は、HostName パラメータについてのこの章のほかの場所で説明しています。API ノードで HostName を使用する構成例について、セクション18.3.1「MySQL Cluster の簡易テストセットアップ」も参照してください。

  • 任意の ndb_mgm クライアント

    つまり、管理サーバーのホスト名 (または IP アドレス) とポート (標準ポートでない場合) が指定された任意のクラスタ管理クライアントがクラスタに接続し、任意の管理クライアントコマンドを実行できます。これには、ALL STOPSHUTDOWN などのコマンドが含まれます。

このような理由により、ネットワークレベルでクラスタを保護する必要があります。もっとも安全なクラスタのネットワーク構成は、クラスタノード間の接続をその他のネットワーク通信から分離する構成です。これは、次の方法のいずれかによって実現できます。

  1. どのパブリックネットワークからも物理的に分離されたネットワーク上にクラスタノードを保持します。このオプションは、信頼性がもっとも高いですが、実装するコストももっとも高くなります。

    次に、このように物理的に分離されたネットワークを使用した MySQL Cluster の設定例を示します。

    ハードウェアファイアウォールで保護されたプライベートネットワーク上の MySQL Cluster

    この設定には、クラスタ管理サーバーおよびデータノードの 1 つのプライベート (実線の四角形) と、SQL ノードが存在する 1 つのパブリック (点線の四角形) の 2 つのネットワークがあります。(ギガビットスイッチは最高のパフォーマンスが実現されるため、これを使用して接続された管理ノードとデータノードを示しています。)どちらのネットワークも、ハードウェアファイアウォール (ネットワークベースのファイアウォールと呼ばれることもあります) によって外部から保護されています。

    SQL ノードでパケットの転送が許可されていなければ、パケットは SQL ノードを通過せずに、ネットワーク外部からクラスタの管理ノードまたはデータノードに到達できない (どのクラスタの内部通信も外部に到達できない) ため、このネットワーク設定がもっとも安全です。これは、当然、すべての SQL ノードをハッキングの試みに対して、セキュリティー保護する必要があることを意味します。

    重要

    潜在的なセキュリティーの脆弱性に関しては、SQL ノードとその他の MySQL サーバーとの間に相違はありません。MySQL サーバーをセキュリティー保護するために使用できる技法については、セクション6.1.3「攻撃者に対する MySQL のセキュアな状態の維持」を参照してください。

  2. 1 つ以上のソフトウェアファイアウォール (ホストベースのファイアウォールと呼ばれることもあります) を使用して、アクセスする必要のないネットワークの部分からクラスタまで通過するパケットを制御できます。このタイプの設定では、それがなければローカルネットワークの外部からアクセスできてしまう可能性のあるクラスタ内のすべてのホストに、ソフトウェアファイアウォールをインストールする必要があります。

    ホストベースのオプションは、実装するコストがもっとも低いですが、保護を提供するソフトウェアに完全に依存しているため、セキュアな状態を維持することがもっとも困難です。

    次に、MySQL Cluster に対するこのタイプのネットワーク設定の例を示します。

    ソフトウェアファイアウォールを使用してパブリックおよびプライベートのゾーンを作成するネットワーク上に配備された MySQL Cluster

    このタイプのネットワーク設定を使用することは、MySQL Cluster ホストの 2 つのゾーンが存在することを意味します。各クラスタホストは、クラスタ内のその他のすべてのマシンと通信できる必要がありますが、SQL ノードをホストしているマシン (点線の四角形) のみ、外部との接続を許可でき、データノードおよび管理ノードを含むゾーン内のマシン (実線の四角形) は、クラスタに含まれないすべてのマシンから分離する必要があります。クラスタを使用するアプリケーションとそれらのアプリケーションのユーザーには、管理ノードおよびデータノードホストへの直接アクセスを許可しないでください。

    これを実現するには、各クラスタホストコンピュータ上で実行されているノードのタイプに応じて、次の表に示す 1 つまたは複数のタイプにトラフィックを制限するソフトウェアファイアウォールを設定する必要があります。

    アクセスされるノードのタイプ 許可するトラフィック
    SQL ノードまたは API ノード
    • それは、管理ノードまたはデータノードの IP アドレスから (任意の TCP または UDP ポートを使用して) 発信されています。

    • それは、クラスタが存在し、アプリケーションで使用されているポート上にあるネットワーク内から発信されています。

    データノードまたは管理ノード
    • それは、管理ノードまたはデータノードの IP アドレスから (任意の TCP または UDP ポートを使用して) 発信されています。

    • それは、SQL ノードまたは API ノードの IP アドレスから発信されています。

    特定のノードタイプの、表に示した以外のトラフィックはすべて拒否されるべきです。

    ファイアウォール構成の仕様は、ファイアウォールアプリケーションごとに異なるため、このマニュアルのスコープ外です。iptables は非常に一般的で、信頼性の高いファイアウォールアプリケーションであるため、多くの場合に構成をより簡単にするためにフロントエンドとして APF とともに使用されます。このタイプまたは次の項目で説明する混在タイプの MySQL Cluster ネットワーク設定を実装するように選択した場合、採用するソフトウェアファイアウォールについて、ドキュメントを参照できます (するべきです)。

  3. ハードウェアとソフトウェアの両方を使用して (つまり、ネットワークベースとホストベースの両方のファイアウォールを使用して) クラスタをセキュリティー保護することで、最初の 2 つの方法を組み合わせたものを採用することもできます。これは、セキュリティーレベルとコストの両方の点で、最初の 2 つのスキームの中間に位置するものです。このタイプのネットワーク設定では、クラスタがハードウェアファイアウォールの背後に配置されますが、受信パケットは SQL ノードに到達するために、すべてのクラスタホストに接続しているルータを通過することが許可されます。

    次に、ハードウェアとソフトウェアの両方のファイアウォールを組み合わせて使用することで実現できる MySQL Cluster クラスタのネットワーク配備の一例を示します。

    ハードウェアファイアウォールとソフトウェアファイアウォールを組み合わせて使用して保護を提供する MySQL Cluster のネットワーク設定

    この場合、SQL ノードおよび API ノードへのトラフィックを除くすべての外部トラフィックを拒否し、アプリケーションで必要とするポート上でのみそれらのノードへのトラフィックを許可するように、ハードウェアファイアウォールにルールを設定できます。

どのネットワーク構成を使用する場合でも、クラスタのセキュリティーを維持するという観点からの目標は同じであることは忘れないでください。つまり、クラスタ内のノード間でもっとも効率的な通信を確保しながら、不要なトラフィックがクラスタに到達することを妨げます。

MySQL Cluster では、ノード間の通信を行うために多数のポートを開く必要があるため、推奨されるオプションは、分離されたネットワークを使用することです。これは、不要なトラフィックがクラスタに到達することを防ぐためのもっとも簡単な方法です。

注記

リモートで (つまり、ローカルネットワーク外部から) MySQL Cluster を管理する場合、これを実行する推奨される方法は、ssh や別のセキュアなログインシェルを使用して、SQL ノードホストにアクセスすることです。これにより、このホストから管理クライアントを実行して、クラスタ独自のローカルネットワーク内から管理サーバーに安全にアクセスできます。

ndb_mgm を使用して、クラスタが実行されているローカルネットワーク外部から直接クラスタを管理することは理論上可能ですが、推奨されていません。管理クライアントと管理サーバー間では認証も暗号化も行われないため、これはクラスタを管理するきわめてセキュアでない方法であり、遅かれ早かれ、ほぼ確実に危険にさらされます。


User Comments
Sign Up Login You must be logged in to post a comment.