Windowsサービスアカウントと権限をやさしく図解 — LocalSystem・仮想アカウント・gMSA

「このサービス、どのアカウントで動かすのが正解？」「SYSTEMで動かしていいの？」——Windowsのサービスアカウントは種類が多く、権限の考え方（特権とアクセス許可）も混同しがちです。この記事では、組み込みアカウント3種・仮想アカウント・gMSAの使い分けと、最小権限の考え方、実務の切り分けまでを図解します。サービスがネットワークへ出る通信の設定は Windowsのプロキシ3系統 も参考に。

サービスアカウントとは — サービスが「誰として」動くか

Windowsサービスは、常駐してバックグラウンドで動くプログラムです。動くときには必ず「誰の権限で実行するか」＝サービスアカウントが紐づきます。このアカウントの権限次第で、アクセスできるファイル・レジストリ・ネットワーク上での身元が変わります。だから「必要以上に強いアカウントで動かさない（最小権限）」ことがセキュリティの基本になります。

組み込みアカウント3種

Windowsに最初から用意されている、パスワード管理不要の3つです。ローカルでの強さとネットワーク上での身元が違います。

LocalSystemは強力ゆえに危険です。乗っ取られるとマシン全体を掌握されます。「本当にその強さが要るのか？」を常に問い、要らなければ下の低権限アカウントを選びます。

仮想アカウント（NT SERVICE\サービス名）

Windows 7 / Server 2008 R2 以降で使える、サービスごとに自動で用意される専用アカウントです。NT SERVICE\<サービス名> の形で指定し、パスワード管理は不要。NetworkServiceに似てネットワークではコンピューターアカウントとして振る舞いますが、サービスごとに分離されるのが利点です（1つのサービスが侵害されても他へ波及しにくい）。IISのアプリケーションプールID（IIS APPPOOL\<プール名>）もこの仲間です。ローカル完結のサービスなら、まず仮想アカウントが有力な選択肢です。

gMSA（グループ管理サービスアカウント）

複数サーバーで同じドメインの身元を使いたいときの本命が gMSA です。ドメインのアカウントですが、パスワードをActive Directoryが自動生成・自動更新（既定30日）してくれるため、人がパスワードを管理する必要がありません。SQL Server・IIS・タスクスケジューラなど、ドメインリソースへ特定IDでアクセスするサービスに向きます。アカウント名は末尾に $ が付き（例 EXAMPLE\svcMyApp$）、サービス設定時のパスワード欄は空にします。

準備の流れ（概略）：ドメインで一度だけKDSルートキーを作成 → New-ADServiceAccount でgMSAを作成（利用を許可するサーバーを指定）→ 各サーバーで Install-ADServiceAccount／Test-ADServiceAccount で確認、という手順です。

通常のユーザーアカウントを使う場合

ドメインや個別の権限が必要で、gMSAが使えない場合は通常のユーザーアカウントをサービスアカウントにできます。ただしパスワードを人が管理する負担（定期変更のたびに全サービスを更新）と、認証情報の盗難リスク（メモリ上の資格情報を狙われる）があります。とくにドメイン管理者などの特権アカウントをサービスに使うのは厳禁——1台の侵害がドメイン全体の侵害に直結します。使うなら専用の低権限アカウント、可能ならgMSAへ移行するのが定石です。

どれを選ぶか（早見）

「権限」は2種類ある — 特権（ユーザー権利）とアクセス許可（ACL）

ここが実務で最も混同されるポイントです。Windowsの「権限」は別々の2系統で、サービスを動かすには両方が必要になることがあります。

例えば「サービスは起動できる（特権OK）が、ログ出力先フォルダに書けない（アクセス許可NG）」なら、サービスは起動しても機能しません。逆に「フォルダには書ける（ACL OK）が、そもそもサービスとしてログオンできない（特権NG）」なら起動すらしません。切り分けは常に「特権」と「アクセス許可」の両面で行います。

「サービスとしてログオン」権利（必須）

どのアカウントでも、サービスを動かすには「サービスとしてログオン」（SeServiceLogonRight）という特権が必要です。services.msc のGUIからアカウントを設定すると通常は自動で付与されますが、グループポリシーでユーザー権利が集中管理されていると上書きされて剥がれることがあります。その場合は secpol.msc（ローカルセキュリティポリシー）→「ユーザー権利の割り当て」→「サービスとしてログオン」に、対象アカウントを明示的に追加します。

設定・確認コマンド早見

現在のサービスアカウントを確認：

:: sc.exe で1サービスの構成を確認（実行アカウント＝SERVICE_START_NAME）
sc.exe qc <ServiceName>

# PowerShell で一覧表示
Get-CimInstance Win32_Service | Select-Object Name, StartName, State

アカウントを変更（sc.exe は obj= と password= の後に空白が必要）：

:: LocalService に変更（パスワードなし）
sc.exe config <ServiceName> obj= "NT AUTHORITY\LocalService" password= ""

:: 仮想アカウントに変更
sc.exe config <ServiceName> obj= "NT SERVICE\<ServiceName>" password= ""

:: gMSA に変更（末尾$・パスワード欄は空）
sc.exe config <ServiceName> obj= "EXAMPLE\svcMyApp$" password= ""

gMSAの準備（概略）：

# ドメインで一度だけ（KDSルートキー）
Add-KdsRootKey -EffectiveImmediately

# gMSAを作成し、使用を許可するサーバー（グループ）を指定
New-ADServiceAccount -Name svcMyApp -DNSHostName svcMyApp.example.local `
  -PrincipalsAllowedToRetrieveManagedPassword "MyAppServers"

# 各対象サーバーで導入・確認
Install-ADServiceAccount svcMyApp
Test-ADServiceAccount svcMyApp

よくある障害と切り分け

セキュリティのベストプラクティス

① 最小権限： まずLocalService/仮想アカウントを検討し、SYSTEMは本当に必要なときだけ。
② サービスごとに分離： 仮想アカウントで1サービス＝1アイデンティティにし、侵害の横展開を防ぐ。
③ ドメインサービスはgMSA： パスワード管理と盗難リスクを同時に減らせる。
④ 特権アカウントをサービスに使わない： ドメイン管理者等をサービスアカウントにしない。
⑤ VDI/複数台では自動化： アカウント設定・ACL・ユーザー権利を、マスターイメージやGPO・構成管理に組み込む。

よくある質問

Q. LocalSystemとAdministratorは同じ？
A. 別物です。LocalSystem（SYSTEM）はOS自身が使う特別なアカウントで、ローカルではAdministrator以上に強い場面もありますが、ネットワークではコンピューターアカウントとして振る舞うなど性質が異なります。対話ログオン用のAdministratorとは用途が違います。

Q. IISのApplicationPoolIdentityとは？
A. アプリケーションプールごとに自動で用意される仮想アカウント（IIS APPPOOL\<プール名>）です。プール単位で分離され、パスワード管理も不要。ファイルにアクセス許可を与えるときは、このアカウント名（またはSID）を指定します。

Q. gMSAとsMSA（スタンドアロンMSA）の違いは？
A. どちらもパスワード自動管理のドメインアカウントですが、sMSAは1台のサーバー専用、gMSAは複数サーバーで共有できます。負荷分散やクラスタで同じIDを複数台に使うならgMSA一択です。

まとめ

サービスアカウントは「サービスが誰として動くか」。ローカル完結ならLocalService/仮想アカウント、ネットワークへマシンとして出るならNetworkService、複数サーバーで同じドメインIDならgMSA、SYSTEMは最小限が原則。権限は特権（ユーザー権利）とアクセス許可（ACL）の2系統で、切り分けは両面から。最小権限・サービスごとの分離・gMSA・特権アカウントを使わない——この4つを押さえれば、安全で管理しやすい構成になります。

関連ページ: Windowsのプロキシ3系統 ／ ネットワークセキュリティの基礎 ／ ディジタル証明書 ／ 記事一覧