PostgreSQL / 認証と認可
PostgreSQL における認可と認証の入門
はじめに
システムとデータへのアクセスを制御することは、データのセキュリティと整合性を維持するために不可欠です。PostgreSQL はこれらの懸念を管理するのに役立つ多くの機能を提供しており、それらがどのように機能するかを学ぶことは、データベースを管理する上で重要な部分です。
リソースへのアクセスを制御し、どのエンティティに対して誰が何を行うことができるかを定義する領域は、認証と認可として知られています。このガイドでは、PostgreSQL がシステムへのアクセスとその内部を制御するために提供するツールを探求し、各コンポーネントとそれらがサポートする全体的な機能の概要を提供することを目的としています。
認証と認可とは？
PostgreSQL が提供する具体的なツールに飛び込む前に、認証と認可が正確には何であり、なぜ重要なのかを確認することは役立ちます。
認証とは？
認証とは、ID を検証するプロセスです。コンピューティングでは、これは通常、ユーザーまたはエンティティが本人であると主張していることを確認することを意味します。
認証は通常、ユーザーが知っている秘密の何か（パスワードなど）、持っている固有の何か（携帯電話の認証アプリのコードなど）、または固有の身元の特徴である何か（指紋認証など）を提供するよう求めることを伴います。
ユーザーの身元を証明する一般的な方法には以下があります
- パスワード
- 秘密鍵
- セキュリティ証明書
- ソフトウェアまたはハードウェアトークン
- 指紋認証
認証は、ほとんどすべてのマルチユーザーシステムにとって重要な要件です。異なる人々やエンティティ（自動化ツールなど）は異なる機能とデータへのアクセスを必要とし、ID の確立はクライアントに個別化されたエクスペリエンスを提供する第一歩です。認証は、システム内のアカウントが、それが表すはずの現実世界の人物やエンティティによってのみ使用可能であることを確認する方法です。
認可とは？
認証が ID の検証に関心がある一方で、認可は、それらの ID やアカウントに関連付けられた機能を制御することに焦点を当てています。誰であるかがわかれば、認可機能がその人物ができることを決定します。
認可ポリシー内の定義は通常、3つのコンポーネントで構成されます
- 主体：アクションを実行するユーザー、アカウント、またはID
- アクション：実行される特定の機能または活動
- オブジェクト：アクションの対象となるリソース、エンティティ、またはスコープ
認可ポリシーは、システムが提供する制御レベルに応じて、広範な一般ルールだけでなく、特定の詳細な例外も定義できます。一部のポリシーは、個々のユーザーではなく、ユーザーの「クラス」または「ロール」に機能をマッピングして、設定された認可レベルを確立します。
認可とは、システムが誰であるかに基づいて機能やリソースへのアクセスをロックダウンできるメカニズムです。そのため、ユーザー管理、リソース管理、セキュリティと重要な関係があります。
PostgreSQL は認証と認可をどのように構成するか？
PostgreSQL には、ユーザーアクションを認証および認可するためのアクセス管理要件を共に満たす、相互に関連するいくつかの概念があります。これらの概念は連携して、クライアントが誰の代理であるか、そして PostgreSQL 内で何ができるかを確立します。
要するに、PostgreSQL はデータベースクラスターへのユーザーの認証と認可に以下のフレームワークを使用します
- ユーザーとユーザークラスは、システム内でロールとして定義されます。
- ロールへの認証方法は、
pg_hba.confファイル（ホストベース認証ファイル）で定義されます。 - ロールの機能とアクセスレベルは、直接的、ロールメンバーシップを通じて、またはオブジェクトの所有権を通じて付与される権限によって定義されます。
これら3つの相互に関連する領域をより深く探求することで、それぞれが PostgreSQL のアクセス管理機能にどのように貢献しているかを学ぶのに役立ちます。
ロール
PostgreSQL には、ユーザーとグループを表現するための個別のエンティティがありません。代わりに、ユーザーアカウントとユーザーグループの両方が、ロールと呼ばれる単一の統一された概念として実装されています。ロールは、個々のユーザーとユーザーグループの両方を表現するために使用される柔軟なIDです。
ロールは、PostgreSQL 内で認証および認可ポリシーが誰に適用されるかを決定するアンカーポイントです。普遍的に適用されないポリシーは、制限する対象と許可する対象を定義するための ID の概念を必要とします。PostgreSQL データベースへの各接続は、その初期アクセスレベルを決定する特定のロールに関連付けられています。
認可ポリシーは、各ロールがデータベースクラスター内で持つ権限を決定します。これには、実行できるコマンド、アクセスできるリソース、使用できる機能が含まれます。ユーザーはこれらの権限にアクセスするためにロールに認証します。
管理者は、メンバーが「コンテナ」ロールの権限にアクセスできるように、ロールを他のロールのメンバーにすることができます。この柔軟性により、一部のロールをユーザーアカウントの類似物として扱い、他のロールをユーザーグループ、クラス、または職務の類似物として扱うことができます。
単一のロールは、より複雑なポリシーを実装するために、コンテナとしてもメンバーとしても機能できます。一般に、ユーザーエージェントとして使用されることを意図したロールは、独自の権限、所属するロールの権限、および所有するオブジェクトによって認可レベルが決定される、定義された認証ポリシーを持ちます。対照的に、グループとして機能することを意図したロールには、通常、関連する認可はありません。
ロール専用の記事では、PostgreSQL 内でロールを定義および構成する方法について説明しています。
pg_hba.conf ファイル
pg_hba.conf ファイルは、PostgreSQL 内で認証ポリシーを定義する主要なコンポーネントです。この文脈では、「HBA」は、PostgreSQL ホストへの接続が受け入れられるかどうかを決定するポリシーを参照して、ホストベース認証を表します。
pg_hba.conf ファイルを使用すると、管理者はマッチングシステムを通じて、きめ細かな認証要件を定義できます。接続は、認証ポリシーを使用すべきかどうかを判断するために、マッチング基準に対してテストされます。
ポリシーは、1行に1つずつ、空白で区切られたフィールドで定義されます。各ポリシーは、マッチング基準と認証要件を定義します。
マッチング基準は、次のような基準に対してチェックできます
- クライアントの接続方法
- 認証しようとしているロール
- アクセスしようとしているデータベース
- クライアントのIPアドレスとネットワークプロパティ
接続に一致する最初の認証ポリシーが認証に使用されます。PostgreSQL は、パスワードや証明書から、LDAP や RADIUS サーバーのような外部システムとの連携まで、さまざまなレベルの洗練度を持つ多種多様な認証方法を提供しています。
各接続に対して1つのポリシー（最初に一致するもの）しか参照されないため、ポリシーの特異性と順序を制御することは非常に重要です。不適切な順序付けは、クライアント接続が誤ったポリシーに一致することにつながり、ユーザーがシステムにアクセスできないようにしたり、意図せずに接続へのアクセスを許可したりする可能性があります。
PostgreSQL で効果的な 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 の認証と認可システムは、すべてをまとめて見ると最初は複雑に見えるかもしれません。しかし、システムの個々のコンポーネントはすべて明確に定義されており、ほとんどが単一の懸念事項に関連付けられています。これらのシステムがどのように連携して強力で柔軟なアクセス管理を実装しているかを理解することは、データベースとその中のデータを安全に保つために不可欠です。
