SAAセキュアなアーキテクチャの設計
ある企業のAWSアカウントには数十のプロジェクトチームが存在し、各ユーザーには自分のチームのタグが付いたEC2インスタンスのみを起動・停止・管理させたいと考えています。チームは今後も増え続ける見込みで、チームが増えるたびに新しいIAMポリシーやグループを作成・保守する運用は避けたいと考えています。最も拡張性が高く管理負荷の低い方法はどれですか。
AABACを採用し、IAMポリシーの条件で aws:PrincipalTag と ec2:ResourceTag を比較してタグ一致時のみ操作を許可する
✓ 正解
ABACはプリンシパルタグとリソースタグを条件比較し、一致時のみ許可する。単一ポリシーで一致ロジックを表現でき、チーム増加時もタグ付与だけで自動対応できるため、最も拡張性が高く管理負荷が低い。
BチームごとにIAMポリシーを作成し、対象EC2インスタンスのARNを明示的に列挙して各メンバーに付与する
ARNを明示列挙する方式は、チームやインスタンスが増えるたびにポリシーの編集が必要となる。スケールせず保守負荷が高いため、増え続けるチームを扱う要件に適さない。
CチームごとにIAMグループを作成し、リソース単位の許可を列挙したポリシーをアタッチして管理する
チームごとにグループとポリシーを作成・保守する方式は、チーム数の増加に比例して管理対象が増え煩雑になる。ポリシー追加を避けたいという要件に反するため不適切である。
D全ユーザーにEC2のフルアクセスを付与し、CloudTrailのログを監視して権限逸脱を事後的に検知する
全ユーザーへのフルアクセス付与は最小権限の原則に反し、事後のログ監視では未承認操作を未然に防げない。アクセス制御の要件を満たさずセキュリティ上も不適切である。
解説
ABAC（属性ベースアクセス制御）は、プリンシパルのタグ（aws:PrincipalTag）とリソースのタグ（ec2:ResourceTag等）を条件で比較し、属性が一致する場合にのみ操作を許可する設計です。
単一のポリシーでタグの一致ロジックを定義できるため、チームが増えてもポリシーやグループを追加せず、ユーザーとリソースに正しいタグを付与するだけで自動的にスケールします。
選択肢Bは、チーム追加やインスタンス追加のたびにARN列挙のポリシー更新が必要で運用負荷が高い。
選択肢Cも、チームごとにグループとポリシーを作成・保守する必要があり、増加に伴い管理が煩雑になる。
選択肢Dは最小権限の原則に反し、事後検知では未承認操作を防止できずセキュリティ要件を満たさない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →