Schannel SSP 기술 개요
게시 날짜: 2016년 8월
적용 대상: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8
이 참조 항목은 IT 전문가를 위한 내용으로, Schannel(Secure Channel) SSP(Security Support Provider)의 개념과 Schannel SSP가 TLS(Transport Layer Security) 및 SSL(Secure Sockets Layer) 프로토콜을 사용하여 제공하는 인증 서비스를 설명합니다.
이 항목에는 다음 섹션이 포함되어 있습니다.
TLS, SSL 및 Schannel이란?
일반적인 TLS 및 SSL 시나리오
TLS 및 SSL 종속성
TLS, SSL 및 Schannel이란?
네트워크를 관리할 때 해결할 한 가지 문제는 신뢰할 수 없는 네트워크의 응용 프로그램 간에 전송되는 데이터를 보호하는 것입니다. TLS/SSL을 사용하여 서버와 클라이언트 컴퓨터를 인증한 다음 인증된 대상 간의 메시지를 암호화할 수 있습니다.
TLS 프로토콜, SSL 프로토콜, DTLS 프로토콜 및 PCT(Private Communications Transport) 프로토콜은 공개 키 암호화를 기반으로 합니다. Schannel 인증 프로토콜 모음은 이러한 프로토콜을 제공합니다. 모든 Schannel 프로토콜은 클라이언트 및 서버 모델을 사용합니다. 지원되는 프로토콜 목록은 Schannel SSP에서 지원되는 암호 그룹 및 프로토콜을 참조하세요.
인증 프로세스에서 TLS/SSL 클라이언트 컴퓨터는 TLS/SSL 서버에 메시지를 전송하고 서버는 적절한 정보로 응답하여 자신을 인증합니다. 클라이언트 및 서버가 세션 키 교환을 추가로 수행하고 인증 대화 상자가 종료됩니다. 인증이 완료되면 인증 프로세스 중에 설정된 대칭 암호화 키를 사용하여 서버와 클라이언트 간에 SSL 통신이 시작될 수 있습니다.
클라이언트에 인증할 서버에 대한 TLS/SSL에서는 Active Directory 도메인 서비스와 같은 데이터베이스 또는 도메인 컨트롤러에 서버 키를 저장할 필요가 없습니다. 클라이언트는 Windows Server 운영 체제를 설치할 때 로드된 신뢰할 수 있는 루트 CA(인증 기관) 인증서를 사용하여 서버 자격 증명의 유효성을 확인합니다. 따라서 서버에서 사용자 인증이 필요하지 않은 한 사용자는 서버와의 보안 연결을 만들기 전에 계정을 설정할 필요가 없습니다.
TLS 및 SSL에 대한 기록 및 표준
SSL은 World Wide Web을 통한 트랜잭션을 보호하려고 1994년 Netscape Communications Corporation에서 개발되었습니다. 머지않아 IETF(Internet Engineering Task Force)가 같은 기능을 제공하는 표준 프로토콜을 개발하기 시작했습니다. IETF는 TLS로 발전된 SSL 3.0을 해당 작업의 기준으로 사용했습니다. Windows Server 2003부터 TLS 프로토콜의 구현은 IETF RFC 데이터베이스에 나열된 다음 사양에 정의된 사양을 충실히 따릅니다.
TLS 및 SSL은 웹 브라우저와 웹 서버 간의 인터넷 트랜잭션에 대한 보안 HTTP(HTTPS)를 제공하는 것으로 가장 널리 인식되는 프로토콜입니다. TLS/SSL은 FTP(File Transfer Protocol), LDAP(Lightweight Directory Access Protocol), SMTP(Simple Mail Transfer Protocol) 등의 다른 응용 프로그램 수준 프로토콜에도 사용할 수 있습니다. TLS/SSL을 사용하여 World Wide Web 등의 네트워크를 통한 서버 인증, 클라이언트 인증, 데이터 암호화 및 데이터 무결성을 구현할 수 있습니다.
TLS 및 SSL의 차이점
SSL 3.0과 TLS 버전 간에는 약간 차이점이 있지만 이 참조 가이드는 프로토콜을 TLS/SSL로 참조합니다.
참고
TLS 및 SSL 3.0은 차이점이 사소하더라도 서로 호환되지 않습니다. 클라이언트와 서버에서 같은 프로토콜이 지원되지 않으면 클라이언트와 서버는 성공적으로 통신하려면 일반 프로토콜을 협상해야 합니다.
SSL은 증가하는 보안 공격에 취약했기 때문에 IETF는 더 안전한 프로토콜에 대한 인터넷 표준으로 TLS를 개발했습니다. 다음 목록에서는 신뢰할 수 없는 네트워크를 통한 통신을 보호하기 위한 SSL 기능을 넘어선 TLS의 향상된 기능을 설명합니다.
키가 지정된 HMAC(해시 메시지 인증 코드) 알고리즘이 SSL MAC(메시지 인증 코드) 알고리즘을 대체합니다.
TLS는 표준화되고 인터넷 표준이지만 SSL에는 다양한 변형이 있습니다.
TLS에는 추가 경고 메시지가 포함됩니다.
SSL에는 루트 CA에서 발급되거나 다시 루트 CA에 연결된 인증서가 필요합니다. TLS를 선택할 경우 항상 다시 루트 CA에 연결된 인증서를 포함해야 하는 것은 아닙니다. 중간 기관을 사용할 수 있습니다.
Fortezza 알고리즘은 공개 검토용으로 공개되지 않으므로 TLS RFC에 포함되지 않습니다.
TLS 및 SSL의 이점
TLS/SSL은 클라이언트 및 서버에 대한 다른 인증 방법 사용보다 다양한 이점을 제공합니다. 다음 표에서는 이들 일부 이점에 대해 설명합니다.
이점 |
설명 |
|---|---|
강력한 인증, 메시지 개인 정보 및 무결성 |
TLS/SSL을 통해 암호화를 사용하여 전송된 데이터를 보호할 수 있습니다. TLS/SSL은 서버를 인증하고 선택적으로 클라이언트를 인증하여 보안 통신에 관련된 시스템의 ID를 증명합니다. 또한 무결성 검사 값을 통해 데이터 무결성을 제공합니다. 데이터 공개 방지 이외에 TLS/SSL 보안 프로토콜을 사용하여 가상 공격, 메시지 가로채기(man-in-the-middle 또는 bucket-brigade) 공격, 롤백 공격, 재생 공격을 방지할 수 있습니다. |
상호 운용성 |
TLS/SSL은 대부분 웹 브라우저와 대부분 운영 체제 및 웹 서버에서 작동합니다. 이 프로토콜은 종종 뉴스 리더, LDAP 서버 및 다양한 기타 상업적으로 사용할 수 있는 응용 프로그램에 통합됩니다. |
알고리즘 유연성 |
TLS/SSL은 보안 세션에서 사용되는 인증 메커니즘, 암호화 알고리즘 및 해시 알고리즘에 대한 옵션을 제공합니다. |
간편한 배포 |
대부분 응용 프로그램은 Windows Server 운영 체제에서 TLS/SSL을 투명하게 사용합니다. Internet Explorer 및 IIS(인터넷 정보 서비스)를 사용할 때 더 안전한 검색을 위해 TLS를 사용할 수 있습니다. 서버에 서버 인증서가 설치되어 있으면 Internet Explorer에서 확인란을 선택하면 됩니다. |
사용 편의성 |
TLS/SSL은 응용 프로그램 계층 아래에 구현되므로 대부분 작업이 클라이언트 컴퓨터에 완전히 보이지 않습니다. 이에 따라 클라이언트에는 통신 보안에 대한 정보가 거의 포함되지 않고 공격으로부터 보호될 수 있습니다. |
TLS 및 SSL의 제한 사항
다음 표의 설명과 같이 TLS/SSL 사용에는 몇 가지 제한 사항이 있습니다.
제한 사항 |
설명 |
|---|---|
프로세서 부하 증가 |
이는 TLS/SSL 구현 시 가장 중요한 제한 사항입니다. 암호화, 특히 공개 키 작업은 CPU를 많이 사용합니다. 따라서 SSL을 사용할 경우 성능이 달라집니다. 아쉽게도 어느 정도 성능이 손실되는지 알 수 없습니다. 성능은 연결 설정 빈도 및 연결 지속 기간에 따라 달라집니다. TLS는 연결을 설정할 때 가장 큰 리소스를 사용합니다. |
관리 오버헤드 |
TLS/SSL 환경은 복잡하고 유지 관리가 필요합니다. 시스템 관리자는 시스템을 구성하고 인증서를 관리해야 합니다. |
일반적인 TLS 및 SSL 시나리오
대부분 사용자는 TLS 및 SSL을 웹 브라우저에서 인터넷을 더 안전하게 검색하는 데 사용되는 프로토콜로 생각합니다. 그러나 이들 프로토콜은 인증 및 데이터 보호가 필요할 때마다 사용할 수 있는 범용 프로토콜이기도 합니다. 사실, SSPI(Security Service Provider Interface)를 통해 이들 프로토콜에 액세스할 수 있다는 것은 거의 모든 응용 프로그램에 이들 프로토콜을 사용할 수 있음을 의미합니다. 대부분 응용 프로그램은 TLS/SSL 기능을 활용하도록 수정되고 있습니다. 다음 표에서는 TLS/SSL을 사용하는 방법에 대한 예를 제공합니다.
시나리오 |
설명 |
|---|---|
전자 상거래 웹 사이트의 SSL 트랜잭션 |
이 상황은 브라우저와 웹 서버 간에 발생하는 일반적인 SSL 사용을 나타냅니다. 예를 들어 전자 상거래 쇼핑 사이트에서는 고객이 신용 카드 번호를 제공해야 합니다. 프로토콜은 먼저 웹 사이트의 인증서가 유효한지 확인하고 신용 카드 정보를 암호화 텍스트로 전송합니다. 이 트랜잭션 유형에서 서버 인증서가 신뢰할 수 있는 출처에서 발급될 경우 서버에 대한 인증만 발생합니다. 데이터 트랜잭션이 발생하는 주문 양식과 같은 웹 페이지에서 TLS/SSL을 사용하도록 설정해야 합니다. |
SSL로 보호된 웹 사이트에 대한 인증된 클라이언트 액세스 |
클라이언트와 서버에는 상호 신뢰할 수 있는 CA(인증 기관)에서 발급한 인증서가 필요합니다. Schannel SSP를 사용하여 클라이언트 인증서를 일대일 또는 다대일 기준으로 Windows Server 운영 체제의 사용자 또는 컴퓨터 계정에 매핑할 수 있습니다. 그다음에 Active Directory 사용자 및 컴퓨터를 통해 인증서를 관리할 수 있고 암호 제공 없이 웹 사이트에서 사용자를 인증할 수 있습니다. 다대일 매핑은 여러 용도로 사용됩니다. 예를 들어 여러 사용자에게 기밀 자료에 대한 액세스 권한을 부여하려면 그룹을 만들고, 사용자 인증서를 그룹에 매핑하고, 자료에 대한 필요 권한을 그룹에 부여할 수 있습니다. 일대일 매핑에서 서버에는 클라이언트 인증서 복사본이 있고 사용자가 클라이언트 컴퓨터에서 로그인할 때 서버는 사용자가 동일한지 확인합니다. 이 일대일 매핑은 일반적으로 한 명의 개인만 개인 계정을 볼 권한을 가지는 은행 웹 사이트 등의 개인 자료에 사용됩니다. |
원격 액세스 |
Schannel SSP가 사용된 일반적인 예는 재택 근무입니다. 사용자가 원격으로 Windows 기반 시스템 또는 네트워크에 로그인할 때 이 기술을 사용하여 인증 및 데이터 보호를 제공할 수 있습니다. 사용자는 집에서나 이동 중에 엔터프라이즈 응용 프로그램이나 메일에 안전하게 액세스할 수 있으므로 인터넷에서 정보가 누군가에게 노출될 위험이 감소합니다. |
SQL Server 액세스 |
SQL Server를 실행하는 서버에 연결할 때 클라이언트 컴퓨터를 인증해야 할 수 있습니다. 클라이언트와 서버 간에 전송되는 데이터를 암호화하도록 클라이언트 또는 서버를 구성할 수 있습니다. 금융 및 의료 데이터베이스와 같은 매우 중요한 정보는 네트워크에 대한 무단 액세스 및 정보 공개를 차단하도록 보호할 수 있습니다. |
메일 |
Exchange Server를 사용하면 데이터가 인트라넷이나 인터넷에서 서버 간에 이동할 때 Schannel SSP를 사용하여 데이터를 보호할 수 있습니다. 전체 종단 간 보안에는 S/MIME(Secure/Multipurpose Internet Mail Extensions)를 사용해야 할 수 있습니다. 그러나 서버 간 교환에서 데이터 보호를 지원하는 기능을 통해 회사에서는 같은 회사, 자회사 및 파트너 내의 부서 간에 인터넷을 사용하여 메일을 안전하게 전송할 수 있습니다. S/MIME 사용 여부와 관계없이 이 작업을 할 수 있습니다. |
Schannel SSP 아키텍처
Windows Server 운영 체제에서 Schannel 인증 프로토콜 집합에는 TLS가 포함됩니다. 다음 다이어그램은 이들 프로토콜과 다른 기술에 맞게 Schannel SSP를 조정하는 경우를 보여 줍니다. 클라이언트 응용 프로그램이나 서버 응용 프로그램은 SSPI 호출을 통해 Secur32.dll을 사용하여 LSASS(Local Security Authority Subsystem Service)와 통신합니다.
Schannel SSP 아키텍처
.jpeg "Schannel Architecture")
다음 표에는 TLS/SSL에 참여하는 요소에 대한 설명이 나와 있습니다.
TLS 및 SSL 인증에 사용되는 보안 하위 시스템 요소
요소 |
설명 |
|---|---|
Schannel.dll |
TLS/SSL 인증 프로토콜. 이 프로토콜은 덜 안전한 클리어 채널 대신 암호화된 채널을 통해 인증을 제공합니다. |
Lsasrv.dll |
LSASS는 보안 정책을 적용하고 로컬 보안 기관에 대한 보안 패키지 관리자로 사용됩니다. |
Netlogon.dll |
TLS 서비스와 관련해서 Netlogon 서비스는 SSL 채널을 통해 사용자의 인증서 정보를 도메인 컨트롤러에 전달하여 사용자 인증서를 사용자 계정에 매핑합니다. |
Secur32.dll |
SSPI를 구현하는 여러 인증 공급자. |
인증 프로토콜 집합은 Windows Server 운영 체제에 대한 보안 서비스를 제공하는 SSPI API(응용 프로그래밍 인터페이스)에서 지원되는 Schannel SSP에 의해 활성화됩니다.
Microsoft SSPI(Security Support Provider Interface)는 Windows 운영 체제에서 인증에 사용되는 기본 기능입니다. 즉, 인증이 필요한 응용 프로그램 및 인프라 서비스는 SSPI를 사용하여 인증을 제공합니다. 더 안전하게 통신할 수 있도록 클라이언트 및 서버를 인증해야 하면 인증 요청이 SSPI로 라우트되고, SSPI는 현재 사용 중인 네트워크 프로토콜과 관계없이 인증 프로세스를 완료합니다. SSPI는 GSSAPI(Generic Security Service API)의 구현입니다. GSSAPI에 대한 자세한 내용은 IETF RFC 데이터베이스에서 다음 RFC를 참조하세요.
모든 SSP용 SSPI 아키텍처 및 이 아키텍처에 맞게 Kerberos 공급자를 조정하는 방법에 대한 자세한 내용은 Security Support Provider Interface Architecture를 참조하세요.
웹 페이지에 저장되는 개인 정보 또는 메일과 같은 웹 사용 서비스 액세스에 Schannel SSP를 사용할 수 있습니다. Schannel SSP는 공개 키 인증서를 사용하여 당사자를 인증합니다. 집합에는 네 가지 인증 프로토콜이 있습니다. 당사자를 인증할 때 다음 우선 순위로 네 가지 프로토콜의 하나를 선택합니다.
TLS 버전 1.2
TLS 버전 1.1
TLS 버전 1.0
SSL 버전 3.0
그다음에 Schannel SSP는 클라이언트와 서버에서 지원할 수 있는 가장 우선하는 인증 프로토콜을 선택합니다. 예를 들어 서버에서 네 가지 Schannel 프로토콜을 모두 지원하고 클라이언트 컴퓨터에서는 SSL 3.0만 지원하면 Schannel 공급자는 SSL 3.0을 인증에 사용합니다.
클라이언트 인증에 대한 신뢰할 수 있는 발급자 관리
Windows Server 2012 및 Windows 8 전에는 Schannel SSP를 사용하는 응용 프로그램 또는 프로세스(HTTP.sys 및 IIS 포함)에서 클라이언트 인증을 위해 지원하는 신뢰할 수 있는 발급자 목록을 제공할 수 있었습니다. 이 정보는 CTL(인증서 신뢰 목록)을 통해 제공되었습니다.
클라이언트 컴퓨터의 인증에 SSL 또는 TLS를 사용해야 하는 경우 신뢰할 수 있는 인증서 발급자 목록을 보내도록 서버를 구성할 수 있습니다. 이 목록에는 서버에서 신뢰하는 인증서 발급자 집합이 포함되며 여러 인증서가 있는 경우 선택할 클라이언트 인증서에 대한 힌트를 클라이언트 컴퓨터에 제공합니다. 또한 클라이언트 컴퓨터에서 서버로 보내는 인증서 체인은 신뢰할 수 있는 발급자 목록에 대해 유효성이 검사되어야 합니다.
Windows Server 2012 및 Windows 8에서 기본 인증 프로세스가 다음과 같이 변경되었습니다.
CTL 기반의 신뢰할 수 있는 발급자 목록 관리가 더 이상 지원되지 않습니다.
기본적으로 신뢰할 수 있는 발급자 목록을 전송하는 동작이 해제됩니다. SendTrustedIssuerList 레지스트리 키의 기본값은 이제 1이 아닌 0(기본적으로 해제)입니다.
이전 버전 Windows 운영 체제와의 호환성이 유지됩니다.
이를 통해 Windows PowerShell 공급자의 기존 인증서 관리 cmdlet 및 certutil.exe와 같은 명령줄 도구를 사용하여 더욱 친숙한 방법으로 관리할 수 있게 되었습니다. Schannel SSP가 지원하는 신뢰할 수 있는 인증 기관 목록의 최대 크기(16KB)는 Windows Server 2008 R2와 동일하지만 Windows Server 2012에는 관련되지 않은 인증서가 클라이언트/서버 메시지에 포함되지 않도록 클라이언트 인증 발급자에 대한 새로운 전용 인증서 저장소가 있습니다.
작동 방식
신뢰할 수 있는 발급자 목록이 인증서 저장소(기본 글로벌 컴퓨터 인증서 저장소와 사이트별로 선택 사항인 인증서 저장소)를 사용하여 구성됩니다. 목록의 원본은 다음과 같이 결정됩니다.
사이트의 대해 구성된 특정 인증서 저장소가 있는 경우 해당 인증서 저장소가 원본으로 사용됩니다.
인증서가 응용 프로그램 정의 저장소에 없으면 Schannel은 로컬 컴퓨터에서 클라이언트 인증 발급자 저장소를 확인합니다. 인증서가 있으면 Schannel이 해당 저장소를 원본으로 사용합니다.
글로벌 저장소와 로컬 저장소에 모두 인증서가 없는 경우 Schannel SSP는 신뢰할 수 있는 루트 인증 기관 저장소를 신뢰할 수 있는 발급자 목록의 원본으로 사용합니다. (또한 이는 Windows Server 2008 R2의 동작입니다.)
올바른 인증서를 선택하도록 최종 사용자에게 힌트를 제공하는 믿을 만한 인증서 발급자 이름 목록을 구성할 수 있습니다. 이 목록은 그룹 정책을 사용하여 구성할 수 있습니다.
신뢰할 수 있는 루트 인증 기관 저장소에 루트(자체 서명됨)와 CA(인증 기관) 발급자 인증서가 섞여서 포함되어 있는 경우에는 기본적으로 CA 발급자 인증서를 서버에 보냅니다.
Schannel이 신뢰할 수 있는 발급자의 인증서 저장소를 사용하도록 구성하는 방법
Schannel SSP는 이전에 설명한 것처럼 신뢰할 수 있는 발급자 목록을 관리하는 데 기본적으로 저장소를 사용합니다. 인증서를 관리하는 데 Windows PowerShell 공급자의 기존 인증서 관리 cmdlet 및 certutil.exe 같은 명령줄 도구를 계속 사용할 수 있습니다.
Windows PowerShell 공급자를 사용하여 인증서를 관리하는 방법에 대한 자세한 내용은 Windows의 AD CS 관리 Cmdlet을 참조하세요.
인증서 유틸리티를 사용하여 인증서를 관리하는 방법에 대한 자세한 내용은 certutil.exe를 참조하세요.
응용 프로그램 정의 저장소를 포함하여 Schannel 자격 증명에 대해 정의된 데이터에 대한 자세한 내용은 SCHANNEL_CRED 구조(Windows)를 참조하세요.
클라이언트 인증 발급자 저장소를 사용하도록 응용 프로그램 또는 기능 구성
일부 기술은 기본적으로 클라이언트 인증 발급자 저장소를 사용하지 않습니다. 이 경우 저장소를 사용하도록 해당 기술을 구성해야 합니다.
예를 들어 Windows HTTP-서버 스택을 구현하는 웹 서버 HTTP.sys는 기본적으로 클라이언트 인증 발급자 저장소를 사용하도록 구성되지 않습니다.
클라이언트 인증 발급자 저장소를 사용하도록 HTTP.SYS를 구성하려면 다음 명령을 사용합니다.
netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier} sslctlstorename=ClientAuthIssuer
서버에서 certhash 및 appid 값을 찾으려면 다음 명령을 사용합니다.
netsh http show sslcert
신뢰 모드의 기본값
Schannel SSP에서는 세 가지 클라이언트 인증 신뢰 모드를 지원합니다. 신뢰 모드는 클라이언트의 인증서 체인에 대해 유효성 검사를 수행하는 방식을 제어합니다. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel의 REG_DWORD “ClientAuthTrustMode”로 제어되는 시스템 차원의 설정입니다.
Value |
신뢰 모드 |
설명 |
|---|---|---|
0 |
컴퓨터 신뢰(기본값) |
클라이언트 인증서가 신뢰할 수 있는 발급자 목록의 인증서에서 발급되어야 합니다. |
1 |
단독 루트 신뢰 |
클라이언트 인증서가 호출자가 지정한 신뢰할 수 있는 발급자 저장소에 포함된 루트 인증서에 연결되어야 합니다. 또한 인증서가 신뢰할 수 있는 발급자 목록에서 발급되어야 합니다. |
2 |
단독 CA 신뢰 |
클라이언트 인증서가 호출자가 지정한 신뢰할 수 있는 발급자 저장소의 루트 인증서 또는 중간 CA 인증서에 연결되어야 합니다. |
신뢰할 수 있는 발급자 목록의 구성 문제로 인한 인증 실패에 대한 자세한 내용은 Microsoft 기술 자료 문서 280256(영문)을 참조하세요.
TLS 및 SSL 종속성
TLS 및 SSL이 제대로 작동하려면 여러 가지 관련 기술 및 리소스를 고려해야 합니다. 다음 표에서는 이러한 기술 및 리소스를 설명하고 이들 기술 및 리소스가 TLS/SSL 인증에 어떻게 관련되는지 간략히 설명합니다.
종속성 |
설명 |
|---|---|
운영 체제 |
TLS 및 SSL 인증은 Windows Server 운영 체제 및 Windows 클라이언트 운영 체제에 기본 제공된 클라이언트 기능에 의존합니다. 클라이언트 또는 서버에서 TLS/SSL을 지원하지 않는 운영 체제를 실행하면 TLS/SSL 인증을 사용할 수 없습니다. |
TCP/IP 네트워크 연결 |
TLS 또는 SSL 인증이 발생하려면 클라이언트와 대상 서버 간에 TCP/IP 네트워크 연결이 있어야 합니다. 자세한 내용은 TCP/IP를 참조하세요. |
Active Directory 도메인 |
서버 응용 프로그램에 클라이언트 인증이 필요한 경우 Schannel SSP가 클라이언트에서 사용자 계정에 제공하는 인증서를 자동으로 매핑하려고 합니다. 인증서 정보를 Windows 사용자 계정에 연결하는 매핑을 수동으로 만들어 클라이언트 인증서를 사용하여 로그인하는 사용자를 인증할 수 있습니다. 인증서 매핑을 만들고 사용하도록 설정하면 클라이언트가 인증서를 제공할 때마다 서버 응용 프로그램이 해당 사용자를 Windows 운영 체제의 적절한 사용자 계정에 자동으로 연결합니다. 인증서 매핑을 사용하려면 Active Directory 도메인 서비스의 사용자 계정을 사용해야 합니다. 자세한 내용은 Active Directory 도메인 서비스 개요를 참조하세요. |
신뢰할 수 있는 인증 기관 |
인증은 디지털 인증서를 사용하므로 Verisign 또는 Active Directory 인증서 서비스와 같은 CA(인증 기관)는 TLS/SSL의 중요한 부분입니다. CA는 인증서 요청자(일반적으로 사용자 또는 컴퓨터)의 ID를 확인한 다음 해당 요청자에게 인증서를 발급하는 상호 신뢰할 수 있는 Microsoft 이외의 인증서입니다. 인증서가 요청자의 ID를 공개 키로 바인딩합니다. 또한 CA는 필요에 따라 인증서를 갱신하고 해지합니다. 예를 들어 클라이언트가 서버의 인증서로 표시되면 해당 클라이언트 컴퓨터는 서버의 CA가 클라이언트의 신뢰할 수 있는 CA 목록과 일치하는지 여부를 확인하려 할 수 있습니다. 발급 CA를 신뢰할 수 있는 경우 클라이언트는 해당 인증서를 인증하고 변경되지 않았는지 확인합니다. CA에 대한 자세한 내용은 Active Directory 인증서 서비스 개요를 참조하세요. |