Az - Basic Information
組織階層
管理グループ
組織に 多くのAzureサブスクリプションがある場合、これらの サブスクリプションの アクセス、ポリシー、コンプライアンスを効率的に 管理する方法が必要になる場合があります。 管理グループは、 サブスクリプションよりも上位のガバナンススコープを提供します。
1つのディレクトリで 10,000の管理グループをサポートし、管理グループツリーは 最大6階層の深さをサポートできます。
ドキュメントから: 各ディレクトリには、 ルート管理グループと呼ばれる単一の最上位管理グループが与えられます。 ルート管理グループは、 すべての管理グループとサブスクリプションがそれに折りたたまれるように階層に組み込まれています。 このルート管理グループには、 グローバルポリシーとAzureロールの割り当てがディレクトリレベルで適用できます。 Azure AD Global Administrator は、最初にこのルートグループのユーザーアクセス管理者ロールに昇格する必要があります。 アクセスを昇格させた後、管理者は、他のディレクトリユーザーまたはグループにAzureロールを割り当てて階層を管理できます。 管理者として、 自分のアカウントをルートの所有者として割り当てることができます。
ルート管理グループは、他の管理グループとは異なり、 移動または削除できません。
管理グループを使用すると、どのような種類のサブスクリプションがあっても、スケールでエンタープライズグレードの管理が可能です。 ただし、 単一の管理グループ内のすべてのサブスクリプションは、 同じAzure Active Directory（Azure AD）テナントを信頼する必要があります。
Azureサブスクリプション
Azureでは、サブスクリプションは、ビジネスや技術の リソースをプロビジョニングするための 論理的なコンテナとして機能します。 このコンテナは、仮想マシン（VM）、データベースなどのリソースの詳細を維持します。 VMなどのAzureリソースの作成時には、それに関連付けられた サブスクリプションが指定されます。 この構造により、ロールベースのアクセス制御メカニズムを利用してアクセスを委任することが容易になります。
リソースグループ
ドキュメントから： リソースグループは、Azureソリューションの 関連するリソースを保持する コンテナです。 リソースグループには、ソリューションのすべてのリソース、または グループとして管理したいリソースのみを含めることができます。 通常、 ライフサイクルを共有するリソースを同じリソースグループに追加して、グループとして簡単に展開、更新、削除できるようにします。
すべての リソースは リソースグループ内にあり、グループにのみ属することができ、リソースグループが削除されると、それに含まれるすべてのリソースも削除されます。
管理ユニット
ドキュメントから： 管理ユニットを使用すると、組織を 任意の単位に 細分化し、そのユニットの メンバーだけを管理できる特定の管理者を 割り当てることができます。 たとえば、大学の各学部の管理者に権限を委任して、工学部のみでアクセスを制御し、ユーザーを管理し、ポリシーを設定できるようにするために、管理ユニットを使用できます。
ユーザー、グループ、デバイスのみが 管理ユニットの メンバーになることができます。
したがって、 管理ユニットにはいくつかの メンバーが含まれ、他の 主体はその管理ユニットを管理するために使用できる権限が 割り当てられます。
Azure vs Azure AD vs Azure AD Domain Services
重要なのは、Azure ADは Azureの中にあるサービスです。 AzureはMicrosoftの クラウドプラットフォームであり、Azure ADはAzure内のエンタープライズ アイデンティティサービスです。 さらに、Azure ADはWindows Active Directoryとは異なり、完全に異なる方法で機能するアイデンティティサービスです。 Windows Active Directory環境で ドメインコントローラーをAzureで実行したい場合は、Azure AD Domain Servicesを使用する必要があります。
主体
Azureは異なるタイプの主体をサポートしています:
ユーザー: アクセス権を持つ 通常の人
グループ: 一緒に管理される 主体のグループ。 グループに付与された 権限 は、その メンバー に 継承 されます。
サービスプリンシパル/エンタープライズアプリケーション: アプリケーション、ホストされるサービス、およびAzureリソースにアクセスするために作成された アイデンティティ。 このアクセスは、サービスプリンシパルに割り当てられた ロールによって制限 され、 どのリソースにアクセスできるか およびどのレベルでアクセスできるかを制御します。 セキュリティ上の理由から、 自動化ツールでサービスプリンシパルを使用 することが常に推奨されます。
サービスプリンシパルを作成する際には、 パスワード認証 または 証明書認証 のいずれかを選択できます。
パスワード認証を選択した場合（デフォルト）、 生成されたパスワードを保存 しておく必要があります。
証明書認証を選択した場合は、 アプリケーションがプライベートキーにアクセスできるように してください。
管理されたアイデンティティ（メタデータ認証情報）: Azure Active Directoryの管理されたアイデンティティは、アプリケーションの アイデンティティを自動的に管理する 解決策を提供します。 これらのアイデンティティは、Azure Active Directory（Azure AD）認証に対応したリソースに接続するためにアプリケーションによって使用されます。 管理されたアイデンティティを利用することで、アプリケーションは Azure ADトークンを安全に保護 しながら、直接資格情報を処理する必要がなくなります。 2種類の管理されたアイデンティティがあります:
システム割り当て。一部のAzureサービスでは、サービスインスタンスに 直接管理されたアイデンティティを有効にすることができます。 システム割り当ての管理されたアイデンティティを有効にすると、Azure ADにアイデンティティが作成されます。 このアイデンティティは、そのサービスインスタンスの ライフサイクルに結び付けられています。 リソースが 削除 されると、Azureは自動的に そのアイデンティティを削除 します。 設計上、そのAzureリソースだけがこのアイデンティティを使用してAzure ADからトークンを要求できます。
ユーザー割り当て。スタンドアロンのAzureリソースとして管理されたアイデンティティを作成することもできます。 ユーザー割り当ての管理されたアイデンティティを作成し、Azureサービスの1つまたは 複数のインスタンス（複数のリソース）に割り当てることができます。 ユーザー割り当ての管理されたアイデンティティでは、 そのアイデンティティを使用するリソースとは別に管理 されます。
ロールと権限
ロールはスコープに主体に割り当てられます: 主体 -[HAS ROLE]->(スコープ)
グループに割り当てられたロールは、グループのすべてのメンバーに継承されます。
割り当てられたロールがスコープによって異なり、例えば、ユーザーAがサブスクリプションにロールを持っている場合、そのユーザーはサブスクリプション内のすべてのリソースグループおよびリソースグループ内のすべてのリソースにそのロールを持つことになります。
クラシックロール
所有者 |
| すべてのリソースタイプ |
寄稿者 |
| すべてのリソースタイプ |
リーダー | • すべてのリソースを表示 | すべてのリソースタイプ |
ユーザーアクセス管理者 |
| すべてのリソースタイプ |
組み込みロール
ドキュメントから: Azure ロールベースのアクセス制御 (Azure RBAC)には、ユーザー、グループ、サービスプリンシパル、および管理された IDに**割り当てることができるいくつかの Azure 組み込みロールがあります。ロールの割り当ては、Azure リソースへのアクセスを制御する方法です。組み込みのロールが組織の特定のニーズを満たさない場合は、Azure カスタムロールを作成することができます。
組み込みのロールは、それが意図されているリソースにのみ適用されます。たとえば、Computeリソースに対する2つの組み込みロールの例を確認してください:
ディスクバックアップを実行するためのバックアップボールトの権限を提供します。 | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
ポータルで仮想マシンを表示し、通常のユーザーとしてログインします。 | fb879df8-f326-4884-b1cf-06f3ad86be52 |
これらのロールはロジックコンテナ（管理グループ、サブスクリプション、リソースグループなど）にも割り当てることができ、影響を受ける主体はそれらのコンテナ内のリソースにそれらを持つことになります。
すべての Azure 組み込みロールのリストはこちらで見つけることができます。
すべての Azure AD 組み込みロールのリストはこちらで見つけることができます。
カスタムロール
Azureでは、ユーザーが必要とする権限を持つカスタムロールを作成することもできます。
アクセスが拒否されました
主体がリソースにアクセス権を持つためには、明示的なロールが割り当てられ（どのようにであれ）その権限が与えられる必要があります。 明示的な拒否ロール割り当ては、権限を付与するロールよりも優先されます。
グローバル管理者
グローバル管理者ロールを持つユーザーは、User Access Administrator Azure ロールをルート管理グループに昇格する権限を持っています。これにより、グローバル管理者はすべての Azure サブスクリプションと管理グループを管理することができます。 この昇格は次のページの最後で行うことができます: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure ポリシー
Azure ポリシーは、Microsoft Azureのルールと規制のセットであり、組織の基準を管理し、規制順守を評価するのに役立ちます。これらのポリシーは、異なるルールをAzure リソースに強制し、それらのリソースが企業の基準とサービスレベル契約に準拠していることを確認します。
Azure ポリシーは、クラウドガバナンスとセキュリティに不可欠であり、リソースが適切かつ効率的に使用され、外部規制および内部ポリシーに準拠していることを確認します。 いくつかの例:
特定の Azure リージョンへの準拠の確保: このポリシーは、すべてのリソースが特定の Azure リージョンに展開されることを確認します。たとえば、企業は GDPR の準拠のためにすべてのデータをヨーロッパに保存することを望むかもしれません。
命名規則の強制: ポリシーは Azure リソースの命名規則を強制できます。これにより、名前に基づいてリソースを整理および簡単に識別することができ、大規模な環境で役立ちます。
特定のリソースタイプの制限: このポリシーは、特定の種類のリソースの作成を制限できます。たとえば、特定の VM サイズなどの高価なリソースタイプの作成を防止するためにポリシーを設定できます。
タグ付けポリシーの強制: タグは、Azure リソースに関連付けられたキーと値のペアで、リソース管理に使用されます。ポリシーは、すべてのリソースに特定のタグが存在するか、特定の値を持つ必要があることを強制できます。これは、コスト追跡、所有権、またはリソースのカテゴリ分類に役立ちます。
リソースへの公開アクセスの制限: ポリシーは、ストレージアカウントやデータベースなどの特定のリソースが公開エンドポイントを持たないように強制し、それらが組織のネットワーク内でのみアクセス可能であることを確認します。
セキュリティ設定の自動適用: ポリシーは、リソースにセキュリティ設定を自動的に適用するために使用できます。たとえば、すべての VM に特定のネットワークセキュリティグループを適用したり、すべてのストレージアカウントが暗号化を使用するようにしたりすることができます。
Azure ポリシーは Azure 階層の任意のレベルにアタッチできますが、一般的にはルート管理グループや他の管理グループで使用されます。
権限スコープ
Azureでは、権限は階層の任意の部分に割り当てることができます。これには、管理グループ、サブスクリプション、リソースグループ、個々のリソースが含まれます。権限は、割り当てられたエンティティの含まれるリソースによって継承されます。
この階層構造により、アクセス権限の効率的かつスケーラブルな管理が可能となります。
Azure RBAC vs ABAC
RBAC（ロールベースのアクセス制御）は、以前のセクションで見たように、主体にロールを割り当ててアクセス権を付与することです。 ただし、場合によっては、より細かいアクセス管理を提供したり、何百ものロール割り当てを簡素化することが望ましい場合があります。
Azure ABAC（属性ベースのアクセス制御）は、Azure RBACに特定のアクションのコンテキストで属性に基づいたロール割り当て条件を追加することで構築されます。ロール割り当て条件は、ロール定義およびロール割り当ての一部としてオプションで追加できる追加チェックです。たとえば、特定のタグを持つオブジェクトがオブジェクトを読むために必要であるという条件を追加できます。 条件を使用して特定のリソースへのアクセスを明示的に拒否することはできません。
デフォルトユーザー権限
基本ユーザーはAzureADの一部を列挙するためのいくつかのデフォルト権限を持ちます：
すべてのユーザー、グループ、アプリケーション、デバイス、ロール、サブスクリプション、およびそれらの公開プロパティを読む
ゲストを招待する（オフにできる）
セキュリティグループを作成する
非表示のグループメンバーシップを読む
所有するグループにゲストを追加する
新しいアプリケーションを作成する（オフにできる）
最大50台のデバイスをAzureに追加する（オフにできる）
ユーザーのデフォルト権限のリストをドキュメントで確認できます。さらに、そのリストにはゲストのデフォルト権限リストも表示されます。
Azureリソースを列挙するには、ユーザーに明示的な権限付与が必要です。
特権アイデンティティ管理（PIM）
Azureの特権アイデンティティ管理（PIM）は、Azure Active DirectoryとAzureでの特権アクセスを管理、制御、監視するツールです。必要なときにだけ特権アクセスを提供し、時間制限を設け、承認ワークフローを強制し、追加の認証を要求することでセキュリティを強化します。このアプローチにより、昇格された権限が必要な場合にのみ、特定の期間だけ付与されるため、未承認のアクセスのリスクが最小限に抑えられます。
認証トークン
OIDCで使用される3種類のトークンがあります：
アクセストークン: クライアントはこのトークンをリソースサーバーに提示してリソースにアクセスします。ユーザー、クライアント、リソースの特定の組み合わせにのみ使用でき、有効期限まで取り消すことはできません（デフォルトでは1時間）。これを使用して検出することは難しいです。
IDトークン：クライアントは認可サーバーからこのトークンを受け取ります。ユーザーに関する基本情報が含まれています。特定のユーザーとクライアントの組み合わせにバインドされています。
リフレッシュトークン：アクセストークンとともにクライアントに提供されます。新しいアクセスおよびIDトークンを取得するために使用されます。特定のユーザーとクライアントの組み合わせにバインドされ、取り消すことができます。非アクティブなリフレッシュトークンのデフォルトの有効期限は90日であり、アクティブなトークンには有効期限がありません。
条件付きアクセスの情報はJWT内に保存されます。したがって、許可されたIPアドレスからトークンを要求すると、そのIPがトークンに保存され、その後、そのトークンを使用してリソースにアクセスできる許可されていないIPからアクセスできます。
異なる方法でアクセストークンを要求し、それらでログインする方法を学ぶために、次のページをチェックしてください：
pageAz - AzureAD (AAD)最も一般的なAPIエンドポイントは次のとおりです：
Azure Resource Manager（ARM）: management.azure.com
Microsoft Graph: graph.microsoft.com（非推奨のAzure AD Graphはgraph.windows.net）
参考文献
最終更新
