Windows 인증의 자격 증명 프로세스
IT 전문가를 위한 이 참조 토픽에서는 Windows 인증이 자격 증명을 처리하는 방법에 대해 설명합니다.
Windows 자격 증명 관리는 운영 체제에서 서비스 또는 사용자로부터 자격 증명을 수신하고 향후 프레젠테이션을 위해 인증 대상에 대한 정보를 보호하는 프로세스입니다. 도메인 조인 컴퓨터의 경우 인증 대상은 도메인 컨트롤러입니다. 인증에 사용되는 자격 증명은 인증서, 암호 또는 PIN과 같은 특정 양식의 신뢰성 증명에 사용자의 ID를 연결하는 디지털 문서입니다.
기본적으로 Windows 자격 증명은 Winlogon 서비스를 통해 로컬 컴퓨터의 SAM(보안 계정 관리자) 데이터베이스 또는 도메인 조인 컴퓨터의 Active Directory에 대해 유효성을 검사합니다. 자격 증명은 로그온 사용자 인터페이스의 사용자 입력을 통해 수집되거나 인증 대상에 표시되는 API(애플리케이션 프로그래밍 인터페이스)를 통해 프로그래밍 방식으로 수집됩니다.
로컬 보안 정보는 HKEY_LOCAL_MACHINE\SECURITY 아래의 레지스트리에 저장됩니다. 저장된 정보는 정책 설정, 기본 보안 값 및 계정 정보(예: 캐시된 로그온 자격 증명)를 포함합니다. SAM 데이터베이스의 복사본은 쓰기가 보호되지만 여기에도 저장됩니다.
다음 다이어그램에서는 필요한 구성 요소 및 자격 증명이 성공적인 로그온을 위해 사용자 또는 프로세스를 인증하기 위해 시스템을 통과하는 경로를 보여 줍니다.
다음 표에서는 로그온 시점의 인증 프로세스에서 자격 증명을 관리하는 각 구성 요소를 설명합니다.
모든 시스템에 대한 인증 구성 요소
| 구성 요소 | 설명 |
|---|---|
| 사용자 로그온 | Winlogon.exe는 보안 사용자 상호 작용을 관리하는 실행 파일입니다. Winlogon 서비스는 보안 데스크톱(로그온 UI)에서 사용자 작업으로 수집한 자격 증명을 Secur32.dll을 통해 LSA(로컬 보안 기관)에 전달하여 Windows 운영 체제에 대한 로그온 프로세스를 시작합니다. |
| 애플리케이션 로고 | 대화형 로그온이 필요하지 않은 애플리케이션 또는 서비스 로그온입니다. 사용자가 시작한 대부분의 프로세스는 Secur32.dll을 사용하여 사용자 모드에서 실행되는 반면, 서비스와 같이 가동 시 시작된 프로세스는 Ksecdd.sys를 사용하여 커널 모드로 실행됩니다. 사용자 모드 및 커널 모드에 대한 자세한 내용은 이 토픽의 애플리케이션 및 사용자 모드 또는 서비스 및 커널 모드를 참조하세요. |
| Secur32.dll | 인증 프로세스의 기초를 형성하는 다중 인증 공급자입니다. |
| Lsasrv.dll | 보안 정책을 적용하고 LSA의 보안 패키지 관리자 역할을 하는 LSA 서버 서비스입니다. LSA는 성공할 프로토콜을 결정한 후 NTLM 또는 Kerberos 프로토콜을 선택하는 Negotiate 함수를 포함하고 있습니다. |
| 보안 지원 공급자 | 한 개 이상의 인증 프로토콜을 개별적으로 호출할 수 있는 공급자 집합입니다. 기본 공급자 집합은 Windows 운영 체제의 각 버전에 따라 변경될 수 있고 사용자 지정 공급자를 작성할 수 있습니다. |
| Netlogon.dll | Net Logon 서비스가 수행하는 서비스는 다음과 같습니다. - 컴퓨터의 보안 채널(Schannel과 혼동해서는 안 됨)을 도메인 컨트롤러에 유지 관리합니다. |
| Samsrv.dll | 로컬 보안 계정을 저장하는 SAM(보안 계정 관리자)은 로컬에서 저장된 정책을 적용하고 API를 지원합니다. |
| Registry | 레지스트리에는 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는 인증을 위해 이러한 자격 증명을 제출합니다.
자격 증명 공급자는 적용 메커니즘이 아닙니다. 자격 증명을 수집하고 직렬화하기 위해 사용됩니다. 로컬 보안 기관 및 인증 패키지는 보안을 적용합니다.
자격 증명 공급자는 컴퓨터에 등록되며 다음 사항을 담당합니다.
인증에 필요한 자격 증명 정보를 설명합니다.
외부 인증 기관과의 통신 및 논리를 처리합니다.
대화형 및 네트워크 로그온을 위한 자격 증명을 패키징합니다.
대화형 및 네트워크 로그온에 대한 자격 증명 패키징에는 직렬화 프로세스가 포함됩니다. 자격 증명을 직렬화하여 여러 로그온 타일을 로그온 UI에 표시할 수 있습니다. 따라서 조직에서는 사용자 지정 자격 증명 공급자를 사용하여 사용자, 로그온 대상 시스템, 네트워크에 대한 사전 로그온 액세스 및 워크스테이션 잠금/잠금 해제 정책과 같은 로그온 표시를 제어할 수 있습니다. 여러 자격 증명 공급자가 같은 컴퓨터에 공존할 수 있습니다.
SSO(Single Sign-On) 공급자는 표준 자격 증명 공급자 또는 사전 로그온 액세스 공급자로 개발될 수 있습니다.
각 버전의 Windows에는 하나의 기본 자격 증명 공급자 및 SSO 공급자라고도 하는 하나의 기본 PLAP(사전 로그온 액세스 공급자)가 포함되어 있습니다. SSO 공급자는 사용자가 로컬 컴퓨터에 로그온하기 전에 네트워크에 연결하도록 허용합니다. 이 공급자가 구현되는 경우 공급자는 로그온 UI에서 타일을 열거하지 않습니다.
SSO 공급자는 다음 시나리오에서 사용되기 위한 것입니다.
네트워크 인증 및 컴퓨터 로그온은 다양한 자격 증명 공급자에 의해 처리됩니다. 이 시나리오의 변형에는 다음 사항이 포함됩니다.
사용자에게는 컴퓨터에 로그온하기 전에 VPN(가상 사설망) 연결과 같은 네트워크에 연결하는 옵션이 있지만 이 연결을 만들 필요는 없습니다.
대화형 인증 중에 사용되는 정보를 로컬 컴퓨터에서 검색하려면 네트워크 인증이 필요합니다.
다중 네트워크 인증 다음에는 다른 시나리오 중 하나가 수행됩니다. 예를 들어 사용자는 ISP(인터넷 서비스 공급자)에 인증하고 VPN에 인증한 다음, 사용자 계정 자격 증명을 사용하여 로컬로 로그온합니다.
캐시된 자격 증명은 사용하지 않도록 설정되며 사용자를 인증하려면 로컬 로그온 전에 VPN을 통한 원격 액세스 서비스 연결이 필요합니다.
도메인 사용자는 도메인 조인 컴퓨터에 로컬 계정을 설정하지 않았으며 대화형 로그온을 완료하기 전에 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), 워크스테이션 서비스 및 서버 서비스로 구성됩니다. 보안 시스템 프로세스에서는 보안 토큰을 처리하고, 리소스 권한에 따라 사용자 계정에 액세스할 수 있는 권한을 부여하거나 거부하며, 로그온 요청을 처리하고, 로그온 인증을 시작하고, 운영 체제에서 감사해야 하는 시스템 리소스를 결정합니다.
애플리케이션은 시스템(로컬 시스템)의 보안 컨텍스트를 포함하여 애플리케이션을 보안 주체로 모두 실행할 수 있는 사용자 모드에서 실행할 수 있습니다. 애플리케이션은 시스템(로컬 시스템)의 보안 컨텍스트에서 애플리케이션을 실행할 수 있는 커널 모드에서 실행할 수도 있습니다.
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 서비스는 사용자가 컴퓨터를 시작하는 경우 서비스 컨트롤러에서 시작됩니다. 이러한 서비스는 로컬 서비스 또는 로컬 시스템으로 실행될 수 있으며 마지막 사용자 로그오프 후 계속해서 실행될 수 있습니다.
참고 항목
서비스는 일반적으로 시스템(로컬 시스템), 네트워크 서비스 또는 로컬 서비스라고 하는 보안 컨텍스트에서 실행됩니다. Windows Server 2008 R2에서는 도메인 보안 주체인 관리 서비스 계정으로 실행되는 서비스를 도입했습니다.
서비스를 시작하기 전에 서비스 컨트롤러는 서비스에 지정된 계정을 사용하여 로그온한 다음 LSA에서 인증할 서비스의 자격 증명을 제공합니다. Windows 서비스에서는 서비스 컨트롤러 관리자가 서비스를 제어하는 데 사용할 수 있는 프로그래밍 방식 인터페이스를 구현합니다. Windows 서비스는 시스템이 시작되는 경우 자동으로 시작하거나 서비스 제어 프로그램을 사용하여 수동으로 시작할 수 있습니다. 예를 들어 Windows 클라이언트 컴퓨터가 도메인에 가입하는 경우 컴퓨터의 메신저 서비스가 도메인 컨트롤러에 연결되고 보안 채널이 열립니다. 인증된 연결을 얻으려면 서비스에 원격 컴퓨터의 LSA(로컬 보안 기관)에서 신뢰하는 자격 증명이 있어야 합니다. 네트워크의 다른 컴퓨터와 통신하는 경우 LSA는 로컬 시스템 및 네트워크 서비스의 보안 컨텍스트에서 실행되는 다른 모든 서비스와 마찬가지로 로컬 컴퓨터의 도메인 계정에 대한 자격 증명을 사용합니다. 로컬 컴퓨터의 서비스는 SYSTEM으로 실행되므로 자격 증명을 LSA에 표시하지 않아도 됩니다.
파일 Ksecdd.sys는 이러한 자격 증명을 관리 및 암호화하고 LSA에 대한 로컬 프로시저 호출을 사용합니다. 파일 형식은 DRV(드라이버)이고 커널 모드 SSP(보안 지원 공급자)라고 하며 이 항목의 시작 부분에 있는 적용 대상 목록에 지정된 버전에서는 FIPS 140-2 수준 1 규격입니다.
커널 모드에는 컴퓨터의 하드웨어 및 시스템 리소스에 대한 모든 권한이 있습니다. 커널 모드는 액세스 권한이 없어야 하는 운영 체제의 중요한 영역에 사용자 모드 서비스 및 애플리케이션이 액세스하지 못하도록 합니다.
로컬 보안 기관
LSA(로컬 보안 기관)란 사용자를 인증하고 로컬 컴퓨터에 로그온하는 보호된 시스템 프로세스입니다. 또한 LSA는 컴퓨터에서 로컬 보안의 모든 측면에 대한 정보를 유지 관리하며(이러한 측면은 집합적으로 로컬 보안 정책이라고 함) 이름 및 SID(보안 식별자) 간 번역을 위한 다양한 서비스를 제공합니다. 보안 시스템 프로세스인 LSASS(로컬 보안 기관 서버 서비스)는 컴퓨터 시스템에서 적용되는 보안 정책 및 계정을 추적합니다.
LSA는 다음의 두 개 엔터티 중 사용자 계정을 발급한 엔터티에 따라 사용자의 ID의 유효성을 검사합니다.
로컬 보안 기관. LSA에서는 동일한 컴퓨터에 있는 SAM(보안 계정 관리자) 데이터베이스를 확인하여 사용자 정보의 유효성을 검사할 수 있습니다. 모든 워크스테이션 또는 멤버 서버는 로컬 그룹에 대한 로컬 사용자 계정 및 정보를 저장할 수 있습니다. 하지만 이러한 계정은 해당 워크스테이션 또는 컴퓨터에만 액세스하는 데 사용할 수 있습니다.
로컬 도메인 또는 신뢰할 수 있는 도메인의 보안 기관입니다. LSA는 계정을 발급한 엔터티에 연결하고 계정이 유효하며 요청이 계정 소유자로부터 시작되었음을 확인합니다.
LSASS(Local Security Authority Subsystem Service)는 활성 Windows 세션의 사용자를 위해 메모리에 자격 증명을 저장합니다. 저장된 자격 증명을 통해 사용자는 각 원격 서비스에 대한 자격 증명을 다시 입력하지 않고도 파일 공유, Exchange Server 사서함, SharePoint 사이트 등의 네트워크 리소스에 원활하게 액세스할 수 있습니다.
LSASS는 다음을 비롯한 여러 가지 형식으로 자격 증명을 저장할 수 있습니다.
역방향으로 암호화된 일반 텍스트
Kerberos 티켓(TGT(티켓 부여 티켓), 서비스 티켓)
NT 해시
LM(LAN 관리자) 해시
사용자가 스마트 카드를 사용하여 Windows에 로그온한 경우 LSASS는 일반 텍스트 암호를 저장하는 것이 아니라 계정의 해당 NT 해시 값 및 스마트 카드의 일반 텍스트 PIN를 저장합니다. 대화형 로그온에 필요한 계정 특성이 스마트 카드에 사용하도록 설정된 경우 계정에 대해 원래 암호 해시 대신 임의의 NT 해시 값이 자동으로 생성됩니다. 특성이 설정될 때 자동으로 생성된 암호는 변경되지 않습니다.
사용자가 LM(LAN 관리자) 해시와 호환되는 암호를 사용하여 Windows 기반 컴퓨터에 로그온하면 이 인증자가 메모리에 존재하게 됩니다.
메모리의 일반 텍스트 자격 증명 스토리지는 이를 필요로 하는 자격 증명 공급자가 사용되지 않는 경우에도 비활성화할 수 없습니다.
저장된 자격 증명은 마지막으로 다시 시작한 이후에 시작되어 아직 닫히지 않은 LSASS(로컬 보안 기관 하위 시스템 서비스) 로그온 세션에 직접 연결됩니다. 예를 들어 사용자가 다음 중 하나를 수행하는 경우 저장된 LSA 자격 증명을 사용하는 LSA 세션이 만들어집니다.
컴퓨터의 로컬 세션 또는 RDP(원격 데스크톱 프로토콜) 세션에 로그온하는 경우
RunAs 옵션을 사용하여 작업을 실행하는 경우
컴퓨터에서 활성 Windows 서비스를 실행하는 경우
예약된 작업 또는 일괄 처리 작업을 실행하는 경우
원격 관리 도구를 사용하여 로컬 컴퓨터에서 작업을 실행하는 경우
경우에 따라 SYSTEM 계정 프로세스에서만 액세스할 수 있는 암호 데이터 조각인 LSA 암호가 하드 디스크 드라이브에 저장됩니다. 이러한 암호 중 일부는 다시 부팅 후 유지해야 하는 자격 증명이며, 하드 디스크 드라이브에 암호화된 형식으로 저장됩니다. LSA 암호로 저장될 수 있는 자격 증명은 다음과 같습니다.
컴퓨터의 AD DS(Active Directory Domain Services) 계정에 대한 계정 암호
컴퓨터에 구성되어 있는 Windows 서비스에 대한 계정 암호
구성된 예약된 작업에 대한 계정 암호
IIS 애플리케이션 풀 및 웹 사이트에 대한 계정 암호
Microsoft 계정의 암호
Windows 8.1에 도입된 클라이언트 운영 체제는 보호되지 않는 프로세스에 의한 메모리 및 코드 주입 읽기를 방지하기 위해 LSA에 대한 추가 보호를 제공합니다. 이 보호 기능으로 인해 LSA에서 저장 및 관리하는 자격 증명에 대한 보안이 강화됩니다.
이러한 추가 보호에 대한 자세한 내용은 추가 LSA 보호 구성을 참조하세요.
캐시된 자격 증명 및 유효성 검사
유효성 검사 메커니즘은 로그온 시 자격 증명 표시를 사용합니다. 하지만 컴퓨터가 도메인 컨트롤러에서 연결이 끊어지고 사용자가 도메인 자격 증명을 표시하는 경우 Windows는 유효성 검사 메커니즘에서 캐시된 자격 증명 프로세스를 사용합니다.
사용자가 도메인에 로그온할 때마다 Windows는 제공된 자격 증명을 캐시하며 운영 시스템의 레지스트리에 있는 보안 하이브에 저장합니다.
캐시된 자격 증명을 사용하면 사용자는 해당 도메인 내의 도메인 컨트롤러에 연결하지 않고도 도메인 구성원에 로그온할 수 있습니다.
자격 증명 스토리지 및 유효성 검사
다른 리소스에 액세스하기 위해 자격 증명 집합 중 하나를 사용하는 것이 항상 바람직하지는 않습니다. 예를 들어 관리자는 원격 서버에 액세스하는 경우 사용자 자격 증명 대신 관리자를 사용할 수 있습니다. 이와 유사하게 사용자가 은행 계좌와 같은 외부 리소스에 액세스하는 경우 도메인 자격 증명과 다른 자격 증명만 사용할 수 있습니다. 다음 섹션에서는 현재 버전의 Windows 운영 체제와 Windows Vista 및 Windows XP 운영 체제 간의 자격 증명 관리의 차이점에 대해 설명합니다.
원격 로그온 자격 증명 프로세스
RDP(원격 데스크톱 프로토콜)는 Windows 8에서 도입한 원격 데스크톱 클라이언트를 사용하여 원격 컴퓨터에 연결하는 사용자의 자격 증명을 관리합니다. 일반 텍스트 형식의 자격 증명은 호스트에서 인증 프로세스를 수행하려고 시도하고 성공하는 경우 사용자를 허용된 리소스에 연결하는 대상 호스트로 전송됩니다. RDP는 자격 증명을 클라이언트에 저장하지 않지만 사용자의 도메인 자격 증명은 LSASS에 저장됩니다.
Windows Server 2012 R2 및 Windows 8.1에 도입된 제한된 관리 모드는 원격 로그온 시나리오에 대한 추가 보안을 제공합니다. 이 원격 데스크톱 모드를 사용하면 클라이언트 애플리케이션이 NTOWF(NT 단방향 함수)를 사용하여 네트워크 로그온 챌린지 응답을 수행하거나 원격 호스트에 인증하는 경우 Kerberos 서비스 티켓을 사용합니다. 관리자가 인증된 후에는 관리자가 원격 호스트에 제공되지 않았으므로 LSASS에 해당 계정 자격 증명이 없습니다. 대신 관리자에게는 세션에 대한 컴퓨터 계정 자격 증명이 있습니다. 관리자 자격 증명은 원격 호스트에 제공되지 않으므로 작업은 컴퓨터 계정으로 수행됩니다. 또한 리소스는 컴퓨터 계정으로 제한되고 관리자는 자신의 계정으로 리소스에 액세스할 수 없습니다.
로그온 자격 증명 프로세스 자동 재시작
사용자가 Windows 8.1 디바이스에 로그인하는 경우 LSA는 LSASS.exe에서만 액세스할 수 있는 암호화된 메모리에 사용자 자격 증명을 저장합니다. Windows 업데이트에서 사용자의 현재 상태 없이 자동 재시작을 시작하는 경우 이러한 자격 증명은 사용자에 대한 자동 로그온을 구성하는 데 사용됩니다.
재시작할 때 사용자는 자동 로그온 메커니즘을 통해 자동으로 로그인된 다음 사용자의 세션을 보호하기 위해 컴퓨터가 추가로 잠깁니다. 잠금은 Winlogon을 통해 시작되는 반면 자격 증명 관리는 LSA에서 수행됩니다. 자동으로 로그인하고 콘솔에서 사용자 세션을 잠그면 사용자의 잠금 화면 애플리케이션이 재시작되고 사용할 수 있습니다.
ARSO에 대한 자세한 내용은 Winlogon 자동 재시작을 참조하세요.
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 Settings\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는 Active Directory 도메인의 도메인 계정을 관리합니다.
예를 들면 Windows 운영 체제를 실행하는 클라이언트 컴퓨터는 사용자 로그온이 없는 경우에도 도메인 컨트롤러와 통신하여 네트워크 도메인에 참여합니다. 통신을 시작하려면 컴퓨터에 도메인에 활성 계정이 있어야 합니다. 컴퓨터의 통신을 수락하기 전에 도메인 컨트롤러의 LSA는 컴퓨터의 ID를 인증한 다음, 사용자 보안 주체와 같이 컴퓨터의 보안 컨텍스트를 생성합니다. 이 보안 컨텍스트는 특정 컴퓨터의 사용자나 서비스 또는 네트워크상의 사용자, 서비스 또는 컴퓨터의 신원 및 기능을 정의합니다. 예를 들면 보안 컨텍스트 내에 포함된 액세스 토큰은 액세스할 수 있는 리소스(예: 파일 공유 또는 프린터)와 해당 보안 주체(사용자, 컴퓨터 또는 해당 리소스의 서비스)에서 수행할 수 있는 작업(예: 읽기, 쓰기 또는 수정)을 정의합니다.
사용자 또는 컴퓨터의 보안 컨텍스트는 사용자가 사용자의 자체 기본 워크스테이션이 아닌 서버나 워크스테이션에 로그온하는 경우와 같이 컴퓨터마다 다를 수 있습니다. 관리자가 사용자의 권리 및 권한을 수정하는 경우와 같이 세션마다 다를 수도 있습니다. 또한 사용자 또는 컴퓨터가 독립 실행형 기반, 네트워크 또는 Active Directory 도메인의 일부로 작동하는 경우 보안 컨텍스트는 일반적으로 다릅니다.
로컬 도메인 및 신뢰할 수 있는 도메인
두 개의 도메인 간에 트러스트가 있는 경우 각 도메인에 대한 인증 메커니즘은 다른 도메인에서 들어오는 인증의 유효성을 사용합니다. 트러스트는 수신되는 인증 요청이 신뢰할 수 있는 기관(신뢰할 수 있는 도메인)에서 온 것인지 확인하여 리소스 도메인(신뢰할 수 있는 도메인)의 공유 리소스에 대한 제어된 액세스를 제공하도록 도움을 줍니다. 이 방식으로 트러스트는 유효성이 검사된 인증 요청만 도메인 간에 이동되도록 허용하는 브리지 역할을 합니다.
특정 트러스트가 인증 요청을 전달하는 방법은 구성 방법에 따라 다릅니다. 트러스트 관계는 신뢰할 수 있는 도메인에서 신뢰할 수 있는 도메인의 리소스에 대한 액세스를 제공하거나 다른 도메인의 리소스에 대한 액세스를 각 도메인에서 양방향으로 제공하여 단방향일 수 있습니다. 트러스트는 또한 비전환적이며 이러한 경우 트러스트는 두 개의 트러스트 파트너 도메인 간에만 존재하거나 전이적입니다. 이러한 경우 트러스트는 파트너 중 하나가 신뢰하는 다른 도메인으로 자동 확장됩니다.
인증과 관련된 도메인 및 포리스트 트러스트 관계에 대한 자세한 내용은 위임된 인증 및 트러스트 관계를 참조하세요.
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(가상 사설망) 및 무선 연결을 비롯한 다양한 유형의 네트워크 액세스에 대해 인증서 기반 인증을 수행합니다.
네트워킹의 인증서 기반 인증에 대한 자세한 내용은 네트워크 액세스 인증 및 인증서를 참조하세요.