• 戻る（Azure、Microsoft Azure Active Directory）
  • Azureの評価環境を入手する
  • AzureのPoC環境を契約する
  • AzureのPoC環境を構築する
  • Azure上に素早く環境を構築する
  • AzADのテナント作成方法
  • Azure Subscriptionの管理@エンプラ
    ＞ Azure Subscriptionの管理手順@エンプラ
    • Azureによる基盤開発法
    • Azureの高可用性設計
    • Azureの監視と管理
    • Azureのアクセス制御と権限

評価環境では出来ない事も多いので。

補足（Azure の契約が分かりにくい理由）: Azure の契約は
3 つの層が別々の概念であるため、初見では混乱しやすい。
本ページはこの 3 層を順に扱っている。

① アカウント     … 契約を行う「人」（Microsoft アカウント or 組織アカウント）
     ↓ が
② ディレクトリ（テナント） … 「誰がいるか」を持つ入れ物（Microsoft Entra ID）
     ↓ に紐づく
③ サブスクリプション  … 「何を作れて、誰に請求するか」の単位

要点は次のとおり。

層	何を入れるか	課金
ディレクトリ（テナント）	ユーザ・グループ・アプリ登録	原則無料（Premium 機能は有償）
サブスクリプション	リソース（VM・ストレージ等）	ここが課金単位
リソース グループ	サブスクリプション内のリソースの束	－

1 つのディレクトリに複数のサブスクリプションをぶら下げられる一方、
1 つのサブスクリプションは必ず 1 つのディレクトリに信頼を置く。
「サブスクリプションを別のディレクトリに移す」ことも可能だが、
RBAC の割り当てが全て消えるため注意が要る。

契約を行うアカウント（ディレクトリとテナントの管理者になる）

無料アカウントは正確には無料のアカウントではなく、
個人アカウントに紐ついた無料の Azure ディレクトリとサブスクリプションの事。

個人アカウントは Microsoft アカウントで

組織アカウントは組織のディレクトリと同期された、組織アカウントで

※ 参考：AzAD オンプレミス・ディレクトリとの同期

• ディレクトリは Azure ユーザを格納するもので、テナントは Azure リソースを格納するもの。
• ただ、双方の TOP 管理者が、ディレクトリを作成してサブスクリプション契約してテナント化すると言う意味で関係がある。
• テナントのリソースへのアクセス許可は、ディレクトリに登録されたユーザに対して行われる。

補足（用語の整理）: 本文の「ディレクトリ」と「テナント」の使い分けは
現場での慣用に沿ったものだが、Microsoft の現在の用語では
両者は同じものを指す（Microsoft Entra ID のテナント）。

呼び方	指すもの
Azure AD ディレクトリ	同一のもの。「ユーザが入っている」側面を強調した呼び方
Azure AD テナント	同一のもの。「組織の区画」という側面を強調した呼び方
サブスクリプション	別物。リソースと課金の単位

本文が言う「テナントは Azure リソースを格納する」は、
厳密にはサブスクリプションの役割である。
ただし、サブスクリプションがテナントに信頼を置くという
関係を踏まえた表現であり、実務上の理解としては通じる。

なお、Azure Active Directory は 2023 年に
Microsoft Entra ID に改称された。

• 個人アカウントの場合はコチラで OK（違う用途の場合、ディレクトリを新規作成することもできる）
• 組織アカウントの既定のディレクトリは ≒ O365用と運用用のディレクトリでコチラ使うのは NG

• 組織アカウントの既定のディレクトリ
• AzureADのPremiumを使用する場合。

移行メモ（正誤）: 原典は「O356」と誤記されていたため
「O365（Office 365）」に修正した（2 箇所）。

補足（なぜ本番テナントで PoC をやってはいけないのか）: 本文が
「コチラ使うのは NG」とする理由は、次のとおり明確である。

リスク	内容
権限の巻き添え	PoC のために付与したロールが全社の Microsoft 365 に効いてしまう
条件付きアクセスの影響	全社ポリシー（MFA・デバイス準拠）が PoC 作業を阻む／逆に緩めると全社に穴が開く
削除できない	PoC が終わってもテナントごと捨てられない
監査ログの混在	検証の操作が本番の監査ログに混ざる

PoC 用には**別テナント（別ディレクトリ）**を切るのが原則であり、
後掲の「ディレクトリ（テナント）作成手順」がその話になる。

なんだか、色々と紆余曲折があったらしい。

• Qiita carol0226
  • はじめての Microsoft Entra テナント の作成 #初心者
    https://qiita.com/carol0226/items/e560688f2b6a93e97126
  • Microsoft Entra テナント の削除 #Azure
    https://qiita.com/carol0226/items/0e28af0cfd4e7a5acf6d
  • テナントが 追加作成できない = 顛末と解決策 #AzureAD
    https://qiita.com/carol0226/items/3eed9674c17f73c78ba2
