本記事は、Microsoft Azure Tech Advent Calendar 2025 12/21 分の記事となります。
What is this?
各組織活動の基盤として IT の運用が欠かせない現代ですが、日々それらを運用、管理するのが情報システム部門、いわゆる情シスです。
一方で情シスの所属者も組織の一員であるので、当然入れ替わりや欠員は流動的に生じます。その際の引継ぎがうまく行われればよいのですが、そうもいかないのが現代社会のつらいところ。
引継ぎマニュアルが無い、何がどこにあるかがわからないなどは日常茶飯事、"管理者情報の永久欠落により、電源が落ちたが最後の時限爆弾化" やら "システムのある一部のフローが使えなくなったため、そこだけ印刷しての紙処理決済" やら、現代の怪談とも呼ぶべき惨事が各所で発生している御話を伺ったりすることもあります。夏にお寺でやれ。
さて、Azure の利用と RBAC に始まるロールの権限関連は切っても切り離せないものですが、本記事ではそれらの "管理者" に分類されるいくつかのロールの保有アカウントが失われた場合にどうすれば解決できるのかをまとめてみました。
この記事を以て、危機管理フォーム(?)がいかに重要か、痛い目を見ないような事前準備はどのようにできるのかについて、ご一考いただければ幸いです。
対象
情シス、あるいはそれに類する部門に所属されている方 、かつ IT リスクに理解が薄い上司をお持ちの方 を対象とします。
なお、本記事はわかりやすさを優先としているため、技術的な内部処理については一部齟齬が生じる部分があることをあらかじめお伝えいたします。
(具体例としては管理グループの説明がごっそり抜けているなど)
エキスパートの方にとっては違和感を覚える箇所があるかと思いますが、こちらご容赦ください。
用語の確認
"権限の紛失" がテーマではありますが、その権限の作用範囲を明確にするためにまずは各用語についてまとめます。
テナント (ディレクトリ) と Microsoft Entra
まず、Azure を利用する上で混乱の要素の一つであるテナントと、"Microsoft Entra" および "Entra ID" からお話します。
なお、どちらも厳密には Azure の構成要素ではないことにご留意ください。
テナント、あるいはディレクトリは、Microsoft のクラウド サービスを利用するための基盤で、論理的には "Microsoft のデータセンター上に 組織、あるいは個人ごとに割り当てられている領域" です。
用語としての "テナント" と "ディレクトリ" は公式ドキュメントにも記載がある通り、ほぼ同義として問題ありません。"Entra テナント" や "Azure テナント" と言った表記を見なくもなくもありませんが、やはりこれらも同一です。
一方で Microsoft Entra は、ID とネットワーク アクセス製品のファミリで、要はクラウドサービスを扱うための認証基盤です。Entra ID はその中でも認証を管理するアクセス管理サービスです。
具体例として、"個人で Outlook アカウントを登録してメールを利用する" 場合を考えてみましょう。
ユーザーは Microsoft アカウントの作成 ページにアクセス後、各種情報を入力することでメールアドレスの発行を受け、利用を開始しますが、このタイミングで "メールアドレスと同一の Entra ID" が発行されています。また、その後メールをすればその情報を蓄積する領域も Microsoft のデータセンター内に用意されます。
この "用意された領域" がテナントです。同じアカウントであれば OneDrive にファイルをアップロードしても、Sharepoint で作業をしてもそのデータは同じテナントに格納されます。
ここまでは直感的だと思いますが、テナントの中には "Entra ID" それ自体の情報も含まれています。
これは個人利用ではほぼ意識することではありませんが、組織として Entra ID とテナントを利用する際は、利用開始前の事前検討が不十分だと問題の要因となりがちです。
グローバル管理者
グローバル管理者は Microsoft Entra ロールの最上位特権管理者です。Microsoft Entra テナントにサインアップしたユーザーが本管理者になります。
Microsoft Entra に関するあらゆる権限を持つ一方で、実は Azure のリソースに関する権限はデフォルトでは保持していません。
従って、通常は相互で影響を及ぼすことはありません。
Azure サブスクリプション (クラウド サブスクリプション)
Azure サブスクリプション (以降 "サブスクリプション" と呼称します) は、Azure 利用時の請求管理の単位です。
公式ドキュメント上では "Microsoft から購入する製品とサービスを管理する方法" とありますが、イメージ的には "サービスを利用するための初期契約" が近いかもしれません。
サブスクリプションなくして Azure 上の各種サービスを利用することはできません。
サブスクリプションは必ず作成時に "プラン(=契約種別)" が設定され、プラン番号が割り当てられます。Azure の利用費用は基本的には "プランに応じた単価" * "利用時間" として設定されることになります。
サブスクリプション自体は無料ですので 「使いたいサービスを自分でどんどん追加設定し、その使用量から算出される個々のサービス利用料の合算が月額費用となる」とでも申しましょうか。
具体的なプラン番号は Microsoft Azure プランの詳細 にて確認が可能です。
最期に重要なことですが、サブスクリプションは 「作成操作を行ったユーザーアカウントが "ホーム テナント" として属している Entra テナントに関連付けられて作成」 されます。
要約すると "(だいたい) サブスクリプションを作成したアカウントのテナント" に所属する、ということになります。
Azure ロール (RBAC : Azure role-based access control)
あるユーザーが Azure Portal にアクセスしたものの、なにも確認できないということが起きたりします (多くの場合はディレクトリの違い)。
これは、実際の Azure の管理はサブスクリプション単位で行われるのに対し、Azure Portal ではユーザーをドメインのルートとした構造となっているために起きるズレの為です。
Entra ID を持つため Azure Portal にはサインインできるものの、Azure の権限は何もないため何も見ることができないというわけです。
では "Azure の権限" とは具体的に何を指すものか、それが RBAC と呼ばれる仕組みです。
Azure ロールベースのアクセス制御 (Azure RBAC) とは の記事の通り、Azure ロールという定義済みロールの組み合わせで個別にサブスクリプション、リソースグループ、またはリソースに対し、"読み取り" "更新" "追加" "削除" といった各種権限を割り当てるものです。
Azure 上でのアクセスは、VM 等の個別のサービスの利用権からユーザー管理、課金と費用の確認といったあらゆる要素がこの RBAC で管理されます。
RBAC はサブスクリプションの所有者が各ユーザに対して行うことが最も多い事例になると思われます。
Azure Enterprise Agreement (EA 契約)
Enterprise で大規模に Azure をご利用いただくお客様には、EA 契約と呼ばれる特別な契約を締結する場合があります。
いくつか特徴はありますが主な点は "為替の影響を受けない割り引かれた固定の単価でサービスが利用可能である" "通常サブスクリプションごとに行われる請求が一つの請求アカウントに集約される" などがあります。
EA 契約ご利用時には専用のプランである "エンタープライズ サブスクリプション (0017P)" および "Enterprise Dev/Test(0148P)" がサブスクリプション作成時に選択できるようになります。
エンタープライズ ロール
EA 契約は請求が集約される関係上、費用とサブスクリプションの管理形態が変更されます。
その管理のために専用に用意されているのがエンタープライズロールです。
通常のサブスクリプションとは異なり、EA サブスクリプションの管理ロールは アカウント所有者となります。
その他、EA 契約内全体の管理者としてエンタープライズ管理者が最上位権限を持つロールとして存在します。
エンタープライズロールはAzure ロールとは完全に独立しており、"ロールの付与"という観点で相互干渉することはありません。
管理者情報の紛失
さて、ここまで Microsoft Azure に関連する管理者をまとめてきました。
これらの利用手段が紛失した場合の対応策について以下に記載します。
グローバル管理者情報の紛失時
結論から書くと、セルフサーブでの解決方法はありません。
弊社カスタマー サポートにグローバル管理者紛失についてご相談ください。
(私の所属部門担当外なため、詳細は割愛します。)
サブスクリプションの所有者情報の紛失時
"グローバル管理者の特権昇格" により、グローバル管理者に Azure リソースへのアクセス権を付与することで解決可能です。
先の項目 "グローバル管理者" 内の記載に
実は Azure のリソースに関する権限はデフォルトでは保持していません。
従って、通常は相互で影響を及ぼすことはありません。
と記載していたのはこのためです。
詳しくは下記ドキュメントをご参照ください。
・Azure のすべてのサブスクリプションと管理グループを管理する目的でアクセス権限を昇格させる
なお、この方法はあくまで "サブスクリプションの所属するテナント" のグローバル管理者で対応可能なものであることにご注意ください。当然ですがグローバル管理者は "所属テナントの最高権利ロール" に過ぎないので、異なるテナントに所属している情報には何の影響も及ぼしません。
EA 契約における管理者の紛失時
アカウント所有者情報の紛失時
エンタープライズ管理者により所有者の変更が可能です。
[コストの管理と請求] - [{EA 請求スコープ}] - [Azure サブスクリプション] にアクセスいただき、当該サブスクリプションについて操作を実行ください。
エンタープライズ管理者情報の紛失時
こちらもグローバル管理者の紛失同様、セルフサーブでの対応方法はございません。また、弊社にお問い合わせいただきましても契約条項上の個人情報保護観点にて、照会作業はお断りさせていただいています。
日本での EA 契約はその多くが LSP (License Solution Partner) という代理店様を介して締結されておりますので、そちらにご質問賜りますようお願い申し上げます。
なお、通常はあり得ませんが "エンタープライズ管理者が一人もいない" という状況となった場合、"CICR プロセス" という特殊プロセスを経て、指定のアカウントをエンタープライズ管理者に登録することが可能です。こちらもパートナー様にてご対応頂く内容となりますので、必要に応じてご相談頂ければと存じます。
・Azure portal での EA 課金管理 - エンタープライズ管理者のサポートが得られない場合
予防措置としてやっておくべきこと
とある落合という科学者が小林さんにいつもこんなことを言っていたそうです。
「大事なものには予備が必要だと」
科学者 落合の言う通り、予備の管理者を用意して頂くだけで、リスクは大きく軽減されます。選任や寡占といった状態自体がそもそものリスクであるということです。
一方で、グローバル管理者やエンタープライズ管理者などの絶大な権限を持つロールを無作為に付与するのは、Azure での "最小特権の原則" とも反しますので考えものです。
ベストプラクティスにも "グローバル管理者の数を 5 人未満に制限する" という項目がございますので、まずはこちらを目安に運用方針を検討されることをお勧めします。
終わりに
2025年も残すところ10日を切り、一年の終わりを感じています。
なお個人的な話になりますが、様々な勉強会に参加するのが好きなのもので、たびたびいろいろなところへ参加させていただいております。昨日の 12/20 にも "本年の勉強会納め" として、何度かお世話になっている会に参加してきたのですが、そこで突然全員参加のイベント "正解してはいけないクイズ(ただし全力で正解は当てに行かなければならない)" が開かれ、その上正答が "エンタープライズ管理者" となる問題を出されて撃沈しました。狙い撃ちは良くないと思う。
では皆様もよいクリスマス & 年越し計算ライフを。
余談
「科学者 落合」に敬称がないのは "科学者の枕詞がある意味敬称" "「科学者 落合」で一単語" "奴は敬われるような輩ではない" という複合的な理由による意図した記載です。ご了承ください。
出展
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/overview
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/role-assignments-list-portal
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/classic-administrators?tabs=azure-portal
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/best-practices
https://www.kodansha.co.jp/comic/products/0000047351