「svc-」アカウントが時限爆弾になる理由

By Mirko Peters · 2026-08-11

ポッドキャストへようこそ。エンタープライズ セキュリティ アーキテクチャについての継続的な掘り下げを、今回も続けます。多くの組織と同様に、Active Directory や Microsoft Entra ID のディレクトリを一通り確認すると、「svc-」「app-」「admin-bot」で始まるアカウントが大量に見つかるはずです。

Automatically translated with AI from the original post. Read the English original

ポッドキャストへようこそ。エンタープライズ セキュリティ アーキテクチャについての継続的な掘り下げを、今回も続けます。多くの組織と同様に、Active Directory や Microsoft Entra ID のディレクトリを一通り確認すると、"svc-"、"app-"、"admin-bot" で始まるアカウントが大量に見つかるはずです。これらのアカウントは、システムを稼働させ、データを流し、自動化を動かし続けています。しかし同時に、現代のセキュリティ態勢における最大の死角でもあります。本ブログ記事では、最新の対談の内容をさらに掘り下げ、従来のサービス アカウントがなぜゼロトラスト アーキテクチャを根本から損なうのか、そして Microsoft Entra Workload Identities への移行こそが唯一の道である理由を解説します。

このテーマの音声による詳しい解説は、関連ポッドキャスト エピソード Replace Service Accounts with Entra Workload Identities をぜひお聴きください。それでは、非人間のリスクの仕組みと、それを根本から排除する方法を見ていきましょう。

要約（TL;DR）

静的なシークレットと広範な権限を持つサービス アカウントは、最大の ID 上のセキュリティ ギャップです。Microsoft Entra ID の Workload Identities は、非人間のすべてのアクターに、最小特権、ライフサイクル、条件付きアクセス ポリシー、ローテーション、完全な監査証跡を備えた統制された ID を提供します。しかも、自動化を止めることなく実現できます。

サービス アカウントが失敗する理由（ゼロトラストを損なう理由）

従来のサービス アカウント モデルは、もはや存在しないネットワーク境界を前提に設計されたものです。信頼が「デバイスが社内 LAN に接続されているか」で決まっていた時代には、構成ファイルに保存された静的なパスワードも許容されるように思われていました。今日では、その設計思想は脆弱性そのものです。

• 静的なシークレットと MFA の欠如 → 盗まれやすく、安全にローテーションするのも困難
• 初期設定で過剰な権限 → 「とにかく動かす」ための権限が恒久的に残る
• ライフサイクルの欠如 → 放置された孤立アカウントが、移行や組織再編を生き延びる
• 監査性の低さ → 「誰が、なぜ使ったのか」は推測とスクリーンショット頼み
• 例外を容認する文化 → ボット向けの CA/MFA 除外設定が、攻撃対象領域を静かに広げる

マネージド ID：良い一歩だが Azure に限定される

組織が静的なサービス アカウントの危険性に気づくと、最初に向かうのは多くの場合 Azure マネージド ID です。マネージド ID は、Azure でホストされるリソースについてシークレットを完全になくせるため大きな前進ですが、明確な境界もあります。

• ✅ Azure ネイティブリソース（Functions、VM、Logic Apps）へのシークレットレス アクセス
• ❌ ハイブリッド/サードパーティのターゲットに対するギャップ、所有者の対応付けの弱さ、ガバナンス ビューの限界
• ❌ Azure 以外のサーフェスでは、CA やアクセス許可の適用範囲が統一されていない

Workload Identities：実際に得られるもの

ここで Microsoft Entra Workload Identities の出番です。非人間のアクターを二級の存在として扱ったり、Azure のみの制約に縛ったりするのではなく、Workload Identities はアプリケーション、スクリプト、自動化サービスを一級のセキュリティ プリンシパルに引き上げます。

• 一級の非人間 ID（アプリ、スクリプト、コネクタ、RPA、統合）
• スコープ付きのアクセス許可（Graph/リソース ロール、アプリ専用認証）による最小特権
• 業務プロセスに紐づくライフサイクル（所有者、レビュー周期、廃止フロー）
• ワークロード向けの条件付きアクセス（リスクやコンテキストに応じたゲート、対応している場合はセッション制御）
• 資格情報の衛生管理（短期間有効なシークレット、証明書、キーのローテーション ポリシー）
• 統合された可視性（サインイン、トークン、リソース アクセス、変更履歴）→ 監査に対応可能

比較マトリックス（概要）

アーキテクチャ パターン（代表的なユースケース）

ワークロード ID を実装するには、アーキテクチャのパターンに正しく対応づける必要があります。よく使われるエンタープライズ ワークロードへの適用方法は次のとおりです。

• Power Platform コネクタ / クラウド フロー -> 統合ごとに ワークロード ID を割り当て、必要な Graph / Dataverse のスコープのみを付与します。
• 基幹業務アプリ（Web API、デーモン）-> アプリの登録と証明書を使用し、アプリ ロールとアプリ専用の Graph アクセスを使います。該当する場合は条件付きアクセスを適用します。
• 自動化スクリプト（Azure Automation、GitHub Actions、DevOps）-> フェデレーション資格情報（OIDC）を使用し、シークレットは保存しません。
• テナント間 / B2B のジョブ -> テナントの境界ごとに専用のワークロード ID を用意し、権限とログを分離します。

移行プレイブック（90 日、混乱を抑えた進め方）

何百ものレガシー サービス アカウントに取り組むのは、途方もなく感じられるかもしれません。だからこそ、90 日間にわたってリスクを減らすことに焦点を当てた、体系的な移行プレイブックが必要になります。

フェーズ 1 — 検出と優先順位付け（0〜3 週目）

1. 人によらないサインインとオブジェクトを洗い出します。対象は svc-*、app-*、共有メールボックス、アプリの登録、90 日以内に期限切れとなるシークレットです。
2. 各項目を、所有者、業務上の目的、対象、アクセス許可、緊急アクセス アカウントへの依存関係に対応づけます。
3. リスクの順位を付けます。判断基準は、静的なパスワード、グローバル ロール、所有者の不在、最近のローテーションの欠如です。

フェーズ 2 — 高リスクのものから変換（4〜8 週目）

1. 統合ごとに ワークロード ID を用意します（使い回さないでください）。
2. パスワード認証を 証明書またはフェデレーション資格情報に置き換え、ローテーションを設定します。
3. アプリ専用のアクセス許可に移行し、不要なユーザー委任のアクセス許可は削除します。
4. ワークロードのサインインに対して、（サポートされている場合は）条件付きアクセスポリシーを適用します。
5. アクセス レビュー（四半期ごと）を実装し、CMDB / ITSM で所有者を管理します。

フェーズ 3 — 廃止とガバナンス（9〜12 週目）

1. 古いサービス アカウントを無効化し、14 日間監視してから削除します。
2. 作成標準を徹底します。命名規則、所有者、データ分類、レビューの頻度を定めます。
3. アラートを追加します。対象は、異常なサインイン、30 / 60 / 90 日を超えて非アクティブな ID、期限切れが近いシークレットです。
4. ID チェックを CI/CD に組み込みます（ポリシー as コード）。

条件付きアクセスとアクセス許可（実践的なガードレール）

最新の ID プラットフォームで特に強力な機能の 1 つは、人によらないアクターに特化したガードレールを適用できることです。人のポリシーとワークロードのポリシーを分けることで、ボットが「実現不可能な移動」のアラートを発生させることを防ぎつつ、悪意のあるトラフィックはブロックし続けられます。

• 人のための ID とワークロードのための ID に対してポリシーを分けます。ワークロードについては対話型サインインをブロックします。
• 可能な場合は、アプリ専用のアクセスに対して名前付きの場所 / ネットワーク制限を設定します。
• 期間を限定した資格付与を行います（利用可能な場合はアプリ ロールに対する PIM、定期的なアクセス レビューのスケジュール設定）。
• スコープは、ディレクトリ全体の権限よりも、アプリ ロールやリソース固有のロールを優先します。

ログと監査（監査人に示すべき内容）

コンプライアンス担当者や監査人が確認に来ると、バックエンド スクリプトへのアクセス権を誰が持つのかについて、もはやスプレッドシートや口頭での説明では納得されません。一元化されたログによって、ガバナンスをその場で証明できる必要があります。

• アプリ / ワークロードの所有者、目的、データの機密性
• サインイン ログ（サービス プリンシパルのサインイン）、トークンのオーディエンス、IP アドレス、クライアント アプリ
• ロールの割り当て（誰が承認し、いつ認定されたか）
• 資格情報の履歴（種類、最後のローテーション、有効期限）
• ライフサイクル：作成、変更、無効化、削除と、その変更を行った実行者

KPI ダッシュボード（改善を証明する）

経営層の継続的な支持を得るために、人によらない ID のリスク低減が時間とともにどう進んでいるかを示す主要業績評価指標を追跡し、報告します。

• 所有者とレビューの頻度が設定された人によらない ID の割合（目標 95% 以上）
• 孤立したサービス アカウント（目標は 0 件）
• 90 日を超えたシークレット（目標は 0 件。証明書またはフェデレーション資格情報を優先）
• アプリ専用ロールの広さ（「Directory.ReadWrite.All」の数。減少傾向であること）
• 人によらないアクセスに関する監査の指摘事項（四半期ごとに減少）

排除すべきアンチパターン

環境を整理する際は、チームが古い習慣に戻らないように注意してください。次のアンチパターンは直ちになくしてください。

• 1 つの汎用サービス アカウントを多数のシステムで使い回すこと
• スクリプトや web.config、あるいは Key Vault にパスワードを埋め込み、ローテーション ポリシーを設けていない
• ジョブを動かし続けるために「念のため」とグローバル管理者 / 所有者の権限を付与する
• 期限のない「一時的な」条件付きアクセスの例外

クイックウィン（今週中に実施できること）

セキュリティ態勢を改善するために、大規模プロジェクトの開始を待つ必要はありません。今週中に実行できる 4 つのクイックウィンをご紹介します。

• 人間以外のすべての ID に、所有者、システム、データ分類のタグを付けます。
• リスクの高いジョブを 1 つ選び、フェデレーション資格情報（GitHub OIDC -> Entra）に切り替えます。
• Power Automate で共有のサービス アカウントを使っている場合は、ワークロード IDに置き換えます。
• 有効期限が近い、または期限切れのシークレットを持つサービス プリンシパルのレポートを作成し、アラートをスケジュールします。

よくある質問（手早く回答）

ワークロード ID を使うと、レガシーなオンプレミスのジョブが動かなくなりますか？
いいえ。アプリのみの認証、証明書、またはブローカー サービスを使って橋渡しし、パスワードは段階的に廃止してください。

人間以外のサインインに条件付きアクセスを適用できますか？
はい。サポートされているフロー（サービス プリンシパルのサインイン）で適用できます。該当する場合はネットワーク、場所、デバイスの信号を使用し、対話型のサインインはブロックしてください。

無秩序に増えるのを防ぐにはどうすればよいですか？
チームごとではなく、連携ごとに 1 つのワークロード ID を作成します。作成時に命名規則、所有者、レビューを必須にし、一定期間使われていないものの削除は自動化してください。

Power Platform の場合はどうですか？
コネクタや Dataverse にはサービス プリンシパル / ワークロード IDを使用し、共有のユーザー アカウントの利用はやめてください。

まとめ

サービス アカウントのリスクは、ローテーションだけでは解消できません。Entra ワークロード IDを使えば、人間のアクセスに求めているのと同じゼロトラスト、ライフサイクル管理、監査の仕組みに人間以外のアクセスも組み込めます。障害や大きな手間をかけることなく実現できます。まずはリスクの高い「svc-」アカウントから着手し、ガバナンスの効いたワークロード ID に移行して、例外を本来の例外に戻しましょう。

この記事を気に入っていただけたら、ぜひポッドキャストのエピソード Replace Service Accounts with Entra Workload Identities で詳しい議論もご覧ください。エンタープライズの Microsoft 365 と Azure のセキュリティ戦略をさらに深掘りする番組も、ぜひご購読ください！