Az - Basic Information
組織階層
管理グループ
組織に多くのAzureサブスクリプションがある場合、これらのサブスクリプションのアクセス、ポリシー、およびコンプライアンスを効率的に管理する方法が必要です。管理グループは、サブスクリプションの上にあるガバナンスの範囲を提供します。
1つのディレクトリで10,000の管理グループをサポートでき、管理グループツリーは最大6レベルの深さをサポートできます。
ドキュメントから: 各ディレクトリには、ルート管理グループと呼ばれる単一のトップレベル管理グループが与えられます。ルート管理グループは、すべての管理グループとサブスクリプションがそれに折りたたまれるように階層に組み込まれています。このルート管理グループにより、グローバルポリシーとAzureロールの割り当てがディレクトリレベルで適用されます。Azure AD グローバル管理者は、最初にこのルートグループのユーザーアクセス管理者ロールに昇格する必要があります。アクセスを昇格させた後、管理者は階層を管理するために他のディレクトリユーザーまたはグループに任意のAzureロールを割り当てることができます。管理者として、自分のアカウントをルート管理グループの所有者として割り当てることができます。
ルート管理グループは、他の管理グループとは異なり、移動または削除できません。
管理グループは、どのようなタイプのサブスクリプションを持っていても、エンタープライズグレードの管理を大規模に提供します。ただし、単一の管理グループ内のすべてのサブスクリプションは、同じAzure Active Directory (Azure AD) テナントを信頼する必要があります。
Azureサブスクリプション
Azureでは、サブスクリプションはビジネスまたは技術的なリソースをプロビジョニングするための論理コンテナとして機能します。このコンテナは、仮想マシン (VM)、データベースなどのリソースの詳細を保持します。VMのようなAzureリソースを作成するとき、それに関連付けられたサブスクリプションが指定されます。この構造は、ロールベースのアクセス制御メカニズムを利用してアクセスの委任を容易にします。
リソースグループ
ドキュメントから: リソースグループは、Azureソリューションのための関連リソースを保持するコンテナです。リソースグループには、ソリューションのすべてのリソースを含めることも、グループとして管理したいリソースのみを含めることもできます。一般的に、同じライフサイクルを共有するリソースを同じリソースグループに追加することで、グループとして簡単にデプロイ、更新、削除できます。
すべてのリソースはリソースグループ内に存在し、1つのグループにのみ属し、リソースグループが削除されると、その中のすべてのリソースも削除されます。
管理単位
ドキュメントから: 管理単位を使用すると、組織を任意の単位に細分化し、特定の管理者を割り当てることができます。たとえば、大規模な大学の各学校の管理者に権限を委任するために管理単位を使用し、彼らが工学部内でのみアクセスを制御し、ユーザーを管理し、ポリシーを設定できるようにすることができます。
ユーザー、グループ、およびデバイスのみが管理単位のメンバーとなることができます。
したがって、管理単位はいくつかのメンバーを含み、他のプリンシパルがその管理単位に対して権限を割り当てられ、管理単位のメンバーを管理するために使用できます。
Azure vs Azure AD vs Azure AD ドメインサービス
Azure ADはAzureの内部にあるサービスであることに注意することが重要です。Azureはマイクロソフトのクラウドプラットフォームであり、Azure ADはAzureのエンタープライズアイデンティティサービスです。 さらに、Azure ADはWindows Active Directoryのようなものではなく、全く異なる方法で機能するアイデンティティサービスです。Windows Active Directory環境でAzureにドメインコントローラーを実行したい場合は、Azure AD ドメインサービスを使用する必要があります。
プリンシパル
Azureは異なるタイプのプリンシパルをサポートしています：
ユーザー: アクセスするための資格情報を持つ通常の人。
グループ: 一緒に管理されるプリンシパルのグループ。グループに付与された権限は、そのメンバーによって継承されます。
サービスプリンシパル/エンタープライズアプリケーション: アプリケーション、ホスティングサービス、および自動化ツールがAzureリソースにアクセスするために使用するために作成されたアイデンティティです。このアクセスは、サービスプリンシパルに割り当てられたロールによって制限され、どのリソースにアクセスできるかとそのレベルを制御します。セキュリティ上の理由から、ユーザーアイデンティティでログインさせるのではなく、自動化ツールとともにサービスプリンシパルを使用することが常に推奨されます。
サービスプリンシパルを作成する際には、パスワード認証または証明書認証のいずれかを選択できます。
パスワード認証を選択した場合（デフォルト）、生成されたパスワードを保存してください。再度アクセスすることはできません。
証明書認証を選択した場合、アプリケーションがプライベートキーにアクセスできることを確認してください。
マネージドアイデンティティ（メタデータクレデンシャル）: Azure Active Directoryのマネージドアイデンティティは、アプリケーションのアイデンティティを自動的に管理するためのソリューションを提供します。これらのアイデンティティは、Azure Active Directory（Azure AD）認証に対応するリソースに接続するためにアプリケーションによって使用されます。マネージドアイデンティティを利用することで、アプリケーションはAzure ADトークンを安全に保ちながら、資格情報を直接扱う必要がなくなります。マネージドアイデンティティには2種類あります：
システム割り当て。一部のAzureサービスでは、サービスインスタンスに直接マネージドアイデンティティを有効にすることができます。システム割り当てマネージドアイデンティティを有効にすると、Azure ADにアイデンティティが作成されます。このアイデンティティは、そのサービスインスタンスのライフサイクルに結び付けられています。リソースが削除されると、Azureは自動的にアイデンティティを削除します。設計上、そのAzureリソースのみがこのアイデンティティを使用してAzure ADからトークンを要求できます。
ユーザー割り当て。マネージドアイデンティティをスタンドアロンのAzureリソースとして作成することもできます。ユーザー割り当てマネージドアイデンティティを作成し、1つまたは複数のAzureサービスのインスタンス（複数のリソース）に割り当てることができます。ユーザー割り当てマネージドアイデンティティの場合、アイデンティティはそれを使用するリソースとは別に管理されます。
ロールと権限
ロールはスコープに対してプリンシパルに割り当てられます: principal -[HAS ROLE]->(scope)
グループに割り当てられたロールは、グループのすべてのメンバーによって継承されます。
ロールが割り当てられたスコープに応じて、ロールはスコープコンテナ内の他のリソースに継承される可能性があります。たとえば、ユーザーAがサブスクリプションにロールを持っている場合、彼はそのサブスクリプション内のすべてのリソースグループおよびリソースグループ内のすべてのリソースにそのロールを持ちます。
クラシックロール
ビルトインロール
ドキュメントから: Azureロールベースアクセス制御 (Azure RBAC)には、ユーザー、グループ、サービスプリンシパル、およびマネージドアイデンティティに割り当てることができるいくつかのAzureのビルトインロールがあります。ロールの割り当ては、Azureリソースへのアクセスを制御する方法です。ビルトインロールが組織の特定のニーズを満たさない場合は、独自のAzureカスタムロールを作成できます。
ビルトインロールは、意図されたリソースにのみ適用されます。たとえば、以下の2つのビルトインロールの例を確認してください：
これらのロールは、論理コンテナ（管理グループ、サブスクリプション、リソースグループなど）にも割り当てることができ、影響を受けるプリンシパルはそれらのコンテナ内のリソースに対してロールを持ちます。
ここにすべてのAzureビルトインロールのリストがあります。
ここにすべてのAzure ADビルトインロールのリストがあります。
カスタムロール
Azureは、ユーザーが必要とする権限を持つカスタムロールを作成することも許可します。
権限拒否
プリンシパルがリソースに対してアクセスを持つためには、明示的なロールが付与される必要があります（いずれにせよ）その権限を付与します。
明示的な拒否ロールの割り当ては、権限を付与するロールよりも優先されます。
グローバル管理者
グローバル管理者ロールを持つユーザーは、ルート管理グループに対してユーザーアクセス管理者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の一部を列挙するためのいくつかのデフォルト権限を持ちます：
すべてのユーザー、グループ、アプリケーション、デバイス、ロール、サブスクリプション、およびその公開プロパティを読み取る
ゲストを招待する（オフにすることができます）
セキュリティグループを作成する
非表示でないグループメンバーシップを読み取る
所有グループにゲストを追加する
新しいアプリケーションを作成する（オフにすることができます）
Azureに最大50のデバイスを追加する（オフにすることができます）
ドキュメントでのユーザーのデフォルト権限の完全なリストを確認できます。さらに、そのリストにはゲストのデフォルト権限リストも表示されます。
Azureリソースを列挙するには、ユーザーが明示的に権限を付与される必要があることを忘れないでください。
特権アイデンティティ管理 (PIM)
Azureの特権アイデンティティ管理 (PIM) は、Azure Active DirectoryおよびAzureにおける特権アクセスを管理、制御、および監視するツールです。これは、必要なときに必要な期間だけ特権アクセスを提供し、承認ワークフローを強制し、追加の認証を要求することによってセキュリティを強化します。このアプローチは、特権が必要なときにのみ付与され、特定の期間に制限されることを保証することによって、無許可のアクセスのリスクを最小限に抑えます。
認証トークン
OIDCで使用される3種類のトークンがあります：
アクセストークン: クライアントはこのトークンをリソースサーバーに提示してリソースにアクセスします。これは、特定のユーザー、クライアント、およびリソースの組み合わせにのみ使用でき、期限切れまで取り消すことはできません - デフォルトでは1時間です。検出は低いです。
IDトークン: クライアントはこのトークンを認証サーバーから受け取ります。これは、ユーザーに関する基本情報を含んでいます。これは、特定のユーザーとクライアントの組み合わせに結び付けられています。
リフレッシュトークン: アクセストークンとともにクライアントに提供されます。新しいアクセストークンとIDトークンを取得するために使用されます。これは、特定のユーザーとクライアントの組み合わせに結び付けられ、取り消すことができます。デフォルトの有効期限は、非アクティブなリフレッシュトークンで90日、アクティブなトークンには有効期限がありません。
条件付きアクセスに関する情報はJWT内に保存されます。したがって、許可されたIPアドレスからトークンを要求すると、そのIPがトークンに保存され、その後許可されていないIPからリソースにアクセスするためにそのトークンを使用できます。
以下のページを確認して、アクセストークンを要求するさまざまな方法とそれを使用してログインする方法を学んでください：
最も一般的なAPIエンドポイントは次のとおりです：
Azureリソースマネージャー (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com（非推奨のAzure AD Graphはgraph.windows.net）
参考文献
Last updated
