3. Microsoft Entra ID(Azure Active Directory)とガバナンス
3.1. ゼロトラストモデル
ゼロトラストモデルは境界防衛と異なるアプローチで境界に依存しないセキュリティの考え方の1つ。 AzureやEntra IDのセキュリティ機能の多くはこのゼロトラストモデルの考え方に基づいている。
3.1.1. ゼロトラストモデルの要素
- 明示的な確認 : アクセス元の端末やIDを無条件に信頼せず検証をしっかり行う
- 必要最低限のアクセス権の付与 : 必要最低限の権限を必要な時間のみ付与する(Just in time)
- 侵害の想定 : 攻撃者にシステムが侵入されることを想定し、データの暗号化/アクセス範囲の細分化を行う
3.2. Microsoft Entra ID
Microsoft Entra ID(Azure Active Directory)はユーザのAzureサービス/リソースへのアクセスを安全に管理できる、クラウドベースのID管理機能のこと。
3.1. Microsoft Entra IDの特徴
- ユーザ管理機能
- IDとしてユーザアカウントの作成/編集/削除などの管理が行える
- ユーザIDはアカウントと呼ばれる
- IDの認証とシングルサインオン
- ユーザアカウントの認証を行う
- シングルサインオン(SSO)への対応
- グループの管理
- アクセス権管理のためのセキュリティグループの作成/グループメンバーシップの管理機能
- ルールに応じてメンバーシップの変更が行われる動的グループ機能も搭載
- Azureリソースに対する管理アクセス制御
- ロールベースのアクセス制御(RBAC)
- デバイスの登録
- Microsoft Entra IDにデバイスの登録をさせ、組織管理下における
- 脅威に対するID保護
- セキュリティの強化のための多要素認証機能(MFA)の提供
- Microsoft Entraアクティビティログの取得/監査
- サインインや各種アクティビティログの参照ができる(なお30日間の保存)
- クラウドアプリの管理
- 組織のアプリやSaaSアプリをMicrosoft Entra IDで認証管理できる
- セルフサービス
- ユーザ自身でパスワードをリセット/グループ管理を行う機能の提供
3.2. Microsoft Entra IDのテナント
Microsoft Entra IDはSaaSサービスであり、各組織間ではMicrosoft Entra IDの環境が隔離/分離されている。 この状態はMicrosoft Entra テナントと呼ばれる。
3.3. Entra IDとWindows Active Directoryとの違い。
項目 | Entra ID | Active Directory |
---|---|---|
ディレクトリサービスの提供 | 提供される | 提供される |
認証プロトコル | SAML, OAuth,OpenID | Keroberos, LDAP |
ネットワーク | インターネット | LAN |
対象 | クラウド | ローカル |
デバイス登録 | Entra追加/登録 | ADドメインへの参加 |
デバイス構成管理 | MS Intuneの利用 | グループポリシ |
Entra IDの特徴は以下の通り。
- Entra IDはHTTP/HTTPS向けの設定
- REST APIでクエリ設計されている
- SAMLやOpenIDなどの認証プロトコル
- 組織単位(OU)やGPOなどはなく、ユーザ/グループはフラットで構成されている
3.4. Entra IDのエディション
Microsoft Entra IDには3種類のエディションが存在する。
- Freeエディション
- 無料で提供されるエディション
- 最低限のID管理機能/認証機能、セキュリティ機能が提供される
- SLAが保証されない
- P1 (Plan1)エディション
- 作業効率化/柔軟なアクセス制御が提供
- グループベースのアプリ割り当て、セルフグループ管理、条件付きアクセスポリシーが利用可能
- P2 (Plan2)エディション
- P1の機能に強力なID保護の機能が追加
- リスクべースアクセス制御/特権保護などが利用可能
機能 | Free | P1 | P2 |
---|---|---|---|
IDの管理と認証 | 〇 | 〇 | 〇 |
企業間コラボレーション | 〇 | 〇 | 〇 |
セルフサービスパスワードリセット | 〇 | 〇 | |
動的グループ | 〇 | 〇 | |
多要素認証 | 〇 | 〇 | 〇 |
条件付きアクセス | 〇 | 〇 | |
検知IDリスク自動修復 | 〇 | ||
特権保護 | 〇 | ||
IDガバナンス機能 | 〇 |
3.5. Microsoft Entra Connect
Microsoft Entra ConnectはWindows Active DirectoryからMicrosoft Entra IDへのアカウントを同期、一元管理するための機能。 この機能を構成してWindows Active DirectoryとMicrosoft Entra ID両方でユーザアカウントを使用できる(ハイブリッドID)
なおこのツールのほかに、Microsoft Entraクラウド同期(Cloud Sync)を利用して同期も行える。 ただし利用できる機能は限られる。
3.6. ユーザアカウントの種類
Entra IDのアカウントは以下3種類がある。
- クラウドID (Entra ID)
- 同期ID (WIndows AD)
- 外部ユーザ (外部のIDソース)
クラウドID
クラウドIDはMicrosoft Entra IDで作成されたユーザアカウント。 通常のユーザアカウントのほかに管理権限を持った管理アカウントも存在できる。
ユーザアカウントはAzure portal上で作成でき、CSVのアップロードによるスクリプトによる作成も可能。
同期ID
同期IDはMicrosoft Entra ConnectによりWindows Active Directoryから同期されたユーザアカウント。 一部の属性はMicrosoft Entra ID上で変更できず、WIndows AD上で編集する必要がある。
外部ユーザ(ゲストユーザ)
外部ユーザはEntra IDのテナントに招待された外部組織のユーザ。 Microsoft Entra IDに招待されたユーザは正体を了承するとテナントへのアクセス権を得る。
この他のテナントへユーザを紹介する機能はMicrosoft Entra External ID(外部ID)/Microsoft Entra B2Bコラボレーションと呼ばれる。
3.7. ユーザアカウントの作成/管理
Azure Portal上での作成
- 「Microsoft Entra ID」-「ユーザ」-「+新しいユーザ」-「新しいユーザの作成」
- 「新しいユーザの作成」メニュで必要情報を入力する
- 必要に応じて「割り当て」よりグループや管理者ロールを割り当てる
ユーザの一括作成
- 「Microsoft Entra ID」-「ユーザ」より「一括作成/操作」を選択
- ID一括登録用のcsvテンプレートをダウンロードする
- 追加したいユーザの情報をcsvに入力後アップロードする
PowerShellによるユーザ作成
PowerShellの場合、New-MgUser
コマンドで作成できる。
なお、外部ユーザを招待する場合はNew-MgInvitation
コマンドを利用する。
3.8. ライセンス管理
Microsoft Entra IDやMicrosof 365を利用するためにはユーザ単位でライセンスを割り当てる必要がある。 ライセンスはMicrosoftやCSPを経由して購入/入手可能。
ユーザへのライセンス割り当て
Azure Portalを利用して割り当てる場合以下のように可能。
- 「Microsoft Entra ID」-「ユーザ」-「すべてのユーザ」からライセンスを割り当てるユーザを選択
- ユーザの「プロパティ」から「設定」「利用場所」が適切に設定されていることを確認
- 「管理」-「ライセンス」-「+割り当て」から割り当てて、「保存」をクリック
その他のライセンスの割り当て
その他にグループベースのライセンス割り当ても可能だが、この場合はP1以上のEntra IDライセンスが必要となる。
3.9. 多要素認証
Microsoft Entra IDでは多要素認証がサポートされている(MFA)。 これはパスワードが流出しても不正アクセスのリスクを大きく減らすことができるものといえる。
3.10. セルフサービスリセット(SSPR)
セルフサービスリセットはユーザ自身がパスワードを忘れた際にIT管理者に直接連絡しなくてもユーザ自身でパスワードをリセットできる機能。
3.10. Microsoft Entraロール
Microsoft EntraロールはEntra IDユーザ/グループなどMicrosoft Entra IDリソースを管理するためのアクセス権セットのこと。 ロールは全部で11種類ある。
- 全体管理者
- グローバル閲覧者
- アプリケーション管理者
- アプリケーション開発者
- 特権ロール管理者
- ユーザ管理者
- ヘルプデスク管理者
- 課金管理者
- セキュリティ管理者
- セキュリティ閲覧者
3.11. 管理単位
Microsoft Entra IDにはWindows ADにあるような階層化と権限委任のための組織単位(OU)は存在しないため、ユーザはフラットに管理される。 ただし、管理単位(AU)を構成してユーザの管理スコープを設けることで、ユーザ管理を他の管理者に委任できる。
3.12. Microsoft Entra Priviledged Identify Management
Microsoft Entra PIM はMicrosoft Entra IDの特権ロールを持つアカウントおよび、Azureリソース管理権限を持つユーザを管理監視するための機能。 セキュリティの最重要機能である特権管理をMicrosoft Entra IDがもつビルドイン機能で強化できる。
Microsoft Entra PIMの特徴
- 通常はユーザに特権を付与せず、必要なときのみ付与する
- 特権付与方法は自己でのアクティブ化、管理者による認証フローから選択できる
- Just In Timeアクセス
- 特権のアクティブ化や認証依頼時は「アクティブ化の理由」「チケット番号」の記載を要求できる
- 特権のアクティブ化や認証依頼時は多要素認証を要求する
- アクセス権はアクティブ化時に許可された期間を過ぎると自動失効させられる
- アクセスレビュー機能
- 監査レポートを取得できる
アクセスレビュー
アクセスレビューはMicrosoft Entra ID P2ライセンスで使用できるガバナンス機能。 特権ロール/グループメンバーシップなどアクセス権に関わるユーザに対し、定期的にアクセス権の要不要をレビューできる。
3.13. パスワードライトバック
パスワードライトバック機能はハイブリッドID構成時に追加設定を行うことでMicrosoft Entra ID上で変更もしくはリセットをWindows ADの方に反映させれる機能のこと。
3.14. Microsoft Entra IDへのデバイスの登録
Microsoft Entra IDにデバイスを参加させるメリットは以下の通り。
- Microsoft Entra IDと認証連携するアプリに対しSSOが利用できるようになる
- Microsoft Intuneと組み合わせると条件付きアクセスポリシーを利用し、コンプライアンス準拠端末のみリソースアクセスできるように構成できる
- 端末の簡単なインベントリ機能を取得できる
Microsoft Entra IDへのデバイス登録
- Microsoft Entra 登録
- 個人所有(BYOD)の端末
- 端末のローカルアカウント
- Microsoft Entra 参加
- 組織所有の端末
- Microsoft Entra IDアカウント
- Microsoft Entra ハイブリッド参加
- 組織所有の端末
- WIndows ADアカウント
Microsoft Entra IDの参加構成
Microsoft Entra 参加するユーザを制御できる。 これにより意図せずMicrosoft Entra IDに参加してしまうことを防止できる。
またMicrosoft Entra 参加デバイスに対し、ローカルPC管理者を設定するには以下手順で行う。
- 「Microsoft Entra ID」-「デバイス」から「ローカル管理者設定」を選択
- 「管理Microsoft Entra に参加済みのデバイスの追加のローカル管理者」を選択
- 「device Addministrator | 割り当て 」にローカル管理者アカウントとして追加したいMicrosoft Entra IDユーザアカウントを選択する
Microsoft Entra 参加/登録の違い
登録は個人所有デバイス用、参加は組織所有デバイス用
3.15. 条件付きアクセスポリシー
Microsoft Entra IDの条件付きアクセスポリシーを利用するとクラウドアプリやAzure Portalへのアクセス可否や追加条件を柔軟に制御できる。 Azure Portalの「Microsoft Entra ID」-「セキュリティ」-「条件付きアクセス」からアクセスできる。
条件付きアクセスポリシの主要要件
条件は以下の項目を組み合わせて指定する。
- ユーザ/グループ
- ターゲットリソース
- 条件 - デバイスプラットフォーム
- 条件 - ユーザのリスク/サインインリスク (P2ライセンス以上)
- 条件 - 場所
- 条件 - クライアントアプリケーション
条件付きアクセスポリシの主要制御
制御は以下の要件を複数組み合わせて設定する。
- アクセスのブロック
- 多要素認証の要求
- 認証強度が必要
- Microsoft Entra ハイブリッド参加済みデバイスが必要
- デバイスは準拠しているマーク済みの必要がある
- パスワードの変更を必須とする
- セッションコントロール
Microsoft Entra Identify Protection
Microsoft Entra Identify Protection(Microsoft Entra IDP)はユーザリスク及びサインインリスクの検出と修復する機能を提供するサービス。 Microsoft Entra IDPでは条件付きアクセスでのユーザリスク、サインインリスクや、IPダッシュボードを使用してテナント全体のリスク検出状況を確認できる。
3.16. グループの作成と管理
Microsoft Entra IDでは2種類のグループを作成できる。
- セキュリティグループ
- アプリケーションの割り当てやアクセス権を付与管理するためのグループ
- ユーザ、デバイス、サービスプリンシパル、他グループをメンバーツイできる
- Microsoft 365グループ
- Microsoft 365コラボレーション機能のために使用するグループ
- メールアドレスを付与する必要があり、またユーザのみをメンバー追加できる
グループメンバーシップの管理
各グループでは静的に割り当てる方法と動的に割り当てる方法のどちらかが選択できるが、動的に割り当てるにはP1もしくはP2ライセンスが必要となる。
- 割り当て済み(静的グループ)
- Microsoft Entra ID管理者/グループ所有者がメンバーの出し入れを行う
- 動的ユーザグループ
- メンバーシップの管理のためのグループメンバーシップを作成することで、ルールに合致したユーザを自動的にグループメンバーシップに追加/削除できる
- 動的デバイスグループ
- デバイスを対象にした動的グループ
動的グループの作成
- Azure Portalで「Microsoft Entra ID」-「グループ」を選択
- 「すべてのグループ」-「新しいグループ」を選択
- グループ名を入力し、「グループの種類」をセキュリティにし、動的メンバとする
- 「動的クエリの追加」を選択、メンバへクエリを追加する
3.17. アプリケーションとの認証連携
Microsoft Entra IDはSaaSやクラウドアプリにMicrosoft Entra IDユーザによる認証認可を提供する。 以下プロトコルが利用できる。
- SAML 2.0
- OpenID Connect/OAuth 2.0
3.18. Microsoft Entra Domain Services
Microsoft Entra Domain Services(Microsoft Entra DS)はAzure上でWindows ADの機能を提供できるサービス。 特徴は以下の通り。
- オンプレミスネットワークとの接続が不要
- NTLM/Keroberos認証の提供
- LDAPの提供
- 高可用性
Microsoft Entra DSとWindows ADの違い
Microsoft Entra DSではWindows ADと異なり以下の機能は提供しない。
- ADスキーマの拡張
- 入力方向の信頼関係
- ドメイン管理者の特権利用
- 一部のグループポリシー機能
- アカウントベースのKeroberos制限付き委任
3.19. サービスプリンシパルとマネージドID
Microsoft Entra IDではアプリ向けのIDが2種類定義されている。
- サービスプリンシパル
- マネージドID
サービスプリンシパル
サービスプリンシパル(アプリケーションID)はアプリやサービスが使用する目的で作成するID。 以下の特徴がある。
- 認証にはシークレットもしくは証明書を使用
- シークレットや証明書をKey Vaultに格納することで、利用者がそれを把握せずアプリケーションIDを利用させれる
マネージドID
マネージドIDはAzureリソースで利用可能なアプリケーションIDのこと。 マネージドIDには以下の2種類がある。
- システム割り当て
- リソースに自動割り当てされる
- ユーザ割り当て
- 手動で割り当てる
特徴は以下の通り。
- アプリケーションIDのようにシークレットや証明書を管理する必要がない
- Azureリソースでのみ利用できる
- RBACを利用してマネージドIDへのアクセス権を付与できる
3.20. カスタムドメイン
Microsoft Entra テナントを作成するとドメイン名.onmicrosoft.comの一位のテナント名が作られる。 カスタムドメインを追加することで、組織のDNSドメインをユーザIDにユーザプリンシパル名(UPN)として設定できる。
カスタムドメインの追加
Microsoft Entra テナントにカスタムドメインを追加するには、追加するドメインを組織が保有していることを証明する必要がある。
- 「Microsoft Entra ID」-「カスタムドメイン」へアクセス
- 「+カスタムドメインの追加」をクリックしカスタムドメイン名を入力
- DNSレコードの登録を行う(TXT,MXレコードで可能)
3.21. セキュリティ既定値群
セキュリティ既定値群を利用するとMicrosoft Entra IDのP1,P2ライセンスを持たない組織でも、必要なID保護機能が自動的に有効化されID侵害による不正リスクを軽減できる。
通常は開発環境のセキュリティ向上に用いる。
3.3. サブスクリプションの構成
3.3.1. サブスクリプション
サブスクリプションはAzureリソースの管理/および課金単位となる論理ユニットのこと。 Azureリソースは必ず、いずれかのAzureサブスクリプション内に作成される。 また各リソースの課金は各サブスクリプションに請求される。
3.3.2. サブスクリプションの取得
取得方法 | 取得先 |
---|---|
無料試用版サブスクリプション | AzureのWebサイトから個人で申し込む。金額と期間に制限がある |
Microsoft顧客契約サブスクリプション(MCA) | マイクロソフトのWebサイトから申し込む |
エンタープライズ契約(EA) | 企業/組織向けの方法。年単位で契約を行う |
マイクロソフトパートナー経由 (CSP) | 企業/組織向けの方法 |
3.3.3. サブスクリプションの管理権限
サブスクリプションの管理のためのロールは以下の通り。
- エンタープライズ管理者
- EA契約のみでい利用可能
- EAポータルという独立したポータルで管理できる
- アカウント所有者
- EAポータルで使用するロール
- Azureサブスクリプションの作成と管理を行える
- 所有者(Owner)
- Azure Portal上のロール
- サブスクリプション配下のすべてのAzureリソースへのアクセス権を持つ
- 共同作成者(Contributer)
- サブスクリプションの所有者によって追加された追加管理者
- 所有者と基本的に同等の権限を持つ
- Microsoft Entra 全体管理者
- Microsoft Entra IDのロール
- テナント内のAzureサブスクリプションのアクセス権を持たない
3.3.4. サブスクリプションの管理単位
サブスクリプションは環境ごとに作成できる。
3.3.5. Microsoft Entra IDのサブスクリプションの関係
初期でAzure環境を作成する場合、Azureサブスクリプションの関連づいたMicrosoft Entraテナントが作成される。 しかしAzureサブスクリプションとEntra IDは独立して管理される。
- Azureサブスクリプションは必ず1つのMicrosoft Entraテナントに関連付ける必要がある
- 1つのAzureサブスクリプションを複数のMicroosft Entraテナントに関連付けることはできない
- Mircosoft ENtraテナントは複数のサブスクリプションを管理できる
- Azureサブスクリプションの関連付け先ディレクトリを別のテナントに変更できる
- Azureサブスクリプションの関連付け先ディレクトリが変更されると、以前に管理されていたディレクトリのロールベースのアクセス権を失う
3.3.6. 管理グループ
管理グループは複数のサブスクリプションを管理するためのもの。
管理グループの特徴は以下の通り。
- サブスクリプションをまとめてグループ化できる
- Entraテナント直下にはルート管理グループが規定で存在する
- ルート管理グループには規定で特定ロールにアクセス権が付与されている
- 組織の階層に沿った管理単位を作成可能
- 管理グループにAzureポリシーやRBACのアクセス制御を付与できる
3.4. ロールベースのアクセス制御(RBAC)
Azureのロールベースのアクセス制御(RBAC)を用いることでユーザがAzureリソースに対しどのような操作を実行できるかを制御できる。 Azure RBACでは「だれが(セキュリティプリンシパル)」「どの権限を(ロール)」「何に対して(スコープ)」の要素を組み合わせてアクセス制御できる。
利点は以下の通り。
- セキュリティの向上
- きめ細かいアクセス制御
- 管理権限の効率化(継承)
3.4.1. Azure RBACの構成要素
ロール定義
ロール定義はAzureリソースに対して実行できる操作(読み取り、書き込み、削除)を定義できるもの。 ビルドインで用意されている読み込みロールのほかに、必要なアクセス許可を独自構築したカスタムロールを作成できる。
以下にAzure標準の組み込みロールを記載する。
- 所有者(OWner)
- アクセス権を含めて全管理
- 閲覧者(Reader)
- 読み取り権限のみ
- 共同作成者(Contributer)
- アクセス権以外の全管理
- ユーザアクセスの管理者
- Azureリソースに対するユーザアクセスの管理
- 仮想マシンの共同作業者
- 仮想マシンを管理できる
- 仮想ネットワークやストレージアカウントなどは管理できない
- 従来の仮想マシンの共同作業者
- クラシック仮想マシンを管理できる
- 仮想ネットワークやストレージアカウントなどは管理できない
- ストレージアカウントの共同作業者
- ストレージアカウントを管理できる
- 従来のストレージアカウントの共同作業者
- 従来のストレージアカウントを管理できる
- ネットワークの共同作業者
- すべてのネットワークリソースを管理できる
- 従来のネットワークの共同作業者
- 従来のすべてのネットワークリソースを管理できる
- 課金リーダ
- 全ての課金情報を見ることができる
スコープ
スコープはアクセス権を適用するAzureリソースのセットのこと。 上位レベルに割り当てられたロールは下位のリソースに自動継承される。
セキュリティプリンシパル
セキュリティプリンシパルはアクセス割り当て可能なオブジェクトのこと。 セキュリティプリンシパルは以下が含まれる。
- ユーザ
- グループ
- サービスプリンシパル
- マネージドID
3.4.2. Azure RBACの設定方法
RBACによるロール割り当てはAzure Portal, Azure PowerShell, Azure CLI, REST APIなどを利用できる。 RBACによるアクセス権を割りあてる場合以下点を考慮すべき。
- どのセキュリティプリンシパルにアクセス権を付与するか
- 何のアクセス権(ロール)を付与するか
- どのスコープにアクセス権を割り当てるか
Azure Portalを利用して割り当てる
- 割当先スコープのリソースにアクセスする
- 「アクセス制御(IAM)」を開く
- 「+追加」から「ロールベースの割り当ての追加」を選択
- 割り当てるロールを検索し割り当てる
- アクセス権を付与するセキュリティプリンシパルを選択
- 保存する
3.4.3. カスタムロール
カスタムロールはアクセス許可を独自定義したロールのこと。 Azure PortalやAzure POwerShellやAzure CLIでJSON形式で定義できる。
カスタムロールの数は1テナントあたり最大5000個までと決まっている。
JSONによるカスタムロールの構成
JSONで指定可能な主要なキーと値は以下の通り。
NAME
- カスタムロールの表示名を指定
IsCustom
- カスタムロールであるかをBool値で指定
Description
- カスタムロールの説明文を記載
Actions
- アクションを指定
NoActions
- 許可されないアクションを指定
DataActions
- データ操作/変更に関する権限の指定
AssignableScopes
- ロールを割り当て可能なスコープを指定
アクションは以下の通り。
- *
- 全てのアクションを有効
- read
- 読み取りアクションを有効
- write
- 書き込みアクションを有効
- action
- 仮想マシンの起動や停止などのアクションの有効化
- delete
- 削除アクションの有効化
3.4.4. タグ
タグはAzureリソースに関連付けられるラベルのこと。 リソース管理のためのメタデータとして振舞う。
タグをうまく利用すると、サブスクリプション上で散らばったリソースを効率的にカテゴライズし整理できる。
タグの構成
ラグはキーと値で構成される。
例は以下の通り。
- Environment (キー)
- Production (値)
- Development (値)
- Pre-Prduction (値)
タグの付与方法
タグはリソース作成時のオプション設定やリソース作成後に付与できる。 またAzureポリシーやAzure BluePrintsを用いてリソースにタグの付与を強制できる。
3.4.5. リソースのロック
リソース(サブスクリプション、リソースグループ、リソース)をロックすると、リソースの誤った削除/変更を防ぐことができる。
ロックの種類
- CanNotDelete: リソースの削除をブロック
- ReadOnly: リソースの変更をブロック
Azureポータルによるロックの設定方法
VMの削除をブロックする例
- 対象のVMを開く
- 「設定」-「ロック」
- 「+追加」-「ロックの追加」
- ロック名、ロックの種類を設定
- 「OK」をクリック
3.5. Azureポリシー
AzureポリシーはAzureのガバナンス機能の1つで組織が強制させたいセキュリティポリシーや運用ルールをリソースに適用できるもの。 Azureポリシーは管理グループ、サブスクリプション、リソースグループ、各リソースに適用できる。
例えば、以下のようなことが指定できる。
- Aサブスクリプション以下ではB,DシリーズのみのVMを作成できる
- 東日本リージョンのみにリソースの作成を許可する
3.5.1. ポリシー定義
Azureでビルドインのポリシー定義がいくつも用意されているのでカスタムして使用でる。
3.5.2. イニシアチブ
イニシアチブは複数の関連するポリシー定義をまとめてグループ化したもののこと。 ポリシー定義のグループと考えることができる。
3.5.3. Azureポリシーの設定
Azureポリシーの設定は以下順序で行う。
- ポリシー定義を作成する
- ポリシー定義またはイニシアチブ定義を割り当てる
- 適用結果を評価する
3.5.4. Azure Blueprints
Azure Blueprintsでは以下の構成をまとめた繰り返し利用可能なテンプレートを作成できる。
- Azure RBACによるロール割り当て
- ARMテンプレート
- リソースグループ
- Azureポリシーの割り当て