サービスIDの棚卸しと移行 ─ MFA展開の最後に残るID

MFAを全社へ展開すると、最後に「人がいないから承認できないID」が残る。それをサインインログから見つけ、ひとつの台帳へ載せ、実行場所とトークン発行能力で移行先を決めるまで。人へのMFAとTeams Rooms等の機器は別デッキに分割した。

動画で見る

MFAをかけられないIDをどうするか

多要素認証を全社へ広げよう、と決まった組織で必ず起きることがあります。人のアカウントは順調に進むのに、最後に「多要素をかけられないID」がまとまって残る。今日はそれをどう見つけて、どこへ移すかという話です。

解説する人：胡田昌彦

解説する胡田昌彦です。Microsoft MVPを14年連続で受賞し、Windows、Azure、Microsoft 365を実機で検証してきました。今日は運用の現場で必ず詰まるところだけを扱います。

「今年こそMFAを全社へ」

想定する組織は、これまで多要素認証を本格的には適用してこなかった組織です。ランサムウェアの事例、保険や監査の要件、取引先からの要請。こうした理由で全社展開が決まります。人のアカウントの展開自体は、実はそれほど難しくありません。

人がいないIDには、多要素をかけられない

多要素認証は、知っているもの、持っているもの、体の特徴といった異なる種類の要素を組み合わせて、利用者本人を確かめる仕組みです。ここで二つに分けます。サービスプリンシパルやマネージドIDのようなワークロードIDには、そもそも多要素認証という考え方を適用しません。一方で、夜間バッチやRPAがユーザーのIDを使っている場合は、IDとしては登録できても、承認する人がその場にいないので実質的に通せません。技術的な工夫の前に、まずこの区別から始めます。

そして「除外グループ」が生まれる

かけられないので除外します。ここまでは仕方がない。問題はその後です。除外グループは一度作ると必ず育ちます。困ったらここへ入れる、という運用になり、誰も中身を見なくなる。全社に多要素を入れたのに、攻撃者から見て一番おいしい入口が一箇所にまとまってしまう、という結果になりかねません。

「サービスID」と呼んでいるもの

呼び方は組織によって違います。サービスアカウント、システム利用ID、共有アカウント。共通しているのは、人が対話的にサインインしない、あるいは特定の人に紐づいていないIDだということです。まずは自分の組織にどれがあるかを言葉にします。

本来は、最初から分かれているはず

先に整理しておきます。IDの管理がきちんとできている組織なら、こうなっているはずです。人にはAさん、Bさんという個人のIDがある。自動化したいときは、人のIDを使わずに専用のIDを用意して権限を割り当てる。これができていれば、今日の話の半分は要りません。人には多要素認証をかけ、自動化にはワークロードIDを使う。それで終わりです。

実際に問題になるのは、この3つ

ではなぜ話が長くなるのか。実際に詰まるのは三つです。一つ目、Aさんのアカウントを、本人が対話的に使いながら、同じアカウントで自動化にも使ってしまっているケース。Microsoftも必須MFAの案内で、ユーザーアカウントをサービスアカウントとして使っている顧客がいる、ワークロードIDへ移行することを推奨する、と名指ししています。二つ目、システム用として作ってはいるが、器が人のIDと同じというケース。ここは正確に言います。多要素認証を登録すること自体はできます。問題は、無人で動いているので、要求された時点で承認する人がおらず止まってしまうことです。三つ目、これは運用の失敗ではなく製品の仕様ですが、Teams RoomsやBookingsのリソースアカウントです。人ではないのにユーザーオブジェクトとして存在し、Microsoftが公式に多要素認証をかけるなと書いています。

あなたの組織は、どちらですか

ここで一度分岐します。自動化用のIDが台帳で分かれていて、どれが人でどれがシステムかを即答できる組織。この場合、次の棚卸しのセクションは飛ばして構いません。移行先を決めるところから始めてください。一方で、即答できない、あるいは人のIDで動いている自動化がありそうだ、という組織。こちらが棚卸しの対象です。そして正直に言うと、これまで多要素認証を本格的に適用してこなかった組織で、サービスIDの台帳だけが整っている、というのはあまり見かけません。多要素認証を強制する仕組みが無かったからこそ、人のIDで自動化しても誰も困らなかった、という関係にあるからです。

SECTION 1 ─ どこにいるのかを見つける

一つ目のセクション、棚卸しです。分類できていない組織はここから。できている組織はSECTION 2へ進んでください。

サインインログは、4種類ある

棚卸しは手作業だと思われがちですが、サインインログでかなりの部分が埋まります。ここで大事なのは、サインインログが一種類ではないことです。対話型、非対話型、サービスプリンシパル、マネージドIDの4つがあります。旧来のサインインログの画面は対話型しか含みません。対話型のタブだけを見て「サービスIDは見当たらない」と結論するのが典型的な取りこぼしです。

今のログを、3つに仕分ける

まだ多要素をかけていない今の状態のログを見て仕分けます。ここで一つ、大事な注意があります。非対話型サインインのログは、サービスIDだけが並ぶ場所ではありません。普通の利用者の端末やアプリが、裏でリフレッシュトークンを使ってトークンを取り直した記録も、ここに大量に入ります。だから非対話型を丸ごとサービスID扱いすると、大半が誤検出になります。確実にワークロードIDだと言えるのは、サービスプリンシパルとマネージドIDのログです。人が対話でサインインしているものは、そのまま多要素の対象。そして非対話型は、利用者、クライアントアプリ、認証プロトコル、業務用途を追加で確認して、初めてサービスアカウントを抽出できます。

それでも、ログで埋まらない5つ

ただし万能ではありません。保持期間、既存トークン、Entra IDを通らない認証、所有者情報、そして規模。特に保持期間は重大で、既定の保持はEntra ID Freeで7日、P1とP2で30日です。四半期ごとのバッチはこの窓では絶対に捉えられませんし、月次でも調べるタイミング次第で漏れます。しかも診断設定を入れていないと、過去へ遡ることはできません。

最初にやるのは、ログを貯め始めること

順番として、棚卸しの前にログの保持を延ばします。診断設定でLog Analyticsやストレージへ送っておけば、あとから長い期間で集計できます。ここを後回しにすると、3か月後に同じ場所で止まります。今日からできる一番安い一手です。

出てきたIDを、1つの台帳へ

ログから出た情報を台帳にします。列はこの通りです。ここで大事なのは、多要素の例外台帳と、他のブロック施策の例外台帳を別々に作らないこと。別々に作ると、片方だけ見直されないIDが必ず残ります。台帳は一つにします。

台帳の「人にしか埋められない列」

ログが埋めるのは、何が、いつ、どこから、何に、までです。誰の持ち物で、止めていいのか、いつ廃止するのかは、どこにも書かれていません。ここが棚卸しの本当のコストです。逆に言えば、機械が大半を埋めた表を持って所有者を探しに行く形にできれば、作業量は現実的になります。

SECTION 2 ─ どこへ移すのかを決める

二つ目のセクション、移行先です。ここは判断の順番さえ決めれば、機械的に振り分けられます。

移行先は、4つの質問で決まる

上から順に答えるだけです。人が操作するなら、それは人のIDなので多要素をかけます。無人なら、動く場所を見ます。Azureの中で、かつ実行元のリソースがマネージドIDに対応し、接続先もMicrosoft Entra認証を受け付けるならマネージドID。場所だけでは決まらない点に注意してください。Azureの外なら、そのワークロードがMicrosoft Entraの要件を満たすOIDCトークンを発行できるかどうか。発行できるならフェデレーション。できないなら、資格情報を安全に保管できるかどうかで、証明書を使うアプリケーションか、期限付きの例外かが決まります。

アプリ名だけで判断してはいけない

一つ注意です。同じアプリ名でも答えが違います。たとえばコマンドラインツールが出てきたとき、人が手で叩いているのか、スクリプトが無人で回しているのかで、最初の質問の答えが変わります。台帳に「人の操作があるか」という列を必ず作る理由がこれです。

Azureの中なら、マネージドID

Azureの中で動く処理なら、マネージドIDが第一候補です。IDそのものをAzureが管理するので、パスワードもシークレットもコードに出てきません。種類は二つあります。リソースと一対一で、リソースを消せば一緒に消えるのがシステム割り当て。独立したリソースとして先に作れて、複数から共有でき、フェデレーションも設定できるのがユーザー割り当てです。前提として、実行元のAzureリソースがマネージドIDに対応していることを確認してください。

Azure Arcを入れれば、「Azureの中」にできる

ここが実務では効きます。オンプレミスや他社クラウドのサーバーでも、Azure ArcでオンボードすればマネージドIDを持てます。判断の木で言えば、Q2を「いいえ」から「はい」に変えられる、ということです。正確に言うと、処理が動く場所はオンプレのままで、そのサーバーがAzureのリソースとして管理できるようになり、サーバー上のプロセスがローカルのエンドポイントからトークンを取れるようになります。なおArc対応サーバーで使えるのはシステム割り当てマネージドIDです。対応OSはWindows Server 2012から2025まで、ただし2012と2012 R2は2026年11月にArcのサポートが終了予定です。Windows 10と11のクライアントも対応表に入っていますが、常時インターネットに接続され、電源につながれ、電源が入っている、サーバーのような使い方をしている場合に限られます。デジタルサイネージやPOS、バックオフィス端末が例として挙げられていて、長時間オフラインになる業務用PCは対象外です。そちらはIntuneかConfiguration Managerを使ってください、と明記されています。

