Azure Database for PostgreSQL - 유연한 서버에서 TLS 및 SSL을 사용하여 보안 연결

적용 대상: Azure Database for PostgreSQL - 유연한 서버

Azure Database for PostgreSQL - 유연한 서버는 TLS(전송 계층 보안)를 사용하여 클라이언트 애플리케이션을 Azure Database for PostgreSQL - 유연한 서버에 연결하도록 적용합니다. TLS는 데이터베이스 서버와 클라이언트 애플리케이션 간에 암호화된 네트워크 연결을 보장하는 업계 표준 프로토콜입니다. TLS는 SSL(Secure Sockets Layer)의 업데이트된 프로토콜입니다.

TLS란? 

TLS는 Netscape의 SSL 프로토콜로 만들어졌으며 정기적으로 대체되었습니다. SSL 또는 TLS/SSL이라는 용어는 여전히 서로 바꿔서 사용됩니다. TLS는 TLS 레코드 쇼와 TLS 핸드셰이크 쇼의 두 계층으로 구성됩니다. 레코드 쇼는 연결 보안을 제공합니다. 핸드셰이크 쇼를 통해 서버와 고객은 정보를 거래하기 전에 서로를 확인하고 암호화 평가 및 암호화 키를 조정할 수 있습니다.

위의 다이어그램은 다음 단계로 구성된 일반적인 TLS 1.2 핸드셰이크 시퀀스를 보여 줍니다.

1. 클라이언트는 TLS 1.2를 통해 클라이언트가 지원하는 암호 그룹 집합과 통신할 의향이 있음을 나타내는 메시지를 ClientHello 보내는 것으로 시작합니다.
2. 서버는 메시지를 받고, 답변하며 ServerHello, 특정 암호 그룹을 사용하여 TLS 1.2를 통해 클라이언트와 통신하는 데 동의합니다.
3. 또한 서버는 키 공유를 보냅니다. 이 키 공유의 세부 정보는 선택한 암호 그룹을 기반으로 변경됩니다. 클라이언트와 서버가 암호화 키에 동의하려면 서로의 부분을 받거나 공유해야 합니다.
4. 서버는 인증서(CA]에 의해 서명된 인증서와 해당 부분 및 에 대한 서명을 보냅니다 ClientHello ServerHello. 키 공유도 포함됩니다. 이러한 방식으로 클라이언트는 자신이 정통임을 알고 있습니다.
5. 클라이언트가 데이터를 성공적으로 수신한 다음 자체 키 공유를 생성한 후 서버 키 공유와 혼합하여 세션에 대한 암호화 키를 생성합니다.
6. 클라이언트는 서버에 키 공유를 보내고, 암호화를 사용하도록 설정하고, 메시지를 보냅니다 Finished . 이 메시지는 지금까지 무슨 일이 있었는지에 대한 성적 증명서의 해시입니다. 서버도 마찬가지입니다. 키 공유를 혼합하여 키를 가져와서 자체 Finished 메시지를 보냅니다.
7. 이제 연결에서 애플리케이션 데이터를 암호화하여 보낼 수 있습니다.

인증서 체인

인증서 체인은 TLS/SSL 인증서 및 CA 인증서를 포함하는 순서가 지정된 인증서 목록입니다. 수신자가 보낸 사람 및 모든 CA가 신뢰할 수 있는지 확인할 수 있습니다. 체인 또는 경로는 TLS/SSL 인증서로 시작합니다. 체인의 각 인증서는 체인의 다음 인증서로 식별되는 엔터티에 의해 서명됩니다.

체인은 루트 CA 인증서로 끝납니다. 이 인증서는 항상 CA 자체에서 서명됩니다. 체인에 있는 모든 인증서의 서명은 마지막 루트 CA 인증서까지 확인되어야 합니다.

TLS/SSL 인증서와 체인의 루트 CA 인증서 사이에 있는 모든 인증서를 중간 인증서라고 합니다.

TLS 버전

전 세계 여러 정부 기관은 네트워크 보안과 관련된 TLS에 대한 지침을 유지 관리합니다. 미국 이러한 조직에는 보건 복지부와 국립 표준 기술 연구소가 포함됩니다. TLS가 제공하는 보안 수준은 TLS 프로토콜 버전과 지원되는 암호화 그룹의 영향을 가장 많이 받습니다.

