Managed Red Tenant

Red Tenantは、特権を持つアイデンティティとその端末だけのために存在する独立したMicrosoft Entraテナントです。本番テナントはそこから管理し、本番テナント自身の中からは管理しません。

理由は単純です。テナントを侵害した者は、そのテナントを直すために使うアカウントも自動的に手にします。そのアカウントが別のテナントにあれば、侵害された利用者から完全な支配へ至る経路は断たれます。名前は、Active Directory向けに管理専用のフォレストを置くMicrosoftのかつてのモデル、Red Forestに由来します。

Enterprise Access Modelは、環境を階層に分けます。コントロールプレーン（Tier 0）にはアイデンティティと権限を管理するものがすべて入り、マネジメントプレーン（Tier 1）はサーバー、アプリケーション、ワークロードを含み、ユーザーアクセスプレーン（Tier 2）はエンドポイントと利用者から成ります。

背後にあるルールは、上位の階層が下位の階層から制御できてはならない、というものです。そのためEntra IDでは、グローバル管理者、特権ロール管理者、条件付きアクセス管理者、Intune管理者といったロールがTier 0に属し、さらにEntra Connectと、これらのシステムにパッチを当て、バックアップし、監視するものすべてが含まれます。

まずはコントロールプレーンの正直な棚卸しから始めるのが最善です。つまり、いまアイデンティティや権限を変更できるアカウント、グループ、サービスアカウント、アプリケーションはどれかを洗い出します。ほとんどの環境で、その数は事前の想定をかなり上回ります。

そのうえで階層ごとにアカウントを分け、恒常的な割り当てをPIMに置き換え、サインインを専用端末に限定します。当社の無料のTiering-Checkは、いまTierの境界がどこで越えられているかを図で示すので、当社の知るかぎり最も速い入り口です。

どちらもアイデンティティとサインインの状況は検証しますが、キーボードがつながっている端末そのものは検証しません。

強力な認証に成功しても、その先にあるのは端末上のトークンです。その端末が侵害されていれば、PIMと条件付きアクセスがそこまで正しく働いていても、トークンは盗まれ、セッションは乗っ取られます。Red Tenantは両方を使ったうえで、端末自体が隔離された環境のものであることを条件に加えます。

Privileged Access Workstation（PAW）は、管理作業だけに使う堅牢化された端末です。メールや一般的なWeb閲覧は行わず、Application Controlを適用し、ローカル管理者権限を持たず、TPMとセキュアブートによる信頼の起点を備えます。

専用ハードウェアが必要になるのは、コントロールプレーンにアクセスするすべてのロールです。そこでは「きれいなキーボード」の原則が効きます。認証情報は、対象より信頼水準の低い端末に触れてはなりません。Tier 1であれば仮想版で足ります。

コントロールプレーンより下のすべてです。仮想アクセスワークステーション（VAW）はRed Tenant上でAzure Virtual Desktopとして動き、準拠状態のオフィス端末からEntra Private Access経由で、アイデンティティを切り替えてFIDO2で接続します。

ハードウェアなしでスケールし、Azure、Microsoft 365、オンプレミスをカバーします。ただしアクセスがTier 2の端末を経由するため、残余リスクは残ります。だからこそ、コントロールプレーンは物理のPAWに限定したままにします。

いいえ。ただし管理者は全員、別のアイデンティティと別のアクセス経路が必要です。それが物理のPAWになるか仮想のVAWになるかは、その人が作業する階層で決まります。

実際にはTier 0の権限を持つ人はごくわずかで、その人たちが物理のPAWを受け取り、大多数はVAWで作業します。だからこそ、このモデルは管理者5人から5,000人まで対応できます。

違いは信頼の起点にあります。アカウント、ポリシー、デバイス管理が本番システムと同じテナントにあるPAWは、そのテナントと運命を共にします。テナントを掌握した者は、PAWを堅牢化しているIntuneのポリシーも掌握するからです。

Red Tenantは、アカウント、端末、管理の仕組みを、本番テナントからは到達できない独立したテナントへ移します。PAWという部品は同じで、置かれている土台が違うだけです。

PAM製品は資格情報を預かり、セッションを仲介します。つまり守るのは資格情報であって、それを使う端末ではありません。エンドポイントが侵害されていれば、攻撃者は仲介されたセッションにそのまま相乗りします。PAM製品だけでは端末のリスクを確実にはカバーできないと、Microsoft自身が書いています。

Red TenantはPAMを置き換えるものではなく、補うものです。PIMも既存のボールトもそのまま使えます。変わるのは、アクセスが危険領域の外にある端末から来るようになる点です。

お客様の承認なしに効力を持つことは何も起きません。Red Tenantへの変更はすべてコードとしてパイプラインを通り、お客様側のCustomer Approverによる承認が必要です。緊急用のアクセス手段も、どちらか一方だけでは動けないように分割されています。

加えて、当社はお客様の環境を自社のRed Tenantから、お客様に適用するのと同じルールで管理しています。拒否権は常にお客様の側にあります。

第21条第2項は、アクセス制御の方針、多要素認証、システムの取得・開発・保守における安全性などを挙げています。第20条は、その実施を監督し証明する責任を経営層に課しています。

ドイツでは2025年12月からBSI法を通じて、オーストリアでは2026年10月1日からNISG 2026を通じて適用されます。BSIのIT-Grundschutzは、管理作業の分離を基本要件、管理機能を独立した構造へ切り出すことを上位要件として定めています。Red Tenantはまさにそれをクラウドで実装したもので、バージョン管理されたリポジトリがその証跡になります。

自社運用には複雑すぎることが実際によくあります。費用がかかるのは技術そのものではなく、継続的な堅牢化、保守、監視、証跡づくりだからです。これらは片手間では終わりません。

マネージドサービスがあるのは、まさにそのためです。手間は当社側に置かれ、自動化と反復によって扱える範囲に収まります。管理者20人のRed Tenantも、2,000人のRed Tenantも、同じコードです。

MicrosoftがESAEを撤回したのは、このモデルがオンプレミスの管理者しかカバーせず、運用が複雑すぎたからであって、分離が効かなかったからではありません。

同じドキュメントは、Microsoftが社内では今も同等のアーキテクチャを運用していることを記し、すべての管理作業にPAWを推奨し、とりわけ保護が必要なリソースについては複数テナントによる隔離を明示的に挙げています。Red Tenantはこの原則をクラウド向けに置き換えたもので、ESAEを行き詰まらせた運用の手間はマネージドサービスが引き受けます。

階層設計は誰が何をできるかを、PIMはいつできるかを、条件付きアクセスはどんな条件でできるかを決めます。ただしこの3つはいずれも、守るべき環境と同じ場所にあり、グローバル管理者権限を奪った攻撃者が同じく手にするロールによって管理されています。

Red Tenantは管理業務をその環境の外へ出します。既存の統制はそのまま残り、内側からは届かない信頼の起点を得ます。