Active Directory Service Accounts とは？

Aug 7, 2025

人間のユーザーと同じように、コンピュータプログラムも正しく動作するには、ネットワーク上のリソースにアクセスする必要があります。ただし、この2つのグループ——個人とプログラム——がそれらのリソースにアクセスする方法には違いがあります。人間がユーザーアカウントを利用する一方で、コンピュータプログラムは Active Director のサービスアカウントを使用します。Active Directory のサービスアカウントは、人の介入を必要とせずにコンピュータサービスやプログラムを実行できるようにし、重要なプロセスが裏側で中断されることなく継続することを確実にするうえで欠かせません。それでも、ユーザーアカウントと同様に、Active Directory のサービスアカウントが組織をサイバー攻撃にさらさないように管理する必要があります。

このガイドでは、Active Directory のサービスアカウントに関連するあらゆる内容を取り上げます。重要性の理解から、AD サービスアカウントのさまざまな種類、そしてそれらの管理方法までを解説します。

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

サービスアカウントは、特権アカウントの一種であり、アプリケーションやサービスがオペレーティングシステムやその他のネットワークリソースと連携できるようにします。これらの非人間のアカウントは、ユーザーアカウントと同様に、システムリソースへのアクセスを試みるコンピュータープログラムやサービスに対して、アイデンティティと権限（特権）を割り当てることで機能します。一般に、サービスアカウントには Managed Service Accounts、Group Managed Service Accounts、Local Service Accounts など、いくつかの種類がありますが、この点についてはガイドの後半で詳しく説明します。

次の記事でサービスアカウントについてさらに詳しくご覧ください：

ユーザーアカウントとサービスアカウントの違い

ユーザーアカウントとサービスアカウントの最初で最大の違いは、作成方法です。ユーザーアカウントはネットワーク管理者が作成して権限を割り当てる必要がある一方で、ほとんど（すべてではありません。一部は手動で作成することもできます）は、サービスやソフトウェアの一部として事前にインストールされ、設定された状態で提供されます。

もう一つの重要な違いは、どのように実行され、どのように識別できるかにあります。ユーザーアカウントでは、人がシステムのリソースにアクセスできるように設計されているため、特定のアカウントに紐づく個人を特定できます。一方、サービスアカウントは、アプリケーションやサービスなどの非人間のエンティティのために作成されるため、特定の人物とは関連付けられません。

それらの実行方法や Active Directory 環境における役割の違いにより、ユーザーアカウントとサービスアカウントは認証方式も異なります。ユーザーアカウントはユーザーIDとパスワードによる手動ログインが必要ですが、サービスアカウントは自律的に動作するため、サービスを実行するための権限は必要ありません。

厳選した関連コンテンツ：

Active Directory Users & Computers をインストールして使用する方法

よくある課題と、それを克服する方法

AD サービスアカウントの管理には、少なからず多くの課題があります。このセクションでは、サービスアカウントを扱う際に直面し得ることと、サービスアカウントを安全に保ち、期待どおりに動作させるためのベストプラクティスを取り入れることで、これらの課題にどう対処するかを解説します。

パスワード管理に関する問題

Active Directory のサービスアカウントに関連する最も一般的な課題の1つは、パスワード管理の欠如です。ユーザーアカウントとは異なり、サービスアカウントは、一定期間ごとにパスワードを継続的に変更またはリセットするような運用（パスワードのローテーション）を行うことがほとんどありません。IT チームがこれを見落としてしまう理由は、彼らが不注意だからではありません。むしろその逆です。サービスアカウントのパスワードを変更した場合に起こり得る結果、つまり重要なプロセスが中断されることを懸念しているからです。

サービスアカウントの使用状況の監査と監視

サービスアカウントの監視と監査は、IT 管理者にとって大きな課題です。その理由はいくつかあります。まず、単一の企業内に存在するサービスアカウントの数が非常に多くなることがあり、追いつくことが不可能になります。これらのアカウントの一部は監視できるとしても、その他は「存在を知らない」ために見落とされてしまう可能性があります。さらに、これらのアカウントは本質的に特定のユーザーに紐づいていないため、説明責任（アカウンタビリティ）が問題になることがあります。

サービスアカウントのセキュリティ

ほとんどの AD アカウントと同様に、セキュリティはサービスアカウントにおいても課題です。多くのサービスアカウントは高い権限やアクセス許可を持っているため、もしセキュリティ侵害が発生すれば、組織のネットワーク上にある多数のリソースにアクセスできてしまいます。さらに、責任（管理状況）が明確でないサービスアカウントが多すぎる場合、すべてのアカウントを 1 つずつ確実に保護することは不可能になるかもしれません。

孤立または未使用のサービスアカウント

