IAMと最小権限 — ユーザー・グループ・ロール・ポリシーを設計する - AWS SAA-C03 合格と実務のためのAWS設計入門

学習者

IAMユーザー、ロール、ポリシーが全部「権限」っぽく見えて、何をどう使い分けるのか混乱します。

AWSのセキュリティ設計は、ほぼ必ず IAM（Identity and Access Management） から始まります。誰が、どのAWSリソースに、どの操作をできるのかを決める仕組みです。

SAA-C03では、IAMユーザー、IAMグループ、IAMロール、IAMポリシー、MFA、ルートユーザーの扱いが頻出です。

IAMの基本構成

実務では、長期的なアクセスキーを持つIAMユーザーより、IAMロールと一時認証情報を優先します。EC2からS3へアクセスするなら、アクセスキーをサーバーに置くのではなく、EC2インスタンスプロファイルでIAMロールを付与します。

最小権限とは、「必要な操作だけを、必要なリソースにだけ許可する」ことです。

悪い例:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

json

良い方向性:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": ["arn:aws:s3:::example-bucket/reports/*"]
}

json

実務では最初から完璧な最小権限を書くのは難しいため、AWS IAM Access AnalyzerやCloudTrailの履歴を使って権限を絞り込むことがあります。

SAA-C03では、次のような要件が出たらIAMロールを疑います。

アクセスキーをアプリケーションに埋め込む構成は避けます。漏洩時の影響が大きく、ローテーションも難しくなるためです。

IAMはAWS設計の土台です。

次の章では、複数アカウント、IAM Identity Center、Organizations、SCPを使った組織単位のアクセス管理を扱います。