PostgreSQL sslmode 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

PostgreSQL sslmode 기준 정리

sslmode는 PostgreSQL 클라이언트가 서버와 연결할 때 TLS를 아예 쓰지 않을지, 우선 시도만 할지, 인증서까지 검증할지를 정하는 핵심 옵션이다. 현재 PostgreSQL 18 공식 문서 기준으로 이 값은 여섯 가지 모드를 가지며, 기본값은 prefer다.

실무에서 중요한 기준은 세 가지다. 평문 연결을 허용해도 되는지, 서버 인증서를 검증해야 하는지, 그리고 접속 대상이 TCP/IP인지 유닉스 도메인 소켓인지다. 이 글은 PostgreSQL 공식 문서를 바탕으로 각 모드의 의미와 안전한 기본값을 객관적으로 정리한다.

sslmode는 정확히 무엇을 제어할까?

공식 문서에서 sslmode는 클라이언트가 서버와 secure SSL TCP/IP connection을 어떤 우선순위로 협상할지 결정하는 옵션으로 설명된다. 즉 서버 설정인 ssl = on과는 역할이 다르며, 클라이언트 쪽에서 연결 정책을 정하는 값이다.

이 옵션은 연결 문자열이나 환경 변수로 지정할 수 있고, psql, libpq 기반 애플리케이션, 여러 PostgreSQL 드라이버의 하위 설정에도 자주 연결된다. 다만 공식 문서 기준으로 sslmode는 TCP/IP 연결에만 의미가 있고, 유닉스 도메인 소켓 통신에서는 무시된다.

여섯 가지 모드는 어떻게 다를까?

모드	동작	실무 해석
disable	SSL 없이만 연결 시도	TLS를 전혀 쓰지 않는다.
allow	평문 먼저, 실패하면 SSL 시도	보안보다 호환성 우선이다.
prefer	SSL 먼저, 실패하면 평문 시도	기본값이지만 평문 fallback이 남아 있다.
require	SSL로만 연결 시도	암호화는 강제하지만 호스트명 검증은 아니다.
verify-ca	SSL 강제 + 신뢰된 CA 확인	인증서 체인은 보지만 대상 호스트명은 따로 보지 않는다.
verify-full	SSL 강제 + CA 확인 + 호스트명 일치 확인	가장 엄격한 검증이다.

공식 문서는 require에서 root CA 파일이 있으면 verify-ca처럼 인증서 검증이 함께 일어날 수 있다고 설명한다. 반대로 root CA 파일이 없으면 require는 "암호화는 하지만 서버 신원은 엄격히 검증하지 않는 상태"로 이해하는 편이 안전하다.

기본값 prefer를 그대로 써도 될까?

prefer는 현재 libpq의 기본값이지만, 서버가 SSL을 받지 않으면 평문으로도 연결될 수 있다. 그래서 네트워크 경로에서 반드시 암호화를 강제해야 하는 운영 환경이라면 기본값 그대로 두는 판단은 보수적이지 않다.

대부분의 운영 서비스에서는 다음처럼 나누면 단순하다.

• 로컬 유닉스 소켓 접속: sslmode보다 소켓 사용 자체가 더 중요한 기준이다.
• 같은 VPC나 내부망이라도 TLS 강제가 필요함: 최소 require 이상을 본다.
• 서버 신원 검증까지 필요함: verify-full이 기본 후보다.
• 개발 편의 때문에 평문 fallback을 허용해야 함: 그때만 prefer 또는 allow를 검토한다.

왜 verify-full이 자주 권장될까?

PostgreSQL 18의 SSL 지원 문서는 보안 민감한 대부분의 환경에서 verify-full을 권장한다고 설명한다. 이유는 단순하다. TLS 연결만으로는 "암호화됐다"는 사실만 보장할 뿐, 지금 붙은 서버가 원래 의도한 그 서버인지까지는 자동으로 보장하지 않기 때문이다.

verify-full은 서버 인증서가 신뢰된 CA로부터 발급됐는지 확인하고, 요청한 호스트명이 인증서의 SAN 또는 필요한 경우 Common Name과 일치하는지도 본다. DNS 오염, 잘못된 라우팅, 다른 서버 인증서 오배치 같은 문제를 막으려면 이 단계가 빠지면 안 된다.

verify-ca와 verify-full 차이는 어디서 생길까?

