Windows 인증의 자격 증명 프로세스
적용 대상: Windows Server 2022, Windows Server 2019, Windows Server 2016
IT 전문가를 위한 이 참조 항목에서는 Windows 인증 자격 증명을 처리하는 방법을 설명합니다.
Windows 자격 증명 관리는 운영 체제가 서비스 또는 사용자로부터 자격 증명을 수신하고 향후 프레젠테이션을 위해 인증 대상에 대한 정보를 보호하는 프로세스입니다. do기본 조인된 컴퓨터의 경우 인증 대상은 do기본 컨트롤러입니다. 인증에 사용되는 자격 증명은 인증서, 암호 또는 PIN과 같은 특정 형태의 신뢰성 증명에 사용자의 ID를 연결하는 디지털 문서입니다.
기본적으로 Windows 자격 증명은 Winlogon 서비스를 통해 로컬 컴퓨터의 SAM(Security Accounts Manager) 데이터베이스 또는 do기본 조인 컴퓨터의 Active Directory에 대해 유효성을 검사합니다. 자격 증명은 로그온 사용자 인터페이스의 사용자 입력을 통해 수집되거나 인증 대상에 표시될 API(애플리케이션 프로그래밍 인터페이스)를 통해 프로그래밍 방식으로 수집됩니다.
로컬 보안 정보는 레지스트리의 HKEY_LOCAL_MACHINE\SECURITY에 저장됩니다. 저장된 정보에는 정책 설정, 기본 보안 값 및 계정 정보(예: 캐시된 로그온 자격 증명)가 포함됩니다. SAM 데이터베이스의 복사본은 쓰기 보호되지만 여기에 저장됩니다.
다음 다이어그램에서는 필요한 구성 요소와 자격 증명이 성공적인 로그온을 위해 사용자 또는 프로세스를 인증하기 위해 시스템을 통과하는 경로를 보여 줍니다.
다음 표에서는 로그온 시점의 인증 프로세스에서 자격 증명을 관리하는 각 구성 요소에 대해 설명합니다.
모든 시스템에 대한 인증 구성 요소
| 구성 요소 | 설명 |
|---|---|
| 사용자 로그온 | Winlogon.exe는 보안 사용자 상호 작용을 관리하는 실행 파일입니다. Winlogon 서비스는 보안 데스크톱(로그온 UI)에서 사용자 작업으로 수집한 자격 증명을 Secure32.dll을 통해 LSA(로컬 보안 기관)에 전달하여 Windows 운영 체제에 대한 로그온 프로세스를 시작합니다. |
| 애플리케이션 로그온 | 대화형 로그온이 필요하지 않은 애플리케이션 또는 서비스 로그온 사용자가 시작한 대부분의 프로세스는 Secur32.dll을 사용하여 사용자 모드에서 실행되는 반면, 서비스와 같이 시작 시 시작된 프로세스는 Ksecdd.sys를 사용하여 커널 모드로 실행됩니다. 사용자 모드 및 커널 모드에 대한 자세한 내용은 이 항목의 애플리케이션 및 사용자 모드 또는 서비스 및 커널 모드를 참조하세요. |
| Secur32.dll | 인증 프로세스의 기초를 형성하는 여러 인증 공급자입니다. |
| Lsasrv.dll | 보안 정책을 적용하고 LSA의 보안 패키지 관리자 역할을 하는 LSA 서버 서비스입니다. LSA에는 성공할 프로토콜을 결정한 후 NTLM 또는 Kerberos 프로토콜을 선택하는 Negotiate 함수가 포함되어 있습니다. |
| 보안 지원 공급자 | 하나 이상의 인증 프로토콜을 개별적으로 호출할 수 있는 공급자 집합입니다. 기본 공급자 집합은 Windows 운영 체제의 각 버전에 따라 변경될 수 있으며 사용자 지정 공급자를 작성할 수 있습니다. |
| Netlogon.dll | Net Logon 서비스에서 수행하는 서비스는 다음과 같습니다. - 컴퓨터의 보안 채널(Schannel과 혼동하지 않음)을 do기본 컨트롤러에 유지 관리합니다. |
| Samsrv.dll | 로컬 보안 계정을 저장하는 SAM(보안 계정 관리자)은 로컬로 저장된 정책을 적용하고 API를 지원합니다. |
| 등록 | 레지스트리에는 SAM 데이터베이스의 복사본, 로컬 보안 정책 설정, 기본 보안 값 및 시스템에서만 액세스할 수 있는 계정 정보가 포함됩니다. |
이 항목에는 다음과 같은 섹션이 포함되어 있습니다.
사용자 로그온에 대한 자격 증명 입력
Windows Server 2008 및 Windows Vista에서는 GINA(그래픽 식별 및 인증) 아키텍처가 자격 증명 공급자 모델로 대체되어 로그온 타일을 사용하여 다양한 로그온 형식을 열거할 수 있었습니다. 두 모델 모두 아래에 설명되어 있습니다.
그래픽 식별 및 인증 아키텍처
GINA(그래픽 식별 및 인증) 아키텍처는 Windows Server 2003, Microsoft Windows 2000 Server, Windows XP 및 Windows 2000 Professional 운영 체제에 적용됩니다. 이러한 시스템에서 모든 대화형 로그온 세션은 Winlogon 서비스의 별도 인스턴스를 만듭니다. GINA 아키텍처는 Winlogon에서 사용하는 프로세스 공간에 로드되고, 자격 증명을 수신 및 처리하며, LSALogonUser를 통해 인증 인터페이스를 호출합니다.
세션 0에서 실행되는 대화형 로그온에 대한 Winlogon 인스턴스입니다. 세션 0은 LSA(로컬 보안 기관) 프로세스를 포함하여 시스템 서비스 및 기타 중요한 프로세스를 호스트합니다.
다음 다이어그램에서는 Windows Server 2003, Microsoft Windows 2000 Server, Windows XP 및 Microsoft Windows 2000 Professional에 대한 자격 증명 프로세스를 보여 줍니다.
자격 증명 공급자 아키텍처
자격 증명 공급자 아키텍처는 이 항목의 시작 부분에 있는 적용 대상 목록에 지정된 버전에 적용됩니다. 이러한 시스템에서 자격 증명 입력 아키텍처는 자격 증명 공급자를 사용하여 확장 가능한 디자인으로 변경되었습니다. 이러한 공급자는 동일한 사용자에 대한 다양한 계정 및 암호, 스마트 카드 및 바이오 메트릭과 같은 다양한 인증 방법 등 다양한 로그온 시나리오를 허용하는 보안 데스크톱의 다양한 로그온 타일로 표시됩니다.
자격 증명 공급자 아키텍처를 사용하면 Winlogon은 보안 주의 시퀀스 이벤트를 받은 후 항상 로그온 UI를 시작합니다. 로그온 UI는 공급자가 열거하도록 구성된 다양한 자격 증명 형식의 수에 대해 각 자격 증명 공급자를 쿼리합니다. 자격 증명 공급자는 이러한 타일 중 하나를 기본값으로 지정할 수 있습니다. 모든 공급자가 타일을 열거하면 로그온 UI가 사용자에게 표시됩니다. 사용자가 타일과 상호 작용하여 자격 증명을 제공합니다. 로그온 UI는 인증을 위해 이러한 자격 증명을 제출합니다.
자격 증명 공급자는 적용 메커니즘이 아닙니다. 자격 증명을 수집하고 직렬화하는 데 사용됩니다. 로컬 보안 기관 및 인증 패키지는 보안을 적용합니다.
자격 증명 공급자는 컴퓨터에 등록되며 다음을 담당합니다.
인증에 필요한 자격 증명 정보를 설명합니다.
외부 인증 기관과의 통신 및 논리 처리
대화형 및 네트워크 로그온을 위한 패키징 자격 증명입니다.
대화형 및 네트워크 로그온에 대한 패키징 자격 증명에는 serialization 프로세스가 포함됩니다. 자격 증명을 직렬화하여 로그온 UI에 여러 로그온 타일을 표시할 수 있습니다. 따라서 조직은 사용자 지정 자격 증명 공급자를 사용하여 사용자, 로그온 대상 시스템, 네트워크에 대한 사전 로그온 액세스 및 워크스테이션 잠금/잠금 해제 정책과 같은 로그온 표시를 제어할 수 있습니다. 여러 자격 증명 공급자가 동일한 컴퓨터에 공존할 수 있습니다.
SSO(Single Sign-On) 공급자는 표준 자격 증명 공급자 또는 사전 로그온 액세스 공급자로 개발할 수 있습니다.
Windows의 각 버전에는 하나의 기본 자격 증명 공급자와 SSO 공급자라고도 하는 하나의 기본 PLAP(사전 로그온 액세스 공급자)가 포함되어 있습니다. SSO 공급자는 사용자가 로컬 컴퓨터에 로그온하기 전에 네트워크에 연결할 수 있도록 허용합니다. 이 공급자가 구현되면 공급자는 로그온 UI에서 타일을 열거하지 않습니다.
SSO 공급자는 다음 시나리오에서 사용됩니다.
네트워크 인증 및 컴퓨터 로그온은 서로 다른 자격 증명 공급자에 의해 처리됩니다. 이 시나리오의 변형은 다음과 같습니다.
사용자는 컴퓨터에 로그온하기 전에 VPN(가상 사설망) 연결과 같은 네트워크에 연결할 수 있지만 이 연결을 만들 필요는 없습니다.
로컬 컴퓨터에서 대화형 인증 중에 사용되는 정보를 검색하려면 네트워크 인증이 필요합니다.
여러 네트워크 인증 다음에는 다른 시나리오 중 하나가 수행됩니다. 예를 들어 사용자는 ISP(인터넷 서비스 공급자)에 인증하고, VPN에 인증한 다음, 사용자 계정 자격 증명을 사용하여 로컬로 로그온합니다.
캐시된 자격 증명은 사용하지 않도록 설정되며, 사용자를 인증하려면 로컬 로그온 전에 VPN을 통한 원격 액세스 서비스 연결이 필요합니다.
do기본 사용자에게는 do기본 조인된 컴퓨터에 로컬 계정이 설정되어 있지 않으며 대화형 로그온을 완료하기 전에 VPN 연결을 통해 원격 액세스 서비스 연결을 설정해야 합니다.
네트워크 인증 및 컴퓨터 로그온은 동일한 자격 증명 공급자에 의해 처리됩니다. 이 시나리오에서는 사용자가 컴퓨터에 로그온하기 전에 네트워크에 연결해야 합니다.
로그온 타일 열거형
자격 증명 공급자는 다음 인스턴스에서 로그온 타일을 열거합니다.
이 항목의 시작 부분에 있는 적용 대상 목록에 지정된 운영 체제의 경우
자격 증명 공급자는 워크스테이션 로그온에 대한 타일을 열거합니다. 자격 증명 공급자는 일반적으로 로컬 보안 기관에 인증을 위해 자격 증명을 직렬화합니다. 이 프로세스는 각 사용자 및 각 사용자의 대상 시스템에 한정된 타일을 표시합니다.
로그온 및 인증 아키텍처를 사용하면 사용자가 자격 증명 공급자가 열거한 타일을 사용하여 워크스테이션의 잠금을 해제할 수 있습니다. 일반적으로 현재 로그온한 사용자는 기본 타일이지만 둘 이상의 사용자가 로그온된 경우 수많은 타일이 표시됩니다.
자격 증명 공급자는 암호 또는 PIN과 같은 기타 개인 정보를 변경하라는 사용자 요청에 대한 응답으로 타일을 열거합니다. 일반적으로 현재 로그온한 사용자는 기본 타일입니다. 그러나 둘 이상의 사용자가 로그온하면 수많은 타일이 표시됩니다.
자격 증명 공급자는 원격 컴퓨터에서 인증에 사용할 직렬화된 자격 증명을 기반으로 타일을 열거합니다. 자격 증명 UI는 로그온 UI, 워크스테이션 잠금 해제 또는 암호 변경과 동일한 공급자 인스턴스를 사용하지 않습니다. 따라서 상태 정보는 자격 증명 UI 인스턴스 간에 공급자에 기본 수 없습니다. 이 구조는 자격 증명이 올바르게 직렬화되었다고 가정하여 각 원격 컴퓨터 로그온에 대해 하나의 타일을 생성합니다. 이 시나리오는 UAC(사용자 계정 컨트롤)에서도 사용되며, 컴퓨터의 작업에 영향을 줄 수 있거나 컴퓨터의 다른 사용자에게 영향을 줄 수 있는 설정을 변경할 수 있는 작업을 허용하기 전에 사용자에게 권한 또는 관리자 암호를 묻는 메시지를 표시하여 컴퓨터에 대한 무단 변경을 방지할 수 있습니다.
다음 다이어그램에서는 이 항목의 시작 부분에 있는 적용 대상 목록에 지정된 운영 체제에 대한 자격 증명 프로세스를 보여 줍니다.
애플리케이션 및 서비스 로그온에 대한 자격 증명 입력
Windows 인증 사용자 상호 작용이 필요하지 않은 애플리케이션 또는 서비스에 대한 자격 증명을 관리하도록 설계되었습니다. 사용자 모드의 애플리케이션은 액세스 권한이 있는 시스템 리소스의 측면에서 제한되지만 서비스는 시스템 메모리 및 외부 디바이스에 무제한으로 액세스할 수 있습니다.
시스템 서비스 및 전송 수준 애플리케이션은 Windows의 SSPI(보안 지원 공급자 인터페이스)를 통해 SSP(보안 지원 공급자)에 액세스합니다. 이 인터페이스는 시스템에서 사용할 수 있는 보안 패키지를 열거하고, 패키지를 선택하고, 해당 패키지를 사용하여 인증된 연결을 가져오는 기능을 제공합니다.
클라이언트/서버 연결이 인증되는 경우:
연결의 클라이언트 쪽에 있는 애플리케이션은 SSPI 함수
InitializeSecurityContext (General)를 사용하여 서버에 자격 증명을 보냅니다.연결의 서버 쪽에 있는 애플리케이션은 SSPI 함수
AcceptSecurityContext (General)로 응답합니다.SSPI는 인증 성공 또는 실패를 위해 필요한 모든 인증 메시지가 교환될 때까지 작동
InitializeSecurityContext (General)하며AcceptSecurityContext (General)반복됩니다.연결이 인증된 후 서버의 LSA는 클라이언트의 정보를 사용하여 액세스 토큰을 포함하는 보안 컨텍스트를 빌드합니다.
그런 다음 서버는 SSPI 함수
ImpersonateSecurityContext를 호출하여 액세스 토큰을 서비스의 가장 스레드에 연결할 수 있습니다.
애플리케이션 및 사용자 모드
Windows의 사용자 모드는 적절한 커널 모드 드라이버에 I/O 요청을 전달할 수 있는 두 시스템, 즉 다양한 유형의 운영 체제에 대해 작성된 애플리케이션을 실행하는 환경 시스템 및 환경 시스템을 대신하여 시스템별 기능을 작동하는 정수 시스템으로 구성됩니다.
정수 시스템은 환경 시스템을 대신하여 운영 체제의 특정 기능을 관리하고 보안 시스템 프로세스(LSA), 워크스테이션 서비스 및 서버 서비스로 구성됩니다. 보안 시스템 프로세스는 보안 토큰을 처리하고, 리소스 권한에 따라 사용자 계정에 액세스할 수 있는 권한을 부여하거나 거부하며, 로그온 요청을 처리하고, 로그온 인증을 시작하고, 운영 체제에서 감사해야 하는 시스템 리소스를 결정합니다.
애플리케이션은 시스템(로컬 시스템)의 보안 컨텍스트를 포함하여 애플리케이션을 모든 보안 주체로 실행할 수 있는 사용자 모드에서 실행할 수 있습니다. 애플리케이션은 SYSTEM(로컬 시스템)의 보안 컨텍스트에서 애플리케이션을 실행할 수 있는 커널 모드에서 실행할 수도 있습니다.
SSPI는 인증, 메시지 무결성 및 메시지 개인 정보 보호를 위해 통합 보안 서비스를 가져오는 데 사용되는 API인 Secur32.dll 모듈을 통해 사용할 수 있습니다. 애플리케이션 수준 프로토콜과 보안 프로토콜 간에 추상화 계층을 제공합니다. 서로 다른 애플리케이션에는 사용자를 식별하거나 인증하는 다양한 방법과 네트워크를 통해 이동하는 데이터를 암호화하는 다양한 방법이 필요하기 때문에 SSPI는 다양한 인증 및 암호화 기능을 포함하는 DLL(동적 연결 라이브러리)에 액세스하는 방법을 제공합니다. 이러한 DLL을 SSP(보안 지원 공급자)라고 합니다.
관리 서비스 계정 및 가상 계정은 Windows Server 2008 R2 및 Windows 7에서 Microsoft SQL Server 및 IIS(인터넷 정보 서비스)와 같은 중요한 애플리케이션을 제공하기 위해 도입되었으며, 관리자가 이러한 계정기본의 SPN(서비스 주체 이름) 및 자격 증명을 수동으로 관리할 필요가 없도록 했습니다. 이러한 기능 및 인증 에서의 역할에 대한 자세한 내용은 Windows 7 및 Windows Server 2008 R2 및 그룹 관리 서비스 계정 개요에 대한 관리 서비스 계정 설명서를 참조하세요.
서비스 및 커널 모드
대부분의 Windows 애플리케이션은 시작하는 사용자의 보안 컨텍스트에서 실행되지만 서비스의 경우는 그렇지 않습니다. 네트워크 및 인쇄 서비스와 같은 많은 Windows 서비스는 사용자가 컴퓨터를 시작할 때 서비스 컨트롤러에서 시작됩니다. 이러한 서비스는 로컬 서비스 또는 로컬 시스템으로 실행될 수 있으며 마지막 사용자 로그오프 후 계속 실행될 수 있습니다.
참고 항목
서비스는 일반적으로 SYSTEM(로컬 시스템), 네트워크 서비스 또는 로컬 서비스라고 하는 보안 컨텍스트에서 실행됩니다. Windows Server 2008 R2는 관리되는 서비스 계정으로 실행되는 서비스를 도입했습니다기본 보안 주체입니다.
서비스를 시작하기 전에 서비스 컨트롤러는 서비스에 대해 지정된 계정을 사용하여 로그온한 다음 LSA에서 인증할 서비스의 자격 증명을 제공합니다. Windows 서비스는 서비스 컨트롤러 관리자가 서비스를 제어하는 데 사용할 수 있는 프로그래밍 방식 인터페이스를 구현합니다. Windows 서비스는 시스템이 시작될 때 자동으로 시작하거나 서비스 제어 프로그램을 사용하여 수동으로 시작할 수 있습니다. 예를 들어 Windows 클라이언트 컴퓨터가 do기본 조인하면 컴퓨터의 메신저 서비스가 do기본 컨트롤러에 연결하여 보안 채널을 엽니다. 인증된 연결을 얻으려면 원격 컴퓨터의 LSA(로컬 보안 기관)에서 신뢰하는 자격 증명이 서비스에 있어야 합니다. 네트워크의 다른 컴퓨터와 통신할 때 LSA는 로컬 시스템 및 네트워크 서비스의 보안 컨텍스트에서 실행되는 다른 모든 서비스와 마찬가지로 로컬 컴퓨터의 do기본 계정에 대한 자격 증명을 사용합니다. 로컬 컴퓨터의 서비스는 SYSTEM으로 실행되므로 자격 증명을 LSA에 표시할 필요가 없습니다.
Ksecdd.sys 파일은 이러한 자격 증명을 관리하고 암호화하며 LSA에 대한 로컬 프로시저 호출을 사용합니다. 파일 형식은 DRV(드라이버)이며 커널 모드 SSP(보안 지원 공급자)라고 하며, 이 항목의 시작 부분에 있는 적용 대상 목록에 지정된 버전에서는 FIPS 140-2 수준 1 규격입니다.
커널 모드는 컴퓨터의 하드웨어 및 시스템 리소스에 대한 모든 권한을 갖습니다. 커널 모드는 사용자 모드 서비스 및 애플리케이션이 액세스 권한이 없어야 하는 운영 체제의 중요한 영역에 액세스하지 못하도록 합니다.
로컬 보안 기관
LSA(로컬 보안 기관)는 사용자를 인증하고 로컬 컴퓨터에 로그온하는 보호된 시스템 프로세스입니다. 또한 LSA는 컴퓨터에서 로컬 보안의 모든 측면에 대한 정보를 기본(이러한 측면은 집합적으로 로컬 보안 정책이라고 함) 이름 및 SID(보안 식별자) 간 번역을 위한 다양한 서비스를 제공합니다. 보안 시스템 프로세스인 LSASS(로컬 보안 기관 서버 서비스)는 컴퓨터 시스템에 적용되는 보안 정책 및 계정을 추적합니다.
LSA는 다음 두 엔터티 중 사용자 계정을 발급한 엔터티에 따라 사용자의 ID의 유효성을 검사합니다.
로컬 보안 기관. LSA는 동일한 컴퓨터에 있는 SAM(보안 계정 관리자) 데이터베이스를 검사 사용자 정보의 유효성을 검사할 수 있습니다. 모든 워크스테이션 또는 멤버 서버는 로컬 사용자 계정 및 로컬 그룹에 대한 정보를 저장할 수 있습니다. 그러나 이러한 계정은 해당 워크스테이션 또는 컴퓨터에만 액세스하는 데 사용할 수 있습니다.
로컬 do기본 또는 신뢰할 수 있는 do기본 보안 기관입니다. LSA는 계정을 발급한 엔터티에 연결하고 계정이 유효하고 요청이 계정 소유자로부터 시작되었음을 확인합니다.
LSASS(Local Security Authority Subsystem Service)는 활성 Windows 세션의 사용자를 위해 메모리에 자격 증명을 저장합니다. 저장된 자격 증명을 사용하면 사용자가 각 원격 서비스에 대한 자격 증명을 다시 입력하지 않고도 파일 공유, Exchange Server 사서함 및 SharePoint 사이트와 같은 네트워크 리소스에 원활하게 액세스할 수 있습니다.
LSASS는 다음을 비롯한 여러 가지 형식으로 자격 증명을 저장할 수 있습니다.
역방향으로 암호화된 일반 텍스트
Kerberos 티켓(TGT(티켓 부여 티켓), 서비스 티켓)
NT 해시
LAN 관리자(LM) 해시
사용자가 스마트 카드 사용하여 Windows에 로그온하는 경우 LSASS는 일반 텍스트 암호를 저장하지 않지만 계정에 해당하는 NT 해시 값과 스마트 카드 일반 텍스트 PIN을 저장합니다. 대화형 로그온에 필요한 계정 특성이 스마트 카드에 사용하도록 설정된 경우 계정에 대해 원래 암호 해시 대신 임의의 NT 해시 값이 자동으로 생성됩니다. 특성이 설정될 때 자동으로 생성된 암호는 변경되지 않습니다.
사용자가 LM(LAN Manager) 해시와 호환되는 암호를 사용하여 Windows 기반 컴퓨터에 로그온하는 경우 이 인증자는 메모리에 있습니다.
메모리의 일반 텍스트 자격 증명 스토리지는 이를 필요로 하는 자격 증명 공급자가 사용되지 않는 경우에도 비활성화할 수 없습니다.
저장된 자격 증명은 마지막으로 다시 시작한 후 시작되었으며 닫혀 있지 않은 LSASS(로컬 보안 기관 하위 시스템 서비스) 로그온 세션과 직접 연결됩니다. 예를 들어 사용자가 다음 중 하나를 수행하는 경우 저장된 LSA 자격 증명을 사용하는 LSA 세션이 만들어집니다.
컴퓨터의 로컬 세션 또는 RDP(원격 데스크톱 프로토콜) 세션에 로그온합니다.
RunAs 옵션을 사용하여 작업을 실행하는 경우
컴퓨터에서 활성 Windows 서비스를 실행하는 경우
예약된 작업 또는 일괄 처리 작업을 실행하는 경우
원격 관리 도구를 사용하여 로컬 컴퓨터에서 작업을 실행하는 경우
경우에 따라 SYSTEM 계정 프로세스에서만 액세스할 수 있는 비밀 데이터 조각인 LSA 비밀이 하드 디스크 드라이브에 저장됩니다. 이러한 암호 중 일부는 다시 부팅 후 유지해야 하는 자격 증명이며, 하드 디스크 드라이브에 암호화된 형식으로 저장됩니다. LSA 암호로 저장될 수 있는 자격 증명은 다음과 같습니다.
컴퓨터의 AD DS(Active Directory 도메인 Services) 계정에 대한 계정 암호
컴퓨터에 구성되어 있는 Windows 서비스에 대한 계정 암호
구성된 예약된 작업에 대한 계정 암호
IIS 애플리케이션 풀 및 웹 사이트에 대한 계정 암호
Microsoft 계정의 암호
Windows 8.1에서 도입된 클라이언트 운영 체제는 보호되지 않는 프로세스에서 메모리 및 코드 삽입을 읽지 못하도록 LSA에 대한 추가 보호를 제공합니다. 이 보호는 LSA가 저장하고 관리하는 자격 증명에 대한 보안을 강화합니다.
이러한 추가 보호에 대한 자세한 내용은 추가 LSA 보호 구성을 참조하세요.
캐시된 자격 증명 및 유효성 검사
유효성 검사 메커니즘은 로그온 시 자격 증명을 표시합니다. 그러나 컴퓨터가 do기본 컨트롤러에서 연결이 끊어지고 사용자가 do기본 자격 증명을 제시하는 경우 Windows는 유효성 검사 메커니즘에서 캐시된 자격 증명 프로세스를 사용합니다.
사용자가 do기본 로그온할 때마다 Windows는 제공된 자격 증명을 캐시하고 운영 시스템의 레지스트리에 있는 보안 하이브에 저장합니다.
캐시된 자격 증명을 사용하면 사용자는 할 일기본 내의 할 일기본 컨트롤러에 연결하지 않고도 할 일기본 멤버에 로그온할 수 있습니다.
자격 증명 스토리지 및 유효성 검사
다른 리소스에 액세스하기 위해 자격 증명 집합을 사용하는 것이 항상 바람직하지는 않습니다. 예를 들어 관리자는 원격 서버에 액세스할 때 사용자 자격 증명 대신 관리자를 사용할 수 있습니다. 마찬가지로 사용자가 은행 계좌와 같은 외부 리소스에 액세스하는 경우 해당 자격 증명과 다른 자격 증명만 사용할 수 기본. 다음 섹션에서는 현재 버전의 Windows 운영 체제와 Windows Vista 및 Windows XP 운영 체제 간의 자격 증명 관리의 차이점을 설명합니다.
원격 로그온 자격 증명 프로세스
RDP(원격 데스크톱 프로토콜)는 Windows 8에서 도입된 원격 데스크톱 클라이언트를 사용하여 원격 컴퓨터에 연결하는 사용자의 자격 증명을 관리합니다. 일반 텍스트 형식의 자격 증명은 호스트가 인증 프로세스를 수행하려고 시도하고 성공하면 사용자를 허용된 리소스에 연결하는 대상 호스트로 전송됩니다. RDP는 클라이언트에 자격 증명을 저장하지 않지만 사용자의 do기본 자격 증명은 LSASS에 저장됩니다.
Windows Server 2012 R2 및 Windows 8.1에 도입된 제한된 관리 모드는 원격 로그온 시나리오에 대한 추가 보안을 제공합니다. 이 원격 데스크톱 모드를 사용하면 클라이언트 애플리케이션이 NTOWF(NT 단방향 함수)를 사용하여 네트워크 로그온 챌린지 응답을 수행하거나 원격 호스트에 인증할 때 Kerberos 서비스 티켓을 사용합니다. 관리자가 인증된 후에는 관리자가 원격 호스트에 제공되지 않았기 때문에 LSASS에 해당 계정 자격 증명이 없습니다. 대신 관리자에게 세션에 대한 컴퓨터 계정 자격 증명이 있습니다. 관리이스트레이터 자격 증명은 원격 호스트에 제공되지 않으므로 작업이 컴퓨터 계정으로 수행됩니다. 또한 리소스는 컴퓨터 계정으로 제한되며 관리자는 자신의 계정으로 리소스에 액세스할 수 없습니다.
로그온 자격 증명 프로세스 자동 다시 시작
사용자가 Windows 8.1 디바이스에 로그인하면 LSA는 LSASS.exe에서만 액세스할 수 있는 암호화된 메모리에 사용자 자격 증명을 저장합니다. Windows 업데이트 사용자 존재 없이 자동 다시 시작을 시작하면 이러한 자격 증명을 사용하여 사용자에 대한 Autologon을 구성합니다.
다시 시작할 때 사용자는 자동 로그온 메커니즘을 통해 자동으로 로그인되고 컴퓨터는 사용자의 세션을 보호하기 위해 추가로 잠깁니다. 잠금은 Winlogon을 통해 시작되는 반면 자격 증명 관리는 LSA에서 수행됩니다. 콘솔에서 자동으로 로그인하고 사용자의 세션을 잠그면 사용자의 잠금 화면 애플리케이션이 다시 시작되고 사용할 수 있습니다.
ARSO에 대한 자세한 내용은 Winlogon ARSO(자동 다시 시작 로그온)를 참조하세요.
Windows Vista 및 Windows XP에 저장된 사용자 이름 및 암호
Windows Server 2008, Windows Server 2003, Windows Vista 및 Windows XP에서 저장된 사용자 이름 및 암호는 제어판 스마트 카드 및 Windows Live 자격 증명(현재 Microsoft 계정이라고 함)과 함께 사용되는 X.509 인증서를 포함하여 여러 로그온 자격 증명 집합의 관리 및 사용을 간소화합니다. 사용자 프로필의 일부인 자격 증명은 필요할 때까지 저장됩니다. 이 작업은 한 암호가 손상될 경우 모든 보안이 손상되지 않도록 하여 리소스별로 보안을 강화할 수 있습니다.
사용자가 로그온하여 서버의 공유와 같은 추가 암호로 보호된 리소스에 액세스하려고 시도하고 사용자의 기본 로그온 자격 증명이 액세스 권한을 얻기에 충분하지 않은 경우 저장된 사용자 이름 및 암호를 쿼리합니다 . 올바른 로그온 정보가 있는 대체 자격 증명이 저장된 사용자 이름 및 암호에 저장된 경우 이러한 자격 증명을 사용하여 액세스 권한을 얻습니다. 그렇지 않으면 사용자에게 새 자격 증명을 제공하라는 메시지가 표시됩니다. 이 자격 증명은 나중에 로그온 세션 또는 후속 세션 중에 다시 사용하기 위해 저장할 수 있습니다.
다음 제한 사항이 적용됩니다.
저장된 사용자 이름 및 암호에 특정 리소스에 대한 잘못된 자격 증명 또는 잘못된 자격 증명이 포함되어 있으면 리소스에 대한 액세스가 거부되고 저장된 사용자 이름 및 암호 대화 상자가 표시되지 않습니다.
저장된 사용자 이름 및 암호는 NTLM, Kerberos 프로토콜, Microsoft 계정(이전의 Windows Live ID) 및 SSL(Secure Sockets Layer) 인증에 대해서만 자격 증명을 저장합니다. 일부 버전의 Internet Explorer는 기본 인증을 위해 자체 캐시를 기본.
이러한 자격 증명은 \Documents and 설정\Username\Application Data\Microsoft\Credentials 디렉터리에서 사용자 로컬 프로필의 암호화된 부분이 됩니다. 따라서 사용자의 네트워크 정책에서 로밍 사용자 프로필을 지원하는 경우 이러한 자격 증명은 사용자와 함께 로밍할 수 있습니다. 그러나 사용자가 서로 다른 두 컴퓨터에 저장된 사용자 이름 및 암호의 복사본을 가지고 있고 이러한 컴퓨터 중 하나의 리소스와 연결된 자격 증명을 변경하는 경우 변경 내용은 두 번째 컴퓨터의 저장된 사용자 이름 및 암호로 전파되지 않습니다.
Windows 자격 증명 모음 및 자격 증명 관리자
자격 증명 관리자는 사용자 이름과 암호를 저장하고 관리하는 제어판 기능으로 Windows Server 2008 R2 및 Windows 7에서 도입되었습니다. 자격 증명 관리자를 사용하면 사용자가 보안 Windows 자격 증명 모음에 다른 시스템 및 웹 사이트와 관련된 자격 증명을 저장할 수 있습니다. 일부 버전의 Internet Explorer는 웹 사이트에 대한 인증에 이 기능을 사용합니다.
자격 증명 관리자를 사용한 자격 증명 관리는 로컬 컴퓨터의 사용자에 의해 제어됩니다. 사용자는 지원되는 브라우저 및 Windows 애플리케이션에 자격 증명을 저장하여 이러한 리소스에 로그인해야 할 때 편리하게 사용할 수 있습니다. 자격 증명은 사용자 프로필 아래 컴퓨터의 특수 암호화된 폴더에 저장됩니다. 웹 브라우저 및 앱과 같은 자격 증명 관리자 API를 사용하여 이 기능을 지원하는 애플리케이션은 로그온 프로세스 중에 다른 컴퓨터 및 웹 사이트에 올바른 자격 증명을 표시할 수 있습니다.
웹 사이트, 애플리케이션 또는 다른 컴퓨터가 NTLM 또는 Kerberos 프로토콜을 통해 인증을 요청하면 기본 자격 증명 업데이트 또는 암호 저장 검사 상자를 선택하는 대화 상자가 나타납니다. 사용자가 자격 증명을 로컬로 저장할 수 있도록 하는 이 대화 상자는 자격 증명 관리자 API를 지원하는 애플리케이션에서 생성됩니다. 사용자가 암호 저장 검사 상자를 선택하면 자격 증명 관리자는 사용 중인 인증 서비스에 대한 사용자의 사용자 이름, 암호 및 관련 정보를 추적합니다.
다음에 서비스를 사용할 때 자격 증명 관리자는 Windows 자격 증명 모음에 저장된 자격 증명을 자동으로 제공합니다. 확인란을 선택하지 않은 경우에는 올바른 액세스 정보를 입력하라는 메시지가 표시됩니다. 새 자격 증명을 사용하여 액세스 권한이 부여되면 자격 증명 관리자는 이전 자격 증명을 새 자격 증명으로 덮어쓰고 새 자격 증명을 Windows 자격 증명 모음에 저장합니다.
보안 계정 관리자 데이터베이스
SAM(보안 계정 관리자)은 로컬 사용자 계정 및 그룹을 저장하는 데이터베이스입니다. 모든 Windows 운영 체제에 있습니다. 그러나 컴퓨터가 할 일기본 조인되면 Active Directory에서 do기본 계정을 관리합니다기본.
예를 들어 Windows 운영 체제를 실행하는 클라이언트 컴퓨터는 사용자가 로그온되지 않은 경우에도 do기본 컨트롤러와 통신하여 네트워크에 참여합니다기본. 통신을 시작하려면 컴퓨터에 do기본 활성 계정이 있어야 합니다. 컴퓨터의 통신을 수락하기 전에 do기본 컨트롤러의 LSA는 컴퓨터의 ID를 인증한 다음, 사용자 보안 주체와 마찬가지로 컴퓨터의 보안 컨텍스트를 생성합니다. 이 보안 컨텍스트는 네트워크의 특정 컴퓨터 또는 사용자, 서비스 또는 컴퓨터에서 사용자 또는 서비스의 ID와 기능을 정의합니다. 예를 들어 보안 컨텍스트 내에 포함된 액세스 토큰은 액세스할 수 있는 리소스(예: 파일 공유 또는 프린터)와 해당 보안 주체(사용자, 컴퓨터 또는 해당 리소스의 서비스)에서 수행할 수 있는 작업(예: 읽기, 쓰기 또는 수정)을 정의합니다.
사용자 또는 컴퓨터의 보안 컨텍스트는 사용자가 서버 또는 사용자 고유의 기본 워크스테이션 이외의 워크스테이션에 로그온하는 경우와 같이 컴퓨터마다 다를 수 있습니다. 관리자가 사용자의 권한 및 권한을 수정하는 경우와 같이 세션마다 다를 수도 있습니다. 또한 사용자 또는 컴퓨터가 독립 실행형으로, 네트워크에서 또는 Active Directory의 일부로 작동하는 경우 일반적으로 보안 컨텍스트가 다릅니다기본.
로컬 do기본s 및 신뢰할 수 있는 do기본s
두 do기본 사이에 트러스트가 있는 경우 각각에 대한 인증 메커니즘은 기본 다른 do기본 들어오는 인증의 유효성에 의존합니다. 트러스트는 들어오는 인증 요청이 신뢰할 수 있는 기관(신뢰할 수 있는 권한기본)에서 오는지 확인하여 리소스의 공유 리소스에 대한 제어된 액세스를 제공하는 데 도움이 됩니다기본(트러스트할 기본). 이러한 방식으로 트러스트는 유효성이 검사된 인증 요청만 do기본 사이를 이동할 수 있도록 하는 브리지 역할을 합니다.
특정 트러스트가 인증 요청을 전달하는 방법은 구성 방법에 따라 달라집니다. 트러스트 관계는 신뢰할 수 있는 do기본에서 신뢰할 수 있는 할 일기본 리소스에 대한 액세스를 제공하거나, 다른 do기본 리소스에 대한 액세스를 제공하여 단방향일 수 있습니다기본. 또한 트러스트는 비전환적이며, 이 경우 트러스트는 두 트러스트 파트너 간에만 존재하거나기본 전이적입니다. 이 경우 트러스트는 파트너 중 하나가 신뢰하는 다른 do기본로 자동으로 확장됩니다.
인증과 관련된 do기본 및 포리스트 트러스트 관계에 대한 자세한 내용은 위임된 인증 및 트러스트 관계를 참조하세요.
Windows 인증 인증서
PKI(공개 키 인프라)는 조직이 통신 및 비즈니스 트랜잭션을 보호할 수 있도록 하는 소프트웨어, 암호화 기술, 프로세스 및 서비스의 조합입니다. PKI가 통신 및 비즈니스 트랜잭션을 보호하는 기능은 인증된 사용자와 신뢰할 수 있는 리소스 간의 디지털 인증서 교환을 기반으로 합니다.
디지털 인증서는 속한 엔터티, 발행한 엔터티, 고유한 일련 번호 또는 기타 고유 ID, 발급 및 만료 날짜 및 디지털 지문에 대한 정보를 포함하는 전자 문서입니다.
인증은 원격 호스트를 신뢰할 수 있는지 확인하는 프로세스입니다. 신뢰도를 설정하려면 원격 호스트가 허용 가능한 인증 인증서를 제공해야 합니다.
원격 호스트는 CA(인증 기관)에서 인증서를 획득하여 신뢰성을 설정합니다. CA는 더 높은 기관으로부터 인증을 받아 신뢰 체인을 만들 수 있습니다. 인증서가 신뢰할 수 있는지 여부를 확인하려면 애플리케이션이 루트 CA의 ID를 확인한 다음 신뢰할 수 있는지 확인해야 합니다.
마찬가지로 원격 호스트 또는 로컬 컴퓨터는 사용자 또는 애플리케이션에서 제공하는 인증서가 인증인지 확인해야 합니다. LSA 및 SSPI를 통해 사용자가 제공한 인증서는 Active Directory의 인증서 저장소를 통해 로컬 로그온, 네트워크 또는 할 일기본 로컬 컴퓨터에서 신뢰성을 평가합니다.
인증서를 생성하기 위해 인증 데이터는 SHA1(Secure Hash Algorithm 1)과 같은 해시 알고리즘을 통과하여 메시지 다이제스트를 생성합니다. 그런 다음 보낸 사람의 프라이빗 키를 사용하여 메시지 다이제스트가 보낸 사람에서 생성되었음을 증명하여 메시지 다이제스트에 디지털 서명됩니다.
참고 항목
SHA1은 Windows 7 및 Windows Vista의 기본값이지만 Windows 8에서 SHA2로 변경되었습니다.
스마트 카드 인증
스마트 카드 기술은 인증서 기반 인증의 예입니다. 스마트 카드 사용하여 네트워크에 로그온하면 사용자를 인증할 때 암호화 기반 식별 및 소유 증명을 사용하기 때문에 강력한 형태의 인증이 기본. AD CS(Active Directory Certificate Services)는 각 스마트 카드 대한 로그온 인증서 발급을 통해 암호화 기반 ID를 제공합니다.
스마트 카드 인증에 대한 자세한 내용은 Windows 스마트 카드 기술 참조를 참조하세요.
가상 스마트 카드 기술은 Windows 8에서 도입되었습니다. 스마트 카드 인증서를 PC에 저장한 다음, 디바이스의 변조 방지 TPM(신뢰할 수 있는 플랫폼 모듈) 보안 칩을 사용하여 보호합니다. 이러한 방식으로 PC는 실제로 인증을 받기 위해 사용자의 PIN을 받아야 하는 스마트 카드 됩니다.
원격 및 무선 인증
원격 및 무선 네트워크 인증은 인증에 인증서를 사용하는 또 다른 기술입니다. IAS(인터넷 인증 서비스) 및 가상 사설망 서버는 EAP-TLS(Extensible Authentication Protocol-Transport Level Security), PEAP(Protected Extensible Authentication Protocol) 또는 IPsec(인터넷 프로토콜 보안)을 사용하여 VPN(가상 사설망) 및 무선 연결을 비롯한 다양한 유형의 네트워크 액세스에 대해 인증서 기반 인증을 수행합니다.
네트워킹의 인증서 기반 인증에 대한 자세한 내용은 네트워크 액세스 인증 및 인증서를 참조 하세요.