こんにちは！インフラやセキュリティの世界へようこそ。
日々、開発やサーバーの管理にお疲れ様です。新人のIT担当者さんや、セキュリティに初めて触れる開発者さんにとって、「サーバーの安全を守る（要塞化する）」というのは、なんだか難しそう壁に見えますよね。
でも、大丈夫です！一歩ずつ、身近な例えから紐解いていけば、決して越えられない壁ではありません。今回は、Windows環境における最強の防衛策の一つ「Windows Defender Application Control (WDAC)」について、分かりやすく解説していきますね。
—
1. なぜ「普通のセキュリティ対策」だけでは破られてしまうのか？
皆さんは、自分の家に出かけるとき、玄関のドアに鍵をかけますよね。現代のITインフラにおける従来のセキュリティ対策、例えば従来のウイルス対策ソフトなどは、いわば「泥棒の顔写真（ブラックリスト）を貼っておき、その人が来たら追い返す仕組み」でした。
しかし、攻撃者は非常に頭が良いです。日々、新しい顔（見たことのないウイルスや不正なプログラム）に整形して、私たちのサーバーに侵入しようとします。もし、知らない人が「宅急便です！」と言って新しい顔でやって来たら……従来の対策ソフトは「うーん、リストに載っていないから、まあ入ってもいいか」と通してしまうことがあるのです。
ここで登場するのが、今回テーマにする WDAC（Windows Defender Application Control） です。
—
2. WDACとは？ 家の鍵に例える「ホワイトリスト」の思想
WDACを身近な例えで言うと、「信頼できる家族や特定の業者リスト（ホワイトリスト）に載っている人以外は、たとえどんなにスーツを着て愛想が良くても、絶対に家の中に入れない鉄壁のセキュリティシステム」です。
ウイルス対策ソフトが「怪しいものを防ぐ」のに対し、WDACは「許可されていないものは、すべて動かさない（実行をブロックする）」という強力なアプローチをとります。
しかも、WDACがすごいのは、OSの最も根っこである「カーネルレベル」でそれを実行する点です。泥棒が家に入り込もうとした瞬間、玄関の床がパカッと割れて地下に落ちるような、OSの深部で不正なコードをねじ伏せる仕組みになっています。これなら、仮に攻撃者がサーバーの管理者の権限を一時的に奪ったとしても、WDACのポリシーを勝手に書き換えることは簡単にはできません。
—
3. AppLockerとの違いは何？
Windowsには、従来からアプリケーションの実行を制限する AppLocker という機能もありました。こちらも非常に便利なのですが、OSの少し「上の方（ユーザーモード）」で動いています。
そのため、高度な知識を持った攻撃者に権限を握られてしまうと、AppLockerのガードをすり抜けてしまう隙（バイパス）が存在することがありました。
一方の WDAC は、より深層の「カーネルレベル」でブロックするため、現代の高度なサイバー攻撃（ランサムウェアやファイルレス攻撃など）に対しても、圧倒的に高い耐性を発揮します。
—
4. 実践！WDACポリシーの基本設定を見てみよう
「なんだか難しそうな設定ファイルを書くのかな……」と身構えてしまいますよね。でも、基本の考え方はシンプルです。
WDACでは、XML形式のポリシーファイルを作成し、それに「どのプログラムの実行を許可するか」を定義します。
ここでは、実際にWDACのポリシーを作成する際の手順と、設定ファイルの雰囲気を感じていただきましょう。
ステップ1: 参照用（クリーン）な環境でルールを作る
WDACのポリシーを作る際は、余計なアプリが入っていない綺麗な状態のWindows（ゴールデンイメージなど）を用意し、そこに入っている信頼できるアプリをスキャンして「許可リスト（XML）」を自動生成するのが一般的です。
PowerShellを管理者として起動し、以下のようなコマンドレットを使ってベースとなるポリシーの雛形を作ります。
# 【解説】信頼できる基本イメージをスキャンして、WDACポリシーの雛形（XML）を作成するコマンド例です
New-CIPolicy -FilePath "C:\WDAC\BasePolicy.xml" -Level PFN -UserPEs- ※
PFNは パッケージファミリー名などを指し、アプリの署名などを元に安全性を判断するためのパラメータの一つです。
ステップ2: ポリシーの結合（マージ）と監査モード
いきなり「すべてを厳しくブロックするぞ！」とやると、社内で使っている大切な業務アプリまで動かなくなってしまい、社内が大パニックになってしまいます。これを実務では「検証不足によるインシデント」と呼びます。
そのため、最初は「監査モード（Audit Mode）」という、ブロックはせずに「もしこのポリシーを本番適用したら、どれがブロック対象になるかな？」というログだけを記録するモードで動かします。
# 【解説】作成したポリシーに「監査モード」のルールをマージ（追加）する例
Set-RuleOption -FilePath "C:\WDAC\BasePolicy.xml" -Option 3- *Option 3* を指定することで、ポリシーに違反するプログラムがあっても実行を止めず、イベントビューアーに「警告」として記録を残すことができます。これにより、安全にテスト運用が行えます。
ステップ3: 本番適用（強制モード）への切り替え
監査モードでログを確認し、「おっ、怪しいアプリだけが引っかかっていて、業務アプリは問題なく動いているな」と確認できたら、いよいよ監査モードを解除して、カーネルレベルの強制ブロック（Enforced Mode）に切り替えます。
# 【解説】監査モードのオプションを削除し、実際にカーネルレベルでブロックする強制モードにする例
Set-RuleOption -FilePath "C:\WDAC\BasePolicy.xml" -Option 3 -Delete最後に、このXMLファイルをバイナリ形式（.cip）に変換して、グループポリシー（GPO）やMDM（Intuneなど）を使ってサーバーやクライアントPCに配備します。
# 【解説】XMLポリシーをWindowsが読み込めるバイナリ形式に変換する
ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC\BasePolicy.xml" -BinaryFilePath "C:\WDAC\SiPolicy.p7b"生成された SiPolicy.p7b を所定のフォルダ（C:\Windows\System32\CodeIntegrity\ など）に配置し、再起動を行えば、あなたのサーバーはWDACによる堅牢な要塞へと生まれ変わります。
—
5. 導入時の泥臭い注意点（現場のリアル）
教科書的には上記のようにスマートに進むのですが、実際の現場では少し泥臭い苦労もあります。
1. 「社内ニッチツール」の存在
開発現場や総務部がこっそり使っている、古いフリーソフトやインハウス（自製）のスクリプトにデジタル署名が付いていないことがよくあります。これらはデフォルトでは容赦なく弾かれるため、「どのソフトを許可リストに追加するか」の棚卸し（アセット管理）が非常に重要になります。
2. 証明書の管理
自社で開発した社内製アプリを動かす場合、自社のコードサイニング証明書（デジタル署名）でアプリに署名し、その証明書をWDACの「信頼できる証明書リスト」に登録しておく必要があります。この仕組みを整えるまでは、少し手間取るかもしれません。
—
まとめ：一歩ずつ、強固なインフラを作ろう
今回は、Windows Defender Application Control (WDAC) によるカーネルレベルの保護について、身近な防犯の例えを交えながら解説しました。
- 従来のウイルス対策ソフトは「怪しい人を顔写真で弾く（ブラックリスト）」
- WDAC は「信頼できる身内以外は一切通さない（カーネルレベルのホワイトリスト）」
最初は難しく感じるかもしれませんが、まずは「監査モード」でテスト環境からスモールスタートし、徐々に適用範囲を広げていくことで、確実にお手元のサーバーの安全性を何段階も引き上げることができます。
セキュリティの向上は、一日にして成らず。焦らず、一歩ずつ、安全で強いインフラを作っていきましょう！それでは、また次の技術解説でお会いしましょう。
コメント