MySQL セキュリティ ガイド (2) (リダイレクト)

mysql|セキュリティ|セキュリティ

MySQL セキュリティ ガイド (2)

発行日: 2000-5-10
内容:
---------------------------- -------------------------------------------------- -- -

MySQL セキュリティ ガイド (2)

著者: Yan Zi


2.1.3 データベースとテーブルの権限
次の権限はデータベースとテーブルの操作に適用されます。

ALTER
を使用すると、ALTER TABLE ステートメントを使用できます。これは、実際には、データベースに対して実行する操作に応じて、他の権限が必要です。
CREATE
を使用すると、データベースとテーブルを作成できますが、インデックスは作成できません。
DELETE
を使用すると、テーブルから既存のレコードを削除できます。
DROP
を使用すると、データベースとテーブルを削除 (破棄) できますが、インデックスは削除できません。
INDEX
を使用すると、インデックスを作成および削除できます。
参考資料
現在は使用されていません。
SELECT
を使用すると、SELECT ステートメントを使用してテーブルからデータを取得できます。 SELECT NOW() や SELECT 4/2 など、テーブルを含まない SELECT ステートメントの場合は必要ありません。
UPDATE
を使用すると、テーブル内の既存のレコードを変更できます。
2.1.4 管理権限
次の権限は、サーバーの操作またはユーザー認証機能を制御する管理操作に使用されます。

FILE
を使用すると、サーバーホスト上のファイルの読み取りまたは書き込みをサーバーに指示できます。この権限は安易に付与すべきではありません。危険です。「権限テーブルのリスクの回避」を参照してください。サーバーは、この権限を制限内に保つためにある程度の注意を払います。誰でも読み取り可能なファイルのみを読み取ることができます。書き込み中のファイルは存在してはなりません。これにより、/etc/passwd や他の人のデータベースに属するデータ ディレクトリなどの重要なファイルをサーバーに強制的に書き換えることができなくなります。
ファイル権限を付与する場合は、サーバーを UNIX root ユーザーとして実行していないことを確認してください。これは、root はファイル システムのどこにでも新しいファイルを作成できるためです。サーバーを特権のないユーザーとして実行する場合、サーバーはユーザーがアクセスできるディレクトリにのみファイルを作成できます。

GRANT
を使用すると、GRANT を含む自分の権限を他の人に付与できます。
PROCESS
を使用すると、SHOW PROCESS ステートメントまたは mysqladmin process コマンドを使用して、サーバー内で実行されているスレッド (プロセス) に関する情報を表示できます。この権限により、KILL ステートメントまたは mysqladmin kill コマンドを使用してスレッドを強制終了することもできます。
いつでも自分のスレッドを表示したり、強制終了したりできます。 PROCESS 権限により、任意のスレッドでこれらの操作を実行できるようになります。

RELOAD
を使用すると、幅広いサーバー管理操作を実行できます。 FLUSH ステートメントを発行できます。また、mysqladmin の reload、refresh、flush-hosts、flush-logs、flush-privileges、および flash-tables コマンドを参照することもできます。
SHUTDOWN
を使用すると、mysqladmin shutdown を使用してサーバーをシャットダウンできます。
user、db、host テーブルでは、各権限は個別の列で指定されます。これらの列はすべて ENUM ("N", "Y") 型として宣言されているため、各重みのデフォルト値は "N" です。 tables_priv および columns_priv の権限は SET によって表され、単一の列と任意の組み合わせで権限を指定できます。これら 2 つのテーブルは他の 3 つのテーブルより新しいため、より効率的な表現が使用されます。 (将来的には、user、db、および host テーブルも SET タイプで表される可能性があります。)

tables_priv テーブルの Table_priv 列は、次のように定義されます:

SET('Select','Insert' ,'Update',' Delete','Create','Drop','Grant','References','Index','Alter')
coloums_priv テーブルの Column_priv 列は次のように定義されます:

SET(' Select','Insert' ,'Update','References')
列の権限はテーブルの権限よりも低くなります。これは、より少ない列レベルの権限が合理的であるためです。たとえば、テーブルを作成することはできますが、独立した列を作成することはできません。

ユーザー テーブルには、他の認可テーブルには存在しない特定の権限列 (File_priv、Process_priv、Reload_priv、Shutdown_priv) が含まれています。これらのアクセス許可は、特定のデータベースやテーブルに関連しない、サーバーに実行を要求する操作に適用されます。現在のデータベースの内容に基づいてユーザーがデータベースを閉じることを許可するのは意味がありません。

2.2 サーバーがクライアント アクセスを制御する方法
MySQL を使用する場合、クライアント アクセス制御には 2 つの段階があります。最初のフェーズは、サーバーに接続しようとしたときに発生します。サーバーはユーザー テーブルを調べて、ユーザーの名前、接続元のホスト、および指定したパスワードに一致するエントリが見つかるかどうかを確認します。一致しない場合は接続できません。一致するものがあれば、接続を確立し、第 2 フェーズに進みます。このフェーズでは、発行するクエリごとに、サーバーは認可テーブルをチェックして、クエリを実行するための十分な権限があるかどうかを確認します。第 2 フェーズは、サーバーとの会話が終了するまで続きます。

このセクションでは、認証テーブルのエントリを受信した接続リクエストまたはクエリに一致させるために MySQL サーバーが使用する原則について詳しく説明します。これには、認証テーブルの範囲列の正当な値の種類、権限情報を組み合わせる方法が含まれます。権限テーブルとエントリがチェックされる順序。

2.2.1 範囲列の内容
一部の範囲列にはリテラル値が必要ですが、ほとんどの列ではワイルドカードまたはその他の特別な値が許可されます。

ホスト
[ホスト] 列の値には、ホスト名または IP アドレスを指定できます。値 localhost はローカルホストを意味しますが、ホスト名を使用した場合ではなく、ローカルホストのホスト名を使用した場合にのみ一致します。ローカル ホスト名が pig.snake.net で、ユーザー テーブルに 2 つのレコードがあり、1 つはホスト値または localhost で、もう 1 つは pig.snake.net である場合、localhost のレコードは次のように扱われます。これは localhost に接続した場合に一致し、他のものは pig.snake.net に接続した場合にのみ一致します。クライアントが 2 つの方法で接続できるようにするには、ユーザー テーブルに 2 つのレコードが必要です。

ワイルドカードを使用してホスト値を指定することもできます。 SQL パターン文字「%」および「_」を使用でき、クエリで LIKE 演算子を使用する場合と同じ意味になります (正規表現演算子は使用できません)。 SQL パターン文字は、ホスト名と IP アドレスの両方に使用できます。たとえば、%wisc.edu は wisc.edu ドメイン内の任意のホストに一致し、%.edu は College of Education 内の任意のホストに一致します。同様に、192.168.% は 192.168 クラス B サブネット上の任意のホストに一致し、192.168.3.% は 192.168.3 クラス C サブネット上の任意のホストに一致します。

% 値はすべてのホストに一致し、ユーザーがどこからでも接続できるようにするために使用できます。空白のホスト値は % に相当します。 (例外: DB テーブルで、空白の Host 値は「ホスト テーブルをさらに確認する」ことを意味します。このプロセスは「クエリ アクセスの検証」で紹介されています。)

MySQL 3.23 以降では、次の値に基づいて IP アドレスを指定することもできます。 192.168.128.0/17 などのネットワーク アドレスのネットマスクは 17 ビットのネットワーク アドレスを指定し、IP アドレスが 192.168128 の最初の 17 桁であるホストと一致します。

ユーザー
ユーザー名はテキストまたは空白にする必要があります。空白の値は任意のユーザーと一致します。ユーザー値としての % は空白を意味するのではなく、リテラルの % 名と一致しますが、これはおそらくあなたが望むものではありません。

受信接続がユーザー テーブルを通じて認証され、一致するレコードに空のユーザー値が含まれている場合、クライアントは匿名ユーザーとみなされます。

パスワード
パスワード値は空でも空以外でもかまいません。ワイルドカードは使用できません。空のパスワードは、どのパスワードでも一致するという意味ではなく、ユーザーがパスワードを指定する必要がないことを意味します。

パスワードはリテラルテキストではなく、暗号化された値として保存されます。 「パスワード」列に文字通りのパスワードを保存すると、ユーザーは接続できなくなります。 GRANT ステートメントと mysqladminpassword コマンドはパスワードを自動的に暗号化しますが、INSERT、REPLACE、UPDATE、SET PASSWORD などのコマンドを使用する場合は、単に "new_password" ではなく PASSWORD("new_password") を使用してパスワードを指定してください。 。

Db
columns_priv テーブルと tables_priv テーブルでは、Db 値は実際のデータベース名 (文字通り) である必要があり、パターンと空白は許可されません。 db および host では、Db 値を文字通り指定することも、SQL パターン文字「%」または「_」を使用してワイルドカードを指定することもできます。 「%」または空白は任意のデータベースに一致します。
Table_name、Column_name
これらの列の値は、リテラルのテーブル名または列名である必要があり、パターンと空白は許可されません。
一部の範囲列はサーバーによって大文字と小文字が区別されると見なされますが、残りは区別されません。これらの原則を以下の表にまとめます。特に、クエリ内のテーブル名の大文字と小文字の区別は、サーバーが実行されているホストのファイル システムによって異なりますが、Table_name の値は常に大文字と小文字が区別されるものとして扱われることに注意してください (UNIX では大文字と小文字が区別されますが、Windows では大文字と小文字が区別されません)。 ）。

表 3 認可テーブル範囲の列の大文字と小文字の区別
Column
Host
User
Password
Db
Table_name
Column_name
大文字と小文字の区別
No
Yes
Yes
Yes
Yes
No


2.2.2 クエリアクセス検証
クエリを発行するたびに、サーバーはクエリを実行するための十分な権限があるかどうかをチェックし、適切なアクセス権があると判断するか、すべてのテーブルを検索しても何も見つからないまで、user、db、tables_priv、columns_priv の順にチェックします。具体的には:

サーバーは、接続を開始したテーブルと一致するレコードがユーザー テーブルにあるかどうかを確認して、どのようなグローバル権限を持っているかを確認します。クエリに必要な情報があり、それらがクエリに十分であれば、サーバーはクエリを実行します。
グローバル権限が十分でない場合、サーバーはデータベーステーブルを検索し、レコード内の権限をグローバル権限に追加します。結果がクエリに対して十分である場合、サーバーはクエリを実行します。
グローバル レベルとデータベース レベルの権限を組み合わせた権限が不十分な場合、サーバーは引き続き最初に tables_priv テーブルを検索し、次に columns_priv テーブルを検索します。
すべてのテーブルをチェックした後も権限がない場合、サーバーはクエリの実行を拒否します。
ブール用語で言えば、認可テーブルの権限はサーバーによって次のように使用されます:

user OR tables_priv OR columns_priv

実際には 5 つの認可テーブルがあるのに、前の説明ではなぜ 4 つの認可テーブルしか参照していないのか疑問に思われるかもしれません。実際、サーバーは次のようにアクセス許可をチェックします:

user OR (db AND host) OR tables_priv OR columns_priv

最初の簡単な式は、ホスト テーブルが GRANT および REVOKE ステートメントの影響を受けないためです。ユーザー権限の管理に常に GRANT と REVOKE を使用する場合は、ホスト テーブルについて考える必要はありません。しかし、それがどのように機能するかを知っておく必要があります:

サーバーがデータベース レベルの権限をチェックするとき、クライアントの db テーブルを検索します。 [ホスト] 列が空の場合は、「ホスト テーブルをチェックしてデータベースにアクセスできるホストを確認する」ことを意味します。
サーバーは、ホスト テーブル内で、db テーブルのレコードと同じ DB 列の値を探します。クライアントのホストと一致するホスト レコードがない場合、データベース レベルのアクセス許可は付与されません。これらのレコードのいずれかに、接続されたクライアントのホストと一致するホスト列の値がある場合、db テーブル レコードとホスト テーブル レコードが結合されて、クライアントのデータベース レベルのアクセス許可が生成されます。
ただし、アクセス許可は論理 AND で結合されます。これは、特定のアクセス許可が両方のテーブルに存在しない限り、クライアントはそのアクセス許可を持たないことを意味します。このようにして、db テーブルで基本的な権限セットを付与し、ホスト テーブルを使用して特定のホストに対してそれらの権限を選択的に無効にすることができます。たとえば、ドメイン内のすべてのホストからのデータベース アクセスを許可し、安全性の低いゾーンにあるホストのデータベース アクセス許可をオフにすることができます。

上記の説明では、特にサーバーが発行するすべてのクエリに対して権限チェックを実行すると考えると、アクセス チェックがかなり複雑なプロセスのように聞こえるかもしれませんが、サーバーは実際には承認テーブルをチェックしないため、このプロセスは非常に高速です。代わりに、起動時にテーブルの内容をメモリに読み取り、クエリがメモリ内のコピーを使用していることを確認します。これにより、アクセスチェック操作のパフォーマンスが大幅に向上します。しかし、非常に明らかな副作用があります。権限テーブルの内容を直接変更すると、サーバーは権限の変更を認識できません。

たとえば、INSERT ステートメントを使用してユーザー テーブルに新しいレコードを追加して新しいユーザーを追加すると、レコード内で指定されたユーザーはサーバーに接続できなくなります。これは新しい管理者 (場合によっては経験豊富なベテラン) にとって混乱を招くものでしたが、当時の解決策は単純でした。許可テーブルの内容を変更した後にサーバーに再ロードするように指示することでした。FLUSH PRIVILEGES を送信するか、mysqladmin flash-privileges (または、フラッシュ権限をサポートしていない古いバージョンを使用している場合は、mysqladmin reload を使用してください。)

2.2.3 範囲列の一致順序
MySQL サーバーは、認可テーブル内のレコードを特定の方法でソートし、レコードを順番に参照して受信接続を一致させます。最初に見つかった一致によって、どのレコードが使用されるかが決まります。 MySQL、特にユーザーテーブルで使用されるソート順序を理解することが重要です。

サーバーがユーザーテーブルの内容を読み取るとき、ホスト列とユーザー列の値に従ってレコードを並べ替えます。ホスト値が決定的な役割を果たします（同じホスト値がまとめて配置されます）。ユーザー値に従ってソートされます)。ただし、ソートはアロディックな順序付け (単語による順序付け) ではなく、部分的にのみ行われます。覚えておくべきことは、文字通りの単語がパターンよりも優先されるということです。これは、client.your.net からサーバーに接続しており、Host に client.your.net と %.your.net という 2 つの値がある場合、最初の値が最初に選択されることを意味します。同様に、%.your.net は %.net よりも優先され、次に % が優先されます。 IP アドレスの照合についても同様です。

一言で言えば、優先順位がより具体的になるということです。例については、この記事の付録を参照してください。

2.3 認可テーブルのリスクを回避する
このセッションでは、認可時のいくつかの予防策と、不明な値の選択によって引き起こされるリスクについて紹介します。一般に、スーパーユーザー権限の付与は非常に「ケチ」にする必要があります。つまり、ユーザー テーブルのエントリで権限を有効にせず、他の権限テーブルを使用して、データベース、テーブル、または列に対するユーザー権限を制限する必要があります。ユーザー テーブルの権限により、サーバーの操作に影響を与える任意のデータベース内の任意のテーブルへのアクセスが許可されます。

