gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-10 14:12:45 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

Browse Source
This commit is contained in:
Translator
2024-12-31 20:45:32 +00:00
parent ea3a11546a
commit 3c2f3f44a7
245 changed files with 9950 additions and 12671 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-basic-information/README.md
+238 -246
View File
@@ -1,376 +1,372 @@
# Az - Basic Information
# Az - 基本情報
{{#include ../../../banners/hacktricks-training.md}}
## Organization Hierarchy
## 組織階層
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUcVrh1BpuQXN7RzGqoxrn-4Nm_sjdJU-dDTvshloB7UMQnN1mtH9N94zNiPCzOYAqE9EsJqlboZOj47tQsQktjxszpKvIDPZLs9rgyiObcZCvl7N0ZWztshR0ZddyBYZIAwPIkrEQ=s2048?key=l3Eei079oPmVJuh8lxQYxxrB" alt=""><figcaption><p><a href="https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png">https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png</a></p></figcaption></figure>
### Management Groups
### 管理グループ
- It can contain **other management groups or subscriptions**.
- This allows to **apply governance controls** such as RBAC and Azure Policy once at the management group level and have them **inherited** by all the subscriptions in the group.
- **10,000 management** groups can be supported in a single directory.
- A management group tree can support **up to six levels of depth**. This limit doesn’t include the root level or the subscription level.
- Each management group and subscription can support **only one parent**.
- Even if several management groups can be created **there is only 1 root management group**.
- The root management group **contains** all the **other management groups and subscriptions** and **cannot be moved or deleted**.
- All subscriptions within a single management group must trust the **same Entra ID tenant.**
- **他の管理グループやサブスクリプション**を含むことができます。
- これにより、管理グループレベルで**ガバナンスコントロール**（RBACやAzureポリシーなど）を一度適用し、グループ内のすべてのサブスクリプションに**継承**させることができます。
- **10,000の管理**グループが単一のディレクトリでサポートされます。
- 管理グループツリーは**最大6レベルの深さ**をサポートできます。この制限にはルートレベルやサブスクリプションレベルは含まれません。
- 各管理グループとサブスクリプションは**1つの親**のみをサポートできます。
- 複数の管理グループを作成できる場合でも、**ルート管理グループは1つだけ**です。
- ルート管理グループは**すべての**他の**管理グループとサブスクリプションを含み、**移動または削除することはできません**。
- 単一の管理グループ内のすべてのサブスクリプションは、**同じEntra IDテナントを信頼**しなければなりません。
<figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>
### Azure Subscriptions
### Azureサブスクリプション
- It’s another **logical container where resources** (VMs, DBs…) can be run and will be billed.
- Its **parent** is always a **management group** (and it can be the root management group) as subscriptions cannot contain other subscriptions.
- It **trust only one Entra ID** directory
- **Permissions** applied at the subscription level (or any of its parents) are **inherited** to all the resources inside the subscription
- これは、リソース（VM、DBなど）を実行し、請求される**論理コンテナ**です。
- その**親**は常に**管理グループ**であり（ルート管理グループであることも可能）、サブスクリプションは他のサブスクリプションを含むことはできません。
- **1つのEntra ID**ディレクトリのみを**信頼**します。
- サブスクリプションレベル（またはその親のいずれか）で適用された**権限**は、サブスクリプション内のすべてのリソースに**継承**されます。
### Resource Groups
### リソースグループ
[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) A resource group is a **container** that holds **related resources** for an Azure solution. The resource group can include all the resources for the solution, or only those **resources that you want to manage as a group**. Generally, add **resources** that share the **same lifecycle** to the same resource group so you can easily deploy, update, and delete them as a group.
[ドキュメントから:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) リソースグループは、Azureソリューションのための**関連リソース**を保持する**コンテナ**です。リソースグループには、ソリューションのすべてのリソースを含めることも、**グループとして管理したいリソースのみ**を含めることもできます。一般的に、**同じライフサイクル**を共有する**リソース**を同じリソースグループに追加することで、グループとして簡単に展開、更新、削除できます。
All the **resources** must be **inside a resource group** and can belong only to a group and if a resource group is deleted, all the resources inside it are also deleted.
すべての**リソース**は**リソースグループ内**に存在し、グループにのみ属し、リソースグループが削除されると、その中のすべてのリソースも削除されます。
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1</a></p></figcaption></figure>
### Azure Resource IDs
### AzureリソースID
Every resource in Azure has an Azure Resource ID that identifies it.
Azureのすべてのリソースには、それを識別するAzureリソースIDがあります。
The format of an Azure Resource ID is as follows:
AzureリソースIDの形式は次のとおりです。
- `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`
For a virtual machine named myVM in a resource group `myResourceGroup` under subscription ID `12345678-1234-1234-1234-123456789012`, the Azure Resource ID looks like this:
サブスクリプションID `12345678-1234-1234-1234-123456789012` のリソースグループ `myResourceGroup` にある仮想マシン `myVM` のAzureリソースIDは次のようになります。
- `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
## Azure vs Entra ID vs Azure AD Domain Services
## AzureとEntra IDとAzure ADドメインサービス
### Azure
Azure is Microsoft’s comprehensive **cloud computing platform, offering a wide range of services**, including virtual machines, databases, artificial intelligence, and storage. It acts as the foundation for hosting and managing applications, building scalable infrastructures, and running modern workloads in the cloud. Azure provides tools for developers and IT professionals to create, deploy, and manage applications and services seamlessly, catering to a variety of needs from startups to large enterprises.
Azureは、Microsoftの包括的な**クラウドコンピューティングプラットフォームで、幅広いサービスを提供**しており、仮想マシン、データベース、人工知能、ストレージなどが含まれます。アプリケーションのホスティングと管理、スケーラブルなインフラストラクチャの構築、クラウドでの最新のワークロードの実行の基盤として機能します。Azureは、開発者やIT専門家がアプリケーションやサービスをシームレスに作成、展開、管理できるツールを提供し、スタートアップから大企業までさまざまなニーズに対応します。
### Entra ID (formerly Azure Active Directory)
### Entra ID（旧Azure Active Directory）
Entra ID is a cloud-based **identity and access management servic**e designed to handle authentication, authorization, and user access control. It powers secure access to Microsoft services such as Office 365, Azure, and many third-party SaaS applications. With features like single sign-on (SSO), multi-factor authentication (MFA), and conditional access policies among others.
Entra IDは、認証、承認、ユーザーアクセス制御を処理するために設計されたクラウドベースの**アイデンティティおよびアクセス管理サービス**です。Office 365、Azure、その他の多くのサードパーティのSaaSアプリケーションへの安全なアクセスを提供します。シングルサインオン（SSO）、多要素認証（MFA）、条件付きアクセスポリシーなどの機能を備えています。
### Entra Domain Services (formerly Azure AD DS)
### Entraドメインサービス（旧Azure AD DS）
Entra Domain Services extends the capabilities of Entra ID by offering **managed domain services compatible with traditional Windows Active Directory environments**. It supports legacy protocols such as LDAP, Kerberos, and NTLM, allowing organizations to migrate or run older applications in the cloud without deploying on-premises domain controllers. This service also supports Group Policy for centralized management, making it suitable for scenarios where legacy or AD-based workloads need to coexist with modern cloud environments.
Entraドメインサービスは、従来のWindows Active Directory環境と互換性のある**管理されたドメインサービスを提供することにより、Entra IDの機能を拡張**します。LDAP、Kerberos、NTLMなどのレガシープロトコルをサポートし、組織がオンプレミスのドメインコントローラーを展開することなく、クラウドで古いアプリケーションを移行または実行できるようにします。このサービスは、集中管理のためのグループポリシーもサポートしており、レガシーまたはADベースのワークロードが最新のクラウド環境と共存する必要があるシナリオに適しています。
## Entra ID Principals
## Entra IDプリンシパル
### Users
### ユーザー
- **New users**
- Indicate email name and domain from selected tenant
- Indicate Display name
- Indicate password
- Indicate properties (first name, job title, contact info…)
- Default user type is “**member**”
- **External users**
- Indicate email to invite and display name (can be a non Microsft email)
- Indicate properties
- Default user type is “**Guest**”
- **新しいユーザー**
- 選択したテナントからのメール名とドメインを示す
- 表示名を示す
- パスワードを示す
- プロパティ（名、職名、連絡先情報など）を示す
- デフォルトのユーザータイプは「**メンバー**」
- **外部ユーザー**
- 招待するメールと表示名を示す（Microsoft以外のメールも可）
- プロパティを示す
- デフォルトのユーザータイプは「**ゲスト**」
### Members & Guests Default Permissions
### メンバーとゲストのデフォルト権限
You can check them in [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) but among other actions a member will be able to:
[https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) で確認できますが、メンバーは以下のアクションを実行できます。
- Read all users, Groups, Applications, Devices, Roles, Subscriptions, and their public properties
- Invite Guests (_can be turned off_)
- Create Security groups
- Read non-hidden Group memberships
- Add guests to Owned groups
- Create new application (_can be turned off_)
- Add up to 50 devices to Azure (_can be turned off_)
- すべてのユーザー、グループ、アプリケーション、デバイス、ロール、サブスクリプション、およびその公開プロパティを読み取る
- ゲストを招待する（_オフにすることが可能_）
- セキュリティグループを作成する
- 非表示のグループメンバーシップを読み取る
- 所有グループにゲストを追加する
- 新しいアプリケーションを作成する（_オフにすることが可能_）
- Azureに最大50デバイスを追加する（_オフにすることが可能_）
> [!NOTE]
> Remember that to enumerate Azure resources the user needs an explicit grant of the permission.
> Azureリソースを列挙するには、ユーザーに明示的な権限の付与が必要です。
### Users Default Configurable Permissions
### ユーザーのデフォルト設定可能な権限
- **Members (**[**docs**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
- Register Applications: Default **Yes**
- Restrict non-admin users from creating tenants: Default **No**
- Create security groups: Default **Yes**
- Restrict access to Microsoft Entra administration portal: Default **No**
- This doesn’t restrict API access to the portal (only web)
- Allow users to connect work or school account with LinkedIn: Default **Yes**
- Show keep user signed in: Default **Yes**
- Restrict users from recovering the BitLocker key(s) for their owned devices: Default No (check in Device Settings)
- Read other users: Default **Yes** (via Microsoft Graph)
- **Guests**
- **Guest user access restrictions**
- **Guest users have the same access as members** grants all member user permissions to guest users by default.
- **Guest users have limited access to properties and memberships of directory objects (default)** restricts guest access to only their own user profile by default. Access to other users and group information is no longer allowed.
- **Guest user access is restricted to properties and memberships of their own directory objects** is the most restrictive one.
- **Guests can invite**
- **Anyone in the organization can invite guest users including guests and non-admins (most inclusive) - Default**
- **Member users and users assigned to specific admin roles can invite guest users including guests with member permissions**
- **Only users assigned to specific admin roles can invite guest users**
- **No one in the organization can invite guest users including admins (most restrictive)**
- **External user leave**: Default **True**
- Allow external users to leave the organization
- **メンバー（**[**ドキュメント**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**）**
- アプリケーションの登録: デフォルトは**はい**
- 非管理者ユーザーによるテナントの作成を制限: デフォルトは**いいえ**
- セキュリティグループの作成: デフォルトは**はい**
- Microsoft Entra管理ポータルへのアクセスを制限: デフォルトは**いいえ**
- これはポータルへのAPIアクセスを制限しません（ウェブのみ）
- ユーザーがLinkedInと仕事または学校のアカウントを接続できるようにする: デフォルトは**はい**
- ユーザーをサインインしたままにする: デフォルトは**はい**
- ユーザーが所有するデバイスのBitLockerキーを回復することを制限: デフォルトはいいえ（デバイス設定で確認）
- 他のユーザーを読み取る: デフォルトは**はい**（Microsoft Graph経由）
- **ゲスト**
- **ゲストユーザーアクセス制限**
- **ゲストユーザーはメンバーと同じアクセス権を持つ**は、デフォルトでゲストユーザーにすべてのメンバー権限を付与します。
- **ゲストユーザーはディレクトリオブジェクトのプロパティとメンバーシップへのアクセスが制限される（デフォルト）**は、デフォルトで自分のユーザープロファイルのみへのアクセスを制限します。他のユーザーやグループ情報へのアクセスは許可されません。
- **ゲストユーザーアクセスは自分のディレクトリオブジェクトのプロパティとメンバーシップに制限される**が最も制限的です。
- **ゲストは招待できる**
- **組織内の誰でもゲストユーザーを招待できる（ゲストや非管理者を含む、最も包括的） - デフォルト**
- **メンバーユーザーおよび特定の管理ロールに割り当てられたユーザーは、メンバー権限を持つゲストを含むゲストユーザーを招待できます**
- **特定の管理ロールに割り当てられたユーザーのみがゲストユーザーを招待できます**
- **組織内の誰もゲストユーザーを招待できない（管理者を含む、最も制限的）**
- **外部ユーザーの退会**: デフォルトは**真**
- 外部ユーザーが組織を退会できるようにする
> [!TIP]
> Even if restricted by default, users (members and guests) with granted permissions could perform the previous actions.
> デフォルトで制限されていても、権限が付与されたユーザー（メンバーとゲスト）は前述のアクションを実行できます。
### **Groups**
### **グループ**
There are **2 types of groups**:
**2種類のグループ**があります。
- **Security**: This type of group is used to give members access to aplications, resources and assign licenses. Users, devices, service principals and other groups an be members.
- **Microsoft 365**: This type of group is used for collaboration, giving members access to a shared mailbox, calendar, files, SharePoint site, and so on. Group members can only be users.
- This will have an **email address** with the domain of the EntraID tenant.
- **セキュリティ**: このタイプのグループは、メンバーにアプリケーション、リソースへのアクセスを提供し、ライセンスを割り当てるために使用されます。ユーザー、デバイス、サービスプリンシパル、他のグループがメンバーになれます。
- **Microsoft 365**: このタイプのグループは、コラボレーションのために使用され、メンバーに共有メールボックス、カレンダー、ファイル、SharePointサイトなどへのアクセスを提供します。グループメンバーはユーザーのみです。
- これは、EntraIDテナントのドメインを持つ**メールアドレス**を持ちます。
There are **2 types of memberships**:
**2種類のメンバーシップ**があります。
- **Assigned**: Allow to manually add specific members to a group.
- **Dynamic membership**: Automatically manages membership using rules, updating group inclusion when members attributes change.
- **割り当てられた**: 特定のメンバーを手動でグループに追加することを許可します。
- **動的メンバーシップ**: ルールを使用してメンバーシップを自動的に管理し、メンバーの属性が変更されるとグループの含有を更新します。
### **Service Principals**
### **サービスプリンシパル**
A **Service Principal** is an **identity** created for **use** with **applications**, hosted services, and automated tools to access Azure resources. This access is **restricted by the roles assigned** to the service principal, giving you control over **which resources can be accessed** and at which level. For security reasons, it's always recommended to **use service principals with automated tools** rather than allowing them to log in with a user identity.
**サービスプリンシパル**は、**アプリケーション**、ホスティングサービス、および自動化ツールがAzureリソースにアクセスするために**使用**される**アイデンティティ**です。このアクセスは、サービスプリンシパルに割り当てられたロールによって**制限され**、**どのリソースにアクセスできるか**とそのレベルを制御します。セキュリティ上の理由から、**ユーザーアイデンティティでログインするのではなく、自動化ツールとともにサービスプリンシパルを使用することを常に推奨します**。
It's possible to **directly login as a service principal** by generating it a **secret** (password), a **certificate**, or granting **federated** access to third party platforms (e.g. Github Actions) over it.
サービスプリンシパルとして**直接ログインする**ことも可能で、**シークレット**（パスワード）、**証明書**を生成するか、第三者プラットフォーム（例：Github Actions）への**フェデレーテッド**アクセスを付与することができます。
- If you choose **password** auth (by default), **save the password generated** as you won't be able to access it again.
- If you choose certificate authentication, make sure the **application will have access over the private key**.
- **パスワード**認証（デフォルト）を選択した場合、**生成されたパスワードを保存**してください。再度アクセスすることはできません。
- 証明書認証を選択した場合、**アプリケーションがプライベートキーにアクセスできることを確認**してください。
### App Registrations
### アプリ登録
An **App Registration** is a configuration that allows an application to integrate with Entra ID and to perform actions.
**アプリ登録**は、アプリケーションがEntra IDと統合し、アクションを実行できるようにするための構成です。
#### Key Components:
#### 主要コンポーネント:
1. **Application ID (Client ID):** A unique identifier for your app in Azure AD.
2. **Redirect URIs:** URLs where Azure AD sends authentication responses.
3. **Certificates, Secrets & Federated Credentials:** It's possible to generate a secret or a certificate to login as the service principal of the application, or to grant federated access to it (e.g. Github Actions).&#x20;
1. If a **certificate** or **secret** is generated, it's possible to a person to **login as the service principal** with CLI tools by knowing the **application ID**, the **secret** or **certificate** and the **tenant** (domain or ID).
4. **API Permissions:** Specifies what resources or APIs the app can access.
5. **Authentication Settings:** Defines the app's supported authentication flows (e.g., OAuth2, OpenID Connect).
6. **Service Principal**: A service principal is created when an App is created (if it's done from the web console) or when it's installed in a new tenant.
1. The **service principal** will get all the requested permissions it was configured with.
1. **アプリケーションID（クライアントID）**: Azure AD内のアプリの一意の識別子。
2. **リダイレクトURI**: Azure ADが認証応答を送信するURL。
3. **証明書、シークレット、フェデレーテッド資格情報**: アプリケーションのサービスプリンシパルとしてログインするためにシークレットまたは証明書を生成するか、フェデレーテッドアクセスを付与することが可能です。
1. **証明書**または**シークレット**が生成された場合、**アプリケーションID**、**シークレット**または**証明書**、および**テナント**（ドメインまたはID）を知っていることで、CLIツールを使用して**サービスプリンシパルとしてログイン**できます。
4. **API権限**: アプリがアクセスできるリソースまたはAPIを指定します。
5. **認証設定**: アプリのサポートされている認証フローを定義します（例：OAuth2、OpenID Connect）。
6. **サービスプリンシパル**: アプリが作成されると（ウェブコンソールから行われた場合）、サービスプリンシパルが作成されます。
1. **サービスプリンシパル**は、構成されたすべての要求された権限を取得します。
### Default Consent Permissions
### デフォルト同意権限
**User consent for applications**
**アプリケーションに対するユーザー同意**
- **Do not allow user consent**
- An administrator will be required for all apps.
- **Allow user consent for apps from verified publishers, for selected permissions (Recommended)**
- All users can consent for permissions classified as "low impact", for apps from verified publishers or apps registered in this organization.
- **Default** low impact permissions (although you need to accept to add them as low):
- User.Read - sign in and read user profile
- offline_access - maintain access to data that users have given it access to
- openid - sign users in
- profile - view user's basic profile
- email - view user's email address
- **Allow user consent for apps (Default)**
- All users can consent for any app to access the organization's data.
- **ユーザー同意を許可しない**
- すべてのアプリに対して管理者が必要です。
- **確認されたパブリッシャーからのアプリに対するユーザー同意を許可し、選択された権限（推奨）**
- すべてのユーザーは、「低影響」と分類された権限に同意でき、確認されたパブリッシャーからのアプリやこの組織に登録されたアプリに対して同意できます。
- **デフォルト**の低影響権限（ただし、低影響として追加するには同意が必要）:
- User.Read - サインインしてユーザープロファイルを読み取る
- offline_access - ユーザーがアクセスを許可したデータへのアクセスを維持する
- openid - ユーザーをサインインさせる
- profile - ユーザーの基本プロファイルを表示する
- email - ユーザーのメールアドレスを表示する
- **アプリに対するユーザー同意を許可する（デフォルト）**
- すべてのユーザーは、組織のデータにアクセスするために任意のアプリに同意できます。
**Admin consent requests**: Default **No**
**管理者同意要求**: デフォルトは**いいえ**
- Users can request admin consent to apps they are unable to consent to
- If **Yes**: It’s possible to indicate Users, Groups and Roles that can consent requests
- Configure also if users will receive email notifications and expiration reminders&#x20;
- ユーザーは、同意できないアプリに対して管理者同意を要求できます。
- **はい**の場合: 同意要求を行うことができるユーザー、グループ、ロールを指定できます。
- ユーザーがメール通知や期限切れリマインダーを受け取るかどうかも設定できます。
### **Managed Identity (Metadata)**
### **管理されたアイデンティティ（メタデータ）**
Managed identities in Azure Active Directory offer a solution for **automatically managing the identity** of applications. These identities are used by applications for the purpose of **connecting** to **resources** compatible with Azure Active Directory (**Azure AD**) authentication. This allows to **remove the need of hardcoding cloud credentials** in the code as the application will be able to contact the **metadata** service to get a valid token to **perform actions** as the indicated managed identity in Azure.
Azure Active Directoryの管理されたアイデンティティは、アプリケーションの**アイデンティティを自動的に管理する**ためのソリューションを提供します。これらのアイデンティティは、Azure Active Directory（**Azure AD**）認証と互換性のある**リソース**に接続するためにアプリケーションによって使用されます。これにより、アプリケーションは**メタデータ**サービスに連絡して、有効なトークンを取得し、Azureで指定された管理されたアイデンティティとして**アクションを実行**できるようになります。
There are two types of managed identities:
管理されたアイデンティティには2種類あります。
- **System-assigned**. Some Azure services allow you to **enable a managed identity directly on a service instance**. When you enable a system-assigned managed identity, a **service principal** is created in the Entra ID tenant trusted by the subscription where the resource is located. When the **resource** is **deleted**, Azure automatically **deletes** the **identity** for you.
- **User-assigned**. It's also possible for users to generate managed identities. These are created inside a resource group inside a subscription and a service principal will be created in the EntraID trusted by the subscription. Then, you can assign the managed identity to one or **more instances** of an Azure service (multiple resources). For user-assigned managed identities, the **identity is managed separately from the resources that use it**.
- **システム割り当て**: 一部のAzureサービスでは、**サービスインスタンスに直接管理されたアイデンティティを有効にする**ことができます。システム割り当ての管理されたアイデンティティを有効にすると、リソースが存在するサブスクリプションによって信頼されるEntra IDテナントに**サービスプリンシパル**が作成されます。**リソース**が**削除されると**、Azureは自動的に**アイデンティティ**を削除します。
- **ユーザー割り当て**: ユーザーが管理されたアイデンティティを生成することも可能です。これらは、サブスクリプション内のリソースグループ内に作成され、サブスクリプションによって信頼されるEntraIDにサービスプリンシパルが作成されます。その後、管理されたアイデンティティをAzureサービスの1つまたは**複数のインスタンス**（複数のリソース）に割り当てることができます。ユーザー割り当ての管理されたアイデンティティでは、**アイデンティティはそれを使用するリソースとは別に管理されます**。
Managed Identities **don't generate eternal credentials** (like passwords or certificates) to access as the service principal attached to it.
管理されたアイデンティティは、サービスプリンシパルにアクセスするための永続的な資格情報（パスワードや証明書など）を生成しません。
### Enterprise Applications
### エンタープライズアプリケーション
It’s just a **table in Azure to filter service principals** and check the applications that have been assigned to.
これは、サービスプリンシパルをフィルタリングし、割り当てられたアプリケーションを確認するための**Azure内のテーブル**です。
**It isn’t another type of “application”,** there isn’t any object in Azure that is an “Enterprise Application”, it’s just an abstraction to check the Service principals, App registrations and managed identities.
**別の「アプリケーション」タイプではありません。** Azure内に「エンタープライズアプリケーション」というオブジェクトは存在せず、サービスプリンシパル、アプリ登録、管理されたアイデンティティを確認するための抽象化に過ぎません。
### Administrative Units
### 管理単位
Administrative units allows to **give permissions from a role over a specific portion of an organization**.
管理単位は、**組織の特定の部分に対してロールから権限を付与する**ことを可能にします。
Example:
例:
- Scenario: A company wants regional IT admins to manage only the users in their own region.
- Implementation:
- Create Administrative Units for each region (e.g., "North America AU", "Europe AU").
- Populate AUs with users from their respective regions.
- AUs can **contain users, groups, or devices**
- AUs support **dynamic memberships**
- AUs **cannot contain AUs**
- Assign Admin Roles:
- Grant the "User Administrator" role to regional IT staff, scoped to their region's AU.
- Outcome: Regional IT admins can manage user accounts within their region without affecting other regions.
- シナリオ: 会社は地域のIT管理者に自分の地域のユーザーのみを管理させたい。
- 実装:
- 各地域のために管理単位を作成します（例: "北米AU"、"ヨーロッパAU"）。
- 各地域のユーザーでAUを構成します。
- AUは**ユーザー、グループ、またはデバイスを含むことができます**
- AUは**動的メンバーシップをサポートします**
- AUは**AUを含むことができません**
- 管理ロールを割り当てます:
- 地域のITスタッフに「ユーザー管理者」ロールを付与し、その地域のAUにスコープを設定します。
- 結果: 地域のIT管理者は、他の地域に影響を与えることなく、自分の地域内のユーザーアカウントを管理できます。
### Entra ID Roles
### Entra IDロール
- In order to manage Entra ID there are some **built-in roles** that can be assigned to Entra ID principals to manage Entra ID
- Check the roles in [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)
- The most privileged role is **Global Administrator**
- In the Description of the role it’s possible to see its **granular permissions**
- 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)で確認できます。
- 最も特権のあるロールは**グローバル管理者**です。
- ロールの説明には、その**詳細な権限**が表示されます。
## Roles & Permissions
## ロールと権限
**Roles** are **assigned** to **principals** on a **scope**: `principal -[HAS ROLE]->(scope)`
**ロール**は、**プリンシパル**に**スコープ**で割り当てられます: `principal -[HAS ROLE]->(scope)`
**Roles** assigned to **groups** are **inherited** by all the **members** of the group.
**グループ**に割り当てられた**ロール**は、グループのすべての**メンバー**に**継承**されます。
Depending on the scope the role was assigned to, the **role** cold be **inherited** to **other resources** inside the scope container. For example, if a user A has a **role on the subscription**, he will have that **role on all the resource groups** inside the subscription and on **all the resources** inside the resource group.
ロールが割り当てられたスコープに応じて、**ロール**はスコープコンテナ内の**他のリソース**に**継承**される可能性があります。たとえば、ユーザーAが**サブスクリプション**にロールを持っている場合、彼はその**サブスクリプション内のすべてのリソースグループ**および**リソースグループ内のすべてのリソース**にその**ロール**を持ちます。
### **Classic Roles**
### **クラシックロール**
| **Owner** | <ul><li>Full access to all resources</li><li>Can manage access for other users</li></ul> | All resource types |
| **オーナー** | <ul><li>すべてのリソースへの完全なアクセス</li><li>他のユーザーのアクセスを管理できる</li></ul> | すべてのリソースタイプ |
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
| **Contributor** | <ul><li>Full access to all resources</li><li>Cannot manage access</li></ul> | All resource types |
| **Reader** | • View all resources | All resource types |
| **User Access Administrator** | <ul><li>View all resources</li><li>Can manage access for other users</li></ul> | All resource types |
| **寄稿者** | <ul><li>すべてのリソースへの完全なアクセス</li><li>アクセスを管理できない</li></ul> | すべてのリソースタイプ |
| **リーダー** | • すべてのリソースを表示 | すべてのリソースタイプ |
| **ユーザーアクセス管理者** | <ul><li>すべてのリソースを表示</li><li>他のユーザーのアクセスを管理できる</li></ul> | すべてのリソースタイプ |
### Built-In roles
### 組み込みロール
[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) has several Azure **built-in roles** that you can **assign** to **users, groups, service principals, and managed identities**. Role assignments are the way you control **access to Azure resources**. If the built-in roles don't meet the specific needs of your organization, you can create your own [**Azure custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
[ドキュメントから: ](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)**を作成できます。**
**Built-In** roles apply only to the **resources** they are **meant** to, for example check this 2 examples of **Built-In roles over Compute** resources:
**組み込み**ロールは、**意図されたリソース**にのみ適用されます。たとえば、以下の2つの**組み込みロール**の例を確認してください。
| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Provides permission to backup vault to perform disk backup. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
| [ディスクバックアップリーダー](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | ディスクバックアップを実行するためにバックアップボールトへの権限を提供します。 | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
| [Virtual Machine User Login](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | View Virtual Machines in the portal and login as a regular user. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
| [仮想マシンユーザーログイン](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | ポータル内の仮想マシンを表示し、通常のユーザーとしてログインします。 | fb879df8-f326-4884-b1cf-06f3ad86be52 |
This roles can **also be assigned over logic containers** (such as management groups, subscriptions and resource groups) and the principals affected will have them **over the resources inside those containers**.
これらのロールは、**論理コンテナ**（管理グループ、サブスクリプション、リソースグループなど）にも**割り当てることができ**、影響を受けるプリンシパルは**それらのコンテナ内のリソースに対して**持ちます。
- Find here a list with [**all the Azure built-in roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
- Find here a list with [**all the Entra ID built-in roles**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
- ここに[**すべての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)のリストがあります。
### Custom Roles
### カスタムロール
- It’s also possible to create [**custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
- They are created inside a scope, although a role can be in several scopes (management groups, subscription and resource groups)
- It’s possible to configure all the granular permissions the custom role will have
- It’s possible to exclude permissions
- A principal with a excluded permission won’t be able to use it even if the permissions is being granted elsewhere
- It’s possible to use wildcards
- The used format is a JSON
- `actions` are for control actions over the resource
- `dataActions` are permissions over the data within the object
Example of permissions JSON for a custom role:
- [**カスタムロール**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)を作成することも可能です。
- これらはスコープ内に作成されますが、ロールは複数のスコープ（管理グループ、サブスクリプション、リソースグループ）に存在できます。
- カスタムロールが持つすべての詳細な権限を構成できます。
- 権限を除外することも可能です。
- 除外された権限を持つプリンシパルは、他の場所で権限が付与されていてもそれを使用できません。
- ワイルドカードを使用することも可能です。
- 使用される形式はJSONです。
- `actions`はリソースに対する制御アクションのためのものです。
- `dataActions`はオブジェクト内のデータに対する権限です。
カスタムロールの権限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": []
}
]
}
"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
- In order for a **principal to have some access over a resource** he needs an explicit role being granted to him (anyhow) **granting him that permission**.
- An explicit **deny role assignment takes precedence** over the role granting the permission.
- リソースに対して**principalがアクセスを持つためには**、明示的な役割が彼に付与される必要があります（いかなる方法でも）**その権限を付与します**。
- 明示的な**拒否役割の割り当ては**、権限を付与する役割よりも優先されます。
<figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
### Global Administrator
Global Administrator is a role from Entra ID that grants **complete control over the Entra ID tenant**. However, it doesn't grant any permissions over Azure resources by default.
Global Administratorは、**Entra IDテナントに対する完全な制御を付与する**Entra IDの役割です。しかし、デフォルトではAzureリソースに対する権限は付与されません。
Users with the Global Administrator role has the ability to '**elevate' to User Access Administrator Azure role in the Root Management Group**. So Global Administrators can manage access in **all Azure subscriptions and management groups.**\
This elevation can be done at the end of the page: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
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)
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
### Azure Policies
**Azure Policies** are rules that help organizations ensure their resources meet specific standards and compliance requirements. They allow you to **enforce or audit settings on resources in Azure**. For example, you can prevent the creation of virtual machines in an unauthorized region or ensure that all resources have specific tags for tracking.
**Azure Policies**は、組織がリソースが特定の基準およびコンプライアンス要件を満たすことを保証するためのルールです。これにより、**Azure内のリソースに設定を強制または監査することができます**。たとえば、許可されていない地域での仮想マシンの作成を防止したり、すべてのリソースに追跡用の特定のタグが付けられていることを確認したりできます。
Azure Policies are **proactive**: they can stop non-compliant resources from being created or changed. They are also **reactive**, allowing you to find and fix existing non-compliant resources.
Azure Policiesは**プロアクティブ**です：非準拠のリソースが作成または変更されるのを防ぐことができます。また、**リアクティブ**でもあり、既存の非準拠リソースを見つけて修正することができます。
#### **Key Concepts**
1. **Policy Definition**: A rule, written in JSON, that specifies what is allowed or required.
2. **Policy Assignment**: The application of a policy to a specific scope (e.g., subscription, resource group).
3. **Initiatives**: A collection of policies grouped together for broader enforcement.
4. **Effect**: Specifies what happens when the policy is triggered (e.g., "Deny," "Audit," or "Append").
1. **Policy Definition**: 許可または要求されることを指定するJSONで書かれたルール。
2. **Policy Assignment**: 特定のスコープ（例：サブスクリプション、リソースグループ）にポリシーを適用すること。
3. **Initiatives**: より広範な強制のためにグループ化されたポリシーのコレクション。
4. **Effect**: ポリシーがトリガーされたときに何が起こるかを指定します（例：「Deny」、「Audit」、または「Append」）。
**Some examples:**
**いくつかの例:**
1. **Ensuring Compliance with Specific Azure Regions**: This policy ensures that all resources are deployed in specific Azure regions. For example, a company might want to ensure all its data is stored in Europe for GDPR compliance.
2. **Enforcing Naming Standards**: Policies can enforce naming conventions for Azure resources. This helps in organizing and easily identifying resources based on their names, which is helpful in large environments.
3. **Restricting Certain Resource Types**: This policy can restrict the creation of certain types of resources. For example, a policy could be set to prevent the creation of expensive resource types, like certain VM sizes, to control costs.
4. **Enforcing Tagging Policies**: Tags are key-value pairs associated with Azure resources used for resource management. Policies can enforce that certain tags must be present, or have specific values, for all resources. This is useful for cost tracking, ownership, or categorization of resources.
5. **Limiting Public Access to Resources**: Policies can enforce that certain resources, like storage accounts or databases, do not have public endpoints, ensuring that they are only accessible within the organization's network.
6. **Automatically Applying Security Settings**: Policies can be used to automatically apply security settings to resources, such as applying a specific network security group to all VMs or ensuring that all storage accounts use encryption.
1. **特定のAzure地域でのコンプライアンスの確保**: このポリシーは、すべてのリソースが特定のAzure地域にデプロイされることを保証します。たとえば、企業はGDPRコンプライアンスのためにすべてのデータがヨーロッパに保存されることを望むかもしれません。
2. **命名基準の強制**: ポリシーはAzureリソースの命名規則を強制できます。これにより、大規模な環境でリソースを整理し、名前に基づいて簡単に識別するのに役立ちます。
3. **特定のリソースタイプの制限**: このポリシーは、特定のタイプのリソースの作成を制限できます。たとえば、コストを制御するために、特定のVMサイズのような高価なリソースタイプの作成を防ぐポリシーを設定できます。
4. **タグ付けポリシーの強制**: タグは、リソース管理に使用されるAzureリソースに関連付けられたキーと値のペアです。ポリシーは、すべてのリソースに特定のタグが存在するか、特定の値を持つ必要があることを強制できます。これは、コスト追跡、所有権、またはリソースの分類に役立ちます。
5. **リソースへの公共アクセスの制限**: ポリシーは、ストレージアカウントやデータベースのような特定のリソースに公共エンドポイントがないことを強制し、組織のネットワーク内でのみアクセスできるようにします。
6. **セキュリティ設定の自動適用**: ポリシーは、すべてのVMに特定のネットワークセキュリティグループを適用したり、すべてのストレージアカウントが暗号化を使用することを保証したりするなど、リソースにセキュリティ設定を自動的に適用するために使用できます。
Note that Azure Policies can be attached to any level of the Azure hierarchy, but they are **commonly used in the root management group** or in other management groups.
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"
"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"
}
```
### 権限の継承
### Permissions Inheritance
Azure **権限は階層の任意の部分に割り当てることができます**。これには管理グループ、サブスクリプション、リソースグループ、および個々のリソースが含まれます。権限は、割り当てられたエンティティの含まれる**リソース**によって**継承**されます。
In Azure **permissions are can be assigned to any part of the hierarchy**. That includes management groups, subscriptions, resource groups, and individual resources. Permissions are **inherited** by contained **resources** of the entity where they were assigned.
This hierarchical structure allows for efficient and scalable management of access permissions.
この階層構造は、アクセス権限の効率的かつスケーラブルな管理を可能にします。
<figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>
### Azure RBAC vs ABAC
### Azure RBAC と ABAC
**RBAC** (role-based access control) is what we have seen already in the previous sections: **Assigning a role to a principal to grant him access** over a resource.\
However, in some cases you might want to provide **more fined-grained access management** or **simplify** the management of **hundreds** of role **assignments**.
**RBAC**（ロールベースのアクセス制御）は、前のセクションで見たものです：**リソースへのアクセスを付与するために、プリンシパルにロールを割り当てる**。\
しかし、場合によっては、**より細かいアクセス管理**を提供したり、**数百の**ロール**割り当て**の管理を**簡素化**したいことがあります。
Azure **ABAC** (attribute-based access control) builds on Azure RBAC by adding **role assignment conditions based on attributes** in the context of specific actions. A _role assignment condition_ is an **additional check that you can optionally add to your role assignment** to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can **add a condition that requires an object to have a specific tag to read the object**.\
You **cannot** explicitly **deny** **access** to specific resources **using conditions**.
Azure **ABAC**（属性ベースのアクセス制御）は、特定のアクションの文脈における**属性に基づくロール割り当て条件**を追加することでAzure RBACを拡張します。_ロール割り当て条件_は、**より細かいアクセス制御を提供するためにオプションでロール割り当てに追加できる追加のチェック**です。条件は、ロール定義およびロール割り当ての一部として付与される権限を絞り込みます。たとえば、**オブジェクトを読み取るために特定のタグを持つ必要がある条件を追加できます**。\
条件を使用して特定のリソースへの**アクセスを明示的に拒否することはできません**。
## References
## 参考文献
- [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)
@@ -379,7 +375,3 @@ You **cannot** explicitly **deny** **access** to specific resources **using cond
- [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}}
src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
+96 -106
View File
@@ -2,100 +2,99 @@
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
## 基本情報
Entra ID is Microsoft's cloud-based identity and access management (IAM) platform, serving as the foundational authentication and authorization system for services like Microsoft 365 and Azure Resource Manager. Azure AD implements the OAuth 2.0 authorization framework and the OpenID Connect (OIDC) authentication protocol to manage access to resources.
Entra IDは、Microsoftのクラウドベースのアイデンティティおよびアクセス管理（IAM）プラットフォームであり、Microsoft 365やAzure Resource Managerなどのサービスの基盤となる認証および認可システムとして機能します。Azure ADは、リソースへのアクセスを管理するためにOAuth 2.0認可フレームワークとOpenID Connect（OIDC）認証プロトコルを実装しています。
### OAuth
**Key Participants in OAuth 2.0:**
**OAuth 2.0の主要参加者:**
1. **Resource Server (RS):** Protects resources owned by the resource owner.
2. **Resource Owner (RO):** Typically an end-user who owns the protected resources.
3. **Client Application (CA):** An application seeking access to resources on behalf of the resource owner.
4. **Authorization Server (AS):** Issues access tokens to client applications after authenticating and authorizing them.
1. **リソースサーバー（RS）:** リソースオーナーが所有するリソースを保護します。
2. **リソースオーナー（RO）:** 通常、保護されたリソースを所有するエンドユーザーです。
3. **クライアントアプリケーション（CA）:** リソースオーナーの代理としてリソースへのアクセスを求めるアプリケーションです。
4. **認可サーバー（AS）:** クライアントアプリケーションを認証および認可した後、アクセス トークンを発行します。
**Scopes and Consent:**
**スコープと同意:**
- **Scopes:** Granular permissions defined on the resource server that specify access levels.
- **Consent:** The process by which a resource owner grants a client application permission to access resources with specific scopes.
- **スコープ:** アクセスレベルを指定するリソースサーバー上で定義された詳細な権限です。
- **同意:** リソースオーナーが特定のスコープでリソースにアクセスするためのクライアントアプリケーションに権限を付与するプロセスです。
**Microsoft 365 Integration:**
**Microsoft 365統合:**
- Microsoft 365 utilizes Azure AD for IAM and is composed of multiple "first-party" OAuth applications.
- These applications are deeply integrated and often have interdependent service relationships.
- To simplify user experience and maintain functionality, Microsoft grants "implied consent" or "pre-consent" to these first-party applications.
- **Implied Consent:** Certain applications are automatically **granted access to specific scopes without explicit user or administrator approva**l.
- These pre-consented scopes are typically hidden from both users and administrators, making them less visible in standard management interfaces.
- Microsoft 365はIAMのためにAzure ADを利用し、複数の「ファーストパーティ」OAuthアプリケーションで構成されています。
- これらのアプリケーションは深く統合されており、相互依存するサービス関係を持つことがよくあります。
- ユーザーエクスペリエンスを簡素化し、機能を維持するために、Microsoftはこれらのファーストパーティアプリケーションに「暗黙の同意」または「事前同意」を付与します。
- **暗黙の同意:** 特定のアプリケーションは、明示的なユーザーまたは管理者の承認なしに特定のスコープへのアクセスを自動的に**付与されます**。
- これらの事前同意されたスコープは通常、ユーザーや管理者から隠されており、標準の管理インターフェースではあまり目立ちません。
**Client Application Types:**
**クライアントアプリケーションの種類:**
1. **Confidential Clients:**
- Possess their own credentials (e.g., passwords or certificates).
- Can **securely authenticate themselves** to the authorization server.
2. **Public Clients:**
- Do not have unique credentials.
- Cannot securely authenticate to the authorization server.
- **Security Implication:** An attacker can impersonate a public client application when requesting tokens, as there is no mechanism for the authorization server to verify the legitimacy of the application.
1. **機密クライアント:**
- 自身の資格情報（例：パスワードや証明書）を持っています。
- 認可サーバーに**安全に自己認証**できます。
2. **公開クライアント:**
- ユニークな資格情報を持っていません。
- 認可サーバーに安全に認証できません。
- **セキュリティの影響:** 攻撃者は、認可サーバーがアプリケーションの正当性を確認するメカニズムがないため、トークンを要求する際に公開クライアントアプリケーションを偽装できます。
## Authentication Tokens
## 認証トークン
There are **three types of tokens** used in OIDC:
OIDCで使用される**3種類のトークン**があります：
- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** The client presents this token to the resource server to **access resources**. It can be used only for a specific combination of user, client, and resource and **cannot be revoked** until expiry - that is 1 hour by default.
- **ID Tokens**: The client receives this **token from the authorization server**. It contains basic information about the user. It is **bound to a specific combination of user and client**.
- **Refresh Tokens**: Provided to the client with access token. Used to **get new access and ID tokens**. It is bound to a specific combination of user and client and can be revoked. Default expiry is **90 days** for inactive refresh tokens and **no expiry for active tokens** (be from a refresh token is possible to get new refresh tokens).
- A refresh token should be tied to an **`aud`** , to some **scopes**, and to a **tenant** and it should only be able to generate access tokens for that aud, scopes (and no more) and tenant. However, this is not the case with **FOCI applications tokens**.
- A refresh token is encrypted and only Microsoft can decrypt it.
- Getting a new refresh token doesn't revoke the previous refresh token.
- [**アクセス トークン**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** クライアントはこのトークンをリソースサーバーに提示して**リソースにアクセス**します。これは特定のユーザー、クライアント、およびリソースの組み合わせにのみ使用でき、**期限切れまで取り消すことはできません** - デフォルトでは1時間です。
- **IDトークン**: クライアントはこの**トークンを認可サーバーから受け取ります**。ユーザーに関する基本情報が含まれています。これは**特定のユーザーとクライアントの組み合わせにバインドされています**。
- **リフレッシュトークン**: アクセストークンと共にクライアントに提供されます。**新しいアクセスおよびIDトークンを取得するために使用されます**。これは特定のユーザーとクライアントの組み合わせにバインドされており、取り消すことができます。非アクティブなリフレッシュトークンのデフォルトの有効期限は**90日**で、アクティブなトークンには**有効期限がありません**（リフレッシュトークンから新しいリフレッシュトークンを取得することが可能です）。
- リフレッシュトークンは**`aud`**、いくつかの**スコープ**、および**テナント**に結び付けられており、そのaud、スコープ（それ以上ではなく）およびテナントのためにのみアクセス トークンを生成できる必要があります。ただし、これは**FOCIアプリケーショントークン**には当てはまりません。
- リフレッシュトークンは暗号化されており、Microsoftのみがそれを復号化できます。
- 新しいリフレッシュトークンを取得しても、以前のリフレッシュトークンは取り消されません。
> [!WARNING]
> Information for **conditional access** is **stored** inside the **JWT**. So, if you request the **token from an allowed IP address**, that **IP** will be **stored** in the token and then you can use that token from a **non-allowed IP to access the resources**.
> **条件付きアクセス**に関する情報は**JWT**内に**保存**されています。したがって、**許可されたIPアドレス**から**トークンを要求**すると、その**IP**がトークンに**保存**され、その後**許可されていないIPからリソースにアクセスするためにそのトークンを使用**できます。
### Access Tokens "aud"
### アクセストークン "aud"
The field indicated in the "aud" field is the **resource server** (the application) used to perform the login.
"aud"フィールドに示されたフィールドは、ログインを実行するために使用される**リソースサーバー**（アプリケーション）です。
The command `az account get-access-token --resource-type [...]` supports the following types and each of them will add a specific "aud" in the resulting access token:
コマンド`az account get-access-token --resource-type [...]`は、以下のタイプをサポートしており、それぞれが結果のアクセス トークンに特定の"aud"を追加します：
> [!CAUTION]
> Note that the following are just the APIs supported by `az account get-access-token` but there are more.
> 以下は`az account get-access-token`でサポートされているAPIに過ぎないことに注意してくださいが、他にもあります。
<details>
<summary>aud examples</summary>
<summary>audの例</summary>
- **aad-graph (Azure Active Directory Graph API)**: Used to access the legacy Azure AD Graph API (deprecated), which allows applications to read and write directory data in Azure Active Directory (Azure AD).
- `https://graph.windows.net/`
- **aad-graph (Azure Active Directory Graph API)**: レガシーAzure AD Graph API（非推奨）にアクセスするために使用され、アプリケーションがAzure Active Directory（Azure AD）内のディレクトリデータを読み書きすることを可能にします。
- `https://graph.windows.net/`
* **arm (Azure Resource Manager)**: Used to manage Azure resources through the Azure Resource Manager API. This includes operations like creating, updating, and deleting resources such as virtual machines, storage accounts, and more.
- `https://management.core.windows.net/ or https://management.azure.com/`
* **arm (Azure Resource Manager)**: Azure Resource Manager APIを通じてAzureリソースを管理するために使用されます。これには、仮想マシン、ストレージアカウントなどのリソースの作成、更新、削除などの操作が含まれます。
- `https://management.core.windows.net/ or https://management.azure.com/`
- **batch (Azure Batch Services)**: Used to access Azure Batch, a service that enables large-scale parallel and high-performance computing applications efficiently in the cloud.
- `https://batch.core.windows.net/`
- **batch (Azure Batch Services)**: 大規模な並列および高性能コンピューティングアプリケーションをクラウドで効率的に実行するためのサービスであるAzure Batchにアクセスするために使用されます。
- `https://batch.core.windows.net/`
* **data-lake (Azure Data Lake Storage)**: Used to interact with Azure Data Lake Storage Gen1, which is a scalable data storage and analytics service.
- `https://datalake.azure.net/`
* **data-lake (Azure Data Lake Storage)**: スケーラブルなデータストレージおよび分析サービスであるAzure Data Lake Storage Gen1と対話するために使用されます。
- `https://datalake.azure.net/`
- **media (Azure Media Services)**: Used to access Azure Media Services, which provide cloud-based media processing and delivery services for video and audio content.
- `https://rest.media.azure.net`
- **media (Azure Media Services)**: ビデオおよびオーディオコンテンツのためのクラウドベースのメディア処理および配信サービスを提供するAzure Media Servicesにアクセスするために使用されます。
- `https://rest.media.azure.net`
* **ms-graph (Microsoft Graph API)**: Used to access the Microsoft Graph API, the unified endpoint for Microsoft 365 services data. It allows you to access data and insights from services like Azure AD, Office 365, Enterprise Mobility, and Security services.
- `https://graph.microsoft.com`
* **ms-graph (Microsoft Graph API)**: Microsoft 365サービスデータのための統一エンドポイントであるMicrosoft Graph APIにアクセスするために使用されます。Azure AD、Office 365、Enterprise Mobility、Securityサービスなどのサービスからデータとインサイトにアクセスすることを可能にします。
- `https://graph.microsoft.com`
- **oss-rdbms (Azure Open Source Relational Databases)**: Used to access Azure Database services for open-source relational database engines like MySQL, PostgreSQL, and MariaDB.
- `https://ossrdbms-aad.database.windows.net`
- **oss-rdbms (Azure Open Source Relational Databases)**: MySQL、PostgreSQL、MariaDBなどのオープンソースリレーショナルデータベースエンジンのためのAzure Databaseサービスにアクセスするために使用されます。
- `https://ossrdbms-aad.database.windows.net`
</details>
### Access Tokens Scopes "scp"
### アクセストークンのスコープ "scp"
The scope of an access token is stored inside the scp key inside the access token JWT. These scopes define what the access token has access to.
アクセス トークンのスコープは、アクセス トークンJWT内のscpキーに保存されています。これらのスコープは、アクセス トークンがアクセスできるものを定義します。
If a JWT is allowed to contact an specific API but **doesn't have the scope** to perform the requested action, it **won't be able to perform the action** with that JWT.
### Get refresh & access token example
JWTが特定のAPIに連絡することが許可されているが、**要求されたアクションを実行するためのスコープを持っていない場合**、そのJWTでアクションを**実行できません**。
### リフレッシュおよびアクセス トークンの取得例
```python
# Code example from https://github.com/secureworks/family-of-client-ids-research
import msal
@@ -107,17 +106,17 @@ from typing import Any, Dict, List
# LOGIN VIA CODE FLOW AUTHENTICATION
azure_cli_client = msal.PublicClientApplication(
"04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
"04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
)
device_flow = azure_cli_client.initiate_device_flow(
scopes=["https://graph.microsoft.com/.default"]
scopes=["https://graph.microsoft.com/.default"]
)
print(device_flow["message"])
# Perform device code flow authentication
azure_cli_bearer_tokens_for_graph_api = azure_cli_client.acquire_token_by_device_flow(
device_flow
device_flow
)
pprint(azure_cli_bearer_tokens_for_graph_api)
@@ -125,83 +124,74 @@ pprint(azure_cli_bearer_tokens_for_graph_api)
# DECODE JWT
def decode_jwt(base64_blob: str) -> Dict[str, Any]:
"""Decodes base64 encoded JWT blob"""
return jwt.decode(
base64_blob, options={"verify_signature": False, "verify_aud": False}
)
"""Decodes base64 encoded JWT blob"""
return jwt.decode(
base64_blob, options={"verify_signature": False, "verify_aud": False}
)
decoded_access_token = decode_jwt(
azure_cli_bearer_tokens_for_graph_api.get("access_token")
azure_cli_bearer_tokens_for_graph_api.get("access_token")
)
pprint(decoded_access_token)
# GET NEW ACCESS TOKEN AND REFRESH TOKEN
new_azure_cli_bearer_tokens_for_graph_api = (
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),
# Same scopes as original authorization
scopes=["https://graph.microsoft.com/.default"],
)
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),
# Same scopes as original authorization
scopes=["https://graph.microsoft.com/.default"],
)
)
pprint(new_azure_cli_bearer_tokens_for_graph_api)
```
## FOCIトークンの特権昇格
## FOCI Tokens Privilege Escalation
以前に述べたように、リフレッシュトークンは生成された**スコープ**、**アプリケーション**、および**テナント**に結び付けられるべきです。これらの境界のいずれかが破られると、ユーザーがアクセスできる他のリソースやテナントに対して、元々意図されたよりも多くのスコープでアクセストークンを生成することが可能になるため、特権を昇格させることができます。
Previously it was mentioned that refresh tokens should be tied to the **scopes** it was generated with, to the **application** and **tenant** it was generated to. If any of these boundaries is broken, it's possible to escalate privileges as it will be possible to generate access tokens to other resources and tenants the user has access to and with more scopes than it was originally intended.
さらに、[Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/)（Microsoft Entraアカウント、Microsoft個人アカウント、FacebookやGoogleなどのソーシャルアカウント）では、**すべてのリフレッシュトークンでこれが可能です**。なぜなら、[**ドキュメント**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens)には次のように記載されているからです。「リフレッシュトークンはユーザーとクライアントの組み合わせに結び付けられていますが、**リソースやテナントには結び付けられていません**。クライアントは、許可されている任意のリソースとテナントの組み合わせに対してアクセストークンを取得するためにリフレッシュトークンを使用できます。リフレッシュトークンは暗号化されており、Microsoft identity platformのみがそれを読み取ることができます。」
Moreover, **this is possible with all refresh tokens** in the [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google) because as the [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) mention: "Refresh tokens are bound to a combination of user and client, but **aren't tied to a resource or tenant**. A client can use a refresh token to acquire access tokens **across any combination of resource and tenant** where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them."
さらに、FOCIアプリケーションは公開アプリケーションであるため、**サーバーに認証するための秘密は必要ありません**。
Moreover, note that the FOCI applications are public applications, so **no secret is needed** to authenticate to the server.
次に、[**元の研究**](https://github.com/secureworks/family-of-client-ids-research/tree/main)で報告された既知のFOCIクライアントは、[**こちら**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv)で見つけることができます。
Then known FOCI clients reported in the [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main) can be [**found here**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).
### Get different scope
Following with the previous example code, in this code it's requested a new token for a different scope:
### 異なるスコープを取得
前の例のコードに続いて、このコードでは異なるスコープの新しいトークンを要求しています：
```python
# Code from https://github.com/secureworks/family-of-client-ids-research
azure_cli_bearer_tokens_for_outlook_api = (
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
new_azure_cli_bearer_tokens_for_graph_api.get(
"refresh_token"
),
# But different scopes than original authorization
scopes=[
"https://outlook.office.com/.default"
],
)
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
new_azure_cli_bearer_tokens_for_graph_api.get(
"refresh_token"
),
# But different scopes than original authorization
scopes=[
"https://outlook.office.com/.default"
],
)
)
pprint(azure_cli_bearer_tokens_for_outlook_api)
```
### Get different client and scopes
### 異なるクライアントとスコープを取得する
```python
# Code from https://github.com/secureworks/family-of-client-ids-research
microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
microsoft_office_bearer_tokens_for_graph_api = (
# This is a different client application than we used in the previous examples
microsoft_office_client.acquire_token_by_refresh_token(
# But we can use the refresh token issued to our original client application
azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
# And request different scopes too
scopes=["https://graph.microsoft.com/.default"],
)
# This is a different client application than we used in the previous examples
microsoft_office_client.acquire_token_by_refresh_token(
# But we can use the refresh token issued to our original client application
azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
# And request different scopes too
scopes=["https://graph.microsoft.com/.default"],
)
)
# How is this possible?
pprint(microsoft_office_bearer_tokens_for_graph_api)
```
## References
## 参考文献
- [https://github.com/secureworks/family-of-client-ids-research](https://github.com/secureworks/family-of-client-ids-research)
{{#include ../../../banners/hacktricks-training.md}}