¶ AD基盤アーキテクチャ設計書
¶ 📘 1. はじめに
本ページは、Active Directory を単に「ドメインが動作する環境」としてではなく、組織の認証・信頼・暗号化を担う中核基盤として設計するための構成方針を整理する。
AD DS（Active Directory Domain Services）は単体でも認証・認可基盤として成立する。
しかし、組織利用を前提とした場合、以下のような設計上の弱点が残りやすい。
- LDAP通信（TCP 389）が平文で扱われ得る
- DC（ドメインコントローラー）の真正性を技術的に説明しづらい
- 証明書管理が属人的になりやすい
- 内部通信のTLS化が進まず、構造理解が難しくなる
本設計では、次の3要素を統合する。
- 🧩 AD DS：認証（Identity）
- 🔐 AD CS：信頼（Trust）
- 🌐 LDAPS：暗号化（Encryption）
これらを役割分離した上で連携させることで、
Identity / Trust / Encryption が揃った統合AD基盤を構成する。
¶ 🎯 2. 設計目的
本基盤の設計目的は以下の通りである。
- 🔐 LDAP平文通信の排除
- 🪪 DC真正性を証明可能な状態の確立
- 🛡 内部通信のTLS前提化
- 📜 証明書管理の統制（テンプレート・自動登録）
- 🔄 運用負荷の最小化
- 🧠 構造理解と再現性の確保
単なる「構築完了」ではなく、設計理由を論理的に説明できる状態を維持することを目的とする。
¶ 🏗 3. 全体アーキテクチャ構成
この図は、AD DS / AD CS / LDAPS を別要素として分離しつつ、実際には DNS によるDC探索、Kerberos認証、証明書発行、LDAPS通信が
連携して成立していることを示している。
ポイントは次の通りである。
- クライアントは最初からDCの所在を知っているわけではない
- DNS により DC を探索してから認証処理へ進む
- AD DS は認証基盤として動作する
- AD CS は証明書による信頼を提供する
- LDAPS は AD DS と AD CS が連携して初めて成立する
※ 図は概念構成を示すものであり、実環境では冗長化やネットワーク分離も考慮する。
¶ 🧩 4. 各構成要素の役割
¶ 🧩 4.1 AD DS（認証基盤）
AD DS は基盤の中心であり、以下を担う。
- Kerberos 認証
- NTLM（後方互換用途）
- グループによる認可制御
- GPOによる構成管理
- NTDS.dit によるディレクトリ管理
- マルチマスター型レプリケーション
ユーザーがログオンする際、クライアントはまず DNS を利用してドメインコントローラーを探索する。
その後、Kerberos を利用して認証処理が行われる。
ただし LDAP 389 は暗号化されない通信経路であるため、AD DS 単体では通信保護の観点で不十分となる。
¶ 🔐 4.2 AD CS（信頼基盤）
AD CS は内部PKIとして機能し、証明書の発行・管理・失効を統制する。
設計方針は以下の通りである。
- Enterprise CA を採用
- 証明書テンプレートによる用途別管理
- Auto Enrollment による自動配布
- CRL 配布設計の明確化
- 信頼チェーンの維持
これにより、次を実現する。
- DC証明書の標準化
- LDAPS前提環境の構築
- 内部サービスのTLS化
- 組織内信頼の可視化
AD CS は単なる証明書発行機能ではなく、内部通信において「その接続先が本物である」と説明可能にする基盤である。
¶ 🌐 4.3 LDAPS（暗号化層）
LDAPS（LDAP over TLS）はディレクトリ通信を暗号化する仕組みである。
仕様概要は以下の通りである。
- TCP 636
- サーバー証明書必須
- TLSハンドシェイク
- 通信暗号化
- 改ざん検知
- 接続先真正性確認
LDAPS は AD DS 単体では成立しない。
AD CS により証明書が発行されて初めて実用的に機能する。
そのため LDAPS は、
AD DS と AD CS を接続する暗号化レイヤーとして位置付ける。
¶ 🔍 5. 統合時の状態比較
¶ 🧩 AD DSのみ
- 認証可能
- LDAP平文
- DC真正性未保証
- 証明書管理なし
この状態でもドメインとしては動作する。
ただし、通信保護および信頼性の観点では検証用途レベルに留まる。
¶ 🧩 AD DS + 🔐 AD CS（LDAPS未使用）
- 証明書発行可能
- RDP警告排除可能
- 内部PKI構築可能
- LDAP平文継続
この段階で信頼基盤は成立する。
ただし LDAP 通信自体は暗号化されないため、設計としては未完成である。
¶ 🧩 AD DS + 🔐 AD CS + 🌐 LDAPS（本設計）
- Kerberos認証
- LDAP暗号化
- DC真正性保証
- 証明書自動配布
- 内部通信TLS統一
この状態で初めて、
認証・信頼・暗号化が一体化した実運用水準の構成となる。
¶ 🔐 6. セキュリティ設計観点
本設計では、構築だけでなく運用面も含めて次を重視する。
- LDAP 389 の制限
- Simple Bind の抑止または無効化
- 証明書期限監視
- CRL配布確認
- 最小権限原則
- 監査ログ有効化
- 管理者権限の分離
証明書管理は構築時だけで完結するものではなく、
セキュリティ設計の継続要素として扱う必要がある。
¶ ⚠ 7. リスク設計
PKIを含むAD基盤は強力である一方、運用を誤ると影響範囲が広い。
主なリスクは以下の通りである。
-
CA停止
→ 新規証明書発行不可 -
証明書期限切れ
→ LDAPS停止、TLS通信失敗 -
CRL参照失敗
→ 証明書検証失敗、接続拒否 -
秘密鍵漏洩
→ 信頼崩壊 -
DNS不整合
→ DC探索失敗、認証開始不可 -
時刻同期異常
→ Kerberos失敗
したがって、
AD基盤は AD DS / AD CS / LDAPS だけでなく、DNS と時刻同期まで含めて一体の基盤として扱う必要がある。
¶ 🔥 8. 結論
AD DS は Identity。
AD CS は Trust。
LDAPS は Encryption。
さらに、DNS は Discovery、時刻同期は Kerberos 成立条件としての基盤である。
これらが連携することで、組織内の認証・信頼・暗号化が統合的に成立する。
本設計は単なる検証構成ではない。
再現可能で説明可能な統合AD基盤の基本アーキテクチャである。