4. ID管理とアクセス制御

ディレクトリサービスのセキュリティ徹底解説｜LDAPとActive Directoryの仕組みと脆弱性対策

2025年12月26日

企業ネットワークの基盤として、ユーザー情報やコンピュータ資産を一元管理する「ディレクトリサービス」は、現代の組織運営において欠かせない存在です。しかし、情報の集約拠点であるということは、攻撃者にとっても「そこさえ攻略すれば全権限を掌握できる」という極めて価値の高い標的であることを意味します。

特にLDAP(Lightweight Directory Access Protocol)や、それをベースとしたMicrosoftのActive Directory(AD)は、認証・認可の核心部を担っており、そのセキュリティ設定の不備は組織全体の崩壊を招きかねません。本記事では、ディレクトリサービスの基礎から、認証プロトコルの詳細、そして高度化する攻撃から認証基盤を守るための要塞化手法について解説します。

1. ディレクトリサービスとLDAPのプロトコル構造

ディレクトリサービスとは、ネットワーク上のリソース(ユーザー、グループ、プリンタ、サーバーなど)を階層構造で管理し、効率的な検索や認証を可能にするシステムです。その標準的な通信プロトコルとして広く普及しているのがLDAPです。

ディレクトリサービスの概念と階層構造(DIT)

ディレクトリサービスは、一般的なリレーショナルデータベース(RDB)とは異なり、読み取りと検索に特化した階層型のデータ構造を持っています。この構造は「DIT(Directory Information Tree)」と呼ばれ、組織の階層(国、組織、部門)に合わせたツリー形式でデータを保持します。

各データエントリーは「DN(Distinguished Name:識別名)」によって一意に特定されます。例えば、あるユーザーのDNは cn=Tanaka,ou=Sales,dc=example,dc=com のように表記され、どのドメインの、どの組織単位(OU)に属する誰であるかを明確に示します。この論理的な構造を理解することは、アクセス制御リスト(ACL)を適切に設定するための第一歩となります。

LDAPの動作モデルと主要な操作

LDAPはクライアント／サーバー型のプロトコルで、TCP/IP上で動作します(通常ポート389)。クライアントがサーバーに対してリクエストを送り、サーバーが応答を返すというシンプルな流れですが、その中には以下のような重要な操作が含まれています。

  • Bind(認証):クライアントがディレクトリサービスに接続し、認証情報を提示する操作
  • Search(検索):特定の条件に合致するエントリーを検索する操作
  • Modify(変更):既存のエントリーの属性を変更する操作
  • Add(追加):新しいエントリーをディレクトリに追加する操作
  • Delete(削除):エントリーをディレクトリから削除する操作

これらの操作を組み合わせることで、ユーザー管理やグループ管理、権限管理などの複雑な認証基盤を構築できます。

LDAPにおけるセキュリティリスクと暗号化(LDAPS)

標準のLDAP通信は暗号化されていません。パケットキャプチャを行えば、管理者のパスワードさえも容易に特定できてしまう脆弱な状態です。この問題を解決するために導入されるのが「LDAPS(LDAP over SSL/TLS)」です。

LDAPSでは、通常ポート636を使用し、TLS(Transport Layer Security)によって通信全体を保護します。また、ポート389を維持したまま、通信の途中で暗号化を開始する「STARTTLS」という拡張機能も存在します。

現代のシステム設計においては、たとえ内部ネットワークであっても、平文のLDAP利用は避け、必ずこれらの暗号化手段を講じることが鉄則となっています。内部ネットワークだからといって安全だという考えは、ラテラルムーブメント(横展開攻撃)が一般化した現代では通用しません。

2. Active DirectoryのアーキテクチャとKerberos認証

多くの企業で採用されているActive Directory(AD)は、LDAPを基盤としつつ、さらに高度な管理機能と独自の認証プロトコルを組み合わせたディレクトリサービスの実装です。

Active Directoryの管理単位と信頼関係

ADは「ドメイン」という単位でリソースを管理します。さらに複数のドメインを束ねる「ツリー」、複数のツリーを包含する「フォレスト」という階層構造を持ちます。フォレストはセキュリティの境界線となり、異なるフォレスト間でのリソース共有には「信頼関係」の設定が必要になります。

ADにおいて重要なのは「ドメインコントローラ(DC)」の役割です。DCはユーザーのログオン処理を行い、ディレクトリデータベースを保持します。DCが侵害されると、そのドメインに属する全てのユーザー、全てのコンピュータの管理権限が攻撃者に渡るため、物理的・論理的に厳重な保護が求められます。

ドメインコントローラは複数台構成が基本です。これは可用性の確保とともに、負荷分散の意味もあります。しかし、どれか一台でも侵害されれば、ドメイン全体が危険にさらされるという点を忘れてはいけません。

Kerberos認証の三者間スキーム

ADの認証において中心的な役割を果たすのが「Kerberos(ケルベロス)」プロトコルです。Kerberosは、クライアント、サーバー、そして信頼された第三者機関である「KDC(Key Distribution Center)」の三者間で認証を行います。

Kerberosの認証フローは以下の通りです。

  1. AS Request:ユーザーが認証サービス(AS)にTGTを要求
  2. AS Reply:ASがユーザー認証後、TGT(Ticket Granting Ticket)を発行
  3. TGS Request:ユーザーがTGTを使い、チケット供与サービス(TGS)にサービスチケットを要求
  4. TGS Reply:TGSがサービスチケットを発行
  5. AP Request:ユーザーがサービスチケットを提示して、目的のリソースにアクセス
  6. AP Reply:サービスがチケットを検証し、アクセスを許可

Kerberosの最大の特徴は、パスワードそのものをネットワークに流さない点です。代わりに「チケット」という概念を用います。このチケットには有効期限があり、通常は10時間程度に設定されています。この仕組みにより、パスワードの盗聴リスクを大幅に低減できます。

3. 最恐の攻撃「ゴールデンチケット」の脅威とその防御策

ここでは、Active Directory環境において「王国の鍵」を奪われるに等しい、最も恐ろしい攻撃手法の一つである「ゴールデンチケット」攻撃について詳しく解説します。

ゴールデンチケット攻撃とは何か

ゴールデンチケット攻撃とは、Kerberos認証の仕組みを悪用し、攻撃者が「偽造されたTGT(Ticket Granting Ticket)」を作成する攻撃です。

通常、TGTはドメインコントローラ(KDC)のみが作成・署名できるものですが、攻撃者がドメイン内の「krbtgt」アカウントのパスワードハッシュ(NTLMハッシュ)を窃取すると、自ら有効なTGTを偽造できるようになります。これが「ゴールデンチケット」と呼ばれる理由は、このチケットさえあれば、ドメイン内のあらゆるリソースに対して、あらゆる権限(ドメイン管理者権限など)でアクセス可能になるからです。

なぜこの攻撃は「恐ろしい」のか

ゴールデンチケット攻撃が極めて危険視される理由は、その「永続性」と「隠蔽性」にあります。

  • パスワード変更が効かない:一般ユーザーやドメイン管理者のパスワードを変更しても、ゴールデンチケットの作成には「krbtgt」のハッシュが使われるため、攻撃者は引き続きアクセス可能です
  • 有効期限を自由に設定できる:偽造チケットの有効期限を数十年先に設定することで、一度侵入を許すと半永久的にアクセス権を保持されます
  • MFAをバイパスする:Kerberosチケットそのものを提示するため、チケット提示の段階で多要素認証(MFA)を求められない設定になっている場合、検知すら困難です
  • ログに痕跡が残りにくい:正規のチケットと見分けがつきにくく、通常の認証ログでは異常を検知できません

さらに深刻なのは、攻撃者が一度krbtgtハッシュを入手すると、ドメインコントローラへの直接アクセスがなくても、オフラインでチケットを作成できる点です。つまり、ネットワークから完全に切断された状態でも攻撃準備が可能なのです。

防御の要所:krbtgtアカウントの保護

この攻撃を防ぐための「設定の急所」は、何よりも「krbtgt」アカウントのハッシュを渡さないことです。

  • krbtgtパスワードの2回リセット:万が一の侵害に備え、あるいは定期的なメンテナンスとして、krbtgtアカウントのパスワードをリセットする必要があります。Kerberosの仕様上、古いパスワードも一定期間有効であるため、「2回」リセットすることで完全に古いハッシュを無効化できます。リセット間隔は、通常のチケット有効期限(10時間)の2倍以上、最低でも24時間以上空けることが推奨されます
  • ドメインコントローラの要塞化:krbtgtハッシュはドメインコントローラにのみ存在します。物理アクセス制限、リモート管理の制限、EDR(Endpoint Detection and Response)による監視をDCに対して集中的に行うことが重要です
  • イベントログの監視:不自然に長い有効期限を持つチケットの発行や、ドメインコントローラ以外からの「チケット偽造」に関連するパケットの動きをSIEM(Security Information and Event Management)等で監視します。特にイベントID 4768、4769、4770に注目し、異常な認証パターンを検出します

シルバーチケットとの違い

ゴールデンチケットと類似した攻撃に「シルバーチケット」があります。シルバーチケットは、特定のサービスアカウントのハッシュを使って、そのサービスのみにアクセス可能なチケットを偽造する攻撃です。

ゴールデンチケットがドメイン全体への神の権限を与えるのに対し、シルバーチケットは特定サービスへの限定的なアクセスに留まります。しかし、その分検知が難しく、TGSへの問い合わせが発生しないため、ログに残る痕跡がさらに少なくなります。

4. ディレクトリサービスの要塞化と運用管理

ゴールデンチケットのような高度な攻撃を防ぐためには、個別の対策だけでなく、組織全体のディレクトリ運用を構造的に守る必要があります。

特権アクセス管理と階層化モデル(Tierモデル)

AD運用において最も効果的な防御策の一つが、管理権限の分離です。Microsoftが提唱する「Tierモデル」では、環境を3つの階層に分けます。

  • Tier 0(最上位層):ドメインコントローラ、エンタープライズ管理者、ドメイン管理者など、AD全体を管理する最高権限層
  • Tier 1(中間層):サーバー管理者、アプリケーション管理者など、サーバーインフラを管理する層
  • Tier 2(最下位層):一般ユーザーのワークステーション、標準的な業務端末を管理する層

このモデルの核心は、「Tier 0の管理者がTier 2の一般端末にログインしない」という運用です。もし管理者が一般端末にログインすると、その端末がマルウェアに感染していた場合に、メモリ上からTier 0の認証情報が窃取され、ゴールデンチケット攻撃への足掛かりにされるリスクがあるためです。

この階層化により、仮にTier 2が侵害されても、攻撃者がTier 0に到達するまでに複数の防御層を突破する必要が生じ、防御側に検知と対応の時間が生まれます。

グループポリシー(GPO)によるセキュリティ強化

グループポリシーを利用して、以下のようなセキュリティ設定をドメイン全体に強制します。

  • パスワードポリシーの徹底:複雑さ(大文字、小文字、数字、記号の組み合わせ)や有効期間(90日など)を厳格に設定します。ただし、近年はパスワードの定期変更よりも長く複雑なパスワードと多要素認証の組み合わせが推奨されています
  • アカウントロックアウト:連続ログイン失敗時に一時的にアカウントをロックすることで、ブルートフォース攻撃を防ぎます。推奨設定は、5回の失敗で30分間ロックです
  • 不要なサービスの停止:SMBv1などの脆弱なプロトコルを無効化します。SMBv1は2017年のWannaCry攻撃で悪用された経緯があり、現代のネットワークでは完全に無効化すべきです
  • 監査ログの設定:特権行使のログを外部のセキュアなサーバーへ転送し、改ざんを防ぎます。ログの保管期間は、最低でも90日間、可能であれば1年以上確保することが望ましいです

多要素認証(MFA)の導入とモダン認証への移行

パスワードのみの認証には限界があります。ディレクトリサービスへのアクセス、特に特権管理者によるログインには、多要素認証(MFA)を組み合わせることが必須です。

近年では、オンプレミスのADとクラウドのID管理(Microsoft Entra IDなど)を連携させる「ハイブリッドID」構成が一般的です。クラウド側の「条件付きアクセス」を活用することで、攻撃者がパスワードやチケットを盗んだとしても、信頼されていないデバイスや場所からのアクセスを遮断することが可能になります。

条件付きアクセスでは、以下のような条件を設定できます。

  • 信頼されたIPアドレス範囲からのみアクセスを許可
  • デバイスコンプライアンス(最新のセキュリティパッチが適用されているか等)を確認
  • サインインリスクレベルに応じて追加認証を要求
  • 特定の国や地域からのアクセスをブロック

5. 認証基盤の脆弱性を克服するための実践的アプローチ

技術的な対策に加え、日々の運用における「隙」をなくすことが重要です。

サービスアカウントの管理とパスワードローテーション

システム間の連携で使われる「サービスアカウント」は、高い権限を持ちながらパスワードが変更されにくいため、攻撃者の標的になります。これに対しては、Windowsの「グループ管理サービスアカウント(gMSA)」を利用することで、OSが自動的に複雑なパスワードを管理・更新する仕組みを導入し、人為的な管理ミスを排除します。

gMSAの主な利点は以下の通りです。

  • パスワードが240文字のランダムな文字列で自動生成される
  • 30日ごとに自動的にパスワードが変更される
  • サービスの中断なくパスワード更新が行われる
  • 管理者がパスワードを知る必要がない

従来のサービスアカウントでは「パスワードを変更するとサービスが止まる」という理由で何年も同じパスワードが使われ続けることがありましたが、gMSAではそのような問題が発生しません。

セキュリティ更新プログラムの適用とパッチ管理

ドメインコントローラ自体の脆弱性(例:Zerologon、PrintNightmare)は、即座にドメイン全体の崩壊につながります。セキュリティパッチは、十分に検証した上で、優先的に適用するプロセスを確立しておく必要があります。

パッチ適用の理想的なフローは以下の通りです。

  1. テスト環境で新しいパッチの動作検証(1週間)
  2. 段階的な本番環境への適用(まず1台のDC、問題なければ残りへ)
  3. 適用後の動作監視(24時間)
  4. 全体への展開完了

特にドメインコントローラに対するパッチは、深夜のメンテナンス時間帯に実施し、万が一の問題に備えて複数の技術者で対応することが推奨されます。

定期的なセキュリティ診断と棚卸し

「幽霊アカウント」の放置は非常に危険です。退職者のアカウントが無効化されないまま残っていると、攻撃者がそのアカウントを悪用する可能性があります。定期的にアカウントの有効性を確認し、不要なアカウントは即座に無効化・削除する徹底したライフサイクル管理が求められます。

セキュリティ診断で確認すべき項目は以下の通りです。

  • 90日以上ログインがないアカウントのリストアップ
  • 過剰な権限を持つアカウントの特定
  • 管理者権限を持つサービスアカウントの見直し
  • ドメイン管理者グループのメンバー数(本来は2〜3名程度が適切)
  • 期限切れのコンピュータアカウントの削除

最小権限の原則とJIT(Just-In-Time)アクセス

管理者権限は「常に保持する」のではなく、「必要な時だけ昇格する」というアプローチが有効です。Microsoft Identity Manager(MIM)やAzure AD Privileged Identity Management(PIM)などのツールを使用することで、管理者が必要な時に一時的な権限昇格を申請し、承認後に限定時間だけ特権を得る「JITアクセス」を実現できます。