放置すると、貴社が「サービスアカウントが多すぎて、単純に追跡できない」状態になっている多くの組織の1つになってしまう可能性があります。これは、これらのアカウントを管理していた従業員が退職した場合、新しいシステムへ移行した場合、または一時的なサービスアカウントを削除するのを忘れた場合に起こり得ます。これらのサービスアカウントは見過ごされることが多く、そのままネットワーク上に蓄積してしまうことがあります。

サービスアカウントを管理するためのベストプラクティス

上で取り上げた課題を予防し、対処するために実装できるベストプラクティスはいくつかあります。その一部には次のようなものがあります。

最小権限の原則 (PoLP)：これは、サービスアカウントに対して、実行が求められているタスクを行うために必要な（最小限の）権限だけを付与することを意味します。このベストプラクティスにより、未承認の操作やアクセスのリスクを最小限に抑えられます。さらに、セキュリティ侵害が発生した場合でも、未承認のユーザーが引き起こし得る被害の大きさが抑えられます。
権限を定期的に見直し更新する： PoLP を実装したうえで、権限を各サービスアカウントが保持している内容に応じて、時々見直し、修正する必要があります。時間の経過とともに、さまざまなアプリケーションやサービスに対する権限は変わることがあり、必要以上のアクセスを許さないようにすることが重要です。
強力なパスワードポリシーを実装する：従来のドメインアカウントのようにパスワードが自動的に変更されないサービスアカウントでは、強力なパスワードポリシーとして、複雑で長いパスワードを使用すること、高権限のサービスアカウントは定期的にパスワードを変更すること、パスワードを安全に保管することなどを行うと、侵害の可能性を減らせます。
MSA と gMSA を使用して管理の手間を削減する： MSA と gMSA はパスワード管理を自動化し、SPN の構成を簡素化します。これにより、IT スタッフは他の重要な作業に集中するための時間を確保できます。
サービスアカウントの活動を監視・監査する： サービスアカウントを作成したまま放置することは、災害への近道です（つまり、セキュリティ侵害）。そのため、不審な挙動を検出して止めるには、アカウントに対して定期的に監査を実施するためのポリシーを導入する必要があります。

未使用のサービスアカウントを整理する

未使用のサービスアカウントは、組織にとってセキュリティ上の問題になり得ます。すでに述べたとおり、これらのアカウントの中には非常に高い権限を持つものがあるため、攻撃者がそれらのいずれかにアクセスできてしまうと、大きな被害につながる可能性があります。未使用、またはオーファン（孤立）になっているサービスアカウントを特定することが重要です。これを行う方法はいくつかあり、たとえば次のようなものがあります：

Privileged Access Management (PAM) のソリューションを使用する： 例えば Netwrix のようなソリューションは、IT 環境全体をスキャンして、存在するすべてのサービスアカウントを特定します。アカウントの一覧から、未使用または不要なアカウントを見つけて削除できます。
検索クエリを活用する：一般的なクエリ「Service Accounts not logged in for $days」を使用して、AD 環境内で利用されていない古いサービスアカウントを特定できます。

未使用のサービスアカウントを安全に削除する手順

古くて未使用のアカウントを削除するには、システム全体を危険にさらさないように、いくつかの手順に従う必要があります。とはいえ、未使用のサービスアカウントを特定した後は次のとおりです。

特定したアカウントがもう必要ないことを確認します。そのために、次の PowerShell コマンドを使用できます：「Get-ADUser -Identity <AccountName> -Properties LastLogonDate」
サービスアカウントをすぐに削除するのではなく、まず無効化することをおすすめします。これにより、アカウントを無効化しても重要なサービスに影響しないことを確認できます。
サービスアカウントを無効化しても問題が発生しないことを確認したら、次の PowerShell コマンドを実行して削除できます：「Remove-ADUser -Identity <AccountName>」

サービスアカウントを管理するためのツールと手法

PowerShell は、AD 環境でサービスアカウントを管理するための強力なツールであることが証明されています。アカウントを簡単かつ迅速に作成、変更、削除するために使用できる複数のコマンドを提供します。また、権限の管理や日常的な作業の自動化にも利用できます。

Netwrix ができること

Active Directory のサービスアカウントは便利ですが、適切に管理されていない場合、組織全体にセキュリティ上のリスクをもたらす可能性もあります。だからこそ、AD サービスアカウントのベストプラクティスを作成、管理、維持するのに役立つソリューションに頼ることが不可欠です。Netwrix では Active Directory が私たちの専門分野なので、サービスアカウントを安全に保つことを任せられます。私たちの end-to-end Active Directory Security Solution は、リスク評価を実施し、AD 環境を保護するためのセーフガードを導入し、脅威に即座に対応し、包括的な AD リカバリをサポートすることで機能します。

よくある質問（FAQ）

Active Directory でサービスアカウントを作成するには？

Active Directory でサービスアカウントを作成すること自体は簡単ですが、安全に行うには、実績のあるベストプラクティスに従う必要があります。まず Active Directory Users and Computers (ADUC) を開き、アカウントを作成したい組織単位へ移動して、右クリックして「New」>「User」を選択します。サービスと目的を明確に識別できる説明的な名前を使用してください。たとえば「SQL-Service-Account」や「Backup-Service-Account」です。

組織のポリシー要件を満たす、強力で複雑なパスワードを設定します。「Password never expires」オプションは、パスワードのローテーション手順が十分に整っている場合に限って有効にしてください。そうしないと、セキュリティ上のリスクを作り出してしまいます。アカウントは、特定のサービスに必要な最小限の権限だけで構成します。ここで「最小特権（least privilege）」が理論ではなく実務として機能します。サービス要件に基づいて適切なセキュリティグループにアカウントを割り当てますが、どうしても必要な場合を除き、特権グループに追加しないでください。

覚えておいてください。攻撃者は侵入するだけではなく、ログインしてきます。権限が過剰で設定が不適切なサービスアカウントは、横方向への移動（lateral movement）の“近道”になってしまいます。 Data security that starts with identity とは、サービスアカウントを単なる機能上の必需品ではなく、重要なセキュリティ資産として扱うことを意味します。

Active Directory のサービスアカウントとは何ですか？

Active Directory のサービスアカウントは、対話型のユーザーログオンではなく、サービス、アプリケーション、および自動化されたプロセスを実行するために設計された専用のユーザーアカウントです。通常のユーザーアカウントとは異なり、サービスアカウントは、人の介入なしに認証してネットワークリソースへアクセスする必要があるアプリケーションやサービスに対して、セキュリティコンテキストを提供します。

サービスアカウントには主に4つの種類があります。ローカルサービスアカウントはローカルマシン上で限られた権限で実行されます。ドメインサービスアカウントはドメイン全体にまたがるネットワークリソースへアクセスできます。マネージドサービスアカウント（Managed Service Accounts, MSA）は自動のパスワード管理を提供します。そしてグループマネージドサービスアカウント（Group Managed Service Accounts, gMSA）は、MSA の機能を複数のサーバーに拡張します。各種類は、それぞれ異なるセキュリティおよび運用上の要件に対応します。

サービスアカウントとユーザーアカウントの大きな違いは、その目的と管理方法にあります。サービスアカウントはバックグラウンドで継続的に動作し、異なるセキュリティ上の考慮が必要で、通常ユーザーが必要としないシステムリソースに対する特定の権限を求められることがよくあります。サービスが適切に機能し続けることを保証しながら、最小権限の原則を維持するうえで欠かせません。正しく設定すれば、サービスアカウントはセキュリティ態勢を損なうことなく必要なアクセスを提供できます。

PowerShell を使って Active Directory でサービスアカウントを見つけるには？

PowerShell は、Active Directory 環境全体でサービスアカウントを特定し、監査するための強力なツールを提供します。最も効果的な方法は、複数のコマンドを組み合わせて、サービスアカウントの状況を包括的に可視化することです。

まずはこの基本コマンドから始めます：

      Get-ADUser -Filter {servicePrincipalName -like "*"} -Properties servicePrincipalName, lastLogon, passwordLastSet | Select-Object Name, servicePrincipalName, lastLogon, passwordLastSet

これは、通常サービスに関連付けられている Service Principal Names（SPNs）を持つアカウントを特定します。

SPN を持たないアカウントも含めて、より幅広く検索する場合は次を使用します：

      Get-ADUser -Filter {Name -like "*service*" -or Name -like "*svc*" -or Description -like "*service*"} -Properties Description, lastLogon, passwordLastSet, memberOf | Select-Object Name, Description, lastLogon, passwordLastSet, memberOf

これは、命名規則と説明に基づいてアカウントを特定します。

潜在的にリスクのあるサービスアカウントを特定するには、次のコマンドを実行します:

      Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} -Properties passwordLastSet, lastLogon, memberOf | Where-Object {$_.memberOf -like "*Admin*"}

管理者権限があり、パスワードが期限切れにならない有効なアカウントを検出します。まさに、追加の精査が必要な種類のアカウントです。

これらの PowerShell コマンドを定期的に監査することで、危険な挙動が侵害につながる前に見つけられます。見えないものは管理できません。これらのコマンドは、適切なサービスアカウントの衛生状態を維持するために必要な可視性を提供します。

Active Directory でマネージドサービスアカウントを作成するには？

マネージドサービスアカウント（Managed Service Accounts：MSA）は、パスワード管理を自動化し、パスワードに起因するサービス停止をなくすことで、従来のサービスアカウントよりも大幅にセキュリティを向上させます。MSA の作成には準備が必要ですが、管理の手間を減らしながら強化されたセキュリティを実現できます。

