[アップデート] EC2インスタンスでWindows Defender Credential Guardがサポートされました

Takuya Shibata
2023.02.06
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
先週AWSよりEC2においてWindows Defender Credential Guard(以後Credential Guardと表記)がサポートされたとアナウンスされました。
https://aws.amazon.com/jp/about-aws/whats-new/2023/01/aws-credential-guard-windows-instances-amazon-ec2/
本記事ではこの詳細を解説します。
 Credential Guardとは？Credential GuardはWindows 10/Windows Server 2016より登場した仮想化ベースのセキュリティ(VBS)の一機能です。

VBSはその名前の通りHyper-Vの機能を使い、ハイパーバイザーによって分離された環境(VSM)のカーネル上でOSの特定機能を実行します。
(https://techcommunity.microsoft.com/t5/windows-insider-program/virtualization-based-security-vbs-and-hypervisor-enforced-code/m-p/240571 より引用)
そしてCredential GuardはOSの認証情報を取り扱うプロセスであるLSASS(Local Security Authority Server Service)のメモリ内に保存される認証情報を盗み取る攻撃(Pass-the-Hash攻撃)を防ぐためにLSAの処理を隔離された環境(LSAIso)で行うものになります。
(https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-how-it-works より引用)
より具体的なはなしは@ITのこちらの記事がわかりやすいので参考にしてください。
物理マシンとユーザーのための「デバイスガード」と「資格情報ガード」――仮想化ベースのセキュリティ（その1）
認証情報を守るWindows 10の「Credential Guard」
 AWSにおける前提条件Credential GuardはWindows OSの標準機能ですが、AWS上で実行する場合は以下の前提条件を満たす必要があります。
参考 : Credential Guard : Prerequisites
 1. NitroTPMとUEFI Secure Bootが有効なAMIAWSでCredential Guardを有効にするにはNitroTPMとUEFI Secure Bootが有効なAMIを使う必要があります。

通常のWindows Server AMIはNitroTPMとUEFIブートは無効なので専用のAMIを使うか自前でNitroTPMを有効にしたAMIを用意する必要があります。
NitroTPMはAWSによって提供されるTPM 2.0互換の仮想TPMモジュールであり、細かい話は以下のブログを見て頂くのが良いでしょう。
https://aws.amazon.com/jp/blogs/news/amazon-ec2-now-supports-nitrotpm-and-uefi-secure-boot/
ちなみに、本日時点でAWS公式でNitroTPMが有効なAMIは以下のTPM-Windows_Serverで始まる名前で提供されています。
TPM-Windows_Server-2022-English-Full-Base
TPM-Windows_Server-2022-English-Core-Base
TPM-Windows_Server-2019-English-Full-Base
TPM-Windows_Server-2019-English-Core-Base
TPM-Windows_Server-2016-English-Full-Base
TPM-Windows_Server-2016-English-Core-Base
英語版OSのみの提供です。

AWS CLIだと以下のコマンドで検索可能です。
# AWS CLI on PowerShellの場合
aws ec2 describe-images `
    --filters 'Name=platform,Values=windows' 'Name=name,Values=TPM-Windows_Server-*' `
    --query 'reverse(sort_by(Images, &CreationDate))[*].{ImageId:ImageId, Name:Name, Description:Description}' `
    --output json |
    ConvertFrom-Json | Format-List
実行例)
PS C:\> aws ec2 describe-images `
>     --filters 'Name=platform,Values=windows' 'Name=name,Values=TPM-Windows_Server-*' `
>     --query 'reverse(sort_by(Images, &CreationDate))[*].{ImageId:ImageId, Name:Name, Description:Description}' `
>     --output json |
>     ConvertFrom-Json | Format-List

# ・・・中略・・・

ImageId     : ami-077cd4fb23670552b
Name        : TPM-Windows_Server-2022-English-Full-Base-2023.01.19
Description : Microsoft Windows Server 2022 Full Locale English with TPM 2.0 and Secure Boot support, AMI provided by Amazon

ImageId     : ami-0228f44254658986b
Name        : TPM-Windows_Server-2022-English-Core-Base-2023.01.19
Description : Microsoft Windows Server 2022 Core Locale English with TPM 2.0 and Secure Boot support, AMI provided by Amazon

# ・・・後略・・・
また、各AMIでNitroTPMとUEFIブートが有効かどうかは以下のコマンドで確認できます。
# AWS CLI on PowerShellの場合
aws ec2 describe-images --image-ids "AMI ID" `
    --query "Images[].{Name:Name,BootMode:BootMode,TpmSupport:TpmSupport}" `
    --output json | 
    ConvertFrom-Json
実行例)
# 有効な場合、TpmSupport, BootMode それぞれに値が設定される
PS C:\> aws ec2 describe-images --image-ids ami-077cd4fb23670552b ami-05f53c2def3a51a08 `
>     --query "Images[].{Name:Name,BootMode:BootMode,TpmSupport:TpmSupport}" `
>     --output json |
>     ConvertFrom-Json

Name                                                 BootMode TpmSupport
----                                                 -------- ----------
Windows_Server-2022-English-Full-Base-2023.01.19
TPM-Windows_Server-2022-English-Full-Base-2023.01.19 uefi     v2.0
 2. インスタンスタイプCredential Guardがサポートされるインスタンスタイプは限定されています。

具体的なリストは前掲のドキュメントに記載の通りですが、ざっくりNitro第5世代以降のC、M、Rタイプである必要があります。
ここでは対象となるインスタンスタイプのみ記載します。
C5, C5d, C5n
C6i, C6id
M5, M5d, M5dn, M5n, M5zn
M6i, M6id, M6in
R5, R5b, R5d, R5dn, R5n
R6i, R6id, R6in
なお、NitroTPMをサポートするインスタンスタイプとは微妙に異なりますのでご注意ください。

(NitroTPMをサポートする内の一部だけがCredential Guardをサポートする)
 3. OSCredential GuardはWindows Server 2016から導入された機能であるため、Windows Server 2016以降のOSである必要があります。

AWSが公式に用意するTPM有効のAMIはすべてWindows Server 2016より新しいOSなので気にしないで大丈夫ですが、自前でTPMを有効にしたAMIを作る場合はご留意ください。
 試してみたそれでは実際に試していきます。
今回は私の検証用AWSアカウントの東京リージョンにNitroTPM有効のEC2インスタンスを一台用意します。

AMIとインスタンスタイプは下記の通りです。
AMI : ami-077cd4fb23670552b (TPM-Windows_Server-2022-English-Full-Base-2023.01.19)
インスタンスタイプ : m6i.large
VPC環境およびEC2自体の構築手順は割愛します。
以降の作業は当該インスタンスにリモートデスクトップ接続した状態で行っています。
 NitroTPMの確認はじめにTPMの管理(tpm.msc)を呼び出してNitroTPMが有効か確認しておきます。

「TPM Manufacturer Information」欄に「Manufacturer Name: AMZN」の表示がされていれば問題ありません。
なお、NitroTPMが無効な場合は「TPMが見つからない」旨の表示になります。
 Credential Guardの有効化Credential Guardを有効にする方法はいくつかありますが、AWSのドキュメントではグループポリシーを使った方法が記載されているので本記事でもそれに倣います。
Turning on Credential Guard
今回はワークグループ環境なのでローカルグループポリシーエディタ(gpedit.msc)を使います。

エディタの左ペインを「Computer Configuration」→「Administrative Templates」→「System」→「Device Guard」の順に選択し「Turn On Virtualization Based Security」ポリシーを設定します。
このポリシーの「Select Platform Security Level」をSecure Boot and DMA Protection、「Credential Guard Configuration」をEnabled without lockに設定します。
ちゃんと設定済みになっていることを確認しサーバーを再起動します。
以上で作業は完了です。
ちなみにグループポリシーからCredential Guardを有効にする場合は「Hyper-Vの機能」を明示して有効にする必要はありません。ポリシーを設定するだけで大丈夫です。
 Credential Guardの確認再起動後はCredential Guardが有効になります。
システム情報(msinfo32.exe)を起動するとVBSおよびCredential Guardの設定状況が確認できます。

「System Summary」欄が下図の様になっていればCredential Guardが有効です。
特に見るべき項目はVirtualization-based security = Running、Virtualization-based security Services Running = Credential GUardあたりでしょう。
ちなみにVBSおよびCredential Guardが無効な場合はVirtualization-based security = Not enabledだけ記載され他の項目は表示されません。
(VBSおよびCredential Guardが無効な場合)
 補足 : HVCI and Windows Defender Credential Guard hardware readiness tool別の確認方法としてMicrosoftが専用のPowerShellスクリプトを提供しています。
Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool
上記ページに記載されているPowerShellスクリプトを任意の名前で保存して、スクリプト名.ps1 -Readyと-Readyパラメーターを付けて実行してやると設定状況が表示されます。
(上図ではスクリプトをDG_Readliness_Tool_v3.7.ps1という名前で保存)
このツールではCredential Guard以外の設定状況も確認でき、実行ログがC:\DGLogs\DeviceGuardCheckLog.txtに保存されます。
DeviceGuardCheckLog.txt
###########################################################################

Readiness Tool Version 3.7.2 Release. 
Tool to check if your device is capable to run Device Guard and Credential Guard.

###########################################################################

###########################################################################
OS and Hardware requirements for enabling Device Guard and Credential Guard
 1. OS SKUs: Available only on these OS Skus - Enterprise, Server, Education and Enterprise IoT
 2. Hardware: Recent hardware that supports virtualization extension with SLAT
To learn more please visit: https://aka.ms/dgwhcr
########################################################################### 

Current DGRunning = 1, ConfigCI= 0
_CGState: 1, _HVCIState: 0, _ConfigCIState: 0
Credential-Guard is enabled and running.
HVCI is not running.
Config-CI is not running. (Not Enabled)
Not all services are running.
 余談 : Pass-the-Challenge本記事を書いている際に知ったのですが、Credential Guardを回避する新しい攻撃手法(Pass-the-Challenge)が最近公開されたそうです。

日本語では以下のブログが詳しかったので参考になると思います。
https://n-etupirka.net/entry/2023/01/28/104428
私はセキュリティの専門家では無いのでなんとも言えませんが、Credential Guardがあるから安全と安易に考えない方が良さそうですね。Pass-the-Challengeが対象としているのはNTLMハッシュのみの様なので[1]逆にCredential Guardは設定するだけ無駄とも言えなそうです。
ありきたりですが結局は組織のセキュリティ要件に応じてCredential Guardの導入を決めると良いんじゃないかと思う次第です。
 最後に以上となります。
導入までの敷居は高めですが要件によっては導入する価値があるのではないでしょうか？

NitroTPMを有効にした場合AMIの作成やEBSスナップショットの作成とリストアに制約が付きますのでその点はご注意ください。

脚注
基本的にNTLMv1,v2の話でKerberosチケットも対象なのかよくわからなかった... ↩︎