サービスアカウントの設計と運用

サービスアカウントの種類、パスワードの管理、OU と ACL を使った権限委任をまとめます。アカウントを作るときだけでなく、継続して監査できるかも確認します。

サービスアカウントを管理する理由

サービスアカウントは「人がログインしない ID」であり、認証情報の漏洩や使い回しが検知されにくい。
最小権限（Least Privilege）を徹底しないと、侵害時に水平展開やドメイン全体の影響が拡大する。
パスワードローテーションや監査証跡（イベントログ、Kerberos チケット監査）が設計段階で組み込まれていないと後付けが困難。

例

旧来の共有サービスアカウントがドメイン管理者権限のまま放置され、全 DC にログオン履歴が残らない。
SQL Server 用アカウントが複数サーバーで流用され、1 台侵害で全サーバーに横展開。

よくある誤解

「サービスだから高権限でよい」: 実際には RBAC と最小権限で十分なケースが多い。
「人が使わないので監査不要」: サービス経由の動作も監査対象。異常動作検知にはログが必要。

注意点

監査ポリシー（ログオン/特権使用）を初期段階で決める。後から GPO 拡張すると影響が大きい。
パスワード管理を手動運用に頼らず、自動管理型（gMSA）を優先。

サービスアカウントの種類

User 型サービスアカウント: 通常のユーザーを流用。自由度は高いがパスワード管理が人手依存でリスク大。
MSA (Managed Service Account): 単一ホスト向けにパスワード自動管理。複数ホスト非対応。
gMSA (Group Managed Service Account): 複数ホスト対応、Kerberos 前提、パスワード自動管理。現行の主流。
新規設計では実質 gMSA を第一候補にするのが一般的。

例

User 型: svc-sql01 を複数サーバーで共有し、setspn -S MSSQLSvc/sql.contoso.com:1433 svc-sql01 を手動登録。
MSA: svc-iis$ を IIS01 専用で構成。Install-ADServiceAccount を単一サーバーで実行。
gMSA: webpool$ を IIS ファーム全台で共有し、各サーバーが自動でパスワード取得。

よくある誤解

「MSA を複数サーバーで使える」: MSA は単一ホスト前提。複数台は gMSA を選ぶ。
「gMSA は Kerberos 以外でも万能」: gMSA は Kerberos での認証利用が前提。NTLM 専用サービスでは恩恵が限定的。

注意点

User 型を残す場合でも SPN は重複チェック（setspn -S）で管理する。
gMSA はドメイン機能レベル要件を満たすこと（2012 以降が目安）。DC の時間同期も必須。

dMSA と委任の設計

dMSA は「新しいアカウント種類」ではなく、gMSA を誰が作成・どの OU/ホストで使うかを委任する運用モデル。
中央 AD 管理者が「gMSA の作成権限とパスワード取得権限を OU/グループ単位で委任」することで権限分離を実現。

例

中央チームが OU=Apps,DC=contoso,DC=com 直下の gMSA 作成権限をアプリ運用チームに委任。IIS-Farm グループにだけパスワード取得権限を付与。
製造ラインごとに OU を分け、ライン担当者が自分の OU 内 gMSA のみ管理できるように ACL を設定。

よくある誤解

「dMSA は gMSA とは別物」: 実体は gMSA。委任の設計・命名・申請フローが異なるだけ。
「委任すれば全て安全」: OU 粒度が粗いまま委任すると過大権限のまま。OU 設計とセットで考える必要がある。

注意点

OU が「1 拠点=1 OU」のように粗いと委任粒度が足りず、dMSA の利点が出にくい。用途別 OU 分割を検討。
委任範囲・命名規則・申請/棚卸しフローを文書化し、監査ログ（イベント 4728/4732 などグループ変更）で追跡可能にする。

AD のディレクトリ構造：DC・OU・CN

DC (Domain Component): ドメイン名を LDAP で階層表現する部分。ツリーの根（例: DC=contoso,DC=com）。
OU (Organizational Unit): 管理単位。GPO 適用、権限委任、運用境界を区切る。
CN (Common Name): 実体オブジェクト。ユーザー、コンピュータ、グループ、gMSA も CN で表現。

例

管理者アカウント: CN=Administrator,CN=Users,DC=contoso,DC=com
コンピュータ: CN=PC01,OU=Clients,OU=Tokyo,DC=contoso,DC=com
gMSA: CN=webpool$,OU=ServiceAccounts,OU=Apps,DC=contoso,DC=com
SQL サービスアカウント: CN=svc-sql01,OU=DB,OU=ServiceAccounts,DC=contoso,DC=com

図: AD 階層イメージ（DC/OU/CN）

flowchart TD
    DC["DC=contoso,DC=com"];
    DC --> OUApps["OU=Apps"];
    DC --> OUServers["OU=Servers"];
    DC --> OUClients["OU=Clients"];
    OUApps --> OUServiceAccounts["OU=ServiceAccounts"];
    OUServiceAccounts --> CNwebpool["CN=webpool$ (gMSA)"];
    OUServers --> OUWeb["OU=Web"];
    OUWeb --> CNWEB01["CN=WEB01 (Computer)"];
    OUClients --> CNPC01["CN=PC01 (Computer)"];
    DC --> CNUsers["CN=Users"];
    CNUsers --> CNAdmin["CN=Administrator"];

補足: CN=Users は「コンテナ（Container）」で、RDN が CN でも子オブジェクト（CN=Administrator など）を持つ特別なオブジェクトです。CN= は「名前の種別」を表すだけで、OU のような階層性の有無を決めているわけではありません（コンテナ/OU は子を持てるが、通常のオブジェクトは子を持たない）。

よくある誤解

「Users コンテナと OU は同じ」: CN=Users はコンテナで委任/GPO 対象外。管理したい場合は専用 OU に移動。
「CN はユーザー専用」: コンピュータ、gMSA など多くのオブジェクトが CN で表現される。

注意点

OU 階層は深くしすぎると GPO 適用やレプリケーション確認が複雑になる。管理単位と委任単位のバランスを取る。
LDAP パスを扱うスクリプトは大文字小文字を気にしないが、OU/CN の正確な綴りと構造は厳密に確認する。

OU の ACL と権限委任

Windows/AD の ACL は「オブジェクト操作権限」を制御する。ネットワーク ACL（IP/ポート許可）とは別物。
代表的な権限: Create/Delete Computer Object、Reset Password、特定属性の Write、gMSA パスワード取得 (Read msDS-ManagedPassword) など。
ACL は OU に設定すると配下のオブジェクトへ継承される。例外を付けると継承をブロックできる。

例

アプリ運用グループに OU=Apps 直下で「新規コンピュータ作成」「gMSA パスワード読み取り」を委任。
ヘルプデスクに OU=Clients 以下で「パスワードリセット」「アカウント無効化」を委任し、サーバー OU には継承させない。

図: OU ACL 継承イメージ

flowchart TD
    OUApps["OU=Apps / ACL: gMSA 作成・取得を Ops に委任"];
    OUWeb["OU=Web"];
    OUDB["OU=DB"];
    CNWEB01["CN=WEB01 (Computer)"];
    CNDB01["CN=DB01 (Computer)"];
    OUApps --> OUWeb;
    OUApps --> OUDB;
    OUWeb --> CNWEB01;
    OUDB --> CNDB01;
    classDef delegated fill:#dfe9ff,stroke:#3c6dd8,stroke-width:1px;
    class OUApps delegated;

よくある誤解

「ACL で通信も制御できる」: AD ACL はオブジェクト操作のみ。通信制御はファイアウォールやネットワーク ACL。
「Domain Admin で一律運用が安全」: 高権限の多用は監査困難・事故リスク増大。委任モデルに分解すべき。

注意点

継承を多用すると意図せぬ権限が子 OU に伝播する。例外設定はドキュメント化し、定期棚卸しを行う。
権限付与はグループ経由を基本とし、個人アカウントへの直接付与は避ける。

ネットワークの概念との対応

OU は VLAN/セグメント分割に似た「管理境界」。通信分離ではなく運用権限とポリシー適用の区切り。
AD の ACL はネットワーク ACL の「IP 許可/拒否」ではなく、「オブジェクト操作の許可/拒否」に相当。
VRF（Virtual Routing and Forwarding）はルーティング名前空間を分ける仕組み。完全一致ではないが、「範囲を分けて衝突や影響を抑える」考え方として OU/ACL のモデル理解に有用。

例

「OU=Apps」を VLAN のように分け、そこにだけアプリ運用権限を委任するイメージ。
gMSA パスワード取得権限を特定グループにだけ許可するのは、ネットワークで特定ポートを許可する ACL の感覚に近い。

よくある誤解

「OU を分けると通信も隔離される」: AD 上の管理境界であり、実際のネットワーク分離とは別。必要に応じて VLAN/ファイアウォール設計も併せる。
「VRF と同じ機能」: 目的は似ても実装は異なる。OU/ACL はディレクトリ操作権限の分離。

注意点

ネットワーク担当と AD 担当で「何を分離しているか」を共有する。誤解すると期待したリスク低減が得られない。
OU 境界とネットワーク境界がずれた場合、運用負荷や監査の複雑性が増すため、定期的な対応表を更新する。

運用と設計のポイント

OU 設計は「粗すぎると委任できない」「細かすぎると管理コスト増」のトレードオフ。用途/運用主体/セキュリティ境界を軸に切る。
グループ設計は役割ベース（RBAC）と命名規則を徹底し、棚卸しを定期化する。
gMSA/dMSA 導入時は委任範囲、監査、申請フローを事前に決める。既存 User 型からの移行計画も用意。

例

OU 例: OU=Servers 配下を OU=Web, OU=DB, OU=Mgmt に分割し、それぞれに運用グループを委任。
グループ命名例: GRP-APP-WebOps-Admin, GRP-DBA-Operators のように用途/権限/範囲を名前に含める。
gMSA 移行例: 既存 svc-iis を webpool$ (gMSA) に置き換え、IIS アプリプールを段階的に切り替え。

よくある誤解

「委任を細かくすればするほど安全」: 細分化しすぎると運用が回らず、結局 Domain Admin に戻る悪循環が起きる。
「gMSA にすれば監査は不要」: 誰がパスワード取得権限を持つか、どこで使われたかの監査は依然必要。

注意点

委任設定は変更履歴を残し、年次/四半期で棚卸し。Group Policy 委任も同時に確認。
申請フローに「SPN 登録」「gMSA へのホスト追加/削除」「利用停止時のクリーンアップ」を含める。
自動化スクリプトは対象 OU/グループをハードコードせず、パラメータ化して誤適用を防ぐ。

付録

用語の共通理解と、設計・運用チェックポイントを一か所にまとめる。

例

下記の用語集とチェックリストをキックオフや定期レビューで参照する運用を設定する。

よくある誤解

「用語やチェックリストは後追いで良い」: 導入初期から共有し、設計判断の基準にする方がブレが少ない。

注意点

用語定義は組織内標準に合わせて微調整し、製品バージョン更新に合わせて見直す。

用語集

MSA (Managed Service Account): 単一ホスト向けの自動管理サービスアカウント。
gMSA (Group Managed Service Account): 複数ホスト対応の自動管理サービスアカウント。Kerberos 前提。
dMSA (delegated Managed Service Account): gMSA の作成・利用権限を委任するモデル。新種のアカウントではない。
DC (Domain Controller/Component): ドメインを管理するサーバー／LDAP パスのドメイン要素。
OU (Organizational Unit): 管理・委任・GPO 適用の単位。
CN (Common Name): オブジェクトの名前。ユーザー/コンピュータ/グループ/gMSA など。
ACL (Access Control List): オブジェクト操作権限の一覧。
SID (Security Identifier): Windows セキュリティ主体の一意識別子。
Kerberos: チケットベースの認証プロトコル。gMSA は Kerberos を前提に設計されている。

チェックリスト（設計/運用）

OU 粒度は委任したい単位になっているか（粗すぎ/細かすぎの見直し）。
グループ命名・役割（RBAC）が明確か。棚卸しの頻度と責任者が決まっているか。
gMSA/dMSA の委任範囲と申請フローが文書化され、監査ログ取得方法が定義されているか。
User 型サービスアカウントの残存リストがあり、gMSA への移行計画と期限があるか。
SPN 管理（重複チェック）、パスワードローテーション方針、イベントログ/監査設定が適用されているか。

サービスアカウントの設計と運用

サービスアカウントを管理する理由

サービスアカウントの種類

dMSA と委任の設計

AD のディレクトリ構造：DC・OU・CN

図: AD 階層イメージ（DC/OU/CN）

OU の ACL と権限委任

図: OU ACL 継承イメージ

ネットワークの概念との対応

運用と設計のポイント

付録

用語集

チェックリスト（設計/運用）

参考資料