タグ・ベースのアクセス制御

条件およびタグ変数のセットを使用して、リソースに適用されたタグに基づいてアクセスのスコープを設定するポリシーを記述できます。アクセスは、リクエストしているリソースに存在するタグ、またはリクエストのターゲット・リソースまたはコンパートメントに基づいて制御できます。タグ・ベースのアクセス制御により、コンパートメント、グループおよびリソースにまたがるタグを使用してアクセス・ポリシーを定義できるため、ポリシーに対する柔軟性が向上します。

注意:

組織で、タグを使用してアクセスを管理するポリシーを作成することを選択した場合は、タグを適用できるユーザーを管理する適切なコントロールが配置されていることを確認します。また、ポリシーが設定された後、グループ、ユーザーまたはリソースにタグを適用すると、リソースへのアクセスを推測できることに注意してください。

このようなポリシーを作成する前に、タグを運ぶ潜在的なすべてのリクエスタおよびターゲット・リソースを認識していることを確認してください。

リソースにタグを適用する前に、そのタグを含む所定のポリシーを認識し、リソースへのアクセス権を持つユーザーに影響を与える可能性があることを確認してください。

リクエストしているリソースに適用されるタグの値に基づいて、アクセスを制御できます。具体的には、リクエスト元のユーザーが属するグループに割り当てられているタグの値に基づいて、ユーザー・アクセスを付与するポリシー・ステートメントを記述できます。

また、ターゲット・リソースに適用されるタグの値またはターゲット・リソースが存在するコンパートメントに基づいてアクセスを制御することもできます。

ポリシー・ステートメントでタグを使用してアクセスのスコープを設定することで、単一のポリシー・ステートメントを介して複数のグループのアクセスを定義できます。元のポリシーを変更せずにタグを適用または削除することで、グループのアクセスを遅延したり、アクセスを取り消したりすることもできます。

「Oracle Private Cloud Applianceユーザーズ・ガイド」には、ポリシー構文でタグ変数と演算子を使用する方法の詳細な説明と例が示されています。 Identity and Access Managementの章の「ポリシー・ステートメントの作成」の項を参照してください。

重要なノートおよび制限

この項では、リソース・タグに基づいて権限を制御するポリシーの書込みを開始する際に考慮する多くのアイテムについて説明します。

項目	説明
リソースをリストする権限は個別に付与する必要があります	ターゲット・リソースに適用されたタグに基づいてアクセスのスコープを設定するポリシーでは、リソースのリストを返すことができる権限を付与できません。したがって、リソースのリストを許可する権限は、追加のポリシー・ステートメントを使用して付与する必要があります。このアプローチでは、ユーザーが管理するリソースを表示できるが、検査する権限のみを制限するため、タグ・ベースのポリシーが改善されます。この制限を回避するために使用できるもう1つの方法は、アクセス権を付与するリソースを含むコンパートメントにタグ付けすることです。
ターゲット・リソースにタグを必要とするポリシーは、作成権限を付与できません	リソースのタグの値に基づいてアクセスのスコープを設定するポリシーを記述する場合は、ポリシーで作成権限を付与できないことに注意してください。たとえば、ターゲット・リソースがまだ作成されていないため、インスタンスの作成リクエストは失敗し、評価する適切なタグがありません。そのタグでインスタンスを使用および削除することは許可されますが、インスタンスの作成はできません。
ポリシー変数で使用されるタグ・ネームスペースおよびタグ・キー定義の文字の制限	タグ・ネームスペースおよびタグ・キー定義では、ポリシー変数で許可されるよりも広い文字セットがサポートされます。したがって、変数でタグ・ネームスペースおよびタグ・キー定義を使用するには、ポリシー変数でもサポートされている文字のみが含まれていることを確認してください。サポートされている文字: `a-z, A-Z, 0-9, _, @, -, :` タグ・ネームスペースまたはタグ・キーにこれらの文字以外の文字がある場合、ポリシー変数では使用できません。タグ・ネームスペースおよびタグ・キーの名前を変更できないため、新しいタグ・ネームスペースおよびタグ・キー定義を作成する必要があります。
ケースに関する考慮事項	ポリシーでタグを操作する場合、タグ値は大/小文字が区別されないことに注意してください。
コンパートメント階層	ターゲット・コンパートメントに適用されるタグに基づいてアクセスを許可する条件を記述する場合、このポリシーでは、タグ付けされたコンパートメント内にネストされているすべてのコンパートメントへのアクセスも許可されることに注意してください。タグ付けされたコンパートメント内のすべてのサブコンパートメントは、タグ付けされたコンパートメント内のリソースであるため、ポリシーによってアクセス権が付与されます。
サポートされているサービス	すべてのサービスは、`request.principal.group`および`target.resource.compartment.tag`ポリシー変数をサポートしています。すべてのサービスが`target.resource.tag`ポリシー変数をサポートしているわけではありません。サポートされているサービスは次のとおりです: Compute、Networking、IAM、DNS、File Storage、Block Storage。

グループに適用されるタグの使用例

次の例は、ユーザー・グループに適用されたタグを使用して、コンパートメント内のリソースへのアクセスを管理する方法を示しています。

3つのコンパートメントがあるとします: ProjectA、ProjectBおよびProjectC。コンパートメントごとに、管理グループが設定されています: A-Admins、B-AdminsおよびC-Admins。各管理グループは、次のポリシーを介して自分のコンパートメントに対する完全なアクセス権を持ちます:

allow group A-Admins to manage all-resources in compartment ProjectA
allow group B-Admins to manage all-resources in compartment ProjectB
allow group C-Admins to manage all-resources in compartment ProjectC

組織では、ロールによって各グループにタグ付けするための次のタグ・ネームスペースおよびキーが設定されています: EmployeeGroup.Role。このタグの一部の値は、管理、開発者、テスト・エンジニアです。すべての管理グループにEmployeeGroup.Role='Admin'のタグが付けられます。

ここで、共有する3つのプロジェクトのメンバーのテスト・コンパートメントを設定します。既存の3つの管理グループすべてに対する管理アクセス権を付与します。これを実現するために、次のようなポリシーを記述できます:

allow any-group to manage all-resources in compartment Test where
request.principal.group.tag.EmployeeGroup.Role='Admin'

このポリシーでは、タグを持つ既存のすべての管理グループが、テスト・コンパートメントにアクセスできます。また、今後EmployeeGroup.Role='Admin'でタグ付けする新規または既存のグループは、ポリシー・ステートメントを更新せずにテスト・コンパートメントにアクセスできます。

ターゲット・リソース・コンパートメントに適用されるタグの使用例

この例では、組織プロジェクト・コンパートメントごとに2つの子コンパートメントが含まれています: テストと製品。テスト・エンジニアに、3つのプロジェクトすべてにわたってテスト・コンパートメントへのアクセス権を付与しようと考えています。これを行うには、タグResourceGroup.Role='Test'を作成し、これを各プロジェクト・コンパートメント内のテスト・コンパートメントに適用します。

グループTestersが3つすべてのテスト・コンパートメントのリソースにアクセスできるようにするには、次のようなポリシーを使用します:

allow group Testers to use all-resources in tenancy where
target.resource.compartment.tag.ResourceGroup.Role='Test'