Classic Administrator の廃止後に、Azure ポータルで自分の RBAC ロールが「None」のままになり、ロールを追加できないことがあります。実はこれは“詰み”ではなく、Microsoft Entra ID のグローバル管理者が一時的にアクセスを昇格し、サブスクリプションに Owner を付与することで復旧できます。
現象：RBAC ロールが「None」になり、権限を付与できない
Classic Administrator（旧来の共同管理者/サービス管理者など）に依存した運用をしていた環境で、廃止・移行期限を過ぎると、次のような状態に遭遇することがあります。
- Azure ポータルの「アクセス制御 (IAM)」で、ロール割り当てを追加しようとしても操作が進まない
- 「自分のアクセス」や権限表示が常に「None（なし）」になっている
- サブスクリプション配下のリソースが見えていても、割り当て操作だけができない／そもそもサブスクリプション自体が一覧に出ない
| よくある見え方 | 起きている可能性が高いこと | 影響 |
|---|---|---|
| 自分のロールが None と表示される | サブスクリプションに対する RBAC のロール割り当てが存在しない、または確認できない | ロール追加・変更ができず、権限復旧が進まない |
| 「ロールの割り当ての追加」がグレーアウト | ロール割り当てを実行できる権限（Owner / User Access Administrator）がない | 運用担当者が“自力で”復旧できない |
| サブスクリプションが一覧に出ない | テナント/ディレクトリが違う、またはサブスクリプションに対する閲覧権限すらない | 対象スコープに到達できず、対処が迷子になりやすい |
なぜ起きるのか：Classic Administrator と Azure RBAC は別物
まず押さえるべきポイントは、Classic Administrator と Azure RBAC は「同じ権限体系の名前違い」ではなく、仕組み自体が別という点です。Classic Administrator は“古い管理モデル”に紐づいており、Azure Resource Manager（ARM）を前提にした RBAC とは管理面が分離しています。
そのため、Classic Administrator 側の権限が失効・廃止されたタイミングで、RBAC 側に Owner/Contributor などが割り当てられていないと、サブスクリプションの権限管理ができなくなります。さらに重要なのは、Microsoft Entra ID の「グローバル管理者」であっても、通常は Azure サブスクリプションの RBAC 権限を自動的に持たないという点です。
| 旧来（Classic） | 現在（RBAC） | 運用上の違い |
|---|---|---|
| 共同管理者/サービス管理者など | Owner / Contributor / Reader など（ロール） | RBAC はスコープ（管理グループ/サブスクリプション/リソースグループ/リソース）単位で付与 |
| Azure AD とは別の管理モデルが残っていた | ARM を前提に Entra ID のユーザー/グループ/サービスプリンシパルへ付与 | グループに付与してチーム運用しやすい（属人化を減らせる） |
| “昔からいる管理者”が強かった | 最小権限・PIM などを組み合わせやすい | 強権限は必要なときだけ昇格、が前提の設計に寄せられる |
解決の大枠：グローバル管理者が「アクセス昇格」して Owner を付与する
この「None」状態からの復旧は、条件さえ満たせば Azure ポータルだけで完結できます。結論は次の流れです。
- 前提として、対象アカウントが Microsoft Entra ID のグローバル管理者（Global Administrator）であることを確認する
- 「グローバル管理者のアクセス権を一時的に昇格（elevate access）」し、ルートスコープで RBAC を操作できる状態にする
- 対象サブスクリプションに対して、自分のアカウントにOwnerロールを割り当てる
- 必要な管理者（旧 Classic Administrator 相当）へ、Owner / Contributor など適切な RBAC ロールを割り当て直す
- 作業後はアクセス昇格をオフに戻し、強権限を常態化させない
ここから先は、実際の手順を「つまずきやすいポイント」込みで具体的に整理します。
作業前のチェック：ここを外すと復旧できない
自分が Microsoft Entra ID の「グローバル管理者」か確認する
もっとも多い落とし穴が「自分はテナント管理者だと思っていたが、実はグローバル管理者ではなかった」というケースです。復旧作業は高い権限を扱うため、まずは役割の確認から始めます。
- Microsoft Entra 管理センターで、対象ユーザーに Global Administrator が割り当てられているか確認する
- PIM（Privileged Identity Management）を使っている環境では、“割り当て済み（Eligible）”ではなく“有効化（Active）”になっているか確認する
- MFA（多要素認証）や条件付きアクセスで、グローバル管理者の操作がブロックされないか確認する
正しい「ディレクトリ（テナント）」に入っているか確認する
Azure ポータルは、ログインしているアカウントが複数テナントに所属していると、別テナントの画面を見ているだけで「サブスクリプションがない」「ロールが None」に見えることがあります。必ず対象のテナントへ切り替えてから作業してください。
| チェック項目 | 確認の目安 | 間違えるとどうなるか |
|---|---|---|
| ディレクトリ切り替え | 「ディレクトリ + サブスクリプション」で対象テナントを選択 | そもそもサブスクリプションが表示されない |
| サブスクリプション フィルター | 必要なサブスクリプションにチェックが入っている | “一覧にない”と誤認しやすい |
| ブラウザ キャッシュ | シークレット/プライベート ウィンドウで再ログイン | 権限反映が遅れて見える、ボタンが出ない |
手順：グローバル管理者のアクセス権を一時的に昇格（elevate access）する
ここが復旧の核です。グローバル管理者は、テナント設定を使ってAzure リソース管理に対するアクセスを一時的に昇格できます。これにより、ルートスコープで RBAC の割り当てができる状態になり、Owner 不在のサブスクリプションでも自分へ Owner を付与できるようになります。
Azure ポータルでの操作手順
- Azure ポータルで Microsoft Entra ID を開く
- 左メニューから プロパティ（Properties）を開く
- 「Azure リソースのアクセス管理」相当の設定（Access management for Azure resources）を探す
- アクセスを昇格する（または同等のボタン/トグル）を有効化する
- 反映のため、サインアウト → サインインを行う
昇格後に“何が変わる”のか
アクセス昇格は「自動的に Owner になる」機能ではありません。イメージとしては、ルートスコープでロール割り当てを操作できる力（User Access Administrator 相当）を一時的に得る機能です。そのため、次のステップでサブスクリプションに対して Owner を付与する作業が必須になります。
手順：サブスクリプションに自分自身へ Owner ロールを付与する
アクセス昇格を反映したら、対象サブスクリプションへ Owner を割り当てます。ここで初めて「None」状態から抜け出し、以降の RBAC 運用が正常に回せるようになります。
Azure ポータルでの具体的な手順（画面操作）
- Azure ポータルで サブスクリプション を開き、対象サブスクリプションを選択する
- 左メニューから アクセス制御 (IAM) を選択する
- 上部メニューの 追加 → ロールの割り当ての追加 をクリックする
- 「特権管理者ロール（Privileged administrator roles）」タブがある場合はそれを開き、所有者（Owner） を選んで 次へ
- 「メンバーの選択」で 自分のアカウント を検索して選択し、選択
- 「条件」タブが表示される場合は、ユーザーにすべてのロール（高い特権を持つロールを含む）を割り当てることを許可 を選択する
- 確認および割り当て（Review + assign）で確定する
- 反映のため、再度 サインアウト → サインイン を行う
ポイントは、必ずサブスクリプション スコープで Owner を付与することです。リソースグループ単位で付与してしまうと、サブスクリプション全体の RBAC 管理やコスト管理などに必要な権限が不足し、結局あとで詰まります。
（任意）Azure CLI で確認・付与する場合
ポータルが重い・UI が変わって迷う場合は、CLI で“事実”を確認するとトラブルシュートが速くなります。以下は代表例です。
az login
az account list --output table
az account set --subscription <SUBSCRIPTION_ID>
# 自分のオブジェクトIDを確認（サインインユーザー）
az ad signed-in-user show --query id -o tsv
# 既存のロール割り当て確認（自分が見える範囲）
az role assignment list --assignee --all -o tableOwner 付与（作業用の例）は次のような形になります。実行には、アクセス昇格が反映された状態であることが前提です。
az role assignment create \
--assignee <OBJECT_ID> \
--role "Owner" \
--scope /subscriptions/<SUBSCRIPTION_ID>「None」が解消したか確認する方法
Owner 付与後、次の観点で“復旧できたか”を確認します。ここで曖昧なまま先へ進むと、また権限で詰まりがちです。
- 対象サブスクリプションの「アクセス制御 (IAM)」で、自分のロールが Owner として表示される
- 「ロール割り当て」一覧で、自分のアカウントのエントリが存在する
- リソースグループの作成、ロール割り当ての追加/削除など、管理操作が行える
- CLI で
az role assignment listを実行し、Owner が確認できる
次にやること：旧 Classic Administrator 相当のアクセスを RBAC で再構成する
自分が Owner になって復旧できたら、次は組織として困らない形に整えます。Classic Administrator に近い権限を“人”に直接付与すると属人化しやすいので、基本は Entra ID グループに付与するのがおすすめです。
| やりたいこと | 推奨ロール | 付与先のおすすめ |
|---|---|---|
| サブスクリプション全体を管理（ロール付与も含む） | Owner | 運用チーム用グループ（常用は最小人数） |
| リソース作成・運用はできるが権限管理は不要 | Contributor | 担当者グループ（プロジェクト単位） |
| 閲覧のみ | Reader | 監査/参照用グループ |
| ロール割り当てだけ行いたい（運用設計次第） | User Access Administrator | 権限管理担当グループ（用途を限定） |
よくあるつまずきと対処法
「アクセスを昇格する」ボタンが見当たらない
- グローバル管理者ではない（または PIM で有効化できていない）可能性があります。まず Entra 側のロールを再確認してください。
- 正しいテナントにいない可能性があります。「ディレクトリ + サブスクリプション」の切り替えを確認してください。
- 組織のポリシーで設定変更が制限されている場合は、別のグローバル管理者（ブレイクグラス）で実施する必要があります。
昇格したはずなのに、IAM の追加がまだできない
- 反映前のトークンのまま操作しているケースが多いです。必ず サインアウト → サインイン を実施してください。
- ブラウザのキャッシュ/セッションが悪さをすることがあります。シークレット ウィンドウで再ログインすると切り分けが楽です。
- サブスクリプションが管理グループ配下で厳格に管理されている場合、上位スコープのポリシーや deny 割り当ての影響を受けることがあります。
サブスクリプションが一覧に出ない（ID が分からない）
閲覧権限すらない場合、一覧に出ないことがあります。その場合は、組織内の請求管理者や既存の管理者、パートナー（CSP）にサブスクリプション ID を確認してもらうのが近道です。ID が分かるなら、直接 URL で開けるケースもあります。
https://portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade/subscriptionId/<SUBSCRIPTION_ID>「条件」タブが表示されない／表示が違う
ポータルの UI は更新頻度が高く、テナント設定や機能の展開状況で表示が異なります。「条件」タブが出ない場合でも、Owner を選びメンバーを指定して割り当てできれば問題ありません。逆に条件が必須として出る場合は、指示通りに許可設定を選んで進めてください。
作業後のセキュリティ：アクセス昇格は必ず戻す
アクセス昇格は非常に強力です。復旧が終わったら、必ずオフに戻す運用にしてください。オンのままにすると「グローバル管理者＝Azure の権限管理も常時可能」という状態になり、侵害時の被害範囲が一気に広がります。
戻し方（基本手順）
- Azure ポータルで Microsoft Entra ID を開く
- プロパティ（Properties）から、アクセス昇格を無効化する
- 反映のため サインアウト → サインイン を行う
安全に運用するための実践的なポイント
- Owner は最小人数に絞り、日常運用は Contributor/Reader を基本にする
- 可能なら Entra PIM で Owner を常時付与せず、必要時にだけ昇格する
- Owner の直付けではなく、グループ付与＋アクセスレビューで棚卸しする
- “最後の管理者が消える”事故を防ぐため、少なくとも 2 名（または 2 アカウント）の Owner を確保する
再発防止：Classic Administrator 依存を断ち、RBAC を“運用”に落とす
今回のトラブルは、権限が「個人の記憶」と「昔の慣習」に紐づいていたときに起こりがちです。復旧できたタイミングで、次のような運用ルールに寄せると再発しにくくなります。
- サブスクリプション Owner は“人”ではなく“管理者グループ”へ付与し、メンバーは最小限にする
- プロジェクト単位の権限はリソースグループ スコープで設計し、不要な権限の横展開を避ける
- 権限設計の基準（どの作業にどのロールが必要か）をドキュメント化し、引き継ぎ可能にする
- ロール割り当ての棚卸し（四半期/半期）をルーチンにする
まとめ：RBAC が None でも復旧できる条件と最短ルート
Classic Administrator 廃止後に RBAC ロールが None になっても、グローバル管理者であればアクセス昇格 → Owner 付与で復旧できるケースが多いです。復旧の成否を分けるのは「正しいテナントにいること」「昇格後にサインインし直すこと」「サブスクリプション スコープで Owner を付与すること」です。復旧後はアクセス昇格を戻し、RBAC をグループ中心で設計し直すことで、同様の権限事故を防げます。
コメント