この仕組みにより、攻撃者が管理者のアカウントを侵害しても、その時点で特権が付与されていなければ、ドメイン全体への攻撃は防げます。

セキュリティベースラインの適用

MicrosoftやCIS(Center for Internet Security)が公開しているセキュリティベースラインを適用することで、既知の脆弱性を体系的に排除できます。これらのベースラインには、数百項目のセキュリティ設定が含まれており、手動で設定するのは困難ですが、GPOテンプレートとして適用することで、効率的に堅牢な環境を構築できます。

6. インシデント対応とフォレンジック準備

どれほど対策を講じても、侵害を100%防ぐことは不可能です。侵害発生時に迅速に対応できる体制を整えることが重要です。

イベントログの長期保存と相関分析

ゴールデンチケット攻撃を検知するには、通常とは異なるパターンの認証要求を見つける必要があります。以下のようなイベントログを保存し、SIEM等で相関分析を行います。

  • イベントID 4768:Kerberosチケット(TGT)が要求された
  • イベントID 4769:Kerberosサービスチケットが要求された
  • イベントID 4771:Kerberos事前認証が失敗した

特に、DCのIPアドレス以外から発行されたTGT、異常に長い有効期限を持つチケット、存在しないユーザーからのチケット要求などは、攻撃の兆候です。

ハニーポットアカウントの配置

「おとり」として、高権限を持つように見せかけた実際には何の権限もないアカウントを配置します。このアカウントへのログイン試行が検出された時点で、攻撃者の存在を確信できます。

オフラインバックアップとディザスタリカバリ

ランサムウェア攻撃やドメイン全体の侵害に備え、システム状態のバックアップを定期的に取得し、ネットワークから物理的に切り離された場所に保管します。特にドメインコントローラのシステム状態バックアップは、最低でも週1回、理想的には毎日取得すべきです。

知識を定着させる実践演習

ここまで、ディレクトリサービスの基本構造から、Active Directoryにおける最恐の攻撃手法である「ゴールデンチケット」までを学習してきました。ディレクトリサービスは、その抽象的な概念ゆえに、実際に手を動かして問題を解くことで、理解の解像度が飛躍的に高まります。

特にLDAPのポート番号、Kerberosの認証フロー、そして攻撃の要となる「krbtgt」アカウントの役割については、試験でも頻繁に問われる重要ポイントです。学習した内容を思い出しながら、以下の演習問題に取り組んでみてください。

【演習】理解度チェック（全10問）

まとめ

ディレクトリサービスは、組織のITインフラにおける「心臓部」です。LDAPによる情報の標準化、Active Directoryによる高度な管理、そしてKerberosによる安全な認証。これらは非常に強力な仕組みですが、ゴールデンチケット攻撃に代表されるように、一度隙を突かれれば組織全体が掌握されるリスクを孕んでいます。

「krbtgt」アカウントの保護、Tierモデルによる特権の分離、そして継続的な監視。これらを組み合わせることで、初めて堅牢な認証基盤を構築することができます。防御側は常に全体を網羅的に守らなければなりませんが、攻撃者は一箇所の隙を見つけるだけで十分です。

この非対称な戦いに勝つためには、ディレクトリサービスの仕組みを深く理解し、対策を講じ続ける姿勢が不可欠です。技術的な対策と運用の徹底、そして組織全体のセキュリティ意識の向上。これら三位一体の取り組みによって、初めて攻撃者の一歩先を行くことができるのです。

セキュリティは「完璧」ではなく「継続的改善」が目標です。今日できる対策を着実に実施し、明日の脅威に備える。その積み重ねが、組織の認証基盤を守る唯一の道です。

次回予告: 次回の記事では、ネットワーク全体の認証を支える「RADIUSとTACACS+ ネットワーク認証のプロトコル」について解説します。今回学んだディレクトリサービスとどのように連携し、セキュアなネットワークアクセスを実現するのか、その詳細に迫ります。

-4. ID管理とアクセス制御