Skip to content

MS_AzureADTenantCreation

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 2 revisions

Azure Active Directoryのテナント作成方法

概要

ハイセキュアな 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 サブスクリプション

詳細

サブスクリプション

基本的に EA から切り出す。

検証では、ダミー・テナントを使用。

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

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

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

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

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

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

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

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

ホーム / B2B

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

ホーム・アカウント

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

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

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 管理）を利用して、
ユーザに対して動的に権限を付与・はく奪する。

手順

初期構築用アカウント

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

２つのアカウントを併用するので...。

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

InPrivate ブラウザで作業するなど。

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

異なるブラウザを使用する（Edge と Chrome）。

そもそも別物なので。

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

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

Step 0. O365 用 AzAD テナント

アカウント 役割 備考
ea_ea@o365aad EA エンタープライズ管理者の個人アカウント
ea_aa@o365aad EA アカウント管理者の個人アカウント Azure サブスクリプション払い出し
xxxx@o365aad 一般ユーザ１の個人アカウント
yyyy@o365aad 一般ユーザ２の個人アカウント

Step 1. Azure 用 AzAD テナントの作成

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

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

Step 2. 管理者アカウントの作成と保護

アカウントの作成

  • 以下の 4 つのアカウントを作成
    • 緊急事態用アカウント（Breakglass Account）
      Azure AD 用、Azure 用の 2 つが必要
    • Azure AD 管理用アカウント
      日常的な Azure AD の管理用に利用するアカウントだが、以下 2 つの検討が必要
ID 役割 役割（詳細） 主な日常作業 個人/共用 ホーム/B2B AzAD 権限 Azure 権限
bg_admin_aad@prodaad 緊急事態用アカウント Azure AD 用 ナシ 共用 ホーム Global Administrator（静的） 昇格権限
bg_admin_azure@prodaad 緊急事態用アカウント Azure 用 ナシ 共用 ホーム ナシ Tenant Root Group/owner（静的）
XXXX_prv_admin@prodaad 個人アカウント 特権ロール管理用 AzAD, Azure の権限払い出し 個人 ホーム or B2B Privilege Role Administrator（静的） なし（暗黙的に User Access Admin を持つ）
YYYY_aad_admin@prodaad 個人アカウント Azure AD 管理者用 AzAD の設定・操作・監査 個人 ホーム or B2B ・（Global Reader（静的））<br>・Global Administrator（PIM） ナシ

※ 上記の表の通り、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 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 3. Azure サブスクリプションの準備

サブスクリプションを作成する。

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

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

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

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

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

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

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

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

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

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

Azure 権限付与（ルート管理グループ）

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

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

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

Step 4. ログ・監視・アラートの設定

長期ログ保存のための設定

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

  • 初期構築用アカウントに対して、
    当該 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 など設定。

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

したがって、

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

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

Step 5. テストとクリーンアップ

緊急事態アカウントの動作確認

  • 封緘パスワードの用意
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 死亡

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

Microsoft Learn

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

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally