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=1LDAP 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=krbmappg_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=postgresqlPAM 설정 /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
postgres 슈퍼유저는 SCRAM 비밀번호로 유지하고 비상 시 사용합니다.정리
- 외부 인증은 비밀번호 검증만 위임 — PostgreSQL 역할은 그대로 존재해야 함
- LDAP: AD/OpenLDAP과의 표준 통합합니다. TLS 필수
- Kerberos/GSSAPI: SSO·비밀번호 안 흐름. KDC 인프라 필요
- PAM: 가장 유연하지만 디버그 어려움
- OAuth (PG 18+): 현대적이지만 신규
- 매니지드 클라우드는 자체 IAM 통합이 보통 정답
- 비상 fallback 슈퍼유저는 SCRAM으로 유지
Part IX 인증·보안·권한이 끝났습니다. 다음 Part X에서는 설정과 운영 — postgresql.conf, 로깅, 모니터링 — 을 봅니다.