Microsoft.Data.SqlClient의 암호화 및 인증서 유효성 검사

ADO.NET 다운로드

전송 계층 보안(TLS)을 사용해 애플리케이션과 SQL Server 간의 트래픽을 암호화하세요. 서버 인증서 검증은 서버 신원을 확인하기 위해 활성화해 두세요. 신원 검증 없는 암호화는 서버를 가장하는 중간 공격 자로부터 보호하지 못합니다.

Microsoft.Data.SqlClient의 기본값은 Encrypt=Mandatory 및 TrustServerCertificate=false입니다. Encrypt=true 와 Mandatory는 동의어입니다. 원격 연결의 경우, 이 설정들을 명시적으로 요청하고 클라이언트가 검증할 수 있는 서버 인증서를 프로비저닝하세요:

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

플레이스홀더를 교체하고 서버와 애플리케이션 환경에서 지원하는 인증 방식을 사용하세요. Microsoft Fabric에서 Azure SQL 또는 SQL 데이터베이스에 대해서는 Microsoft Entra 인증을 참조하세요.

암호화 모드를 선택하세요

Encrypt 클라이언트가 암호화가 필요한지 여부를 제어합니다. 서버도 암호화를 요구할 수 있습니다. 다음 표는 인증서 핀닝 없이 현재 동작을 설명합니다:

클라이언트 설정 서버 요구 사항 인증서 유효성 검사 결과
Encrypt=Optional 또는 false 암호화를 강제하지는 않습니다. TrustServerCertificate와 관계없이 없습니다. 로그인 패킷만 암호화되어 있습니다. 이후 트래픽은 암호화되지 않습니다.
Encrypt=Optional;TrustServerCertificate=false 암호화를 강제합니다. 트러스트 체인, 유효성, 서버 이름. 모든 트래픽은 암호화되어 있습니다. 유효하지 않은 인증서는 연결이 실패합니다.
Encrypt=Optional;TrustServerCertificate=true 암호화를 강제합니다. 우회됨. 모든 트래픽은 암호화되어 있지만, 서버의 신원은 검증되지 않습니다.
Encrypt=Mandatory;TrustServerCertificate=false 어느 설정이든. 트러스트 체인, 유효성, 서버 이름. 모든 트래픽은 암호화되어 있습니다. 유효하지 않은 인증서는 연결이 실패합니다.
Encrypt=Mandatory;TrustServerCertificate=true 어느 설정이든 가능합니다. 우회됨. 모든 트래픽은 암호화되어 있지만, 서버의 신원은 검증되지 않습니다.
Encrypt=Strict 테이블 형식 데이터 스트림(TDS) 8.0을 지원합니다. 필수입니다. TrustServerCertificate 우회할 수 없어요. TLS는 TDS 메시지보다 먼저 시작됩니다. 지원되지 않는 서버나 유효하지 않은 인증서는 연결이 실패합니다.

TDS 8.0을 지원하지 않는 서버에 암호화 연결을 사용하려면 Mandatory을(를) 사용하세요. 엔드포인트가 TDS 8.0, SQL Server 2022(16.x) 및 이후 버전을 지원할 때 사용 Strict 하세요. TDS 8.0은 TLS 1.2와 TLS 1.3을 지원합니다. TLS 1.3은 필수가 아닙니다. 협상된 TLS 버전은 클라이언트, 서버, 운영체제 구성에 따라 달라집니다.

Optional 인증서 오류에 대한 해결책이 아닙니다. 서버가 암호화를 필요로 하지 않을 때는 애플리케이션 데이터를 암호화하지 않은 상태로 남겨둘 수 있습니다.

검증 가능한 서버 인증서를 설정하세요

일반적인 인증서 검증을 위해:

  1. SQL Server 인증서 요구사항을 충족하는 인증서를 프로비저닝하세요.
  2. 클라이언트가 연결하는 데 사용하는 이름은 인증서의 주제 대체명(SAN)에 포함하세요.
  3. 발급 인증서 기관과 필요한 중간 인증서는 모든 클라이언트 호스트나 컨테이너에서 신뢰하도록 만드세요.
  4. SQL Server가 인증서를 사용하도록 구성하고, 클라이언트에서 TrustServerCertificate=false를 유지하세요.
  5. 플랜 증명서 갱신은 만료 전에 이루어지며, 이름이나 발급 권한의 변경 사항도 포함됩니다.

공공 또는 기업 인증 기관의 인증서는 이러한 요구사항을 충족할 수 있습니다. 기업 인증서는 리눅스 컨테이너 내나 별도의 개발자 컴퓨터에서 자동으로 신뢰받지 않습니다.

별명으로 연결해

만약 연결이 인증서에 없는 도메인 네임 시스템(DNS) 별칭을 사용한다면, 먼저 별칭이 포함된 인증서를 발급하는 것을 고려해 보세요. 또는 인증서에서 예상되는 이름으로 설정 HostNameInCertificate 하세요:

Server=tcp:sql-alias.contoso.com,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=sql-server.contoso.com;MultiSubnetFailover=true;

HostNameInCertificate 인증서 검증 시 SqlClient가 기대하는 이름을 변경합니다. 네트워크 목적지를 변경하거나 신뢰 체인 및 만료 검사를 우회하지 않습니다. 서버 이름이 이미 인증서와 일치하면 설정하지 않은 상태로 두세요.

특정 서버 인증서를 핀 지정하세요

ServerCertificate 서버 인증서와 정확히 비교할 수 있도록 로컬 인증서 파일을 제공합니다. 지원되는 형식은 Privacy-Enhanced Mail(PEM) 및 Distinguished Encoding Rules(DER)이며, 여기에는 .cer 인증서 파일이 포함됩니다. Encrypt=Strict 또는 Encrypt=Mandatory와 함께 사용하고, TrustServerCertificate=false는 그대로 유지하세요.

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=Strict;TrustServerCertificate=false;ServerCertificate=C:\certificates\sql-server.cer;MultiSubnetFailover=true;

예상된 인증서를 신뢰할 수 있는 채널을 통해 배포하고 파일을 교체로부터 보호하세요. 정확한 인증서 일치는 일반적인 체인 및 이름 검증의 대안이지, 추가적인 검증이 아닙니다. 인증서 바이트가 일치해야 하며; 같은 주제 이름이나 공개키만으로는 충분하지 않습니다. 누락되거나 읽을 수 없거나 유효하지 않거나 일치하지 않는 핀 파일은 검증에 실패합니다.

핀 연결은 클라이언트 배포와 인증서 순환을 연결합니다. 서버 인증서가 변경될 때, 갱신 시 PIN을 업데이트하세요. 네트워크에서 검증되지 않은 인증서를 받아서 PIN을 얻지 마세요.

SqlClient는 임의의 TLS 서버 인증서 검증을 위한 공개 콜백을 노출하지 않습니다. AccessTokenCallback TLS 검증이 아니라 인증 토큰 획득을 제어합니다.

개발 인증서 및 문제 해결

올바른 서버 이름이 포함된 신뢰할 수 있는 개발 인증서를 사용하세요. 일시적으로 격리된 개발 환경에서 TrustServerCertificate=true를 Encrypt=true와 함께 사용하는 경우, 연결은 암호화되지만 클라이언트는 서버 인증서를 확인하지 않습니다.

주의

인증서 오류에 대한 프로덕션 패치로 배포 TrustServerCertificate=true 하지 마세요. 이 기능은 Mandatory에서는 서버 ID 유효성 검사를 비활성화하며, Strict에서는 효과가 없습니다.

Failure 확인
인증서 체인은 신뢰받지 못합니다. 클라이언트에 적절한 신뢰할 수 있는 루트와 중개자를 설치하세요. SQL Server가 실제로 제공하는 인증서를 확인하세요.
인증서 이름이 일치하지 않습니다. SAN 인증서와 비교해 보세요 Server . 이름, 인증서, 또는 의도적 HostNameInCertificate 무효화를 수정하세요.
증명서가 만료되었습니다. 서버 인증서를 갱신하고 클라이언트 시계를 확인하세요.
고정된 인증서가 일치하지 않거나 로드할 수 없습니다. 파일 경로, 권한, 형식, 배포된 인증서를 확인하세요. 신뢰하는 배포 절차를 통해 핀을 업데이트하세요.
엄격한 암호화로는 연결할 수 없습니다. 엔드포인트가 TDS 8.0을 지원하는지, 그리고 TLS 구성이 클라이언트와 호환되는지 확인하세요.

서버 측 구성에 대해서는 인증서 개요를 참조하세요.

암호화 및 인증서 유효성 검사 동작 변경 내용

이 호환성 노트는 구형 애플리케이션 업그레이드 시 동작 변화를 설명합니다. 새로운 애플리케이션은 이 문서에서 설명한 현재 설정을 사용해야 합니다.

드라이버 출시 변경
1.0 Encrypt=false 기본값입니다. 클라이언트가 암호화를 요청하지 않을 때, 서버 강제 암호화는 인증서 검증을 트리거하지 않습니다.
2.0 서버 강제 암호화는 Encrypt=false인 경우에도 TrustServerCertificate을 준수합니다.
4.0 암호화는 기본적으로 활성화됩니다. 업그레이드는 이전에 발견하지 못했던 인증서 구성 오류를 노출시킬 수 있습니다.
5.0 HostNameInCertificate, Optional, Mandatory 및 Strict를 추가합니다.
5.1 인증서 고정 기능을 추가 ServerCertificate 합니다.
7.0.3 누락되었거나 유효하지 않거나 일치하지 않는 파일이 있을 경우, 일반적인 플랫폼 검증이 성공하더라도 관리형 네트워킹 인증서 핀 검증이 닫힘 상태로 실패하도록 수정했습니다.