とりあえずLocalSystemで動かしているサービスは、今すぐ変えるべきですか？

一律に即時変更が正解とは限りません。まず、そのサービスが本当にLocalSystem相当のローカル権限(管理者を超える強い特権)を必要としているかを確認してください。ファイルの読み書きとネットワーク通信程度なら、仮想アカウント(NT SERVICE\サービス名)へ移すのが第一候補です。移行時には、必要なフォルダーやレジストリへのアクセス許可の付与、プロファイルやDPAPIに依存したデータの扱い、「サービスとしてログオン」権限の有無を確認します。検証環境で起動と主要機能を確かめてから、本番を切り替えてください。

仮想アカウントとNetworkServiceはどちらを選ぶべきですか？

新規に選ぶなら仮想アカウントをおすすめします。両者はネットワーク上ではどちらもコンピューターアカウント(DOMAIN\コンピューター名$)として見え、ローカル権限が小さい点も似ています。しかしNetworkServiceは複数のサービスが同じアカウントを共有するため、ACLで「このサービスだけに許可する」という分離ができません。仮想アカウントはサービスごとに固有の身元を持ち、ACLにNT SERVICE\サービス名を直接指定できます。SQL Serverなど近年のMicrosoft製品の既定も仮想アカウントです。

gMSAはワークグループ環境(ドメインなし)でも使えますか？

使えません。gMSAはActive Directoryのドメインコントローラーがパスワードを生成・管理する仕組みで、ドメインとKDSルートキーの作成が前提です。ワークグループ環境では、仮想アカウントかLocalService/NetworkServiceでローカル処理を完結させるのが基本です。他のマシンへのアクセスが必要な場合は、接続先に用意したアカウントの資格情報を明示的に使うなどの別設計になります。コンピューターアカウント(PC$)としてのネットワークアクセスも、ドメイン環境でだけ成り立つ話です。

サービスの実行アカウントを変えたら、保存していた設定や資格情報が読めなくなりました。なぜですか？

実行アカウントには、それぞれ固有のユーザープロファイル・%TEMP%・HKEY_CURRENT_USER・DPAPIキーが紐づいているためです。特にDPAPI(CryptProtectData等)でユーザースコープの保護をかけたデータは、原則として保護したときと同じアカウントでしか復号できません。また、プロファイル配下(AppData等)に保存したファイルは、新アカウントからは別のパスになります。アカウント切替の前に、DPAPI保護済みデータの再作成手順(APIキーの再入力等)と、プロファイル配下のファイルの移行を計画してください。

サービスから共有フォルダにアクセスしたいだけなら、ドメインユーザーは必要ですか？

多くの場合は不要です。ドメイン環境なら、LocalSystem・NetworkService・仮想アカウントで動くサービスは、リモートに対してコンピューターアカウント(DOMAIN\コンピューター名$)として認証されます。共有フォルダの共有アクセス許可とNTFSアクセス許可にそのPC$を追加すれば読み書きできます。サービス固有の身元でアクセス制御したい場合や、複数サーバーで同じ身元が必要な場合は、ドメインユーザーではなくgMSAを検討してください。

Windowsサービスアカウントの選び方

「とりあえずLocalSystemで動かしていた社内サービスが、セキュリティ監査で『過剰な権限』と指摘された。何に変えればいいのか」「サービスから共有フォルダにアクセスできなかったので、ドメインユーザーで動かしている。パスワードの期限が切れるとサービスが止まるから無期限にして、手順書に平文で書いてある」── お客様のWindowsサービスまわりの相談で、この2つは定番です。

どちらの現場にも共通するのは、サービスの実行アカウントが「設計判断」ではなく「動いた設定」のまま固定されていることです。Windowsサービスは必ず何らかのアカウントのセキュリティコンテキストで動き、そのアカウントが、ローカルで何ができるか、ネットワークの先から誰に見えるか、パスワードを誰が管理するかを全部決めます。ここを既定値のままにすると、1つのサービスの脆弱性がマシン全体の乗っ取りに直結し、平文パスワードが手順書やスクリプトに散らばります。

選択肢は実質6つ ── LocalSystem、LocalService、NetworkService、仮想アカウント(NT SERVICE\<サービス名>)、ドメインユーザー、そしてgMSA(グループ管理サービスアカウント)です。この記事では、中小企業の情シス担当者とWindowsアプリ開発者を対象に、この6つの権限・ネットワーク上の身元・パスワード管理を1枚の表に整理し、判断フローまでを2026年8月時点のMicrosoft Learnの一次情報にもとづいてまとめます。

サービスそのものの作り方(タスクスケジューラとの使い分け、.NET Worker Serviceでの実装)は「Windowsサービスの作り方と運用」で扱っています。本記事はその中で最も事故が多い「実行アカウント」に集中します。

1. まず結論

迷ったら、単一マシン内で完結するサービスは仮想アカウント、ドメイン内のリソースへサービス固有の身元でアクセスするサービスはgMSAが第一候補です。Microsoftも、可能な限り管理されたアカウント(MSA/仮想アカウント)を使うよう指針を示しています。¹²
LocalSystemを「動くから」で選んではいけません。トークンにSYSTEMとBUILTIN\Administratorsを含み、SeDebugPrivilegeなどの強力な特権を持つため、乗っ取られるとそのマシンのほぼすべてを失います。sc.exe createの既定値がLocalSystemであることが、この事故の温床です。³⁴
LocalServiceとNetworkServiceの違いは、ネットワーク上の身元です。ローカル権限はどちらも最小ですが、リモートに対してLocalServiceは匿名、NetworkServiceはコンピューターアカウントとして見えます。⁵
**仮想アカウント(NT SERVICE\<サービス名>)は、パスワード管理不要のままサービスごとに身元を分離できる現代の既定解です。**ACLに「NT SERVICE\\サービス名」を直接指定でき、SQL Serverの既定のサービスアカウントもこれです。[^understand-service-accounts][^sql-service-accounts]
LocalSystem・NetworkService・仮想アカウントがネットワークに出るときは、コンピューターアカウント(DOMAIN\コンピューター名$)になります。共有フォルダやSQL ServerのACLにPC$を付与すれば、ドメインユーザーを使わずに済むケースは多くあります。³⁶
ドメインユーザーをサービスに使う構成は、パスワード運用とKerberoastingの両面で負債になります。SCMは保存したパスワードでログオンするため、期限切れはサービスの起動失敗になり、それを避ける「無期限+平文メモ」が攻撃者への贈り物になります。⁷⁸
gMSAはActive Directoryがパスワードを自動生成・自動ローテーションします。要件はドメインとKDSルートキーで、サービスには「DOMAIN\アカウント名$」をパスワード欄空で設定します。対応していないアプリがある点は事前検証が必要です。⁹¹⁰
アカウントを変えると、プロファイル・%TEMP%・DPAPIの前提が変わります。旧アカウントのDPAPIで保護したデータは新アカウントでは復号できません。
現状の棚卸しは、サービス一覧の実行アカウントと、イベントID 4624(ログオンタイプ5)で確認できます。¹¹

一言でまとめるなら、「サービスに人間用のパスワードを持たせない」構成(組み込みアカウント・仮想アカウント・gMSA)を既定とし、ドメインユーザーは最後の手段にする、が本記事の結論です。

2. 選択肢の全体像 ── 6つの実行アカウントを1枚の表で

前提を1段だけ復習します。サービスの起動時、サービスコントロールマネージャー(SCM)は構成されたアカウントでログオンし、成功するとアクセストークンを作ってサービスプロセスに割り当てます。以後、ファイルやパイプなどすべてのリソースアクセスは、このトークンとACLの突き合わせで判定されます。⁷ つまり実行アカウントの選定とは、サービスプロセスに渡すトークンの中身を決める設計です。6つの選択肢を並べます。

アカウント	ローカル権限	ネットワーク上の身元	パスワード管理	主な使いどころ
LocalSystem	ほぼ無制限(SYSTEM+Administrators)	コンピューターアカウント(PC$)	不要(パスワードなし)	OSと一体で動く例外的なサービスのみ
LocalService	最小(Users相当)	匿名	不要	ネットワーク上の身元が不要なローカル処理
NetworkService	最小(Users相当)	コンピューターアカウント(PC$)	不要	低権限+マシン単位の身元で足りる処理
仮想アカウント NT SERVICE\<名前>	最小+ACLで個別に付与	コンピューターアカウント(PC$)	不要(自動管理)	単一サーバーで動く業務サービスの既定解
ドメインユーザー	付与した分だけ	そのユーザー自身	手動(期限・漏えい・ローテーションすべて人任せ)	gMSA非対応アプリでの最後の手段
gMSA	付与した分だけ	そのgMSA自身	ADが自動生成・自動ローテーション	ドメイン環境でサービス固有の身元が必要な場合

LocalSystem・LocalService・NetworkService・仮想アカウントはいずれもパスワードという概念自体がありません。SCMに保存されたパスワードでログオンする(=期限切れや漏えいがあり得る)のは、ドメインユーザーとローカルユーザーだけです。⁷³

以下、この表を1行ずつ掘り下げます。

3. LocalSystemの何が問題か

3.1. 「管理者で実行」よりさらに強い

LocalSystem(表示名はローカルシステム、NT AUTHORITY\SYSTEM)は、SCMが使う定義済みアカウントで、ローカルコンピューター上で広範な特権を持ちます。トークンにはNT AUTHORITY\SYSTEMとBUILTIN\AdministratorsのSIDが含まれ、システム上のほとんどのオブジェクトにアクセスできます。さらに、他プロセスをデバッグできるSeDebugPrivilegeや、OSの一部として動作するSeTcbPrivilegeが既定で有効です。³

この強さは、乗っ取られたときの被害の大きさと同義です。LocalSystemで動くサービスに任意コード実行の脆弱性が1つあれば、攻撃者はそのマシン上で、全ユーザーのファイルの読み取り・改ざん(NTFS上でSYSTEMは既定でフルコントロールです⁵)、SeDebugPrivilegeによる他プロセスのメモリ読み取り、そして資格情報の窃取とそこからの横展開(Pass-the-Hash等の起点)まで一息に到達します。認証情報の窃取と横展開の連鎖は「図解でわかるNTLMとKerberos」と「Windows LAPS実務ガイド」で扱ったとおりです。

3.2. それでも選ばれ続ける理由

理由は単純で、既定値であり、絶対にアクセス拒否が出ないからです。sc.exe createでobj=を省略したときの既定はLocalSystemで⁴、古いサンプルコードやインストーラーの雛形もLocalSystem前提のものが多く残っています。開発中に権限エラーと無縁でいられるため、「動いたのでそのまま」が量産される構造です。Microsoft自身のドキュメントも、ほとんどのサービスにこれほど高い特権レベルは不要であり、必要がなければLocalServiceかNetworkServiceの利用を検討するよう明記しています。³

3.3. TrustedInstallerとの違い ── LocalSystemも無制限ではない

なお、LocalSystemを「Windowsの最強アカウント」と呼ぶのは正確ではありません。Windows Vista以降のWindowsリソース保護(WRP)は、OSの重要なシステムファイル・フォルダー・レジストリキーの変更をTrustedInstaller(Windows Modules Installerサービス)だけに許可しており、SYSTEMや管理者でも書き換えはアクセス拒否になります。¹² エクスプローラーの「TrustedInstallerのアクセス許可が必要です」がこの仕組みです。逆に言えば、WRP保護領域以外のほぼすべてに手が届くのがLocalSystemであり、業務サービスに与える理由は通常ありません。

3.4. LocalSystemが妥当なケース

例外的に妥当なのは、デバイスドライバーと密に連携する、OSのセキュリティ基盤を操作する、他のサービスやセッションを管理するなど、要求される特権がそもそも管理者相当を超えるサービスです。バックアップエージェントやEDRのようなソフトウェアが該当します。その場合も、本当にその特権を使うコードパスがあるかを確認し、権限が必要な処理だけを分離できないかを検討する価値があります(見極め方は「Windows の管理者特権が必要になるのはいつなのか」参照)。

4. LocalServiceとNetworkService ── 最小権限の組み込みアカウント

LocalService(NT AUTHORITY\LOCAL SERVICE、SID: S-1-5-19)とNetworkService(NT AUTHORITY\NETWORK SERVICE、SID: S-1-5-20)は、低権限サービスのために用意された組み込みアカウントです。どちらもローカルでは最小限の権限しか持たず、おおむねUsersグループのメンバー相当のアクセスしかできません。⁵¹

両者の違いは1点、ネットワークの先から誰に見えるかです。⁵

LocalService: リモートに対して匿名資格情報で接続します。認証を要求するリソースにはアクセスできません。
NetworkService: リモートに対してコンピューターの資格情報(ドメイン環境ならDOMAIN\コンピューター名$)を提示します。

「ネットワークに出ない、出ても身元が要らない」ならLocalService、「ドメイン内リソースへマシンの身元でアクセスしたい」ならNetworkService、という使い分けです。

ただし、この2つには現代の視点で見ると弱点があります。同じアカウントを多数のサービスが共有することです。LocalServiceで動くサービスが5つあれば、ACLがアカウント単位である限り、5つは互いのリソースへアクセスできてしまいます。SQL ServerがLocal Serviceアカウントをサポートしないのも、共有アカウントであるため他のサービスから分離できないからです。¹

この「低権限のまま、サービスごとに分離したい」を解決するのが、次の仮想アカウントです。

5. 仮想アカウント(NT SERVICE\<サービス名>) ── 現代の既定解

5.1. パスワードなしで、サービスごとの身元を持てる

仮想アカウントは、Windows Server 2008 R2 / Windows 7以降で使える「管理されたローカルアカウント」です。特徴は3点です。⁶

アカウントは自動的に管理され、作成もパスワード設定も不要
名前はNT SERVICE\<サービス名>で、サービス1つにつき固有の身元になる
ドメイン環境では、ネットワークへコンピューターアカウント(DOMAIN\コンピューター名$)の資格情報でアクセスできる

つまり、LocalService/NetworkServiceの「パスワード管理不要」という長所を保ったまま、「アカウント共有による分離不能」という短所を解消します。SQL Serverのセットアップが既定でNT SERVICE\MSSQLSERVERのような仮想アカウントを使うのも、このためです。¹

5.2. ACLに「NT SERVICE\サービス名」を直接書ける

実務上の便利さは、ACLにそのサービスだけを名指しで追加できることです。「このデータフォルダーは、このサービスだけが書ける」を、グループ作成もパスワード管理もなしに実現できます。

# サービスのログオンアカウントを仮想アカウントへ変更する
# obj= の値は「NT SERVICE\サービス名」。パスワードは指定しない
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# 構成の確認(SERVICE_START_NAME を確認する)
sc.exe qc MyAppService

# データフォルダーへの変更権限を、このサービスにだけ付与する
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

GUIなら、services.mscでサービスのプロパティ →「ログオン」タブ →「アカウント」にNT SERVICE\サービス名と入力し、パスワード欄は空のままにします(仮想アカウントやMSAではパスワードを指定しないのがSCMの仕様です)。変更後はサービスの再起動で反映されます。

5.3. 制約 ── マシンの外では「そのサービス」だと分からない

仮想アカウントの身元はマシンローカルであり、ドメインからは認識されません。ネットワーク上では後述のとおりコンピューターアカウントに縮退するため、リモート側から「どのサービスか」を区別できず、複数サーバーで同じ身元を共有することもできません。¹⁰

この制約 ── ネットワークの先でサービス固有の身元が必要、複数サーバーで同じ身元が必要 ── が問題になった時点で、gMSA(8章)の出番です。

6. ネットワークに出るときの身元 ── コンピューターアカウント(PC$)の実務

6.1. 「サービスは共有フォルダにアクセスできない」は誤解

ドメイン参加マシンでは、LocalSystem・NetworkService・仮想アカウントで動くサービスがリモートのリソースへアクセスするとき、コンピューターアカウント(DOMAIN\コンピューター名$)として認証されます。³⁶ 冒頭の「共有フォルダにアクセスできないからドメインユーザーにした」という相談の多くは、実はこれで解決します。接続先のACLがPC$を許可していなかっただけです。

ファイルサーバー側での付与は通常のACL操作と同じで、アカウント名にコンピューター名$を指定します(GUIのオブジェクト選択ダイアログでは、オブジェクトの種類に「コンピューター」を含めます)。

# ファイルサーバー側: APPSV01 上のサービスに共有フォルダへの変更権限を与える
# 共有アクセス許可とNTFSアクセス許可の両方に付与が必要
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Serverも同様に、コンピューターアカウントをログインとして作成すれば、接続文字列はIntegrated Security=trueのままパスワードなしで通ります。

-- DB サーバー側: APPSV01 上のサービスからの Windows 統合認証を許可する
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. PC$方式の限界を知っておく

この方式には2つの限界があります。

粒度がマシン単位になります。同じマシンで動くLocalSystem・NetworkService・全仮想アカウントのサービスは、リモートからはすべて同じPC$に見えます。接続先で「このサービスだけ許可」はできず、どのサービスがそのアカウントを使ったのか監査もできません。²
ワークグループ環境では使えません。コンピューターアカウントはActive Directoryのオブジェクトなので、ドメインに参加していないマシンには存在しません。接続先のアカウント資格情報を明示的に扱う設計が必要になります。

1の限界を超えたくなったら、次章のドメインユーザー…ではなく、その問題点を飛ばしてgMSAへ進むのが2026年の答えです。

7. ドメインユーザーをサービスに使う問題

7.1. パスワードの構造的な問題

ドメインユーザー(またはローカルユーザー)をサービスに割り当てると、SCMがそのパスワードを保存し、起動のたびにログオンに使います。SCMは期限を管理してくれないため、パスワードが期限切れになるとログオンが失敗し、サービスは起動しなくなります。⁷

ここから、現場でよく見る負のスパイラルが始まります。

期限切れでサービスが止まる事故が起きる
再発防止として「パスワード無期限」に設定する
変更手順が整備されず、複数サーバーの手順書・スクリプト・タスクスケジューラに同じパスワードが平文で書き込まれていく
退職者が出てもパスワードは変わらない(変えるとどこが止まるか分からない)

Microsoftも、ドメインアカウントをサービスに使う構成ではパスワードとSPNの手動管理に相当な運用工数がかかり、メンテナンスがサービス停止を招き得ると指摘しています。¹

7.2. Kerberoasting ── サービスアカウントは狙われる

もう1つ、ドメインユーザーのサービスアカウント特有の攻撃がKerberoastingです。Kerberos認証を受けるサービスは、実行アカウントにSPN(サービスプリンシパル名)を登録します。ドメインの任意の認証済みユーザーは、SPNが登録されたアカウントへのサービスチケットを要求できるため、攻撃者はチケットを取得し、オフラインでパスワードの総当たりを試みます。人間が決めた10〜16文字程度のパスワードは、この攻撃には耐えられません。

実効性のある対策は、パスワードを人間が推測・解読できない強度にすることです。Microsoftも、長いパスワードの強制と、パスワードが機械生成の長大なランダム値になるgMSAの利用を挙げています。⁸ なお、同じ文書はKerberosアーマリング(FAST)にも触れていますが、FASTが保護するのは事前認証データとKDC偽装への耐性であり、認証済みユーザーによるSPNへのサービスチケット要求そのものは防げないため、サービスアカウントのパスワード強度の代替にはなりません。 SPNとKerberosの関係、認証がNTLMへ落ちる条件は「図解でわかるNTLMとKerberos」で図解しています。

7.3. それでもドメインユーザーを使うなら

アプリケーションがgMSAに対応していない等の理由でドメインユーザーを使わざるを得ない場合は、次を最低限の緩和策としてください。

パスワードは25文字以上のランダム生成にし、パスワード管理ツール以外(手順書・スクリプト・共有Excel)に書かない
サービス専用アカウントにし、サービスごとに分ける(人間のアカウントと兼用しない²)
対話型ログオンとリモートデスクトップを拒否し、「サービスとしてログオン」だけを許可する
所属グループを最小化する(Domain Adminsへの追加は論外です)
定期ローテーションの手順を整備し、変更が波及する場所を台帳化する

これらをすべてやるより、gMSAへ移行するほうが安全で楽 ── というのが次章です。

8. gMSA ── パスワード管理をActive Directoryに任せる

8.1. 仕組みと効果

gMSA(グループ管理サービスアカウント)は、パスワード管理をドメインコントローラーに委ねるドメインアカウントです。パスワードはKDS(キー配布サービス)のルートキーからドメインコントローラーが計算し、許可されたホストだけがそれを取得します。¹³

効果は明快です。⁹

240バイトのランダム生成パスワード: 総当たりや辞書攻撃が現実的でなくなり、Kerberoasting耐性が大きく上がります
既定30日ごとの自動ローテーション: 人間が変更を計画する必要も、サービスを止める必要もありません
複数サーバーで同じ身元を共有可能: 負荷分散配下のサーバーファームでも同一プリンシパルで相互認証できます
SPN管理の簡素化: SPNの登録・管理も委任・簡素化できます

人間はパスワードを知らないまま運用できる ── Windows LAPSがローカル管理者パスワードに対してやることを、サービスアカウントに対してやる仕組みだと捉えると位置づけが掴みやすいはずです。

8.2. 要件

gMSAには前提条件があります。¹⁰

Active Directoryドメイン環境であること(ワークグループ不可)
ドメインとフォレストの機能レベルがWindows Server 2012以上であること
KDSルートキーが作成済みであること
gMSA名はドメインではなくフォレスト内で一意であること
パスワード変更間隔は作成時にしか設定できないこと

KDSルートキーの作成は1回だけの作業ですが、作成から最大10時間は、全ドメインコントローラーへの複製を待つためgMSAを作成できません。複製が終わらないうちにパスワード取得が失敗する事故を防ぐための安全装置です。¹⁴

# ドメイン管理者として、ドメインコントローラー(または AD PowerShell モジュール
# の入った管理端末)で実行する

# KDS ルートキーの有無を確認し、なければ作成する(フォレストで1回だけ)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # 実際に使えるのは最大10時間後

8.3. 作成から設定までの手順

手順は「①取得を許可するグループを作る → ②gMSAを作る → ③サーバーにインストールする → ④サービスに設定する」の4段階です。¹⁰

# ① パスワード取得を許可するセキュリティグループを作り、
#    サービスを動かすサーバーのコンピューターアカウントを追加する
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# グループメンバーシップはコンピューターのログオン時に評価されるため、
# 追加後は対象サーバーを再起動しておくのが確実

# ② gMSA を作成する
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ サービスを動かす各サーバー上で、gMSA をインストールして検証する
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True なら取得できている

# ④ サービスの実行アカウントに設定する。名前の末尾に $ を付け、パスワードは指定しない
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

services.mscから設定する場合も、アカウント名はCORP\svc-batch$のように末尾に$を付け、パスワード欄は空のままにします。MSA系アカウントは対話的なサインインには使えません。¹ あとは共有フォルダやSQL ServerのACLにPC$の代わりにCORP\svc-batch$を付与すれば、サービス固有の身元でのネットワークアクセスがパスワードレスで完成します。

8.4. 対応していないアプリがある

注意点として、すべてのソフトウェアがgMSAで動くわけではありません。Windowsサービス、IISアプリケーションプール、タスクスケジューラのタスクなど、標準の仕組みでログオン身元を構成するものは広く対応しますが、フェールオーバークラスタリング自体はgMSAをサポートしないなどの制約があり、アプリが内部でパスワードを要求する作りだと使えません。¹⁰ Microsoftも、本番投入前にテスト環境でgMSAでの動作を確認するよう明記しています。⁹

なお、単一サーバー用のsMSA(スタンドアロン管理サービスアカウント)と、Windows Server 2025で導入されたdMSA(委任管理サービスアカウント。デバイス識別に紐づけて資格情報窃取に対抗する)という兄弟もあります。新規に組むならgMSAを基本に、要件に応じて検討してください。⁶

9. 付随する設計 ── ログオン権限・プロファイル・DPAPI・監査

アカウントに紐づいて変わるものを、あと4つ押さえてください。

9.1. 「サービスとしてログオン」権限(SeServiceLogonRight)

サービスとして起動するには、アカウントに「サービスとしてログオン」のユーザー権利が必要です。LocalSystem・LocalService・NetworkServiceには組み込みで与えられていますが、それ以外のアカウント(ドメインユーザー・gMSA等)には明示的な割り当てが必要です。¹⁵

services.mscのGUIの「ログオン」タブから設定すると、スナップインがこの権利を自動で付与します。一方、CreateService/ChangeServiceConfig(sc.exe configが呼ぶAPI)は、指定したアカウントがこの権利を持っているかを検証しません。スクリプトで構成したサービスが起動時に「ログオンに失敗しました」で止まる典型原因がこれです。ツールの副作用に頼らず、ローカルセキュリティポリシー(secpol.msc)の「サービスとしてログオン」への追加、またはGPO/Intuneでの構成をデプロイ手順に明示的に含めてください(グループポリシーでこの権利を構成している環境では、ローカルでの付与はポリシー適用時に上書きされる点にも注意が必要です)。逆に、サービス専用アカウントには「対話型ログオンの拒否」も合わせて設定するのが定石です。

9.2. プロファイル・%TEMP%・HKEY_CURRENT_USERが変わる

SCMはサービス起動時にそのアカウントのユーザープロファイルをロードします。⁷ つまり%TEMP%、%APPDATA%、HKEY_CURRENT_USERの実体は実行アカウントごとに別物で、アカウントを切り替えると、旧アカウントのプロファイルに保存していた設定やキャッシュは「消えた」ように見えます。

設計上の対策はシンプルで、サービスのデータはプロファイル配下ではなくC:\ProgramData\<アプリ名>のような明示的なパスに置き、そのACLを実行アカウントに付与することです。これでアカウント変更がデータ移行を伴わなくなります。

9.3. DPAPIで保護したデータは、アカウントと運命共同体

より見落とされがちなのがDPAPIです。ユーザースコープのDPAPI(CryptProtectDataや.NETのProtectedData)で暗号化したデータは、原則として保護時と同じアカウントでしか復号できません。アカウントを変えた途端に保存済みの接続文字列やAPIキーが読めなくなる ── DPAPIが正しく仕事をしている姿ですが、移行手順に入っていないと障害になります。

対応は「アカウント切替の後にシークレットを再投入する」手順を移行計画に含めることです(保存先の設計は「Windowsアプリの機密情報保存」参照)。なお、gMSAやPC$によるWindows統合認証で済む構成にすれば、シークレットの保存自体をなくせます。「どこに保存するか」の前に「保存しなくて済むか」を検討するのが正しい順序です。

また、サービスが「呼び出し元ユーザーの権限で」処理を行いたい場合は、アカウントを強くするのではなく偽装(インパーソネーション)を使います。こちらは「Windowsの偽装トークンを正しく扱う」を参照してください。

9.4. 監査 ── 4624のログオンタイプ5を見る

サービスの起動は、セキュリティイベントログにイベントID 4624(アカウントが正常にログオンしました)のログオンタイプ5(Service: SCMがサービスを開始した)として記録されます。イベント中の「仮想アカウント」フィールドはMSA/仮想アカウントによるログオンかを示すため、管理されたアカウントの利用状況の監視にも使えます。¹¹

現状の棚卸しには、サービス一覧の実行アカウントを集計するのが手早い方法です。

# どのサービスがどのアカウントで動いているかを集計する
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# LocalSystem で動く非標準のサービスを洗い出す(パスで自社/サードパーティ製を見分ける)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

この出力に「LocalSystemで動く業務サービス」「ドメインユーザーで動くサービス」が並んでいたら、次章の判断フローの出番です。

10. 判断フロー ── 4つの質問で決める

ここまでの内容を、選定手順としてまとめます。順に4つの質問に答えてください。

質問1: そのサービスは、ネットワーク上の他のマシン(共有フォルダ・DB・API等)へWindows認証でアクセスするか？

しないなら仮想アカウントが既定解です。特殊なローカル特権が必要な場合だけ、その必要性を確認したうえでLocalSystemを検討します。

質問2: (アクセスする場合)マシンはドメインに参加しているか？

ワークグループなら、PC$もgMSAも使えません。接続先のアカウント資格情報を明示的に扱う設計(保存はDPAPI等で保護)にするか、ドメイン参加を検討します。

質問3: (ドメインの場合)マシン単位の身元(PC$)で足りるか？

足りるなら、仮想アカウント(またはNetworkService)+接続先ACLへのPC$付与で完成です。サービス固有の身元や、複数サーバーで共通の身元が必要なら質問4へ。

質問4: アプリケーションはgMSAに対応しているか？

対応している(SCM・IISアプリプール・タスクスケジューラ等、標準の仕組みでログオン構成するものは概ね対応)ならgMSA。検証環境での動作確認を忘れずに。どうしても非対応なら、7.3節の緩和策をすべて適用したうえで専用のドメインユーザーを使います。

表にすると次のとおりです。

状況	推奨	備考
ローカル完結・通常権限	仮想アカウント	ACLは`NT SERVICE\<名前>`へ付与
ローカル完結・管理者超の特権が必須	LocalSystem	特権の必要性を先に検証する
ネットワークの身元が不要なローカル処理	LocalService	既存サービスの現状維持なら可
ドメイン内リソースへマシンの身元でアクセス	仮想アカウント(またはNetworkService)	接続先ACLに`PC$`を付与
ドメイン内リソースへサービス固有の身元でアクセス	gMSA	KDSルートキー+対応確認
複数サーバーで同一身元(負荷分散等)	gMSA	仮想アカウントでは不可
gMSA非対応アプリ+固有の身元が必要	専用ドメインユーザー	7.3節の緩和策を必須とする
ワークグループ+リモートアクセスが必要	明示的な資格情報を保護して保存	設計の見直しも検討

11. まとめ

サービスの実行アカウントは、ローカル権限・ネットワーク上の身元・パスワード管理の3つを同時に決める設計判断です。既定値(LocalSystem)のまま放置しないでください。
LocalSystemはSYSTEM+Administratorsのトークンと強力な特権を持ち、乗っ取られたときの被害が最大化します。ほとんどの業務サービスに、この特権は不要です。
LocalServiceとNetworkServiceはどちらも低権限で、違いはネットワーク上の身元(匿名か、コンピューターアカウントか)です。ただしアカウントを複数サービスで共有するため、分離はできません。
仮想アカウント(NT SERVICE\<サービス名>)は、パスワード管理不要のままサービス単位の分離ができる現代の既定解です。ACLに直接指定でき、設定はログオンアカウント名を変えるだけです。
LocalSystem・NetworkService・仮想アカウントは、ドメイン環境ではDOMAIN\PC$としてネットワークに出ます。共有フォルダやSQL ServerのACLにPC$を付与すれば、ドメインユーザーなしで済む構成は多くあります。
ドメインユーザーのサービス利用は、期限切れによる停止・平文パスワードの拡散・Kerberoastingという構造的な問題を抱えます。使うなら専用アカウント+長いランダムパスワード+ログオン制限が必須です。
gMSAはADがパスワードを自動生成・自動ローテーションする仕組みで、要件はドメイン・機能レベル2012以上・KDSルートキーです。サービスには「DOMAIN\名前$」をパスワード欄空で設定します。
アカウント変更時は、「サービスとしてログオン」権限、プロファイル・%TEMP%の移動、DPAPI保護データの再投入を移行手順に含めます。監査はイベントID 4624のログオンタイプ5で確認できます。

次にサービスをインストールするとき、ログオン設定の画面で一度だけ手を止めて、こう問い直してください。このサービスは、誰として、どこまでアクセスできるべきなのか。その答えは、この記事の判断表のどこかの行になっているはずです。

参考リンク

Microsoft Learn, Configure Windows service accounts and permissions. SQL Serverの既定サービスアカウントが仮想アカウント(NT SERVICE\MSSQLSERVER等)であること、仮想アカウント・MSA指定時はパスワード欄を空にすること、MSAが末尾$付きの名前で対話サインインには使えないこと、Local Serviceが共有アカウントであるため分離できずSQL Serverでサポートされないこと、ドメインアカウント利用時はパスワードとSPNの手動管理に工数がかかり保守作業がサービス停止を招き得ること、常に最小権限のアカウントでサービスを実行すべきことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Securing on-premises service accounts. オンプレミスのサービスにはまずgMSA、使えなければsMSA、次いでコンピューターアカウント、最後にユーザーアカウントという優先順位、コンピューターアカウントを使う場合はどのサービスがそのアカウントを使っているかを判別できず変更の監査ができないこと、サービスアカウントの役割(サービスの識別・認証・起動)について。 ↩ ↩² ↩³
Microsoft Learn, LocalSystem Account. LocalSystemがローカルコンピューター上で広範な特権を持ち、トークンにNT AUTHORITY\SYSTEMとBUILTIN\AdministratorsのSIDを含むこと、パスワードを持たないこと、リモートサーバーへはコンピューターの資格情報を提示すること、SE_DEBUG_NAMEやSE_TCB_NAMEを含む特権の一覧、ほとんどのサービスにはこの特権レベルは不要でLocalService/NetworkServiceの利用を検討すべきことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, sc.exe config. サービスの実行アカウントをobj=パラメーターで指定すること、その既定値がLocalSystemであること、LocalSystem以外のユーザーアカウントを使う場合のpassword=パラメーターについて。 ↩ ↩²
Microsoft Learn, Local accounts. SYSTEM(S-1-5-18)がNTFSボリューム上で既定でフルコントロールを持つこと、NETWORK SERVICE(S-1-5-20)がリモートサーバーへコンピューターの資格情報を提示すること、LOCAL SERVICE(S-1-5-19)がローカルで最小限の特権を持ちネットワークへは匿名資格情報を提示することについて。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Service accounts. 仮想アカウントが自動管理されるローカルアカウントでパスワード管理が不要なこと、名前がNT SERVICE<SERVICENAME>形式であること、ドメイン環境ではコンピューターアカウント(\$)の資格情報でネットワークへアクセスすること、sMSA・gMSA・dMSA・仮想アカウントの使い分けの基準について。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Service User Accounts. サービスがユーザーアカウントのセキュリティコンテキストで実行されること、SCMが起動時にアカウントへログオンしてアクセストークンをサービスプロセスへ関連付けること、SCMがユーザープロファイルをロードすること、SCMはパスワードの期限を管理せず期限切れではログオンが失敗しサービスが起動しないことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Protect SMB traffic from interception. サービスアカウント保護策としてのgMSA(機械生成の長大なランダムパスワードにより総当たり・辞書攻撃によるパスワード解読が現実的でなくなること)、長いパスワードの強制、Kerberosアーマリング(FAST)への言及などの推奨事項について。 ↩ ↩²
Microsoft Learn, Secure group managed service accounts. gMSAのパスワードが240バイトのランダム生成で総当たり・辞書攻撃を受けにくいこと、Windows OSが30日ごとにパスワードを変更し管理者による変更計画やサービス停止が不要なこと、サーバーファームへの展開とSPN管理の簡素化、サービスがgMSAをサポートしない場合はsMSA、それも不可なら強力なパスワード管理を伴う標準ユーザーアカウントを使うこと、本番前にテスト環境でgMSAでの動作を確認すべきことについて。 ↩ ↩² ↩³
Microsoft Learn, Manage group Managed Service Accounts. gMSAの前提条件(ドメイン/フォレスト機能レベル2012以上、KDSルートキーの作成)、gMSA名がフォレスト内で一意である必要があること、パスワード変更間隔は作成時のみ設定できること、New-ADServiceAccountの-PrincipalsAllowedToRetrieveManagedPasswordでパスワード取得を許可するグループを指定すること、Install-ADServiceAccount/Test-ADServiceAccountの手順、仮想アカウントの身元がマシンローカルでドメインから認識されないこと、フェールオーバークラスターがgMSAをサポートしないこと、SCM・IISアプリプール・タスクスケジューラがgMSAでのログオン構成に対応することについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, 4624(S): An account was successfully logged on. イベント4624がログオンセッション作成時にアクセス先コンピューターで記録されること、ログオンタイプ5がサービス(SCMによるサービス開始)を意味すること、「Virtual Account」フィールドでMSA・仮想アカウントによるログオンを識別でき、管理されたサービスアカウントの監視に使えることについて。 ↩ ↩²
Microsoft Learn, About Windows Resource Protection. Windowsリソース保護(WRP)が重要なシステムファイル・フォルダー・レジストリキーの置き換えを防ぐこと、WRP保護リソースへのフルアクセスがTrustedInstallerに制限されており、変更はWindows Modules Installerサービスを介したサポートされた置換メカニズムでのみ行えること、保護リソースを変更しようとするアプリケーションはアクセス拒否を受けることについて。 ↩
Microsoft Learn, Group Managed Service Accounts overview. gMSAがWindowsにパスワード管理を任せるドメインアカウントであること、キー配布サービス(kdssvc.dll)の共有シークレットからドメインコントローラーがパスワードを計算し、メンバーホストがドメインコントローラーへ問い合わせて現在と直前のパスワードを取得すること、サーバーファームで同一プリンシパルによる相互認証を可能にすることについて。 ↩
Microsoft Learn, Create a Key Distribution Service (KDS) root key. ドメインコントローラーがgMSAパスワードの生成を始めるためにルートキーが必要なこと、Add-KdsRootKey -EffectiveImmediatelyによる作成手順、作成後最大10時間はAD複製の収束を待つためgMSAを作成できないこと、複製が不完全なままではパスワード取得が失敗し得ることについて。 ↩
Microsoft Learn, Policy CSP - UserRights: LogOnAsService. 「サービスとしてログオン」権利によりセキュリティプリンシパルがサービスとしてログオンできること、Local System・Local Service・Network Serviceには組み込みでこの権利があること、それ以外のアカウントで実行するサービスにはこの権利の割り当てが必要なこと、グループポリシーでの構成パスについて。 ↩

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。

サービスを見るお問い合わせ

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

とりあえずLocalSystemで動かしているサービスは、今すぐ変えるべきですか？: 一律に即時変更が正解とは限りません。まず、そのサービスが本当にLocalSystem相当のローカル権限(管理者を超える強い特権)を必要としているかを確認してください。ファイルの読み書きとネットワーク通信程度なら、仮想アカウント(NT SERVICE\サービス名)へ移すのが第一候補です。移行時には、必要なフォルダーやレジストリへのアクセス許可の付与、プロファイルやDPAPIに依存したデータの扱い、「サービスとしてログオン」権限の有無を確認します。検証環境で起動と主要機能を確かめてから、本番を切り替えてください。
仮想アカウントとNetworkServiceはどちらを選ぶべきですか？: 新規に選ぶなら仮想アカウントをおすすめします。両者はネットワーク上ではどちらもコンピューターアカウント(DOMAIN\コンピューター名$)として見え、ローカル権限が小さい点も似ています。しかしNetworkServiceは複数のサービスが同じアカウントを共有するため、ACLで「このサービスだけに許可する」という分離ができません。仮想アカウントはサービスごとに固有の身元を持ち、ACLにNT SERVICE\サービス名を直接指定できます。SQL Serverなど近年のMicrosoft製品の既定も仮想アカウントです。
gMSAはワークグループ環境(ドメインなし)でも使えますか？: 使えません。gMSAはActive Directoryのドメインコントローラーがパスワードを生成・管理する仕組みで、ドメインとKDSルートキーの作成が前提です。ワークグループ環境では、仮想アカウントかLocalService/NetworkServiceでローカル処理を完結させるのが基本です。他のマシンへのアクセスが必要な場合は、接続先に用意したアカウントの資格情報を明示的に使うなどの別設計になります。コンピューターアカウント(PC$)としてのネットワークアクセスも、ドメイン環境でだけ成り立つ話です。
サービスの実行アカウントを変えたら、保存していた設定や資格情報が読めなくなりました。なぜですか？: 実行アカウントには、それぞれ固有のユーザープロファイル・%TEMP%・HKEY_CURRENT_USER・DPAPIキーが紐づいているためです。特にDPAPI(CryptProtectData等)でユーザースコープの保護をかけたデータは、原則として保護したときと同じアカウントでしか復号できません。また、プロファイル配下(AppData等)に保存したファイルは、新アカウントからは別のパスになります。アカウント切替の前に、DPAPI保護済みデータの再作成手順(APIキーの再入力等)と、プロファイル配下のファイルの移行を計画してください。
サービスから共有フォルダにアクセスしたいだけなら、ドメインユーザーは必要ですか？: 多くの場合は不要です。ドメイン環境なら、LocalSystem・NetworkService・仮想アカウントで動くサービスは、リモートに対してコンピューターアカウント(DOMAIN\コンピューター名$)として認証されます。共有フォルダの共有アクセス許可とNTFSアクセス許可にそのPC$を追加すれば読み書きできます。サービス固有の身元でアクセス制御したい場合や、複数サーバーで同じ身元が必要な場合は、ドメインユーザーではなくgMSAを検討してください。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal