PostgreSQL / 認証と認可
PostgreSQLにおける認可と認証の概要
はじめに
システムとデータへのアクセスを制御することは、データのセキュリティと整合性を維持するために不可欠です。PostgreSQLは、これらの懸念事項を管理するのに役立つ多くの機能を提供しており、それらの仕組みを学ぶことは、データベース管理の重要な一部です。
リソースへのアクセスを制御し、誰がどのエンティティに何を実行できるかを定義することは、認証と認可として知られる分野です。このガイドでは、PostgreSQLがシステム内外へのアクセスを制御するために提供するツールを調査し、各コンポーネントとそれらがサポートする全体的な機能の概要を示すことを目的としています。
認証と認可とは？
PostgreSQLが提供する特定のツールについて掘り下げる前に、認証と認可が正確には何であり、なぜ重要なのかを再確認すると役立ちます。
認証とは？
認証とは、アイデンティティを検証するプロセスです。コンピューティングでは、これは一般に、ユーザーまたはエンティティが彼らが言う本人であることを検証することを意味します。
認証は一般に、ユーザーに、彼らが知っている秘密のもの（パスワードなど）、彼らが持っているユニークなもの（携帯電話の認証アプリからのコードなど）、または彼らのユニークなアイデンティティの機能であるもの（指紋認証など）を提供するように求めることを含みます。
ユーザーの身元を証明する一般的な方法には、次のようなものがあります。
- パスワード
- 秘密鍵
- セキュリティ証明書
- ソフトウェアまたはハードウェアトークン
- 指紋認証
認証は、ほぼすべてのマルチユーザーシステムにとって重要な要件です。異なる人々またはエンティティ（自動化ツールなど）は、異なる機能とデータへのアクセスを必要とし、身元を確立することは、クライアントに個別化されたエクスペリエンスを提供するための最初のステップです。認証は、システム内のアカウントが、それらが代表するはずの現実世界の人々またはエンティティのみが使用できることを確認する方法です。
認可とは？
認証がアイデンティティの検証に関係しているのに対し、認可は、これらのアイデンティティまたはアカウントに関連付けられた機能を制御することに焦点を当てています。誰が誰であるかがわかれば、認可機能は彼らが何ができるかを決定します。
認可ポリシー内の定義は、通常、3つのコンポーネントで構成されています。
- サブジェクト：アクションを実行するユーザー、アカウント、またはアイデンティティ
- アクション：実行される特定の機能またはアクティビティ
- オブジェクト：アクションの対象となるリソース、エンティティ、またはスコープ
認可ポリシーは、システムが提供する制御のレベルに応じて、広範で一般的なルールと、特定で粒度の細かい例外を定義できます。一部のポリシーでは、設定された認可レベルを確立するために、機能を個々のユーザーではなく、ユーザー「クラス」または「ロール」にマッピングします。
認可は、システムがあなたが誰であるかに基づいて、機能とリソースへのアクセスをロックダウンできるメカニズムです。そのため、ユーザー管理、リソース管理、およびセキュリティと重要な関係があります。
PostgreSQLはどのように認証と認可を設定するのか？
PostgreSQLには、ユーザーアクションを認証および認可するためのアクセス管理要件を満たす、相互に関連するいくつかの概念があります。これらの概念は連携して、クライアントが誰のエージェントであるか、およびPostgreSQL内で何ができるかを確立します。
要するに、PostgreSQLは、データベースクラスターへのユーザーを認証および認可するために、次のフレームワークを使用します。
- ユーザーとユーザー クラスは、システム内でロールとして定義されます。
- ロールへの認証方法は、
pg_hba.confファイル (ホストベースの認証ファイル) で定義されます。 - ロールの機能とアクセスレベルは、ロールに直接、ロールメンバーシップを通じて、またはオブジェクトの所有権を通じて付与される権限によって定義されます。
これら3つの相互に関連する領域をより深く探求することで、それぞれがPostgreSQLのアクセス管理機能にどのように貢献しているかを学ぶのに役立ちます。
ロール
PostgreSQLには、ユーザーとグループを表すための別個のエンティティはありません。代わりに、ユーザーアカウントとユーザーグループの両方が、ロールと呼ばれる単一の統合された概念として実装されています。ロールは、個々のユーザーとユーザーのグループの両方を表すために使用される柔軟なアイデンティティです。
ロールは、PostgreSQL内で認証および認可ポリシーが誰に適用されるかを決定するアンカーポイントです。普遍的に適用されないポリシーは、誰を制限し、誰を許可するかを定義するために、アイデンティティの概念を必要とします。PostgreSQLデータベースへの各接続は、初期アクセスレベルを決定する特定のロールに関連付けられています。
認可ポリシーは、データベースクラスター内で各ロールが持つ権限、つまり、実行できるコマンド、アクセスできるリソース、および使用できる機能を決定します。ユーザーは、これらの権限へのアクセス権を取得するためにロールに対して認証を行います。
管理者は、ロールを他のロールのメンバーにすることで、メンバーに「コンテナ」ロールの権限へのアクセス権を与えることができます。この柔軟性により、一部のロールをユーザーアカウントのアナログとして扱い、他のロールをユーザーグループ、クラス、または職務のアナログとして扱うことができます。
単一のロールは、より複雑なポリシーを実装するために、コンテナとメンバーの両方として機能できます。一般に、ユーザーエージェントとして使用することを目的としたロールには、定義された認証ポリシーがあり、それらの認可レベルは、自身の権限、メンバーであるロールの権限、および所有するオブジェクトによって決定されます。対照的に、グループとして機能することを目的としたロールは、通常、関連付けられた認可を持っていません。
ロールに特化した記事では、PostgreSQL内でロールを定義および構成する方法について説明しています。
pg_hba.conf ファイル
pg_hba.conf ファイルは、PostgreSQL内で認証ポリシーを定義する主要なコンポーネントです。このコンテキストでは、「HBA」は、PostgreSQLホストへの接続が受け入れられるかどうかを決定するポリシーを参照して、ホストベースの認証を意味します。
pg_hba.conf ファイルを使用すると、管理者は、マッチングシステムなどを通じて、粒度の細かい認証要件を定義できます。接続は、認証ポリシーを使用する必要があるかどうかを判断するために、マッチング基準に対してテストされます。
ポリシーは、1行に1つずつ、フィールドが空白で区切られて定義されます。各ポリシーは、マッチング基準と認証要件を定義します。
マッチング基準は、次のような基準に対してチェックできます。
- クライアントの接続方法
- 認証を試みているロール
- アクセスを試みているデータベース
- クライアントのIPアドレスとネットワークプロパティ
接続に一致する最初の認証ポリシーが認証に使用されます。PostgreSQLは、パスワードや証明書から、LDAP や RADIUS サーバーなどの外部システムとの連携まで、さまざまな洗練度レベルの認証方法を幅広く提供しています。
各接続に対して単一のポリシー（最初に一致するもの）のみが参照されるため、ポリシーの具体性と順序を制御することが非常に重要です。不適切な順序付けは、クライアント接続が誤ったポリシーに一致し、ユーザーがシステムにアクセスできなくなったり、誤って接続へのアクセスを許可したりする可能性があります。
効果的な pg_hba.conf ポリシーを構成する方法については、PostgreSQLでの認証の構成に関するガイドを参照してください。
PostgreSQLの権限およびロール属性システム
PostgreSQLの認可に関する話の最後の部分は、各ロールが何ができるかを定義する機能です。さまざまなロールが持つアクセスまたは制御のレベルを変更するメカニズムが多数あります。
ロール属性
PostgreSQLがロールの機能を変更できるようにする最初の方法は、ロール属性を使用することです。ロール属性は、ロールがデータベースクラスター全体で持つ権限を定義します。これらは主に、特別な管理者レベルの機能、またはアカウントの制限の程度を表すものです。
最も強力な属性は、superuser 属性であり、ロールにPostgreSQL内のすべての認可チェックをバイパスする機能を与え、事実上、システムを完全に制御できるようにします。他の属性は、createrole および createdb 属性を使用してロールとデータベースを作成する機能など、より狭く定義された権限を許可します。
属性は、ロールがシステムにアクセスすることを許可される方法にも影響を与える可能性があります。たとえば、最初の接続で認証できるようにするには、login 属性が必要です。同様に、ロールが作成できる同時接続の数を制御するために、connection limit を設定できます。
ロール属性は、ロールのグローバル機能を定義する主要な手段として機能します。
PostgreSQLは、データベース、テーブル、列などの特定のデータベースオブジェクトに関するロールの権限を決定するために、別のシステムを使用します。データベースオブジェクトとロールの関係は、ロールの所有権ステータスとロールに付与された権限の関数です。
オブジェクトの所有権
オブジェクトの所有権は、最初の決定要因です。デフォルトでは、ロールは自身で作成したオブジェクトを所有します。所有権により、オブジェクト自体を削除または変更する機能などの特別な権限を含め、オブジェクトへのフルアクセスが可能になります。所有していないオブジェクトを削除または変更できるのは、superuser ロールのみです。
各データベースオブジェクトには、所有者が1人だけいます。複数のロールにデータベースオブジェクトの所有者権限を持たせたい場合は、両方を単一のロールのメンバーにし、そのロールに所有権を与える必要があります。
付与されたオブジェクト権限
オブジェクトの所有者ではないロールには、PostgreSQLの権限付与システムを使用して、さまざまなレベルのアクセス権を付与できます。
権限は、GRANT および REVOKE コマンドで管理されます。 GRANT コマンドは、このコンテキストで使用すると、特定のデータベースオブジェクトのロールに権限を追加します。反対に、REVOKE コマンドは、ロールから同じ権限を削除します。
前述のように、オブジェクト自体を削除または変更できるのは、オブジェクトの所有者と superuser ロールのみです。ただし、オブジェクト内のデータまたは他のオブジェクトに対して、粒度の細かい権限を割り当てることができます。たとえば、テーブルの場合、SELECT、INSERT、UPDATE、および DELETE 権限は、ロールがそれぞれデータを表示、追加、変更、および削除できるかどうかを制御します。
使用可能な権限のタイプは、問題のデータベースオブジェクトによって異なります。たとえば、ロールがオブジェクトに関連する外部キー制約を作成できるようにする REFERENCES 権限は、テーブルまたはテーブル列オブジェクトでの使用に限定されています。たとえば、シーケンスに外部制約権限を定義しても意味がないためです。どの権限とデータベースオブジェクトを一緒に使用できるかの概要については、PostgreSQLの権限に関するドキュメントの表5.1と表5.2をご覧ください。
PostgreSQLの付与システムの使用方法の詳細については、PostgreSQL内での権限の管理に関するガイドをご覧ください。
結論
PostgreSQLの認証および認可システムは、全体として見ると最初は複雑に見えるかもしれません。ただし、システムの個々のコンポーネントはすべて明確に定義されており、主に単一の懸念事項に関連付けられています。これらのシステムがどのように連携して強力で柔軟なアクセス管理を実装するかを理解することは、データベースとそれに保持されているデータを安全に保つために不可欠です。