암호 그룹은 암호, 키 교환 알고리즘 및 해시 알고리즘을 포함하는 알고리즘 집합입니다. 보안 TLS 연결을 설정하기 위해 함께 사용됩니다. 대부분의 TLS 클라이언트 및 서버는 여러 대안을 지원합니다. 공통 TLS 버전 및 암호 그룹을 선택하기 위해 보안 연결을 설정할 때 협상해야 합니다.

Azure Database for PostgreSQL은 TLS 버전 1.2 이상을 지원합니다. RFC 8996에서 IETF(Internet Engineering Task Force)는 TLS 1.0 및 TLS 1.1을 사용해서는 안 된다고 명시하고 있습니다. 두 프로토콜 모두 2019년 말부터 더 이상 사용되지 않습니다.

TLS 1.0 및 TLS 1.1과 같은 이전 버전의 TLS 프로토콜을 사용하는 모든 수신 연결은 기본적으로 거부됩니다.

IETF는 2018년 8월 RFC 8446에서 TLS 1.3 사양을 릴리스했으며, TLS 1.3은 현재 가장 일반적이고 권장되는 TLS 버전입니다. TLS 1.3은 TLS 1.2보다 빠르고 안전합니다.

참고 항목

SSL 및 TLS 인증서는 연결이 최첨단 암호화 프로토콜로 보호됨을 인증합니다. 유선 연결을 암호화하면 전송 중에 데이터에 대한 무단 액세스를 방지할 수 있습니다. 최신 버전의 TLS를 사용하여 Azure Database for PostgreSQL - 유연한 서버에 대한 연결을 암호화하는 것이 좋습니다.

권장하지는 않지만 필요한 경우 Azure Database for PostgreSQL - 유연한 서버에 연결하기 위해 TLS\SSL을 사용하지 않도록 설정할 수 있습니다. 서버 매개 변수를 .로 require_secure_transport 업데이트할 OFF수 있습니다. 설정 및 ssl_max_protocol_version 서버 매개 변수를 사용하여 ssl_min_protocol_version TLS 버전을 설정할 수도 있습니다.

인증서 인증 은 인증에 SSL 클라이언트 인증서를 사용하여 수행됩니다. 이 시나리오에서 PostgreSQL 서버는 제공된 클라이언트 인증서의 CN(일반 이름) 특성을 요청된 데이터베이스 사용자와 비교합니다.

현재 Azure Database for PostgreSQL - 유연한 서버는 다음을 지원하지 않습니다.

• SSL 인증서 기반 인증.
• 사용자 지정 SSL\TLS 인증서입니다.

참고 항목

Microsoft는 Azure Database for PostgreSQL - 유연한 서버를 포함하여 다양한 Azure 서비스에 대한 루트 CA를 변경했습니다. 자세한 내용은 Azure TLS 인증서 변경 내용 및 클라이언트에서 SSL 구성 섹션 을 참조하세요.

현재 TLS\SSL 연결 상태를 확인하려면 sslinfo 확장을 로드한 다음, ssl_is_used() 함수를 호출하여 SSL이 사용되고 있는지 확인할 수 있습니다. 연결에서 SSL을 사용하는 경우 함수가 반환 t 됩니다. 그 외의 경우 f를 반환합니다. 다음 쿼리를 사용하여 프로세스, 클라이언트 및 애플리케이션별로 Azure Database for PostgreSQL 유연한 서버의 SSL 사용량에 대한 모든 정보를 수집할 수도 있습니다.

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

테스트를 위해 명령을 직접 사용할 openssl 수도 있습니다.

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

이 명령은 TLS 버전 및 암호와 같은 하위 수준 프로토콜 정보를 출력합니다. -starttls postgres 옵션을 사용해야 합니다. 그렇지 않으면 이 명령은 SSL이 사용되지 않는다고 보고합니다. 이 명령을 사용하려면 OpenSSL 1.1.1 이상이 필요합니다.

클라이언트에서 Azure Database for PostgreSQL - 유연한 서버로의 연결 보호를 위해 가장 안전한 최신 TLS 버전을 적용하려면 다음으로 1.3설정합니다ssl_min_protocol_version. 이 설정을 사용하려면 Azure Database for PostgreSQL 유연한 서버에 연결하는 클라이언트가 이 버전의 프로토콜을 사용하여 안전하게 통신해야 합니다. 이전 클라이언트는 이 버전을 지원하지 않으므로 서버와 통신하지 못할 수 있습니다.

클라이언트에서 SSL 구성

기본적으로 PostgreSQL은 서버 인증서의 확인을 수행하지 않습니다. 이러한 이유로 클라이언트를 모르고 서버 ID(예: DNS 레코드를 수정하거나 서버 IP 주소를 인수)를 스푸핑할 수 있습니다. 모든 SSL 옵션은 암호화 및 키 교환의 형태로 오버헤드를 수행하므로 성능과 보안 간에 장차가 발생합니다.

스푸핑을 방지하려면 클라이언트에서 SSL 인증서 확인을 사용해야 합니다.

SSL에 대한 클라이언트를 구성하기 위한 많은 연결 매개 변수가 있습니다. 몇 가지 중요한 사항은 다음과 같습니다.

• ssl: SSL을 사용하여 연결합니다. 이 속성에는 연결된 값이 필요하지 않습니다. 단순히 존재하는 것만으로 SSL 연결을 지정합니다. 이후 버전과의 호환성을 위해 값 true 이 선호됩니다. 이 모드에서 SSL 연결을 설정할 때 클라이언트 드라이버는 서버 ID의 유효성을 검사하여 중간에서 맨 인 더 미들 공격을 방지합니다. 서버 인증서가 신뢰할 수 있는 기관에서 서명하고 연결하는 호스트가 인증서의 호스트 이름과 같은지 확인합니다.

• sslmode: 암호화가 필요하고 암호화할 수 없는 경우 연결이 실패하도록 하려면 설정합니다 sslmode=require. 이 설정은 서버가 이 호스트/IP 주소에 대한 SSL 연결을 허용하도록 구성되고 서버가 클라이언트 인증서를 인식하도록 합니다. 서버가 SSL 연결을 허용하지 않거나 클라이언트 인증서가 인식되지 않으면 연결이 실패합니다. 다음 표에서는 이 설정의 값을 나열합니다.

  SSL 모드	설명
  disable	암호화는 사용되지 않습니다.
  allow	암호화는 서버 설정에 필요하거나 적용하는 경우에 사용됩니다.
  prefer	암호화는 서버 설정이 허용하는 경우 사용됩니다.
  require	암호화가 사용되지 않음 서버가 이 호스트 IP 주소에 대한 SSL 연결을 허용하도록 구성되고 서버가 클라이언트 인증서를 인식하도록 합니다.
  verify-ca	암호화가 사용되지 않음 클라이언트에 저장된 인증서에 대해 서버 인증서 서명을 확인합니다.
  verify-full	암호화가 사용되지 않음 클라이언트에 저장된 인증서에 대해 서버 인증서 서명 및 호스트 이름을 확인합니다.

  사용되는 기본 sslmode 모드는 libpq 기반 클라이언트(예: psql)와 JDBC 간에 다릅니다. libpq 기반 클라이언트는 기본적으로 prefer. JDBC 클라이언트의 기본값은 .입니다 verify-full.

• sslcert, sslkey및 sslrootcert: 이러한 매개 변수는 클라이언트 인증서, PKCS-8 클라이언트 키 및 루트 인증서의 기본 위치를 재정의할 수 있습니다. 기본값/defaultdir/postgresql.crt/defaultdir/postgresql.pk8/defaultdir/root.crt은 각각 닉스 시스템과 %appdata%/postgresql/ Windows에 있습니다.defaultdir ${user.home}/.postgresql/

CA는 인증서 발급을 담당하는 기관입니다. 신뢰할 수 있는 인증 기관은 누군가가 자신이 누구인지 확인할 자격이 있는 엔터티입니다. 이 모델이 작동하려면 모든 참가자가 신뢰할 수 있는 CA 집합에 동의해야 합니다. 모든 운영 체제와 대부분의 웹 브라우저는 신뢰할 수 있는 CA 집합과 함께 제공됩니다.

사용 verify-ca 및 verify-full sslmode 구성 설정을 인증서 고정이라고도 합니다. 이 경우 PostgreSQL 서버의 루트 CA 인증서는 인증서 서명과 클라이언트의 인증서에 대한 호스트 이름과 일치해야 합니다.