マネージドIDが使えない場合もある

万能ではありません。三つ条件があります。Azureの外でArcも入れられない場所。実行元のリソースがマネージドIDに対応していない場合。そして接続先のサービスがMicrosoft Entra認証を受け付けない場合です。使えるかどうかは、実行元と接続先の両方で確認します。

要件を満たすOIDCトークンを出せるなら、フェデレーション

Azureの外のワークロードでも、Microsoft Entraの要件を満たすOIDCトークンを発行できるなら、Workload identity federationが使えます。相手が発行する短命なトークンを、あらかじめ登録した発行者、サブジェクト、オーディエンスの組み合わせに基づいて、Entraのトークンと交換する仕組みです。長期のシークレットを相手側へ保存しなくてよくなるのが最大の利点です。OIDCなら何でも通るわけではなく、署名方式などの要件があります。

3つの器を並べて比べる

フェデレーションを組むとき、器は二つから選べます。よく「どちらが安全ですか」と聞かれますが、安全性の優劣ではなく、IDをどこで何として管理するかという違いです。あわせてシステム割り当てマネージドIDも並べておきます。フェデレーション資格情報を設定できるのは、ユーザー割り当てマネージドIDと、アプリ登録で作られるアプリケーションオブジェクトだけです。システム割り当ては対象外です。なおアプリ登録の場合、資格情報はアプリケーションオブジェクト側に設定しますが、実際にテナント内で権限を持って動くのは対応するサービスプリンシパルです。

フェデレーションで必ず確認すること

設定するときは、この四つをセットで確認します。信頼する相手を、組織全体ではなく対象のリポジトリや環境まで絞ること。本番と非本番でIDを分けること。権限は必要な範囲へ最小限で付けること。そして、フェデレーション資格情報は1つのIDあたり最大20件なので、多数の対象を1つのIDへ集約しないことです。

展開の順番

全体の順番をまとめます。ログの保持を延ばす。棚卸しして台帳を作る。所有者を確定させる。移行できるものから先に移す。残すものを檻に入れる。レポート専用モードで測る。分割して有効化する。そして切り戻しの単位を先に決めておく。緊急時にポリシー全体を無効化するのではなく、決めた単位で戻せるようにしておくことが大事です。

補足：テナントの除外が効かない場所がある

補足を一つ。Microsoftが定めた必須の多要素認証があります。対象はAzureポータル、Microsoft EntraとIntuneとMicrosoft 365の各管理センター、そして第2段階としてAzure CLI、Azure PowerShell、IaCツール、Azure Resource ManagerのREST APIです。Azure上のすべてのアプリが対象という意味ではありません。重要なのは、自分のテナントの条件付きアクセスで除外を設定していても、その除外はもう効かない、と公式に書かれていることです。緊急アクセス用のアカウントも対象で、パスキーか証明書ベース認証を設定するよう案内されています。一方、マネージドIDとサービスプリンシパルはこの必須化の対象外です。だからユーザーのIDで自動処理を回している構成は、除外では守れず、ワークロードIDへ移すのが答えになります。

覚えるのは、この3つ

まとめます。一つ目、多要素がかけられないことと、弱いままでよいことは別です。無人で動くものには、多要素の代わりにシークレットを持たない仕組みを与えます。二つ目、棚卸しはサインインログで大半が埋まりますが、非対話型を丸ごとサービスID扱いしないこと。残るのは所有者を探す作業です。三つ目、移行先は動く場所と、対応状況と、トークンを発行できるかで決まります。ここで本編はおしまいです。

この続きは、別の回で

今日は棚卸しと移行までを扱いました。ここで扱いきれなかった二つを、別の回に分けています。一つは、MFAをかけられない機器の守り方。Teams Rooms、ROPC、デバイスコードフローの話です。もう一つは、人にどうMFAをかけるか。使える方式の選択肢と、フィッシング耐性の話です。どちらも同じ場所に置いてあります。

体系的に、順番に学びたい方へ

続けて体系的に学びたい方向けに、Ebi StudyでMicrosoft資格、Windows Server、Azure、Claude Codeの動画講座を提供しています。ID関連は、アカウントとテナントの基礎、Entra ID認証と自動化、証明書の3コースが揃っています。月額990円です。

Microsoft公式ドキュメント

今日の内容の一次資料です。認証方式の一覧、ゲストの認証と条件付きアクセス、認証フロー条件、継続的アクセス評価、Azure Arcの前提条件。設定前には必ず最新の文書を確認してください。

ご視聴ありがとうございました！

最後までご視聴いただき、ありがとうございました。役に立ったら高評価とチャンネル登録をお願いします。これからもWindows、Azure、Microsoft 365、生成AIの難しいテーマを分かりやすく解説していきます。

Ebisuda Presentations のトップへ