SCPとIAM権限の組み合わせ方

組織内のアクセスは2 つの層で管理されます。AWS Organizations が設定するSCPの上限と、アカウント内で付与されるIAM 権限です。両者がどのように組み合わさるかを理解することは、ガバナンス分野で特に出題されやすい重要事項の 1 つです。最終的な結果は、両方が許可しているかどうかで決まります。

ルールは単純ですが厳格です。アクションが許可されるのは、適用されるすべての SCPと、アカウントの IAM ポリシーの両方で許可されている場合だけです。実効権限は、それらの共通部分です。対応する IAM の許可がなければ SCP だけでは何も付与されず、SCP によってブロックされた IAM の許可も何の効果も持ちません。

SCP がアクションを許可していても、IAM ポリシーによる許可がなければ、IAM の暗黙的な拒否によって結果は拒否になります。SCP はアクションを実行可能にしただけであり、実際に許可を付与するのは IAM です。SCP は付与ではなく上限であることを、多くの学習者が忘れてしまいます。

反対に、IAM ポリシーがアクションを許可していても、SCP が拒否していれば結果は拒否になります。SCP の拒否は、IAM がどれほど広範囲に許可していても、アカウントの権限に上限を設けます。これにより、組織はローカルの管理者が上書きできない厳格な制限を適用できます。

SCP と IAM ポリシーの両方がアクションを許可し、どこにも明示的な拒否がない場合に限り、リクエストは許可されます。この共通部分の考え方はアクセス権限の境界と同様であり、両方を同時に適用して、権限をさらに絞り込むこともできます。

完全に管理された環境では、複数の上限が積み重なります。SCP（アカウントレベル）、アクセス権限の境界（アイデンティティレベル）、セッションポリシー（セッションレベル）、そしてアイデンティティポリシー（付与）です。実効権限は、付与された権限とすべての上限の共通部分から、明示的な拒否を差し引いたものです。

IAM ポリシーが s3:* と ec2:* を付与し、アクセス権限の境界が s3:* のみを許可し、SCP が s3:GetObject のみを許可しているとします。実効権限は、3 つの層すべての共通部分であるs3:GetObjectだけです。それぞれの上限によって、権限がさらに削られていきます。

どの層であっても、ポリシー、SCP、アクセス権限の境界、セッション、アイデンティティ、リソースのいずれかに明示的な拒否があれば、アクションは直ちにブロックされます。どのような許可の組み合わせでも、明示的な拒否を上書きすることはできません。シナリオを分析するときは、最初に明示的な拒否がないか確認してください。見つかった場合、答えは拒否です。

リソースベースポリシーは、アイデンティティポリシーとは独立して同一アカウント内のアクセスを付与できます。ただし、SCP は引き続きプリンシパルのアカウントに上限を設けます。クロスアカウントアクセスでは、両方のアカウントの制御と、双方のポリシーが適用されます。共通部分のルールは広がりますが、基本的な考え方は同じです。適用されるすべての上限で許可されている必要があります。

組織内で予期せずアクセスが失敗した場合は、外側に向かって確認します。まずアイデンティティポリシーがアクションを許可していることを確認し、次にアクセス権限の境界、アカウントとすべての親 OU に適用されたSCP、セッションポリシーの順に確認します。最後に、すべての層で明示的な拒否を探します。アクションを含まない最初の上限、またはいずれかの拒否が原因です。

SCP と IAM は共通部分で組み合わされます。アクションには両方からの許可が必要であり、さらにアクセス権限の境界とセッションによる上限も適用され、どこにも明示的な拒否があってはなりません。SCP と境界は制限するだけであり、IAM ポリシーが権限を付与します。アクションを許可するには、すべての上限で許可され、かつ少なくとも 1 つの付与が存在する必要があります。

組み合わせのルールを確認しましょう。

SCP と IAM は共通部分で組み合わされます。アクションが許可されるのは、両方で許可され、さらにアクセス権限の境界とセッションポリシーによる上限も満たし、どこにも明示的な拒否がない場合だけです。SCP と境界は制限するだけであり、IAM ポリシーが権限を付与します。どの層にある明示的な拒否も、常にすべての許可に優先します。