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

ハイセキュアな Azure 運用のための
Azure Active Directory テナントの作り方
（→PoC の場合）

• 原則論としては 1 組織 = 1 テナントで、その配下ですべてのクラウド・サービスを利用

• ただし、Azure の運用用のテナントを分けたい場合もある

  • オンプレ AD と同期している Azure Active Directory は
    OA 環境専用（O365 用）

  • 業務システム運用に関わるリソースなど OA 用アカウントと明確に分離しておきたい。

• と言う事で、デプロイ・ガイド（チェックリスト）に、
  幾つかアレンジを加えたモノが本項となっている。

  • 管理を想定したアカウント構成（OA 用アカウントとの切り離し）
  • オンプレ AD とのアカウント同期の削除
  • アプリケーション管理の削除
  • , etc.

補足（このページの位置づけ）: 本ページは、
Azure Subscriptionの管理@エンプラ が述べる
「VDC 専用ディレクトリ」を実際に作る手順書である。
FgCF の
「オンプレが侵害されてもクラウド基盤を巻き添えにしない」という
設計思想が、具体的な作業に落ちている。

【O365 用 AzAD テナント】オンプレ AD と同期。OA 用アカウント
         │ B2B 招待（作業者アカウントのみ）
         ▼
【Azure 運用用 AzAD テナント】同期なし。特権はホーム・アカウント
         │ 信頼
         ▼
   Azure サブスクリプション

• O365 AzAD の EA ポータルからサブスクリプションを作成する。

  • https://ea.azure.com
  • EA 契約管理者からアサインされた EA 契約アカウント管理者が実施。

• ディレクトリ・サブスクリプションには、課金と環境管理の紐付けがある。

  • 初期状態では、O365 AzAD と作成したサブスクリプションが関連付けられる。
  • アカウント管理者：課金、サービス管理者：環境管理ともに、
    サブスクリプションの作成者。

• サブスクリプションの付け替え（信頼テナントの変更）作業

• 特定の期間（通常 30 日から 90 日）に限り、Azure のサービスを試すためのクレジットを提供。

• クレジットの金額や期間は、提供されるパッケージによって異なる（200-1000 ドルのクレジットが付与）

• 主に企業や教育機関向けに提供されることが多く、大規模なプロジェクトや評価のために利用される。

• EA 契約アカウント管理者のアカウントでログイン
  https://www.microsoftazurepass.com/

  • ディレクトリ・サブスクリプションを作成（コード入力、質問回答などを行って作成）

  • ディレクトリ・サブスクリプションが出来たら名称の変更を行う。

  • ディレクトリ・サブスクリプションについては
    「基本的に EA から切り出す。」と同じ。

• サブスクリプションの付け替え（信頼テナントの変更）作業

いずれの方式を利用する場合でも、
複数の作業者でアカウントを共有することは避ける。

個別作成（Azure Active Directory にアカウントを別途作って利用する）

• 一方、退職や人事異動を確実に反映させる必要があり、面倒
• OA 作業からアカウントや端末を切り離せるため、マルウェア攻撃を受け難い。
• 故に、特権アカウントは、B2B アカウントではなく
  ホーム・アカウントを使用すると良い。

B2B 招待（O365 テナントから B2B 招待したアカウントを利用する）

• 1 ユーザ = 1 ID となり、作業者から見て使い勝手がよい
• 多くの場合、人事システムやオンプレ AD と連携しており、退職時に自動失効する
• 故に、各種、作業者アカウントは、コチラを使用すると良い。

補足（トレードオフの整理）: この 2 択は、
「侵害の連鎖を断つ」か「ライフサイクル管理を自動化する」かの
トレードオフである。

	ホーム・アカウント	B2B アカウント
元 OA 環境が侵害されたら	影響を受けない	巻き添えになり得る
退職・異動の反映	手動（漏れやすい）	自動失効
使い勝手	ID が 2 つになる	1 ID で済む
向く用途	特権アカウント（少数）	作業者アカウント（多数）

原文の結論（特権はホーム、作業者は B2B）は、
**「数が少なく重要なものは手間をかけて隔離し、
数が多いものは自動化に乗せる」**という合理的な配分になっている。

どちらの場合でも、以下のようにするのが基本

• セキュリティ管理者（あるいは権限管理システム）に対して、
  静的に Privilege Role Administrator ロールを割り当てる。
• その上で、静的または動的（推奨）に、
  必要に応じて Global Administrator などの作業特権を与える。

• ユーザ単位（またはグループ単位）に権限を付与する
• 高権限をむやみに与えないようにする（最大でも 5 人程度）

Azure AD PIM（特権 ID 管理）を利用して、
ユーザに対して動的に権限を付与・はく奪する。

初期構築時と、構築後の構成変更とを分けて考える。

以下の手順で、初期構築用アカウントに加え
複数アカウントを使い回すので...。

加えて、キャッシュが残らないようにできる。

そもそも別物なので。

• WWWブラウザのセッション等を別にする。

ユーザ・プロファイルも別になる。

• 通常は、既存の O365 用 AzAD テナントを利用

• 検証用なら

  • 既定のディレクトリ（使用できる？）か、

  • 以下からダミー・テナントを作成しても良い。
    https://account.azure.com/organization

    • 全体管理者アカウントを作成する。

    • サブスクリプションは作成しない。

    • Azure ポータル > Azure Active Directory に遷移

    • 以下の 4 つのアカウントを作成

• ダミー・テナントと同じ方法で作成。

  • 全体管理者アカウントを
    「初期構築用アカウント」として作成。
  • サブスクリプションは作成しない。

• Azure ポータル > Azure Active Directory に遷移

  • P2 ライセンスの試用版の有効化

  • テナント（ディレクトリ）の属性を変更
    名称や詳細の記述を変更する。

  • 全体管理者アカウント（初期構築用アカウント）の属性を変更

    • 名称や詳細の記述を変更する。
    • サブスクリプションの RBAC アクセス権限を取得するよう設定する。

補足（「Azure リソースのアクセス管理」の昇格）: 最後の項目は、
Azure AD の 全体管理者 が
既定では Azure リソースを操作できないことへの対処である。
[Azure AD] > [プロパティ] の
**「Azure リソースのアクセス管理」を「はい」**にすると、
ルート管理グループに対する ユーザー アクセス管理者権限が付く。

これは強力な操作なので、
必要な作業が終わったら「いいえ」に戻すのが原則である
（本手順でも、Step 5 で初期構築用アカウント自体を削除している）。

• 以下の 4 つのアカウントを作成
  • 緊急事態用アカウント（Breakglass Account）
    Azure AD 用、Azure 用の 2 つが必要
    • ホーム・アカウントとして作成し、
    • 条件付きアクセスなどの適用対象外にする必要がある
      （代わりに、パスワード長を長めに設定する）
  • Azure AD 管理用アカウント
    日常的な Azure AD の管理用に利用するアカウントだが、以下 2 つの検討が必要
    • ホーム or B2B アカウントどちらを利用するのか？
    • 静的 or 動的どちらの方法で権限割り当てを行うのか？

※ 上記の表の通り、Azure 権限を除いて、アカウントを作成する。

補足（この 4 アカウント構成の意図）: 一見すると冗長だが、
それぞれに明確な役割がある。

① bg_admin_aad     … AzAD が壊れたときの最後の砦（共用・封緘）
② bg_admin_azure   … Azure 側が壊れたときの最後の砦（共用・封緘）
③ XXXX_prv_admin   … 「権限を配る人」。自分では作業しない
④ YYYY_aad_admin   … 「作業する人」。普段は Global Reader、必要時に PIM で昇格

③ と ④ を分けるのが要点で、
「権限を配る役」と「権限を使う役」を別人にすることで、
自分で自分に権限を与えられない状態を作っている
（職務の分離、Separation of Duties）。

また、緊急事態用を AzAD 用と Azure 用の 2 つに分けているのは、
Azure Subscriptionの管理@エンプラ が述べる
**「Azure AD と Azure は独立している」**という構造に対応している。

• 作成後の設定

  • Azure AD 用の緊急事態用アカウント

    • P2 ライセンスの設定
    • パスワード・ポリシーの変更
    • 管理者アカウントの保護
    • Azure 権限付与
    • 封緘用パスワードの設定

  • Azure 用の緊急事態用アカウント

    • P2 ライセンスの設定
    • パスワード・ポリシーの変更
    • 管理者アカウントの保護
    • Azure 権限付与（ルート管理グループ）
    • 封緘用パスワードの設定

  • 特権ロール管理用の個人アカウント

    • P2 ライセンスの設定
    • パスワード・ポリシーの変更
    • 管理者アカウントの保護

  • Azure AD 管理者用の個人アカウント

    • P2 ライセンスの設定
    • パスワード・ポリシーの変更
    • 管理者アカウントの保護

• パスワード保護機能（必要に応じて）

  • [Azure Active Directory] > [セキュリティ] > [認証方法] > [パスワード保護] を開く
  • 必要に応じてロックアウト、禁止パスワードの登録などを行う

• パスワード有効期限の無効化

  • 既定は 90 日で失効
  • 緊急事態用アカウントでは必須
  • PowerShell で設定

Install-Module -Name AzureAD
Connect-AzureAD
Get-AzureADUser -Filter "startswith(userPrincipalName,'緊急事態用アカウントのプレフィックス')" | Set-AzureADUser -PasswordPolicies DisablePasswordExpiration

補足（最新化）: AzureAD PowerShell モジュールは廃止されており、
現在は Microsoft Graph PowerShell SDK を使う。

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "User.ReadWrite.All"
Get-MgUser -Filter "startswith(userPrincipalName,'bg_admin')" |
  ForEach-Object { Update-MgUser -UserId $_.Id -PasswordPolicies "DisablePasswordExpiration" }

なお、現在のクラウド テナントは既定でパスワード無期限であり、
「既定は 90 日で失効」は当時の設定である。
NIST SP 800-63B 以降、定期変更の強制は推奨されなくなった
（漏洩時に即座に変更する方が重要）ため、
この設定は現在の考え方とも整合する。

• セキュリティ・グループの作成と割当

  • 緊急事態用アカウント用グループを作成し、各アカウントに割当

  • 個人アカウント用グループを作成し、各アカウントに割当
    権限を PIM で JIT 割当する YYYY_aad_admin@prodaad のような
    アカウントは変更される可能性が高いので、対象外にする等。

  • 必要に応じて、B2B を使用している場合など、動的メンバーシップ・ルールを使用する。

• 条件付きアクセスの有効化

  • 対象

    • 対象：個人アカウント用グループ
    • 対象外：緊急事態用アカウント用グループ

  • アクセス制御で、多要素認証（MFA）などを追加する。
    その他、ネームド・ロケーション、セキュア・ワークステーション等がある。

  • レポート専用で作成して、問題なく動作しているか確認してからオンする。

• ID 保護の有効化

  • 対象

    • 対象：個人アカウント用グループ
    • 対象外：緊急事態用アカウント用グループ

  • ユーザ・リスク、サインイン・リスク、MFA 登録ポリシーなどを追加する。

Step 1 のテナントで、サブスクリプションを作成する。

• 作成に使用するアカウントは、
  EA アカウント管理者の個人アカウント（ea_aa@o365aad）

• ２つのテナントに１つのサブスクリプションとなる。

• 次に、既定のテナントとサブスクリプションの関連付けを変更する。
  サービス管理者：環境管理のみ関連付けを変更する。

• Step 1 のテナントから
  Step 0 のテナントの
  EA 契約アカウント管理者（ea_aa@o365aad）を、
  初期構築アカウントを使用して、B2B で招待する。