mysql データベースにアクセス許可を与えないでください。認可テーブルを含むデータベースに対する権限を持つユーザーは、テーブルを変更して他のデータベースに対する権限を取得できます。ユーザーに mysql データベース テーブルの変更を許可する権限を付与すると、ユーザーにグローバル GRANT 権限も効果的に付与されます。ユーザーがテーブルを直接変更できる場合、これは想像できるあらゆる GRANT ステートメントを発行できることと同じです。

FILE 権限は特に危険です。簡単に許可しないでください。 FILE 権限を持つ人ができることは次のとおりです:

CREATE TABLE etc_passwd (pwd_entry TEXT);
LOAD DATA INFILE "/etc/passwd" into TABLE etc_passwd;
SELECT * FROM etc_passwd;

これらのステートメントを発行した後、ユーザーはすでにパスワード ファイルの内容が含まれています。実際、サーバー上の一般に読み取り可能なファイルの内容には、FILE 権限を持つユーザーがネットワーク経由でアクセスできます。

FILE 権限は、十分に制限的なファイル権限が設定されていないシステム上のデータベースを侵害するために悪用される可能性もあります。このため、サーバーのみが読み取りできるようにデータ ディレクトリを設定する必要があります。データベース テーブルに対応するファイルが、ユーザーのサーバー アカウントを持つユーザーだけでなく、誰でも読み取り可能な場合は、FILE 権限を持つユーザーもネットワーク経由で接続してファイルを読み取ることができます。このプロセスを以下に示します。

LONGBLOB 列を持つテーブルを作成します:
USER test;
CREATE TABLE tmp (b LONGBLOB);

このテーブルを使用して、作成したデータベース テーブルに対応する各データベース テーブル ファイルの内容を読み取ります。を盗んで、テーブルの内容を自分のデータベースのファイルに書き込みたい:

LOAD DATA INFILE "./other_db/x.frm" INTO TABLE tmp
FIELDS ESCAPED BY "" LINES TERMINATED BY "";
SELECT * FROM tmp INTO OUTFILE "y.frm"
フィールドは "" でエスケープされています 行は "" で終了しています;
DELETE FROM tmp;
LOAD DATA INFILE "./other_db/x.ISD" INTO TABLE tmp
FIELDS ESCED BY "" LINES TERMINATED BY "";
SELECT * FROM tmp INTO OUTFILE "y.ISD"
FIELDS ESCAPED BY "" LINES TERMINATED BY "";
DELETE FROM tmp;
LOAD DATA INFILE "./other_db/x.ISM" INTO TABLE tmp
FIELDS ESCAPED BY "" LINES TERMINATED BY "";
SELECT * FROM tmp INTO OUTFILE "y.ISM "
これで、other_db.x の内容を含む新しいテーブル y が作成され、それに完全にアクセスできるようになりました。
他の人が同じように攻撃するのを防ぐには、「パート 1 内部セキュリティ - データ ディレクトリの保護」の手順に従って、データ ディレクトリにアクセス許可を設定します。サーバーの起動時に --skip-show-database オプションを使用して、ユーザーがアクセス権のないデータベースに対して SHOW DATABASES および SHOW TABLES を使用することを制限することもできます。これにより、ユーザーがアクセスできないデータベースやテーブルに関する情報を見つけることができなくなります。

ALTER 権限は意図しない方法で使用される可能性があります。 user1 には table1 にはアクセスできるが、table2 にはアクセスできないようにしたいとします。 ALTER 権限を持つユーザーは、ALTER TABLE を使用して table1 の名前を変更することで、table2 を変更できます。

GRANT 権限に注意してください。異なる権限を持つ 2 人のユーザーが両方とも GRANT 権限を持っている場合、互いの権限を強化できます。