このセクションでは、NDB Cluster に関連して MySQL 特権システムがどのように機能するか、および NDB Cluster をセキュアに保つためのこれの影響について説明します。
標準 MySQL 権限は、「NDB Cluster」テーブルに適用されます。 これには、データベース、テーブル、およびカラムのレベルで付与されるすべての MySQL 権限タイプ (SELECT 権限、UPDATE 権限、DELETE 権限など) が含まれます。 その他の MySQL サーバーの場合と同様に、ユーザーおよび権限の情報は mysql システムデータベースに格納されます。 NDB テーブル、このようなテーブルを含むデータベース、およびこのようなテーブル内のカラムに対する権限を付与および取り消すために使用される SQL ステートメントは、(その他の) MySQL ストレージエンジンを含むデータベースオブジェクトとの接続に使用される GRANT および REVOKE ステートメントとすべての点で同じです。 CREATE USER および DROP USER ステートメントについても、同じことが当てはまります。
デフォルトでは、MySQL 付与テーブルは MyISAM ストレージエンジンを使用することに注意してください。 このため、これらのテーブルは通常、NDB Cluster 内の SQL ノードとして機能する MySQL サーバー間で複製または共有されません。 言い換えると、デフォルトでは、ユーザーおよびそれらの権限を変更しても自動的に SQL ノード間に反映されません。 必要に応じて、NDB Cluster SQL ノード間での MySQL ユーザーおよび特権の自動配布を有効にできます。詳細は、セクション23.5.12「NDB_STORED_USER での分散 MySQL 権限」 を参照してください。
逆に、MySQL には権限を拒否する方法がないため (権限は最初の場所で取り消すことも付与しないこともできますが、拒否することもできません)、ある SQL ノード上の NDB テーブルに対する特別な保護はありません (これは、ユーザー権限の自動配布を使用していない場合でも当てはまります)。 これを示す明確な例として、任意のデータベースオブジェクトに対して任意のアクションを実行できる MySQL の root アカウントが挙げられます。 このアカウントを config.ini ファイルの空の [mysqld] または [api] セクションと組み合わせると、著しく危険になる可能性があります。 その理由を理解するために、次のようなシナリオを検討します。
config.iniファイルには、少なくとも 1 つの空の[mysqld]または[api]セクションが含まれています。 つまり、NDB Cluster 管理サーバーは、MySQL Server (またはほかの API ノード) が NDB Cluster にアクセスするホストのチェックを実行しません。ファイアウォールが存在しないか、ファイアウォールが NDB Cluster へのアクセスをネットワーク外部のホストから保護できません。
NDB Cluster 管理サーバーのホスト名または IP アドレスは既知であるか、ネットワークの外部から決定できます。
これらの条件が true の場合、だれでも --ndbcluster --ndb-connectstring= を使用して MySQL Server を起動し、この NDB Cluster にアクセスできます。 MySQL management_hostroot アカウントを使用すると、このユーザーは次のアクションを実行できます。
SHOW DATABASESステートメント (サーバー上のすべてのNDBデータベースのリストを取得する) またはSHOW TABLES FROMステートメントなどのメタデータステートメントを実行して、特定のデータベース内のすべてのsome_ndb_databaseNDBテーブルのリストを取得します。-
検出された任意のテーブルに対して、次のような有効な MySQL ステートメントを実行します:
任意のテーブルからすべてのデータを読み取る
SELECT * FROMsome_tableテーブルからすべてのデータを削除する
DELETE FROMsome_tableテーブルスキーマを確認する
DESCRIBEまたはsome_tableSHOW CREATE TABLEsome_table-
テーブルカラムに「不正」データを入力する
UPDATE。これは実際に、単にすべてのデータを削除するよりも、はるかに大きな損害が発生する可能性がありますsome_tableSETcolumn1=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に格納されているその他のデータベースオブジェクトに関する情報を取得できます。また、分散特権を使用していないかぎり、異なる NDB Cluster SQL ノード上の
rootアカウントに異なるパスワードを使用することをお勧めします。
つまり、ローカルネットワークの外部から直接アクセスできる場合は、安全な NDB Cluster を持つことはできません。
MySQL の root アカウントのパスワードは空のままにしないでください。 これは、NDB Cluster SQL ノードとして MySQL を実行している場合と同様に、スタンドアロン (非クラスタ) MySQL Server として実行している場合にも当てはまり、NDB Cluster で MySQL Server を SQL ノードとして構成する前に、MySQL インストールプロセスの一部として実行するようにしてください。
NDB Cluster 分散特権機能を採用する場合は、NDB ストレージエンジンを手動で使用するように mysql データベース内のシステムテーブルを変換するだけではありません。 代わりに、この目的のために提供されているストアドプロシージャーを使用してください。セクション23.5.12「NDB_STORED_USER での分散 MySQL 権限」を参照してください。
それ以外の場合、SQL ノード間で mysql システムテーブルを同期する必要がある場合は、標準の MySQL レプリケーションを使用してこれを実行することも、スクリプトを使用して MySQL サーバー間でテーブルエントリをコピーすることもできます。
サマリー. NDB Cluster に関する MySQL 特権システムについて覚えておくべきもっとも重要な点を次に示します:
ある SQL ノード上で確立されたユーザーおよび権限は、クラスタ内のその他の SQL ノードで自動的に存在することも、有効になることもありません。 逆に、クラスタ内のある SQL ノード上のユーザーまたは権限を削除しても、その他の SQL ノードからユーザーまたは権限は削除されません。
NDB Cluster 配布でこの目的のために提供されている SQL スクリプトとそれに含まれているストアドプロシージャーを使用して、MySQL ユーザーおよび権限を SQL ノード間で配布できます。
NDB Cluster 内のある SQL ノードから
NDBテーブルに対する権限が MySQL ユーザーに付与されると、そのユーザーは、権限配布を使用していない場合でも、データの元となった SQL ノードに関係なく、そのテーブル内の任意のデータを「「参照」」できます。