• EA 契約アカウント管理者（ea_aa@o365aad）は、招待を承認する。

  • メールボックスがない場合、
    EA 契約アカウント管理者（ea_aa@o365aad）が以下の URL 直打ちでも行ける。
    http://portal.azure.com/<Step 1 のテナント>.onmicrosoft.com

    • 招待を承認する。
    • ディレクトリの切替が可能になる。

  • ディレクトリを切り替える

    • Step 0 のテナントでは、サブスクリプション、アリとなる。
    • Step 1 のテナントでは、サブスクリプション、ナシとなる。

  • ディレクトリの変更を実行する。

    • コレを、Step 0 のテナントのサブスクリプションで行う。
    • フェイルオーバー先に Step 1 のテナントを指定する（30 分-1 時間かかる）。

• サービス管理者：環境管理を、

  • EA 契約アカウント管理者（ea_aa@o365aad）から
  • Azure 用の緊急事態用アカウント（bg_admin_azure@prodaad）に

  変更する。...が「Microsoft Azure Pass」だと出来ないとのこと。

補足（この作業で失われるもの）: サブスクリプションのディレクトリを
変更すると、既存の RBAC ロール割り当てがすべて消える。
ID の実体（オブジェクト ID）が別テナントのものになるためで、
移行後に付け直しが必要になる。

したがって、この付け替えはサブスクリプション作成直後に行うのが鉄則。
運用開始後に行うと、権限の再設計と再割り当てが発生する。

また、原文が触れているとおり
課金（アカウント管理者）とディレクトリの紐付けは別物であり、
ディレクトリを移しても課金は EA 側に残る。

• 初期構築アカウントでログインし、
  「Azure リソースのアクセス管理」が「はい」に
  なっていることを確認し、以下の作業を行う。

• 自身がユーザ・アクセス管理者（User Access Administrator）権限を
  持っているので、自身に更に所有者（Owner）権限を追加する。

  • 管理グループ（Tenant Root Group）のアクセス制御（IAM）画面から、
    Azure AD 用の緊急事態用アカウント（bg_admin_aad@prodaad）に以下の権限を割当てる。
    • 所有者（Owner）
    • ユーザ・アクセス管理者（User Access Administrator）

サブスクリプションに対し各種のログを長期保存
するため、ストレージの作成と診断ログの設定を行う。

• 初期構築用アカウントに対して、
  当該 Azure サブスクリプションに対する Owner 権限を付与

• 以下 3 つのリソースを作成

  • リソース・グループ

  • Log Analytics ワーク・スペース
    イベント・ログの収集と表示

  • ストレージ・アカウント

    • より長期のログ保管のストレージ
    • プライベート・エンドポイントを指定（パブリック・エンドポイントを塞ぐ）

• 診断設定を有効化する。

  • Azure AD > サインイン > データ設定のエクスポート > 診断設定
  • サブスクリプション > アクティビティ・ログ > 診断設定

補足（なぜ最初にログを作るのか）: 診断設定は
有効化した時点以降のログしか記録されない（遡れない）。
したがって、運用を始める前に必ず構成する必要がある。

Azure AD のサインイン ログは、既定の保持期間が
ライセンスにより 7〜30 日と短いため、
監査要件がある場合は Log Analytics や
ストレージへの送出が事実上必須になる。

• 緊急事態用アカウントの２つのオブジェクト ID を調査する（xxxx, yyyy）。

• Log Analytics ワークスペースに
  2 種類のアラート・ルールを追加

  • 緊急事態アカウントのサインイン（重大度 0）

    • Custom Log Search から以下の検索クエリを指定

SigninLogs
| project UserId
| where UserId == "xxxx" or UserId == "yyyy"

- アラート・ロジック：「結果の数が 0 より大きい場合」（既定値）

- セキュリティ・チームの ML 宛にメール送信するアクション・グループを作成・設定

- アラート・ルールの詳細でタイトル、本文、重大度 0 など設定。

• 緊急事態アカウントの設定変更（重大度 1）

  • Custom Log Search から以下の検索クエリを指定

AuditLogs
| where TargetResources[0].id == "xxxx" or TargetResources[0].id == "yyyy"

- アラートロジック：「結果の数が 0 より大きい場合」（既定値）

- 先ほど作成したアクション・グループを設定

- アラート・ルールの詳細でタイトル、本文、重大度 1 など設定。

