Windows 디바이스의 상태 제어

아티클
07/16/2024
적용 대상:

✅ Windows 11, ✅ Windows 10

이 문서에서는 Windows 디바이스의 상태를 적용, 제어 및 보고하여 고부가가치 자산을 보호하는 데 도움이 되는 엔드 투 엔드 솔루션을 자세히 설명합니다.

소개

BYOD(Bring Your Own Device) 시나리오의 경우 사용자는 업무 관련 리소스와 개인 데이터에 모두 액세스하기 위해 상업적으로 사용 가능한 디바이스를 가져옵니다. 사용자는 선택한 디바이스를 사용하여 내부 네트워크뿐만 아니라 어디서나 조직의 애플리케이션, 데이터 및 리소스에 액세스하려고 합니다. 이 현상을 IT 소비라고도 합니다.

사용자는 회사 애플리케이션에 액세스하고 디바이스에서 조직 데이터를 작업할 때 최상의 생산성 환경을 원합니다. 즉, 애플리케이션 또는 파일 서버에 액세스할 때마다 회사 자격 증명을 입력하라는 메시지가 표시되는 것을 용납하지 않습니다. 보안 관점에서 볼 때 사용자가 관리되지 않는 디바이스에서 회사 자격 증명 및 회사 데이터를 조작한다는 의미이기도 합니다.

BYOD의 사용이 증가함에 따라 회사 서비스, 내부 리소스 및 클라우드 앱에 액세스하는 비관리형 및 잠재적으로 비정상 시스템이 늘어나게 됩니다.

관리되는 디바이스조차도 손상되어 해로워질 수 있습니다. 조직은 높은 가치의 자산을 보호하기 위해 보안이 침해된 시기를 감지하고 가능한 한 빨리 대응해야 합니다.

Microsoft가 앞으로 나아갈수록 보안 투자는 보안 예방 방어와 탐지 및 대응 기능에 점점 더 초점을 맞추고 있습니다.

Windows는 보안 예방 방어 구현뿐만 아니라 전체 보안 전략에 디바이스 상태 증명 기능을 추가하는 엔드투엔드 보안 솔루션의 중요한 구성 요소입니다.

강력한 엔드 투 엔드 보안 솔루션에 대한 설명

오늘날의 컴퓨팅 위협 환경은 이전에는 발생하지 않았던 속도로 증가하고 있습니다. 범죄 공격의 정교함이 증가하고 있으며, 맬웨어가 이제 모든 산업의 소비자와 전문가를 대상으로 한다는 것은 의심의 여지가 없습니다.

최근 몇 년 동안 특정 위협 범주인 APT(고급 영구 위협)가 널리 보급되었습니다. APT라는 용어는 일반적으로 지속적으로 개별 조직을 대상으로 하는 것처럼 보이는 모든 공격을 설명하는 데 사용됩니다. 실제로 이러한 유형의 공격에는 일반적으로 필요한 방법이나 기술을 사용할 수 있는 결정된 악의적 사용자가 포함됩니다.

BYOD 현상을 사용하면 제대로 유지 관리되지 않는 디바이스가 선택한 대상을 나타냅니다. 공격자의 경우 보안 네트워크 경계를 위반하고 액세스 권한을 얻은 다음 고부가가치 자산을 도용하는 쉬운 방법입니다.

공격자는 개인을 대상으로, 특히 때문에 그들이 누구인지, 하지만 때문에 그들이 일하는 사람. 감염된 디바이스는 조직이 네트워크 경계를 강화했거나 방어 태세에 투자한 경우에도 조직에 맬웨어를 가져옵니다. 방어 전략은 이러한 위협에 대해 충분하지 않습니다.

다른 접근 방식

효과적인 보안 전략은 기존의 타협 방지에 중점을 두기보다는 결정된 악의적 사용자가 모든 방어를 성공적으로 위반할 것이라고 가정합니다. 즉, 예방적 보안 제어에서 보안 문제를 탐지하고 대응하는 것으로 초점을 전환해야 합니다. 따라서 위험 관리 전략의 구현은 예방, 탐지 및 대응에 대한 투자의 균형을 조정합니다.

모바일 디바이스는 회사 정보에 액세스하는 데 점점 더 사용되므로 디바이스 보안 또는 상태를 평가하는 방법이 필요합니다. 이 섹션에서는 고부가가치 자산을 비정상 디바이스로부터 보호할 수 있는 방식으로 디바이스 상태 평가를 프로비전하는 방법을 설명합니다.

회사 리소스에 액세스하는 데 사용되는 디바이스는 신뢰할 수 있어야 합니다. 효율적인 엔드 투 엔드 보안 접근 방식은 높은 가치의 자산에 대한 액세스 권한을 부여할 때 디바이스 상태를 평가하고 현재 보안 상태를 사용할 수 있습니다.

그림 1.

강력한 디자인은 사용자의 ID를 설정하고, 필요한 경우 인증 방법을 강화하고, 사용자가 정기적으로 연결하는 네트워크 위치와 같은 동작을 학습해야 합니다. 또한 최신 접근 방식은 사용자 디바이스가 정상적이고 안전한 것으로 확인된 경우에만 중요한 콘텐츠를 릴리스할 수 있어야 합니다.

다음 그림에서는 클라우드에서 디바이스 상태를 평가하기 위해 빌드된 솔루션을 보여 있습니다. 디바이스는 클라우드의 ID 공급자에 대한 연결을 통해 사용자를 인증합니다. 관리 자산에 기밀 정보가 포함된 경우 ID 공급자의 조건부 액세스 엔진은 액세스 권한이 부여되기 전에 모바일 디바이스의 보안 규정 준수를 확인하도록 선택할 수 있습니다. 사용자의 디바이스는 언제든지 또는 MDM(모바일 디바이스 관리)이 요청할 때 전송할 수 있는 상태를 증명할 수 있습니다.

그림 2.

Windows 디바이스는 UEFI(Unified Extensible Firmware Interface) 보안 부팅과 같은 하위 수준 하드웨어 기술을 사용하여 하위 수준 루트킷 및 부트킷으로부터 보호할 수 있습니다.

보안 부팅은 루트킷 공격을 방지하는 데 도움이 되는 펌웨어 유효성 검사 프로세스입니다. UEFI 사양의 일부입니다. UEFI의 목적은 운영 체제가 최신 하드웨어와 통신할 수 있는 표준 방법을 정의하는 것입니다. 이 방법은 이전 소프트웨어 인터럽트 기반 BIOS 시스템보다 더 빠르고 효율적인 I/O(입력/출력) 함수로 수행할 수 있습니다.

디바이스 상태 증명 모듈은 TPM(신뢰할 수 있는 플랫폼 모듈)으로 보호되는 측정된 부팅 데이터를 원격 서비스로 통신할 수 있습니다. 디바이스가 성공적으로 부팅되면 부팅 프로세스 측정 데이터가 보다 안전하고 변조 방지 통신 채널을 사용하여 신뢰할 수 있는 클라우드 서비스(상태 증명 서비스)로 전송됩니다.

원격 상태 증명 서비스는 측정값에 대한 일련의 검사를 수행합니다. 부팅 상태(보안 부팅, 디버그 모드 등) 및 보안을 관리하는 구성 요소의 상태(BitLocker, Device Guard 등)를 비롯한 보안 관련 데이터 요소의 유효성을 검사합니다. 그런 다음, 디바이스에 다시 상태 암호화된 Blob을 전송하여 디바이스의 상태를 전달합니다.

MDM 솔루션은 일반적으로 구성 정책을 적용하고 디바이스에 소프트웨어를 배포합니다. MDM은 보안 기준을 정의하고 설치된 소프트웨어와 적용되는 구성을 확인하고 디바이스의 상태를 결정하는 정기적인 검사를 통해 디바이스의 준수 수준을 알고 있습니다.

MDM 솔루션은 디바이스에 디바이스 상태 정보를 보내고 상태 암호화된 Blob을 원격 상태 증명 서비스로 전달하도록 요청합니다. 원격 상태 증명 서비스는 디바이스 상태 데이터를 확인하고, MDM이 동일한 디바이스와 통신하고 있는지 확인한 다음, 디바이스 상태 보고서를 MDM 솔루션에 다시 발급합니다.

MDM 솔루션은 상태 어설션을 평가하고 조직에 속한 상태 규칙에 따라 디바이스가 정상인지 여부를 결정할 수 있습니다. 디바이스가 정상이고 규정을 준수하는 경우 MDM은 해당 정보를 ID 공급자에게 전달하여 액세스 권한을 부여하기 위해 조직의 액세스 제어 정책을 호출할 수 있습니다.

콘텐츠에 대한 액세스 권한은 상태 및 기타 조건부 요소가 나타내는 모든 것에 대해 적절한 신뢰 수준에 부여됩니다.

관리 자산의 요구 사항 및 민감도에 따라 액세스 요청을 처리할 때 디바이스 상태를 사용자 ID 정보와 결합할 수 있습니다. 콘텐츠에 대한 액세스 권한은 적절한 신뢰 수준에 부여됩니다. 조건부 액세스 엔진은 관리 자산의 민감도에 따라 필요에 따라 더 많은 확인을 허용하도록 구조화될 수 있습니다. 예를 들어 값이 높은 데이터에 대한 액세스가 요청되면 액세스 권한이 부여되기 전에 사용자에게 전화 통화에 응답하도록 쿼리하여 추가 보안 인증을 설정해야 할 수 있습니다.

Windows에 대한 Microsoft의 보안 투자

Windows에는 다음과 같은 세 가지 투자 요소가 있습니다.

ID를 보호합니다. Microsoft는 로컬 시스템 및 온-프레미스 리소스 및 클라우드 리소스와 같은 서비스 모두에서 인증을 위한 암호 사용에서 벗어나 상호 운용 가능한 보안 인증 방법을 제공하는 것을 목표로 하는 FIDO 동맹의 일부입니다.
정보 보호. Microsoft는 조직이 중요한 데이터에 액세스할 수 있는 사용자와 해당 데이터로 수행할 수 있는 작업을 더 잘 제어할 수 있도록 투자를 하고 있습니다. Windows를 사용하면 조직에서 회사 애플리케이션으로 간주되고 보안 데이터에 액세스하도록 신뢰할 수 있는 애플리케이션을 지정하는 정책을 활용할 수 있습니다.
위협 저항. Microsoft는 조직이 하드웨어에 의존하는 보안 방어를 사용하여 맬웨어 및 공격의 위협에서 엔터프라이즈 자산을 더 잘 보호할 수 있도록 돕고 있습니다.

Windows 기반 디바이스의 보안 상태 보호, 제어 및 보고

이 섹션은 공격자 및 맬웨어로부터 고부가가치 자산 및 정보를 보호하는 데 도움이 되는 엔드투엔드 보안 솔루션의 다양한 부분을 설명하는 개요입니다.

그림 3.

숫자	솔루션의 일부	설명
1	Windows 기반 디바이스	Windows 기반 디바이스가 처음 켜지면 OOBE(기본 제공 환경) 화면이 표시됩니다. 설치하는 동안 디바이스를 Microsoft Entra ID에 자동으로 등록하고 MDM에 등록할 수 있습니다. TPM이 있는 Windows 기반 디바이스는 지원되는 모든 Windows 버전에서 사용할 수 있는 상태 증명 서비스를 사용하여 언제든지 상태를 보고할 수 있습니다.
2	ID 공급자	Microsoft Entra ID에는 사용자, 등록된 디바이스 및 조직 테넌트의 등록된 애플리케이션이 포함됩니다. 디바이스는 항상 사용자에 속하며 사용자는 여러 디바이스를 가질 수 있습니다. 디바이스는 디바이스의 준수 상태와 같은 다른 특성을 가진 개체로 표시됩니다. 신뢰할 수 있는 MDM은 규정 준수 상태를 업데이트할 수 있습니다. Microsoft Entra ID는 리포지토리 이상입니다. Microsoft Entra ID는 사용자 및 디바이스를 인증할 수 있으며 관리되는 리소스에 대한 액세스 권한을 부여할 수도 있습니다. Microsoft Entra ID에는 사용자의 ID, 디바이스 위치 및 신뢰할 수 있는 액세스 결정을 내릴 때 디바이스의 준수 상태를 사용하는 조건부 액세스 제어 엔진이 있습니다.
3	모바일 장치 관리	Windows에는 에이전트를 배포하지 않고도 디바이스를 기본으로 관리할 수 있는 MDM 지원이 있습니다. MDM은 Microsoft Intune 또는 Windows와 호환되는 타사 MDM 솔루션일 수 있습니다.
4	원격 상태 증명	상태 증명 서비스는 Microsoft에서 운영하는 신뢰할 수 있는 클라우드 서비스로, 일련의 상태 검사를 수행하고 디바이스에서 사용하도록 설정된 Windows 보안 기능을 MDM에 보고합니다. 보안 확인에는 부팅 상태(WinPE, 안전 모드, 디버그/테스트 모드) 및 런타임 작업의 보안 및 무결성을 관리하는 구성 요소(BitLocker, Device Guard)가 포함됩니다.
5	엔터프라이즈 관리 자산	엔터프라이즈 관리 자산은 보호할 리소스입니다. 예를 들어 자산은 Office 365, 기타 클라우드 앱, Microsoft Entra ID에서 게시한 온-프레미스 웹 리소스 또는 VPN 액세스일 수 있습니다.

Windows 기반 디바이스, ID 공급자, MDM 및 원격 상태 증명의 조합은 고부가가치 자산에 액세스하는 디바이스의 상태 및 규정 준수 유효성 검사를 제공하는 강력한 엔드 투 엔드 솔루션을 만듭니다.

위협으로부터 디바이스 및 엔터프라이즈 자격 증명 보호

이 섹션에서는 Windows가 보안 방어 측면에서 제공하는 기능과 측정 및 보고할 수 있는 제어에 대해 설명합니다.

Windows 하드웨어 기반 보안 방어

가장 공격적인 형태의 맬웨어는 가능한 한 빨리 부팅 프로세스에 자신을 삽입하여 운영 체제를 조기에 제어하고 보호 메커니즘 및 맬웨어 방지 소프트웨어가 작동하지 않도록 방지하려고 합니다. 이러한 유형의 악성 코드는 종종 루트킷 또는 부트킷이라고 합니다. 낮은 수준의 맬웨어를 처리하지 않아도 되는 가장 좋은 방법은 디바이스가 처음부터 보호되도록 부팅 프로세스를 보호하는 것입니다. Windows는 여러 계층의 부팅 보호를 지원합니다. 이러한 기능 중 일부는 특정 유형의 하드웨어가 설치된 경우에만 사용할 수 있습니다. 자세한 내용은 하드웨어 요구 사항 섹션을 참조하세요 .

그림 4.

Windows는 시작 프로세스 중에 루트킷 및 부트킷과 같은 정교한 하위 수준 맬웨어가 로드되지 않도록 하는 기능을 지원합니다.

신뢰할 수 있는 플랫폼 모듈. TPM(신뢰할 수 있는 플랫폼 모듈)은 고유한 보안 기능을 제공하는 하드웨어 구성 요소입니다.

Windows는 자격 증명을 보호하거나 상태 증명을 위해 부팅 무결성 시퀀스(그리고 이를 기반으로 자동으로 BitLocker 보호 드라이브 잠금 해제)를 측정하기 위해 TPM의 보안 특성을 사용합니다.

TPM은 TCG(신뢰할 수 있는 컴퓨팅 그룹)에서 설명한 사양을 충족하는 컨트롤을 구현합니다. 이 글을 쓰는 시점에 서로 호환되지 않는 TCG에서 생성된 두 가지 버전의 TPM 사양이 있습니다.
- 첫 번째 TPM 사양인 버전 1.2는 TCG에 의해 2005년 2월에 게시되었으며 ISO/IEC 11889 표준에 따라 표준화되었습니다.
- TPM 2.0이라고 하는 최신 TPM 사양은 2014년 4월에 릴리스되었으며 ISO/IEC JTC(공동 기술 위원회)에서 ISO/IEC 11889:2015로 승인되었습니다.
Windows는 상태 증명의 일부로 암호화 계산에 TPM을 사용하고 BitLocker, Windows Hello, 가상 스마트 카드 및 기타 공개 키 인증서의 키를 보호합니다. 자세한 내용은 Windows의 TPM 요구 사항을 참조하세요.

Windows는 TCG에서 생성된 버전 1.2 및 2.0 TPM 사양을 인식합니다. 최신 및 최신 보안 기능의 경우 Windows는 TPM 2.0만 지원합니다.

TPM 2.0은 TPM 1.2를 통한 기능에 대한 주요 수정 버전을 제공합니다.
- 최신 보안 요구 사항을 충족하도록 암호화 강도 업데이트
  - PCR용 SHA-256 지원
  - HMAC 명령 지원
- 정부 요구 사항을 지원하는 암호화 알고리즘 유연성
  - TPM 1.2는 지원할 수 있는 알고리즘 측면에서 심각하게 제한됩니다.
  - TPM 2.0은 TCG 사양 문서에 대한 사소한 업데이트로 임의의 알고리즘을 지원할 수 있습니다.
- 구현 간 일관성
  - TPM 1.2 사양을 사용하면 구현 세부 정보를 선택할 때 공급업체가 넓은 위도를 선택할 수 있습니다.
  - TPM 2.0은 이 동작의 대부분을 표준화합니다.
보안 부팅. UEFI 펌웨어가 있는 디바이스는 신뢰할 수 있는 운영 체제 부팅 로더만 로드하도록 구성할 수 있습니다. 보안 부팅에는 TPM이 필요하지 않습니다.

가장 기본적인 보호는 UEFI 2.2 이상 아키텍처의 표준 부분인 보안 부팅 기능입니다. 기존 BIOS가 있는 PC에서 부팅 프로세스를 제어할 수 있는 모든 사용자는 대체 OS 로더를 사용하여 부팅하고 잠재적으로 시스템 리소스에 액세스할 수 있습니다. 보안 부팅을 사용하도록 설정하면 UEFI 보안 부팅 DB에 저장된 인증서를 사용하여 서명된 OS 로더만 사용하여 부팅할 수 있습니다. 당연히 Windows OS 로더에 디지털 서명하는 데 사용되는 Microsoft 인증서는 해당 저장소에 있으므로 UEFI는 보안 정책의 일부로 인증서의 유효성을 검사할 수 있습니다. Windows 하드웨어 호환성 프로그램에 따라 Windows용으로 인증된 모든 컴퓨터에서 보안 부팅을 기본적으로 사용하도록 설정해야 합니다.

보안 부팅은 부팅 시 중요한 부팅 파일 및 드라이버의 서명 및 확인을 허용하는 UEFI 펌웨어 기반 기능입니다. 보안 부팅은 빌드 시 OEM에서 정의한 정책을 사용하여 시스템이 사용 가능한 운영 체제로 완전히 부팅되도록 허용되기 전에 부팅 시 Windows 부팅 관리자, BCD 저장소, Windows OS 로더 파일 및 기타 부팅에 중요한 DLL의 서명 값을 확인합니다. 보안 부팅은 Windows 플랫폼에 대한 다양한 유형의 부팅 기반 루트킷, 맬웨어 및 기타 보안 관련 공격을 방지합니다. 보안 부팅은 로컬 하드 디스크, USB, PXE 또는 DVD에서 부팅하든 전체 Windows 또는 RE(Windows 복구 환경)로 부팅하든 운영 체제 부팅 프로세스를 보호합니다. 보안 부팅은 중요한 부팅 구성 요소의 서명을 확인하여 악의적인 활동이 손상되지 않았는지 확인하여 Windows 설치의 부팅 환경을 보호합니다. 보안 부팅 보호는 Windows 커널 파일(ntoskrnl.exe)이 로드된 후 종료됩니다.

참고

보안 부팅은 Windows 커널이 로드될 때까지 플랫폼을 보호합니다. 그런 다음 ELAM과 같은 보호가 인계됩니다.
보안 부팅 구성 정책. 보안 부팅 기능을 중요한 Windows 구성으로 확장합니다.

보호된 구성 정보의 예로는 NX(실행 안 함 옵션) 보호 또는 테스트 서명 정책(코드 무결성)을 사용할 수 없는지 확인 등이 있습니다. 이 보호 작업을 수행하면 부팅 프로세스가 완료된 후 컴퓨터의 이진 파일 및 구성을 신뢰할 수 있습니다. 보안 부팅 구성 정책은 UEFI 정책을 사용하여 이 보호 작업을 수행합니다. 이러한 정책에 대한 이러한 서명은 운영 체제 이진 파일이 보안 부팅과 함께 사용하기 위해 서명되는 것과 동일한 방식으로 서명됩니다.

보안 부팅 구성 정책은 KEK(키 교환 키) 목록에 저장된 공개 키 중 하나에 해당하는 프라이빗 키로 서명해야 합니다. MICROSOFT CA(인증 기관)는 모든 Windows 인증 보안 부팅 시스템의 KEK 목록에 표시됩니다. 기본적으로 Microsoft KEK에서 서명한 정책은 모든 보안 부팅 시스템에서 작동합니다. BootMgr은 서명된 정책을 적용하기 전에 KEK 목록에 대한 서명을 확인해야 합니다. Windows를 사용하면 기본 보안 부팅 구성 정책이 bootmgr에 포함됩니다.

부팅 로더는 로드하기 전에 Windows 커널의 디지털 서명을 확인합니다. Windows 커널은 부팅 드라이버, 시작 파일 및 ELAM 구성 요소를 포함하여 Windows 시작 프로세스의 다른 모든 구성 요소를 확인합니다. 이 단계는 중요하며 모든 Windows 부팅 구성 요소에 무결성이 있고 신뢰할 수 있는지 확인하여 부팅 프로세스의 나머지 부분을 보호합니다.
ELAM(맬웨어 방지 조기 실행). ELAM은 로드하기 전에 모든 드라이버를 테스트하여 승인되지 않은 드라이버가 로드되지 않도록 합니다.

기존 맬웨어 방지 앱은 부팅 드라이버가 로드될 때까지 시작되지 않으므로 드라이버로 위장한 루트킷이 작동할 수 있습니다. ELAM은 이전 버전의 Windows에서 도입된 Windows 메커니즘으로, 부팅 시퀀스 초기에 맬웨어 방지 소프트웨어를 실행할 수 있습니다. 따라서 맬웨어 방지 구성 요소는 Windows 운영 체제가 작동할 때까지 다른 부팅 드라이버의 초기화를 실행하고 제어하는 최초의 타사 구성 요소입니다. 시스템이 완전한 런타임 환경(네트워크 액세스, 스토리지 등)으로 시작되면 전체 기능을 갖춘 맬웨어 방지가 로드됩니다.

ELAM은 모든 타사 부팅 드라이버 및 애플리케이션 앞에 Microsoft 또는 타사 맬웨어 방지 드라이버를 로드하여 보안 부팅 및 신뢰할 수 있는 부팅에 의해 설정된 신뢰 체인을 계속할 수 있습니다. 운영 체제가 아직 시작되지 않았고 Windows가 가능한 한 빨리 부팅해야 하기 때문에 ELAM에는 모든 부팅 드라이버를 검사하고 신뢰할 수 있는 드라이버 목록에 있는지 확인하는 간단한 작업이 있습니다. 신뢰할 수 없는 경우 Windows에서 로드하지 않습니다.

참고

Windows에 기본적으로 포함된 Microsoft의 맬웨어 방지 프로그램인 Windows Defender는 ELAM을 지원합니다. 타사 맬웨어 방지 호환 솔루션으로 대체할 수 있습니다. Windows Defender ELAM 드라이버의 이름이 WdBoot.sys. Windows Defender는 ELAM 드라이버를 사용하여 다음 재부팅 시 Windows Defender 드라이버에 대한 악의적인 변경 내용을 롤백합니다. 이렇게 하면 커널 모드 맬웨어가 종료 또는 다시 부팅하기 전에 Windows Defender의 미니 필터 드라이버를 계속 변경할 수 없습니다.

ELAM 서명된 드라이버는 다른 타사 드라이버 또는 애플리케이션 앞에 로드되므로 맬웨어 방지 소프트웨어가 서명되지 않거나 신뢰할 수 없는 코드를 로드하여 부팅 프로세스를 변조하려는 시도를 감지하고 차단할 수 있습니다.

