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

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

特に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通信は暗号化されていません。特にDNとパスワードを送る「単純バインド」を平文のまま使うと、パケットキャプチャで管理者のパスワードさえも容易に特定できてしまいます（SASL（GSSAPI等）によるバインドではパスワード自体はネットワークに流れません）。この問題を解決するために導入されるのが「LDAPS(LDAP over SSL/TLS)」です。

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

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

無料メール講座登録特典FREE PDF

SC午後記述テンプレート集

設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。「知っているのに書けない」を解消する1冊です。

設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し

無料でPDFを受け取る →

＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。

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

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

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

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

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

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

Kerberos認証の三者間スキーム

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

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

AS Request:ユーザーが認証サービス(AS)にTGTを要求
AS Reply:ASがユーザー認証後、TGT(Ticket Granting Ticket)を発行
TGS Request:ユーザーがTGTを使い、チケット供与サービス(TGS)にサービスチケットを要求
TGS Reply:TGSがサービスチケットを発行
AP Request:ユーザーがサービスチケットを提示して、目的のリソースにアクセス
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アカウントのパスワードをリセットする必要があります。Active Directoryの仕様上、krbtgtアカウントのパスワード履歴は1世代前（N-1）まで保持され、1つ前のハッシュで署名されたTGTも有効とみなされるため、「2回」リセットすることで完全に古いハッシュを履歴から押し出し無効化できます。ただし、連続して2回リセットすると現在利用中の正当なTGTまで無効になり認証障害が起きるため、1回目のリセット後、通常のチケット有効期限(10時間)とADの複製時間を考慮し、最低でも12〜24時間程度空けてから2回目のリセットを行うことが推奨されます。
ドメインコントローラの要塞化:krbtgtハッシュはドメインコントローラと、そのバックアップ（NTDS.dit）にのみ存在します。物理アクセス制限、リモート管理の制限、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に到達するまでに複数の防御層を突破する必要が生じ、防御側に検知と対応の時間が生まれます。

なお、現在Microsoftはこの従来型のTierモデルの後継として、クラウドやリモートアクセスも含めて特権アクセスを整理する「エンタープライズアクセスモデル」を推奨しています。ただし「特権の高い資産と低い資産を分離し、上位の認証情報を下位の環境にさらさない」という考え方はそのまま引き継がれています。

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

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

パスワードポリシーの徹底:最小文字数や複雑さ(大文字、小文字、数字、記号の組み合わせ)を設定します。有効期間(90日など)による定期変更は従来よく使われてきましたが、近年は定期変更を強制せず、長く推測されにくいパスワードと多要素認証を組み合わせ、漏えいの疑いがあるときに変更させる運用が推奨されています
アカウントロックアウト:連続ログイン失敗時に一時的にアカウントをロックすることで、ブルートフォース攻撃を抑止します。閾値は基準によって異なり、例えばMicrosoftのWindows 11（22H2以降）のセキュリティベースラインは「10回の失敗で10分間ロック」としています（以前のベースラインではロック時間を15分としていました）。閾値を低くしすぎると、攻撃者がわざと失敗を重ねて正規ユーザーを締め出すDoSに悪用される点にも注意が必要です
不要なサービスの停止:SMBv1などの脆弱なプロトコルを無効化します。SMBv1は2017年のWannaCry攻撃で悪用された経緯があり、現代のネットワークでは完全に無効化すべきです
監査ログの設定:特権行使のログを外部のセキュアなサーバーへ転送し、改ざんを防ぎます。ログの保管期間は組織の要件や法令・監査基準に応じて決めますが、例として「最低90日間、可能であれば1年以上」といった設定がよく見られます

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パッチ適用フローの一例は以下の通りです（括弧内の期間は例であり、組織の要件や脆弱性の緊急度に応じて調整します）。

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

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

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

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

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

一定期間(例:90日以上)ログインがないアカウントのリストアップ
過剰な権限を持つアカウントの特定
管理者権限を持つサービスアカウントの見直し
ドメイン管理者グループのメンバー数(組織の規模に応じて必要最小限に絞る。例として2〜3名程度)
期限切れのコンピュータアカウントの削除

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

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

この仕組みにより、攻撃者が管理者のアカウントを侵害しても、その時点で特権が付与されていなければ、そのアカウントを足掛かりにしたドメイン全体への攻撃のリスクを大きく下げられます。

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

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

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

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

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

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

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

特に、TGT発行要求（イベントID 4768）の履歴がないにもかかわらずTGSが要求（イベントID 4769）された場合や、異常に長い有効期限を持つチケット、存在しないユーザーからのチケット要求などは、攻撃の兆候です。

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

「おとり」として、高権限を持つように見せかけた実際には何の権限もないアカウントを配置します。正規の業務でこのアカウントが使われることはないため、ログイン試行が検出された時点で、攻撃者（または不正な内部活動）の存在を強く疑うことができます。

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

ランサムウェア攻撃やドメイン全体の侵害に備え、システム状態のバックアップを定期的に取得し、ネットワークから物理的に切り離された場所に保管します。特にドメインコントローラのシステム状態バックアップの取得頻度は、組織の要件（許容できるデータ損失の範囲など）に応じて決めます。例として「最低でも週1回、理想的には毎日」といった設定が考えられます。

【演習】ディレクトリサービスとセキュリティ（LDAP/AD）練習問題

この記事で学んだディレクトリサービス、LDAP、およびActive Directoryのセキュリティに関する知識を確認するための練習問題をご用意しました。全10問の選択式問題で、回答するとその場で正誤と各選択肢の解説が表示されます。学習の総仕上げとして、ぜひ練習問題に挑戦してみてください。

【演習】ディレクトリサービスとセキュリティ（LDAP/AD）練習問題（全10問）

まとめ

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

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

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

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

関連記事: ネットワーク全体の認証を支えるRADIUSとTACACS+については、RADIUSとTACACS+の違いとは?ネットワーク認証の仕組みとAAAモデルを徹底解説で解説しています。今回学んだディレクトリサービスとどのように連携し、セキュアなネットワークアクセスを実現するのかをあわせて確認してみてください。