Azure PostgreSQL Flexible Server TLS 연결

Azure PostgreSQL Flexible Server TLS 연결

Azure PostgreSQL Flexible Server를 사용하던 중 TLS가 기본적으로 enforced되어 있는 것을 발견했습니다. 그동안 별다른 SSL 설정 없이도 잘 동작했지만, 문득 이 원리가 궁금해져서 깊이 파보게 되었습니다.

이번 글에서는 PostgreSQL TLS 연결의 동작 원리와 각 SSL 모드의 차이점, 그리고 Azure에서의 실제 구현 방식을 알아보겠습니다.

📋 목차

1. PostgreSQL SSL 모드 이해하기
2. Azure PostgreSQL TLS Enforcement
3. 인증서 체인과 신뢰 구조
4. 각 SSL 모드별 실제 동작
5. 보안 고려사항과 권장사항
6. mTLS와 클라이언트 인증서

PostgreSQL SSL 모드 이해하기

PostgreSQL 클라이언트는 공식 문서의 Table 32.1에 따라 여러 SSL 파라미터를 제공합니다. 각 모드별 보안 수준을 살펴보겠습니다.

SSL 모드별 보안 수준 비교

SSL Mode	암호화	서버 인증	MITM 보호	용도
disable	❌	❌	❌	로컬 개발 전용
allow	Maybe	❌	❌	비권장
prefer	Maybe	❌	❌	비권장
require	✅	❌	❌	기본 암호화
verify-ca	✅	✅ (CA만)	Partial	중간 보안
verify-full	✅	✅ (완전)	✅	최고 보안

일반적으로 require 설정으로 많이 사용하실 텐데

Azure PostgreSQL TLS Enforcement

Azure PostgreSQL Flexible Server는 기본적으로 TLS 연결을 강제합니다. 이는 require_secure_transport 파라미터가 ON으로 설정되어 있기 때문입니다.
개발 환경이거나 자체적으로 사용하는 경우라면 OFF로 지정해도 무방하겠지만 상용환경이거나 보안적인 이슈가 있는 경우라면 TLS 설정도 필요할 것 같습니다.

Azure에서는 기본적으로 SSL이 활성화 되어 있습니다...

TLS Enforcement 테스트

클라이언트 쪽에서 SSL을 비활성화(Disalbed)하고 연결을 시도하면 다음과 같은 오류가 발생합니다:

DBMS: PostgreSQL(버전 16.8)
드라이버: PostgreSQL JDBC Driver(버전 42.7.3, JDBC4.2)
[28000] FATAL: no pg_hba.conf entry for host "", user "john", database "postgres", no encryption.

이 오류는 Azure가 암호화되지 않은 연결을 거부한다는 것을 명확히 보여줍니다.

반대로 아래와 같이 verify-full로 하는 경우 성공적으로 연결이 되는 것을 확인 할 수 있습니다.(jetbrains data grip 사용예시)

Azure의 인증서 정책

Azure PostgreSQL은 현재 다음 CA들로부터 인증서를 발급받습니다:

• DigiCert Global Root G2 (현재 주력)
• Microsoft RSA Root CA 2017 (마이그레이션 중)
• DigiCert Global Root CA (레거시 호환성)

Microsoft 공식 문서에 따르면, 클라이언트 호환성을 위해 3개의 루트 CA 인증서를 모두 지원해야 합니다.

실제 저의 컴퓨터의 키체인에서 검색을 하면 아래와 같이 Root CA가 나오는 것을 확인 할 수 있습니다.(Macos 기준)

Macos 기준으로 스포트라이트에 케체인 접근을 치시고 들어가서 검색을 하시면 인증서가 나오는 것을 알 수 있습니다.

인증서 체인과 신뢰 구조

TLS의 경우에는 하나의 인증서로 이루어져 있다기보다는 체인의 형태로 이루어져 있습니다.

인증서 체인 구조

Azure PostgreSQL의 일반적인 인증서 체인:

📜 서버 인증서: yourserver.postgres.database.azure.com
├─ 🏢 발급자: Microsoft Azure TLS Issuing CA 01
├─ 📜 중간 CA: Microsoft Azure TLS Issuing CA 01
│   ├─ 🏢 발급자: Microsoft RSA Root CA 2017
│   └─ ✍️ 서명: Microsoft RSA Root CA 2017의 개인키
└─ 🔑 루트 CA: Microsoft RSA Root CA 2017 (클라이언트 보유 필요)

각 SSL 모드별 실제 동작

require 모드

동작 과정:
1. 클라이언트: "SSL 연결 필수"
2. 서버: "인증서 전송"
3. 클라이언트: "인증서 검증 없이 암호화만 적용"

장점: 데이터 암호화 보장
단점: 중간자 공격(MITM)에 취약

verify-ca 모드

동작 과정:
1. 클라이언트: "SSL + CA 검증"
2. 서버: "DigiCert 서명 인증서 전송"
3. 클라이언트: "루트 CA로 서명 검증 → 신뢰"

장점: CA 검증으로 신뢰성 확보
단점: 호스트명 검증 없음

쉽게 말해 누군지는 모르겠지만 CA인증서를 토대로 연결을 하겠다...

verify-full 모드

동작 과정:
1. 클라이언트: "SSL + CA + 호스트명 검증"
2. 서버: "인증서 전송"
3. 클라이언트: "CA 검증 → 호스트명 확인 → 완전 신뢰"

장점: 최고 수준의 보안
단점: 설정 복잡도 증가

mTLS와 클라이언트 인증서

SSL 사용예시에서 클라이언트 측 인증서 파일을 설정하는 칸이 있는데 이 옵션들은 mTLS를 위한 옵션으로 내용은 아래와 같습니다.

mTLS (Mutual TLS) 개념

일반 TLS는 서버만 인증하지만, mTLS는 클라이언트도 인증서로 신원을 증명합니다.

일반 TLS:    클라이언트 → 서버 (서버만 인증)
mTLS:        클라이언트 ↔ 서버 (상호 인증)

클라이언트 인증서 설정

고보안 환경에서의 mTLS:

# DataGrip 설정
SSL Mode: verify-full
CA file: /path/to/server-ca.pem      # 서버 검증용
Client Certificate: /path/to/client.crt  # 클라이언트 인증용
Client Key: /path/to/client.key      # 클라이언트 개인키

참고

인증서 체인 확인하기

실제 Azure PostgreSQL의 인증서 체인을 확인하는 방법은 아래와 같습니다.

# 인증서 체인 전체 확인
openssl s_client -starttls postgres -showcerts -connect yourserver.postgres.database.azure.com:5432

# SSL 연결 상태 확인 (연결 후 SQL 실행, Azure 기준)
SELECT * from pg_stat_ssl;

📚 마무리

Azure PostgreSQL의 TLS 연결은 다음과 같은 계층적 보안 구조를 가집니다:

1. 서버 강제: require_secure_transport = ON
2. 인증서 체인: 신뢰할 수 있는 CA 검증
3. 클라이언트 선택: SSL 모드별 보안 수준 조절
4. 선택적 mTLS: 양방향 인증 지원

핵심 포인트:

• 최소 require 이상 사용
• 프로덕션에서는 verify-full 권장
• 시스템의 루트 CA가 신뢰 기반
• mTLS는 높은 보안이 필요한 경우에만

---

🔗 참고 자료

• PostgreSQL SSL Documentation
• Azure PostgreSQL TLS/SSL Guide
• Azure PostgreSQL SSL Concepts