アクセス許可境界が制限する範囲

権限境界は、ユーザーまたはロールが持てる最大権限を設定する高度なIAM機能です。権限境界自体が権限を付与することはなく、アイデンティティベースのポリシーで実際に許可できる範囲に上限を設けます。権限管理の安全な委任を可能にするため、権限境界は試験で頻繁に扱われる重要なテーマです。

アイデンティティベースのポリシーは権限を付与し、権限境界は権限を制限します。実効権限は両者の積集合です。つまり、アイデンティティポリシーと権限境界の両方で許可されている場合にのみ、操作が許可されます。境界によってアイデンティティポリシーが付与する権限を縮小することはできますが、拡大することはできません。

ユーザーのアイデンティティポリシーでS3とEC2へのフルアクセスが許可されている一方、権限境界ではS3のみが許可されているとします。この場合、境界によって上限が設定されるため、ユーザーが実行できるのはS3の操作だけです。境界を削除すると、EC2の権限も再び有効になります。境界はひそかに最大権限を適用します。

この境界ポリシーでは、S3とCloudWatchの操作だけが許可されています。アイデンティティポリシーに何が記載されていても、ユーザーはこれらのサービスの範囲を超えることはできません。

主な用途は安全な委任です。開発者が自分でIAMロールを作成できるようにしたい一方で、過剰な権限を付与することは避けたいとします。開発者が作成するすべてのロールに権限境界を付けるようにすれば、アタッチされたポリシーがどれほど広範でも、そのロールが境界を超えることは決してないと保証できます。

権限境界とSCPはいずれも権限に上限を設けますが、適用範囲が異なります。権限境界は1人のユーザーまたは1つのロールに適用され、IAM内で設定します。SCPは組織内のアカウント全体に適用されます。試験では適切なツールの選択が問われます。アイデンティティ単位なら境界、アカウント全体ならSCPを使用します。

評価の流れでは、境界を含むすべての要素に対して明示的なDenyが優先されます。それ以外の場合、境界は上限として機能します。操作が許可されるには、アイデンティティポリシーと境界の両方でAllowが必要です。リソースベースのポリシーは、場合によっては境界とは独立してアクセスを許可できます。この点は覚えておく価値があります。

よくある誤解は、境界に操作を追加するとその操作が許可されるというものです。実際にはそうなりません。アイデンティティポリシーにその権限がなければ、境界で許可しても効果はありません。操作を成功させるには、アイデンティティポリシーで付与し、境界でも許可する必要があります。

試験で問われる重要な点として、権限境界はプリンシパルのアイデンティティベースのポリシーで実行できる操作を制限しますが、場合によってはリソースベースのポリシーによってそのプリンシパルに付与されたアクセスを制限しません。そのため、ロールの権限境界でS3だけに制限していても、キューポリシーを通じてそのロールにSQSへのアクセスを付与できる場合があります。この抜け道を考慮して設計してください。

委任されたプリンシパルが常に境界をアタッチするようにするには、作成するロールの境界ARNが特定の値と一致することをconditionで要求する権限ポリシーを記述します。このときiam:PermissionsBoundaryを使用します。これにより、開発者が保護策のないロールを作成することを防ぎ、委任の抜け道を塞げます。

権限境界は、1人のユーザーまたは1つのロールの最大権限に上限を設定します。実効アクセスは、境界とアイデンティティポリシーの積集合です。境界自体が権限を付与することはありません。主な目的は、IAMロール作成の安全な委任です。これはiam:PermissionsBoundary条件によって境界を必須にすることで適用できます。

権限境界の仕組みを確認しましょう。

権限境界は、1人のユーザーまたは1つのロールの最大権限を設定します。実効アクセスは、境界とアイデンティティポリシーの積集合です。境界自体が権限を付与することはなく、明示的なdenyが常に優先されます。主な目的は安全な委任であり、iam:PermissionsBoundary条件によって適用します。