Windows UACの極限最適化：管理者権限の濫用を防ぐ防衛アーキテクチャ
インフラの要塞化において、多くのエンジニアが「不要サービスの停止」や「ファイアウォールの厳格化」といった境界防御に注力する一方で、内部犯行や初期侵入後の権限昇格（Privilege Escalation）という現実的な脅威に対して無防備なケースが後を絶たない。特にWindows環境におけるユーザーアカウント制御（UAC: User Account Control）をデフォルトのまま放置している現場は、攻撃者に「どうぞ管理者権限を自由にお使いください」と言っているようなものだ。
最高峰のセキュリティアーキテクトとして断言する。UACは単なる「邪魔なポップアップが出る鬱陶しい機能」ではない。これは、最小権限の原則（Principle of Least Privilege）をOSのカーネルレベルで強制するための、極めて強力な防衛レイヤーである。本稿では、UACの内部挙動の深部から、攻撃者が用いるバイパス手法、そしてインフラ全体で適用すべき最強のハードニング設定までを徹底的に解説する。
—
1. UACの低レイヤメカニズム：なぜデフォルト設定では不十分なのか
UACの本質を理解するには、Windowsがプロセス起動時に割り当てるアクセストークン（Access Token）の挙動を知る必要がある。
ユーザーが管理者グループに所属している場合、通常のプロセスは「制限された管理者トークン（Filtered Token）」で動作する。このトークンには、システムに対する完全な管理権限は含まれていない。しかし、アプリケーションが「管理者として実行（Run as administrator）」を要求するか、マニフェストファイルに requireAdministrator が指定されると、Windowsは consent.exe（または secure desktop）を介してユーザーに昇格の同意を求め、完全な管理者トークン（Elevated Token）を生成・付与する。
デフォルト設定の致命的な盲点
Windowsのデフォルト（「通知するが、アプリがコンピューターを変更しようとしている場合のみ」）では、Windowsの標準コンポーネントや署名済みバイナリが確認なしに自動昇格する挙動が存在する。
攻撃者は、この「自動昇格する信頼されたバイナリ（Auto-elevation binaries）」の脆弱性や、DLLハイジャック、環境変数の汚染を利用して、ユーザーに気づかれることなく最高権限（NT AUTHORITY\SYSTEM 相当）へと昇格する。これが、ランサムウェアやAPT攻撃における典型的な権限昇格のシナリオだ。
—
2. UACポリシーの極限強化：レジストリによるゼロトラスト・ハーデニング
真にセキュアな環境を構築するためには、UACの動作モードを「常に通知（Always notify）」に変更し、自動昇格の余地を完全に排除する必要がある。さらに、管理者のリモート接続時における挙動（Local Account Filter Policy等）も厳格に統制しなければならない。
以下のレジストリ設定（グループポリシーのバックエンド）を適用し、OSレベルで権限昇格の挙動を完全にロックダウンする。
推奨レジストリ設定（PowerShellによる一括適用スクリプト）
インフラの自動化パイプラインやGPO（グループポリシーオブジェクト）のベースラインとして、以下のスクリプトを適用せよ。
<#
.SYNOPSIS
Windows UAC Hardening Script for Enterprise Infrastructure
.DESCRIPTION
最小権限の原則に基づき、UACの挙動を最高セキュリティレベルに引き上げる。
.NOTES
要管理者権限。適用後はシステムの再起動またはポリシーの強制適用が必要。
#>
# 1. 昇格プロンプトの動作を「管理者のみ常に通知 (Always Notify)」に変更
# (ConsentPromptBehaviorAdmin = 2: 管理者用プロンプトでセキュアデスクトップを使用し、常に確認)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "ConsentPromptBehaviorAdmin" -Value 2
# 2. 標準ユーザーの昇格動作を「資格情報の入力を要求する」に変更
# (ConsentPromptBehaviorUser = 0: 標準ユーザーには資格情報の入力を拒否、またはプロンプト表示)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "ConsentPromptBehaviorUser" -Value 1
# 3. 署名されていないバイナリの自動昇格を禁止（暗黙の昇格経路を断つ）
# (EnableInstallerDetection = 0: インストーラー検出の無効化、または厳格化)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "EnableInstallerDetection" -Value 0
# 4. すべての管理者権限昇格時にセキュアデスクトップ（画面が暗転し、他のプロセスから隔離された領域）を使用する
# (PromptOnSecureDesktop = 1: 有効。画面キャプチャやUIオートメーションによるキーロギングを防ぐ)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "PromptOnSecureDesktop" -Value 1
# 5. ローカルアカウントのフィルターポリシーを有効化 (LocalAccountTokenFilterPolicy = 0)
# リモートからのNTLM認証時にビルトイン管理者アカウントの制限を維持する
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "LocalAccountTokenFilterPolicy" -Value 0
Write-Output "UACのハードニング設定が正常に適用されました。システムの再起動を推奨します。"—
3. 運用レイヤーの鉄則：なぜ「標準ユーザー運用」が必須なのか
どれほどレジストリでUACを締め上げようとも、日々の運用を行うオペレーターや開発者が「常に管理者権限を持つユーザーアカウント（Administratorまたはそれに類するグループ）」でログインしていれば、セキュリティモデルは砂上の楼閣と化す。
実戦的なインシデントレスポンスの現場において、フィッシングメールやブラウザのゼロデイ脆弱性を踏み台にした初期侵入の多くは、「実行しているユーザーの権限の範囲内」で被害を拡大させる。もしユーザーが管理者であれば、マルウェアは一撃でEDR（Endpoint Detection and Response）のセンサーを無効化し、LSASSプロセスからメモリ上の資格情報（Kerberosチケットや平文パスワード）をダンプすることが可能になる。
チーフエンジニアが守るべき3つの実務ルール
1. 日常業務は「標準ユーザー（Standard User）」で行う
メールの閲覧、ブラウジング、チャットツール、ドキュメント作成などの日次業務は、一切の管理者権限を持たないアカウントで遂行させる。
2. 昇格は「必要な瞬間・最小限のプロセス」に限定する
アプリケーションのインストールやシステム設定の変更など、どうしても管理者権限が必要な場合は、runas コマンドや一時的な管理者資格情報の入力（セキュアデスクトップ経由）を強制する。永続的な管理者セッションを絶対に放置しない。
3. 開発・検証環境（Dev/Test）でも例外を認めない
「開発効率が落ちる」という現場の甘えを断固として排除せよ。コンテナ技術や仮想化レイヤーが発達した現代において、ホストOSの管理者権限を日常的に保持する正当な理由は存在しない。
—
4. 監査と検証：設定が正しく機能しているかの確認
ハードニングを施した後は、必ず攻撃者の視点（Red Team Perspective）に立った監査を実施し、設定がバイパスされないことを検証しなければならない。
PowerShellコンソールを標準ユーザー権限で開き、以下のコマンドを実行して現在のアクセストークンの整合性レベル（Integrity Level）を確認せよ。
# 現在のプロセスのトークン整合性レベルを確認する
whoami /groups | Select-String "Mandatory Label"- 出力が
High Mandatory Levelの場合： 現在のシェルはすでに昇格しており、危険な状態である（標準ユーザーで実行し直すこと）。 - 出力が
Medium Mandatory Levelの場合： 正常に制限されたトークンで動作している。
もしマルウェアや不正なスクリプトがこの「Medium」のコンテキストから「High」へ勝手にジャンプしようとした際、本稿で設定した厳格なUACポリシーが機能していれば、必ずセキュアデスクトップ上でユーザーの明示的な許可（または資格情報の入力）が要求されるか、完全にブロックされるはずだ。
セキュリティとは、利便性との妥協の歴史ではない。境界が曖昧になった現代のITインフラにおいて、デバイスの根底を守る最後の砦は「誰が、どの権限でコードを実行しているか」という厳格な統制にほかならない。今すぐ手元の環境のUACポリシーを見直し、脆弱性の芽を断ち切れ。
コメント