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

23.5.17.1 NDB Cluster のセキュリティーおよびネットワークの問題

このセクションでは、NDB Cluster に関連する基本的なネットワークセキュリティーの問題について説明します。 NDB Cluster 「「即時利用可能」」はセキュリティー保護されていないことを覚えておくことが非常に重要です。ユーザーまたはネットワーク管理者は、クラスタがネットワーク上で危険にさらされないように適切な手順を実行する必要があります。

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

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

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

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

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

  注記

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

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

• 任意の ndb_mgm クライアント

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

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

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

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

   図 23.28 ハードウェアファイアウォールを備えた NDB Cluster

   
   
   

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

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

   重要

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

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

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

   NDB Cluster のこのタイプのネットワーク設定を次に示します:

   図 23.29 ソフトウェアファイアウォールを備えた NDB Cluster

   
   
   

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

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

   表 23.66 ホストベースのファイアウォールクラスタ構成のノードタイプ

   ノードタイプ	許可されるトラフィック
   SQL ノードまたは API ノード	それは、管理ノードまたはデータノードの IP アドレスから (任意の TCP または UDP ポートを使用して) 発信されています。 それは、クラスタが存在し、アプリケーションで使用されているポート上にあるネットワーク内から発信されています。
   データノードまたは管理ノード	それは、管理ノードまたはデータノードの IP アドレスから (任意の TCP または UDP ポートを使用して) 発信されています。 それは、SQL ノードまたは API ノードの IP アドレスから発信されています。

   
   

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

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

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

   ハードウェアファイアウォールとソフトウェアファイアウォールを組み合わせて使用した NDB Cluster の可能なネットワーク配備の 1 つを次に示します:

   図 23.30 ハードウェアファイアウォールとソフトウェアファイアウォールの組み合わせを使用した NDB Cluster

   
   
   

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

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

NDB Cluster では、ノード間の通信用に多数のポートを開く必要があるため、分離されたネットワークを使用することをお勧めします。 これは、不要なトラフィックがクラスタに到達することを防ぐためのもっとも簡単な方法です。

注記

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

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