Skip to content

MS_AzureSubscriptionMgmtSteps

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

Azure Subscriptionの管理手順@エンプラ

前提条件

キッティングしてもらった初期状態の例

  • Azure Subscription（EA）名の設定

  • Azure AD の

    • 作成
    • 既定のディレクトリ名、ドメイン名の割当
    • サービス管理者になる Microsoft アカウントを追加

  • Azure AD に追加した Microsoft アカウントを、

    • Azure AD の全体管理者の役割（ロール）に追加
    • Azure Subscription のサービス管理者の役割（ロール）に追加

※ 2018/1 月時点:

クラシックポータルが廃止され、
Azure AD ドメインと同じドメインの Microsoft アカウントを
Azure AD に追加できなくなった。
（ドメイン名によって、個人アカウントではなく、組織アカウントと認識されるため）

補足（最新化）: 「サービス管理者」はクラシック デプロイ モデルの概念で、
2024 年 8 月末に提供終了している。
現在のキッティングでは、対象ユーザに
**サブスクリプション スコープの 所有者 ロール（RBAC）**を割り当てる形になる。
手順の骨格（ベース作成 → ユーザ追加 → 権限付与）は変わらない。
詳細は Azure Subscriptionの管理@エンプラ を参照。

ベースの作成

リソース・グループ

リソース・グループを作成する。

ネットワーク

仮想ネットワーク

リソース・グループに仮想ネットワークを作成する。

サブネット

仮想ネットワークにサブネットを作成する。

仮想マシン

リソース・グループに仮想マシンを作成する。

  • 配置する仮想ネットワーク.サブネットを選択する。
  • 以下の、関連するリソースも作成される。

NIC

  • パブリック IP アドレス
    • FQDN 名（DNS）を設定するか、
    • パブリック IP アドレスを固定する。

補足（最新化）: 現在、VM 作成時のパブリック IP は
Standard SKU・静的割り当てが既定である
（Basic SKU は 2025 年 9 月末で提供終了）。
また、Standard SKU のパブリック IP は
既定で受信がクローズされるため、
NSG での明示的な許可が必要になる。
詳細は Azure Load Balancer を参照。

ディスク

※ 基本的に、管理ディスクの方が高額になる。

移行メモ（最新化）: 非管理ディスク（アンマネージド ディスク）は
2025 年 9 月末で提供終了しており、現在は管理ディスク一択である。
したがって「非管理ディスクの方が安い」という選択はもう存在しない。
現在のコスト最適化は、

  • ディスクの種類（Standard HDD / Standard SSD / Premium SSD / Premium SSD v2 / Ultra）
  • サイズと IOPS のバランス（v2 は容量と性能を独立に指定できる）

で行う。詳細は Azureのディスク ストレージ を参照。

自動シャットダウン

  • ポータルから簡単に設定可能。
  • 課金を軽減するため、必要に応じて設定を行う。

補足: 検証・開発環境では効果が大きい。
ただし停止しても課金され続けるもの（ディスク、パブリック IP、
Bastion、Firewall など）があるため、
「VM を止めれば無料」ではない点に注意。
詳細は Azureの課金 を参照。

参考

Azure Bastion

Azure Bastion を使用すると、直接インバウンドを開けずに作業可能。
（AzureBastionSubnet にインバウンドを開け、Azure Bastion 経由にする）

他との違い

管理端末、保守端末向き。
（他の DaaS はリモワなどの業務用）

設定方法

NSG

アウトバウンド

  • 基本的に開放するが、必要に応じて絞る。
  • Azure Firewall を利用可能だが高額。

インバウンド

  • 基本的に全閉するが、必要に応じて開ける。
  • Azure Bastion を使用すれば、直接インバウンドを開けずに作業可能。

設定方法

ユーザの追加

新しいユーザを追加する。

サービス管理者は、

  • Azure AD のドメイン内に直接
    「xxxxx@xxxx.onmicrosoft.com」
    の組織アカウントを作成・登録できる。

  • このままでは、（Office 365 でなければ）メールは受け取れない。

  • 50000 ユーザまで無料だが、数が増えると破綻する。

新しいゲストユーザを招待する。

サービス管理者は、

「Azure Active Directory B2B collaboration」

で マイクロソフト・アカウントのユーザを招待する。

ユーザへ権限を付与する。

上記でアカウントを作成 or 招待しても初期状態で、

  • Azure Subscription の権限はまったくない。
  • Azure AD の権限はゲスト権限しかない。

なので、必要に応じて追加の権限付与（ロールにユーザを追加する）が必要になる。

補足（この「初期状態は無権限」が RBAC の要）: RBAC は
既定が拒否（明示的に許可）である。
ディレクトリに存在することと、リソースを操作できることは無関係。
逆に言えば、ロール割り当てを外せば即座に操作できなくなるため、
退職・異動時の権限剥奪は RBAC 側で完結する。

リソースへの権限付与

アカウント権限を使用する（サブスクリプション管理者）

ロール・レベルで制御する

スコープを選択

  • サブスクリプション
  • リソース・グループ
  • リソース

補足（最新化）: 現在はこれらの上位に
**管理グループ（Management Group）**スコープが加わっている。

管理グループ ＞ サブスクリプション ＞ リソース グループ ＞ リソース

ロール割り当ては下位に継承されるため、

  • 「全社の監査担当は全サブスクリプションの 閲覧者」→ 管理グループに割り当て、
  • 「このシステムの運用担当は当該 RG の 共同作成者」→ リソース グループに割り当て、

というように、最小のスコープに割り当てるのが原則。

役割（ロール）にユーザを追加

  • 上記のスコープを選択して、
  • アクセス制御（IAM）を選択し、
  • 追加ボタンを押下
    • 役割（ロール）を選択
    • 必要に応じて役割（ロール）にユーザを追加

補足（ユーザ個人ではなくグループに割り当てる）: 実務では
ロールの割り当て先はユーザ個人ではなく Azure AD グループにするのが定石。
人事異動のたびにロール割り当てを触る必要がなくなり、
「誰が何を持っているか」の棚卸しもグループ単位で済む。

また、恒久的に強い権限を配らず、
PIM で必要なときだけ昇格させる（Azure AD Privileged Identity Management (PIM)）と、
Azure Virtual Data Center が指摘する
「オペミス・オペレータ不正が最も多い事故」への備えになる。

カスタム・ロールの作成と利用

カスタム・ロールを作成してユーザを追加。

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

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally