9.7 외부 인증 (LDAP, Kerberos, PAM, OAuth)

기업 환경에서 PostgreSQL을 별도 비밀번호 시스템으로 두면 관리 부담이 큽니다. 외부 ID 제공자(IdP)와 통합해 기존 사용자 디렉토리로 인증하게 만드는 옵션이 있습니다. LDAP/Active Directory, Kerberos, PAM, RADIUS, 그리고 PG 18+의 OAuth가 그것입니다.

통합 방식 비교

방식	pg_hba.conf METHOD	장점	단점
LDAP	`ldap`	비밀번호를 LDAP에 보냄. AD 통합 표준	비밀번호가 PostgreSQL 거쳐 LDAP에 — TLS 필수
GSSAPI/Kerberos	`gss` / `sspi`	SSO, 비밀번호 안 흐름	인프라 복잡, 클라이언트 KDC 접근 필요
PAM	`pam`	OS PAM 모듈 활용 — 어떤 IdP든	PAM 모듈마다 동작 차이
RADIUS	`radius`	MFA 친화	네트워크 인프라
Client cert	`cert`	비밀번호 없음, 가장 안전	인증서 발급·갱신 운영 부담
OAuth (PG 18+)	`oauth`	현대적 IdP — Keycloak, Azure AD, Okta	매우 신규, 검증 부족

LDAP 통합

가장 흔한 패턴입니다. AD 또는 OpenLDAP에 사용자가 있고, PostgreSQL은 비밀번호 검증만 위임.

simple bind

# pg_hba.conf
hostssl  all  all  10.0.0.0/8  ldap
   ldapserver=ldap.example.com
   ldapprefix="uid="
   ldapsuffix=",ou=people,dc=example,dc=com"
   ldapport=636
   ldaptls=1

동작:

사용자가 alice / secret로 PostgreSQL에 접속 요청
PostgreSQL이 uid=alice,ou=people,dc=example,dc=com 으로 LDAP bind 시도, 비밀번호 secret 사용
LDAP bind 성공 → 인증 OK

전제: PostgreSQL에 alice라는 역할이 미리 존재 (CREATE ROLE alice LOGIN).

search-bind

LDAP에서 사용자를 검색해 DN을 찾은 뒤 그 DN으로 bind. 디렉토리 구조가 일정하지 않을 때.

hostssl  all  all  10.0.0.0/8  ldap
   ldapserver=ldap.example.com
   ldapbasedn="ou=people,dc=example,dc=com"
   ldapsearchfilter="(&(uid=$username)(objectClass=posixAccount))"
   ldapbinddn="cn=pgldap,ou=services,dc=example,dc=com"
   ldapbindpasswd=service_password
   ldaptls=1

LDAP TLS는 거의 항상 필수 — 평문 LDAP bind는 비밀번호 노출합니다.

그룹 매핑

PostgreSQL은 LDAP 그룹을 자동 동기화하지 않습니다. 운영자는:

LDAP 그룹별로 PostgreSQL 역할을 미리 만들어 둠
주기적 동기화 스크립트가 LDAP 그룹 멤버를 PostgreSQL GRANT로 반영

자체 자동화가 필요한 부담입니다. AD 통합 시 거의 항상 직접 짭니다.

Kerberos / GSSAPI

엔터프라이즈 SSO. 비밀번호가 PostgreSQL을 거치지 않고, 클라이언트가 KDC에서 받은 ticket을 PostgreSQL에 제출.

# pg_hba.conf
hostgssenc  all  all  10.0.0.0/8  gss
   include_realm=0
   krb_realm=EXAMPLE.COM
   map=krbmap

pg_ident.conf로 Kerberos principal과 PostgreSQL 역할을 매핑:

# MAPNAME   SYSTEM-USERNAME              PG-USERNAME
krbmap      /^(.+)@EXAMPLE\.COM$         \1

장점:

비밀번호가 네트워크에 안 흐름
한 번 로그인하면 여러 시스템에 SSO

단점:

KDC 인프라 필요 (Active Directory가 KDC 역할 함)
클라이언트가 kinit로 ticket 미리 받아야
토큰 만료 시 갱신 필요

hostgssenc는 GSSAPI 암호화 전송까지 강제 — SSL이 아닌 GSSAPI 채널.

PAM

OS PAM 스택을 활용합니다. Linux에서 PAM에 어떤 모듈이든 끼울 수 있어 이론적으로 모든 인증 가능합니다.

# pg_hba.conf
host  all  all  10.0.0.0/8  pam pamservice=postgresql

