Az - Basic Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
他の管理グループやサブスクリプションを含むことができます。
これにより、管理グループレベルでRBACやAzureポリシーなどのガバナンスコントロールを適用し、グループ内のすべてのサブスクリプションに継承させることができます。
10,000の管理グループが単一のディレクトリでサポートされます。
管理グループツリーは最大6レベルの深さをサポートできます。この制限にはルートレベルやサブスクリプションレベルは含まれません。
各管理グループとサブスクリプションは1つの親のみをサポートできます。
複数の管理グループを作成できる場合でも、ルート管理グループは1つだけです。
ルート管理グループはすべての他の管理グループとサブスクリプションを含み、移動または削除することはできません。
単一の管理グループ内のすべてのサブスクリプションは、同じEntra IDテナントを信頼する必要があります。
これは、リソース（VM、DBなど）を実行し、請求される論理コンテナです。
その親は常に管理グループであり（ルート管理グループであることも可能）、サブスクリプションは他のサブスクリプションを含むことはできません。
1つのEntra IDディレクトリのみを信頼します。
サブスクリプションレベル（またはその親のいずれか）で適用される権限は、サブスクリプション内のすべてのリソースに継承されます。
From the docs: リソースグループは、Azureソリューションのための関連リソースを保持するコンテナです。リソースグループには、ソリューションのすべてのリソースを含めることも、管理したいリソースのみを含めることもできます。一般的に、同じライフサイクルを共有するリソースを同じリソースグループに追加することで、グループとして簡単に展開、更新、削除できます。
すべてのリソースはリソースグループ内に存在し、グループにのみ属し、リソースグループが削除されると、その中のすべてのリソースも削除されます。
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は、Microsoftの包括的なクラウドコンピューティングプラットフォームであり、幅広いサービスを提供しています。これには、仮想マシン、データベース、人工知能、ストレージが含まれます。Azureは、アプリケーションのホスティングと管理、スケーラブルなインフラストラクチャの構築、クラウドでの最新のワークロードの実行の基盤として機能します。Azureは、開発者やIT専門家がアプリケーションやサービスをシームレスに作成、展開、管理できるツールを提供し、スタートアップから大企業までさまざまなニーズに対応します。
Entra IDは、認証、承認、ユーザーアクセス制御を処理するために設計されたクラウドベースのアイデンティティおよびアクセス管理サービスです。これは、Office 365、Azure、および多くのサードパーティのSaaSアプリケーションへの安全なアクセスを提供します。シングルサインオン（SSO）、多要素認証（MFA）、条件付きアクセスポリシーなどの機能を備えています。
Entraドメインサービスは、従来のWindows Active Directory環境と互換性のある管理されたドメインサービスを提供することにより、Entra IDの機能を拡張します。LDAP、Kerberos、NTLMなどのレガシープロトコルをサポートし、組織がオンプレミスのドメインコントローラーを展開することなく、クラウドで古いアプリケーションを移行または実行できるようにします。このサービスは、集中管理のためのグループポリシーもサポートしており、レガシーまたはADベースのワークロードが最新のクラウド環境と共存する必要があるシナリオに適しています。
新しいユーザー
選択したテナントからのメール名とドメインを指定
表示名を指定
パスワードを指定
プロパティを指定（名、職名、連絡先情報など…）
デフォルトのユーザータイプは「メンバー」
外部ユーザー
招待するメールを指定し、表示名を指定（Microsoft以外のメールも可）
プロパティを指定
デフォルトのユーザータイプは「ゲスト」
https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions で確認できますが、メンバーは以下のアクションを実行できます：
すべてのユーザー、グループ、アプリケーション、デバイス、役割、サブスクリプション、およびその公開プロパティを読み取る
ゲストを招待する（オフにすることが可能）
セキュリティグループを作成する
非表示のグループメンバーシップを読み取る
所有グループにゲストを追加する
新しいアプリケーションを作成する（オフにすることが可能）
Azureに最大50デバイスを追加する（オフにすることが可能）
Azureリソースを列挙するには、ユーザーが明示的に権限を付与される必要があることを忘れないでください。
メンバー（docs）
アプリケーションの登録：デフォルトははい
非管理者ユーザーがテナントを作成するのを制限：デフォルトはいいえ
セキュリティグループを作成する：デフォルトははい
Microsoft Entra管理ポータルへのアクセスを制限：デフォルトはいいえ
これはポータルへのAPIアクセスを制限しません（ウェブのみ）
ユーザーがLinkedInと仕事または学校のアカウントを接続できるようにする：デフォルトははい
ユーザーをサインインしたままにする：デフォルトははい
ユーザーが所有するデバイスのBitLockerキーを回復するのを制限：デフォルトはいいえ（デバイス設定で確認）
他のユーザーを読み取る：デフォルトははい（Microsoft Graph経由）
ゲスト
ゲストユーザーアクセス制限
ゲストユーザーはメンバーと同じアクセス権を持つは、デフォルトでゲストユーザーにすべてのメンバーユーザー権限を付与します。
**ゲストユーザーはディレクトリオブジェクトのプロパティとメンバーシップへのアクセスが制限される（デフォルト）**は、デフォルトで自分のユーザープロファイルのみにゲストアクセスを制限します。他のユーザーやグループ情報へのアクセスは許可されません。
ゲストユーザーアクセスは自分のディレクトリオブジェクトのプロパティとメンバーシップに制限されるは、最も制限的です。
ゲストは招待できる
組織内の誰でもゲストユーザーを招待できる（ゲストや非管理者を含む、最も包括的） - デフォルト
メンバーユーザーおよび特定の管理役割に割り当てられたユーザーは、メンバー権限を持つゲストを含むゲストユーザーを招待できます
特定の管理役割に割り当てられたユーザーのみがゲストユーザーを招待できます
組織内の誰もゲストユーザーを招待できない（管理者を含む、最も制限的）
外部ユーザーの退会：デフォルトは真
外部ユーザーが組織を離れることを許可
デフォルトで制限されていても、権限が付与されたユーザー（メンバーとゲスト）は前述のアクションを実行できます。
2種類のグループがあります：
セキュリティ：このタイプのグループは、メンバーにアプリケーション、リソースへのアクセスを提供し、ライセンスを割り当てるために使用されます。ユーザー、デバイス、サービスプリンシパル、他のグループがメンバーになれます。
Microsoft 365：このタイプのグループは、コラボレーションのために使用され、メンバーに共有メールボックス、カレンダー、ファイル、SharePointサイトなどへのアクセスを提供します。グループメンバーはユーザーのみです。
これは、EntraIDテナントのドメインを持つメールアドレスを持ちます。
2種類のメンバーシップがあります：
割り当てられた：特定のメンバーを手動でグループに追加することを許可します。
動的メンバーシップ：ルールを使用してメンバーシップを自動的に管理し、メンバーの属性が変更されるとグループの含有を更新します。
サービスプリンシパルは、アプリケーション、ホスティングサービス、および自動化ツールがAzureリソースにアクセスするために使用するために作成されたアイデンティティです。このアクセスは、サービスプリンシパルに割り当てられた役割によって制限され、どのリソースにアクセスできるかとそのレベルを制御します。セキュリティ上の理由から、ユーザーアイデンティティでログインさせるのではなく、自動化ツールとともにサービスプリンシパルを使用することを常に推奨します。
サービスプリンシパルとして直接ログインすることも可能で、シークレット（パスワード）、証明書を生成するか、第三者プラットフォーム（例：Github Actions）へのフェデレーテッドアクセスを付与することができます。
パスワード認証を選択した場合（デフォルト）、生成されたパスワードを保存してください。再度アクセスすることはできません。
証明書認証を選択した場合、アプリケーションがプライベートキーにアクセスできることを確認してください。
アプリ登録は、アプリケーションがEntra IDと統合し、アクションを実行するための構成です。
アプリケーションID（クライアントID）：Azure AD内のアプリの一意の識別子。
リダイレクトURI：Azure ADが認証応答を送信するURL。
証明書、シークレット、フェデレーテッド資格情報：アプリケーションのサービスプリンシパルとしてログインするためにシークレットまたは証明書を生成するか、フェデレーテッドアクセスを付与することが可能です（例：Github Actions）。
証明書またはシークレットが生成された場合、アプリケーションID、シークレットまたは証明書、およびテナント（ドメインまたはID）を知っていることで、CLIツールを使用してサービスプリンシパルとしてログインできます。
API権限：アプリがアクセスできるリソースまたはAPIを指定します。
認証設定：アプリのサポートされている認証フローを定義します（例：OAuth2、OpenID Connect）。
サービスプリンシパル：アプリが作成されると（ウェブコンソールから行われた場合）、サービスプリンシパルが作成されます。
サービスプリンシパルは、構成されたすべての要求された権限を取得します。
アプリケーションに対するユーザー同意
ユーザー同意を許可しない
すべてのアプリに対して管理者が必要です。
検証されたパブリッシャーからのアプリに対して、選択された権限のユーザー同意を許可する（推奨）
すべてのユーザーは、「低影響」と分類された権限に対して同意でき、検証されたパブリッシャーからのアプリやこの組織に登録されたアプリに対して同意できます。
デフォルトの低影響権限（ただし、低影響として追加するには同意が必要）：
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を管理するために、Entra IDプリンシパルに割り当てることができる組み込み役割があります。
最も特権のある役割はグローバル管理者です。
役割の説明には、その詳細な権限が表示されます。
役割はプリンシパルにスコープで割り当てられます： principal -[HAS ROLE]->(scope)
グループに割り当てられた役割は、グループのすべてのメンバーに継承されます。
役割が割り当てられたスコープに応じて、役割はスコープコンテナ内の他のリソースに継承される可能性があります。たとえば、ユーザーAがサブスクリプションに役割を持っている場合、彼はそのサブスクリプション内のすべてのリソースグループおよびリソースグループ内のすべてのリソースにその役割を持ちます。
オーナー
すべてのリソースへの完全なアクセス
他のユーザーのアクセスを管理できる
すべてのリソースタイプ
寄稿者
すべてのリソースへの完全なアクセス
アクセスを管理できない
すべてのリソースタイプ
リーダー
• すべてのリソースを表示
すべてのリソースタイプ
ユーザーアクセス管理者
すべてのリソースを表示
他のユーザーのアクセスを管理できる
すべてのリソースタイプ
From the docs: Azureロールベースアクセス制御（Azure RBAC）には、ユーザー、グループ、サービスプリンシパル、および管理されたアイデンティティに割り当てることができるいくつかのAzureの組み込み役割があります。役割の割り当ては、Azureリソースへのアクセスを制御する方法です。組み込み役割が組織の特定のニーズを満たさない場合は、独自のAzureカスタム役割を作成できます。
組み込み役割は、意図されたリソースにのみ適用されます。たとえば、次の2つの組み込み役割の例を確認してください：
ディスクバックアップを実行するためにバックアップボールトへの権限を提供します。
3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
ポータル内の仮想マシンを表示し、通常のユーザーとしてログインします。
fb879df8-f326-4884-b1cf-06f3ad86be52
これらの役割は、論理コンテナ（管理グループ、サブスクリプション、リソースグループなど）にも割り当てることができ、影響を受けるプリンシパルはそれらのコンテナ内のリソースに対して役割を持ちます。
ここにすべてのAzure組み込み役割のリストがあります。
ここにすべてのEntra ID組み込み役割のリストがあります。
カスタム役割を作成することも可能です。
これらはスコープ内に作成されますが、役割は複数のスコープ（管理グループ、サブスクリプション、リソースグループ）に存在できます。
カスタム役割が持つすべての詳細な権限を構成することができます。
権限を除外することも可能です。
除外された権限を持つプリンシパルは、他の場所で権限が付与されていてもそれを使用できません。
ワイルドカードを使用することも可能です。
使用される形式はJSONです。
actionsはリソースに対する制御アクションです。
dataActionsはオブジェクト内のデータに対する権限です。
カスタム役割の権限JSONの例：
リソースに対してプリンシパルがアクセスを持つためには、明示的な役割が付与される必要があります（いずれにせよ）その権限を付与します。
明示的な拒否役割の割り当ては、権限を付与する役割よりも優先されます。
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内のリソースに対して設定を強制または監査することができます。たとえば、許可されていない地域での仮想マシンの作成を防止したり、すべてのリソースに追跡用の特定のタグが付けられていることを確認したりできます。
Azure Policiesはプロアクティブです：非準拠のリソースが作成または変更されるのを防ぐことができます。また、リアクティブでもあり、既存の非準拠リソースを見つけて修正することができます。
Policy Definition: 許可または要求されることを指定するJSONで書かれたルール。
Policy Assignment: 特定のスコープ（例：サブスクリプション、リソースグループ）にポリシーを適用すること。
Initiatives: より広範な強制のためにグループ化されたポリシーのコレクション。
Effect: ポリシーがトリガーされたときに何が起こるかを指定します（例：「拒否」、「監査」、または「追加」）。
いくつかの例:
特定のAzureリージョンでのコンプライアンスの確保: このポリシーは、すべてのリソースが特定のAzureリージョンにデプロイされることを保証します。たとえば、企業はGDPRコンプライアンスのためにすべてのデータがヨーロッパに保存されることを望むかもしれません。
命名基準の強制: ポリシーはAzureリソースの命名規則を強制できます。これにより、大規模な環境でリソースを整理し、名前に基づいて簡単に識別するのに役立ちます。
特定のリソースタイプの制限: このポリシーは、特定のタイプのリソースの作成を制限できます。たとえば、コストを制御するために、特定のVMサイズのような高価なリソースタイプの作成を防ぐポリシーを設定できます。
タグ付けポリシーの強制: タグは、リソース管理に使用されるAzureリソースに関連付けられたキーと値のペアです。ポリシーは、すべてのリソースに特定のタグが存在するか、特定の値を持つ必要があることを強制できます。これは、コスト追跡、所有権、またはリソースの分類に役立ちます。
リソースへの公共アクセスの制限: ポリシーは、ストレージアカウントやデータベースのような特定のリソースに公共エンドポイントがないことを強制し、組織のネットワーク内でのみアクセスできるようにします。
セキュリティ設定の自動適用: ポリシーは、すべてのVMに特定のネットワークセキュリティグループを適用したり、すべてのストレージアカウントが暗号化を使用することを保証したりするなど、リソースにセキュリティ設定を自動的に適用するために使用できます。
Azure PoliciesはAzure階層の任意のレベルに添付できますが、一般的にはルート管理グループまたは他の管理グループで使用されます。
Azure policy json example:
Azureでは権限は階層の任意の部分に割り当てることができます。これには管理グループ、サブスクリプション、リソースグループ、および個々のリソースが含まれます。権限は、割り当てられたエンティティのリソースによって継承されます。
この階層構造は、アクセス権限の効率的かつスケーラブルな管理を可能にします。
RBAC（ロールベースのアクセス制御）は、前のセクションで見たものです：リソースへのアクセスを付与するために、プリンシパルにロールを割り当てる。 しかし、場合によっては、より細かいアクセス管理を提供したり、数百のロール割り当ての管理を簡素化したいことがあります。
Azure ABAC（属性ベースのアクセス制御）は、特定のアクションの文脈における属性に基づくロール割り当て条件を追加することでAzure RBACを拡張します。_ロール割り当て条件_は、より細かいアクセス制御を提供するためにオプションでロール割り当てに追加できる追加のチェックです。条件は、ロール定義およびロール割り当ての一部として付与される権限を絞り込みます。たとえば、オブジェクトを読み取るために特定のタグを持つ必要がある条件を追加できます。 条件を使用して特定のリソースへのアクセスを明示的に拒否することはできません。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