verify-ca는 인증서 체인이 신뢰된 CA로 이어지는지만 확인한다. 반면 verify-full은 거기에 더해 "내가 접속하려는 호스트 이름과 인증서 이름이 맞는가"까지 검사한다.

즉 내부 CA를 쓰고 있다고 해도, 같은 CA가 여러 서버 인증서를 발급할 수 있는 환경이라면 verify-ca만으로는 오접속을 완전히 막지 못한다. 운영 환경에서 접속 대상을 명확히 구분해야 한다면 verify-full 쪽이 더 직접적인 기본값이다.

 

 

유닉스 도메인 소켓에서는 왜 sslmode가 무시될까?

공식 문서는 sslmode가 유닉스 도메인 소켓 통신에서는 ignored 된다고 명시한다. 이 경로는 네트워크 TCP 연결이 아니라 로컬 시스템 내부 IPC이기 때문에, TCP 위에서 협상하는 SSL/TLS 자체가 적용 대상이 아니다.

따라서 로컬 호스트 접속 문제를 점검할 때는 sslmode보다 실제로 소켓으로 붙는지, 혹은 host를 명시해 TCP/IP로 붙는지부터 구분해야 한다. 같은 localhost 접속이라도 드라이버와 파라미터에 따라 경로가 달라질 수 있다.

require만 써도 충분한 경우가 있을까?

있을 수는 있다. 예를 들어 인증서 검증 체계를 아직 배포하지 못했지만 평문 연결만은 막아야 하는 전환 단계라면 require가 현실적인 중간값이 될 수 있다. 다만 이 경우에도 "암호화 강제"와 "서버 신원 검증"을 같은 수준으로 보면 안 된다.

공식 문서가 verify-full을 별도로 강조하는 이유도 여기에 있다. 운영 환경에서 접속 대상 위조 가능성을 줄이려면 최종 목적지는 보통 require가 아니라 verify-full이다.

최근 문서 기준으로 같이 봐야 할 옵션은 무엇일까?

PostgreSQL 18 연결 문서는 sslrootcert=system을 사용할 때 기본 sslmode가 verify-full로 바뀌고, 그보다 약한 설정은 오류가 난다고 설명한다. 시스템 신뢰 저장소를 쓰는 경우에는 약한 검증 모드가 의미를 잃기 쉽다는 점을 문서가 분명히 드러낸 셈이다.

또한 문서는 GSSAPI 암호화가 가능한 환경에서는 sslmode 값과 무관하게 GSSAPI 암호화가 우선될 수 있다고 설명한다. Kerberos 기반 환경에서 반드시 SSL을 강제하려면 gssencmode=disable도 함께 봐야 한다.

FAQ

Q. 내부망이면 prefer로도 충분할까?

상황에 따라 다르다. 내부망 자체가 신뢰 경계라고 보더라도, 공식 문서 기준으로 prefer는 SSL 실패 시 평문 fallback을 허용한다. 내부망에서도 암호화 강제가 필요하면 require 이상이 더 명확하다.

Q. verify-full을 쓰려면 무엇이 먼저 준비돼야 할까?

클라이언트가 신뢰할 CA 체인과, 접속에 사용하는 호스트명이 서버 인증서의 SAN 또는 필요한 경우 Common Name과 일치해야 한다. 즉 인증서 배포만이 아니라 접속 문자열의 호스트명 관리도 같이 맞아야 한다.

Q. IP 주소로 접속해도 verify-full이 가능할까?

가능하다. 공식 문서는 IP로 접속하는 경우 인증서의 iPAddress 또는 경우에 따라 dNSName SAN과 비교한다고 설명한다. 다만 실무에서는 IP 변경과 인증서 재발급 관리까지 함께 고려해야 한다.

정리

sslmode를 고를 때 가장 중요한 기준은 "평문 fallback을 허용할지"와 "서버 신원 검증까지 할지"다. 현재 PostgreSQL 공식 문서 기준으로 기본값 prefer는 호환성에는 유리하지만, 운영 보안 기본값으로는 다소 느슨할 수 있다.

대부분의 운영 환경에서는 verify-full이 가장 설명 가능한 선택이고, 전환 단계에서는 require를 임시값으로 둘 수 있다. 반대로 로컬 유닉스 소켓 접속이라면 sslmode가 아니라 실제 연결 경로를 먼저 보는 편이 맞다.

참고 자료

• PostgreSQL Documentation: libpq connection parameters
• PostgreSQL Documentation: libpq SSL support
• PostgreSQL 18 current documentation