Skip to content

MS_AzureSubscriptionMgmt

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Azure Subscriptionの管理@エンプラ

概要

  • キッティングしてもらった Azure サブスクリプションを、
    エンタープライズ・ユースで安全に管理するには？的なトピック。

  • 自分でキッティングする場合は、以下をご参照下さい。

  • 以下の機能を活用することで、

    • アカウントを管理する。
    • アクセス権で操作や通信を制限し、
    • 必要に応じて VPN 接続を利用する。

    安全に管理・利用できる。

補足（このページの位置づけ）: 「エンプラ」で問題になるのは、
技術の選定よりも「誰が何をできるか」の設計である。
本ページはその観点で、

① サブスクリプション管理者（課金・契約）… 特殊用途のみ
② RBAC（リソース操作の権限）         … 実運用はこちら
③ Azure AD（誰がログインできるか）    … ①②と独立した別階層

という 3 階層を整理している。
①（クラシックな管理者）と ②（RBAC）を混同しないことが要点。

Azure Resource Manager (ARM)

ロール定義、ロール割り当てで、アクセス権で操作を管理する。

シェル

Azure Cloud Shell

  • Azure リソースを管理するための、ブラウザーでアクセスできるシェル。
  • Linux ユーザーは Bashを、Windows ユーザーは PowerShell を選ぶことができる。

Azure PowerShell

Azure Resource Manager (ARM) モデルを使う一連のコマンドレットが用意されている。

Azure CLI

Azure PowerShell の Python 版（Python があれば動作する）。

アクセス制御

Role Based Access Control (RBAC)

アカウントにロールを関連付ける。

Network Security Group (NSG)

通信を管理する（リソースへのネットワーク トラフィックを許可または拒否する一連のセキュリティ規則）。

サブスクリプション管理者

共同管理者

Co-Administrator

  • 2017 年 10 月時点で新規登録できない。

  • RBAC アクセス制御を使用して、サブスクリプションに対して、
    所有者というロールを割り当てれば、従来のクラシック ポータルでの共同管理者相当になる。

補足（最新化）: クラシック デプロイ モデル（ASM）自体が既に廃止されており、
共同管理者（Co-Administrator）およびサービス管理者（Service Administrator）は
2024 年 8 月末で提供終了となった。
現在は本文が推奨するとおり、すべて RBAC のロール割り当てに移行している。
以下の各管理者の説明は、当時の体系の記録として読まれたい。

グローバル管理者

Global Administrator

サブスクリプション契約者で最初のユーザ、緊急事態用として重複して登録しておくと良い。

補足: ここで言う「重複して登録しておく」のが
**緊急事態用アカウント（break glass アカウント）**である。
条件付きアクセスや MFA の設定ミスで全管理者が締め出される事態に備え、
通常運用では使わないアカウントを 2 つ以上用意しておく。
使われたこと自体がインシデントなので、
サインインを検知して通知する（Azure Alerts）設定が必須。
詳細は AzADのテナント作成方法 を参照。

なお現在の正式名称は 全体管理者（Global Administrator）で、
これは Azure AD 側のロールであり、
既定ではAzure リソースへのアクセス権を持たない（後述）。

アカウント管理者

Account Administrator

概要

  • 金銭や契約に関わる作業を行う。

  • サブスクリプションやサポートオプションの

    • 購入
    • 購入後
      • 契約管理
      • 請求管理

権限

  • サブスクリプションやサポートオプションの購入
  • サブスクリプションごとのサービス管理者の指定
  • オンライン請求書の発行やサブスクリプション情報などのメール通知の受信
  • オンライン請求書ならびに使用量レポートのダウンロード
  • 支払方法の変更

ポイント

  • 各種サービスを利用する管理ポータルへのアクセス権および管理権限は無い。
    （管理ポータルを利用するには、サービス管理者や共同管理者に指定する。）
  • アカウント管理者の変更は、セキュリティ上の観点から、ユーザ自身で実施できない。
    Microsoft Azure サポートまで連絡して変更して貰う必要がある。

補足（最新化）: 現在は Microsoft Cost Management ＋ 課金 (Billing) の
体系に整理されており、EA / MCA といった契約種別ごとに
課金ロール（請求書セクション所有者、課金プロファイル共同作成者など）が定義されている。
「課金と、リソース操作の権限は別物」という原文の骨子は現在も同じ。

サービス管理者

Service Administrator

概要

  • Azure の各種サービスを利用するための管理者。
  • 各サブスクリプションに１つサービス管理者が紐づいている。
  • 管理ポータルへのアクセスおよび管理権限が与えられる。

ポイント

一方で、

  • アカウントポータルへのアクセス権および管理権限は与えられていない。
  • サービス管理者はアカウント管理者によって変更できる。

Azure Active Directory との関係

  • Azure Active Directory は、

    • Azure の一機能に見えるが、違う。
    • また、包含関係は無く、互いに独立している。
    • ライセンス購入・課金の仕組みも独立している。
      Azure Active Directory の課金はサブスクリプションから
      引き落とされるのではなく、別途購入する形になる。

  • 各サブスクリプション

補足（この節が本ページで最も重要）: 「Azure と Azure AD は独立している」という
原文の指摘は、実務での混乱を避けるうえで極めて重要である。

[ Azure AD テナント ]  ← 「誰か」を管理する（ID の世界）
       │ 信頼
       ├──▶ サブスクリプション A ┐
       ├──▶ サブスクリプション B ├ 「モノ」を管理する（リソースの世界）
       └──▶ サブスクリプション C ┘

ここから次の帰結が生じる。

  • テナントを削除するとサブスクリプションが孤立する（操作不能になる）。
  • サブスクリプションを別テナントに移すと、
    RBAC のロール割り当てがすべて失われる    （ID の実体が変わるため）。
  • 全体管理者は既定で Azure リソースを操作できない
    （必要なら「Azure リソースのアクセス管理」を昇格させる）。

なお現在、Azure AD は Microsoft Entra ID に改称されている。

カーディナリティ（多重度）

ディレクトリ

  • １つのサブスクリプションには、１つの Azure Active Directory のディレクトリに紐付く。
  • １つの Azure Active Directory のディレクトリには、複数のサブスクリプションが紐付く。
ディレクトリ → サブスクリプション

ユーザ

  • １つのサブスクリプションは、ディレクトリに登録された複数人のユーザが操作できる。

  • １人のユーザは、Azure Active Directory B2B collaboration の招待によって、
    複数のディレクトリに所属して、複数のサブスクリプションを操作できる。

  • 故に、ポータルにログインして、操作するサブスクリプションを切替可能。

ユーザ ←──────────┐
  ↑                ↓
  └→ ディレクトリ → サブスクリプション

サブスクリプションとディレクトリの分割

サブスクリプション

サブスクリプションは（業務・環境の単位に）システムで分割しても良い。

補足（最新化）: 現在は、サブスクリプションの上位に
**管理グループ（Management Group）**という階層を作れる。

ルート管理グループ
  ├─ 本番      … Policy「タグ必須」「特定リージョンのみ」を割り当て
  │    ├─ Sub-A
  │    └─ Sub-B
  └─ 検証      … Policy「高額 SKU 禁止」を割り当て
       └─ Sub-C

Azure Policy や RBAC を管理グループ単位で割り当てられるため、
サブスクリプションが増えても統制が破綻しない。
エンプラでサブスクリプションを分割するなら、
管理グループの設計を先に行うのが現在の定石である。

ディレクトリ

補足（なぜ二重に作るのか）: 「認証専用」と「VDC 専用」を分ける理由は、
Azure Virtual Data Center の操作権限を、
業務ユーザの ID 基盤から切り離すためである。

業務用テナント（オンプレ同期あり）で基盤操作権限まで扱うと、

  • オンプレ AD が侵害されると Azure 基盤まで巻き添えになる、
  • 退職者・異動者の処理が基盤の権限に直結してしまう、

という問題が生じる。分離しておけば影響範囲を限定できる。
一方で運用は二重になるため、
PIM による特権の Just-in-Time 付与（Azure AD Privileged Identity Management (PIM)）で
代替できないかも併せて検討する。

管理者

ユーザとの関連付け

Azure Active Directory 管理者との関係

別の機能であり、管理者も別もの。

参考

AzADのテナント作成方法

Microsoft Learn

構成

最小

アカウント

サブスクリプション管理者アカウント

ネットワーク

１ VNET 内に、１サブネット

VM

使用する数だけ用意する。

NSG

１サブネット向けに１ NSG を作成する。

拡大

アカウント

サブスクリプション管理者権限を付与することなく、
Azure Active Directory B2B collaboration の招待で
同じユーザが複数のサブスクリプションで管理作業をすることができる。

ネットワーク

VM

使用する数だけ用意する。

NSG

追加したサブネット間の通信に関する NSG を追加し、サブネットに関連付ける。

ネットワーク接続

仮想ネットワークに接続する。

OA-LAN から管理端末に接続する。

Azure Virtual Data Center

手順

信頼性・セキュリティ

サービスのセキュア化

参考

参考

Microsoft Learn

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally