이 페이지에서는 일반 보안 서비스 애플리케이션 프로그래밍 인터페이스 (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입니다.
키 배포 센터(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 또는 키 테이블 파일에는 주 구성원 목록과 주 구성원의 비밀번호에서 파생된 해당 비밀 키가 포함되어 있습니다. 서비스는 키탭 파일을 사용하여 KDC에 ID를 증명하고 클라이언트가 제시한 서비스 티켓을 복호화합니다.
이 방식을 사용하면 PostgreSQL과 같은 서비스가 사람의 상호작용 없이 또는 서버에 일반 텍스트 비밀번호를 저장하지 않고도 Kerberos 시스템에 자체적으로 인증할 수 있습니다. keytab 파일은 매우 민감하므로 안전하게 저장하고 보호해야 합니다.
Active Directory와의 PostgreSQL 통합
PostgreSQL을 Active Directory와 통합하면 회사 ID를 기반으로 사용자 관리를 중앙 집중화하여 데이터베이스 보안을 강화할 수 있습니다.
인증을 지원하기 위해 PostgreSQL은 Active Directory와 통합하는 다음 방법을 제공합니다.
경량 디렉터리 액세스 프로토콜 (LDAP): LDAP 프로토콜을 사용하여 Active Directory 서버에 대해 사용자를 인증하도록 PostgreSQL을 구성할 수 있습니다. 사용자가 데이터베이스에 연결하려고 하면 PostgreSQL은 LDAP를 통해 Active Directory 서버와 통신하여 사용자의 사용자 인증 정보(일반적으로 사용자 이름과 비밀번호)를 확인합니다.
이 메서드는 Active Directory를 외부 인증 공급자로 사용합니다.
Kerberos를 사용하는 일반 보안 서비스 애플리케이션 프로그램 인터페이스 (GSSAPI): Active Directory의 기본 인증 메커니즘인 Kerberos 프로토콜을 사용하는 더 안전하고 복잡한 방법입니다. GSSAPI는 애플리케이션이 보안 서비스에 액세스할 수 있는 표준 인터페이스를 제공합니다.
LDAP와 GSSAPI 모두 Active Directory 통합이라는 목표를 달성하지만, Kerberos를 사용하는 GSSAPI는 강력한 티켓 기반 암호화 인증으로 인해 엔터프라이즈 환경에서 더 안전하고 강력한 접근 방식입니다. 이 페이지에서는 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 서버는 키탭 파일의 키를 사용하여 서비스 티켓(T2)을 복호화한 다음 서버가 세션 키(T3)를 가져오고 티켓의 진위 여부를 확인합니다. 이 작업이 성공하면 서버는 액세스 권한을 부여하고 세션 키를 사용하여 클라이언트와 보안 통신 채널을 설정합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Active Directory overview\n\nSelect a documentation version: Current (16.8.0)keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/active-directory-overview)\n- [16.8.0](/alloydb/omni/16.8.0/docs/active-directory-overview)\n\n\u003cbr /\u003e\n\n|\n| **Preview\n| --- [AlloyDB Omni](/alloydb/omni/current/docs/overview)**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| You can process personal data for this feature as outlined in the\n| [Cloud Data Processing\n| Addendum](/terms/data-processing-addendum), subject to the obligations and restrictions described in the agreement under\n| which you access Google Cloud.\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis page describes how PostgreSQL integrates with Active Directory in\nAlloyDB Omni using the Generic Security Services Application Programming\nInterface (GSSAPI), and it introduces key Kerberos concepts.\n[*Kerberos*](https://en.wikipedia.org/wiki/Kerberos_(protocol)) is the\nauthentication protocol that powers Active Directory.\n\n[Active Directory](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview)\nis a directory service developed by Microsoft for Windows domain networks.\nActive Directory is a centralized, standardized system that automates network\nmanagement of user data, security, and distributed resources. This directory\nservice provides a single point of administration for user accounts, groups, and\nother network objects. A key function of Active Directory is authentication,\nwhich confirms a user's identity and authorization, and grants the user access\nto specific resources on the network.\n\nActive Directory components\n---------------------------\n\nA [*realm*](https://web.mit.edu/kerberos/kfw-4.1/kfw-4.1/kfw-4.1-help/html/kerberos_terminology.htm#:%7E:text=Kerberos%20realms%20are%20a%20way,Windows%2C%20realms%20are%20called%20domains.)\nis the administrative domain for Kerberos authentication. In the context of\nActive Directory, a realm is equivalent to an Active Directory domain. Realms\nrepresent a logical group of users, computers, and services that share a common\nauthentication database. When you configure Kerberos, you must specify the realm\nthat your clients and services belong to. A realm is an uppercase version of the\ndomain name---for example, if the domain is `ad.example.com`, then the realm is\n`AD.EXAMPLE.COM`.\n\nThe\n[*Key Distribution Center*](https://web.mit.edu/kerberos/krb5-1.3/krb5-1.3.3/doc/krb5-install.html#:%7E:text=Introduction%2C%20Up:Introduction-,What%20is%20Kerberos%20and%20How%20Does%20it%20Work?,additional%20tickets%20is%20user%2Dtransparent.)\n(KDC) is a core Kerberos service that runs on every domain controller in\nActive Directory. The KDC has the following primary functions:\n\n- Authentication Service (AS): verifies a user's identity at the initial sign-in, for example, when you sign into Windows, and issues a Ticket-Granting Ticket (TGT).\n- Ticket-Granting Service (TGS): issues service tickets to authenticated users who present a valid TGT. These service tickets grant access to specific services, like a PostgreSQL database.\n\nA\n[*principal*](https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html)\nis a unique identity in a Kerberos realm to which tickets can be assigned. The\nfollowing are the main types of principals:\n\n- User principals: represent human users---for example, `username@REALM`.\n- Service principals (SPN): represent a specific service on a specific host---for example, `postgres/db-server.ad.example.com@REALM`. For a client to request a service ticket for your database, the database service must have a registered SPN.\n\nA\n[*keytab*](https://web.mit.edu/kerberos/krb5-devel/doc/basic/keytab_def.html)\nor key table file contains a list of principals and their corresponding secret\nkeys, which are derived from the principals' passwords. Services use a keytab\nfile to prove their identity to the KDC and to decrypt service tickets presented\nby clients.\n\nThis approach allows a service like PostgreSQL to authenticate\nitself to the Kerberos system without requiring human interaction or storing a\nplain text password on the server. The keytab file is highly sensitive and must\nbe securely stored and protected.\n\nPostgreSQL integration with Active Directory\n--------------------------------------------\n\nIntegrating PostgreSQL with Active Directory gives you centralized\nuser management based on corporate identities, which enhances your database security.\n\nTo support authentication, PostgreSQL offers\nthe following methods for integrating with Active Directory:\n\n- Lightweight Directory Access Protocol (LDAP): you can configure\n PostgreSQL to authenticate users against an Active Directory server using\n the LDAP protocol. When a user tries to connect to the\n database, PostgreSQL communicates with the Active Directory server over\n LDAP to verify the user's credentials, which are typically a username and password.\n This method uses Active Directory as an external authentication\n provider.\n\n- Generic Security Services Application Program Interface (GSSAPI) with\n Kerberos: this is a more secure and complex method that uses the\n Kerberos protocol, which is the default authentication mechanism in Active\n Directory. GSSAPI provides a standard interface for applications to access\n security services.\n\nWhile both LDAP and GSSAPI achieve the goal of Active Directory integration, GSSAPI\nwith Kerberos is the more secure and robust approach for\nenterprise environments due to its strong, ticket-based cryptographic\nauthentication. This page addresses implementing Active Directory integration\nfor AlloyDB Omni using the GSSAPI method.\n\nActive Directory authentication with GSSAPI\n-------------------------------------------\n\nAlloyDB Omni lets you authenticate over Kerberos using Active\nDirectory as an authentication backend. The steps to achieve authentication are\nshown in the following diagram.\n\n1. The client `psql` initiates an authentication request using the Authentication Service (AS) in the Key Distribution Center (KDC).\n2. The AS authenticates the client and issues a Ticket Granting Ticket (TGT) (T1) to the client. The TGT is then used to request service tickets.\n3. The client uses the TGT to request a service ticket from the Ticket Granting Service (TGS) in the KDC for the PostgreSQL service. The client is now requesting access to the specific PostgreSQL server.\n4. The TGS validates the TGT and issues a service ticket (T2) to the client. This ticket contains a session key (T3) and is encrypted using the PostgreSQL server's secret key.\n5. The client sends the encrypted service ticket (T2) to the PostgreSQL server.\n6. The PostgreSQL server uses its key (from its keytab file) to decrypt the service ticket (T2), and then the server retrieves the session key (T3) and verifies the ticket's authenticity. If this operation is successful, the server grants access and establishes a secure communication channel with the client using the session key.\n\nWhat's next\n-----------\n\n- [Integrate Active Directory user support with AlloyDB Omni](/alloydb/omni/current/docs/integrate-active-directory).\n- [Integrate Active Directory user support on Kubernetes](/alloydb/omni/current/docs/integrate-active-directory-kubernetes-operator).\n- [Integrate Active Directory group support with AlloyDB Omni](/alloydb/omni/current/docs/integrate-ad-group-support-alloydb-omni).\n- [Integrate Active Directory group support on Kubernetes](/alloydb/omni/current/docs/integrate-ad-group-support-kubernetes-operator).\n- [Troubleshoot Active Directory integration in AlloyDB Omni](/alloydb/omni/current/docs/troubleshoot-active-directory-integration)."]]