• Azure ポータルの強制 MFA 認証の無効化 - 株式会社システムサポート
  https://www.cloud-koubou.jp/news-blog/5800/
• ん...
  • 結局、専任 or 緊急事態用（Breakglass Account）グローバル管理者の MFA を無効にできない。
  • 結局、別のデバイス保持者に緊急事態用グローバル管理者のアカウントへのログインをしてもらい 2 重化するのが良いのかと。

補足（この「紆余曲折」の背景）: テナント作成でつまずく主因は、
Microsoft 側がセキュリティ要件を年々厳しくしていることにある。

変更	影響
Azure ポータルへの MFA 必須化（2024 年〜順次）	例外を作れない。管理操作に必ず MFA が要る
テナント作成の制限	ゲスト ユーザや一部のライセンス状態では作成できない
セキュリティ既定値群	新規テナントでは既定で有効。管理者は MFA 必須になる

本文の結論**「緊急事態用グローバル管理者を 2 重化する」**は、
Microsoft が推奨する Break-glass アカウントの考え方そのもので、
現在の正しい対処である。要点は次のとおり。

• 2 つ以上用意する（1 つが壊れても入れるように）。
• 条件付きアクセスの対象から除外する（ポリシーの事故で締め出されないため）。
• ただし MFA は無効にせず、
  FIDO2 セキュリティ キーなどフィッシング耐性のある方式を、
  異なる担当者・異なるデバイスに分けて持たせる。
• クラウド専用アカウントにする（オンプレ AD 同期が壊れても入れるように）。
• サインインを監視し、使われたらアラートを上げる。

「MFA を無効化する」方向で解こうとすると行き詰まるのは、
仕様どおりである。

• 12 ヶ月間特定の Azure サービスを無料で利用できる
• 最初の 30 日間は 200 ドルのクレジットが付与される。
• ただ、VM サイズが、B1S に限定される模様。
• 参考
  • Azure の無料アカウントを今すぐ作成しましょう
    https://azure.microsoft.com/ja-jp/free/
    • 人気の無料サービス（12 か月）
    • ¥22,500 のクレジット（30 日間）
    • 25 種類以上のサービス（いつでも無料）
  • Azure 無料アカウント FAQ
    https://azure.microsoft.com/ja-jp/free/free-account-faq/

補足（無料枠の落とし穴）: 「無料」の中身は 3 種類あり、
混同すると想定外の請求になる。

種類	期間	注意
クレジット	30 日	使い切るか期限が来ると終わり
12 か月間無料のサービス	12 か月	数量上限がある（B1S は月 750 時間まで＝1 台常時起動分）
常に無料のサービス	無期限	Functions の実行回数など、上限内のみ

特に注意すべきは、

• 上限を超えた分は普通に課金される（無料枠は「上限まで割引」であって遮断ではない）、
• 12 か月経過後は自動的に従量課金へ移行する（アップグレードした場合）、
• B1S を2 台動かせば 750 時間はすぐ尽きる

という点である。
予算アラートの設定（後述）を最初に行うこと。

• 試用/評価用だが、プロモーションコードが必要。
• プロモーションコードの取得方法
  • MS 主催のイベントやトレーニングで提供される。
  • パートナー企業、教育機関（学生や教育向け）に提供される。
  • 一般的ではないが、EA で取得して、後に EA に変換する等もできるらしい。

• 個人、法人のカジュアルな契約
• 組織アカウントでは作成したディレクトリのゲストユーザになるため契約できないことがある。
• その場合、サブスクリプションに対応するディレクトリのユーザで契約（リソース → サブスクリプション → 追加）する。
• 直接購入と CSP 経由購入がある（CSP 経由は Azure ベースのサービスを利用する際の契約になるのでココでは対象外）。

• O365用と運用用のディレクトリを利用できる。
• PoC レベルだと、多くの場合、法人契約など、ゼロからは出来ないので、既存の契約の管理者と連携して作業をすすめる（AzADのテナント作成方法）。

• Azure のライセンス形態・契約パターン（MOSP・CSP・EA…MPA・MCA って？）
  https://zenn.dev/tomot/articles/c4b222c140ddbb

補足（契約形態の対応表）: 打ち消し線が示すとおり
MOSP は MCA に置き換わっている。用語の対応は次のとおり。

略称	正式	位置付け
MOSP	Microsoft Online Subscription Program	旧称。Web から直接申し込む従量課金
MCA	Microsoft Customer Agreement	現行。MOSP の後継。個人・法人が直接契約
EA	Enterprise Agreement	大企業向けの包括契約。前払い・年単位
CSP	Cloud Solution Provider	パートナー経由。請求・サポートをパートナーが担う
MPA	Microsoft Partner Agreement	CSP パートナー側が結ぶ契約

PoC で選ぶなら、

状況	選択
個人・小規模、すぐ始めたい	MCA（従量課金）
既に社内に EA がある	EA の管理者にサブスクリプションを切ってもらう（本文の推奨）
日本語サポートや請求書払いが要る	CSP

本文が「ゼロからは出来ないので既存の契約の管理者と連携」と書くのは、
EA は個人が新規に結べる契約ではないためである。

契約後の構築

• 1 人作業なら Azure Bastion がアレばなんとかなる。
• Resource Group（RG）は分割し、VNET は分割しないのが簡潔。
  （VM 用 RG と Bastion 用 RG を分割し、同一 VNET に格納する）

移行メモ（体裁）: 原典の「なんとなかなる」は
「なんとかなる」の誤りであるため修正した。

補足（この RG 分割の意図）: 「RG は分割し、VNET は分割しない」という
一見ちぐはぐな指針には理由がある。

対象	方針	理由
リソース グループ	分ける	まとめて削除できる単位だから。VM 用 RG を消しても Bastion は残る（Bastion は作成に時間と費用がかかるので残したい）
VNET	分けない	分けるとピアリングが必要になり、構成も費用も増える。Bastion は同一 VNET 内の VM にしか繋がらない（ピアリング無しの場合）

つまり、
「壊して作り直す単位」と「繋がっている必要がある単位」を
それぞれ最適化している、という設計である。

なお、Bastion は専用サブネット AzureBastionSubnet（/26 以上）が
必須である点に注意する。

チーム作業なら、Azure Bastionに加え、ある程度構築が必要になる
（Azure Subscriptionの管理@エンプラ）。

• 月単位等で実コスト / 予測コストに基づいてアラートを構成できる。
• コストの管理と請求 > 予算から設定する。
• 参考
  • チュートリアル - Azure の予算を作成して管理する | Microsoft Docs
    https://docs.microsoft.com/ja-jp/azure/cost-management-billing/costs/tutorial-acm-create-budgets

補足（予算アラートは「止めない」）: 最重要の注意点として、
Azure の予算は通知するだけで、課金を止めない。
上限に達してもリソースは動き続ける。

実際に止めたい場合は、

手段	内容
アクション グループ + Automation Runbook	予算アラートを契機にVM を停止する等の処理を自動実行
自動シャットダウン	VM 単位で時刻指定（Azureの評価環境を入手する）
使用制限（無料アカウントのみ）	無料枠を超えたらサービスを無効化する。従量課金にアップグレードすると使えなくなる

PoC では

• **予算アラートを複数段（50% / 80% / 100% / 予測 100%）**設定する、
• 自動シャットダウンを全 VM に設定する

の 2 つを最初にやっておくのが実務上の定石である。
詳細はAzureの課金を参照。

Azure Security Centerはオーバースペックなので、

• Public IP アドレス一覧

  • Azure CLI

    az network public-ip list
    

  • Azure PowerShell

    Get-AzPublicIpAddress | ConvertTo-Json
    

  • 参考

    • パブリック IP アドレスの管理 - Azure Virtual Network | Microsoft Docs
      https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-public-ip-address

補足（なぜパブリック IP の一覧なのか）: PoC 環境で最も現実的なリスクは、
意図せず外部に露出したリソースである。
検証のために一時的に開けたポートや、
ポータルの既定値のまま作った VM のパブリック IP が、
そのまま残り続ける。

したがって、「パブリック IP を持つリソースの一覧」を
定期的に確認するというのは、
高価なセキュリティ製品を導入せずに実施できる、
費用対効果の高い運用である。

併せて確認したいものを挙げておく。

• 受信を許可している NSG 規則
  （Network Security Group (NSG)）
• パブリックにアクセス可能なストレージ アカウント
  （Azureのストレージ）

なお、本文が「オーバースペック」とする
Security Center（現 Microsoft Defender for Cloud）は、
現在**無料の「基本的な CSPM」**が既定で有効になっており、
セキュリティ スコアと推奨事項の閲覧だけなら追加費用なしで使える。
有償になるのは脅威検知（Defender プラン）の部分である。

• Microsoft Azure 課金と契約パターン完全ガイド | the Biztech blog
  https://career-tech.biz/2020/03/13/azure-contract-billing/
• Azure で法人契約をしていく前に知っておくべきこと – Azure 導入開発支援
  https://www.acrovision.jp/service/azure/?p=2054
• Azure の 4 つのライセンス形態と料金
  〜Azure CSP を利用するメリット〜
  Microsoft Azure コラム｜東京エレクトロンデバイス
  https://esg.teldevice.co.jp/iot/azure/column/column10.html

---

Tags: 移行, インフラストラクチャ, クラウド, Azure