gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-01 18:44:56 -07:00
Code Issues Packages Projects Releases Wiki Activity
Files
3c2f3f44a7c7453349f5a5c9022fef94d83ded6a
hacktricks-cloud/src/pentesting-cloud/azure-security/az-basic-information
T
History

README.md

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ディレクトリのみを信頼します。
  • サブスクリプションレベル（またはその親のいずれか）で適用された権限は、サブスクリプション内のすべてのリソースに継承されます。

リソースグループ

ドキュメントから: リソースグループは、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は、開発者や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 で確認できますが、メンバーは以下のアクションを実行できます。

  • すべてのユーザー、グループ、アプリケーション、デバイス、ロール、サブスクリプション、およびその公開プロパティを読み取る
  • ゲストを招待する（オフにすることが可能）
  • セキュリティグループを作成する
  • 非表示のグループメンバーシップを読み取る
  • 所有グループにゲストを追加する
  • 新しいアプリケーションを作成する（オフにすることが可能）
  • Azureに最大50デバイスを追加する（オフにすることが可能）

Note

Azureリソースを列挙するには、ユーザーに明示的な権限の付与が必要です。

ユーザーのデフォルト設定可能な権限

  • メンバー（ドキュメント）
  • アプリケーションの登録: デフォルトははい
  • 非管理者ユーザーによるテナントの作成を制限: デフォルトはいいえ
  • セキュリティグループの作成: デフォルトははい
  • 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. 証明書、シークレット、フェデレーテッド資格情報: アプリケーションのサービスプリンシパルとしてログインするためにシークレットまたは証明書を生成するか、フェデレーテッドアクセスを付与することが可能です。
    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にサービスプリンシパルが作成されます。その後、管理されたアイデンティティをAzureサービスの1つまたは複数のインスタンス（複数のリソース）に割り当てることができます。ユーザー割り当ての管理されたアイデンティティでは、アイデンティティはそれを使用するリソースとは別に管理されます。

管理されたアイデンティティは、サービスプリンシパルにアクセスするための永続的な資格情報（パスワードや証明書など）を生成しません。

エンタープライズアプリケーション

これは、サービスプリンシパルをフィルタリングし、割り当てられたアプリケーションを確認するためのAzure内のテーブルです。

別の「アプリケーション」タイプではありません。 Azure内に「エンタープライズアプリケーション」というオブジェクトは存在せず、サービスプリンシパル、アプリ登録、管理されたアイデンティティを確認するための抽象化に過ぎません。

管理単位

管理単位は、組織の特定の部分に対してロールから権限を付与することを可能にします。

例:

  • シナリオ: 会社は地域のIT管理者に自分の地域のユーザーのみを管理させたい。
  • 実装:
    • 各地域のために管理単位を作成します（例: "北米AU"、"ヨーロッパAU"）。
    • 各地域のユーザーでAUを構成します。
    • AUはユーザー、グループ、またはデバイスを含むことができます
    • AUは動的メンバーシップをサポートします
    • AUはAUを含むことができません
    • 管理ロールを割り当てます:
    • 地域のITスタッフに「ユーザー管理者」ロールを付与し、その地域のAUにスコープを設定します。
    • 結果: 地域のIT管理者は、他の地域に影響を与えることなく、自分の地域内のユーザーアカウントを管理できます。

Entra IDロール

ロールと権限

ロールは、プリンシパルにスコープで割り当てられます: principal -[HAS ROLE]->(scope)

グループに割り当てられたロールは、グループのすべてのメンバーに継承されます。

ロールが割り当てられたスコープに応じて、ロールはスコープコンテナ内の他のリソースに継承される可能性があります。たとえば、ユーザーAがサブスクリプションにロールを持っている場合、彼はそのサブスクリプション内のすべてのリソースグループおよびリソースグループ内のすべてのリソースにそのロールを持ちます。

クラシックロール

オーナー
  • すべてのリソースへの完全なアクセス
  • 他のユーザーのアクセスを管理できる
 すべてのリソースタイプ
寄稿者
  • すべてのリソースへの完全なアクセス
  • アクセスを管理できない
 すべてのリソースタイプ
リーダー • すべてのリソースを表示 すべてのリソースタイプ
ユーザーアクセス管理者
  • すべてのリソースを表示
  • 他のユーザーのアクセスを管理できる
 すべてのリソースタイプ

組み込みロール

ドキュメントから: Azureロールベースアクセス制御（Azure RBAC）には、ユーザー、グループ、サービスプリンシパル、および管理されたアイデンティティに割り当てることができるいくつかのAzureの組み込みロールがあります。ロールの割り当ては、Azureリソースへのアクセスを制御する方法です。組み込みロールが組織の特定のニーズを満たさない場合は、独自のAzureカスタムロールを作成できます。

組み込みロールは、意図されたリソースにのみ適用されます。たとえば、以下の2つの組み込みロールの例を確認してください。

ディスクバックアップリーダー ディスクバックアップを実行するためにバックアップボールトへの権限を提供します。 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
仮想マシンユーザーログイン ポータル内の仮想マシンを表示し、通常のユーザーとしてログインします。 fb879df8-f326-4884-b1cf-06f3ad86be52

これらのロールは、論理コンテナ（管理グループ、サブスクリプション、リソースグループなど）にも割り当てることができ、影響を受けるプリンシパルはそれらのコンテナ内のリソースに対して持ちます。

カスタムロール

  • カスタムロールを作成することも可能です。
  • これらはスコープ内に作成されますが、ロールは複数のスコープ（管理グループ、サブスクリプション、リソースグループ）に存在できます。
  • カスタムロールが持つすべての詳細な権限を構成できます。
  • 権限を除外することも可能です。
  • 除外された権限を持つプリンシパルは、他の場所で権限が付与されていてもそれを使用できません。
  • ワイルドカードを使用することも可能です。
  • 使用される形式はJSONです。
  • actionsはリソースに対する制御アクションのためのものです。
  • dataActionsはオブジェクト内のデータに対する権限です。

カスタムロールの権限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

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:

{
"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を拡張します。_ロール割り当て条件_は、より細かいアクセス制御を提供するためにオプションでロール割り当てに追加できる追加のチェックです。条件は、ロール定義およびロール割り当ての一部として付与される権限を絞り込みます。たとえば、オブジェクトを読み取るために特定のタグを持つ必要がある条件を追加できます。
条件を使用して特定のリソースへのアクセスを明示的に拒否することはできません。

参考文献

{{#include ../../../banners/hacktricks-training.md}}

Reference in New Issue View Git Blame Copy Permalink