このページでは、Generic Security Services Application Programming Interface(GSSAPI)を使用して AlloyDB Omni で PostgreSQL が Active Directory と統合される仕組みについて説明し、Kerberos の主なコンセプトを紹介します。Kerberos は、Active Directory を支える認証プロトコルです。
Active Directory は、Microsoft が Windows ドメイン ネットワーク用に開発したディレクトリ サービスです。Active Directory は、ユーザーデータ、セキュリティ、分散リソースのネットワーク管理を自動化する、一元化および標準化されたシステムです。このディレクトリ サービスは、ユーザー アカウント、グループ、その他のネットワーク オブジェクトの管理を一元的に行うことができます。Active Directory の主な機能は認証です。認証により、ユーザーの ID と認可が確認され、ネットワーク上の特定のリソースへのアクセス権がユーザーに付与されます。
Active Directory のコンポーネント
レルムは、Kerberos 認証の管理ドメインです。Active Directory との関連で見ると、レルムは Active Directory ドメインと同等です。レルムは、共通の認証データベースを共有するユーザー、コンピュータ、サービスの論理グループを表します。Kerberos を構成する場合は、クライアントとサービスが属するレルムを指定する必要があります。レルムではドメイン名が大文字になります。たとえば、ドメインが ad.example.com
の場合、レルムは AD.EXAMPLE.COM
になります。
Key Distribution Center(KDC)は、Active Directory のすべてのドメイン コントローラで実行されるコア Kerberos サービスです。KDC には次の主な機能があります。
- 認証サービス(AS): ユーザーの初回ログイン時(Windows にログインするときなど)にユーザーの ID を確認し、チケット付与チケット(TGT)を発行します。
- チケット付与サービス(TGS): 有効な TGT を提示した認証済みユーザーにサービス チケットを発行します。これらのサービス チケットは、PostgreSQL データベースなどの特定のサービスへのアクセス権を付与します。
プリンシパルは、チケットを割り当てることができる Kerberos レルム内の一意の ID です。主なプリンシパル タイプは次のとおりです。
- ユーザー プリンシパル: 人間のユーザーを表します(例:
username@REALM
)。 - サービス プリンシパル(SPN): 特定のホスト上の特定のサービス(
postgres/db-server.ad.example.com@REALM
など)を表します。クライアントがデータベースのサービス チケットをリクエストするには、データベース サービスに登録済みの SPN が必要です。
keytab またはキーテーブル ファイルには、プリンシパルのパスワードから派生したプリンシパルとそれらの対応する秘密鍵のリストが含まれています。サービスは、keytab ファイルを使用して KDC に ID を証明し、クライアントから提示されたサービス チケットを復号します。
このアプローチにより、PostgreSQL などのサービスは、人間の介入を必要とせず、またはサーバーに書式なしテキストのパスワードを保存することなく、Kerberos システムに対して認証を行うことができます。keytab ファイルは機密性が高いため、安全に保存して保護する必要があります。
PostgreSQL と Active Directory の統合
PostgreSQL を Active Directory と統合すると、企業 ID に基づくユーザー管理を一元化できるため、データベースのセキュリティが強化されます。
認証をサポートするために、PostgreSQL には Active Directory と統合するための次の方法が用意されています。
Lightweight Directory Access Protocol(LDAP): LDAP プロトコルを使用して Active Directory サーバーに対してユーザーを認証するように PostgreSQL を構成できます。ユーザーがデータベースに接続しようとすると、PostgreSQL は LDAP 経由で Active Directory サーバーと通信して、ユーザーの認証情報(通常はユーザー名とパスワード)を確認します。この方法では、Active Directory を外部認証プロバイダとして使用します。
Kerberos を使用した Generic Security Services Application Program Interface(GSSAPI): これは、Active Directory のデフォルトの認証メカニズムである Kerberos プロトコルを使用する、より安全で複雑なメソッドです。GSSAPI は、アプリケーションがセキュリティ サービスにアクセスするための標準インターフェースを備えています。
LDAP と GSSAPI の両方で Active Directory の統合という目標を達成できますが、GSSAPI と Kerberos の組み合わせは、強力なチケットベースの暗号認証を行うことができるため、エンタープライズ環境にとってより安全で堅牢なアプローチです。このページでは、GSSAPI メソッドを使用して AlloyDB Omni の Active Directory 統合を実装する方法について説明します。
GSSAPI を使用した Active Directory 認証
AlloyDB Omni では、認証バックエンドとして Active Directory を使用して Kerberos 経由で認証できます。認証を実現する手順を次の図に示します。
- クライアント
psql
は、キー配布センター(KDC)の認証サービス(AS)を使用して認証リクエストを開始します。 - AS はクライアントを認証し、クライアントにチケット付与チケット(TGT)(T1)を発行します。TGT はサービス チケットをリクエストするために使用されます。
- クライアントは、TGT を使用して、PostgreSQL サービスの KDC のチケット付与サービス(TGS)からサービス チケットをリクエストします。クライアントが特定の PostgreSQL サーバーへのアクセスをリクエストしています。
- TGS は TGT を検証し、クライアントにサービス チケット(T2)を発行します。このチケットにはセッションキー(T3)が含まれており、PostgreSQL サーバーの秘密鍵を使用して暗号化されます。
- クライアントは、暗号化されたサービス チケット(T2)を PostgreSQL サーバーに送信します。
- PostgreSQL サーバーは、その鍵(keytab ファイルの鍵)を使用してサービス チケット(T2)を復号し、セッションキー(T3)を取得して、チケットの信頼性を検証します。このオペレーションが成功すると、サーバーはアクセス権を付与し、セッションキーを使用してクライアントとの安全な通信チャネルを確立します。
次のステップ
- Active Directory ユーザーのサポートを AlloyDB Omni と統合する。
- Kubernetes で Active Directory ユーザーのサポートを統合する。
- Active Directory グループのサポートを AlloyDB Omni と統合する。
- Kubernetes で Active Directory グループのサポートを統合する。
- AlloyDB Omni での Active Directory 統合のトラブルシューティング。