Active Directoryセキュリティの基礎。侵入後の横展開を止める防御設計

オンプレミスのActive Directory(以下AD)は、社内の認証と認可を一手に引き受ける仕組みです。だからこそ、外部公開機器やメールから入り込んだ攻撃者は、最終的にドメイン管理者権限を目指して社内を横に移動します。この記事は、個別の攻撃手法を並べるのではなく、ADという基盤そのものをどう設計すれば横展開と権限昇格が止まるのかを、管理階層、特権アカウント、Kerberos設定、監査ログ、復旧の順に整理します。

想定読者は、オンプレミスADを実際に運用する情報システム担当とインフラエンジニアです。記述はMicrosoft Learnの現行ドキュメント、ASD's ACSCとCISAほかによる共同ガイダンス、JPCERT/CCの公開資料で確認できた範囲に限り、確認できなかった数値や仕様は書きません。特定製品の推奨はしません。

先に、この記事で扱う防御層と、それぞれが止める動きを一覧にします。

オンプレミスADが侵入後の目的地になる理由#

ADは、利用者と端末とサーバの認証を一箇所に集約します。集約されているということは、そこを取れば配下のすべてに手が届くということでもあります。カナダのCyber Centreは共同ガイダンスの紹介で、ADについて「脅威アクターにとって価値ある標的であり、侵害されればADが管理するすべてのシステムと利用者への特権アクセスを得られる」と述べています。

Microsoftの「Best practices for securing Active Directory」も、資格情報窃取の標的になりやすいアカウントとして、常時特権を持つアカウント、VIPアカウント、ADに特権が紐づくアカウント、ドメインコントローラ(DC)、そしてPKIサーバやシステム管理サーバのようにID管理とアクセス管理と構成管理に影響する基盤サービスを挙げています。あわせて、特権アカウントで保護されていない端末にサインインすること、特権アカウントのままインターネットを閲覧することを、リスクを高める行動として名指ししています。

JPCERT/CCの「ログを活用したActive Directoryに対する攻撃の検知と対策」(1.2版、2017年7月28日)は、同センターが対応支援した被害組織のほとんどでドメイン管理者アカウントが悪用されていたと報告しています。ドメイン管理者アカウントが横断的侵害の要になるという構図は、いまのガイダンスとも一致します。

ASD's ACSC、CISA、NSA、CCCS、NCSC-UK、NCSC-NZの6機関は、2024年9月に共同ガイダンス「Detecting and Mitigating Active Directory Compromises」を公開し、代表的な17種類の手法を整理しました。内訳は、Kerberoasting、AS-REP roasting、パスワードスプレー、MachineAccountQuota、制約なし委任、グループポリシー環境設定に残るパスワード、AD CSの侵害、Golden Certificate、DCSync、ntds.ditの持ち出し、Golden Ticket、Silver Ticket、Golden SAML、Microsoft Entra Connectの侵害、一方向の信頼関係の迂回、SID Historyの悪用、Skeleton Keyです。防御設計は、この17種類のどれが自社で成立してしまうのかを潰していく作業だと捉えると進めやすくなります。

このうちKerberoastingは、サービスアカウントの弱いパスワードをオフラインで解析する手口として単独で扱う価値があるため、別記事で成立条件と検知まで整理しています。

あわせて読みたい

Kerberoastingとは何か。サービスアカウントの弱いパスワードが狙われる仕組みと対策

Enterprise Access ModelとAD DS Tierモデルの現在地#

管理階層の話をするとき、古い「レガシーTierモデル」と現行の「Enterprise Access Model」がどういう関係にあるのかで混乱が起きます。Microsoft Learnの記述は明快です。「Enterprise access modelはADティアモデルの上に構築される」とあり、そのうえで、現代の企業がオンプレミスと複数のクラウドと内外の利用者アクセスにまたがることをふまえ、アクセス管理の要件を丸ごと取り込んだものだと説明されています。

