権限ポリシーに許可（allow）と拒否（deny）の権限付与文が同時に含まれる場合、具体的なシナリオに基づいてdenyが有効かどうかを判断する必要があります。
本稿は、リソースリスト類の操作、COS権限によるすべてのユーザー（匿名ユーザーanonymous）へのdeny、課金関連操作という三つの典型的なシナリオをクエリすることにより、denyが有効にならないロジックを理解するのに役立ちます。
リソースリストタイプのクエリ操作
Tencent Cloudの各サービスの操作（action）は、追加、削除、変更、照会の4種類に簡潔に分類できます。そのうち照会類は、単一リソースの詳細照会と特定種類のリソースリスト照会にさらに分けられます。以下のシナリオではdenyが有効にならない可能性があり、このような操作に対してdenyの使用やstring_not_equal、string_likeなどの条件キーの使用を避けることを推奨します。
有効にならないシナリオ一覧
シナリオ1：付与により、サブユーザーがCVMインスタンスa、b、cへのアクセスを許可（allow）し、インスタンスdへのアクセスを拒否（deny）します。同時に、サブユーザーにTag Tが紐付けられたリソースへのアクセスを付与します。ここで、インスタンスdはTag Tが紐付けられています。この場合、「インスタンスdへのアクセス拒否（deny）」のポリシーは有効になりません。
例えば、以下のポリシーを付与すると、ユーザーがCVMインスタンスリストを閲覧する際に、引き続きインスタンスdを閲覧できます。
{
"version": "2.0",
"statement": [
{
"effect": "allow",
"action": [
"*"
],
"resource": "*",
"condition": {
"for_any_value:string_equal": {
"qcs:resource_tag": [
"key&T"
]
}
}
},
{
"effect": "allow",
"action": [
"*"
],
"resource": [
"qcs::cvm:ap-guangzhou::instanceid/a",
"qcs::cvm:ap-guangzhou::instanceid/b",
"qcs::cvm:ap-guangzhou::instanceid/c"
]
},
{
"effect": "deny",
"action": [
"*"
],
"resource": [
"qcs::cvm:ap-guangzhou::instanceid/d"
]
}
]
}
シナリオ2：付与により、サブユーザーがTag T1が紐付けられたリソースへのアクセスを許可し、Tag T2が紐付けられたリソースへのアクセスを拒否します。ここで、リソースaは一方でTag T1が紐付けられ、他方でTag T2も紐付けられている場合、リソースaへのアクセス拒否のポリシーは有効になりません。
例えば、以下のポリシーを付与すると、リソースリストを閲覧する際に、引き続きリソースaを閲覧できます。
{
"version": "2.0",
"statement": [
{
"effect": "allow",
"action": [
"*"
],
"resource": "*",
"condition": {
"for_any_value:string_equal": {
"qcs:resource_tag": [
"key&T1"
]
}
}
},
{
"effect": "deny",
"action": [
"*"
],
"resource": "*",
"condition": {
"for_any_value:string_equal": {
"qcs:resource_tag": [
"key&T2"
]
}
}
}
]
}
シナリオ3：権限ポリシーがconditionを含む場合、完全一致をサポートするポリシー条件キー（string_equal、ip_equal、ip_not_equalなど）のみ有効になります。その他のタイプの条件キー（例えば string_not_equal など）は有効になりません。
例えば、以下のポリシーを付与すると、ユーザーは引き続きTag Tが紐付けられたリソースを閲覧できる可能性があります。
{
"version": "2.0",
"statement": [
{
"effect": "allow",
"action": [
"*"
],
"resource": "*",
"condition": {
"for_any_value:string_not_equal": {
"qcs:resource_tag": [
"key&T"
]
}
}
}
]
}
シナリオ4：同時に付与によりすべてのresourceへのアクセスを許可し、および指定されたTagが紐付けられたリソースへのアクセスを拒否する場合、アクセス拒否が有効にならない可能性があります。つまり、引き続きそのTagが紐付けられたリソースを閲覧できることを意味します。
例えば、以下のポリシーを付与すると、ユーザーはリソースリストを閲覧する際に、引き続きマスターアカウント配下のすべてのリソースを閲覧できる可能性があります。
{
"version": "2.0",
"statement": [
{
"effect": "allow",
"action": [
"*"
],
"resource": "*"
},
{
"effect": "deny",
"action": [
"*"
],
"resource": "*",
"condition": {
"for_any_value:string_equal": {
"qcs:resource_tag": [
"key&T"
]
}
}
}
]
}
COS権限によるすべてのユーザー（匿名ユーザー anonymous）の拒否
COSのBucket ACLまたはBucket Policyで全てのユーザー（匿名ユーザーanonymous）のアクセスをdenyするように設定しても、同時に特定のユーザーをallowするように別途指定している場合、allowされたユーザーは引き続きCOSストレージバケットにアクセスできます。
課金関連操作
サブユーザーがAdministratorAccessまたはQCloudFinanceFullAccessポリシーに関連付けられ、同時にdeny action finance:xxのポリシーにも関連付けられている場合、このサブユーザーはaction finance:xxにおいて引き続き認証を通過でき、アクセス拒否されません。