【ITニュース解説】Planning Active Directory Protected Users membership and operational exceptions

Active DirectoryのProtected Usersグループは、システムエンジニアを目指す皆さんにとって、セキュリティを深く理解するために重要な概念の一つだ。このグループは、組織内のユーザーアカウントやサービスアカウントのセキュリティを強化し、特に「資格情報の盗難」から保護することを目指している。しかし、その強力な保護機能ゆえに、導入には慎重な計画と徹底した準備が欠かせない。

Protected Usersグループにアカウントを追加すると、そのアカウントは対応するホストやドメインコントローラー上で、構成変更不可能な厳格な保護を受けるようになる。これは、単に設定をオンにするような簡単な話ではない。一度アカウントがこのグループに入ると、たとえ管理者であっても、そのアカウントに対する制限を個別に緩和したり無効にしたりすることはできない。この点が、他のセキュリティ設定とは大きく異なる特徴だ。

具体的にどのような保護が適用されるのかというと、主に三つの主要な制限がある。一つ目は、認証情報がデバイスにキャッシュされるのを防ぐことだ。これにより、もしデバイスが侵害されたとしても、そこにユーザーの認証情報が残っていないため、攻撃者がそれを盗み出すことを困難にする。二つ目は、NTLM、Digest、CredSSPといった古い認証プロトコルを使ったデフォルトの資格情報委任をブロックすることだ。これらのプロトコルはセキュリティ上の脆弱性を持つ可能性があり、最新の認証方法への移行を促す。三つ目は、Kerberos認証において、より新しい、より堅牢な暗号化タイプのみを使用するように制限することだ。これはRC4やDESのような古い、脆弱性が指摘されている暗号化の使用を禁止し、セキュリティレベルを高める。これらの制限は、攻撃者が認証情報を傍受したり、盗んだり、再利用したりするのを防ぐ上で非常に効果的だ。

このようにProtected Usersグループは強力なセキュリティ機能を提供するが、その導入は単なるセキュリティ強化策にとどまらず、システム全体の「互換性」に関わる重要な判断となる。なぜなら、NTLM認証を必要とする古いサービス、レガシーなKerberos暗号化タイプに依存するアプリケーション、あるいは認証情報のキャッシュが必要なシステムなどが、Protected Usersグループに属するアカウントでは正常に動作しなくなる可能性があるからだ。そのため、不用意に導入を進めると、システム障害を引き起こし、善意のセキュリティ強化策が緊急のロールバック（元に戻す作業）を必要とする事態に発展しかねない。

このリスクを回避し、安全にProtected Usersグループを導入するためには、綿密な計画と準備が不可欠だ。

まず、どのID（アカウント）をこのグループに入れるべきかを適切に見極めることが重要だ。最も強力な候補となるのは、攻撃者にとってその資格情報が非常に価値のある、高い特権を持つ対話型アカウントだ。例えば、ドメイン管理者や、重要なサーバーのローカル管理者アカウントなどがこれに該当する。Microsoftのガイダンスでも強調されているが、ドメインコントローラー側の制限は、そのドメインの機能レベルに依存するため、ポリシーを他の環境から安易にコピーするのではなく、現在のドメイン環境を注意深く検証する必要がある。また、このグループをサービスアカウントの設計に対する「安易な解決策」として使用してはならない。サービスアカウントは本来、その役割と認証プロトコル、所有者が明確に文書化されているべきだ。もし、あるワークロードアカウントがNTLMやサポートされていない暗号化タイプを必要とするのであれば、それはProtected Usersグループで解決する問題ではなく、その依存関係自体を修正する別のプロジェクトとして取り組むべき課題だ。Protected Usersグループは、互換性のないアプリケーションを無理やり互換性を持たせるための仕組みではないことを理解しておく必要がある。

次に、このグループを適用する前に、徹底した「監査」を行うことが極めて重要だ。まずは、イベントログや認証ログを収集し、既存のシステムがどのように認証を行っているかのインベントリ（棚卸し）から始める。特に、パイロット対象となるアカウントに関連する認証失敗の記録、NTLM認証の使用状況、Kerberos認証におけるRC4やDESといった古い暗号化タイプの使用状況、そして認証の委任パスに注意して確認する。Microsoftは、Protected Usersグループに関連する障害を特定するのに役立つ運用イベントログを公開しているため、これらを参考にログを収集し、タイムスタンプやアカウント識別子とアプリケーションエラーを正確に紐付けられるように、ログを一元的に収集・管理することが望ましい。

監査を通じてリスクが特定できたら、いよいよ「パイロットテスト」だ。最初は非常に小規模な範囲から始めるべきで、例えば一つのプラットフォームと一つのアカウントタイプに限定してテストを行う。このテストでは、対話型サインイン、リモート管理、パスワード変更、Kerberosチケットの取得、そして必要とされる認証の委任といった、そのアカウントが通常行うすべての操作を網羅的に確認する。単にサーバーにコンソールログオンが成功しただけでは十分ではない。サービスチケットの取得、スケジュールされたタスクの実行、各種管理ツールの動作なども含め、そのIDでサポートされるすべてのワークフローが問題なく動作することを確認するまで、テスト範囲を拡大してはならない。

万が一、問題が発生した場合に備えて、「回復パス」を確保しておくことも忘れてはならない。Protected Usersグループの制限は構成変更不可能なため、唯一の回復策は、問題のアカウントをグループから削除することだ。そのため、日常の自動化プロセスから切り離され、厳重に資格情報が保護された「ブレイクグラスアカウント」（緊急時用の管理者アカウント）を事前に準備し、その操作手順も明確にテストしておく必要がある。特定のアプリケーションとの互換性の問題が発生したからといって、ドメイン全体のセキュリティポリシーを緩和するような安易な対応は避けるべきだ。グループのメンバーシップ変更、その承認プロセス、パイロットテストの証拠、例外の所有者、そして詳細なロールバック手順は必ず記録に残しておく。また、Protected Usersグループのメンバーは定期的に見直し、もはや高い特権を必要としないアカウントや、非アクティブになったアカウントは速やかにグループから削除することで、セキュリティ価値を最大限に維持できる。このグループの真のセキュリティ価値は、メンバーの数を少なく、常に最新の状態に保つことによって得られる。

最後に、Protected Usersグループの保護が「どこまで適用されるのか」という境界を正確に理解し、検証することも不可欠だ。グループに属するアカウントは、オペレーティングシステムとドメインの構成がこれらの制御をサポートしている場合にのみ保護される。どのホストとドメインコントローラーがこれらの保護制御を適用するかを明確に文書化しておく必要がある。もし、重要なシステムがサポートされる境界外にある場合、そのシステムを修正して保護対象に含めるか、あるいはそのシステムに別の認証アカウント設計を適用することを検討すべきだ。プラットフォームの対応状況を確認せずに「このアカウントは保護されている」と報告するのは、その制御の有効性を過大評価することになりかねない。

これらの計画と検証を怠ると、セキュリティ強化を目指したはずが、かえって運用の混乱やシステム停止を招くことになりかねない。システムエンジニアとして、セキュリティ強化と運用の安定性を両立させるための深い理解と慎重なアプローチが求められる。