ポリシーの拒否
Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)拒否ポリシーは、管理者が不要なアクションを明示的にブロックできるようにするオプトイン機能であり、セキュリティを強化し、アクセス制御を合理化します。拒否オプションはデフォルトでは有効になっていません。管理者は有効にする必要があります。
IAM拒否ポリシーにより、ポリシー管理を簡素化する拒否ステートメントが導入され、リソース・アクセスの制限が簡単になります。デフォルト・ドメインのデフォルト管理者グループのメンバーのみが、コンソールのガイド付きワークフローを介して拒否ポリシーを有効にできます。設定中に、次のデフォルトのルートレベル・ポリシーによって、拒否ステートメントを管理できるユーザーが制限されるため、IAM拒否を有効にしたテナンシ管理者のみが、拒否ポリシーの書込みを許可され、デフォルトの管理者グループのメンバーも許可されます:
deny any-user to manage policies in tenancy where all {target.policy.type='deny', request.principal.id!='[ocid]'}デフォルトドメイン内のデフォルト管理者グループのメンバーは、常に拒否ポリシーから免除され、最上位レベルでの継続的なアクセスが保証されます。
リスクの制御を支援するために、管理者はポリシーの変更を拒否するための通知を有効にできます。denyポリシーはセキュリティと柔軟性を高めますが、子コンパートメントの管理者はdenyポリシーを使用して親アクセスをブロックできるため、慎重に管理する必要があります。拒否ポリシーは、許可ポリシーよりも優先されます。
IAM拒否ポリシーの利点は、次のとおりです。
- オプトイン保護:デフォルトでは無効になっています。テナンシ管理者は、拒否機能を明示的に有効にして、意図しないリスクを低減する必要があります。
- より強力なアクセス制御:アクセスを明示的にブロックできるため、特権ユーザーよりも細かいガバナンスが可能になります。
- より強力なガードレール:ルート管理者は、テナンシ全体の幅広い制限を設定できます。
ポリシー構文
Denyポリシー構文は、ポリシー・ステートメントがdenyキーワードで始まることを除き、許可ポリシー構文と一致します。ポリシーは、allowで指定または暗黙的に開始することを許可します:
allow...admit...endorse...
ポリシーを拒否すると、denyが明示的に表示されます。
deny...deny admit...deny endorse...
コンテキスト変数
policy-type変数を使用すると、ポリシー作成者が特定のタイプのポリシーのみを作成するように制限できます。たとえば、ユーザーが作成できるのは、指定したコンパートメント内の許可ポリシーのみです。これをサポートするために、target.policy.typeコンテキスト変数は、APIの作成、更新および削除のポリシーにあります。target.policy.type値はセットであり、1つのポリシーにallow文とdeny文の両方がある場合、allowとdenyの両方の値を含めることができます。
target.policy.typeコンテキスト変数は、deny、deny admitおよびdeny endorseの3つのタイプの拒否ポリシーすべてに適用されます。| キー | 値 | 説明 |
|---|---|---|
target.policy.type |
allow/deny | 変更するポリシーが、許可ポリシーの1/5か、拒否ポリシーの1/3かを指定します |
次に、target.policy.type変数を使用する許可ポリシーの例を示します。
allow group SampleGroup to manage policies in tenancy where sets-equal(target.policy.type, 'allow')allow group SampleGroup to manage policies in tenancy where target.policy.type != 'deny'拒否ポリシーを使用すると、同じ結果を得ることができます。
deny group SampleGroup to manage policies in tenancy where target.policy.type = 'deny'許可ポリシーを使用する場合、'='比較(set-equalまたは'!='ではなく)は期待どおりに動作しません。'='比較は、少なくとも1つの文に値があるが、必ずしもすべてではない場合に一致します。
Metaverb Inversion
IAMは、特定の権限を削除することでアクセスを制限し、意図したアクションのみが許可されるようにポリシーを拒否します。拒否ポリシーの上書きにより、アクセスを制限する許可ポリシー。一方、IAMでは、ポリシーによってリソースにアクセスする権限が付与されます。
アクセス・レベルは累積されます(最小アクセス・レベルから最高アクセス・レベルまで)。階層は、
readからuse、manage (最高レベルのアクセス)までのinspect (最下位レベルのアクセス)です。たとえば、権限を許可する場合、manage権限へのアクセス権を付与することは、通常、ユーザーにreadやinspectなどの権限も付与されることを意味します。manage動詞は、常にスコープを拡張して、リソースに対するuse、readおよびinspect権限を含めます。
ただし、アクセス権を拒否する場合は、その逆です。manage権限へのアクセスを拒否するポリシーが記述されている場合、必ずしもinspect、readまたはuseの権限をブロックするわけではありません。
たとえば、拒否ポリシーを記述してinspect権限をブロックする場合、通常、read、useまたはmanage権限も制限します。つまり、リソースをinspectする機能を拒否すると、リソースをread、useまたはmanageする機能も拒否されます。
許可ポリシーの場合は、指定されたものと等しいか低いアクセス権を持つすべてのメタ動詞を含めます。
拒否ポリシーの場合、指定されたポリシーよりも高い権限を持つすべてのメタ動詞を含めます。たとえば、次のポリシーは、SampleGroupによるバケットの削除をブロックしますが、readアクセスはブロックしません。これは、AuthZがまだデフォルトで拒否されるため、アクセス権が付与された別のポリシーを前提としています。
deny group SampleGroup to manage buckets in tenancy一方、次のポリシーは、SampleGroupがそれらのバケットに対して何かをブロックします。アクセスを拒否することは、下位レベルのすべてのアクセス権も拒否することを意味します。
deny group SampleGroup to inspect buckets in tenancy特定の権限文字列は、許可ポリシーを使用して現在あるため、拒否できます(必要な場合)。
deny group SampleGroup to { BUCKET_INSPECT } in tenancyアカウント・ロックアウト防止
非常に広範な拒否ポリシーが記述されている場合、拒否ポリシーは意図せずにテナンシからユーザーをロックアウトする可能性があります。たとえば、コンパートメント管理者がdeny any-user to inspect any-resource in compartment Xなどのポリシーを作成する場合、ポリシーは、ポリシーを作成した管理者を含め、すべてのユーザーがそのコンパートメントのリソースにアクセスすることをブロックします。これを回避するために、デフォルト・ドメインの各テナンシに作成されるデフォルト管理者グループは、拒否ポリシーから除外されます。これにより、広範な拒否ポリシーによって誰かが誤ってロックアウトされた場合に、デフォルトの管理者グループ・アクセスが可能になります。
IAM拒否ポリシー機能の有効化
IAM拒否ポリシーを使用するには、最初にこの機能を有効にする必要があります。