CA가 PostgreSQL 서버 인증서에서 변경되거나 만료될 때 클라이언트에 저장된 인증서를 주기적으로 업데이트해야 할 수 있습니다. CA를 고정하는지 확인하려면 인증서 고정 및 Azure 서비스를 참조 하세요.

클라이언트의 SSL\TLS 구성에 대한 자세한 내용은 PostgreSQL 설명서를 참조하세요.

사용하는 verify-ca 클라이언트 및 verify-full sslmode 구성 설정(즉, 인증서 고정)의 경우 클라이언트 인증서 저장소에 세 개의 루트 CA 인증서를 배포해야 합니다.

• DigiCert 글로벌 루트 G2 및 Microsoft RSA 루트 CA 2017 루트 CA 인증서는 서비스가 Digicert에서 Microsoft CA로 마이그레이션되기 때문입니다.
• 레거시 호환성을 위한 Digicert 글로벌 루트 CA입니다.

인증서 고정 시나리오에서 루트 CA 인증서 다운로드 및 애플리케이션 클라이언트 업데이트

인증서 고정 시나리오에서 클라이언트 애플리케이션을 업데이트하려면 인증서를 다운로드할 수 있습니다.

• Microsoft RSA Root CA 2017
• DigiCert Global Root G2
• Digicert 글로벌 루트 CA

인증서를 클라이언트 인증서 저장소로 가져오려면 이전 URI에서 인증서 파일을 다운로드한 후 인증서 .crt 파일을 .pem 형식으로 변환해야 할 수 있습니다. OpenSSL 유틸리티를 사용하여 다음 파일 변환을 수행할 수 있습니다.

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

새 루트 CA 인증서를 사용하여 클라이언트 애플리케이션 인증서 저장소를 업데이트하는 방법에 대한 정보는 애플리케이션 클라이언트에 대한 업데이트 클라이언트 TLS 인증서에 설명되어 있습니다.

Important

설정을 사용하는 sslmode=verify-full 동안 일부 Postgres 클라이언트 라이브러리는 중간 인증서로 교차 서명된 루트 CA 인증서로 연결 오류가 발생할 수 있습니다. 그 결과 대체 신뢰 경로가 생성됩니다. 이 경우 매개 변수를 명시적으로 지정하는 sslrootcert 것이 좋습니다. 또는 환경 변수를 PGSSLROOTCERT 기본값 %APPDATA%\postgresql\root.crt에서 Microsoft RSA 루트 CA 2017 루트 CA 인증서가 배치되는 로컬 경로로 설정합니다.

인증서 고정 시나리오를 사용하여 복제본 읽기

Microsoft RSA 루트 CA 2017로 루트 CA 마이그레이션을 사용하면 새로 만든 복제본이 이전에 만든 주 서버보다 최신 루트 CA 인증서에 있을 수 있습니다. 사용 및 verify-full sslmode 구성 설정(즉, 인증서 고정)을 사용하는 verify-ca 클라이언트의 경우 중단된 연결에서 다음 세 개의 루트 CA 인증서를 수락해야 합니다.

• Microsoft RSA Root CA 2017
• DigiCert Global Root G2
• Digicert 글로벌 루트 CA

현재 Azure Database for PostgreSQL - 유연한 서버는 인증서 기반 인증을 지원하지 않습니다.

인증서 고정 시나리오에서 psql과 연결하여 클라이언트 인증서 테스트

클라이언트의 명령줄을 psql 사용하여 인증서 고정 시나리오에서 서버에 대한 연결을 테스트할 수 있습니다.

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

SSL 및 인증서 매개 변수에 대한 자세한 내용은 psql 설명서를 참조 하세요.

TLS/SSL 연결 테스트

클라이언트 애플리케이션에서 SSL 사용 서버에 액세스하기 전에 psql을 통해 액세스할 수 있는지 확인합니다. SSL 연결을 설정한 경우 다음 예제와 유사한 출력이 표시됩니다.

psql(14.5)SSL 연결(프로토콜: TLSv1.2, 암호화: ECDHE-RSA-AES256-GCM-SHA384, 비트: 256, 압축: 해제)지원을 받으려면 "help"를 입력합니다.

sslinfo 확장을 로드한 다음 함수를 ssl_is_used() 호출하여 SSL이 사용되고 있는지 확인할 수도 있습니다. 연결에서 SSL을 사용하는 경우 함수가 반환 t 됩니다. 그 외의 경우 f를 반환합니다.

암호 그룹

암호화 제품군은 암호화 알고리즘의 집합입니다. TLS/SSL 프로토콜은 암호 도구 모음의 알고리즘을 사용하여 키를 만들고 정보를 암호화합니다.

암호 그룹은 임의로 보이는 정보의 긴 문자열로 표시되지만 해당 문자열의 각 세그먼트에는 필수 정보가 포함됩니다. 일반적으로 이 데이터 문자열에는 다음과 같은 몇 가지 주요 구성 요소가 포함됩니다.

• 프로토콜(즉, TLS 1.2 또는 TLS 1.3)
• 키 교환 또는 규약 알고리즘
• 디지털 서명(인증) 알고리즘
• 대량 암호화 알고리즘
• MAC(메시지 인증 코드 알고리즘)

서로 다른 버전의 TLS/SSL은 서로 다른 암호 그룹을 지원합니다. TLS 1.2 암호 그룹은 TLS 1.3 연결과 협상할 수 없으며 그 반대의 경우도 마찬가지입니다.

현재 Azure Database for PostgreSQL - 유연한 서버는 HIGH:!aNULL 범주에 속하는 TLS 1.2 프로토콜 버전을 사용하여 많은 암호 그룹을 지원합니다.

TLS/SSL 연결 오류 문제 해결

1. TLS/SSL 프로토콜 버전 호환성 문제를 해결하는 첫 번째 단계는 클라이언트에서 TLS 암호화에서 Azure Database for PostgreSQL 유연한 서버에 액세스하려고 할 때 사용자 또는 사용자가 보고 있는 오류 메시지를 식별하는 것입니다. 애플리케이션 및 플랫폼에 따라 오류 메시지가 다를 수 있습니다. 대부분의 경우 기본 문제를 가리킵니다.

2. TLS/SSL 프로토콜 버전 호환성을 확인하려면 데이터베이스 서버 및 애플리케이션 클라이언트의 TLS/SSL 구성을 확인하여 호환되는 버전 및 암호 그룹을 지원하는지 확인합니다.

3. 데이터베이스 서버와 클라이언트의 TLS/SSL 버전 및 암호 그룹 간의 불일치 또는 간격을 분석합니다. 특정 옵션을 사용하거나 사용하지 않도록 설정하거나, 소프트웨어를 업그레이드 또는 다운그레이드하거나, 인증서 또는 키를 변경하여 해결해 보세요. 예를 들어 보안 및 호환성 요구 사항에 따라 서버 또는 클라이언트에서 특정 TLS/SSL 버전을 사용하거나 사용하지 않도록 설정해야 할 수 있습니다. 예를 들어 안전하지 않고 사용되지 않는 것으로 간주되는 TLS 1.0 및 TLS 1.1을 사용하지 않도록 설정하고, 더 안전하고 최신인 TLS 1.2 및 TLS 1.3을 사용하도록 설정해야 할 수 있습니다.

4. Microsoft RSA Root CA 2017에서 발급된 최신 인증서는 Digicert Global Root G2 CA에서 교차 서명된 체인의 중간 인증서를 가집니다. 일부 Postgres 클라이언트 라이브러리는 사용 또는 sslmode=verify-ca 설정을 사용하는 sslmode=verify-full 동안 중간 인증서로 교차 서명된 루트 CA 인증서로 연결 오류가 발생할 수 있습니다. 그 결과 대체 신뢰 경로가 생성됩니다.

   이러한 문제를 해결하려면 클라이언트 인증서 저장소에 필요한 세 개의 인증서를 모두 추가하거나 매개 변수를 sslrootcert 명시적으로 지정합니다. 또는 환경 변수를 PGSSLROOTCERT 기본값 %APPDATA%\postgresql\root.crt에서 Microsoft RSA 루트 CA 2017 루트 CA 인증서가 배치되는 로컬 경로로 설정합니다.

관련 콘텐츠

• Azure Portal 또는 Azure CLI에서 프라이빗 액세스(VNet 통합) 옵션을 사용하여 Azure Database for PostgreSQL 유연한 서버를 만드는 방법을 알아봅니다.
• Azure Portal 또는 Azure CLI에서 공용 액세스(허용된 IP 주소) 옵션을 사용하여 Azure Database for PostgreSQL 유연한 서버를 만드는 방법을 알아봅니다.