2026年4月30日のMicrosoft Defender公式ドキュメント更新「Move ‘View service accounts’ from Discover to Investigate section」でまず押さえるべき点は、サービスアカウント確認の位置づけが「発見」から「調査」に寄ったということです。新機能が突然追加された、または設定値が強制変更されたというより、Microsoft Defender上でサービスアカウントを扱う運用導線とドキュメント上の整理が見直された更新と捉えるのが現実的です。MicrosoftDocsのコミット説明でも、サービスアカウントの記事を「Investigate a non-human identity」の近くへ移動し、サービスアカウントの発見は侵害前のDiscovery活動ではなく調査活動に近い、というフィードバックに基づく変更だと説明されています。(GitHub)
この変更は、security admins、compliance teams、enterprise IT readersにとって小さな表記変更ではありません。サービスアカウントは、Active Directory上でアプリケーション、サービス、自動タスクを動かすために使われ、しばしば高い権限を持つ一方で、人間のアカウントのようにMFAなどの保護を適用しにくいアカウントです。Microsoft Learnでも、慎重な管理と監視が必要な対象として説明されています。(Microsoft Learn)
Microsoft Defenderの公式ドキュメント更新で何が変わったか
今回の更新名は「Move ‘View service accounts’ from Discover to Investigate section」です。直訳すると、「View service accounts」をDiscoverセクションからInvestigateセクションへ移動する、という意味になります。
実務上は、次のように理解すると分かりやすいです。
| 観点 | 変更前の受け止め方 | 変更後に意識すべき受け止め方 |
|---|---|---|
| サービスアカウントの確認 | 環境内に何があるかを見つける棚卸し作業 | リスク、接続先、認証履歴を見て調査する作業 |
| 主な利用者 | 資産管理担当、ID管理担当 | SOC、セキュリティ管理者、インシデント対応担当、監査担当 |
| 見るべき情報 | アカウントの一覧、種別、件数 | 重要度、接続元、接続先、認証プロトコル、直近の利用状況 |
| 運用上の意味 | インベントリ管理 | 調査・検知・是正判断の入口 |
Microsoft Defenderのサービスアカウント関連ドキュメントでは、サービスアカウントページへはMicrosoft Defenderポータルの「Identities > Service Accounts」から移動すると説明されています。また、一覧では列の追加・削除、フィルター、CSVエクスポート、並べ替えやフィルター処理が可能です。(Microsoft Learn)
つまり、今回の更新は「サービスアカウントを見る場所が変わったかもしれない」という単純なUIメモではなく、サービスアカウントを“資産一覧”として見るだけでなく、“調査対象のID”として扱うべきだという運用上のメッセージとして読むべきです。
なぜサービスアカウントがInvestigate側に寄せられたのか
サービスアカウントは、日常業務では目立ちません。バックアップ、監視、バッチ処理、アプリケーション連携、ファイル共有、データベース接続などで使われ、利用者が直接サインインすることは少ないためです。
しかし、攻撃者にとっては魅力的な対象です。理由は明確です。
- 権限が広く設定されがち
- パスワードが長期間変更されないことがある
- 人間のユーザーと違い、MFAを適用しにくい
- 所有者や用途が不明なまま残りやすい
- 異常な利用が通常業務に紛れやすい
Microsoft Defenderのドキュメントでも、サービスアカウントはgMSA、sMSA、ユーザーアカウントの形で分類され、SPNがあることや「パスワードが期限切れにならない」属性など、特定条件を満たすActive Directoryアカウントを自動検出してサービスアカウントとして分類すると説明されています。(Microsoft Learn)
ここで重要なのは、サービスアカウントの確認は「見つけたら終わり」ではないという点です。たとえば、次のような状態が見つかった場合、単なる棚卸しではなく調査が必要です。
| 見つかった状態 | 調査で確認すべきこと | 放置した場合のリスク |
|---|---|---|
| Domain Adminsなどの特権グループに所属 | 本当に管理者権限が必要か、代替権限で足りないか | アカウント侵害時に広範な管理権限を奪われる |
| 長期間使われていない | 業務影響を確認して無効化・削除できるか | 使われていない入口として悪用される |
| 接続先が多い | 本来の用途と一致しているか | 横展開や不正アクセスの踏み台になる |
| NTLM利用が多い | Kerberosへ移行できるか、古いシステム依存がないか | 認証情報悪用の検知・制御が難しくなる |
| 所有者が不明 | 管理責任者、利用システム、変更手順が明確か | 障害時や監査時に判断できない |
Microsoft Defender for Identityのセキュリティ姿勢評価でも、特権グループ内のサービスアカウントは攻撃対象領域を広げる要因として説明され、不要な特権の削除、未使用アカウントの無効化、gMSAへの移行、ログオン先の制限、定期レビューなどが推奨されています。(Microsoft Learn)
Microsoft Defenderで確認すべきサービスアカウント関連項目
今回のドキュメント更新を受けて、管理者が確認すべき項目は大きく5つあります。
サービスアカウント一覧が現在の運用手順から見つけられるか
まず確認すべきなのは、社内手順書やSOCランブックに記載されているナビゲーションが現在のMicrosoft Defenderポータルと一致しているかです。
Microsoft Learnの日本語ページでは、Microsoft Defenderポータルで「ID > サービス アカウント」に移動すると説明されています。ページ内では、列の追加・削除、フィルター、CSVエクスポート、並べ替えなどが可能です。(Microsoft Learn)
チェックする場所は次の通りです。
| 確認対象 | 見直す内容 |
|---|---|
| SOCランブック | 「Discover」前提の手順が残っていないか |
| 監査証跡の手順書 | サービスアカウント一覧の取得方法が古くないか |
| 新任管理者向け資料 | 「サービスアカウントは調査対象」と説明されているか |
| インシデント対応手順 | アラート調査時にサービスアカウント確認へ進む導線があるか |
| 画面キャプチャ付きマニュアル | 画面上のメニュー名や位置が現行UIと合っているか |
特に大企業では、手順書のスクリーンショットが半年以上更新されていないことがあります。Defenderポータルは段階的なロールアウトやプレビュー機能の影響を受けることがあるため、ドキュメントの表記と実環境の表示が完全に一致しない場合もあります。そのため、手順書では「メニュー名だけ」ではなく、「目的」「確認する項目」「代替の探し方」まで書いておくと運用が止まりにくくなります。
サービスアカウントの分類が十分か
サービスアカウントは、自動検出だけで完全に把握できるとは限りません。Microsoft Defender for Identityでは、gMSA、sMSA、ユーザーアカウントのうち、SPNやパスワード期限なし属性などの条件に基づいてサービスアカウントを自動分類します。さらに、組織独自の命名規則に対応するため、サービスアカウント分類ルールを作成できます。(Microsoft Learn)
たとえば、社内で次のような命名をしている場合は、分類ルールの見直しが必要です。
| 命名例 | 想定される用途 | 確認ポイント |
|---|---|---|
svc_backup01 | バックアップ処理 | バックアップサーバー以外から使われていないか |
srv_sql_batch | SQLバッチ処理 | DB権限が過剰でないか |
app_monitoring | 監視ツール | 読み取り権限だけで足りるか |
robot_rpa_finance | RPA処理 | 人間のユーザー権限を流用していないか |
legacy_sync | 旧システム同期 | 現在も必要か、移行予定があるか |
Microsoft Learnでは、たとえばsvcのようなプレフィックスを持つ組織独自の命名規則はDefender for Identityが自動検出しない場合があり、その場合は分類ルールでサービスアカウントビューに含められると説明されています。(Microsoft Learn)
接続元・接続先・認証プロトコルを確認する
サービスアカウント調査で最も重要なのは、「そのアカウントがどこから、どこへ、どの認証方式でアクセスしているか」です。
Microsoft Defenderのサービスアカウント詳細では、Sources、Destinations、Connections、Auth protocols、Created、Last updatedなどの項目が扱われます。接続タブでは、ソース、ソース種別、ソースリスク、宛先、宛先種別、KerberosやNTLMなどの認証プロトコル、サービスクラス、過去180日間のサインインイベント数、最終確認日時などを確認できます。(Microsoft Learn)
調査では、次のように判断します。
| 確認項目 | 正常な例 | 注意すべき例 |
|---|---|---|
| 接続元 | 特定のアプリケーションサーバーのみ | 複数の端末、管理者PC、想定外のサーバー |
| 接続先 | 業務上必要なDB、ファイルサーバー | ドメインコントローラー、広範なサーバー群 |
| 認証プロトコル | Kerberos中心 | NTLMが多い、古いプロトコル依存が強い |
| 最終利用 | 定期処理のタイミングと一致 | 深夜や休日に不自然な利用 |
| 接続数 | 用途に見合った範囲 | 急に増加、または過去にない接続先が出現 |
ここで大事なのは、「接続がある＝悪い」と短絡しないことです。サービスアカウントは業務システムを動かすためのアカウントなので、通常でも多数のイベントが出る場合があります。見るべきなのは、業務上の想定と実際の接続パターンが一致しているかです。
Non-human identities全体の中でサービスアカウントを位置づける
今回の更新は、サービスアカウント単体の話に見えますが、より大きく見るとMicrosoft Defenderの「Non-human identities」対応の流れに含まれます。
Microsoft Defenderでは、Non-human identitiesを、人間が直接操作しないアカウントやアプリケーションとして説明しており、Microsoft Entra IDのサービスプリンシパル、Active Directoryサービスアカウント、Google WorkspaceやSalesforceに接続されたOAuthアプリなどが含まれます。これらは高い権限や機密リソースへのアクセスを持つことがあるため、セキュリティ監視上の優先対象です。(Microsoft Learn)
Microsoft DefenderのIdentity inventoryでも、人間のIDとNon-Human identitiesを分けて表示し、Non-Human identitiesにはMicrosoft Entra IDのOAuthアプリ、Active Directoryのオンプレミスサービスアカウント、Salesforce、Google Workspaceなどが含まれると説明されています。(Microsoft Learn)
したがって、サービスアカウントだけを個別に管理するより、次のようにNon-human identities全体で管理すると実務に合います。
| ID種別 | 代表例 | 主な確認観点 |
|---|---|---|
| Active Directoryサービスアカウント | gMSA、sMSA、通常ユーザー型サービスアカウント | 権限、接続先、認証方式、所有者 |
| Microsoft Entra IDアプリ | サービスプリンシパル、アプリ登録 | API権限、管理者同意、最終利用 |
| SaaS OAuthアプリ | Google Workspace連携、Salesforce連携 | 同意範囲、発行元、利用者、外部アプリリスク |
| 自動化アカウント | RPA、バッチ、CI/CD連携 | 認証情報の保管、権限範囲、実行環境 |
Microsoft Defender XDRのWhat’s newでも、Identity inventoryが人間のIDとNon-human identitiesを分けて表示すること、重要なActive Directoryサービスアカウントやクラウドアプリケーションアカウントを把握するInsight cardsに触れています。(Microsoft Learn)
運用影響：すぐに設定変更が必要とは限らないが、手順書は見直すべき
今回の更新だけを根拠に、即座にポリシー変更やセンサー再構成が必要になるとは限りません。少なくとも、コミット説明から読み取れる中心は、機能停止や強制的な仕様変更ではなく、ドキュメント上の配置変更と運用文脈の整理です。(GitHub)
ただし、次のような組織では影響が出やすいです。
| 組織の状態 | 起こりやすい影響 | 対応 |
|---|---|---|
| 手順書がDiscover前提 | 新人や夜間対応者が該当ページを探せない | ランブックの画面導線を更新 |
| 監査でサービスアカウント一覧を定期提出 | 取得手順の説明が古くなる | 監査用手順を現行UIに合わせる |
| SOCがID調査を人間ユーザー中心に実施 | サービスアカウントの異常利用を見落とす | 調査チェックリストにNHIを追加 |
| 命名規則が独自 | 自動分類から漏れるアカウントがある | 分類ルールを整備 |
| 特権サービスアカウントが多い | 攻撃時の影響範囲が広い | 権限レビューとgMSA移行を検討 |
特に注意したいのは、監査・コンプライアンス部門との認識差です。セキュリティ管理者は「単なるドキュメント更新」と見なしても、監査担当者は「サービスアカウントの管理証跡をどう取得するのか」を確認します。画面導線が変わった場合、証跡取得手順が古いだけで監査対応が遅れることがあります。
移行準備として実施したいチェックリスト
この更新を受けて、企業IT部門やSOCが行うべき作業は、派手な移行プロジェクトではありません。まずは既存運用の確認から始めるのが安全です。
| 優先度 | 作業 | 担当の目安 | 完了基準 |
|---|---|---|---|
| 高 | Microsoft Defenderポータルでサービスアカウントページを確認 | Security admin | 現行UIで該当ページに到達できる |
| 高 | ランブック内の「Discover」表記を確認 | SOCリード | 調査手順がInvestigate文脈に更新されている |
| 高 | 特権グループ内のサービスアカウントを確認 | AD管理者 | 不要な特権を削除または例外承認済み |
| 中 | 分類ルールを見直す | ID管理担当 | 命名規則ベースの漏れを補完 |
| 中 | CSVエクスポート手順を確認 | 監査・コンプライアンス | 定期レビュー用の証跡取得方法が明確 |
| 中 | 接続元・接続先の異常確認を定例化 | SOC | 想定外の接続をレビューする運用がある |
| 低 | 教育資料のスクリーンショットを差し替える | 情報システム部 | 新任者が迷わず操作できる |
このチェックリストで重要なのは、作業を「ドキュメント更新への追随」として終わらせないことです。サービスアカウントは、IDセキュリティ、特権アクセス管理、監査、インシデント対応が交差する領域です。今回の更新をきっかけに、所有者不明、過剰権限、未使用、古い認証方式という4つの観点で見直すと、実際のリスク低減につながります。
Advanced Huntingで確認する場合の考え方
Microsoft Defenderの高度なハンティングを使っている組織では、サービスアカウントの調査を画面確認だけに頼らず、クエリ化しておくと再現性が高まります。
Microsoft Learnでは、IdentityAccountInfoテーブルに各種ソースからのアカウント情報や、アカウントが紐づくIDへのリンク情報が含まれると説明されています。また、Type列にはUserやServiceAccountといった値が含まれるとされています。(Microsoft Learn)
たとえば、考え方としては次のような確認が有効です。
IdentityAccountInfo
| where Type == "ServiceAccount"
| project Timestamp, DisplayName, AccountUpn, AccountId, CriticalityLevel, DefenderRiskLevel
| order by Timestamp descこのクエリは、サービスアカウントとして分類されているアカウントを確認する入口として使えます。実環境では、列名やデータの有無、対象テーブルの利用可否がテナント構成や連携サービスによって異なる場合があるため、Defenderポータル内のスキーマ参照と照合しながら調整してください。
ログオンイベントを確認する場合は、IdentityLogonEventsも候補になります。このテーブルは、Microsoft Defender for Identityによって取得されたオンプレミスActive Directoryの認証活動や、Defender for Cloud Appsで取得されたMicrosoftオンラインサービス関連の認証活動を含むと説明されています。ただし、サービスが展開されていない環境ではクエリが動作しない、または結果が返らない可能性があります。(Microsoft Learn)
調査時は、単に「サービスアカウントの一覧」を出すだけでなく、次のような問いに答えられる形にしておくと実用的です。
- 重要度が高いサービスアカウントはどれか
- 最終利用が古いアカウントはないか
- 想定外の接続元から使われていないか
- 特権を持つアカウントが通常業務と関係ない宛先へアクセスしていないか
- NTLMなど、見直し対象の認証プロトコルが多用されていないか
コンプライアンス部門が確認すべきポイント
コンプライアンス部門にとって、この更新は「証跡取得の画面が変わったかもしれない」というだけではありません。サービスアカウント管理の説明責任をどう果たすかに関わります。
確認すべきポイントは次の3つです。
所有者と用途が記録されているか
サービスアカウントには、最低限次の情報を紐づけて管理します。
| 項目 | 記録例 |
|---|---|
| 所有部門 | 情報システム部、経理システムチーム |
| 技術責任者 | 管理者名またはグループ名 |
| 利用システム | 会計DBバックアップ、監視基盤、ファイル連携 |
| 権限範囲 | 読み取り専用、特定OUのみ、DB接続のみ |
| 利用サーバー | APP01、BACKUP02など |
| 変更手順 | パスワード変更、無効化、権限変更時の承認経路 |
| レビュー頻度 | 四半期、半期、年次 |
所有者が不明なサービスアカウントは、障害時にもセキュリティ対応時にも判断が遅れます。まずは「消せるか」ではなく、「誰が責任を持って判断するか」を明確にすることが先です。
定期レビューの証跡を残せるか
サービスアカウントの一覧をCSVで出力できるとしても、それだけでは十分ではありません。レビュー済みであることを示すには、次のような証跡が必要です。
- いつ確認したか
- 誰が確認したか
- どの範囲を確認したか
- どのアカウントに問題があったか
- 是正済みか、例外承認か
- 次回レビュー日はいつか
Microsoft Learnでは、サービスアカウント一覧のCSVエクスポート時に最大2,000件のサービスアカウントが表示されると説明されています。大量のサービスアカウントを抱える環境では、エクスポート件数の制限やフィルター条件を考慮し、監査対象が漏れないようにする必要があります。(Microsoft Learn)
例外管理を明文化する
すべてのサービスアカウントをすぐにgMSAへ移行できるわけではありません。古い業務アプリ、ベンダー管理システム、夜間バッチなど、レガシーなユーザー型サービスアカウントが残ることはあります。
その場合は、例外を放置するのではなく、次の条件を満たす必要があります。
| 例外条件 | 必須の管理 |
|---|---|
| 特権が必要 | 具体的な理由、承認者、期限を記録 |
| パスワード期限なしが必要 | 代替統制、監視、保管方法を記録 |
| NTLMが必要 | 対象システム、移行予定、リスク受容を記録 |
| 所有者変更が多い | グループ所有にして個人依存を避ける |
| 廃止予定 | 廃止日、依存システム、移行先を記録 |
コンプライアンス対応では、「例外があること」自体より、「例外が管理されていないこと」が問題になりやすいです。
よくある誤解と注意点
「DiscoverからInvestigateへ移動したから検出機能がなくなった」は早計
今回の更新名だけを見ると、サービスアカウントのDiscovery機能が削除されたように見えるかもしれません。しかし、コミット説明は記事の配置変更と文脈の見直しを示すものであり、機能削除を直接示すものではありません。(GitHub)
確認すべきなのは、実際のテナントでサービスアカウント一覧、分類、接続情報、エクスポート、ハンティング結果が従来通り利用できるかです。
「サービスアカウントは一覧化できれば十分」ではない
一覧化は入口にすぎません。サービスアカウントで本当に重要なのは、権限と利用実態です。
たとえば、同じ「サービスアカウント」でも、読み取り専用で特定サーバーからしか使われないものと、Domain Adminsに所属して複数サーバーへ接続しているものではリスクがまったく違います。Microsoft Defenderの調査観点では、重要度、タグ、接続元、接続先、認証プロトコル、過去180日間のサインインイベント数などを組み合わせて見る必要があります。(Microsoft Learn)
「人間のID管理」と同じ基準だけでは足りない
Non-human identitiesは、人間のユーザーとは動き方が異なります。通常のユーザーであれば勤務地、端末、サインイン時間、MFA状況などが判断軸になります。一方、サービスアカウントでは、実行元サーバー、接続先、サービスクラス、認証方式、定期処理の周期などが重要です。
そのため、ユーザーアカウント向けの不審サインイン検知だけに頼ると、サービスアカウントの異常を見落とす可能性があります。
この記事の内容を受けて次に行うこと
今回のMicrosoft Defender公式ドキュメント更新で確認すべきことは、機能追加の有無だけではありません。より重要なのは、サービスアカウントを「見つける対象」から「調査して保護する対象」として扱う運用に変えることです。
まずは、次の順番で確認してください。
- Microsoft Defenderポータルでサービスアカウント一覧に到達できるか確認する
- 社内手順書に古い「Discover」前提の記載がないか確認する
- 特権グループに所属するサービスアカウントを洗い出す
- 所有者不明、未使用、過剰権限、NTLM依存のアカウントを優先的にレビューする
- 分類ルールと監査証跡の取得方法を見直す
サービスアカウントは、普段は静かに動く一方で、侵害されたときの影響が大きいIDです。今回の更新をきっかけに、Microsoft Defender上のサービスアカウント確認を、単なる棚卸しではなく、調査・是正・監査につながる運用へ整えておきましょう。
コメント