Mysql 権限システムの仕組み_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 17:23:20776ブラウズ
権限システムの仕組み MySQL 権限システムは、すべてのユーザーが、許可されていると想定されている内容を正確に実行できることを保証します。 MySQL サーバーに接続するとき、ユーザーの ID は接続元のホストによって決定され、ユーザーの ID と実行内容に基づいて権限が付与されます。特定のユーザーがインターネット上で同じ人物に属していると想定する理由はほとんどないため、MySQL はアイデンティティを決定する際にホスト名とユーザー名を考慮します。たとえば、ユーザーがwhitehouse.govから接続する請求書は、ユーザーがmosoft.comから接続する請求書と同じ人物である必要はありません。 MySQL は、異なるホスト上でたまたま同じ名前を持つユーザーを区別できるようにすることでこれを処理します。つまり、whitehouse.gov からの接続に対しては 1 つの権限セットを付与し、microsoft.com からの接続に対しては別の権限セットを付与することができます。 MySQL のアクセス制御は 2 つのフェーズで構成されます。 フェーズ 1: サーバーは接続を許可するかどうかを確認します。 フェーズ 2: 接続できると仮定すると、サーバーはユーザーのすべてのリクエストをチェックします。それを実装するのに十分な権限があるかどうかを確認してください。たとえば、データベース内のテーブルから行を選択するか、データベースからテーブルを削除すると、サーバーは、テーブルに対する選択権限またはデータベースに対する削除権限があると判断します。 サーバーは、アクセス制御の 2 段階で mysql データベースの user、db、および host テーブルを使用します。これらの認証テーブルのフィールドは次のとおりです。 テーブル名 user db host range フィールド Host Host Host User Db Db Password User Permission フィールド Select_priv Select_priv Select_priv Insert_priv Insert_priv Insert_priv Update_priv Update_priv Update_priv Delete_priv Delete_priv Delete_priv Index_priv Index_priv Index_priv Alter_priv Alter_priv Alter_priv Create_priv Create_priv Drop_priv Drop_priv Grant_priv Grant_priv Grant_priv Reload_priv Shutdown_priv Process_priv File_priv アクセス制御の第 2 フェーズ (リクエストの確認) では、リクエストにテーブルが含まれる場合、サーバーはさらに、tables_priv テーブルと columns_priv テーブルを参照できます。これらのテーブルのフィールドは次のとおりです。 テーブル名 tables_priv columns_priv スコープ フィールド Host Host Db Db User User Table_name Table_name Column_name Permission フィールド Table_priv Column_priv Column_priv その他のフィールド Timestamp Timestamp Grantor 各許可テーブルには、スコープ フィールドと権限フィールドが含まれます。 スコープ フィールドは、テーブル内の各エントリのスコープ、つまりエントリが適用されるコンテキストを決定します。たとえば、thomas.loc.gov と bob の Host 値と User 値を持つユーザー テーブル エントリは、ホスト thomas.loc.gov からサーバーへの bob の接続を認証するために使用されます。同様に、db テーブル エントリの Host、User、および Db フィールドの値は thomas.loc.gov、bob であり、bob がホストから thomas.loc.gov に接続してレポート データベースにアクセスするときにレポートが使用されます。 tables_priv テーブルと columns_priv テーブルには、各エントリが適用されるテーブルまたはテーブルと列の組み合わせを示すスコープ フィールドが含まれています。 アクセスをチェックする目的で、ホスト値の比較では大文字と小文字が無視されます。 User、Password、Db、Table_name の値は大文字と小文字が区別されます。 MySQL 3.22.12 以降のバージョンでは、Column_name 値の大文字と小文字が区別されません。 権限フィールドは、テーブル エントリによって付与される権限、つまり実行できる操作を示します。サーバーは、さまざまな認証テーブルからの情報を組み合わせて、ユーザーの権限の完全な説明を形成します。これに使用されるルールについては、「6.8 アクセス制御、フェーズ 2: 認証の要求」で説明されています。 以下で説明するように、範囲フィールドは文字列です。各フィールドのデフォルト値は空の文字列です。 フィールド名 タイプ ホスト CHAR(60) ユーザー CHAR(16) パスワード CHAR(16) Db CHAR(64) (CHAR の tables_priv および columns_priv テーブル) (60)) user、db、および host テーブルでは、すべての権限フィールドが ENUM(N,Y) として宣言されます。それぞれのフィールドには値 N または Y を指定でき、デフォルト値は N です。 tables_priv および columns_priv では、テーブルでは、権限フィールドは SET フィールドとして宣言されます。 テーブル名 フィールド名 可能なセットメンバー tables_priv Table_priv 選択、挿入、更新、削除、作成、ドロップ、付与、参照、インデックス、変更 tables_priv Column_priv 選択、挿入、更新、参照 columns_priv Column_priv選択、挿入、更新、参照 簡単に言えば、サーバーは次のような承認テーブルを使用します。 ユーザー テーブルのスコープ フィールドは、受信接続を許可するか拒否するかを決定します。許可された接続の場合、権限フィールドはユーザーのグローバル (スーパーユーザー) 権限を示します。 db テーブルと host テーブルは一緒に使用されます。db テーブル範囲フィールドにより、ユーザーがどのホストからどのデータベースにアクセスできるかが決まります。権限フィールドは、どの操作が許可されるかを決定します。 ホスト テーブルは、特定の db エントリを複数のホストに適用する場合に、db テーブルの拡張として使用されます。たとえば、ユーザーがネットワーク上の複数のホストからデータベースを使用できるようにする場合は、ユーザーの db テーブルの Host エントリを NULL に設定し、それらの各ホストを hosts テーブルに移動します。このメカニズムについては、「6.8 アクセス制御、フェーズ 2: 認証の要求」で詳しく説明されています。 tables_priv テーブルと columns_priv テーブルは db テーブルに似ていますが、より洗練されており、データベース レベルではなくテーブルと列のレベルで適用されます。 管理権限 (リロード、シャットダウンなど) はユーザー テーブルでのみ指定されることに注意してください。これは、管理操作はサーバー自体の操作であり、データベース固有のものではないため、そのような権限を他の権限テーブルにリストする理由がないからです。実際、ユーザー テーブルを参照するだけで、管理操作を実行するかどうかを判断できます。ファイル権限もユーザー テーブルでのみ指定されます。これは管理者権限ではありませんが、サーバー ホスト上のファイルを読み取ったりアクセスしたりする能力は、アクセスしているデータベースには依存しません。mysqld サーバーが起動すると、認可テーブルの内容が 1 回読み取られます。権限テーブルへの変更は、「6.9 権限の変更が有効になる時期の説明」で有効になります。 権限テーブルの内容を変更する場合は、権限設定を希望どおりに変更することをお勧めします。問題の診断に役立つように、「6.13 「アクセス拒否が原因」エラーの原因」を参照してください。セキュリティ問題に関するアドバイスについては、「6.14 復号専門家に対して MySQL を安全にする方法」を参照してください。 有用な診断ツールは、Carlier Yves が MySQL ディストリビューション用に提供する mysqlaccess スクリプトです。 --help オプションを使用して mysqlaccess を呼び出し、その仕組みを確認してください。注: mysqlaccess は、user、db、および host テーブルを使用してアクセスのみをチェックします。テーブルまたは列レベルの権限はチェックされません。 6.7 アクセス制御、フェーズ 1: 接続の検証 MySQL サーバーに接続しようとすると、サーバーはユーザーの ID と、正しいパスワードを入力して ID を認証できるかどうかに基づいて接続を受け入れるか拒否します。そうでない場合、サーバーはアクセスを完全に受け入れます。そうでない場合、サーバーは接続を受け入れ、フェーズ 2 に入り、リクエストを待ちます。 あなたの ID は 2 つの情報に基づいています: MySQL ユーザー名から接続しているホスト ID チェックは、3 つのユーザー テーブル (ホスト、ユーザー、パスワード) スコープ フィールドを使用して実行されます。サーバーは、ユーザー テーブルのエントリがホスト名とユーザー名に一致し、正しいパスワードを入力した場合にのみ接続を受け入れます。 ユーザー テーブルの範囲フィールドは次のように指定できます。 Host 値にはホスト名または IP 番号を指定できます。あるいは、localhost はローカル ホストを示します。 「ホスト」フィールドでは、ワイルドカード文字「%」および「_」を使用できます。Host 値 % は任意のホスト名と一致し、空白の Host 値は % と同等です。これらの値を一致させると、任意のホストからサーバーへの接続が作成される可能性があることに注意してください。 「ユーザー」フィールドではワイルドカード文字は使用できませんが、任意の名前と一致する空白の値を指定できます。着信接続に一致するユーザー テーブル エントリのユーザー名が空白の場合、そのユーザーは、クライアントによって実際に割り当てられた名前ではなく、匿名ユーザー (名前のないユーザー) とみなされます。これは、接続中 (つまり、フェーズ 2 の間) のさらなるアクセス チェックに空白のユーザー名が使用されることを意味します。 「パスワード」フィールドは空白でもかまいません。これは、任意のパスワードと一致するという意味ではなく、ユーザーはパスワードを指定せずに接続する必要があることを意味します。 空白以外のパスワード値は、暗号化されたパスワードを表します。 MySQL はパスワードを誰でも読み取れるプレーン テキスト形式で保存せず、接続しようとしているユーザーが提供したパスワードを (PASSWORD() 関数を使用して) 暗号化し、ユーザー テーブルに保存されている暗号化バージョンと比較します。一致する場合、パスワードは正しいです。 次の例は、ユーザー テーブルのホスト エントリとユーザー エントリの値のさまざまな組み合わせが受信接続にどのように適用されるかを示しています。 ホスト値とユーザー値がエントリによって一致する接続 thomas.loc.gov fred fred,connections thomas.loc.gov から thomas へ .loc.gov 任意のユーザー、thomas.loc.gov から接続 % fred fred、任意のホストから接続 % 任意のユーザー、任意のホストから接続 %.loc.gov fred fred、x.y.% から接続loc.gov ドメイン内の任意のホスト fred fred、x.y.net、x.y.com、x.y.edu などから接続します。 (役に立たない可能性があります) 144.155.166.177 fred fred、IP アドレスのホストから接続 144.155.166.177 144.155.166.% fred fred、144.155.166 クラス C サブネット上の任意のホストから接続 IP ワイルドカードを使用できるため[ホスト] フィールドの値 (たとえば、144.155.166.% はサブネット上のすべてのホストに一致します) では、誰かがホストに 144.155.166.somewhere.com という名前を付けてこの機能を探索しようとする可能性があります。このような試みを防ぐために、MySQL では数字とドットで始まるホスト名の一致を許可しないため、1.2.foo.com のような名前のホストを使用する場合、その名前は認可テーブルの Host 列と一致しません。 IP ワイルドカード値と一致できる IP 番号は 1 つだけです。 着信接続は、ユーザー テーブル内の複数のエントリと一致する可能性があります。たとえば、thomas.loc.gov からの fred による接続は、上で説明したように複数のエントリと一致します。複数の一致が発生した場合、サーバーは使用するエントリをどのように選択しますか?サーバーは、起動時にユーザー テーブルを読み取った後にソートすることでこの問題を解決し、ユーザーが接続しようとすると、ソートされた順序でエントリが参照され、最初に一致したエントリが使用されます。ユーザー テーブルが次のようになっていると仮定すると、ユーザー テーブルの並べ替えは次のように機能します。 +-------+----------+- | ルート | localhost | | ... +----------+----------+- サーバーはテーブルを読み取るときに、最も具体的なホスト値の順に並べ替えます。最初に (ホスト列の % は「任意のホスト」を意味し、最も具体的ではありません)。同じ Host 値を持つエントリは、最も具体的な User 値から順に並べられます (空白の User 値は「任意のユーザー」を意味し、最も具体的ではありません)。最終的にソートされたユーザー テーブルは次のようになります。 | ローカルホスト | % | ----------+----------+- 接続が試行されると、サーバーは並べ替えられたエントリを調べて、最初に見つかった一致を使用します。 jeffrey による localhost からの接続の場合、「Host」列の localhost エントリーが最初に照合されます。ユーザー名が空白のエントリは、接続されたホスト名とユーザー名と一致します。 (%/jeffrey エントリも一致しますが、テーブル内の最初の一致にはなりません。) 別の例を次に示します。ユーザー テーブルが次のようになっているとします。 -------------+----------+- | トーマス.loc.gov | ------------+----------+- ソートされたテーブルは次のようになります: +-------------- - -+ ----------+- | ホスト ユーザー | +-----+---------- +- | トーマス.loc.gov ... +-----+------+ - jeffrey による thomas.loc.gov からのリンクが最初のエントリと一致しました、