対応関係は次のとおりです。Tier 0は範囲が広がってコントロールプレーンになり、レガシーOTのようにネットワーク制御が唯一または最良の手段となる領域まで含めてアクセス制御を扱います。Tier 1は2つに分かれ、全社的なIT管理機能を担う管理プレーンと、ワークロードごとの管理を担うデータ/ワークロードプレーンになりました。Tier 2も2つに分かれ、B2BとB2Cと公開シナリオを含む利用者アクセスと、API経路を扱うアプリアクセスになっています。

一方で、AD DSに閉じた話としてのTierモデルも現役です。Microsoft Learnの「AD DS Tier Model」ページは、TierモデルをEnterprise Access Modelの構成要素と位置づけ、AD DSとその近傍の依存関係について、不正な権限昇格を防ぎ管理階層を強制するための主要な手段だと説明しています。同ページのTier区分は次のとおりです。

同ページが繰り返し強調しているのは、境界を決めるのはネットワークではないという点です。「封じ込めが境界であり、境界防御ではありません。ネットワーク分割はモデルを支えますが、置き換えはしません。Tierを決めるのは資格情報とキーボードであり、IPアドレスではありません」と書かれています。この原則から、ジャンプサーバの扱いも自動的に決まります。DCへ到達するために使うジャンプサーバは、ネットワーク上は境界セグメントに置かれていてもTier 0資産です。触れた資格情報の信頼レベルを、そのまま引き受けるからです。

ネットワーク分割そのものの考え方は別記事で扱っています。Tier分離と組み合わせると効きが変わります。

あわせて読みたい

ネットワークセグメンテーションで侵入後の被害を広げない設計

Tier 0を小さく保つための線引き#

同ページはTier 0を「できるだけ小さく保て」と明言し、アカウントもサーバもアプリケーションも、1つ増えるたびにIDコントロールプレーンの攻撃面が広がると説明しています。具体的な目安として、ドメイン管理者相当のアクセスを持つ人間を5人未満にすること、ドメイン管理者のサービスアカウントを置かないことが挙げられています。

崩れやすいパターンも列挙されています。すべてをTier 0に押し込めてTier 0を薄めてしまうこと、ドメイン管理者相当のアカウントで日常業務を行うこと、監視やバックアップやEDRのエージェントにドメイン管理者権限を与えること、Tier 0とTier 1でサービスアカウントを共有すること、そしてジャンプサーバを別のTierとして扱うことです。3つ目は見落としやすく、Tier 1やTier 2のホスト上でTier 0権限のエージェントが動いていれば、そのホストがIDコントロールプレーンへの資格情報露出点になります。

管理端末についても要件が明示されています。TierごとにPAW(特権アクセスワークステーション)を用意し、Tier 0の作業はTier 0のPAWから始めます。同ページは「上位Tierの資格情報を下位Tierのワークステーションで入力した時点で、その資格情報は低信頼の環境に露出します。宛先ではなくキーボードが、セッションの実効的な信頼レベルを決めます」と書いています。PAWは管理専用とし、メールやWeb閲覧や未管理ソフトウェアを載せません。

最小権限の考え方そのものは、ADに限らず共通します。役割設計から入る場合はこちらもあわせて確認してください。

あわせて読みたい

最小権限の原則（Least Privilege）。なぜ権限を絞ることが最強の防御の一つなのか

特権アカウントを守る3つの仕組み#

特権アカウントの保護には、ADの標準機能で組める打ち手が3つあります。

1つ目がProtected Usersグループです。Microsoft Learnによれば、これはグローバルセキュリティグループ(RID 525)で、メンバーがサインインしたときに資格情報がキャッシュされないよう、設定変更できない保護を端末側とDC側の両方で発動させます。端末側では、CredSSPによる資格情報委任が平文の資格情報をキャッシュしなくなり、Windows Digestも平文をキャッシュせず、NTLMは平文もNTOWFもキャッシュしなくなります。KerberosはDESとRC4の鍵を作らず、初回のTGT取得後は平文や長期鍵をキャッシュしません。キャッシュされた検証子も作られないため、そのメンバーはオフラインでのサインインができなくなります。

DC側では、NTLM認証ができなくなり、Kerberosの事前認証でDESとRC4が使えなくなり、制約付きと制約なしのどちらの委任も行えず、TGTを初期の4時間を超えて更新できなくなります。この4時間(240分)は固定値で、ドメインのチケット有効期間ポリシーより優先されます。前提条件は、ホストがWindows 10/11またはWindows Server 2012 R2以降で最新のセキュリティ更新が適用済みであること、ドメインの機能レベルがWindows Server 2012 R2以降であることです。

同ページは注意も強く書いています。サービスとコンピュータのアカウントは決して追加してはいけません。パスワードや証明書がホスト上に常在するため、ローカル側の保護が得られないからです。Enterprise AdminsやDomain Adminsのような高特権グループのメンバーも、悪影響がないと確認できるまで追加しません。高特権の利用者も同じ制限を受け、回避や変更はできないため、一括で追加するとロックアウトを招く可能性があります。AESの鍵がない古いアカウントは認証できなくなるため、移行してきたアカウントは事前にパスワードをリセットしておきます。

2つ目が認証ポリシーサイロです。Windows Server 2012 R2で導入された機能で、利用者アカウントとコンピュータアカウントとサービスアカウントを入れるコンテナとして働き、そこに適用した認証ポリシーで、その特権アカウントをドメイン内のどこで使えるかを制限できます。高価値のアカウントを高価値のホストだけに縛る手段として、Protected Usersと組み合わせて使います。なお、ビルトインのドメインAdministrator(RID 500)は、サイロに割り当てても認証ポリシーの対象外である点は仕様として押さえておきます。

3つ目がWindows LAPSです。Microsoft Entra参加またはWindows Server AD参加の端末について、ローカル管理者アカウントのパスワードを自動で管理しバックアップします。DCについては、ディレクトリサービス復元モード(DSRM)アカウントのパスワードも管理できます。Microsoftが挙げる効果は、pass-the-hashと水平移動への対策、リモートのヘルプデスク運用のセキュリティ向上、到達できなくなった端末の回復です。旧来のMicrosoft LAPS製品はWindows 11 23H2以降で非推奨となり、新しいOSではMSIのインストールがブロックされています。現行のWindows LAPSはWindows Server 2019以降とサポート対象のWindows 10/11で利用でき、ADへのパスワード保存には追加のライセンス要件がありません。

アカウントの棚卸しと退職者処理が回っていないと、これらの仕組みは効きません。ライフサイクル管理の実務はこちらで整理しています。

あわせて読みたい

入社から退職までアカウントを人事イベントに同期させる運用の作り方

Kerberos周りでふさげる穴#

Kerberos側の設定は、暗号タイプとチケットの信頼の2軸で見ます。

暗号タイプは、AESへ寄せるほど攻撃側のオフライン解析コストが上がります。MicrosoftはCVE-2022-37966への対応として、2022年11月8日以降のWindows Updateで、暗号タイプが明示されていないアカウントについてKerberosの既定をRC4からAES-SHA1へ変更しました。さらに現行のドキュメントは、AD DCの既定で想定される暗号タイプとしてのRC4の利用を、2026年第2四半期末までに無効化する計画だと明記しています。Windows Server 2025のDCはRC4のTGTを発行しません。自社の状況は、DC上のイベントID 4768と4769に追加されたMSDS-SupportedEncryptionTypesとAvailable KeysとAdvertized Etypesのフィールドで確認できます。MicrosoftはList-AccountKeys.ps1とGet-KerbEncryptionUsage.ps1という2本のPowerShellスクリプトをGitHubで公開しており、監査の起点として使えます。

