認証の「遺物」を葬る：NTLM排除によるActive Directoryの要塞化とKerberos強制の深層
ネットワークセキュリティの現場で、依然として「レガシーの呪縛」に苦しんでいるアーキテクトは多いはずだ。今日のテーマは、Windows認証の心臓部における「NTLM」の追放、そしてKerberosへの完全移行である。
多くの組織が、未だにWindows Server 2003時代から続く認証プロトコル、NTLM (NT LAN Manager) に依存している。だが、これはもはや「脆弱性の温床」という言葉では生ぬるい。NTLMは設計の段階で、パスワードハッシュを直接チャレンジ・レスポンス認証に利用する構造的欠陥を抱えており、中間者攻撃（MitM）による「リレー攻撃」に対して無防備だ。
我々が守るべきインフラにおいて、NTLMを放置することは、鍵をかけ忘れた金庫を街中に放置するのと同義である。
なぜNTLMは「即刻排除」されるべきなのか
NTLMが抱える根本的な問題は、認証サーバー（ドメインコントローラー）の認証プロセスにおいて、クライアントが自身の資格情報を直接証明するのではなく、ハッシュ化された資格情報をネットワーク上に流す点にある。攻撃者は、Responderのようなツールを用いてこのハッシュを傍受し、それを別のサーバーへ「リレー」するだけで、特権昇格や横展開（Lateral Movement）を容易に達成できる。
対してKerberosは、チケットベースの認証だ。KDC（Key Distribution Center）を介して発行されるチケット（TGT/TGS）を利用するため、パスワード自体やそのハッシュがネットワーク上に直接露出することは（正しく運用されていれば）ない。
レジストリによるNTLM無効化の技術的実装
現場でこの移行を進める際、いきなり全てを遮断すると、古いアプリケーションやサービスが共倒れするリスクがある。まずは「監査」から入り、次に「制限」、最後に「無効化」というフェーズを踏むのが鉄則だ。
以下のレジストリ設定は、認証の制御を司る LsaLmCompatibilityLevel を最適化し、NTLMの使用を制限するためのアーキテクチャ設計だ。
# 警告: 実行前に必ずドメイン環境での検証を実施すること。
# NTLMを無効化する前に、どのサービスがNTLMを要求しているかをイベントログ(ID 4624等)で特定せも。
# 1. NTLM認証の制限レベルを「NTLMv2のみ送信、LM拒否」以上に設定
# 5: NTLMv2 のみを送信し、LM と NTLM を拒否する (クライアント側)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel" -Value 5
# 2. ネットワーク認証におけるNTLMの使用を無効化
# 1: ネットワーク認証でNTLMを拒否
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "RestrictSendingNTLMTraffic" -Value 1
# 3. サーバー側でのNTLM認証を拒否する設定
# 2: ドメイン内でのすべてのNTLM認証を拒否
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "RestrictReceivingNTLMTraffic" -Value 2アーキテクトの視点：なぜ「完全移行」が難しいのか
技術的にレジストリを書き換えるのは容易だが、現実はそう甘くない。多くのレガシーアプリケーションは、ハードコードされた認証ロジックでNTLMを要求してくる。
ここで重要になるのが、「ガードレイルとしての認証ポリシー」だ。単に無効化するのではなく、以下の観点で監査環境を整える必要がある。
1. SPN (Service Principal Name) の正確なマッピング: Kerberos認証が失敗する原因の多くは、ホスト名とサービス名の不一致だ。setspn -L <ユーザー名> で確認し、重複や欠落を徹底的に排除せよ。
2. AES暗号化の強制: Kerberosを利用する際、古いDESやRC4暗号化が許可されていると、攻撃者は「Kerberoasting」によってチケットをオフライン解析する。ドメインのプロパティで「AES 128/256ビット暗号化をサポートする」をチェックし、古い暗号スイートを廃止するポリシーを適用すること。
3. PAC (Privilege Attribute Certificate) の検証: Kerberosチケットに含まれるPACの改ざんを検知するために、Kerberos Armoring (FAST: Flexible Authentication Secure Tunneling) を有効化し、認証チャネルを保護せよ。
次世代への備え：耐量子暗号と認証の未来
現在、我々が守っているKerberosも、将来的な耐量子コンピューティングの脅威に晒されることは避けられない。現在、Microsoftや関連コミュニティでは、認証フレームワーク自体をより強固なものへ移行する動きがある。
将来的なガードレイルの設計において、我々が注力すべきは、個々のプロトコルへの固執ではなく、「認証プロトコルの抽象化」だ。IDaaS（Identity as a Service）を活用したモダン認証（OAuth 2.0 / OIDC / FIDO2）へ、オンプレミスのレガシー環境をいかに橋渡しするか。それが現代のセキュリティアーキテクトに課せられた、最も難解な課題である。
結びに代えて
「設定すれば終わり」というセキュリティは、この業界には存在しない。NTLMの無効化は、あくまで攻撃者の土俵を狭めるための第一歩だ。泥臭いインフラの掃除を厭わず、ログを読み解き、静かに、しかし確実にレガシーを削ぎ落としていく。その積み重ねこそが、最高峰のホワイトハッカーが築く堅牢な要塞の礎となる。
君たちが守るべき環境は、君たちの技術的潔癖さによってのみ守られる。次のデプロイメントで、まずは監査モードから始めてみてほしい。システムが悲鳴を上げる場所こそが、君たちが次に潰すべき脆弱性の場所だ。
コメント