• 参考
  • 緊急アクセス用管理者アカウントを管理する
    https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access

補足（この監視が構成の要）: 緊急事態用アカウントは
条件付きアクセスの対象外であり、
かつ Global Administrator / Owner という最強の権限を持つ。
つまり、このアカウントが使われた ＝ 何かが起きているか、
侵害されているかのどちらかである。

したがって、

• サインインの検知（誰かが使った）→ 重大度 0
• 設定変更の検知（誰かが属性を触った）→ 重大度 1

の 2 本立てで監視するのが必須になる。
クエリは KQL で書かれており、
Azure Alerts のログ アラートとして構成する。

• 封緘パスワードの用意

Add-Type -AssemblyName System.Web
$len = 30
do { $pwd = [System.Web.Security.Membership]::GeneratePassword($len,0) } until `
( $pwd -match '^[0-9a-zA-Z]+$' ); $pwd

• 緊急事態アカウントでサインイン
  初回アクセス時に PWD 変更が求められるので、封緘パスワードに変更。

• 緊急事態アカウントの動作確認
  ログイン、権限確認、監査ログの参照などを行う。

• 緊急事態アカウントのパスワードの封緘
  アカウント情報を封緘（リアルに封筒などに入れる）

• 前述の緊急事態アカウントのアラート確認
  初期構築用アカウントで確認する。

補足（記号を除外している理由）: 上記のスクリプトが
-match '^[0-9a-zA-Z]+$' で英数字のみに絞っているのは、
封緘（紙に印刷して封筒に入れる）した際の
転記ミスを避けるためと解される。
記号は手書き・読み上げで誤りやすい。
その分の強度低下は長さ 30 文字で補っている。

運用面では、

• 2 アカウントのパスワードを別々の人が保管する、
• 封緘の開封記録を残す、
• 定期的に（例: 半年ごと）動作確認を行う
  （いざというときに使えないと意味がない）、

といった手順も併せて定める必要がある。

• 特権ロール管理用の個人アカウント（XXXX_prv_admin@prodaad）でログイン
• PIM で Azure AD 管理者用の個人アカウント（YYYY_aad_admin@prodaad）に、ロールを割当てる。
• Azure AD 管理者用の個人アカウント（YYYY_aad_admin@prodaad）でログインして構成作業を行う。

• 全体セキュリティ管理者アカウントの動作確認後、
• 初期構築用アカウントを削除する。

補足（最後に消すことの意味）: 初期構築用アカウントは、
構築のために全体管理者 ＋ ルート管理グループの所有者という
極めて強い権限を一時的に持つ。
これを残すと「条件付きアクセスも PIM も通らない万能アカウント」が
常設されることになり、ここまでの設計がすべて無意味になる。

削除する前に、① 緊急事態用アカウントで入れること、
② PIM 経由で日常運用ができること、
の 2 つを必ず確認するという手順の順序が重要である。

• グローバル管理者は MFA 必須でデバイスをロストしたりすると
  誰もログインできないテナントが出来上がる。

• そんな場合は、私の場合はプレミアサポートから誘導して貰った窓口に対応してもらった。

• で、窓口はドコに？...→ ココにヒントが（個人契約の場合はどうするの？）。

  • [2025/1/15 更新] 一般法人向け Microsoft 365 サポート窓口のご紹介
  • 機種変更後の Authenticator の回復のためオペレータの方と会話する方法

補足（まさにこれが緊急事態用アカウントの存在理由）: この「MFA 死亡」は、
本ページが冒頭から用意している緊急事態用アカウントが
解決するはずの事象そのものである。
逆に言えば、緊急事態用アカウントを用意していないテナントは、
デバイス紛失や条件付きアクセスの設定ミス 1 つで
サポートに頼るしかない状態に陥る。

• Microsoft Entra デプロイ チェックリスト
  https://learn.microsoft.com/ja-jp/entra/architecture/deployment-checklist-p2
• セルフサービス パスワード リセット ポリシー
  https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-sspr-policy

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, アカウント, 認証基盤, Azure, Active Directory