Az - 基本情報

Reading time: 36 minutes

組織階層

管理グループ

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

Azureサブスクリプション

• これは、リソース（VM、DBなど）を実行し、請求される論理コンテナです。
• その親は常に管理グループであり（ルート管理グループであることも可能）、サブスクリプションは他のサブスクリプションを含むことはできません。
• 1つのEntra IDディレクトリのみを信頼します。
• サブスクリプションレベル（またはその親のいずれか）で適用される権限は、サブスクリプション内のすべてのリソースに継承されます。

リソースグループ

ドキュメントから: リソースグループは、Azureソリューションのための関連リソースを保持するコンテナです。リソースグループには、ソリューションのすべてのリソースを含めることも、管理したいリソースのみを含めることもできます。一般的に、同じライフサイクルを共有するリソースを同じリソースグループに追加することで、グループとして簡単にデプロイ、更新、削除できます。

すべてのリソースはリソースグループ内に存在し、グループにのみ属することができ、リソースグループが削除されると、その中のすべてのリソースも削除されます。

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 で確認できますが、メンバーは以下のアクションを実行できます：

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

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

• メンバー（ドキュメント）
• アプリケーションの登録：デフォルトははい
• 非管理者ユーザーによるテナントの作成を制限：デフォルトはいいえ
• セキュリティグループの作成：デフォルトははい
• Microsoft Entra管理ポータルへのアクセスを制限：デフォルトはいいえ
• これはポータルへのAPIアクセスを制限しません（ウェブのみ）
• ユーザーがLinkedInと仕事または学校のアカウントを接続できるようにする：デフォルトははい
• ユーザーをサインインしたままにする：デフォルトははい
• ユーザーが所有するデバイスのBitLockerキーを回復することを制限：デフォルトはいいえ（デバイス設定で確認）
• 他のユーザーを読み取る：デフォルトははい（Microsoft Graph経由）
• ゲスト
• ゲストユーザーアクセス制限オプション：
• ゲストユーザーはメンバーと同じアクセス権を持ちます。
• ゲストユーザーはディレクトリオブジェクトのプロパティとメンバーシップへのアクセスが制限されています（デフォルト）。これにより、デフォルトでゲストは自分のユーザープロファイルのみへのアクセスが許可されます。他のユーザーやグループ情報へのアクセスは許可されません。
• ゲストユーザーアクセスは自分のディレクトリオブジェクトのプロパティとメンバーシップに制限されていますが最も制限的です。
• ゲストを招待できるオプション：
• 組織内の誰でもゲストユーザーを招待できます（最も包括的） - デフォルト
• メンバーユーザーおよび特定の管理ロールに割り当てられたユーザーは、メンバー権限を持つゲストを含むゲストユーザーを招待できます
• 特定の管理ロールに割り当てられたユーザーのみがゲストユーザーを招待できます
• 組織内の誰もゲストユーザーを招待できません（最も制限的）
• 外部ユーザーの退会：デフォルトは真
• 外部ユーザーが組織を離れることを許可

グループ

2種類のグループがあります：

• セキュリティ：このタイプのグループは、メンバーにアプリケーション、リソースへのアクセスを提供し、ライセンスを割り当てるために使用されます。ユーザー、デバイス、サービスプリンシパル、他のグループがメンバーになれます。
• Microsoft 365：このタイプのグループは、コラボレーションのために使用され、メンバーに共有メールボックス、カレンダー、ファイル、SharePointサイトなどへのアクセスを提供します。グループメンバーはユーザーのみです。
• これは、EntraIDテナントのドメインを持つメールアドレスを持ちます。

2種類のメンバーシップがあります：

• 割り当てられた：特定のメンバーを手動でグループに追加することを許可します。
• 動的メンバーシップ：ルールを使用してメンバーシップを自動的に管理し、メンバーの属性が変更されるとグループの含有を更新します。

サービスプリンシパル

サービスプリンシパルは、アプリケーション、ホスティングサービス、および自動化ツールがAzureリソースにアクセスするために使用されるアイデンティティです。このアクセスは、サービスプリンシパルに割り当てられたロールによって制限され、どのリソースにアクセスできるかを制御します。セキュリティ上の理由から、ユーザーアイデンティティでログインさせるのではなく、自動化ツールとともにサービスプリンシパルを使用することを常に推奨します。

サービスプリンシパルとして直接ログインすることも可能で、シークレット（パスワード）、証明書、または第三者プラットフォーム（例：Github Actions）へのフェデレーテッドアクセスを付与することができます。

• パスワード認証を選択した場合（デフォルト）、生成されたパスワードを保存してください。再度アクセスすることはできません。
• 証明書認証を選択した場合、アプリケーションがプライベートキーにアクセスできることを確認してください。

アプリ登録

アプリ登録は、アプリケーションがEntra IDと統合し、アクションを実行するための構成です。

主要コンポーネント：

1. アプリケーションID（クライアントID）： Azure AD内のアプリの一意の識別子。
2. リダイレクトURI： Azure ADが認証応答を送信するURL。
3. 証明書、シークレット、フェデレーテッド資格情報： アプリケーションのサービスプリンシパルとしてログインするためにシークレットまたは証明書を生成することが可能で、またそれにフェデレーテッドアクセスを付与することもできます（例：Github Actions）。
4. 証明書またはシークレットが生成された場合、アプリケーションID、シークレットまたは証明書、およびテナント（ドメインまたはID）を知っていることで、CLIツールを使用してサービスプリンシパルとしてログインできます。
5. API権限： アプリがアクセスできるリソースまたはAPIを指定します。
6. 認証設定： アプリがサポートする認証フローを定義します（例：OAuth2、OpenID Connect）。
7. サービスプリンシパル：アプリが作成されると（ウェブコンソールから行われた場合）、サービスプリンシパルが作成されます。
8. サービスプリンシパルは、構成されたすべての要求された権限を取得します。

デフォルト同意権限

アプリケーションに対するユーザー同意

• ユーザー同意を許可しない
• すべてのアプリに対して管理者が必要です。
• 確認されたパブリッシャーからのアプリ、内部アプリ、および選択された権限のみを要求するアプリに対してユーザー同意を許可する（推奨）
• すべてのユーザーは、"低影響"として分類された権限のみを要求するアプリ、確認されたパブリッシャーからのアプリ、およびテナントに登録されたアプリに同意できます。
• デフォルトの低影響権限（ただし、低影響として追加するには同意が必要）：
• 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 でロールを確認できます。
• EntraIDによって**PRIVILEGED**とマークされたロールは、Microsoftがドキュメントで説明しているように：特権ロールの割り当ては、安全で意図された方法で使用されない場合、特権の昇格につながる可能性があるため、注意して割り当てるべきです。
• 最も特権のあるロールはグローバル管理者です。
• ロールグループは詳細な権限をまとめており、それらは説明に記載されています。
• 希望する権限を持つカスタムロールを作成することが可能です。ただし、何らかの理由で、すべての詳細な権限が管理者によるカスタムロールの作成に利用できるわけではありません。
• Entra IDのロールはAzureのロールとは完全に独立しています。唯一の関係は、Entra IDでグローバル管理者のロールを持つプリンシパルが、Azureでユーザーアクセス管理者のロールに昇格できることです。
• Entra IDのロールでワイルドカードを使用することはできません。

Azureロールと権限

• ロールはスコープでプリンシパルに割り当てられます： principal -[HAS ROLE]->(scope)
• グループに割り当てられたロールは、グループのすべてのメンバーに継承されます。
• ロールが割り当てられたスコープに応じて、ロールはスコープコンテナ内の他のリソースに継承される可能性があります。たとえば、ユーザーAがサブスクリプションにロールを持っている場合、彼はそのサブスクリプション内のすべてのリソースグループおよびリソースグループ内のすべてのリソースにそのロールを持ちます。

組み込みロール

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

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

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

• ここにすべてのAzure組み込みロールのリストがあります。
• ここにすべてのEntra ID組み込みロールのリストがあります。

カスタムロール

• カスタムロールを作成することも可能です。
• これらはスコープ内に作成されますが、ロールは複数のスコープ（管理グループ、サブスクリプション、リソースグループ）に存在できます。
• カスタムロールが持つすべての詳細な権限を構成することが可能です。
• 権限を除外することも可能です。
• 除外された権限を持つプリンシパルは、他の場所で権限が付与されていてもその権限を使用できません。
• ワイルドカードを使用することが可能です。
• 使用される形式はJSONです。
• actionsは、リソースの作成、更新、削除などの管理操作に対する権限を指します。
• dataActionsは、リソース内のデータ操作に対する権限であり、リソース内の実際のデータを読み取ったり、書き込んだり、削除したりすることを許可します。
• notActionsおよびnotDataActionsは、ロールから特定の権限を除外するために使用されます。ただし、それらを拒否するわけではなく、異なるロールがそれらを付与する場合、プリンシパルはそれらを持ちます。
• assignableScopesは、ロールを割り当てることができるスコープの配列です（管理グループ、サブスクリプション、リソースグループなど）。

カスタムロールの権限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がアクセスを持つためには、明示的な役割が付与される必要があります（いかなる方法でも）その権限を付与します。
• 明示的な拒否の割り当ては、権限を付与する役割よりも優先されます。

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

Assignments Conditions & MFA

ドキュメントによると: 現在、条件は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:

{
"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/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://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