개요
클라이언트 애플리케이션과 데이터베이스 서버 간의 연결은 항상 SSL(Secure Sockets Layer)으로 알려진 업계 표준 TLS(전송 계층 보안)를 사용하여 암호화됩니다.
비고
오픈 소스 PostgreSQL은 기존 구현을 중단하지 않도록 명령, 변수 및 설명서에서 레거시 이름 SSL을 사용합니다. 이 문서에서는 명령 이름 및 변수에서 SSL을 사용하는 동안 약어 TLS를 사용합니다.
Azure Database for PostgreSQL은 TLS 1.2 및 1.3을 사용하여 암호화된 연결을 지원합니다. TLS 1.0 및 TLS 1.1을 사용하여 트래픽을 암호화하려는 모든 들어오는 연결이 거부됩니다.
기본적으로 클라이언트와 서버 간의 보안 연결이 적용됩니다. 암호화된 클라이언트 통신과 암호화되지 않은 클라이언트 통신을 모두 허용하는 TLS 적용을 사용하지 않도록 설정하려면 서버 매개 변수 require_secure_transport 를 OFF.로 변경할 수 있습니다. 서버 매개 변수를 설정 ssl_max_protocol_version 하여 TLS 버전을 설정할 수도 있습니다. TLS 를 사용하지 않도록 설정하는 것이 좋습니다 .
중요합니다
새 중간 CA 인증서 및 결과 인증서 체인을 업데이트하기 위해 Azure Database for PostgreSQL에 대한 TLS 인증서 회전을 시작했습니다. 루트 CA는 동일하게 유지됩니다.
클라이언트 구성이 TLS에 대한 권장 구성을 구현하는 경우에는 아무 작업도 필요하지 않습니다.
인증서 회전 일정
- 미국 중서부, 동아시아 및 영국 남부 Azure 지역은 2025년 11월 11일에 TLS 인증서 회전을 시작했습니다.
- 2026년 1월 19일부터 이 인증서 회전은 Azure Government를 포함한 나머지(중국 제외) 지역으로 확장될 예정입니다.
- 2026년 봄 축제(중국 설날) 이후 중국 지역도 루트 CA 중 하나에 대한 변경을 포함하는 인증서 회전을 거칩니다.
클라이언트 TLS 구성
기본적으로 PostgreSQL은 서버 인증서의 확인을 수행하지 않습니다. 이러한 이유로 클라이언트가 알지 못하는 사이에 서버 ID를 위조하는 것이 가능합니다(예: DNS 레코드 수정 또는 서버 IP 주소 인수). 이러한 스푸핑을 방지하려면 클라이언트에서 TLS 인증서 확인을 사용해야 합니다.
TLS에 대한 클라이언트를 구성하기 위한 많은 연결 매개 변수가 있습니다. 몇 가지 중요한 사항은 다음과 같습니다.
ssl: TLS를 사용하여 연결합니다. 이 속성에는 연결된 값이 필요하지 않습니다. 단순한 존재는 TLS 연결을 지정합니다. 향후 버전과의 호환성을 위해 값true가 기본 설정됩니다. 이 모드에서 TLS 연결을 설정할 때 클라이언트 드라이버는 서버 ID의 유효성을 검사하여 중간에서 맨 인 더 미들 공격을 방지합니다.sslmode: 암호화가 필요하고 암호화할 수 없을 경우 연결이 실패하도록 하려면sslmode=require를 설정합니다. 이 설정은 서버가 이 호스트/IP 주소에 대한 TLS 연결을 허용하도록 구성되고 서버가 클라이언트 인증서를 인식하도록 합니다. 서버가 TLS 연결을 허용하지 않거나 클라이언트 인증서가 인식되지 않으면 연결이 실패합니다. 다음 표에는 이 설정에 대한 값이 나열되어 있습니다.sslmodeExplanation disable암호화가 사용되지 않습니다. Azure Database for PostgreSQL에는 TLS 연결이 필요합니다. 따라서 이 설정은 사용되지 않습니다. allow서버 설정에서 요구하거나 강제로 적용하는 경우 암호화가 사용됩니다. Azure Database for PostgreSQL에는 TLS 연결이 필요합니다. 따라서 이 설정은 .에 해당합니다 prefer.prefer암호화는 서버 설정이 이를 허용하는 경우 사용됩니다. Azure Database for PostgreSQL에는 TLS 연결이 필요합니다. require암호화가 사용되지 않음 그러면 서버가 TLS 연결을 허용하도록 구성됩니다. verify-ca암호화가 사용되지 않음 클라이언트에 저장된 신뢰할 수 있는 루트 인증서에 대해 서버 인증서를 확인합니다. verify-full암호화가 사용되지 않음 클라이언트에 저장된 인증서에 대해 서버 인증서를 확인합니다. 또한 서버 인증서가 연결과 동일한 호스트 이름을 사용하는지 확인합니다. 프라이빗 DNS 확인자가 다른 이름을 사용하여 Azure Database for PostgreSQL 서버를 참조하지 않는 한 이 설정을 사용하는 것이 좋습니다.
사용되는 기본 sslmode 모드는 libpq 기반 클라이언트(PSQL 및 JDBC와 같은)들 사이에서 서로 다릅니다. libpq 기반 클라이언트는 기본적으로 prefer로 설정됩니다.
JDBC 클라이언트의 기본값은 verify-full입니다.
-
sslcert,sslkey및sslrootcert: 이러한 매개 변수는 클라이언트 인증서, PKCS-8 클라이언트 키 및 루트 인증서의 기본 위치를 재정의할 수 있습니다. 기본값은 각각/defaultdir/postgresql.crt,/defaultdir/postgresql.pk8, 및/defaultdir/root.crt이며, Linux 시스템에서는defaultdir이고 Windows에서는${user.home}/.postgresql/입니다.
중요합니다
일부 Postgres 클라이언트 라이브러리는 sslmode=verify-full 설정을 사용하는 동안 중간 인증서와 교차 서명된 루트 CA 인증서에서 연결 실패가 발생할 수 있습니다. 그 결과 대체 신뢰 경로가 생성됩니다. 이 경우 sslrootcert 매개 변수를 명시적으로 지정하는 것이 좋습니다. 또는 PGSSLROOTCERT 환경 변수를 기본값인 %APPDATA%\postgresql\root.crt에서 Microsoft RSA 루트 CA 2017 루트 CA 인증서가 배치된 로컬 경로로 설정합니다.
신뢰할 수 있는 루트 CA(인증 기관) 설치
루트 CA 인증서 다운로드 및 변환
신뢰할 수 있는 루트 인증서에 시스템 인증서 저장소를 사용하는 Windows 클라이언트의 경우 Windows가 Windows 업데이트를 통해 새 루트 CA 인증서를 배포하기 때문에 아무 작업도 필요하지 않습니다.
Java 클라이언트, VS Code 확장, 그리고 기타 클라이언트(예: PSQL, Perl 등)로서 시스템 저장소를 사용하지 않는 경우 및 Linux의 클라이언트인 경우: 루트 CA 인증서를 다운로드하고 PEM 파일로 결합해야 합니다. 최소한 다음 루트 CA 인증서를 포함합니다.
비고
중국 지역 및 회전 확장이 있는 고객의 경우: Digicert 글로벌 루트 CA(pem 파일) 는 여전히 유효합니다. 결합된 PEM 파일에 포함합니다.
Azure Database for PostgreSQL에서 사용하는 루트 CA가 변경된 경우 결합된 파일에 대한 향후 업데이트 필요성을 줄이기 위해 모든 Azure 루트 CA 인증서를 포함하는 것이 좋습니다. Azure 루트 CA 인증서 목록은 Azure 인증 기관 세부 정보에서 찾을 수 있습니다.
인증서를 클라이언트 인증서 저장소로 가져오려면 CRT 형식 인증서를 PEM 형식으로 변환하고 PEM 파일을 단일 파일로 연결해야 할 수 있습니다. OpenSSL X509 유틸리티를 사용하여 CRT 파일을 PEM으로 변환할 수 있습니다.
openssl x509 -inform DER -in certificate-filename.crt -out certificate-filename.pem -outform PEM
루트 CA 인증서를 단일 PEM 파일로 결합
일부 클라이언트의 경우 텍스트 편집기 또는 명령줄 도구를 사용하여 모든 PEM 파일을 단일 파일에 연결합니다.
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----
중국 지역 및 회전 확장이 있는 고객의 경우:
-----BEGIN CERTIFICATE-----
(Root CA0 content: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----
Java 애플리케이션에 대한 루트 CA 인증서 결합 및 업데이트
사용자 지정으로 작성된 Java 애플리케이션은 신뢰할 수 있는 CA(인증 기관) 인증서를 포함하는 기본 키 저장소를 cacerts사용합니다. 이름이 지정된 cacerts 인증서 파일은 보안 속성 디렉터리인 java.home\lib\security에 있습니다. 여기서 java.home은 런타임 환경 디렉터리( jre SDK의 디렉터리 또는 Java™ 2 런타임 환경의 최상위 디렉터리)입니다.
다음 지침을 사용하여 PostgreSQL을 사용하여 클라이언트 인증서 고정 시나리오에 대한 클라이언트 루트 CA 인증서를 업데이트할 수 있습니다.
Java 키 저장소에 필요한 인증서가 이미 포함되어 있는지 확인
cacerts합니다. 다음 명령을 사용하여 Java 키 저장소에 인증서를 나열할 수 있습니다.keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt필요한 인증서가 클라이언트의 Java 키 저장소에 없는 경우 출력에서 체크 인할 수 있듯이 다음 지침을 진행해야 합니다.
사용자 지정 키 저장소의 백업 복사본을 만듭니다.
인증서 파일을 다운로드하고 참조할 수 있는 위치에 로컬로 저장합니다.
필요한 모든 루트 CA 인증서가 포함된 결합된 CA 인증서 저장소를 생성합니다. 아래 예제에서는 PostgreSQL Java 사용자에 대해 DefaultJavaSSLFactory를 사용하는 방법을 보여 줍니다.
keytool -importcert -alias PostgreSQLServerCACert -file "DigiCertGlobalRootG2.crt.pem" -keystore truststore -storepass password -noprompt keytool -importcert -alias PostgreSQLServerCACert2 -file "Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password -noprompt ...
Azure App Services에서 루트 CA 인증서 업데이트
Azure App Services의 경우 Azure Database for PostgreSQL 유연한 서버 인스턴스에 연결하는 경우 클라이언트 인증서를 업데이트하는 두 가지 시나리오를 사용할 수 있으며, Azure App Services에 배포된 애플리케이션에서 SSL을 사용하는 방법에 따라 달라집니다.
- Azure Database for PostgreSQL 유연한 서버 인스턴스에서 변경이 발생하기 전에 플랫폼 수준에서 App Service에 새 인증서가 추가됩니다. 애플리케이션의 App Service 플랫폼에 포함된 SSL 인증서를 사용하는 경우 아무 작업도 필요하지 않습니다. 자세한 내용은 Azure App Service 설명서의 Azure App Service에서 TLS/SSL 인증서 추가 및 관리를 참조하세요.
- 코드에 SSL 인증서 파일의 경로를 명시적으로 포함하는 경우 새 인증서를 다운로드하고 사용할 코드를 업데이트해야 합니다.
AKS(Azure Kubernetes Service)에서 클라이언트를 사용할 때 루트 CA 인증서 업데이트
AKS(Azure Kubernetes Services)에서 호스트되는 애플리케이션을 사용하여 Azure Database for PostgreSQL에 연결하려는 경우 전용 고객의 호스트 환경에서 액세스하는 것과 유사합니다. AKS 설명서의 자세한 지침을 참조하세요.
Windows에서 .NET(Npgsql) 사용자에 대한 루트 CA 인증서 업데이트
Windows의 .NET(Npgsql) 사용자의 경우 Azure Database for PostgreSQL 유연한 서버 인스턴스에 연결하려면 모든 루트 CA 인증서가 신뢰할 수 있는 루트 인증 기관인 Windows 인증서 저장소에 포함되어 있는지 확인합니다. Windows 업데이트는 표준 Azure 루트 CA 목록을 유지 관리합니다.
권장 구성에 나열된 인증서가 포함되지 않은 경우 누락된 인증서를 가져옵니다.
인증서 유효성 검사와 함께 TLS를 사용하는 방법
데이터베이스 서비스에 PostgreSQL을 사용하는 일부 애플리케이션 프레임워크는 설치하는 동안 기본적으로 TLS를 사용하도록 설정하지 않습니다. Azure Database for PostgreSQL 인스턴스는 TLS 연결을 적용하지만 애플리케이션이 TLS에 대해 구성되지 않은 경우 애플리케이션이 실패할 수 있습니다. TLS 연결을 사용하도록 설정하는 방법을 알아보려면 애플리케이션 설명서를 참조하세요.
PSQL으로 연결하십시오
다음 예제에서는 명령줄 인터페이스를 사용하여 PSQL 서버에 연결하는 방법을 보여 줍니다.
sslmode=verify-full 또는 sslmode=verify-ca 연결 문자열 설정을 사용하여 TLS 인증서 확인을 적용합니다. 로컬 인증서 파일 경로를 sslrootcert 매개 변수에 전달합니다.
psql "sslmode=verify-full sslrootcert=<path-of-pem-file> host=mydemoserver.postgres.database.azure.com dbname=postgres user=myadmin"
TLS 연결 테스트
TLS 사용 서버에 클라이언트 애플리케이션 PSQL에서 액세스하기 전에, PSQL를 통해 해당 서버에 접근할 수 있는지 확인하십시오. TLS 연결을 설정한 경우 다음 예제와 유사한 출력이 표시됩니다.
psql (14.5)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
sslinfo 확장을 로드한 다음 함수를 ssl_is_used() 호출하여 TLS가 사용되고 있는지 확인할 수도 있습니다. 연결에서 TLS를 사용하는 경우 함수가 반환 t 됩니다. 그 외의 경우 f를 반환합니다.
Java 키 저장소에서 프로그래밍 방식으로 신뢰할 수 있는 인증서 목록 가져오기
기본적으로 Java는 클라이언트의 Java 설치 폴더 내에 있는 특수 cacerts 파일에 신뢰할 수 있는 인증서를 저장합니다.
아래 예제에서는 먼저 cacerts 개체를 읽고 로드합니다.
private KeyStore loadKeyStore() {
String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
String filename = System.getProperty("java.home") + relativeCacertsPath;
FileInputStream is = new FileInputStream(filename);
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
String password = "changeit";
keystore.load(is, password.toCharArray());
return keystore;
}
기본 암호 cacerts 는 changeit 실제 클라이언트에서 달라야 합니다. 관리자가 Java 설치 직후 암호를 변경하는 것이 좋습니다.
KeyStore 개체를 로드한 후에는 PKIXParameters 클래스를 사용하여 존재하는 인증서를 읽을 수 있습니다.
public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
KeyStore keyStore = loadKeyStore();
PKIXParameters params = new PKIXParameters(keyStore);
Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
List<Certificate> certificates = trustAnchors.stream()
.map(TrustAnchor::getTrustedCert)
.collect(Collectors.toList());
assertFalse(certificates.isEmpty());
}