PAM 설정 /etc/pam.d/postgresql:

auth     required     pam_unix.so
account  required     pam_unix.so

운영 사용:

OS Unix 사용자와 동기화
MFA PAM 모듈 (PAM TOTP 등) 통합
pam_ldap, pam_krb5 등 다른 PAM 모듈과 연결

단점: 디버그가 어렵고 PAM 모듈 버전 차이가 미묘.

OAuth (PG 18+)

PG 18에서 도입된 신기능. Keycloak·Azure AD·Okta 등 현대 IdP와 직접 통합 가능합니다.

hostssl  all  all  0.0.0.0/0  oauth
   issuer="https://login.example.com"
   scope="openid email"

클라이언트는 OAuth 토큰을 받아 PostgreSQL에 제시. PG는 토큰을 IdP에 검증합니다.

아직 매우 신규라 실 운영 검증이 쌓이기 전입니다. 도입을 평가할 때는 신중히 접근합니다.

외부 인증 일반 원칙

원칙	메모
PostgreSQL 역할은 그대로 필요	외부 IdP는 비밀번호 검증만 위임. 권한은 PostgreSQL이
TLS 필수	LDAP·RADIUS·HTTP 모두 비밀번호/토큰이 네트워크에
만료·잠금·MFA는 IdP 책임	PostgreSQL 자체 정책은 사용 안 함
슈퍼유저는 외부 인증 권장 안 함	비상 시 fallback 위해 SCRAM 슈퍼유저 하나 유지
매니지드 클라우드는 자체 통합	RDS = IAM, Azure = Entra ID 등. PostgreSQL 직접 LDAP보다 매니지드 통합이 보통 더 안정

매니지드 클라우드와의 차이

클라우드	외부 인증
AWS RDS PostgreSQL	IAM 인증 (token 기반), AD 통합 옵션
AWS Aurora PostgreSQL	같음 + Secrets Manager 통합
Azure Database for PostgreSQL	Entra ID(AAD) 통합, password rotation
GCP Cloud SQL	IAM 데이터베이스 인증
NCP Cloud DB for PostgreSQL	IAM 연동 (관리 콘솔 기반)

매니지드는 보통 자체 IAM/디렉토리 서비스 통합이 더 깔끔합니다. PostgreSQL의 LDAP/Kerberos는 온프레미스나 직접 운영하는 클라우드에서 주로 씁니다.

의사결정

    flowchart TD
  Q1{"환경"}
  Q1 -- "매니지드 클라우드" --> CLOUD["클라우드 IAM 통합"]
  Q1 -- "온프레미스·셀프호스팅" --> Q2{"기존 IdP"}
  Q2 -- "Active Directory" --> ADAUTH["GSSAPI/Kerberos 또는 LDAP"]
  Q2 -- "OpenLDAP" --> LDAP["LDAP simple bind"]
  Q2 -- "Keycloak·Okta" --> OAUTH["OAuth (PG 18+) 또는 PAM+oidc"]
  Q2 -- "없음" --> SCRAM["SCRAM 단독"]
  Q2 -- "MFA 필요" --> RADIUS["RADIUS 또는 PAM+TOTP"]

  classDef cloud fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
  classDef onprem fill:#d1fae5,stroke:#047857,color:#064e3b
  classDef q fill:#fed7aa,stroke:#c2410c,color:#7c2d12
  class CLOUD cloud
  class ADAUTH,LDAP,OAUTH,SCRAM,RADIUS onprem
  class Q1,Q2 q

비상 fallback 슈퍼유저는 항상 SCRAM으로. 외부 IdP가 중단되면 LDAP/Kerberos 인증이 안 됩니다. postgres 슈퍼유저는 SCRAM 비밀번호로 유지하고 비상 시 사용합니다.

정리

외부 인증은 비밀번호 검증만 IdP에 위임할 뿐, PostgreSQL 역할 자체는 그대로 있어야 합니다. AD·OpenLDAP과 붙일 때는 LDAP이 표준이고 TLS가 필수이며, SSO가 필요하고 비밀번호를 네트워크에 흘리고 싶지 않으면 Kerberos/GSSAPI를 쓰되 KDC 인프라를 준비해야 합니다. PAM은 가장 유연하지만 디버그가 어렵고, OAuth는 PG 18+에서 도입된 현대적 방식이지만 아직 신규입니다.

매니지드 클라우드는 자체 IAM 통합이 보통 정답
비상 fallback 슈퍼유저는 SCRAM으로 유지

이것으로 Part IX 인증·보안·권한을 마칩니다.

9.6 감사 (pgaudit)