「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ハイセキュアな Azure運用のためのAzure Active Directoryテナントの作り方
- 原則論としては 1 組織 = 1 テナントで、
その配下ですべてのクラウド・サービスを利用
- ただし、Azureの運用用のテナントを分けたい場合もある
- 業務システム運用に関わるリソースなど
OA用アカウントと明確に分離しておきたい。
- と言う事で、
デプロイ・ガイド（チェックリスト）に、
幾つかアレンジを加えたモノが本項となっている。
- 管理を想定したアカウント構成
（OA用アカウントとの切り離し）
- オンプレAD とのアカウント同期の削除
- アプリケーション管理の削除
- , etc.
詳細 †
サブスクリプション †
基本的にEAから切り出す。 †
- 初期状態
- O365 AAD の EAポータルからサブスクリプションを作成する。
- ディレクトリ・サブスクリプションには、課金と環境管理の紐付けがある。
検証では、ダミー・テナントを使用。 †
- 「Microsoft Azure Pass」を使用して、払い出しを行うことが出来る。
ホーム / B2B †
いずれの方式を利用する場合でも、
複数の作業者でアカウントを共有することは避ける。
ホーム・アカウント †
個別作成（Azure Active Directoryにアカウントを別途作って利用する）
- 一方、退職や人事異動を確実に反映させる必要があり、面倒
- OA 作業からアカウントや端末を切り離せるため、マルウェア攻撃を受け難い。
- 故に、特権アカウントは、B2Bアカウントではなくホーム・アカウントを使用すると良い。
B2Bアカウント †
B2B 招待（O365 テナントから B2B 招待したアカウントを利用する）
- 1 ユーザ = 1 ID となり、作業者から見て使い勝手がよい
- 多くの場合、人事システムやオンプレ AD と連携しており、退職時に自動失効する
- 故に、各種、作業者アカウントは、コチラを使用すると良い。
静的 / 動的 †
どちらの場合でも、以下のようにするのが基本
- セキュリティ管理者（あるいは権限管理システム）に対して、
静的に Privilege Role Administrator ロールを割り当てる。
- その上で、静的または動的（推奨）に、
必要に応じて Global Administrator などの作業特権を与える。
静的権限 †
- ユーザ単位（またはグループ単位）に権限を付与する
- 高権限をむやみに与えないようにする（最大でも 5 人程度）
動的権限 †
Azure AD PIM（特権 ID 管理）を利用して、ユーザに対して動的に権限を付与・はく奪する。
手順 †
２つのアカウントを併用するので...。 †
以下の手順で、複数アカウントを使い回すので...。
InPrivate?ブラウザで作業するなど。 †
加えて、キャッシュが残らないようにできる。
異なるブラウザを使用する（EdgeとChrome）。 †
そもそも別物なので。
ユーザ・プロファイルも別になる。
Step 0. O365 用 AAD テナント †
- 通常は、既存の O365 用 AAD テナントを利用
- 以下の 4つのアカウントを作成
| ea_ea@o365aad | EA エンタープライズ管理者の個人アカウント | |
| ea_aa@o365aad | EA アカウント管理者の個人アカウント | Azure サブスクリプション払い出し |
| xxxx@o365aad | 一般ユーザ１の個人アカウント | |
| yyyy@o365aad | 一般ユーザ２の個人アカウント | |
Step 1. Azure 用 AAD テナントの作成 †
- ダミー・テナントと同じ方法で作成。
- 全体管理者アカウントを
「初期構築用アカウント」として作成。
- サブスクリプションは作成しない。
- テナント（ディレクトリ）の属性を変更
名称や詳細の記述を変更する。
- 全体管理者アカウント（初期構築用アカウント）の属性を変更
Step 2. 管理者アカウントの作成と保護 †
アカウントの作成 †
- 以下の 4つのアカウントを作成
- 緊急事態用アカウント（Breakglass Account）
Azure AD 用、Azure 用の 2 つが必要
- Azure AD 管理用アカウント
日常的な Azure AD の管理用に利用するアカウントだが、以下 2 つの検討が必要
| ID | 役割 | 主な日常作業 | 個人/共用 | ホーム/B2B | AAD 権限 | Azure 権限 |
| bg_admin_aad@prodaad | 緊急事態用
アカウント | Azure AD 用 | ナシ | 共用 | ホーム | Global Administrator（静的） | 昇格権限 |
| bg_admin_azure@prodaad | Azure 用 | ナシ | Tenant Root Group/owner（静的） |
| XXXX_prv_admin@prodaad | 個人アカウント | 特権ロール管理用 | AAD, Azure の
権限払い出し | 個人 | ホーム or B2B | Privilege Role Administrator (静的) | なし（暗黙的に User Access Admin を持つ） |
| YYYY_aad_admin@prodaad | Azure AD 管理者用 | AAD の設定・操作・監査 | ・（Global Reader（静的））
・Global Administrator（PIM） | ナシ |
※ 上記の表の通り、Azure 権限を除いて、アカウントを作成する。
パスワード・ポリシーの変更 †
- パスワード保護機能（必要に応じて）
- [Azure Active Directory] > [セキュリティ] > [認証方法] > [パスワード保護]を開く
- 必要に応じてロックアウト、禁止パスワードの登録などを行う
管理者アカウントの保護 †
- 緊急事態用アカウント用グループを作成し、各アカウントに割当
- 個人アカウント用グループを作成し、各アカウントに割当
権限をPIMでJIT割当するYYYY_aad_admin@prodaadのような
アカウントは変更される可能性が高いので、対象外にする等。
- 必要に応じて、B2Bを使用している場合など、動的メンバーシップ・ルールを使用する。
- 対象
- 対象：個人アカウント用グループ
- 対象外：緊急事態用アカウント用グループ
- アクセス制御で、多要素認証（MFA）などを追加する。
その他、ネームド・ロケーション、セキュア・ワークステーション等がある。
- レポート専用で作成して、問題なく動作しているか確認してからオンする。
- 対象
- 対象：個人アカウント用グループ
- 対象外：緊急事態用アカウント用グループ
- ユーザ・リスク、サインイン・リスク、MFA登録ポリシーなどを追加する。
Step 3. Azure サブスクリプションの準備 †
Step 1のテナントで、サブスクリプションを作成する。
- 作成に使用するアカウントは、
EAアカウント管理者の個人アカウント（ea_aa@o365aad）
サブスクリプションの環境管理を付け替える。 †
- EA契約アカウント管理者（ea_aa@o365aad）は、招待を承認する。
- 招待を承認する。
- ディレクトリの切替が可能になる。
- サービス管理者：環境管理を、
- EA契約アカウント管理者（ea_aa@o365aad）から
- Azure用の緊急事態用アカウント（bg_admin_azure@prodaad）に
変更する。...が「Microsoft Azure Pass」だと出来ないとのこと。
Azure権限付与（ルート管理グループ） †
- 初期構築アカウントでログインし、
「Azureリソースのアクセス管理」が「はい」に
なっていることを確認し、以下の作業を行う。
- 自身がユーザ・アクセス管理者（User Access Administrator）権限を
持っているので、自身に更に所有者（Owner）権限を追加する。
- 管理グループ（Tenant Root Group）のアクセス制御（IAM）画面から、
Azure AD 用の緊急事態用アカウント（bg_admin_aad@prodaad）に以下の権限を割当てる。
- 所有者（Owner）
- ユーザ・アクセス管理者（User Access Administrator）
Step 4. ログ・監視・アラートの設定 †
長期ログ保存のための設定 †
サブスクリプションに対し各種のログを長期保存
するため、ストレージの作成と診断ログの設定を行う。
- 初期作業ユーザに対して、当該 Azure サブスクリプションに対する Owner 権限を付与
- Log Analyticsワーク・スペース
イベント・ログの収集と表示
- ストレージ・アカウント
- より長期のログ保管のストレージ
- プライベート・エンドポイントを指定（パブリック・エンドポイントを塞ぐ）
- 診断設定を有効化する。
- Azure AD > サインイン > データ設定のエクスポート > 診断設定
- サブスクリプション > アクティビティ・ログ > 診断設定
緊急事態用アカウント利用時に警告メールを送付する。 †
- 緊急事態用アカウントの２つのオブジェクトIDを調査する（xxxx, yyyy）。
- Log Analytics ワークスペースに2 種類のアラートルールを追加
- アラート・ロジック：「結果の数が 0 より大きい場合」（既定値）
- セキュリティ・チームのML宛にメール送信するアクション・グループを作成・設定
- アラート・ルールの詳細でタイトル、本文、重大度 0 など設定。
- アラートロジック：「結果の数が 0 より大きい場合」（既定値）
- アラート・ルールの詳細でタイトル、本文、重大度 1 など設定。
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変更が求められるので、封緘パスワードに変更。
緊急事態アカウントの動作確認 †
ログイン、権限確認、監査ログの参照などを行う。
緊急事態アカウントのパスワードの封緘 †
アカウント情報を封緘
（リアルに封筒などに入れる）
初期構築アカウントで確認する。
参考 †
Microsoft Docs †
nakama †
※ Azure 管理用 Azure AD テナントの作成方法中にも同様のトピックが含まれる。
Tags: :インフラストラクチャ, :クラウド, :Azure, :Active Directory, :認証基盤, :クレームベース認証
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