チケットの信頼の根はkrbtgtアカウントです。この鍵が漏れるとTGTを偽造できるため、Microsoftのフォレストリカバリ手順にはパスワードリセットの項が独立して置かれています。手順の要点は2つです。1つは、指定したパスワード文字列に意味はなく、システムが独立に強いパスワードを生成すること。もう1つは、この操作を2回行い、リセットの間に10時間以上あけることです。10時間という数字は、既定の「ユーザーチケットの最長有効期間」と「サービスチケットの最長有効期間」に由来し、この値を変更している環境では、設定値より長く待つ必要があります。2回必要な理由も明記されています。krbtgtのパスワード履歴は2件で、2回リセットして初めて古いパスワードが履歴から消え、古い鍵で別のDCと複製される余地がなくなるためです。読み取り専用DC(RODC)を復旧対象に含める場合は、krbtgt_数字形式のRODC用krbtgtアカウントを削除しない点にも注意が要ります。

委任の設定も棚卸しの対象です。共同ガイダンスの17手法には制約なし委任が含まれています。Protected Usersのメンバーは制約付きと制約なしのどちらの委任も行えなくなるため、特権アカウント側から先に縛る進め方が取れます。サービスアカウントについては、Windows Server 2025で導入されたdMSA(委任管理サービスアカウント)が選択肢に加わりました。Microsoftはこれを、従来のサービスアカウントから、鍵が完全にランダム化され管理されるマシンアカウントへ移行し、元のサービスアカウントのパスワードを無効化する仕組みだと説明しています。dMSAの秘密はDC以外の場所から取得できず、Kerberoastingのような侵害済みアカウントを使った資格情報収集の防止に役立つとされています。ただし移行には制約があり、既存のマネージドサービスアカウントやgMSAからは移行できず、対応していないマシンが残っていると移行完了時に認証が失敗します。

コンピュータアカウントの作成数を制御するms-DS-MachineAccountQuotaも見ておきます。Microsoftのスキーマ定義では「利用者がドメイン内で作成を許されるコンピュータアカウントの数」で、更新にはドメイン管理者権限が要ります。共同ガイダンスがMachineAccountQuotaを17手法の1つに数えている以上、一般利用者が端末をドメイン参加させる必要のない環境では、現在値を確認して絞る判断が要ります。

AdminSDHolderとレプリケーション権限の管理#

ディレクトリのACL側にも、押さえるべき点が2つあります。

1つ目がAdminSDHolderです。Microsoft Learnの説明では、ADには保護対象として扱われる既定のアカウントとグループがあり、Account Operators、Administrator、Administrators、Backup Operators、Domain Admins、Domain Controllers、Enterprise Admins、Enterprise Key Admins、Key Admins、Krbtgt、Print Operators、Read-only Domain Controllers、Replicator、Schema Admins、Server Operatorsが含まれます。AdminSDHolderオブジェクトは、これら保護対象のアクセス許可のテンプレートを提供します。SDPropという処理が、既定で60分ごとにPDCエミュレータを保持するDC上で動き、AdminSDHolderのアクセス許可と保護対象のアクセス許可を比較し、食い違っていれば元に戻します。保護対象では継承が無効化されるため、別のOUへ移動しても新しい親の許可を継いだりはしません。裏を返せば、AdminSDHolder自体を書き換えられると、保護対象すべてに攻撃者のACEが撒かれます。監視の優先度が高いオブジェクトです。

2つ目がレプリケーション権限です。DCSyncは、DCになりすまして資格情報を複製させる手法で、共同ガイダンスの17手法に含まれます。ここで効くのがディレクトリ変更のレプリケート権限です。Microsoftのサポート文書は「Replicating Directory Changes」をドメイン命名コンテキストごとに設定されるACEだと説明し、ADの管理者権限を持たないアカウントにこの権限を明示的に付与する手順を示しています。運用の含意は単純で、この権限を持つアカウントがDC以外にどれだけいるかを棚卸しし、必要性を説明できないものを外すことです。ディレクトリ同期製品の導入時に付与したまま放置されている例は珍しくありません。

監査ログで残すものと見るもの#

監査は、取得の設定と確認の運用が揃って初めて機能します。

取得側では、MicrosoftのSystem Audit Policy recommendationsが、サーバ向けの推奨として次を挙げています。DS Accessカテゴリでは、Audit Directory Service AccessとAudit Directory Service ChangesをDCで成功と失敗の両方有効にすること。Account Managementでは、Audit Security Group ManagementとAudit User Account ManagementとAudit Other Account Management Eventsを成功と失敗で有効にすること。より強い推奨には、Account LogonカテゴリのAudit Kerberos Authentication ServiceとAudit Kerberos Service Ticket Operationsが加わります。同ページは、DCやサーバだけを見て端末を外すのはよくある見落としで、悪意ある活動の最初の兆候はワークステーションに現れることが多いとも指摘しています。

確認側では、イベントIDごとの意味を取り違えないことが前提になります。Microsoftの「Appendix L: Events to Monitor」は各イベントに深刻度を付けており、高いものは1件でも調査すべきだとしています。

深刻度がLowであることは、見なくてよいという意味ではありません。同ページは、LowやMediumのイベントは想定外に発生したときや、計測期間の基準値を大きく超えたときに調査するものだと定義しています。たとえば4964は、DC以外の端末へドメイン管理者がサインインすることを禁じている環境なら、1件の発生で警報を上げられる作りになっています。

4662は使い方に癖があります。Microsoftの解説によれば、このイベントはADオブジェクトに対して操作が行われるたびに発生しますが、対象オブジェクトにSACLが設定されていて、その操作がSACLに合致する場合にしか記録されません。同ページは監視対象の例として、CN=AdminSDHolder,CN=System,DC=domain,DC=comに対するすべての操作試行を挙げ、アクセス種別のうちWrite PropertyとControl AccessとDELETEとWRITE_DACとWRITE_OWNERを重要なものとして示しています。AdminSDHolderの改ざんを拾う導線は、ここに用意されています。

4769については、同ページが具体的な監視条件を並べています。クライアントアドレスが社内のIP範囲でもプライベートIP範囲でもないものを追うこと。クライアントアドレスが::1のものはDC上でのローカル要求を意味するため、DCへのサインインを許可したアカウント一覧の外にある名前を監視すること。チケット暗号タイプが0x1や0x3(DES)のもの、および0x11と0x12(AES系)以外のものを監視すること。最後の条件は、そのままRC4の残存確認に使えます。

JPCERT/CCの資料は、認証ログの見方をより手順に寄せて示しています。同資料が挙げる確認の観点は3つで、どのアカウントが特権を得たか(イベントID 4672)、どの端末上で特権が使われたか(4624、4625、4768、4769、4776)、認証要求回数に急激な変化がないか、という並びです。1つ目は文字列検索で比較的容易に探せるため優先的に実施することを勧め、2つ目と3つ目は平常時との比較が要るとしています。加えて、イベントログの消去(1102)と不審なタスク作成(4698)を個別に扱っており、4698や4769の失敗が既定では記録されない点にも触れています。

JPCERT/CCは2026年2月10日に、Windowsのイベントログ分析トレーニング用コンテンツを公開しました。ADに焦点を当てた基礎編と実践編で構成され、実践編では攻撃シナリオに沿ってイベントビューアでログを分析し、攻撃のタイムラインを組み立てます。手を動かして慣れる教材として使えます。

ログの取得対象と保管期間の決め方そのものは、別記事で整理しています。

あわせて読みたい

ログ管理の基本。何を・どこまで・どれだけ残すか

バックアップとフォレストリカバリの備え#

ADの防御設計は、復旧まで含めて初めて閉じます。Microsoftの「Active Directory Forest Recovery Guide」は、フォレスト全体の障害によってフォレスト内のすべてのDCが正常に機能しなくなった場合の回復手順をまとめたもので、そのまま使う手順書ではなく、自社の回復計画のテンプレートとして位置づけられています。

同ガイドの前提条件のページが求めているのは、次の3点です。第一に、Microsoftサポートと協議したうえで障害の原因を特定し、フォレスト全体の復元が最善だと結論づけていることです。同ページは、多くの場合フォレストリカバリは最後の選択肢であるべきだと明記しています。第二に、AD DSのドメイン/フォレスト復旧、オブジェクトやサブツリーの復旧、SYSVOLの復旧について、手順を文書化した回復計画を持ち、本番のバックアップを使って検証環境で試験済みであることです。手順は年次のような定期的な間隔で見直し、OSのアップグレードや構成変更にあわせて更新することが求められています。第三に、AD DSとSYSVOLのバックアップと復元を検証環境で定期的に実施していることです。

バックアップの取り方については、別のハードウェアや別のOSインスタンスへ復元できることを理由に、BMR(ベアメタル回復)バックアップが推奨されています。Windows Server Backupは既定ではインストールされないため、機能として追加したうえで「フルサーバー(推奨)」またはカスタムで「ベア メタル回復」を選びます。コマンドラインからはwbadmin start backup -allCritical -backuptarget:<ドライブ>:が使えます。BitLockerなどでボリュームを保護している場合は、回復キーのような緊急時情報を復旧作業中に参照できる状態にしておく必要があります。

侵害が疑われる状況からの復旧では、krbtgtの2回リセットが手順に組み込まれます。先述のとおり間に10時間以上あける必要があるため、その待ち時間を復旧計画のタイムラインに最初から織り込んでおくと、当日の判断が楽になります。

AD FSのような周辺のフェデレーション基盤も、Tier 0資産として同じ扱いになります。実際の脆弱性対応でどう動くかは、こちらの記事が具体例になります。

あわせて読みたい

AD FSの権限昇格ゼロデイCVE-2026-56155。7月Patch Tuesdayで悪用確認、KEV収録された認証基盤の急所

現状把握に使える確認手段#

設計を書き換える前に、現在どうなっているかを測ります。無償で始められる手段としては、まずMicrosoft純正の材料があります。RC4の利用状況は先述のPowerShellスクリプトで棚卸しでき、保護対象グループのメンバーシップとAdminSDHolderのACLはADの標準ツールで、監査ポリシーの現状はauditpolで確認できます。

第三者製のAD診断ツールも広く使われています。PingCastleは、ADとEntra IDの構成情報を収集して設定不備を採点し報告する診断ツールで、現在はNetwrixの下で公開されています。既定のライセンスでは、そこから収益を得ない限り無償で実行でき、営利組織が自社の環境を監査する用途は認められる一方、商用のパッケージやサービスに組み込む場合は別途ライセンスの購入が必要とされています。Purple KnightはSemperisが提供する無償のセキュリティ評価ツールで、AD環境をスキャンして露出や侵害の指標を洗い出し、スコアと改善の指針を返します。

いずれも第三者が提供するツールであり、Microsoftの公式ドキュメントとは位置づけが違います。実行前に、自社が管理する環境であること、収集される情報の範囲とレポートの保管先が社内規程に沿うこと、ライセンス条項の適用範囲を満たすことを確認してください。診断結果は出発点にすぎず、指摘の1件ずつを自社の運用上の必要性と突き合わせる作業は省けません。

Microsoft LearnのAD DS Tierモデルのページは、Tierモデルを「管理アイデンティティ、ワークステーション、管理対象資産を信頼の階層に分離するセキュリティアーキテクチャ」と定義し、Enterprise Access Modelの構成要素として位置づけています。設計原則として、各Tier内でも最小権限を適用すること、Tierをまたいで資格情報を共有しないこと、業務アプリのワークロードをTier 0に置かないこと、職務分離を保つこと、そして封じ込めが境界であることを挙げています。

まとめ#

ADの防御設計は、機能を1つ足して終わる話ではなく、どこからどこへ資格情報が流れうるかを線で区切る作業です。Tierの線を引き、その線をまたぐ資格情報の使い方を禁じ、線をまたいだ痕跡がログに残るようにし、線が破られた場合の戻し方を決めておく。この4つが揃うと、初期侵入が起きても、そこからドメイン管理者権限までの距離が一気に伸びます。

最初の一歩は、範囲の大きな設計変更ではなく現状把握です。ドメイン管理者相当の人数を数え、そのアカウントが直近30日にどの端末からサインインしたかをイベントログで確認するだけでも、Tierの線がどこで崩れているかが見えます。

進めるうえで押さえておきたい点を最後にまとめます。