ELAM 드라이버는 시스템 시작 초기에 로드되는 드라이버에 초점을 맞춘 범위가 좁은 작은 정책 데이터베이스가 있는 작은 드라이버입니다. 정책 데이터베이스는 ELAM 드라이버의 작동 매개 변수를 기록하기 위해 TPM으로 측정되는 레지스트리 하이브에 저장됩니다. ELAM 드라이버는 Microsoft에서 서명해야 하며 연결된 인증서에는 보완 EKU(1.3.6.1.4.1.311.61.4.1)가 포함되어야 합니다.
가상화 기반 보안(Hyper-V + 보안 커널). 가상화 기반 보안은 Windows의 중요한 부분을 보호할 수 있는 새로운 보안 경계입니다.

가상화 기반 보안은 커널 모드 코드 무결성 또는 중요한 회사 도메인 자격 증명과 같은 중요한 코드를 Windows 운영 체제의 나머지 부분과 격리합니다. 자세한 내용은 가상화 기반 보안 섹션을 참조하세요.
HVCI(하이퍼바이저로 보호되는 코드 무결성). 하이퍼바이저로 보호되는 코드 무결성은 Device Guard 코드 무결성 정책을 준수하는 드라이버, 실행 파일 및 DLL만 실행할 수 있도록 하는 Device Guard의 기능입니다.

사용하도록 설정하고 구성하면 Windows에서 Hyper-V 가상화 기반 보안 서비스를 시작할 수 있습니다. HVCI는 부팅 프로세스 초기에 또는 시작 후 맬웨어가 실행되지 않도록 방지하여 시스템 코어(커널), 권한 있는 드라이버 및 시스템 방어(예: 맬웨어 방지 솔루션)를 보호하는 데 도움이 됩니다.

HVCI는 가상화 기반 보안을 사용하여 코드 무결성을 격리합니다. 커널 메모리가 실행될 수 있는 유일한 방법은 코드 무결성 확인을 통해서입니다. 확인에 대한 이러한 종속성은 커널 메모리 페이지는 쓰기 가능 및 실행 파일(W+X)이 될 수 없으며 실행 코드를 직접 수정할 수 없음을 의미합니다.

참고

가상화 기반 보안을 사용하여 커널 모드 코드 무결성을 실행하는 Device Guard 디바이스에는 호환 드라이버가 있어야 합니다. 자세한 내용은 Windows의 Device Guard와의 드라이버 호환성 블로그 게시물을 참조하세요.

Device Guard 코드 무결성 기능을 사용하면 조직에서 Windows 커널에서 실행할 신뢰할 수 있는 코드와 사용자 모드에서 실행하도록 승인된 애플리케이션을 제어할 수 있습니다. 정책을 사용하여 구성할 수 있습니다. Device Guard 코드 무결성 정책은 Microsoft에서 서명을 권장하는 이진 파일입니다. 코드 무결성 정책 서명은 현재 코드 무결성 정책을 수정하거나 제거하려는 관리자 권한이 있는 악의적인 사용자에 대한 보호를 지원합니다.
Credential Guard. Credential Guard는 하드웨어 기반 자격 증명 격리를 사용하여 회사 자격 증명을 보호합니다.

Windows에서 Credential Guard는 도메인 회사 자격 증명을 도난으로부터 보호하고 맬웨어에 의해 재사용하는 것을 목표로 합니다. Credential Guard를 사용하여 Windows는 현재 형태의 PtH(pass-the-hash) 공격을 근본적으로 방지하는 아키텍처 변경을 구현했습니다.

이 공격 없는 상태는 Hyper-V 및 새 가상화 기반 보안 기능을 사용하여 신뢰할 수 있는 코드와 비밀이 Windows 커널에서 격리되는 보호된 컨테이너를 만들어서 수행됩니다. 이는 Windows 커널이 손상되더라도 공격자가 PtH 공격을 시작하는 데 필요한 데이터를 읽고 추출할 방법이 없음을 의미합니다. 암호가 저장된 메모리는 메모리에 액세스할 수 있는 하이퍼바이저 컨트롤인 커널 모드에서도 일반 OS에서 더 이상 액세스할 수 없으므로 Credential Guard는 이 무단 액세스를 방지합니다.
상태 증명. 디바이스의 펌웨어는 부팅 프로세스를 기록하며 Windows는 디바이스의 상태를 확인하고 평가할 수 있는 신뢰할 수 있는 서버로 보낼 수 있습니다.

Windows는 UEFI 펌웨어를 측정하고 각 Windows 및 맬웨어 방지 구성 요소는 부팅 프로세스 중에 로드할 때 만들어집니다. 또한, 그들은 촬영 하 고 순차적으로 측정, 모든 한 번에. 이러한 측정이 완료되면 해당 값은 디지털 서명되고 TPM에 안전하게 저장되며 시스템이 다시 설정되지 않으면 변경할 수 없습니다.

자세한 내용은 보안 부팅 및 측정 부팅: 맬웨어에 대한 초기 부팅 구성 요소 강화를 참조하세요.

각 후속 부팅 중에 동일한 구성 요소가 측정되므로 예상 기준과 측정값을 비교할 수 있습니다. 보안을 강화하려면 TPM으로 측정된 값을 서명하고 원격 서버로 전송하여 비교를 수행할 수 있습니다. 원격 디바이스 상태 증명이라고 하는 이 프로세스를 통해 서버는 Windows 디바이스의 상태를 확인할 수 있습니다.

보안 부팅은 사전 예방적 보호 형태이지만 상태 증명은 반응형 형태의 부팅 보호입니다. 상태 증명은 Windows에서 사용하지 않도록 설정되며 맬웨어 방지 또는 MDM 공급업체에서 사용할 수 있습니다. 보안 부팅과 달리 상태 증명은 부팅 프로세스를 중지하지 않고 측정이 작동하지 않을 때 수정을 입력합니다. 그러나 조건부 액세스 제어를 통해 상태 증명은 고부가가치 자산에 대한 액세스를 방지하는 데 도움이 됩니다.

가상화 기반 보안

가상화 기반 보안은 Windows에 대한 새로운 신뢰 경계를 제공하고 Hyper-V 하이퍼바이저 기술을 사용하여 플랫폼 보안을 강화합니다. 가상화 기반 보안은 특정 Windows 신뢰할 수 있는 코드(trustlet)를 실행하고 중요한 데이터를 보호하기 위한 보안 실행 환경을 제공합니다.

가상화 기반 보안은 손상된 커널 또는 관리자 권한이 있는 악의적인 사용자로부터 보호하는 데 도움이 됩니다. 가상화 기반 보안은 물리적 공격자로부터 보호하려고 하지 않습니다.

다음 Windows 서비스는 가상화 기반 보안으로 보호됩니다.

LSA 자격 증명 보호 (LSA 자격 증명 격리): lsass 메모리의 콘텐츠를 읽고 덤프하여 발생하는 통과 해시 공격 및 엔터프라이즈 자격 증명 도난을 방지합니다.
Device Guard (Hyper-V 코드 무결성): Device Guard는 Windows의 새로운 가상화 기반 보안을 사용하여 Windows 커널 자체에서 코드 무결성 서비스를 격리합니다. 이를 통해 서비스는 엔터프라이즈 제어 정책에 의해 정의된 서명을 사용하여 신뢰할 수 있는 항목을 확인할 수 있습니다. 실제로 코드 무결성 서비스는 Windows 하이퍼바이저로 보호된 컨테이너의 커널과 함께 실행됩니다.
다른 격리된 서비스: 예를 들어 Windows Server 2016에는 서버에 암호화된 VM(가상 머신)을 사용할 수 있는 vTPM 기능이 있습니다.

참고

가상화 기반 보안은 Enterprise 버전에서만 사용할 수 있습니다. 가상화 기반 보안에는 보안 부팅이 사용하도록 설정된 UEFI(2.3.1 이상), 가상화 확장이 사용하도록 설정된 x64 프로세서 및 SLAT가 설정된 디바이스가 필요합니다. IOMMU, TPM 2.0. 보안 메모리 덮어쓰기 지원은 선택 사항이지만 권장됩니다.

아래 스키마는 가상화 기반 보안을 사용하는 Windows의 개략적인 보기입니다.

그림 5.

Credential Guard

Windows에서 Credential Guard를 사용하도록 설정하면 로컬 보안 기관 하위 시스템 서비스(lsass.exe)는 격리된 사용자 모드에서 중요한 코드를 실행하여 일반 사용자 모드에서 실행될 수 있는 맬웨어로부터 데이터를 보호합니다. 이 코드 실행은 보호된 데이터가 원격 머신에서 도난당하고 재사용되지 않도록 하여 많은 PtH 스타일 공격을 완화하는 데 도움이 됩니다.

Credential Guard는 부팅당 또는 영구 키로 자격 증명을 암호화하여 자격 증명을 보호하는 데 도움이 됩니다.

부팅당 키 는 지속성이 필요하지 않은 메모리 내 자격 증명에 사용됩니다. 이러한 자격 증명의 예로는 TGT(티켓 부여 티켓) 세션 키가 있습니다. 이 키는 인증이 발생할 때마다 KDC(키 배포 센터)와 협상되며 부팅당 키로 보호됩니다.
영구 키 또는 일부 파생 키는 다시 부팅 후 저장 및 다시 로드되는 항목을 보호하는 데 사용됩니다. 이러한 보호는 장기 스토리지를 위한 것이며 일관된 키로 보호되어야 합니다. Credential Guard는 레지스트리 키에 의해 활성화된 다음 UEFI 변수를 사용하여 사용하도록 설정됩니다. 이 활성화는 구성의 원격 수정으로부터 보호하기 위해 수행됩니다. UEFI 변수의 사용은 구성을 변경하려면 물리적 액세스가 필요하다는 것을 의미합니다. lsass.exe 자격 증명 격리가 사용하도록 설정된 것을 감지하면 격리된 프로세스로 LsaIso.exe 생성하여 격리된 사용자 모드 내에서 실행되도록 합니다. LsaIso.exe 시작은 보안 지원 공급자를 초기화하기 전에 수행되므로 인증이 시작되기 전에 보안 모드 지원 루틴이 준비됩니다.

Device Guard

Device Guard는 조직에서 신뢰할 수 없는 소프트웨어를 실행하지 못하도록 디바이스를 잠글 수 있는 Windows Enterprise의 기능입니다. 이 구성에서 실행할 수 있는 유일한 애플리케이션은 조직에서 신뢰할 수 있는 애플리케이션입니다.

코드 실행 신뢰 결정은 일반 Windows와 함께 실행되는 Hyper-V 보호 컨테이너인 가상화 기반 보안에서 실행되는 Hyper-V 코드 무결성을 사용하여 수행됩니다.

Hyper-V 코드 무결성은 메모리에 로드될 때마다 드라이버 또는 시스템 파일의 무결성을 확인하는 기능입니다. 코드 무결성은 서명되지 않은 드라이버 또는 시스템 파일이 커널에 로드되고 있는지 또는 관리자 권한이 있는 사용자 계정에서 실행하는 악성 소프트웨어에 의해 시스템 파일이 수정되었는지 여부를 검색합니다. x64 기반 버전의 Windows에서는 커널 모드 드라이버를 디지털 서명해야 합니다.

참고

Device Guard 정책 활성화와는 별개로 Windows 드라이버는 Microsoft에서 서명해야 하며, 특히 WHQL(Windows 하드웨어 품질 랩) 포털에서 서명해야 합니다. 또한 2015년 10월부터 WHQL 포털은 유효한 확장 유효성 검사("EV") 코드 서명 인증서가 있는 커널 및 사용자 모드 드라이버 제출을 포함하여 드라이버 제출만 수락합니다.

Device Guard를 사용하면 조직은 이제 Windows Enterprise를 실행하는 x64 시스템에서 사용할 고유한 코드 무결성 정책을 정의할 수 있습니다. 조직은 실행할 신뢰할 수 있는 항목을 결정하는 정책을 구성할 수 있습니다. 여기에는 드라이버 및 시스템 파일, 기존 데스크톱 애플리케이션 및 스크립트가 포함됩니다. 그러면 시스템이 잠겨 조직에서 신뢰하는 애플리케이션만 실행합니다.

Device Guard는 원치 않는 코드 및 애플리케이션의 실행을 방지하는 Windows Enterprise의 기본 제공 기능입니다. Device Guard는 다음 두 가지 규칙 작업(허용 및 거부)을 사용하여 구성할 수 있습니다.

