グローバル管理者の乗っ取りや悪意あるアプリ同意、条件付きアクセス改ざんで Microsoft Entra ID テナントの根本的な信頼が崩れたとき、最も難しいのは「元テナントを直すか、新規テナントへ移行するか」の判断です。本記事では判断基準と、移行・復旧それぞれの実務手順を整理します。
結論から言うと、Microsoft Entra ID（旧 Azure AD）テナントが「ルートトラスト（根本的な信頼）」を失った疑いが強い場合、原則は新規でクリーンな Entra/Microsoft 365 テナントを構築し、重要な ID とワークロードを段階的に移行する方が安全です。一方で、契約・業務・コストの制約から「元テナントをインプレースで復旧して使い続ける」判断を迫られることもあります。ここでは、判断の軸と、どちらを選んでも破綻しないための実務手順を、現場目線でまとめます。
「ルートトラスト喪失」とは何か
ルートトラスト喪失とは、単にユーザーが侵害されたというより、テナントを信頼してよい根拠（誰が管理者で、どのアプリが権限を持ち、どのポリシーが認証を制御しているか）が崩れた状態を指します。典型例は次の通りです。
- グローバル管理者（Global Administrator）や特権ロールが乗っ取られ、誰が管理者か把握できない
- 悪意あるアプリに管理者同意（Admin Consent）が付与され、API 権限で継続的にデータへアクセスされる
- 条件付きアクセス（Conditional Access）が改ざんされ、攻撃者だけが通れる「例外ルート」が作られる
- PIM やロール割り当て可能グループの設定が壊され、間接経路で権限が付与され続ける
- 監査ログの保持期間やエクスポートが妨害され、何が起きたか追えない
| 疑うサイン | 具体例 | 見落とすと起きること |
|---|---|---|
| 想定外の特権ロール | 見覚えのない GA、Privileged Role Administrator、Application Administrator | 復旧作業そのものが妨害される／再侵入される |
| 不審なエンタープライズ アプリ | Verified publisher ではない、説明文が空、権限が過剰（Mail.Read、Files.Read.All 等） | パスワード変更後も API 経由で情報が抜かれる |
| 条件付きアクセスの例外 | 特定の国・IP を除外、特定ユーザーのみ MFA 免除、レガシー認証許可 | 攻撃者が「自分だけ安全にログイン」できる |
| ログの欠落・保持短縮 | 監査ログの保持が短い、エクスポートが止まっている | 侵害範囲が特定できず、復旧判断ができない |
まず決めるべきこと：復旧か、新規テナント移行か
迷ったときは、次の3つの質問で整理すると判断しやすくなります。
- 根本的な信頼を「証明」できるか：攻撃者の持続性（しつこい仕掛け）を完全に取り除けたと言い切れるか
- 影響範囲を「把握」できるか：監査ログや設定差分で、何が変えられたか追えるか
- ビジネス制約：ドメイン移管、メール停止許容、アプリ改修、端末再登録の許容度
| 観点 | インプレース復旧（元テナント継続） | 新規テナント移行（クリーン再構築） |
|---|---|---|
| 安全性の確実性 | 「安全になった証明」が難しい。見落としが1つでも残ると再侵害 | クリーン基盤から作るため、信頼回復の根拠を作りやすい |
| 復旧スピード | 短期復旧は速い場合があるが、後から発覚してやり直しになることも | 設計と移行が必要。段階移行で業務継続しながら進めやすい |
| 運用・依存関係 | 既存の Teams/SharePoint/SSO 依存は維持しやすい | オブジェクトID変更、SSO 再設定、端末再登録が発生しやすい |
| フォレンジック | 「運用しながら証拠を保つ」難易度が高い | 元テナントを調査専用に縮小しやすい |
| 長期コスト | 監視強化・再発対応で累積コストが増えやすい | 初期コストは増えるが、再発リスク低減で回収しやすい |
判断フローチャート（簡易）
「絶対の正解」はありませんが、次の条件に複数当てはまるほど、新規テナント移行が現実的になります。
| チェック | はい（当てはまる） | いいえ（当てはまらない） |
|---|---|---|
| GA/特権ロールが侵害された、または管理者の正当性を確認できない | 新規テナントを軸に計画（旧テナントは調査用に縮退） | インプレース復旧の選択肢が残る |
| 不審な管理者同意・サービスプリンシパルが複数見つかった | 新規テナント寄り（同意ガバナンスを作り直す） | 影響範囲が限定なら復旧で対応できる場合も |
| 条件付きアクセスや認証設定の改ざんが疑われる | 新規テナント寄り（強いポリシーをゼロから） | 差分が追えるなら復旧で矯正可能 |
| 監査ログが欠落しており、変更点を追えない | 新規テナント寄り（「証明不能」を前提にする） | ログが揃っていれば復旧の確度が上がる |
| バックアップ／テンプレートが汚染されている可能性が高い | 新規テナント寄り（参照して再作成） | 安全な基準構成があれば復旧の手戻りが減る |
初動でやってはいけないこと
重大侵害では、良かれと思った行動が被害を拡大させたり、証拠を消したりします。少なくとも次は避けるのが無難です。
- 侵害疑い端末から管理作業を続ける：再侵入の踏み台になります
- 原因不明のまま設定を大量変更する：調査が困難になり、後でやり直しになる
- 旧テナントの設定を“丸ごとコピー”する：悪意ある同意・例外・過剰権限を再現する
- 最小権限を無視して緊急付与を常態化する：復旧後の運用が破綻しやすい
なぜ「新規テナント」が安全と言われるのか
最大の理由は、攻撃者の「持続性」をゼロにしたと証明するのがほぼ不可能だからです。Entra ID はクラウドサービスであり、オンプレ AD のように「DC を全再構築してクリーンに戻した」と言い切るのが難しく、設定・権限・同意の組み合わせが広範です。
特に見落としやすい“残り方”は次の通りです。
- サービス プリンシパル／エンタープライズ アプリ：管理者同意済みの権限が残ると、ユーザーのパスワード変更後も API でデータに触れます
- アプリの資格情報：アプリに追加された証明書・シークレットは、期限が長いほど厄介です
- 条件付きアクセスの抜け道：例外ユーザー、例外ロケーション、古い認証方式の許可など
- 間接的なロール付与：PIM の設定、ロール割り当て可能グループ、ディレクトリ書き込み権限を持つアプリなど
- 外部連携：クロステナント設定、ゲスト、連携アプリ、コネクタ類
バックアップも攻撃の影響を受けている前提なら、過去のエクスポートやテンプレートをそのまま戻すこと自体がリスクになります。「復旧＝元に戻す」ではなく、「信頼できる構成を再定義する」と考える方が現実的です。
新規テナント移行を選ぶ場合の実務ロードマップ
「新しいテナントへ移る」と決めた瞬間に、やることは大きく4つに分解できます。被害の封じ込め、クリーン基盤の構築、移行、旧テナントの縮退です。
| フェーズ | 目的 | 主な作業 | つまずきポイント |
|---|---|---|---|
| 封じ込め | 追加被害を止め、証拠を残す | 特権アカウント保護、サインイン抑制、ログ保全、転送・ルールの停止 | 拙い初動で証拠が消える／攻撃者に気付かれて対抗される |
| クリーン基盤 | 信頼の起点を作る | 新テナント作成、最小権限設計、PIM、条件付きアクセス、同意ガバナンス | 急ぎ過ぎて「旧テナントの弱い設計」を踏襲する |
| 移行 | 業務を止めずに移す | ID、デバイス、メール、ファイル、Teams、SSO を順に切替 | ドメイン移管のタイミング、アプリ改修、端末再登録の工数 |
| 旧テナント縮退 | 再侵害リスクを減らし調査に集中 | ログ保存、アクセス最小化、必要最小の参照用途に限定 | 旧テナントを放置して“裏口”として残す |
封じ込めで優先すべきこと
「新規テナント移行」を選んでも、旧テナントはすぐ消せません。まずは追加被害（データ流出、ルール改ざん、横展開）を止めつつ、後で検証できるだけのログを守ります。
- 調査用のクリーン端末／クリーンネットワークを用意：侵害端末からの操作は避ける
- 特権アカウントの再確保：緊急アクセス（ブレークグラス）を含め、特権経路を把握する
- セッションの遮断：ユーザー・管理者・アプリのサインイン セッションを失効させる（可能な範囲で）
- ログの保全：Entra のサインインログ／監査ログ、Microsoft 365 監査ログ、メール転送設定などを優先して保存
この段階でのポイントは、「復旧のための変更」を急ぎすぎないことです。証拠が上書きされると、侵害経路や影響範囲が特定できず、移行先の設計にも穴が残ります。
クリーンテナントを「最初から強い状態」で作る
新規テナントは、単に作ってユーザーを入れるだけでは意味がありません。最初の1週間の設計が、その後数年の安全性を決めます。最低限、次の設計を“デフォルト”にします。
- 管理者アカウント分離：日常利用アカウントと管理者アカウントを分ける
- PIM 前提：常時 GA を持つ人を極小化し、必要時に昇格（JIT）
- 条件付きアクセスの強制：強い MFA（できればフィッシング耐性）、準拠デバイス、場所やリスクに応じた制御
- 同意ガバナンス：ユーザー同意を制限し、管理者同意のワークフローを整備
- ログと監視：サインインの異常検知、特権操作のアラート、ログ保管（SIEM 連携）
| 設定領域 | 最低ライン | 意図 |
|---|---|---|
| 特権管理 | PIM を有効化、GA は原則 JIT、ロール割り当てはレビュー対象 | 侵害時の爆発半径を小さくする |
| MFA | 管理者はフィッシング耐性 MFA（FIDO2/証明書等）を優先 | パスワード漏えいだけで突破されない |
| 条件付きアクセス | 管理操作・高リスクサインインは強制ブロック／追加検証 | 攻撃者の再侵入を難しくする |
| 同意 | ユーザー同意を制限、管理者同意は審査制 | 悪意ある OAuth アプリを入り口にしない |
| 監査 | 監査ログの保持とエクスポート、アラート運用 | 次の異常を早期に検知する |
ID（ユーザー）移行の考え方
ID 移行では「何を引き継がないか」を先に決めるのがコツです。侵害が疑われる環境からは、権限・同意・ロール・アプリ資格情報をそのまま持ち込まない方が安全です。移行の基本は次の順序です。
- 管理者基盤を確立：ブレークグラス、PIM、条件付きアクセスを整える
- 一般ユーザーのアカウントを作成：強制パスワード変更・MFA 登録を新テナント側で実施
- 権限（グループ・ロール）を最小から付与：“必要になったら追加”を徹底
ハイブリッド（オンプレ AD 連携）の場合は、オンプレ側が侵害されていないかの確認が先です。侵害が疑われる場合、同期元の AD をそのまま使うと「汚染された ID」が新テナントに流れ込みます。パスワードリセット、管理者グループの再点検、同期サーバーの再構築など、ID の源流をクリーンにする作業が必要になります。
ドメイン（例：example.com）移管の落とし穴
Microsoft 365 の実運用では、メールや UPN に使っているカスタムドメインが最大の依存関係です。一般に、同じドメインは同時に2つのテナントに割り当てられません。そのため、移行設計では次を必ず押さえます。
- 一時ドメインで新テナントを先に組む：最初は onmicrosoft.com や一時 UPN で検証する
- メールの切替手順を作る：MX、Autodiscover、SPF/DKIM/DMARC、送信コネクタ等の変更点を棚卸し
- 切替後の再設定を見込む：SSO、SaaS のリダイレクト URI、アプリの許可ドメインなど
ワークロード移行は「重要度順」に分ける
テナント移行を一気にやると失敗します。業務への影響が大きいものから順に、切替点（カットオーバー）を明確にした小さな移行を積み重ねる方が安全です。
| 対象 | 優先する観点 | 移行アプローチ例 | 注意点 |
|---|---|---|---|
| Exchange Online（メール） | 業務停止を最小化 | 段階移行（部門別）、短期は転送・共同運用で吸収 | 転送設定・ルールが侵害されていないか検査が必須 |
| OneDrive/SharePoint | 情報漏えい防止 | 必要データのみ選別して移行、移行後に DLP/ラベルを適用 | 共有リンクの棚卸し、外部共有の再設計 |
| Teams | コミュニケーション継続 | チーム構造は再構築を前提にし、重要チャネルから復元 | アプリ連携（Webhook/コネクタ）の再登録 |
| Intune/端末 | 端末の信頼回復 | 再登録（再参加）を前提。重要端末から順に準拠化 | 侵害端末を持ち込むと新テナントも危険 |
| SSO/業務アプリ | 認証の穴を作らない | アプリを新規登録し、必要最小権限で再同意。秘密情報は全ローテーション | 旧テナントのアプリ同意をコピーしない |
旧テナントは「調査用の隔離環境」として残す
新テナントへ切り替えた後も、旧テナントはすぐ削除せず、調査・証跡保存・参照用として段階的に縮退させます。ポイントは「ユーザーが日常的にログインし続ける環境」から外すことです。アクセス可能な管理者を最小化し、監査ログの保管と、必要なデータの読み取りに用途を限定します。
それでもインプレース復旧を選ぶなら：最低限やるべき必須対応
インプレース復旧（元テナント継続）は、「短期の業務継続」を優先する場合に選ばれがちです。ただし、ルートトラスト喪失が疑われるなら、復旧の本質は“清掃”ではなく“作り直しに近い再構築”になります。ここでは、見落とすと復旧が破綻する項目をチェックリスト化します。
| 領域 | 必須作業 | 具体的な観点 |
|---|---|---|
| 特権アカウント | GA を含む特権アカウントの総入れ替えと多要素の再登録 | 未知の GA 削除、既存 GA のパスワード変更、MFA 要素再登録、管理者用アカウント分離 |
| セッション／トークン | 全ユーザー・アプリのセッションを失効 | revokeSignInSessions 等でリフレッシュ トークンや継続セッションを遮断（可能な範囲で） |
| アプリ同意 | 不審アプリ削除、同意の棚卸し、過剰権限の剥奪 | エンタープライズ アプリ／アプリ登録／資格情報（証明書・シークレット）の洗い出し |
| 条件付きアクセス | ポリシー改ざんの検証と再構築 | MFA 免除の例外、場所例外、古い認証許可、緩いポリシーの削除 |
| ロール付与経路 | PIM、ロール割り当て可能グループ、間接権限を再点検 | 「誰が」「なぜ」その権限を持つかを説明できる状態に戻す |
| ゲスト／外部連携 | 招待経路・ゲストの棚卸し、外部共有の再設計 | 想定外ゲスト削除、クロステナントアクセスの見直し、共有リンクの整理 |
特権アカウント復旧の現実的な進め方
インプレース復旧で最初にやるべきは「復旧作業を行う人の権限が正しい」状態を作ることです。手順のイメージは次の通りです。
- クリーン環境から管理操作：侵害疑い端末は使わない
- 特権ロールの棚卸し：GA だけでなく、Privileged Role Administrator / Security Administrator / Application Administrator も対象
- パスワード・MFA の再登録：盗まれた可能性がある要素（SMS、古い TOTP シード等）を捨てる
- ブレークグラスの再定義：緊急用は最小人数・厳重保管・ログ監視をセットで運用
注意点として、ブレークグラスを条件付きアクセスから除外する運用は一般的ですが、除外するほど監視と保管が重要になります。除外だけして放置すると、攻撃者にとって最高の標的になります。
「アプリ同意」が残ると復旧は失敗する
Entra ID の侵害で特に厄介なのが、OAuth アプリへの同意（特に管理者同意）です。ユーザーのパスワードを変えても、攻撃者が登録したアプリが有効なままだと、Graph API 等でデータへアクセスし続けられる可能性があります。
インプレース復旧では、次の考え方を徹底します。
- “必要なアプリだけ残す”が基本：必要性が説明できないアプリは停止・削除の候補
- 権限は最小にし直す：過剰な
*.Read.Allやディレクトリ書き込み権限は特に警戒 - 秘密情報は全ローテーション：アプリのシークレット・証明書、Webhook、外部サービスの API キーを総点検
条件付きアクセスは「差分」で見る
条件付きアクセスの改ざんは、見た目が“それっぽい”ため見逃されがちです。おすすめは、復旧中に次の3点を必ずチェックすることです。
- 例外（Exclude）に誰が入っているか：ユーザー、グループ、ロール
- 許可条件が緩くなっていないか：MFA を要求しない、準拠デバイス不要、レガシー認証許可
- Named location／国・IP の扱い：攻撃者の地域だけ許可していないか
可能であれば、条件付きアクセスの“理想形”を先に決め、現状をそこへ寄せる形で再構築します。既存ポリシーを継ぎ足すほど、例外が積み上がって事故になります。
「復旧して終わり」にしない監視の作り方
復旧直後は、攻撃者の再侵入が最も起きやすいタイミングです。テナントの継続運用をするなら、次のような監視を“毎日見るもの”として整えます。
- 特権ロール割り当ての変更（追加・削除・PIM の設定変更）
- アプリ登録／エンタープライズ アプリの追加、権限変更、資格情報追加
- 条件付きアクセスの追加・更新・無効化
- 大量のサインイン失敗、国やIPの急変、Impossible travel などの異常
- メール転送、受信トレイ ルール、代理送信の変更
バックアップが信用できない前提での「安全な持ち出し」
侵害時によくある誤解が「バックアップから戻せば大丈夫」という発想です。しかし Entra ID／Microsoft 365 の“バックアップ”は、ファイル復元というより設定とデータの集合であり、そこに悪意ある同意や脆弱な構成が混ざっていると、復旧で再現してしまいます。
持ち出しの基本原則は次の通りです。
- 設定は「参照」して再作成：旧テナントの設定エクスポートをそのままインポートしない
- データは「選別」して移行：重要度と業務要件でスコープを絞る
- 権限は「新テナントで再設計」：旧環境の過剰権限を継承しない
- 移行後に「検疫」：共有リンク、外部共有、ラベル、DLP、端末準拠を適用してから開放
現場で困りがちな論点と、割り切りポイント
「とにかく早く業務を戻したい」場合
短期復旧を優先するなら、完全復旧を目指すよりも、業務影響が大きい範囲だけを“強制的に安全寄り”へ寄せる方が成功します。例えば、管理者と重要部門だけ先にフィッシング耐性 MFA＋準拠端末に固定し、一般ユーザーは段階的に移行する、といった“優先順位付きのゼロトラスト”です。
「旧テナントの設定をコピーしたい」誘惑
移行中は、旧テナントの条件付きアクセスやアプリ同意をそのまま移したくなります。しかし、ルートトラスト喪失が疑われるなら、そこに攻撃者の仕掛けが混ざっている可能性があります。コピーするなら、差分レビューと承認のプロセスを必ず挟み、最低でも「誰が・いつ・何を・なぜ」コピーしたかを記録します。
「どこまでやれば安全と言えるか」
安全は二値ではなく、リスク低減の積み上げです。だからこそ、移行かインプレースかの選択よりも、最終的には次の状態を作れるかが重要です。
- 特権が最小化され、JIT とレビューが回る
- アプリ同意が統制され、過剰権限が排除されている
- 条件付きアクセスが単純で強く、例外が管理されている
- ログとアラートが運用に組み込まれ、異常を早期検知できる
再発防止のための「ルートトラストを守る」運用
侵害後のテナントは、復旧作業が終わった瞬間から“元通りに弱くなる”方向へ戻ろうとします。例外が増え、権限が増え、監視が形骸化するからです。再発防止の最短ルートは、次の定期作業をルーチン化することです。
- 月次：特権ロール割り当てと PIM の棚卸し（誰が昇格できるか）
- 月次：エンタープライズ アプリ／アプリ登録の追加と権限変更レビュー
- 四半期：条件付きアクセスの例外（Exclude）レビューと削減
- 四半期：ゲストユーザー、外部共有、クロステナント設定の棚卸し
- 随時：秘密情報（シークレット／証明書／Webhook／API キー）のローテーション計画
加えて、侵害は“いつか起きるもの”として、復旧手順のリハーサル（誰が何を、どの端末から、どの順でやるか）を年1回でも実施すると、実際の初動が大きく改善します。
まとめ：迷ったら「新規テナント＋段階移行」を軸にする
ルートトラスト喪失が疑われる重大インシデントでは、インプレース復旧は「安全の証明」が最大の壁になります。だからこそ、原則は新規テナントを信頼の起点にし、旧テナントは調査用に縮退させる二段構えが現実的です。どうしても元テナントを使い続ける場合でも、特権・トークン・同意・条件付きアクセス・間接ロール付与を“総点検して再構築する”覚悟が必要です。
最終的に目指すべきは、攻撃者に奪われにくい認証基盤と、奪われても早期に気付ける監視体制です。復旧をきっかけに、テナントの設計と運用を「守れる形」に作り直しましょう。
コメント