大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第1回 基本概念の理解

AIシステムを支えるアカウント管理を理解する

社内向けのAIシステムを考えるとき、「誰が利用できるか」「どの情報へアクセスできるか」を、組織のアカウント管理と結び付けて整理する場面があります。そこで押さえておきたい基盤の一つが、Active Directoryです。

この連載では、Windows ServerのActive Directory Domain Services（AD DS）を中心に、アカウント、認証、権限、運用の仕組みを順に見ていきます。AIアプリケーションへのつなぎ方を検討する前に、基盤が何を担当するのかを理解しましょう。

第1回では、AD DSが管理する情報、DNSとの関係、Kerberos・NTLM・Basic認証の違いを扱います。漫画は概念を説明するための架空の会話で、技術的な説明の出典は各節末にまとめています。

連載の構成

• 【★今回です★】第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
• 第2章：ドメイン環境の構築 - 検証環境の構築手順
• 第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
• 第4章：プロキシサーバーと統合Windows認証
• 第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
• 第6章：トラブルシューティング - よくある問題と解決方法
• 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
• 第8章：実践的な構成例 - AIセキュリティツールとの統合事例

1.1 Active Directoryの基本

1.1.1 ADの役割と機能

ADは、組織で共通に使うアカウント情報を管理する基盤です。

この連載で扱うのは、Windows ServerのActive Directory Domain Services（AD DS）です。ユーザーやコンピューター、グループなどの情報をディレクトリに保存し、組織内で利用できるようにします。

アカウントの情報を共通化すると、連携するシステムで同じユーザーを扱えます。ただし、アカウントが存在することと、あるファイルを利用できることは別です。

本人確認と利用権限を分ける

認証は本人確認、認可は操作を許すかどうかの判断です。

共有フォルダーを使う場面では、認証されたユーザーや所属グループをもとに、ファイルサーバー側がアクセス権を確認します。「経理部」という所属情報を書き込むだけで、経理用フォルダーの権限が付くわけではありません。

SSOと設定の一元管理を支える

シングルサインオン（SSO）は、連携したサービスで繰り返し認証情報を入力する手間を減らします。

WindowsのKerberos認証では、ログオン後に必要なサービスのチケットを取得し、対応するサービスへ本人であることを示せます。サービスを利用できるかどうかは、そのサービスの権限設定で決まります。

管理者は、グループポリシーオブジェクト（GPO）にまとめた設定を、ユーザーやコンピューターに適用できます。対象はGPOのリンク先や適用条件で決まり、起動時・ログオン時やバックグラウンドの更新時などに処理されます。

ADを理解するときは、アカウント情報の管理、本人確認、アクセス権、設定の適用を分けて捉えると、それぞれの仕組みを追いやすくなります。

1.1.2 ユーザー、コンピューター、グループの管理

利用者、端末、権限をまとめるグループは、別の対象として管理します。

ユーザーアカウントは利用者を、コンピューターアカウントはドメインに参加する端末などを識別します。ユーザーの登録だけで、端末のドメイン参加や必要な設定まで完了するわけではありません。

グループとOUは、役割が異なります。

共有フォルダーへの権限をまとめたい場合は、セキュリティグループを権限設定の対象にできます。OUに移動したことや、部署の属性を書き換えたことだけで、そのフォルダーの利用権限が自動的に付くわけではありません。

OUは、組織図をそのまま写すためのものではありません。誰に管理を任せるか、どのユーザーや端末へ設定を適用するかを考えて構成します。

1.1.3 ドメイン コントローラーの役割

ドメイン コントローラー（DC）は、ディレクトリ情報を保持し、認証などを提供します。

AD DSでは、必要なディレクトリ情報をDC同士で複製します。あるDCで加えた変更が別のDCへ伝わるまでには時間がかかり、複製の途中では参照先によって情報が異なることがあります。

DCを複数台にすることは、1台の停止に備える構成の一部です。ただし、台数だけで可用性が決まるわけではなく、複製や名前解決、通信経路を含めて正常に動く必要があります。

「どのDCも組織全体の全データを常に持つ」とは考えず、どの情報をどこへ複製する構成かを確認します。DCを追加した後も、複製が正常に続いているかを運用で確かめます。

1.2 Active DirectoryとDNSの関係

1.2.1 DNSがADの動作に必要な理由

認証を始める前に、接続するサーバーを見つける必要があります。

DNS（Domain Name System）は、名前からホストやサービスの情報を調べる仕組みです。WindowsのDC LocatorはDNSに登録されたSRVレコードなどを使い、必要なDCの候補を探します。

候補が見つかった後は、DCへ問い合わせて応答や機能を確認します。DNSが利用者のパスワードを検証するわけではなく、接続先の発見と本人確認は別の工程です。

1. 1PCが必要なDCの情報をDNSへ問い合わせる。
2. 2DNSから得た候補へ問い合わせ、利用できるDCを探す。
3. 3選ばれたDCと、ログオンなどに必要な処理を行う。

サイトに対応したレコードも、適切なDCを探すために使われます。「DNSがIPアドレスだけから最寄りの拠点を自動で判定する」という理解ではなく、ADのサイト構成とDC Locatorの動作を合わせて捉えましょう。

1.2.2 AD統合DNSの仕組み

AD統合DNSは、DNSゾーンのデータをAD DSに保存して複製する構成です。

DNSゾーンは、ある範囲のDNSレコードを管理する単位です。AD統合ゾーンでは、そのデータをADの複製機構で共有します。

AD統合ゾーンを保持する書き込み可能なDC上のDNSサーバーで、ゾーンへの更新を受け付けられます。複製範囲は設定で決まるため、フォレスト内のすべてのDCへ無条件に同じゾーンが配られるわけではありません。

AD統合と動的更新は、同じ意味ではありません。また、ユーザーアカウントを作るたびに、そのユーザー用のDNSレコードが作られるわけでもありません。

1.2.3 SRVレコードの役割

SRVレコードは、サービスを提供するホストとポートを示します。

ホスト名のアドレスを調べるA・AAAAレコードと、サービスの所在を調べるSRVレコードは役割が異なります。DC Locatorは、LDAPサービスなどのSRVレコードを利用します。

LDAPはディレクトリへアクセスするためのプロトコルです。ここでは単に「認証サービス」と言い換えず、DCを探す場面で利用されるサービスとして区別します。

以下は、予約済みの例示用ドメインexample.comを使ったDNSゾーンファイル形式の説明例です。実際の組織の設定値ではありません。

_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc01.example.com.

重みは、現在のCPU使用率や接続数を測った値ではありません。SRVの選択規則と、アプリケーション側の探索・接続処理を分けて考えることが大切です。

1.2.4 動的DNS更新

動的更新は、アドレスなどの変更をDNSへ反映するための仕組みです。

WindowsのDNSクライアントは、起動時やアドレス変更時などにレコードの更新を試みます。DHCPを使う環境では、クライアントとDHCPサーバーの設定によって、どちらがA・PTRレコードを更新するかが変わります。

1. 1端末の名前やアドレスなど、更新の対象になる情報が変わる。
2. 2設定に従って、DNSクライアントまたはDHCPサーバーが更新を要求する。
3. 3DNSサーバーが更新の条件や権限を確認し、許可されたレコードを更新する。

認証された端末だからといって、どの名前でも書き換えられるわけではありません。

セキュリティで保護された動的更新では、認証に加えて対象レコードなどのアクセス制御が関わります。VPN接続についても、接続しただけで必ず自動登録されるとは限らず、アダプターや名前登録の設定を確認します。

名前解決の不具合を調べる際は、現在のアドレス、DNSの登録内容、更新する主体を照合します。古いレコードの扱いも含め、実際の更新設定を確認する必要があります。

1.3 認証の基本プロトコル

1.3.1 Kerberos認証

Kerberosは、チケットを使ってサービスへ本人であることを示す認証方式です。

Windowsのドメイン環境では、DC上のKDC（Key Distribution Center）がチケットの発行を担います。クライアントはTGT（Ticket Granting Ticket）を取得し、それを使って接続先のサービスチケットを要求できます。

チケットを使うことで、対応するサービスへ接続するたびに、利用者がパスワードを入力する手間を減らせます。サービスはチケットを検証でき、接続のたびに必ずDCへ本人確認を問い合わせる仕組みではありません。

チケットを持つことと、そのサービスの全機能を使えることは別です。ファイルやアプリケーション側で、ユーザーやグループに許された操作を判断します。

1.3.2 NTLM認証

NTLMは、チャレンジと応答を使う認証プロトコルです。

サーバーが送るチャレンジに対し、クライアントはパスワードから導かれた情報を使って応答を作ります。NTLMの認証交換で、パスワードそのものをそのまま送るわけではありません。

ドメインアカウントの検証では、サーバーからDCへ検証処理を渡す経路が使われます。ローカルアカウントの場合はローカルの情報で検証するため、「NTLMはすべてのアクセスで必ずDCへ問い合わせる」とは言えません。

NTLMの利用が見つかったときは、単に名前だけで原因を決めず、なぜその接続で選ばれたかを調べます。既存サービスへの影響を確認せず、一括で無効化する手順にはしません。

1.3.3 Basic認証

Basic認証はHTTPの認証方式で、Base64による符号化は暗号化ではありません。

クライアントはユーザー名とパスワードを組み合わせてBase64で符号化し、認証情報として送ります。符号化された値を取得できれば元の情報へ戻せるため、Basic認証そのものに通信を隠す働きはありません。

機密情報を扱う通信でBasic認証を使うなら、HTTPSなどによる保護が必要です。ただし、HTTPSは通信経路を保護するもので、受信側のシステムによる認証情報の扱いや、アクセス権の設計まで代わりに解決するものではありません。

Basic認証は、社外からアクセスしたときにADが自動で選ぶ最終手段ではありません。HTTPサービスが提供する認証方式の一つとして、サービス側とクライアント側の設定を確認します。

1.3.4 各認証方式の使い分けと優先順位

認証方式は、アプリケーションの対応と接続条件を合わせて判断します。

WindowsのNegotiateは、KerberosまたはNTLMを選択する仕組みです。「Kerberosが使えなければNTLM、さらにBasicへ」という、すべての接続に共通する自動切り替えではありません。

うまく認証できないときの確認順序

接続できないときは、パスワードの誤りと決めつけず、発見・通信・認証・権限を順に切り分けます。次の順序は、この章で学んだ役割をもとにした確認の整理です。

1. 1どのサービスへ、どの名前で接続したかを確認する。
2. 2DNSで接続先を探せるか、必要な相手へ通信できるかを確認する。
3. 3アプリケーションが提供する方式と、ログなどに記録された実際の認証方式を確認する。
4. 4Kerberosを想定している場合は、サービスの識別情報（SPN）など、接続条件と設定を確認する。
5. 5本人確認に成功した後の拒否なら、アクセス権の設定を確認する。

まず「接続先が分からない」「本人確認に失敗した」「操作が許可されない」を分けることが、ADを使うシステムの動きを理解する出発点になります。次回は、ドメインやフォレストなど、ADの構造を掘り下げます。