허용 은 애플리케이션의 실행을 허용된 코드 또는 신뢰할 수 있는 게시자 목록으로 제한하고 다른 모든 항목을 차단합니다.
거부 는 특정 애플리케이션의 실행을 차단하여 신뢰할 수 있는 게시자 허용 방법을 완료합니다.

이 글을 쓰는 시점에 Microsoft의 최신 연구에 따르면 맬웨어의 90% 이상이 완전히 서명되지 않았습니다. 따라서 기본 Device Guard 정책을 구현하면 맬웨어를 간단하고 효과적으로 차단할 수 있습니다. 실제로 Device Guard는 더 나아가 서명된 맬웨어를 차단하는 데 도움이 될 수 있습니다.

Device Guard는 실제로 효과적이도록 계획하고 구성해야 합니다. 사용하도록 설정되거나 사용하지 않도록 설정된 보호만이 아닙니다. Device Guard는 하드웨어 보안 기능과 소프트웨어 보안 기능의 조합으로, 함께 구성할 때 컴퓨터를 잠그면 가능한 가장 안전하고 저항력이 뛰어난 시스템을 보장할 수 있습니다.

Windows에는 Device Guard 솔루션을 구성하는 세 가지 부분이 있습니다.

첫 번째 부분은 이전 버전의 Windows와 함께 도입된 하드웨어 보안 기능 의 기본 집합입니다. 보안 부팅과 함께 최신 펌웨어를 사용하는 하드웨어 암호화 작업 및 UEFI용 TPM을 사용하면 시스템이 시작될 때 디바이스가 실행되는 항목을 제어할 수 있습니다.
하드웨어 보안 기능 후에는 코드 무결성 엔진이 있습니다. Windows에서 코드 무결성은 이제 완전히 구성할 수 있으며 이제 가상화 기반 보안으로 보호되는 메모리의 일부인 격리된 사용자 모드에 상주합니다.
Device Guard의 마지막 부분은 관리 효율성입니다. 코드 무결성 구성은 특정 그룹 정책 개체, PowerShell cmdlet 및 MDM CSP(구성 서비스 공급자)를 통해 노출됩니다.

엔터프라이즈에서 Device Guard를 배포하는 방법에 대한 자세한 내용은 Device Guard 배포 가이드를 참조하세요.

Device Guard 시나리오

앞에서 설명한 대로 Device Guard는 시스템을 잠그는 강력한 방법입니다. Device Guard는 광범위하게 사용되는 것이 아니며 항상 적용 가능한 것은 아니지만 몇 가지 고금리 시나리오가 있습니다.

Device Guard는 금전 등록기, 키오스크 머신, SAW(Secure Admin Workstations) 또는 잘 관리되는 데스크톱과 같은 고정 워크로드 시스템에 유용하고 적용할 수 있습니다. Device Guard는 실행될 것으로 예상되고 너무 자주 변경되지 않는 잘 정의된 소프트웨어가 있는 시스템과 매우 관련이 있습니다. 또한 실행해야 하는 항목이 알려지고 애플리케이션 집합이 매일 변경되지 않는 한, SAW를 넘어 정보 근로자(W)를 보호하는 데 도움이 될 수 있습니다.

SAW는 다른 보안 위험 중 맬웨어, 피싱 공격, 가짜 웹 사이트 및 PtH 공격으로 인한 손상 위험을 크게 줄이는 데 도움이 되도록 빌드된 컴퓨터입니다. SAW는 이러한 공격에 대한 "실버 글머리 기호" 보안 솔루션으로 간주될 수 없지만 이러한 유형의 클라이언트는 보안에 대한 계층화된 심층 방어 접근 방식의 일부로 유용합니다.

고부가가치 자산을 보호하기 위해 SAW를 사용하여 해당 자산에 안전하게 연결합니다.

마찬가지로 Microsoft Configuration Manager, Intune 또는 타사 디바이스 관리와 같은 배포 도구를 사용하여 애플리케이션을 설치하는 회사 완전 관리형 워크스테이션에서는 Device Guard가 적용됩니다. 이러한 유형의 시나리오에서 조직은 일반 사용자가 실행 중인 소프트웨어에 대해 잘 알 수 있습니다.

일반적으로 사용자가 직접 소프트웨어를 설치할 수 있는 가볍게 관리되는 회사 워크스테이션에서 Device Guard를 사용하는 것은 어려울 수 있습니다. 조직에서 뛰어난 유연성을 제공하는 경우 적용 모드에서 Device Guard를 실행하기가 어렵습니다. 그럼에도 불구하고 Device Guard는 감사 모드에서 실행할 수 있으며, 이 경우 이벤트 로그에는 Device Guard 정책을 위반한 모든 이진 파일에 대한 레코드가 포함됩니다. Device Guard가 감사 모드에서 사용되는 경우 조직은 사용자가 설치하고 실행하는 드라이버 및 애플리케이션에 대한 풍부한 데이터를 가져올 수 있습니다.

Device Guard에 포함된 보호를 활용하려면 먼저 Microsoft에서 제공하는 도구를 사용하여 코드 무결성 정책을 만들어야 하지만 그룹 정책과 같은 일반적인 관리 도구를 사용하여 정책을 배포할 수 있습니다. 코드 무결성 정책은 Windows 스크립트 호스트에 대한 제한 사항과 함께 Windows의 사용자 및 커널 모드 모두에 대한 구성 설정을 포함하는 이진 인코딩된 XML 문서입니다. Device Guard 코드 무결성 정책은 디바이스에서 실행할 수 있는 코드를 제한합니다.

참고

이 정책을 변경하거나 제거하는 관리자에 대한 추가 보호를 추가하는 Windows에서 Device Guard 정책에 서명할 수 있습니다.

서명된 Device Guard 정책은 Device Guard를 무찌르려는 악의적인 로컬 관리자에 대해 더 강력한 보호를 제공합니다.

정책이 서명되면 정책의 GUID는 변조 보호를 제공하는 UEFI OS 이전 보안 변수에 저장됩니다. 나중에 Device Guard 정책을 업데이트하는 유일한 방법은 동일한 서명자가 서명하거나 Device Guard 정책의 일부로 지정된 서명자에서 UpdateSigner 섹션에 새 버전의 정책을 제공하는 것입니다.

애플리케이션 서명의 중요성

Device Guard가 있는 컴퓨터에서 Microsoft는 서명되지 않은 앱을 Windows에서만 실행할 수 있는 서명되고 신뢰할 수 있는 코드만 허용되는 세계로 제한 없이 실행할 수 있는 환경에서 이동할 것을 제안합니다.

Windows를 통해 조직은 Microsoft Store 인프라를 통해 조직 구성원이 LOB(기간 업무) 앱을 사용할 수 있도록 합니다. 특히 LOB 앱은 퍼블릭 Microsoft Store 내의 개인 스토어에서 사용할 수 있습니다. Microsoft Store는 유니버설 Windows 앱과 클래식 Windows 앱에 서명하고 배포합니다. Microsoft Store에서 다운로드한 모든 앱이 서명됩니다.

오늘날 조직에서는 많은 LOB 애플리케이션이 서명되지 않았습니다. 코드 서명은 코드 서명 전문 지식 부족과 같은 다양한 이유로 해결하기 어려운 문제로 자주 간주됩니다. 코드 서명이 모범 사례인 경우에도 많은 내부 애플리케이션이 서명되지 않습니다.

Windows에는 IT 전문가가 이미 패키지된 애플리케이션을 가져와서 프로세스를 통해 실행하여 기존 애플리케이션과 함께 배포할 수 있는 더 많은 서명을 만들 수 있는 도구가 포함되어 있습니다.

맬웨어 방지 및 디바이스 관리 솔루션이 여전히 필요한 이유는 무엇인가요?

허용 목록 메커니즘은 신뢰할 수 있는 애플리케이션만 실행할 수 있도록 하는 데 효율적이지만 알려진 취약성을 악용하도록 설계된 악의적인 콘텐츠로 신뢰할 수 있지만 취약한 애플리케이션의 손상을 방지할 수는 없습니다. Device Guard는 취약성을 악용하여 실행되는 사용자 모드 악성 코드로부터 보호하지 않습니다.

취약성은 공격자가 디바이스의 무결성, 가용성 또는 기밀성을 손상시킬 수 있는 소프트웨어의 약점입니다. 최악의 취약성 중 일부는 공격자가 사용자의 지식 없이 악성 코드를 실행하도록 하여 손상된 디바이스를 악용할 수 있도록 합니다.

공격자가 웹 브라우저(및 플러그 인), Java 가상 머신, PDF 판독기 또는 문서 편집기와 같은 사용자 모드 소프트웨어에서 알려진 취약성을 악용하기 위해 특별히 제작된 콘텐츠를 배포하는 것을 보는 것이 일반적입니다. 현재 검색된 취약성의 90%는 운영 체제 및 이를 호스트하는 커널 모드 드라이버에 비해 사용자 모드 애플리케이션에 영향을 줍니다.

이러한 위협에 대처하기 위해 패치는 맬웨어 방지 소프트웨어가 보완적인 방어 계층을 형성하는 가장 효과적인 단일 제어입니다.

대부분의 애플리케이션 소프트웨어에는 자체 업데이트를 위한 기능이 없으므로 소프트웨어 공급업체가 취약성을 수정하는 업데이트를 게시하더라도 사용자는 업데이트를 사용할 수 있는지 또는 어떻게 얻을 수 있는지 알지 못할 수 있으므로 공격에 취약합니다. 조직은 여전히 디바이스를 관리하고 취약성을 패치해야 합니다.

MDM 솔루션은 경량 디바이스 관리 기술로 널리 보급되고 있습니다. Windows는 MDM에 사용할 수 있게 된 관리 기능을 확장합니다. Microsoft가 Windows에 추가한 주요 기능 중 하나는 MDM이 관리 및 등록된 디바이스에서 강력한 디바이스 상태 설명을 획득하는 기능입니다.

장치 상태 증명

디바이스 상태 증명은 TPM을 사용하여 디바이스를 부팅하는 데 사용되는 소프트웨어 체인의 암호화된 강력하고 확인 가능한 측정값을 제공합니다.

Windows 기반 디바이스의 경우 Microsoft는 MDM 소프트웨어가 Windows Health 증명 서비스라는 원격 증명 서비스에 액세스할 수 있도록 하는 새로운 공용 API를 도입했습니다. 상태 증명 결과는 다른 요소 외에도 디바이스가 정상인지 여부에 따라 네트워크, 앱 또는 서비스에 대한 액세스를 허용하거나 거부하는 데 사용할 수 있습니다.

디바이스 상태 증명에 대한 자세한 내용은 비정상 Windows 기반 디바이스 검색 섹션을 참조하세요.

Windows 버전 및 라이선싱 요구 사항

다음 표에는 디바이스 상태 증명 서비스를 지원하는 Windows 버전이 나와 있습니다.

Windows Pro	Windows Enterprise	Windows Pro Education/SE	Windows Education
예	예	예	예

디바이스 상태 증명 서비스 라이선스 자격은 다음 라이선스에 의해 부여됩니다.

Windows Pro/Pro Education/SE	Windows Enterprise E3	Windows Enterprise E5	Windows Education A3	Windows Education A5
예	예	예	예	예

Windows 라이선싱에 대한 자세한 내용은 Windows 라이선싱 개요를 참조하세요.

하드웨어 요구 사항

다음 표에서는 가상화 기반 보안 서비스와 상태 증명 기능 모두에 대한 하드웨어 요구 사항을 자세히 설명합니다. 자세한 내용은 최소 하드웨어 요구 사항을 참조하세요.

하드웨어	동기
보안 부팅을 사용하도록 설정된 UEFI 2.3.1 이상 펌웨어	UEFI 보안 부팅을 지원하는 데 필요합니다. UEFI 보안 부팅은 디바이스가 권한 있는 코드만 부팅하도록 합니다. 또한 "System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby" 하위 섹션에서 Windows용 시스템용 하드웨어 호환성 사양의 요구 사항에 따라 부팅 무결성(플랫폼 보안 부팅)을 지원해야 합니다.
Intel VT-x, AMD-V 및 SLAT와 같은 가상화 확장을 사용하도록 설정해야 합니다.	가상화 기반 보안을 지원하는 데 필요합니다. 메모: Device Guard는 가상화 기반 보안을 사용하지 않고도 사용하도록 설정할 수 있습니다.
X64 프로세서	Windows 하이퍼바이저를 사용하는 가상화 기반 보안을 지원하는 데 필요합니다. Hyper-V는 x64 프로세서에서만 지원되며 x86에서는 지원되지 않습니다. DMA(직접 메모리 액세스) 보호를 사용하여 추가 메모리 보호를 제공할 수 있지만 프로세서에 DMA 보호 기술을 포함해야 합니다.
IOMMU(예: Intel VT-d) AMD-Vi	Windows에서 IOMMU를 지원하면 DMA 공격에 대한 시스템 복원력이 향상됩니다.
TPM(신뢰할 수 있는 플랫폼 모듈)	상태 증명을 지원하는 데 필요하고 가상화 기반 보안을 위한 다른 키 보호에 필요합니다. TPM 2.0이 지원됩니다. TPM 1.2에 대한 지원은 Windows 10 버전 1607(RS1)부터 추가되었습니다.

이 섹션에서는 Windows의 몇 가지 밀접하게 관련된 컨트롤에 대한 정보를 제공했습니다. 다층 방어 및 심층 접근 방식은 부팅 시퀀스 중에 하위 수준 맬웨어를 근절하는 데 도움이 됩니다. 가상화 기반 보안은 새로운 보안 경계를 추가하는 기본 운영 체제 아키텍처 변경입니다. Device Guard와 Credential Guard는 각각 신뢰할 수 없는 코드를 차단하고 회사 도메인 자격 증명을 도난 및 재사용으로부터 보호하는 데 도움이 될 수 있습니다. 이 섹션에서는 디바이스 관리 및 취약성 패치의 중요성에 대해서도 간략하게 설명했습니다. 이러한 모든 기술은 공격자가 디바이스를 손상시킬 위험을 제한하면서 디바이스를 강화하고 잠그는 데 사용할 수 있습니다.

비정상 Windows 기반 디바이스 검색

현재 많은 조직에서는 운영 체제가 올바른 상태이고 올바르게 구성되었으며 보안 보호가 사용하도록 설정되어 있음을 보여 주는 다양한 검사를 통과한 후에만 디바이스가 회사 정책을 준수하는 것으로 간주합니다. 아쉽게도 오늘날의 시스템에서는 맬웨어가 시스템 상태에 대한 소프트웨어 문을 스푸핑할 수 있기 때문에 이러한 형태의 보고는 완전히 신뢰할 수 없습니다. 루트킷 또는 이와 유사한 하위 수준 악용은 기존 규정 준수 도구에 잘못된 정상 상태를 보고할 수 있습니다.

루트킷의 가장 큰 과제는 클라이언트에서 검색할 수 없다는 것입니다. 맬웨어 방지 전에 시작하고 시스템 수준 권한을 가지므로 시스템 리소스에 계속 액세스하면서 완전히 위장할 수 있습니다. 그 결과, 루트킷에 감염된 기존 컴퓨터는 맬웨어 방지가 실행되더라도 정상으로 보입니다.

앞에서 설명한 것처럼 Windows의 상태 증명 기능은 TPM 하드웨어 구성 요소를 사용하여 펌웨어, Windows 커널 및 초기 부팅 드라이버를 포함한 모든 부팅 관련 구성 요소의 측정값을 안전하게 기록합니다. 상태 증명은 TPM의 하드웨어 기반 보안 기능을 사용하므로 모든 부팅 측정 구성 요소의 로그가 맬웨어의 범위를 벗어나는 상태로 유지됩니다.

디바이스가 신뢰할 수 있는 부팅 상태를 증명한 후 나중에 규정 준수 검사를 스푸핑할 수 있는 하위 수준 맬웨어를 실행하고 있지 않음을 증명할 수 있습니다. TPM 기반 상태 증명은 고부가가치 데이터를 포함하는 자산에 대한 신뢰할 수 있는 신뢰 앵커를 제공합니다.

디바이스 상태의 개념은 무엇인가요?

디바이스 상태의 개념을 이해하려면 IT 전문가가 맬웨어 위반을 방지하기 위해 취한 기존 조치를 알고 있어야 합니다. 맬웨어 제어 기술은 설치 및 배포 방지에 중점을 두고 있습니다.

그러나 맬웨어 방지 또는 패치 솔루션과 같은 기존 맬웨어 방지 기술을 사용하면 IT 전문가에게 조직의 리소스에 액세스하는 디바이스의 규정 준수를 모니터링하고 제어할 수 있는 새로운 문제 집합이 제공됩니다.

디바이스 준수 정의는 조직의 설치된 맬웨어 방지, 디바이스 구성 설정, 패치 관리 기준 및 기타 보안 요구 사항에 따라 달라집니다. 그러나 디바이스의 상태는 전체 디바이스 준수 정책의 일부입니다.

디바이스의 상태는 이진이 아니며 조직의 보안 구현에 따라 달라집니다. 상태 증명 서비스는 신뢰할 수 있는 하드웨어 TPM을 사용하여 디바이스 부팅 중에 보안 기능을 사용하도록 설정하는 MDM에 정보를 다시 제공합니다.

그러나 상태 증명은 정보만 제공하므로 결정을 내리고 적용하기 위해 MDM 솔루션이 필요합니다.

원격 디바이스 상태 증명

Windows에서 상태 증명은 부팅 프로세스 중에 생성된 측정된 부팅 데이터가 Microsoft에서 운영하는 원격 디바이스 상태 증명 서비스로 전송되는 기능을 나타냅니다.

이 방법은 Windows 기반 디바이스에서 보안 방어가 중단된 시기를 감지하는 데 사용할 수 있는 가장 안전한 방법입니다. 부팅 프로세스 중에 TCG 로그 및 PCR의 값이 원격 Microsoft 클라우드 서비스로 전송됩니다. 그런 다음 상태 증명 서비스에서 로그를 확인하여 디바이스에서 발생한 변경 내용을 확인합니다.

MDM과 같은 신뢰 당사자는 원격 상태 증명 서비스에서 생성된 보고서를 검사할 수 있습니다.

참고

Windows의 상태 증명 기능을 사용하려면 디바이스에 불연속 또는 펌웨어 TPM이 장착되어 있어야 합니다. 특정 버전의 Windows에는 제한이 없습니다.

Windows는 애플리케이션이 상태 증명 토큰을 요청할 수 있도록 기본 CSP(상태 증명 구성 서비스 공급자)에 애플리케이션 액세스를 허용하여 상태 증명 시나리오를 지원합니다. 부팅 시퀀스의 측정은 맬웨어 방지 또는 MDM 에이전트를 통해 언제든지 로컬에서 확인할 수 있습니다.

MDM과 결합된 원격 디바이스 상태 증명은 시스템에서 실행되는 소프트웨어를 신뢰할 필요 없이 현재 보안 상태를 보고하고 변경 내용을 검색하는 하드웨어 기반 방법을 제공합니다.

디바이스에서 악성 코드가 실행되는 경우 원격 서버를 사용해야 합니다. 루트킷이 디바이스에 있는 경우 맬웨어 방지는 더 이상 신뢰할 수 없으며 시작 시퀀스 초기에 실행되는 악성 코드에 의해 해당 동작을 하이재킹할 수 있습니다. 이러한 이유로 보안 부팅 및 Device Guard를 사용하여 부팅 시퀀스 중에 로드되는 코드를 제어하는 것이 중요합니다.

맬웨어 방지 소프트웨어는 부팅 시퀀스에 루트킷과 같은 맬웨어의 징후가 포함되어 있는지 여부를 확인하기 위해 검색할 수 있습니다. 또한 TCG 로그와 PCR을 원격 상태 증명 서버로 보내 측정 구성 요소와 확인 구성 요소 간에 분리를 제공할 수도 있습니다.

상태 증명은 부팅 프로세스 중에 다양한 TPM PCR(플랫폼 구성 레지스터) 및 TCG 로그의 측정값을 기록합니다.

그림 6.

TPM이 장착된 디바이스를 시작하면 다양한 구성 요소의 측정이 수행됩니다. 이러한 구성 요소에는 펌웨어, UEFI 드라이버, CPU 마이크로코드 및 부팅 시작 유형이 있는 모든 Windows 드라이버가 포함됩니다. 원시 측정값은 TPM PCR 레지스터에 저장되며 모든 이벤트(실행 경로, 기관 인증 등)의 세부 정보는 TCG 로그에서 사용할 수 있습니다.

그림 7.

상태 증명 프로세스는 다음과 같이 작동합니다.

하드웨어 부팅 구성 요소가 측정됩니다.
운영 체제 부팅 구성 요소를 측정합니다.
Device Guard를 사용하도록 설정하면 현재 Device Guard 정책이 측정됩니다.
Windows 커널을 측정합니다.
바이러스 백신 소프트웨어는 첫 번째 커널 모드 드라이버로 시작됩니다.
부팅 시작 드라이버가 측정됩니다.
MDM 에이전트를 통한 MDM 서버는 상태 증명 CSP를 사용하여 상태 검사 명령을 실행합니다.
부팅 측정은 상태 증명 서비스에서 유효성을 검사합니다.

참고

기본적으로 마지막 100개의 시스템 부팅 로그와 연결된 모든 다시 시작 로그는 %SystemRoot%\logs\measuredboot 폴더에 보관됩니다. 보존된 로그 수는 레지스트리 REG_DWORD 값 PlatformLogRetention 을 HKLM\SYSTEM\CurrentControlSet\Services\TPM 키로 설정할 수 있습니다. 값 0 은 로그 보관을 해제하고 0xffffffff 값은 모든 로그를 유지합니다.

다음 프로세스에서는 상태 부팅 측정을 상태 증명 서비스로 보내는 방법을 설명합니다.

클라이언트(TPM이 있는 Windows 기반 디바이스)는 원격 디바이스 상태 증명 서비스를 사용하여 요청을 시작합니다. 상태 증명 서버는 Microsoft 클라우드 서비스여야 하므로 URI는 클라이언트에서 이미 미리 프로비전되어 있습니다.
그런 다음 클라이언트는 TCG 로그, AIK 서명된 데이터(PCR 값, 부팅 카운터) 및 AIK 인증서 정보를 보냅니다.
원격 디바이스 히스 증명 서비스는 다음을 수행합니다.
1. AIK 인증서가 알려진 신뢰할 수 있는 CA에서 발급되고 인증서가 유효하고 해지되지 않는지 확인합니다.
2. PCR 따옴표의 서명이 올바르고 TCG 로그 값과 일치하는지 확인합니다.
3. TCG 로그의 속성을 구문 분석합니다.
4. 상태 정보, AIK 정보 및 부팅 카운터 정보가 포함된 디바이스 상태 토큰을 발급합니다. 상태 토큰에는 유효한 발급 시간도 포함됩니다. 디바이스 상태 토큰은 암호화되고 서명됩니다. 즉, 정보가 보호되고 상태 증명 서비스를 발급하는 경우에만 액세스할 수 있습니다.
클라이언트는 로컬 저장소에 상태 암호화 Blob을 저장합니다. 디바이스 상태 토큰에는 디바이스 상태, 디바이스 ID(Windows AIK) 및 부팅 카운터가 포함됩니다.

그림 8.

디바이스 상태 증명 구성 요소

디바이스 상태 증명 솔루션에는 TPM, 상태 증명 CSP 및 Windows 상태 증명 서비스인 다양한 구성 요소가 포함됩니다. 이러한 구성 요소는 이 섹션에서 설명합니다.

신뢰할 수 있는 플랫폼 모듈

이 섹션에서는 PCR(시스템 구성 데이터 포함), EK(인증 키) (TPM의 ID 카드 역할을 하는), SRK(키 보호) 및 AIK(플랫폼 상태를 보고할 수 있음)를 상태 증명 보고에 사용하는 방법을 설명합니다.

간소화된 방식으로 TPM은 리소스가 제한된 수동 구성 요소입니다. 난수, RSA 키를 계산하고, 짧은 데이터의 암호를 해독하고, 디바이스를 부팅할 때 가져온 해시를 저장할 수 있습니다.

TPM은 단일 구성 요소에 통합됩니다.

RSA 2048비트 키 생성기
난수 생성기
EK, SRK 및 AIK 키를 저장하기 위한 비휘발성 메모리
암호화, 암호 해독 및 서명할 암호화 엔진
PCR 및 RSA 키를 저장하기 위한 휘발성 메모리

인증 키

TPM에는 인증 키라는 고유한 암호화 키가 포함되어 있습니다. TPM 인증 키는 한 쌍의 비대칭 키(RSA 크기 2048비트)입니다.

인증 키 공개 키는 소유자 암호의 정의 해시를 포함하는 TPM을 소유하는 경우와 같이 안전하게 중요한 매개 변수를 보내는 데 사용됩니다. EK 프라이빗 키는 AIK와 같은 보조 키를 만들 때 사용됩니다.

인증 키는 TPM의 ID 카드 역할을 합니다. 자세한 내용은 TPM 인증 키 이해를 참조하세요.

인증 키에는 종종 하나 또는 두 개의 디지털 인증서가 함께 제공됩니다.

하나의 인증서는 TPM 제조업체에서 생성되며 인증 인증서라고 합니다. 인증 인증서는 TPM(예: 특정 칩 제조업체에서 제조한 실제 TPM)의 신뢰성을 로컬 프로세스, 애플리케이션 또는 클라우드 서비스에 증명하는 데 사용됩니다. 인증 인증서는 제조 중에 생성되거나 온라인 서비스와 통신하여 TPM이 처음 초기화됩니다.
다른 인증서는 플랫폼 작성기에서 생성되며 특정 TPM이 특정 디바이스와 통합되었음을 나타내는 플랫폼 인증서 라고 합니다. Intel 또는 Qualcomm에서 생성된 펌웨어 기반 TPM을 사용하는 특정 디바이스의 경우 Windows OOBE 중에 TPM이 초기화될 때 인증 인증서가 만들어집니다.

참고

보안 부팅은 Windows 커널이 로드될 때까지 플랫폼을 보호합니다. 그런 다음 신뢰할 수 있는 부팅, Hyper-V 코드 무결성 및 ELAM과 같은 보호가 인계됩니다. Intel TPM 또는 Qualcomm TPM을 사용하는 디바이스는 칩을 만든 다음 서명된 인증서를 TPM 스토리지에 저장하는 제조업체로부터 온라인으로 서명된 인증서를 가져옵니다. 작업이 성공하려면 클라이언트 디바이스에서 인터넷 액세스를 필터링하는 경우 다음 URL에 권한을 부여해야 합니다.

Intel 펌웨어 TPM의 경우: https://ekop.intel.com/ekcertservice
Qualcomm 펌웨어 TPM의 경우: https://ekcert.spserv.microsoft.com/

증명 ID 키

인증 인증서는 각 디바이스에 대해 고유하며 변경되지 않으므로 이론적으로 특정 디바이스를 추적할 수 있기 때문에 인증 인증서를 사용하는 경우 개인 정보 보호 문제가 발생할 수 있습니다. 이 개인 정보 보호 문제를 방지하기 위해 Windows는 보증 인증서를 기반으로 파생된 증명 앵커를 발급합니다. 인증 키로 증명될 수 있는 이 중간 키는 AIK(증명 ID 키)이며 해당 인증서를 AIK 인증서라고 합니다. 이 AIK 인증서는 Microsoft 클라우드 서비스에서 발급합니다.

참고

디바이스가 TPM 증명 함수를 사용하여 상태를 보고하려면 먼저 Microsoft Cloud CA 서비스와 같은 타사 서비스와 함께 AIK 인증서를 프로비전해야 합니다. 프로비전된 후 AIK 프라이빗 키를 사용하여 플랫폼 구성을 보고할 수 있습니다. Windows는 AIK를 사용하여 각 부팅에서 플랫폼 로그 상태(및 단조 카운터 값)를 통해 서명을 만듭니다.

AIK는 개인 정보 보호를 위해 TPM의 ID로 EK를 대체하는 데 사용되는 비대칭(퍼블릭/프라이빗) 키 쌍입니다. AIK의 프라이빗 부분은 TPM 외부에서 공개되지 않거나 사용되지 않으며 제한된 작업 집합에 대해서만 TPM 내에서만 사용할 수 있습니다. 또한 서명에만 사용할 수 있으며 제한된 TPM 정의 작업에만 사용할 수 있습니다.

Windows는 2048비트 RSA 서명 키인 TPM(사용 가능한 경우)으로 보호되는 AIK를 만듭니다. Microsoft는 Microsoft Cloud CA라는 클라우드 서비스를 호스팅하여 실제 TPM과 통신하고 TPM이 제시된 AIK를 소유한다는 암호화를 설정합니다. Microsoft Cloud CA 서비스에서 이러한 사실을 설정한 후에는 Windows 기반 디바이스에 AIK 인증서를 발급합니다.

Windows 10으로 업그레이드할 대부분의 기존 디바이스에는 TPM이 없거나 TPM에 인증 인증서가 포함되지 않습니다. 이러한 디바이스를 수용하기 위해 Windows 10에서는 인증 인증서가 없는 AIK 인증서를 발급할 수 있습니다. 이러한 AIK 인증서는 Microsoft 클라우드 CA에서 발급되지 않습니다. 이러한 인증서는 제조 중에 디바이스에 소실되는 보증 인증서만큼 신뢰할 수 없지만 TPM이 없는 비즈니스용 Windows Hello와 같은 고급 시나리오에 대한 호환성을 제공합니다.

발급된 AIK 인증서에서 인증 프로세스 중에 인증 인증서가 사용되었음을 증명하기 위해 특수 OID가 추가됩니다. 이 정보는 신뢰 당사자가 인증 인증서 없이 AIK 인증서를 사용하여 증명된 디바이스를 거부할지 아니면 수락할지를 결정하는 데 사용할 수 있습니다. 또 다른 시나리오는 보증 인증서로 지원되지 않는 AIK 인증서로 증명된 디바이스에서 고가치 자산에 대한 액세스를 허용하지 않는 것입니다.

스토리지 루트 키

SRK(스토리지 루트 키)는 최소 길이가 2048비트인 RSA(비대칭 키 쌍)이기도 합니다. SRK는 주요 역할을 하며 TPM 키를 보호하는 데 사용되므로 TPM 없이는 이러한 키를 사용할 수 없습니다. SRK 키는 TPM의 소유권을 가져올 때 만들어집니다.

플랫폼 구성 레지스터

TPM에는 부팅된 시스템의 소프트웨어 및 상태에 대한 암호화 표현을 제공하도록 설계된 레지스터 집합이 포함되어 있습니다. 이러한 레지스터를 PCR(플랫폼 구성 레지스터)이라고 합니다.

부팅 시퀀스의 측정은 PCR 및 TCG 로그를 기반으로 합니다. 정적 신뢰 루트를 설정하려면 디바이스가 시작될 때 디바이스가 실행하기 전에 펌웨어 코드를 측정할 수 있어야 합니다. 이 경우 CRTM(핵심 측정 신뢰 루트)은 부팅에서 실행되고, 펌웨어의 해시를 계산한 다음, PCR[0] 레지스터를 확장하여 저장하고 실행을 펌웨어로 전송합니다.

PCR은 플랫폼이 부팅될 때 0으로 설정되며, 부팅 체인의 구성 요소를 측정하고 PCR에 측정값을 기록하기 위해 플랫폼을 부팅하는 펌웨어의 작업입니다. 일반적으로 부팅 구성 요소는 실행할 다음 구성 요소의 해시를 가져와서 PCR에 측정값을 기록합니다. 측정 체인을 시작하는 초기 구성 요소는 암시적으로 신뢰할 수 있습니다. 이 구성 요소는 CRTM입니다. 플랫폼 제조업체는 CRTM에 대한 보안 업데이트 프로세스를 갖거나 업데이트를 허용하지 않는 것이 필요합니다. PCR은 측정된 구성 요소의 누적 해시를 기록합니다.

PCR 자체의 값은 해석하기 어렵지만(해시 값일 뿐) 플랫폼은 일반적으로 측정된 내용에 대한 세부 정보가 포함된 로그를 유지하고 PCR은 로그가 변조되지 않았는지 확인합니다. 로그를 TCG 로그라고 합니다. 레지스터 PCR이 확장 될 때마다 항목이 TCG 로그에 추가됩니다. 따라서 부팅 프로세스 전체에서 실행 코드 및 구성 데이터의 추적이 TCG 로그에 만들어집니다.

TPM 프로비저닝

Windows 기반 디바이스의 TPM을 사용할 수 있도록 하려면 먼저 프로비전해야 합니다. 프로비전 프로세스는 TPM 버전에 따라 다르지만, 성공하면 TPM을 사용할 수 있고 TPM에 대한 소유자 권한 부여 데이터(ownerAuth)가 레지스트리에 로컬로 저장됩니다.

TPM이 프로비전되면 Windows는 먼저 HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement 위치에서 레지스트리를 확인하여 EK 및 로컬로 저장된 ownerAuth 값을 확인하려고 시도합니다.

프로비저닝 프로세스 중에 디바이스를 다시 시작해야 할 수 있습니다.

Get-TpmEndorsementKeyInfo PowerShell cmdlet을 관리 권한과 함께 사용하여 TPM의 인증 키 및 인증서에 대한 정보를 가져올 수 있습니다.

TPM 소유권을 알 수 없지만 EK가 있는 경우 클라이언트 라이브러리는 TPM을 프로비전하고 정책에서 SRK 공용 부분을 HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub 위치에 저장할 수 있도록 허용하는 경우 결과 ownerAuth 값을 레지스트리에 저장합니다.

프로비저닝 프로세스의 일부로 Windows는 TPM을 사용하여 AIK를 만듭니다. 이 작업을 수행하면 결과 AIK 공용 부분이 레지스트리의 HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub 위치에 저장됩니다.

참고

AIK 인증서를 프로비전하고 인터넷 액세스를 필터링하려면 다음 와일드카드 URL에 권한을 부여해야 합니다. https://\*.microsoftaik.azure.net

Windows 상태 증명 CSP

Windows에는 상태 증명 기능과 상호 작용하기 위한 CSP(구성 서비스 공급자)가 포함되어 있습니다. CSP는 Windows MDM 클라이언트에 연결하고 MDM 서버가 설정을 구성하고 Windows 기반 디바이스를 관리하는 방법에 대해 게시된 프로토콜을 제공하는 구성 요소입니다. 관리 프로토콜은 "get", "set", "delete" 등과 같은 URI에서 수행할 함수를 사용하여 URI로 지정할 수 있는 트리 구조로 표시됩니다.

다음 목록은 Windows 상태 증명 CSP에서 수행하는 함수의 목록입니다.

디바이스의 상태를 확인하는 데 사용되는 데이터를 수집합니다.
상태 증명 서비스에 데이터 전달
상태 증명 서비스에서 수신하는 상태 증명 인증서를 프로비전합니다.
요청 시 상태 증명 인증서(상태 증명 서비스에서 수신됨) 및 관련 런타임 정보를 MDM 서버에 전달하여 확인합니다.

상태 증명 세션 중에 상태 증명 CSP는 보안 통신 채널을 사용하여 부팅 중에 측정된 TCG 로그 및 PCR 값을 상태 증명 서비스에 전달합니다.

MDM 서버가 디바이스가 상태 증명 서비스에 증명되었는지 확인하면 디바이스가 부팅된 방법에 대한 일련의 문과 클레임이 제공되며, 디바이스가 상태를 증명한 시간과 MDM 서버가 유효성을 검사한 시간 사이에 디바이스가 다시 부팅되지 않았음을 보장합니다.

Windows 상태 증명 서비스

Windows 상태 증명 서비스의 역할은 기본적으로 상태 데이터 집합(TCG 로그 및 PCR 값)을 평가하고, 일련의 검색(사용 가능한 상태 데이터 기반)을 만들고, 암호화된 상태 Blob을 생성하거나 MDM 서버에 대한 보고서를 생성하는 것입니다.

참고

디바이스 서버와 MDM 서버 모두 HTTPS(포트 443)에서 TCP 프로토콜을 사용하여 has.spserv.microsoft.com 액세스할 수 있어야 합니다.

TPM 증명 및 연결된 로그가 유효한지 확인하려면 다음 몇 단계를 수행합니다.

먼저 서버는 신뢰할 수 있는 AIK에서 보고서가 서명되어 있는지 확인해야 합니다. 이 확인은 AIK의 공용 부분이 자산 데이터베이스에 나열되어 있는지 또는 인증서가 확인되었는지 확인하여 수행할 수 있습니다.
키를 확인한 후 서명된 증명(따옴표 구조)을 확인하여 PCR 값에 대한 유효한 서명인지 확인해야 합니다.
다음으로 로그가 보고된 PCR 값과 일치하는지 확인해야 합니다.
마지막으로 MDM 솔루션에서 로그 자체를 검사하여 알려진 보안 구성 또는 유효한 보안 구성을 나타내는지 확인해야 합니다. 예를 들어 간단한 검사는 측정된 초기 OS 구성 요소가 양수로 알려져 있는지, ELAM 드라이버가 예상대로인지, ELAM 드라이버 정책 파일이 최신 상태인지 확인하는 것입니다. 이러한 모든 검사가 성공하면 나중에 클라이언트에 리소스에 대한 액세스 권한을 부여해야 하는지 여부를 결정하는 데 사용할 수 있는 증명 문을 실행할 수 있습니다.

상태 증명 서비스는 디바이스의 상태에 대한 다음 정보를 MDM 솔루션에 제공합니다.

보안 부팅 사용
부팅 및 커널 디버그 사용
BitLocker 사용
VSM 사용
서명되거나 서명되지 않은 Device Guard 코드 무결성 정책 측정
ELAM 로드됨
안전 모드 부팅, DEP 사용, 테스트 서명 사용
디바이스 TPM이 신뢰할 수 있는 인증 인증서로 프로비전되었습니다.

측정의 완전성은 상태 증명 CSP를 참조하세요.

다음 목록에는 Windows 기반 디바이스용 MDM에 다시 보고할 수 있는 몇 가지 주요 항목이 나와 있습니다.

PCR0 측정
보안 부팅 사용
보안 부팅 db가 예상과 일치합니다.
보안 부팅 dbx가 최신 상태입니다.
보안 부팅 정책 GUID가 예상과 일치합니다.
BitLocker 사용
가상화 기반 보안 사용
ELAM이 로드되었습니다.
코드 무결성 버전이 최신 상태입니다.
코드 무결성 정책 해시가 예상되는 일치 항목

MDM 및 상태 증명 서비스 사용

디바이스 상태를 관련성 있게 만들기 위해 MDM 솔루션은 디바이스 상태 보고서를 평가하고 조직의 디바이스 상태 요구 사항에 맞게 구성됩니다.

MDM 및 상태 증명 서비스를 사용하는 솔루션은 다음 세 가지 주요 부분으로 구성됩니다.

상태 증명이 사용하도록 설정된 디바이스입니다. 이 사용은 MDM 공급자 등록의 일부로 수행됩니다(상태 증명은 기본적으로 사용하지 않도록 설정됨).
이 서비스를 사용하도록 설정한 후 이후 부팅할 때마다 디바이스는 Microsoft에서 호스팅하는 상태 증명 서비스에 상태 측정값을 보내고 그 대가로 상태 증명 Blob을 받게 됩니다.
이 주기 후 언제든지 MDM 서버는 디바이스에서 상태 증명 Blob을 요청하고 상태 증명 서비스에 콘텐츠의 암호를 해독하고 증명되었는지 확인하도록 요청할 수 있습니다.

Windows 기반 디바이스, 상태 증명 서비스 및 MDM 간의 상호 작용은 다음과 같이 수행할 수 있습니다.

클라이언트는 MDM 서버로 세션을 시작합니다. MDM 서버의 URI는 요청을 시작하는 클라이언트 앱의 일부가 됩니다. 현재 MDM 서버는 적절한 CSP URI를 사용하여 상태 증명 데이터를 요청할 수 있습니다.
MDM 서버는 요청과 함께 nonce를 지정합니다.
그런 다음 클라이언트는 AIK 따옴표 붙은 nonce + 부팅 카운터 및 상태 Blob 정보를 보냅니다. 이 상태 Blob은 상태 증명 서비스만 암호를 해독할 수 있는 상태 증명 서비스 공개 키로 암호화됩니다.
MDM 서버:
1. nonce가 예상대로 표시되는지 확인합니다.
2. 따옴표 붙은 데이터, nonce 및 암호화된 상태 Blob을 상태 증명 서비스 서버에 전달합니다.
상태 증명 서비스:
1. 상태 Blob의 암호를 해독합니다.
2. 상태 Blob의 AIK를 사용하여 견적의 부팅 카운터가 올바른지 확인하고 상태 Blob의 값과 일치하는지 확인합니다.
3. nonce가 따옴표와 MDM에서 전달된 항목과 일치하는지 확인합니다.
4. 부팅 카운터와 nonce는 상태 Blob에서 AIK로 인용되므로 디바이스가 상태 Blob이 생성된 디바이스와 동일하다는 것을 증명합니다.
5. 상태 매개 변수, 새로 고침 등을 포함하여 MDM 서버로 데이터를 다시 보냅니다.

참고

MDM 서버(신뢰 당사자)는 견적 또는 부팅 카운터 유효성 검사 자체를 수행하지 않습니다. 따옴표 붙은 데이터와 상태 Blob(암호화됨)을 가져오고 유효성 검사를 위해 상태 증명 서비스로 데이터를 보냅니다. 이러한 방식으로 AIK는 MDM에 표시되지 않으며 이로 인해 개인 정보 보호 문제를 해결합니다.

디바이스 준수에 대한 요구 사항을 설정하는 것은 상태 및 규정 준수 요구 사항을 충족하지 않는 등록된 디바이스가 검색, 추적 및 MDM 솔루션에 의해 적용된 작업을 갖도록 하는 첫 번째 단계입니다.

리소스에 연결하려는 디바이스는 비정상 및 비규격 디바이스를 검색하고 보고할 수 있도록 상태를 평가해야 합니다. 완전히 효율적이려면 엔드 투 엔드 보안 솔루션은 고부가가치 자산에 대한 액세스를 거부하는 것과 같은 비정상 디바이스에 대한 결과를 부과해야 합니다. 비정상 디바이스에 대한 결과는 다음 섹션에 자세히 설명된 조건부 액세스 제어의 목적입니다.

액세스 권한이 부여되기 전에 Windows 기반 디바이스의 보안 제어

대부분의 경우 오늘날의 액세스 제어 기술은 적절한 사용자가 올바른 리소스에 액세스할 수 있도록 하는 데 중점을 둡니다. 사용자가 인증할 수 있는 경우 조직의 IT 직원과 시스템이 거의 알지 못하는 디바이스를 사용하여 리소스에 액세스할 수 있습니다. 아마도 전자 메일에 대한 액세스 권한을 부여하기 전에 디바이스가 암호화되었는지 확인하는 것과 같은 몇 가지 검사가 있을 수 있지만, 디바이스가 맬웨어에 감염되면 어떻게 해야 할까요?

원격 디바이스 상태 증명 프로세스는 측정된 부팅 데이터를 사용하여 디바이스의 상태를 확인합니다. 그런 다음 디바이스의 상태는 Intune과 같은 MDM 솔루션에 사용할 수 있습니다.

참고

Intune 및 Windows 기능 지원에 대한 최신 정보는 Microsoft Intune의 새로운 기능을 참조하세요.

아래 그림은 상태 증명 서비스가 Microsoft의 클라우드 기반 Intune MDM 서비스와 어떻게 작동해야 하는지 보여줍니다.

그림 10.

그런 다음 MDM 솔루션은 상태 문을 사용하고, 디바이스가 맬웨어가 없는지, 맬웨어 방지 시스템이 기능적이고 최신 상태이며, 방화벽이 실행 중이며, 디바이스 패치 상태가 준수됨을 증명하는 디바이스의 기능에 따라 조건부 액세스를 부여할 수 있도록 하는 클라이언트 정책과 결합하여 다음 단계로 끌어올 수 있습니다.

마지막으로 리소스가 정상임을 증명할 수 없는 엔드포인트에 대한 액세스를 거부하여 리소스를 보호할 수 있습니다. 이 기능은 조직 리소스에 액세스해야 하는 BYOD 디바이스에 많이 필요합니다.

Windows에서 MDM의 기본 제공 지원

Windows에는 운영 체제의 일부로 제공되는 MDM 클라이언트가 있습니다. 이 MDM 클라이언트를 사용하면 MDM 서버가 별도의 에이전트 없이 Windows 기반 디바이스를 관리할 수 있습니다.

비 Microsoft MDM 서버 지원

비 Microsoft MDM 서버는 MDM 프로토콜을 사용하여 Windows를 관리할 수 있습니다. 기본 제공 관리 클라이언트는 OMA-DM 프로토콜을 지원하는 호환되는 서버와 통신하여 엔터프라이즈 관리 작업을 수행할 수 있습니다. 자세한 내용은 MDM과 Microsoft Entra 통합을 참조하세요.

참고

MDM 서버는 Windows를 관리하기 위해 클라이언트를 만들거나 다운로드할 필요가 없습니다. 자세한 내용은 모바일 디바이스 관리를 참조하세요.

타사 MDM 서버는 등록에 대해 동일한 일관된 자사 사용자 환경을 갖습니다. 이 환경은 Windows 사용자에게도 단순성을 제공합니다.

타사 MDM별 Windows Defender 관리

이 관리 인프라를 사용하면 IT 전문가가 Intune과 같은 MDM 지원 제품을 사용하여 도메인에 가입되지 않은 BYOD를 포함하여 Windows 기반 디바이스에서 상태 증명, Device Guard 또는 Windows Defender를 관리할 수 있습니다. IT 전문가는 하위 수준 운영 체제에서 Intune Endpoint Protection과 함께 Intune을 사용하여 사용자 지정에 익숙한 모든 작업 및 설정을 관리하고 구성할 수 있습니다. 현재 그룹 정책을 통해 도메인에 가입된 디바이스만 관리하는 관리자는 대부분의 설정과 작업이 두 메커니즘 간에 공유되기 때문에 MDM을 사용하여 Windows 기반 디바이스 관리로 쉽게 전환할 수 있습니다.

MDM 솔루션을 사용하여 Windows 보안 및 시스템 설정을 관리하는 방법에 대한 자세한 내용은 Windows 디바이스에 대한 사용자 지정 URI 설정을 참조하세요.

조건부 액세스 제어

대부분의 플랫폼에서 Microsoft Entra 디바이스 등록은 등록 중에 자동으로 수행됩니다. 디바이스 상태는 MDM 솔루션에서 Microsoft Entra ID로 작성한 다음, 다음에 클라이언트가 Office 365 호환 워크로드에 액세스하려고 할 때 Office 365(또는 Microsoft Entra ID와 상호 작용하는 모든 권한 있는 Windows 앱)에서 읽습니다.

디바이스가 등록되지 않은 경우 사용자는 등록 방법(등록이라고도 함)에 대한 지침이 포함된 메시지를 받게 됩니다. 디바이스가 규정을 준수하지 않으면 사용자는 준수 문제와 해결 방법에 대한 자세한 정보를 얻을 수 있는 MDM 웹 포털로 리디렉션하는 다른 메시지를 받게 됩니다.

Microsoft Entra ID 는 사용자 및 디바이스를 인증하고, MDM 은 규정 준수 및 조건부 액세스 정책을 관리하며, 상태 증명 서비스는 증명된 방식으로 디바이스의 상태에 대해 보고합니다.

그림 11.

Office 365 조건부 액세스 제어

Microsoft Entra ID는 조건부 액세스 정책을 적용하여 Office 365 서비스에 대한 액세스를 보호합니다. 테넌트 관리자는 비준수 디바이스의 사용자가 Office 365 서비스에 액세스하지 못하도록 차단하는 조건부 액세스 정책을 만들 수 있습니다. 사용자는 서비스에 대한 액세스 권한을 부여하기 전에 회사의 디바이스 정책을 준수해야 합니다. 또는 관리자는 사용자가 Office 365 서비스에 액세스하기 위해 디바이스를 등록하도록 요구하는 정책을 만들 수도 있습니다. 정책은 조직의 모든 사용자에게 적용되거나 몇 개의 대상 그룹으로 제한되고 시간이 지남에 따라 더 많은 대상 그룹을 포함하도록 향상될 수 있습니다.

사용자가 지원되는 디바이스 플랫폼에서 Office 365 서비스에 대한 액세스를 요청하면 Microsoft Entra는 사용자가 요청을 시작하는 사용자 및 디바이스를 인증합니다. 및 는 사용자가 서비스에 대한 정책 집합을 준수하는 경우에만 서비스에 대한 액세스 권한을 부여합니다. 디바이스를 등록하지 않은 사용자에게는 회사 Office 365 서비스에 액세스하기 위해 등록하고 규정을 준수하는 방법에 대한 수정 지침이 제공됩니다.

