# Az - 基本情報 {{#include ../../../banners/hacktricks-training.md}} ## 組織階層

https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

### 管理グループ - **他の管理グループやサブスクリプション**を含むことができます。 - これにより、管理グループレベルで**ガバナンスコントロール**（RBACやAzureポリシーなど）を一度適用し、グループ内のすべてのサブスクリプションに**継承**させることができます。 - **10,000の管理**グループが単一のディレクトリでサポートされます。 - 管理グループツリーは**最大6レベルの深さ**をサポートできます。この制限にはルートレベルやサブスクリプションレベルは含まれません。 - 各管理グループとサブスクリプションは**1つの親**のみをサポートできます。 - 複数の管理グループを作成できる場合でも、**ルート管理グループは1つだけ**です。 - ルート管理グループは**すべての他の管理グループとサブスクリプションを含み**、**移動または削除することはできません**。 - 単一の管理グループ内のすべてのサブスクリプションは**同じEntra IDテナントを信頼**しなければなりません。

https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

### Azureサブスクリプション - これは、リソース（VM、DBなど）を実行し、請求される**論理コンテナ**です。 - その**親**は常に**管理グループ**であり（ルート管理グループであることも可能）、サブスクリプションは他のサブスクリプションを含むことはできません。 - **1つのEntra ID**ディレクトリのみを**信頼**します。 - サブスクリプションレベル（またはその親のいずれか）で適用される**権限**は、サブスクリプション内のすべてのリソースに**継承**されます。 ### リソースグループ [ドキュメントから:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) リソースグループは、Azureソリューションのための**関連リソース**を保持する**コンテナ**です。リソースグループには、ソリューションのすべてのリソースを含めることも、管理したい**リソースのみ**を含めることもできます。一般的に、**同じライフサイクル**を共有する**リソース**を同じリソースグループに追加することで、グループとして簡単にデプロイ、更新、削除できます。 すべての**リソース**は**リソースグループ内**に存在し、グループにのみ属することができ、リソースグループが削除されると、その中のすべてのリソースも削除されます。

https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

### AzureリソースID Azureのすべてのリソースには、それを識別するAzureリソースIDがあります。 AzureリソースIDの形式は次のとおりです： - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}` サブスクリプションID `12345678-1234-1234-1234-123456789012` のリソースグループ `myResourceGroup` にある仮想マシン名myVMのAzureリソースIDは次のようになります： - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM` ## AzureとEntra IDとAzure ADドメインサービス ### Azure Azureは、Microsoftの包括的な**クラウドコンピューティングプラットフォームであり、幅広いサービスを提供**しています。これには、仮想マシン、データベース、人工知能、ストレージが含まれます。Azureは、アプリケーションのホスティングと管理、スケーラブルなインフラストラクチャの構築、クラウドでの最新のワークロードの実行の基盤として機能します。Azureは、開発者やIT専門家がアプリケーションやサービスをシームレスに作成、デプロイ、管理できるツールを提供し、スタートアップから大企業までさまざまなニーズに対応します。 ### Entra ID（旧Azure Active Directory） Entra IDは、認証、承認、ユーザーアクセス制御を処理するために設計されたクラウドベースの**アイデンティティおよびアクセス管理サービス**です。これは、Office 365、Azure、および多くのサードパーティのSaaSアプリケーションへの安全なアクセスを提供します。シングルサインオン（SSO）、多要素認証（MFA）、条件付きアクセスポリシーなどの機能を備えています。 ### Entraドメインサービス（旧Azure AD DS） Entraドメインサービスは、従来のWindows Active Directory環境と互換性のある**管理されたドメインサービス**を提供することでEntra IDの機能を拡張します。LDAP、Kerberos、NTLMなどのレガシープロトコルをサポートし、組織がオンプレミスのドメインコントローラーを展開することなく、クラウドで古いアプリケーションを移行または実行できるようにします。このサービスは、集中管理のためのグループポリシーもサポートしており、レガシーまたはADベースのワークロードが最新のクラウド環境と共存する必要があるシナリオに適しています。 ## Entra IDプリンシパル ### ユーザー - **新しいユーザー** - 選択したテナントからのメール名とドメインを指定 - 表示名を指定 - パスワードを指定 - プロパティを指定（名、職名、連絡先情報など） - デフォルトのユーザータイプは「**メンバー**」 - **外部ユーザー** - 招待するメールと表示名を指定（Microsoft以外のメールも可） - プロパティを指定 - デフォルトのユーザータイプは「**ゲスト**」 ### メンバーとゲストのデフォルト権限 [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) で確認できますが、メンバーは以下のアクションを実行できます： - すべてのユーザー、グループ、アプリケーション、デバイス、ロール、サブスクリプション、およびその公開プロパティを読み取る - ゲストを招待する（_オフにすることが可能_） - セキュリティグループを作成する - 非表示のグループメンバーシップを読み取る - 所有グループにゲストを追加する - 新しいアプリケーションを作成する（_オフにすることが可能_） - Azureに最大50台のデバイスを追加する（_オフにすることが可能_） > [!NOTE] > Azureリソースを列挙するには、ユーザーに明示的な権限の付与が必要です。 ### ユーザーのデフォルト設定可能権限 - **メンバー（**[**ドキュメント**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**）** - アプリケーションの登録：デフォルトは**はい** - 非管理者ユーザーによるテナントの作成を制限：デフォルトは**いいえ** - セキュリティグループの作成：デフォルトは**はい** - Microsoft Entra管理ポータルへのアクセスを制限：デフォルトは**いいえ** - これはポータルへのAPIアクセスを制限しません（ウェブのみ） - ユーザーがLinkedInと仕事または学校のアカウントを接続できるようにする：デフォルトは**はい** - ユーザーをサインインしたままにする：デフォルトは**はい** - ユーザーが所有するデバイスのBitLockerキーを回復することを制限：デフォルトは**いいえ**（デバイス設定で確認） - 他のユーザーを読み取る：デフォルトは**はい**（Microsoft Graph経由） - **ゲスト** - **ゲストユーザーアクセス制限**オプション： - **ゲストユーザーはメンバーと同じアクセス権を持ちます**。 - **ゲストユーザーはディレクトリオブジェクトのプロパティとメンバーシップへのアクセスが制限されています（デフォルト）**。これにより、デフォルトでゲストは自分のユーザープロファイルのみへのアクセスが許可されます。他のユーザーやグループ情報へのアクセスは許可されません。 - **ゲストユーザーアクセスは自分のディレクトリオブジェクトのプロパティとメンバーシップに制限されています**が最も制限的です。 - **ゲストを招待できる**オプション： - **組織内の誰でもゲストユーザーを招待できます（最も包括的） - デフォルト** - **メンバーユーザーおよび特定の管理ロールに割り当てられたユーザーは、メンバー権限を持つゲストを含むゲストユーザーを招待できます** - **特定の管理ロールに割り当てられたユーザーのみがゲストユーザーを招待できます** - **組織内の誰もゲストユーザーを招待できません（最も制限的）** - **外部ユーザーの退会**：デフォルトは**真** - 外部ユーザーが組織を離れることを許可 > [!TIP] > デフォルトで制限されていても、権限が付与されたユーザー（メンバーおよびゲスト）は前述のアクションを実行できます。 ### **グループ** **2種類のグループ**があります： - **セキュリティ**：このタイプのグループは、メンバーにアプリケーション、リソースへのアクセスを提供し、ライセンスを割り当てるために使用されます。ユーザー、デバイス、サービスプリンシパル、他のグループがメンバーになれます。 - **Microsoft 365**：このタイプのグループは、コラボレーションのために使用され、メンバーに共有メールボックス、カレンダー、ファイル、SharePointサイトなどへのアクセスを提供します。グループメンバーはユーザーのみです。 - これは、EntraIDテナントのドメインを持つ**メールアドレス**を持ちます。 **2種類のメンバーシップ**があります： - **割り当てられた**：特定のメンバーを手動でグループに追加することを許可します。 - **動的メンバーシップ**：ルールを使用してメンバーシップを自動的に管理し、メンバーの属性が変更されるとグループの含有を更新します。 ### **サービスプリンシパル** **サービスプリンシパル**は、**アプリケーション**、ホスティングサービス、および自動化ツールがAzureリソースにアクセスするために**使用**される**アイデンティティ**です。このアクセスは、サービスプリンシパルに割り当てられたロールによって**制限され**、**どのリソースにアクセスできるか**を制御します。セキュリティ上の理由から、**ユーザーアイデンティティでログインさせるのではなく、自動化ツールとともにサービスプリンシパルを使用することを常に推奨します**。 サービスプリンシパルとして**直接ログインする**ことも可能で、**シークレット**（パスワード）、**証明書**、または第三者プラットフォーム（例：Github Actions）への**フェデレーテッド**アクセスを付与することができます。 - **パスワード**認証を選択した場合（デフォルト）、**生成されたパスワードを保存**してください。再度アクセスすることはできません。 - 証明書認証を選択した場合、**アプリケーションがプライベートキーにアクセスできることを確認**してください。 ### アプリ登録 **アプリ登録**は、アプリケーションがEntra IDと統合し、アクションを実行するための構成です。 #### 主要コンポーネント： 1. **アプリケーションID（クライアントID）：** Azure AD内のアプリの一意の識別子。 2. **リダイレクトURI：** Azure ADが認証応答を送信するURL。 3. **証明書、シークレット、フェデレーテッド資格情報：** アプリケーションのサービスプリンシパルとしてログインするためにシークレットまたは証明書を生成することが可能で、またそれにフェデレーテッドアクセスを付与することもできます（例：Github Actions）。 1. **証明書**または**シークレット**が生成された場合、**アプリケーションID**、**シークレット**または**証明書**、および**テナント**（ドメインまたはID）を知っていることで、CLIツールを使用して**サービスプリンシパルとしてログイン**できます。 4. **API権限：** アプリがアクセスできるリソースまたはAPIを指定します。 5. **認証設定：** アプリがサポートする認証フローを定義します（例：OAuth2、OpenID Connect）。 6. **サービスプリンシパル**：アプリが作成されると（ウェブコンソールから行われた場合）、サービスプリンシパルが作成されます。 1. **サービスプリンシパル**は、構成されたすべての要求された権限を取得します。 ### デフォルト同意権限 **アプリケーションに対するユーザー同意** - **ユーザー同意を許可しない** - すべてのアプリに対して管理者が必要です。 - **確認されたパブリッシャーからのアプリ、内部アプリ、および選択された権限のみを要求するアプリに対してユーザー同意を許可する（推奨）** - すべてのユーザーは、"低影響"として分類された権限のみを要求するアプリ、確認されたパブリッシャーからのアプリ、およびテナントに登録されたアプリに同意できます。 - **デフォルト**の低影響権限（ただし、低影響として追加するには同意が必要）： - User.Read - サインインしてユーザープロファイルを読み取る - offline_access - ユーザーがアクセスを許可したデータへのアクセスを維持する - openid - ユーザーをサインインさせる - profile - ユーザーの基本プロファイルを表示する - email - ユーザーのメールアドレスを表示する - **アプリに対するユーザー同意を許可する（デフォルト）** - すべてのユーザーは、組織のデータにアクセスするために任意のアプリに同意できます。 **管理者同意要求**：デフォルトは**いいえ** - ユーザーは、同意できないアプリに対して管理者同意を要求できます。 - **はい**の場合：同意要求を行うことができるユーザー、グループ、ロールを指定できます。 - ユーザーがメール通知や期限切れリマインダーを受け取るかどうかも設定できます。 ### **管理されたアイデンティティ（メタデータ）** Azure Active Directoryの管理されたアイデンティティは、アプリケーションの**アイデンティティを自動的に管理する**ためのソリューションを提供します。これらのアイデンティティは、Azure Active Directory（**Azure AD**）認証と互換性のある**リソース**に接続するためにアプリケーションによって使用されます。これにより、アプリケーションは**メタデータ**サービスに連絡して、Azureで指定された管理されたアイデンティティとして**アクションを実行する**ための有効なトークンを取得できるため、クラウド資格情報をコードにハードコーディングする必要がなくなります。 管理されたアイデンティティには2種類あります： - **システム割り当て**。一部のAzureサービスでは、**サービスインスタンスに直接管理されたアイデンティティを有効にする**ことができます。システム割り当ての管理されたアイデンティティを有効にすると、リソースが存在するサブスクリプションで信頼されるEntra IDテナントに**サービスプリンシパル**が作成されます。**リソース**が**削除される**と、Azureは自動的に**アイデンティティ**を削除します。 - **ユーザー割り当て**。ユーザーが管理されたアイデンティティを生成することも可能です。これらは、サブスクリプション内のリソースグループ内に作成され、サブスクリプションで信頼されるEntraIDにサービスプリンシパルが作成されます。その後、管理されたアイデンティティを1つまたは**複数のインスタンス**のAzureサービスに割り当てることができます（複数のリソース）。ユーザー割り当ての管理されたアイデンティティの場合、**アイデンティティはそれを使用するリソースとは別に管理されます**。 管理されたアイデンティティは、サービスプリンシパルに付随する**永続的な資格情報**（パスワードや証明書など）を生成しません。 ### エンタープライズアプリケーション これは、サービスプリンシパルをフィルタリングし、割り当てられたアプリケーションを確認するための**Azure内のテーブル**です。 **別のタイプの「アプリケーション」ではありません。** Azureには「エンタープライズアプリケーション」というオブジェクトは存在せず、サービスプリンシパル、アプリ登録、管理されたアイデンティティを確認するための抽象化に過ぎません。 ### 管理単位 管理単位は、**組織の特定の部分に対してロールから権限を付与する**ことを可能にします。 例： - シナリオ：ある会社が地域のIT管理者に自分の地域のユーザーのみを管理させたい。 - 実装： - 各地域のために管理単位を作成します（例：「北米AU」、「ヨーロッパAU」）。 - 各地域のユーザーでAUを構成します。 - AUは**ユーザー、グループ、またはデバイスを含むことができます** - AUは**動的メンバーシップ**をサポートします。 - AUは**AUを含むことができません**。 - 管理ロールを割り当てます： - 地域のITスタッフに「ユーザー管理者」ロールを付与し、その地域のAUにスコープを設定します。 - 結果：地域のIT管理者は、他の地域に影響を与えることなく、自分の地域内のユーザーアカウントを管理できます。 ### Entra IDロールと権限 - Entra IDを管理するために、Entra IDプリンシパルに割り当てることができる**組み込みロール**があります。 - [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference) でロールを確認できます。 - EntraIDによって**`PRIVILEGED`**とマークされたロールは、Microsoftが[ドキュメントで説明しているように](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)：特権ロールの割り当ては、安全で意図された方法で使用されない場合、特権の昇格につながる可能性があるため、注意して割り当てるべきです。 - 最も特権のあるロールは**グローバル管理者**です。 - ロールグループは**詳細な権限**をまとめており、それらは説明に記載されています。 - 希望する権限を持つ**カスタムロール**を作成することが可能です。ただし、何らかの理由で、すべての詳細な権限が管理者によるカスタムロールの作成に利用できるわけではありません。 - Entra IDのロールはAzureのロールとは完全に**独立しています**。唯一の関係は、Entra IDで**グローバル管理者**のロールを持つプリンシパルが、Azureで**ユーザーアクセス管理者**のロールに昇格できることです。 - Entra IDのロールでワイルドカードを使用することは**できません**。 ## Azureロールと権限 - **ロール**は**スコープ**で**プリンシパル**に**割り当てられます**： `principal -[HAS ROLE]->(scope)` - **グループに割り当てられたロールは**、グループのすべての**メンバーに継承されます**。 - ロールが割り当てられたスコープに応じて、**ロール**はスコープコンテナ内の**他のリソース**に**継承される**可能性があります。たとえば、ユーザーAが**サブスクリプション**にロールを持っている場合、彼はその**サブスクリプション内のすべてのリソースグループ**および**リソースグループ内のすべてのリソース**にそのロールを持ちます。 ### 組み込みロール [ドキュメントから: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azureロールベースアクセス制御（Azure RBAC）](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview)には、**ユーザー、グループ、サービスプリンシパル、および管理されたアイデンティティ**に**割り当てることができる**いくつかのAzureの**組み込みロール**があります。ロールの割り当ては、**Azureリソースへのアクセスを制御する方法**です。組み込みロールが組織の特定のニーズを満たさない場合は、独自の[**Azureカスタムロール**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)を作成できます。 **組み込み**ロールは、**意図されたリソース**にのみ適用されます。たとえば、以下の2つの**組み込みロール**の例を確認してください： | [ディスクバックアップリーダー](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | バックアップボールトにディスクバックアップを実行する権限を提供します。 | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ | | [仮想マシンユーザーログイン](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | ポータルで仮想マシンを表示し、通常のユーザーとしてログインします。 | fb879df8-f326-4884-b1cf-06f3ad86be52 | これらのロールは、**論理コンテナ**（管理グループ、サブスクリプション、リソースグループなど）にも**割り当てることができ**、影響を受けるプリンシパルは**それらのコンテナ内のリソースに対してロールを持ちます**。 - ここに[**すべてのAzure組み込みロール**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)のリストがあります。 - ここに[**すべてのEntra ID組み込みロール**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference)のリストがあります。 ### カスタムロール - [**カスタムロール**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)を作成することも可能です。 - これらはスコープ内に作成されますが、ロールは複数のスコープ（管理グループ、サブスクリプション、リソースグループ）に存在できます。 - カスタムロールが持つすべての詳細な権限を構成することが可能です。 - 権限を除外することも可能です。 - 除外された権限を持つプリンシパルは、他の場所で権限が付与されていてもその権限を使用できません。 - ワイルドカードを使用することが可能です。 - 使用される形式はJSONです。 - `actions`は、リソースの作成、更新、削除などの管理操作に対する権限を指します。 - `dataActions`は、リソース内のデータ操作に対する権限であり、リソース内の実際のデータを読み取ったり、書き込んだり、削除したりすることを許可します。 - `notActions`および`notDataActions`は、ロールから特定の権限を除外するために使用されます。ただし、**それらを拒否するわけではなく**、異なるロールがそれらを付与する場合、プリンシパルはそれらを持ちます。 - `assignableScopes`は、ロールを割り当てることができるスコープの配列です（管理グループ、サブスクリプション、リソースグループなど）。 カスタムロールの権限JSONの例： ```json { "properties": { "roleName": "", "description": "", "assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"], "permissions": [ { "actions": [ "Microsoft.DigitalTwins/register/action", "Microsoft.DigitalTwins/unregister/action", "Microsoft.DigitalTwins/operations/read", "Microsoft.DigitalTwins/digitalTwinsInstances/read", "Microsoft.DigitalTwins/digitalTwinsInstances/write", "Microsoft.CostManagement/exports/*" ], "notActions": [ "Astronomer.Astro/register/action", "Astronomer.Astro/unregister/action", "Astronomer.Astro/operations/read", "Astronomer.Astro/organizations/read" ], "dataActions": [], "notDataActions": [] } ] } } ``` ### Permissions order - リソースに対して**principalがアクセスを持つためには**、明示的な役割が付与される必要があります（いかなる方法でも）**その権限を付与します**。 - 明示的な**拒否の割り当ては**、権限を付与する役割よりも優先されます。

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

### Global Administrator Global Administratorは、**Entra IDテナントに対する完全な制御を付与する**Entra IDの役割です。ただし、デフォルトではAzureリソースに対する権限は付与されません。 Global Administratorの役割を持つユーザーは、**Root Management Group内でUser Access Administrator Azure役割に「昇格」する能力を持っています**。したがって、Global Administratorsは**すべてのAzureサブスクリプションおよび管理グループでアクセスを管理できます。**\ この昇格はページの下部で行うことができます: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
### Assignments Conditions & MFA **[ドキュメント](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**によると: 現在、条件は**blobストレージデータアクションまたはキューストレージデータアクション**を持つ組み込みまたはカスタム役割の割り当てに追加できます。 ### Deny Assignments 役割の割り当てと同様に、**deny assignments**は**Azureリソースへのアクセスを制御するために使用されます**。ただし、**deny assignments**は、ユーザーが役割の割り当てを通じてアクセスを付与されている場合でも、リソースへのアクセスを**明示的に拒否するために使用されます**。**Deny assignments**は**役割の割り当てよりも優先され**、つまり、ユーザーが役割の割り当てを通じてアクセスを付与されているが、同時にdeny assignmentを通じて明示的にアクセスを拒否されている場合、deny assignmentが優先されます。 役割の割り当てと同様に、**deny assignments**は、影響を受けるprincipalと拒否される権限を示すスコープに対して適用されます。さらに、deny assignmentsの場合、子リソースによって拒否が継承されるのを**防ぐことが可能です**。 ### Azure Policies **Azure Policies**は、組織がリソースが特定の基準およびコンプライアンス要件を満たすことを保証するためのルールです。これにより、Azure内のリソースに対して**設定を強制または監査**することができます。たとえば、許可されていない地域での仮想マシンの作成を防止したり、すべてのリソースに特定のタグを付けて追跡を確実にすることができます。 Azure Policiesは**積極的**です: 非準拠のリソースが作成または変更されるのを防ぐことができます。また、**反応的**でもあり、既存の非準拠のリソースを見つけて修正することができます。 #### **Key Concepts** 1. **Policy Definition**: 許可または要求されることを指定するJSONで書かれたルール。 2. **Policy Assignment**: 特定のスコープ（例: サブスクリプション、リソースグループ）にポリシーを適用すること。 3. **Initiatives**: より広範な強制のためにグループ化されたポリシーのコレクション。 4. **Effect**: ポリシーがトリガーされたときに何が起こるかを指定します（例: "Deny," "Audit," または "Append"）。 **いくつかの例:** 1. **特定のAzure地域でのコンプライアンスの確保**: このポリシーは、すべてのリソースが特定のAzure地域にデプロイされることを保証します。たとえば、企業はGDPRコンプライアンスのためにすべてのデータがヨーロッパに保存されることを望むかもしれません。 2. **命名基準の強制**: ポリシーはAzureリソースの命名規則を強制できます。これにより、大規模な環境でリソースを整理し、名前に基づいて簡単に識別するのに役立ちます。 3. **特定のリソースタイプの制限**: このポリシーは、特定のタイプのリソースの作成を制限できます。たとえば、コストを制御するために、特定のVMサイズのような高価なリソースタイプの作成を防ぐポリシーを設定できます。 4. **タグ付けポリシーの強制**: タグは、リソース管理に使用されるAzureリソースに関連付けられたキーと値のペアです。ポリシーは、すべてのリソースに特定のタグが存在するか、特定の値を持つことを強制できます。これは、コスト追跡、所有権、またはリソースの分類に役立ちます。 5. **リソースへの公共アクセスの制限**: ポリシーは、ストレージアカウントやデータベースのような特定のリソースが公共エンドポイントを持たないことを強制し、組織のネットワーク内でのみアクセス可能であることを保証できます。 6. **セキュリティ設定の自動適用**: ポリシーは、すべてのVMに特定のネットワークセキュリティグループを適用したり、すべてのストレージアカウントが暗号化を使用することを保証するなど、リソースにセキュリティ設定を自動的に適用するために使用できます。 Azure PoliciesはAzure階層の任意のレベルに添付できますが、**一般的にはルート管理グループ**または他の管理グループで使用されます。 Azure policy json example: ```json { "policyRule": { "if": { "field": "location", "notIn": ["eastus", "westus"] }, "then": { "effect": "Deny" } }, "parameters": {}, "displayName": "Allow resources only in East US and West US", "description": "This policy ensures that resources can only be created in East US or West US.", "mode": "All" } ``` ### 権限の継承 Azure **権限は階層の任意の部分に割り当てることができます**。これには管理グループ、サブスクリプション、リソースグループ、および個々のリソースが含まれます。権限は、割り当てられたエンティティの**リソース**によって**継承**されます。 この階層構造は、アクセス権限の効率的かつスケーラブルな管理を可能にします。
### Azure RBAC と ABAC **RBAC**（ロールベースのアクセス制御）は、前のセクションで見たものです：**リソースへのアクセスを付与するために、プリンシパルにロールを割り当てる**ことです。\ しかし、場合によっては、**より細かいアクセス管理**を提供したり、**数百の**ロール**割り当て**の管理を**簡素化**したいことがあります。 Azure **ABAC**（属性ベースのアクセス制御）は、特定のアクションの文脈における**属性に基づくロール割り当て条件**を追加することでAzure RBACを拡張します。_ロール割り当て条件_は、**より細かいアクセス制御を提供するためにオプションでロール割り当てに追加できる追加のチェック**です。条件は、ロール定義およびロール割り当ての一部として付与される権限を絞り込みます。たとえば、**オブジェクトを読み取るために特定のタグを持つ必要がある条件を追加できます**。\ 特定のリソースへの**アクセスを明示的に** **拒否**することは**条件を使用して**はできません。 ## 参考文献 - [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview) - [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions) - [https://abouttmc.com/glossary/azure-subscription/#:\~:text=An%20Azure%20subscription%20is%20a,the%20subscription%20it%20belongs%20to.](https://abouttmc.com/glossary/azure-subscription/) - [https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource) - [https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration](https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration) {{#include ../../../banners/hacktricks-training.md}}