まず、環境が次の前提条件を満たしていることを確認してください：

ドメイン機能レベルが Windows Server 2008 R2 以降
サービスは Windows Server 2008 R2 以降で実行されます
ドメインコントローラーに PowerShell 用の Active Directory モジュールがインストールされていること

PowerShell を使用して MSA を作成します：

      New-ADServiceAccount -Name "MyServiceMSA" -DNSHostName "server.domain.com" -Enabled $true

“MyServiceMSA” を希望するアカウント名に置き換え、 “server.domain.com” を、このアカウントを使用するサーバーの完全修飾ドメイン名（FQDN）に置き換えてください。

次に、昇格（管理者権限）した PowerShell セッションからこのコマンドを実行して、対象サーバーに MSA をインストールします：

      Install-ADServiceAccount -Identity "MyServiceMSA"

インストールが正しく設定されていることを確認するためにテストします：

      Test-ADServiceAccount -Identity "MyServiceMSA"

最後に、サービスのログオンアカウントをパスワードなしで “Domain\MyServiceMSA$”（ドル記号に注意）に設定し、サービスが MSA を使用するように構成します。システムはパスワード管理を自動的に処理し、既定では 30 日ごとにパスワードをローテーションします。このアプローチではチェックボックスを埋めることをやめ、リスクと管理負担の両方を軽減する、実用的で自動化されたソリューションでアイデンティティを保護し始めます。

サービスアカウントとユーザーアカウント — どちらをいつ使うべきですか？

サービスアカウントとユーザーアカウントのどちらを選ぶかは、目的、セキュリティ要件、運用上のニーズによって決まります。それぞれのタイプをいつ使うべきかを理解することは、セキュリティ衛生と運用効率を維持するうえで非常に重要です。

人の操作や対話に依存せずに独立して動作する、自動化プロセス、サービス、アプリケーション、またはスケジュールされたタスクにはサービスアカウントを使用してください。これらのアカウントは非対話型のログオンを処理し、特定のリソースに対して常に利用可能で一貫したアクセスが必要です。サービスアカウントは、次のような場面で特に力を発揮します：

データベースサービス
Web アプリケーション
バックアッププロセス
監視ツール
複数のシステム間で認証を行う統合サービス

ユーザーアカウントは、システムやアプリケーションに対して対話的にアクセスする必要がある人間ユーザー向けのものです。使用パターンが変動する場合、いったんだけアクセスが必要な場合、さらに説明責任（accountability）や監査証跡（audit trail）を特定の個人に紐づける必要がある状況に対応します。人が次のことを行う必要がある場合は、ユーザーアカウントを使用してください:

対話的にログインする
メールにアクセスする
アプリケーションを対話的に使用する
人間の判断を要する管理タスクを実行する

セキュリティの観点からは、サービスアカウントは、多くの場合で昇格した権限で動作し、かつ常時稼働するため、最小権限の原則をより厳格に適用すべきです。また、異なる監視アプローチが必要です。通常の利用のばらつきではなく、異常な活動パターンは侵害の可能性を示すことがあります。ユーザーアカウントには、多要素認証、条件付きアクセスのポリシー、定期的なアクセス見直しなど、別の統制が必要です。

重要な原則は目的の整合です。サービスアカウントはサービスのために、ユーザーアカウントはユーザーのために使います。これらの目的を混在させると、セキュリティ上の隙間と運用の複雑さが生まれます。Data security that starts with identity とは、適切な目的のために適切なアカウント種別を使用し、それぞれに見合った適切な統制を適用することを意味します。このアプローチにより、運用効率を維持しながら攻撃対象領域を減らせます。

共有する

もっと詳しく

著者について

Dirk Schrader

セキュリティリサーチの VP

Dirk Schrader は Netwrix の Resident CISO (EMEA) であり、セキュリティリサーチの VP です。CISSP (ISC²) および CISM (ISACA) の資格を持つ、IT セキュリティ分野で 25 年のベテランとして、サイバー脅威に取り組むための現代的なアプローチであるサイバーレジリエンスの推進に取り組んでいます。Dirk はキャリアの初期に技術およびサポートの役割からスタートし、その後、大規模な多国籍企業から小さなスタートアップまでで、営業、マーケティング、プロダクトマネジメントのポジションへと移行しながら、世界中のサイバーセキュリティプロジェクトに携わってきました。彼はサイバーレジリエンスを実現するために、変更管理と脆弱性管理に取り組む必要性について、多数の記事を発表しています。

Threat Lab Quarterly: 2026年8月

NIST CSF 2.0：サイバーセキュリティフレームワークの新機能

PowerShell でグループ内の AD グループとオブジェクトを追加・削除する方法

Active Directory 属性: Last Logon

Active Directory の信頼（Trust）