사용자가 등록하면 디바이스가 Microsoft Entra ID에 등록되고 Intune과 같은 호환되는 MDM 솔루션에 등록됩니다.

참고

Microsoft는 자동화된 MDM 등록 및 정책 기반 액세스 검사를 지원하기 위해 타사 MDM ISV와 협력하고 있습니다. Microsoft Entra ID 및 Intune을 사용하여 자동 MDM 등록을 설정하는 단계는 Windows, Microsoft Entra ID 및 Microsoft Intune: 클라우드에서 제공하는 자동 MDM 등록! 블로그 게시물에 설명되어 있습니다.

사용자가 디바이스를 성공적으로 등록하면 디바이스가 신뢰할 수 있게 됩니다. Microsoft Entra ID는 회사 애플리케이션에 액세스하기 위한 Single Sign-On을 제공하고 조건부 액세스 정책을 적용하여 사용자가 처음으로 액세스를 요청할 뿐만 아니라 사용자가 액세스 갱신을 요청할 때마다 서비스에 대한 액세스 권한을 부여합니다.

로그인 자격 증명이 변경되거나, 디바이스가 손실/도난당하거나, 갱신 요청 시 준수 정책이 충족되지 않을 때 사용자에게 서비스에 대한 액세스가 거부됩니다.

직원이 Exchange Online에 액세스하는 데 사용하는 전자 메일 애플리케이션 유형에 따라 전자 메일에 대한 보안 액세스를 설정하는 경로가 약간 다를 수 있습니다. 그러나 주요 구성 요소인 Microsoft Entra ID, Office 365/Exchange Online 및 Intune은 동일합니다. IT 환경과 최종 사용자 환경도 비슷합니다.

그림 12.

Office 365에 액세스하려는 클라이언트는 다음 속성에 대해 평가됩니다.

디바이스가 MDM에서 관리되고 있나요?
디바이스가 Microsoft Entra ID에 등록되어 있나요?
디바이스가 규격인가요?

규격 상태가 되도록 Windows 기반 디바이스는 다음을 수행해야 합니다.

MDM 솔루션에 등록합니다.
Microsoft Entra ID에 등록합니다.
MDM 솔루션에서 설정한 디바이스 정책을 준수해야 합니다.

참고

현재 조건부 액세스 정책은 iOS 및 Android 디바이스의 사용자에게 선택적으로 적용됩니다. 자세한 내용은 Microsoft Entra ID, Microsoft Intune 및 Windows - 클라우드를 사용하여 엔터프라이즈 이동성 현대화! 블로그 게시물을 참조하세요.

클라우드 및 온-프레미스 앱 조건부 액세스 제어

조건부 액세스 제어는 Microsoft Entra ID에 기본 제공되는 강력한 정책 평가 엔진입니다. IT 전문가는 사용자의 로그인 컨텍스트를 평가하는 Office 365 이외의 액세스 규칙을 쉽게 만들어 액세스할 수 있는 애플리케이션에 대한 실시간 결정을 내릴 수 있습니다.

IT 전문가는 Microsoft Entra ID 및 온-프레미스 애플리케이션으로 보호되는 클라우드 SaaS 애플리케이션에 대한 조건부 액세스 제어 정책을 구성할 수 있습니다. Microsoft Entra ID의 액세스 규칙은 조건부 액세스 엔진을 사용하여 Intune과 같은 호환되는 MDM 솔루션에서 보고한 디바이스 상태 및 규정 준수 상태를 확인하여 액세스를 허용할지 여부를 결정합니다.

조건부 액세스에 대한 자세한 내용은 SaaS 앱용 Azure 조건부 액세스 미리 보기를 참조하세요.

참고

조건부 액세스 제어는 EMS에서도 사용할 수 있는 Microsoft Entra ID P1 또는 P2 기능입니다. Microsoft Entra ID P1 또는 P2 구독이 없는 경우 Microsoft Azure 사이트에서 평가판을 받을 수 있습니다.

온-프레미스 애플리케이션의 경우 디바이스의 규정 준수 상태에 따라 조건부 액세스 제어를 사용하도록 설정하는 두 가지 옵션이 있습니다.

Microsoft Entra 애플리케이션 프록시를 통해 게시되는 온-프레미스 애플리케이션의 경우 클라우드 애플리케이션과 마찬가지로 조건부 액세스 제어 정책을 구성할 수 있습니다. 자세한 내용은 Microsoft Entra 애플리케이션 프록시를 사용하여 원격 사용자를 위한 온-프레미스 앱 게시를 참조하세요.
또한 Microsoft Entra Connect는 Microsoft Entra ID에서 온-프레미스 AD로 디바이스 준수 정보를 동기화합니다. Windows Server 2016의 ADFS는 디바이스의 규정 준수 상태에 따라 조건부 액세스 제어를 지원합니다. IT 전문가는 호환되는 MDM 솔루션에서 보고한 디바이스의 규정 준수 상태를 사용하여 온-프레미스 애플리케이션을 보호하는 ADFS에서 조건부 액세스 제어 정책을 구성합니다.

그림 13.

다음 프로세스에서는 Microsoft Entra 조건부 액세스의 작동 방식을 설명합니다.

사용자가 Microsoft Entra ID로 디바이스를 등록하는 Workplace Access/Azure AD 조인을 통해 MDM에 이미 등록했습니다.
디바이스가 최대 절전 모드에서 부팅되거나 다시 시작되면 상태 증명 Blob을 백그라운드에서 요청하도록 "Tpm-HASCertRetr" 작업이 트리거됩니다. 디바이스는 상태 증명 서비스에 TPM 부팅 측정값을 보냅니다.
상태 증명 서비스는 디바이스 상태의 유효성을 검사하고 실패한 검사(있는 경우)에 대한 세부 정보와 함께 상태에 따라 디바이스에 암호화된 Blob을 발급합니다.
사용자가 로그온하고 MDM 에이전트가 Intune/MDM 서버에 연결합니다.
MDM 서버는 사용 가능한 경우 새 정책을 푸시다운하고 상태 Blob 상태 및 기타 인벤토리 상태를 쿼리합니다.
디바이스는 이전에 획득한 상태 증명 Blob과 Intune/MDM 서버에서 요청한 다른 상태 인벤토리의 값도 보냅니다.
Intune/MDM 서버는 상태 증명 Blob을 상태 증명 서비스로 보내 유효성을 검사합니다.
상태 증명 서비스는 상태 증명 Blob을 보낸 디바이스가 정상인지 확인하고 이 결과를 Intune/MDM 서버에 반환합니다.
Intune/MDM 서버는 디바이스의 준수 및 쿼리된 인벤토리/상태 증명 상태에 따라 규정 준수를 평가합니다.
Intune/MDM 서버는 Microsoft Entra ID의 디바이스 개체에 대한 준수 상태를 업데이트합니다.
사용자가 앱을 열고 회사 관리 자산에 액세스하려고 시도합니다.
Microsoft Entra ID의 규정 준수 클레임에 의해 제어되는 액세스.
디바이스가 규정을 준수하고 사용자에게 권한이 부여되면 액세스 토큰이 생성됩니다.
사용자는 회사 관리 자산에 액세스할 수 있습니다.

Microsoft Entra 조인에 대한 자세한 내용은 Microsoft Entra ID & Windows: Better Together for Work or School, 백서를 참조하세요.

조건부 액세스 제어는 많은 조직과 IT 전문가가 알지 못할 수도 있고 해야 하는 주제입니다. 조건부 액세스 엔진과 함께 사용할 때 사용자, 디바이스, 규정 준수 및 액세스 컨텍스트를 설명하는 다양한 특성이 강력합니다. 조건부 액세스 제어는 조직이 환경을 보호하는 데 도움이 되는 필수 단계입니다.

테이크아웃 및 요약

다음 목록에는 조직의 보안 태세를 개선하기 위한 개략적인 주요 내용이 포함되어 있습니다. 그러나 이 섹션에 제시된 몇 가지 설명은 보안 모범 사례의 전체 목록으로 해석되어서는 안 됩니다.

100% 안전한 솔루션이 없음을 이해합니다.

악의적인 의도를 가진 악의적인 악의적 사용자가 디바이스에 물리적으로 액세스할 수 있는 경우 결국 보안 계층을 뚫고 제어할 수 있습니다.
MDM 솔루션에서 상태 증명 사용

고부가가치 자산에 연결하려는 디바이스는 비정상 및 비규격 디바이스를 검색, 보고 및 결국 차단할 수 있도록 상태를 평가해야 합니다.
Credential Guard 사용

Credential Guard는 해시 통과 공격으로부터 회사 도메인 자격 증명을 크게 보호하는 데 도움이 되는 기능입니다.
Device Guard 사용

Device Guard는 보안의 진정한 발전이며 맬웨어로부터 보호하는 효과적인 방법입니다. Windows의 Device Guard 기능은 신뢰할 수 없는 앱(조직에서 승인하지 않은 앱)을 차단합니다.
Device Guard 정책 서명

서명된 Device Guard 정책은 현재 정책을 무효화하려는 관리자 권한이 있는 사용자로부터 보호하는 데 도움이 됩니다. 정책이 서명되면 나중에 Device Guard를 수정하는 유일한 방법은 동일한 서명자가 서명하거나 Device Guard 정책의 일부로 지정하는 서명자가 서명한 새 버전의 정책을 제공하는 것입니다.
가상화 기반 보안 사용

가상화 기반 보안으로 보호되는 커널 모드 코드 무결성이 있는 경우 취약성이 무단 커널 모드 메모리 액세스를 허용하는 경우에도 코드 무결성 규칙이 계속 적용됩니다. 가상화 기반 보안으로 커널 코드 무결성을 실행하는 Device Guard 디바이스에는 호환되는 드라이버가 있어야 합니다.
감사 모드를 사용하여 Device Guard 배포 시작

감사 모드에서 대상 컴퓨터 및 디바이스에 Device Guard 정책을 배포합니다. Device Guard가 적용 모드로 구성된 경우 프로그램 또는 드라이버가 차단되었음을 나타내는 코드 무결성 이벤트 로그를 모니터링합니다. 높은 수준의 신뢰도에 도달할 때까지 Device Guard 규칙을 조정합니다. 테스트 단계가 완료되면 Device Guard 정책을 적용 모드로 전환할 수 있습니다.
Device Guard를 배포할 때 격리된 참조 머신 빌드

회사 네트워크에 맬웨어가 포함될 수 있으므로 기본 회사 네트워크와 격리된 참조 환경을 구성해야 합니다. 그런 다음 보호된 디바이스에서 실행하려는 신뢰할 수 있는 애플리케이션을 포함하는 코드 무결성 정책을 만들 수 있습니다.
적합한 경우 AppLocker 사용

AppLocker는 새로운 Device Guard 기능으로 간주되지 않지만 특정 사용자 또는 사용자 그룹에 대해 특정 유니버설 Windows 애플리케이션을 거부할 수 있는 것과 같은 일부 시나리오에서 Device Guard 기능을 보완합니다.
펌웨어 및 구성 잠금

Windows가 설치되면 펌웨어 부팅 옵션 액세스를 잠급니다. 이 잠금을 사용하면 물리적 액세스 권한이 있는 사용자가 UEFI 설정을 수정하거나, 보안 부팅을 사용하지 않도록 설정하거나, 다른 운영 체제를 부팅할 수 없습니다. 또한 Device Guard를 사용하지 않도록 설정하려는 관리자로부터 보호하기 위해 현재 Device Guard 정책에 C:\Windows\System32\SecConfig.efi 도구의 실행을 거부하고 차단하는 규칙을 추가합니다.

상태 증명은 사용자 및 디바이스의 ID 및 회사 거버넌스 정책 준수에 따라 고부가가치 자산에 대한 액세스를 제어하는 클라이언트 및 클라우드 구성 요소를 포함하는 Windows의 주요 기능입니다. 조직은 비정상 디바이스를 검색하고 보고하거나 요구 사항에 따라 상태 적용 규칙을 구성하도록 선택할 수 있습니다. 상태 증명은 공급업체 및 소프트웨어 개발자가 사용자 지정된 솔루션을 빌드하고 통합하는 데 사용할 수 있는 엔드 투 엔드 보안 모델 및 통합 지점을 제공합니다.

다음을 통해 공유