Windows 10, 보다 안전한 컴퓨팅 환경을 위한 핵심 기술, Device Guard (장치 보호) 2편, Device Guard의 구현/적용
지난 Windows 10, 보다 안전한 컴퓨팅 환경을 위한 핵심 기술, Device Guard (장치 보호) 1편 포스팅에서 Device Guard에 대한 기술적인 소개를 살펴보았습니다. 포스팅 이후, 전자신문 김인순기자님께서 관련된 기사까지 게시해주셨었는데요. 실제 동작과 관련된 여러 논란의 요소가 있어, 구현과 동작 관련한 포스팅을 바로 이어서 작성합니다.
1편에서 살짝 공개한 Device Guard 구현과 관련된 설치 구성 요소는 “Windows 기능 켜기/끄기”내 “격리된 사용자 모드”였습니다.
Windows 10의 Device Guard는 일반 사용자가 주로 사용할 Windows 10 Home/Professional 에디션에서는 사용할 수 없고, Windows 10 Enterprise/Education 에디션에서만 사용할 수 있습니다. 또한 Device Guard가 기본 설치/구성되어 판매할 OEM 디바이스를 제외하고는 기본적으로 켜져있지 않은 상태입니다. 비즈니스 조직내 IT 관리자와 관련 부서에서 허가되지 않은 프로그램들에 대해 Device Guard를 이용하여 보호하고자 한다면, 조직내 표준 컴퓨터에서 Device Guard에 대한 코드 무결성 정책(Code Integrity Policy)를 생성하고, 이를 반영하여 Device Guard를 활성화하게 됩니다. (Windows 10에 Device Guard가 기본 동작하는 상태가 아니며, 일반 사용자 버전(Home/Professional)에는 반영할 수 없음을 다시 한번 강조합니다.)
또한 Windows Store/Business Store에서 다운로드되고 설치된 프로그램은 신뢰된 항목에 포함되기에, 실행이 가능합니다. 이에 대한 제어를 위해서는 Windows내 AppLocker를 이용해야 합니다.
서명되어 있지 않은 모든 프로그램들을 사용할 수 없게 한다면, 기존에 사용중인 조직내 기간계(LOB) 응용 프로그램이나, 사용자들이 많이 사용하는 프로그램들은 사용할 수 없게 됩니다. 새롭게 서명을 하는 작업등은 시간과 비용이 소모되는 작업이므로 Device Guard를 구현하는데 큰 장벽이 되는데, Device Guard에서는 IT 관리자가 정책을 만들 때, 서명되지 않은 프로그램들에 대해서는 파일의 고유 정보를 수집하여, 예외 처리를 할 수 있게 됩니다. 따라서 IT 관리자는 Device Guard에 대한 조직내 구성을 계획할 때, 사용자들이 조직내에서 업무를 위해 필수적으로 사용할 프로그램들이 서명된 상태인지, 서명되지 않은 상태인지에 대한 분류가 필요하며, 이에 대한 정책 생성시, 이를 반영해주는 작업을 해야 합니다.
Device Guard에 대한 구성은 그룹 정책, 또는 레지스트리 수정을 통해서 진행합니다. 로컬 혹은 도메인 그룹 정책내 컴퓨터 구성, 관리 템플릿, 시스템, 장치 보호 항목에 갑니다.
가상화 기반 보안 켜기 항목을 사용으로 변경하신 후, 보안 부팅에 대한 부분을 구성해야 합니다. 만약 사용하는 하드웨어에 가상화 기술이 탑재되지 않았다면, 가상화 기반으로 커널내 주요 영역(인증, 코드 무결성 검사)을 보호할 수 없고, 코드 무결성 정책을 배포하여, 일반 커널내 배치된 코드 무결성 검사 서비스에서 이를 처리하게 됩니다. (1편내 그림에서 하드웨어 기술이 있을 때와 없을 때에 대한 비교를 포스팅하였습니다.)
플랫폼 보안 수준 선택에서도 두가지 옵션이 제공됩니다. UEFI 기반의 보안 부팅만 설정할 것인지, 하드웨어의 IOMMU 기술을 활용하여, DMA(Direct Memory Attack)에 대한 보호까지 진행할지를 결정합니다. 사용하는 디바이스에 IOMMU 기술이 없다면, DMA 보호를 구성할 수 없습니다. 사용중인 디바이스의 관련 기술 여부를 확인하려면 시스템 정보 도구(msinfo32)를 실행하여, 하단에 표시된 항목을 확인합니다. (장치 보호 사용 가능한 보안 속성에 표시되어야 합니다.)
두 개의 체크 박스가 더 있습니다. 가상화 기반으로 구성된 별도의 커널 컨테이너에 코드 무결성 서비스와 자격 증명(Credential Guard)를 배치할지에 대한 부분입니다. 가상화 기술을 사용한다면, 당연히 보안을 높히기 위해, 두 기술을 가상화 기반 컨테이너에 배치하는 것을 권장합니다.
그룹 정책을 사용하지 않고, 레지스트리를 통해 반영하려면, HKLM\System\CurrentControlSet\Control\DeviceGuard 항목, 또한 Credential Guard에 대한 부분은 HKLM\System\CurrentControlSet\Control\LSA내 LsaCfgFlags 값에서 반영할 수 있습니다만, 로컬 그룹 정책(gpedit.msc)로 하는 것이 잘못된 구성을 막아주므로, 권장하겠죠. 구성 후에는 한번의 리부팅이 필요합니다.
리부팅 후, 해당 디바이스는 Device Guard를 사용할 준비는 모두 마친 상태입니다. 이에 대한 확인은 이벤트 뷰어, 응용 프로그램 및 서비스 로그, Microsoft, Windows, DeviceGuard, Operational내 Event ID 7000이 표기되어야 합니다. 로그내 가상화 기반 보호(VBS), 코드 무결성에 대한 가상화 기반 보호, 자격 증명 격리(Credential Guard)에 대한 구성 여부가 나타납니다.
Windows PowerShell의 WMI 쿼리를 통해서도 살펴볼 수 있습니다.
아무런 정책이 반영되어 있지 않기 때문에, 현재는 어떠한 제한도 없는 상태입니다. 이제 코드 무결성을 확인할 때 사용할 정책을 구성할 차례입니다. 당연한 이야기지만, 정책을 구성할 땐, Device Guard에 대한 정책이 이미 반영된 디바이스에서 하시면 안되겠죠? 
서명이 된 응용 프로그램과 서명되지 않은 응용 프로그램에 대한 정책 구성 분리가 필요합니다. 정확하게 서명되지 않은 응용 프로그램에 대해서는 정책이라고 하지 않고, Device Guard 카탈로그 파일(Catalog File)이라고 부릅니다. Windows 10 Enterprise, 그리고 앞으로 출시될 Windows Server 2016에는 카탈로그 파일을 생성할 때 사용하는 프로그램인 PackageInspector가 내장되어 있습니다. 해당 프로그램은 서명되지 않은 응용 프로그램, 아니면 서명되어져 있지만, 파일의 고유 정보를 수집하여, Device Guard에서 적용 여부를 처리할 응용 프로그램을 구성할 수 있게 해줍니다.
PackageInspector.exe Start <드라이브명>을 한 후, Device Guard에서 실행 가능하게 할 응용 프로그램, 또는 설치 프로그램을 실행합니다. PackageInspector에서 구성되는 카탈로그 파일은 개별 설치/응용 프로그램 별로 만들거나, 여러 파일을 실행하여 하나로 구성할 수 있습니다. 모든 설치 및 응용 프로그램에 대해서 실행이 완료되었으면, PackageInspector.exe Stop <드라이브명> -Name <파일 이름.cat> -cdfpath <파일 이름.cdf>를 입력합니다. 여기서 만들어진 cat 파일이 카탈로그 파일이 되게 됩니다. 아무 카탈로그 파일이나 예외로 처리할 수 있다면, 이는 보안상 문제가 될 수 있기에, cat 파일에 대해서는 반드시 서명이 되어야 합니다. 이를 위해 Microsoft에서는 Windows Store의 비즈니스 버전인 Business Store내 Device Guard 카탈로그 파일 서명용 기능을 제공할 예정입니다. 조직내 자체적으로 서명에 사용할 인증서가 있다면, Windows SDK에 포함된 SignTool.exe로 서명을 진행할 수 있습니다. 서명이 완료된 파일은 C:\Windows\system32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} 에 복사합니다.
Device Guard용 카탈로그 파일은 폴더에 파일을 복사해줌으로써, 지속적인 업데이트가 가능합니다. 당연히 Windows내 주요 폴더이기에 관리자 권한 이상이 필요한 것은 당연합니다. 또한 개별 디바이스에 직접 업데이트를 하는 수고를 막기 위해, 그룹 정책, System Center를 이용할 수도 있습니다. System Center Configuration Manager의 경우에는 Software Inventory 기능을 사용하여 카탈로그 파일을 수집할 수도 있습니다.
자 이제, 실제 Device Guard 코드 무결성 정책을 만들 시점이 되었습니다. 코드 무결성 정책은 Windows PowerShell을 통해서 만들고 구성하게 됩니다. 조직에서 사용하는 모든 프로그램이 구성된 마스터 디바이스에서 Windows PowerShell을 엽니다.
여기서 New-CIPolicy Cmdlet을 사용하게 됩니다. New-CIPolicy는 지정된 폴더/드라이브내 전체를 검색하게 됩니다. 현재 열려 있기 때문에, 잠금 상태인 파일이 있을 수 있으므로, New-CIPolicy를 구동할 때는 별도의 스냅숏 항목에서 구성하는 것을 권장합니다.
2-5번 줄은 스냅숏을 하나 만들어, c:\scpy 폴더에 연결하는 작업입니다. 8번 라인은 New-CIPolicy로 해당 스냅숏이 연결된 폴더(사실 C 드라이브 전체죠)를 검사합니다. 여기서 중요한 항목은 Level 파라미터입니다. PCACertificate으로 되어 있는 경우에는 응용 프로그램이 서명된 최상위 인증서를 기반으로 허가 정책을 만든다는 뜻입니다. Level 파라미터에는 Hash, FileName, LeafCertificate 등이 있습니다. 아직까지 New-CIPolicy Cmdlet에 대한 도움말이 인터넷에 게시되지 않은 것으로 보이기에, 차후 업데이트하겠습니다. 또한 정책 생성시, 실행을 하지 못하게 하는 것이 아니라, 이에 대한 감사만을 남기게 하기 위해서는 11번 라인의 Cmdlet과 같이 -Audit 옵션을 사용하면 됩니다.
검사할 폴더와 파일의 양에 따라, 시간이 흘러, 정책에 사용될 xml이 생성됩니다. XML 파일은 정책 규칙과 파일 규칙으로 나눠져 있습니다.
Signers 항목은 PCACertificate의 목록입니다.(허가될)
Rules 항목(이를 정책 규칙이라고 합니다.)이 반영을 어떻게 할지에 대한 부분인데, 또 다시 살펴봐야 할 항목입니다. (포스팅이 너무 길어지고 있습니다. ㅜ_ㅜ) 앞서 New-CIPolicy를 실행할 때, -UserPE 옵션을 붙였습니다. 이는 Device Guard 코드 무결성 정책을 사용자 모드에서 실행되는 응용 프로그램까지 확장하겠다는 의미입니다. 이를 1편에서 UMCI(User Mode Code Integrity)라고 불렀습니다. 이 옵션이 구성되어 있었기에, Enabled:UMCI 옵션(Option 0)이 활성화되었습니다. Enable:Audit Mode(옵션 3)는 -Audit 옵션으로 인해 생성된 것입니다. Enabled:Unsigned System Integrity Policy 항목(옵션 6)은 잠시 후 설명할 내용이지만, 코드 무결성 정책에 대해서도 당연히 서명을 하여 반영해야 합니다. 그렇지만, 서명하지 않고 정책을 반영하려면 기본적으로 추가되는 Enabled:Unsigned System Integrity Policy 항목을 내버려두면 됩니다. Enabled:Advanced Boot Options Menu(옵션 9) 항목은 부팅시 F8로 들어갈 수 있는 고급 부트 옵션에서 코드 무결성 검사를 중지할 수 있을지에 대한 부분입니다.
옵션이라는 항목을 파일에는 명시되어 있지 않지만, 제가 하나씩 붙여 놓았습니다.
- 0 : Enabled:UMCI
- 3 : Enabled:Audit Mode
- 6 : Enabled:Unsigned System Integrity Policy
- 8 : Required:EV Signers (응용 프로그램이 아닌, 드라이버 항목에 대한 서명 인증서 요구 사항입니다. 이후 Windows 10과 관련된 드라이버는 EV 인증서로 서명되어야 합니다.
- 9 : Enabled:Advanced Boot Options Menu
현재 만들어진 코드 무결성 정책 파일은 차단을 하지 않는 모드(Audit)로 동작하게 만들어져 있습니다.(Enabled UMCI) 또한 정책 파일이 서명되지 않아도 반영하라는 옵션도 켜져 있고, 일시적으로 코드 무결성 검사를 부팅 레벨에서 제어할 수 있는 항목도 존재합니다. (Enabled:Advanced Boot Options Menu)
IT 관리자는 이에 대한 옵션 제어를 해야 합니다. 감사(Audit) 모드로 동작하다가, 이제 차단 모드로 변경할 수도 있고, 여러 옵션들을 변경하고자 하겠죠. 이 때, Set-RuleOption Cmdlet을 사용하게 됩니다.
이해가 되시죠? -Delete 옵션이 붙으면 해제, 없이 실행하면 추가입니다. -Option 항목에서 앞서 언급한 번호를 입력하면 됩니다. 예제의 3은 바로 감사 모드에 대한 추가 및 해제입니다.
자~! 이제 거의 다 왔습니다. 정책 파일을 디바이스내 반영만 하면 됩니다. XML 파일을 BIN 파일로 변경한 후, 복사하면 됩니다. BIN 파일로 변경하는 Cmdlet은 ConvertFrom-CIPolicy입니다.
이 후, BIN 파일을 C:\Windows\System32\CodeIntegrity 폴더내 SIPolicy.p7b 이름으로 복사합니다.
해당 이름으로 복사하지 않고 지정한 BIN(예, KOALRA-CI.BIN)을 사용하고자 한다면, 그룹 정책을 이용하면 됩니다.
코드 무결성 정책을 반영하였다면, 리부팅을 해주어야 합니다. 리부팅 이후, 코드 무결성과 관련된 로그(감사 모드, 차단 모드 모두)는 이벤트 뷰어(응용 프로그램 및 서비스 로그, Microsoft, Windows, CodeIntegiry, Operational)에 기록됩니다. 1편내 첫번째 그림에 대한 로그죠
코드 무결성 정책에 대한 가장 높은 보안 레벨은 코드 무결성 정책 파일에 대한 서명으로 마무리됩니다. 서명된 코드 무결성 정책의 경우에는 디바이스내 관리자일지더라도 수정이 불가능해집니다. 서명을 위해서는 앞서 카탈로그 파일에서 언급한 SignTool.exe를 활용하게 됩니다.
수정이 불가능해지면, 어떻게 하냐라고 말씀하실 수 있는데, 여러 기술 조건이 결합된 형태가 Device Guard이므로, 해제를 하실 수도 있습니다. Device Guard는 보안 부팅이 Disable 되게 되면, 구동이 안되게 설계되어 있습니다.
Device Guard는 단순히 Windows내 소프트웨어만을 기반으로 구동되는 보안 기술이 아니라고, 몇번 언급하였습니다. 부팅 단계에서 USB/네트워크/CD,DVD-ROM등으로 부팅할 수 없도록 부트 오더를 변경할 수 없도록 잠궈놔야 하며, 시스템의 BIOS 설정등을 변경하여, 보안 부팅을 해제할 수도 있기 때문에, BIOS 셋업으로 들어가는 항목에 대해 관리자 암호를 요구하도록 구성해야 합니다. 이 후, 운영 체제가 정상적인 코드로 부팅됨을 보안 부팅(Secure Boot)이 책임지며, 서명된 안전한 드라이버만을 로드했다고 커널 모드 코드 무결성(KMCI)가 담당합니다. 마지막으로 이번 포스팅에서 살펴보면 코드 무결성 정책을 UMIC(User Mode Code Integrity)가 불러, 응용 프로그램에 대한 보안을 적용해주는 것이죠. 여기에 하드웨어 기술을 이용하여 코드 무결성 서비스, 인증에 대한 보호등을 가상화 환경으로 분리하고, DMA에 대한 보호를 위해 IOMMU를 사용하게 됩니다. 기술 하나에 대한 설정 무시가 전체적인 보안을 다 무너뜨릴 수도 있음을 유의해야 합니다. 이러한 이유로 Device Guard를 OEM사가 구성시 기본적으로 켜서 판매하는 디바이스를 Device Guard Ready라고 부르는 것입니다. (Windows Phone, Windows RT, iOS가 같은 형태죠)
Device Guard는 현재의 하드웨어 기술과 소프트웨어 기술을 잘 연계하여, 높은 수준의 보안을 구현할 수 있게 만든 기술입니다. 특정 보안 기술 영역만을 반영하여 사내 디바이스에 대한 보안을 높힐 수도 있고, 모든 기술을 반영하여 Device Guard라는 이름으로 구현할 수도 있습니다.
매우 길었던 포스팅이 끝났습니다. 다음 포스팅에서는 Windows 10에서 사용자의 암호에 대한 보안을 높혀주는 PIN.. 바로 Microsoft Passport에 대해서 살펴보겠습니다.
Comments
- Anonymous
July 28, 2015
좋은 정보 감사합니다. - Anonymous
July 30, 2015
좋은정보 많이 제공해주셔서 감사합니다.ㅎ - Anonymous
September 21, 2015
좋은 정보 감사합니다. 문의드릴게 있는데 기존 applocker나 Hash값으로 통제하는 부분과는 기술적으로 차이가 있는건가요? - Anonymous
September 22, 2015
감사합니다. 공부 해보겠습니다. - Anonymous
September 22, 2015
공부 해보겠습니다.
감사합니다. - Anonymous
September 29, 2015
뚜껑님 // 안녕하세요. 기존 AppLocker는 디바이스 가드의 기술 중에 일부입니다. 디바이스 가드는 디바이스의 켜짐부터, 부팅 단계, 운영 체제 로딩, 그리고 응용 프로그램 구동 환경까지를 모두 의미하며, AppLocker는 운영 체제의 사용자 모드에서 동작하지만, 디바이스 가드는 커널 레벨과 사용자 모드 레벨을 모두 지원하는 형태입니다. 이에 위 글 마지막 내용에서 가장 마지막 부분에만 AppLocker가 표시되어 있는 것입니다.