IAM ― ユーザー・グループ・ロール・ポリシー

導入

「この社員にはS3だけ触らせたい」「このアプリにはDynamoDBへの書き込みだけ許可したい」——そんな細かい権限管理を実現するのがIAMです。

説明

AWS IAM（Identity and Access Management）は、「誰が（認証）」「何に対して（認可）」アクセスできるかを管理するサービスです。無料で利用でき、次の4つの要素で構成されます。

ユーザー（User） … 人やアプリケーションを表す個別のID。サインイン用のパスワードや、プログラムから使うアクセスキーを持てる。
グループ（Group） … ユーザーの集まり。「開発チーム」「経理チーム」のようにまとめておき、グループに権限を付与すれば所属ユーザー全員に一括で適用できる。
ロール（Role） … 特定の作業のために一時的に引き受ける権限のセット。パスワードを持たず、EC2 インスタンスやLambda関数、あるいは他のAWSアカウントのユーザーに「一時的に借りる」形で割り当てる。
ポリシー（Policy） … 「何を許可・拒否するか」をJSON形式で定義したドキュメント。ユーザー・グループ・ロールにアタッチ（関連付け）することで実際の権限になる。

flowchart LR
    U["IAMユーザー"] --> G["IAMグループ"]
    G --> P1["ポリシー"]
    U --> R["IAMロール<br/>(一時的な権限)"]
    R --> P2["ポリシー"]
    EC2["EC2インスタンス"] -.引き受け.-> R

ポリシーの実体は、次のようなJSONです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::sample-bucket/*"
    }
  ]
}

Effect（許可か拒否か）・Action（対象の操作）・Resource（対象のリソース）の3点セットで、「誰が」の部分はこのポリシーをアタッチされた側（ユーザーやロール）によって決まります。IAMの設計では、必要な権限だけを与える最小権限の原則（Principle of Least Privilege）が基本方針です。

具体例

10人の会社でIAMを設計する場面を追ってみましょう。

人 → ユーザーとグループ … 経理の3人を「経理グループ」にまとめ、請求関連の閲覧権限を持つポリシーをグループにアタッチ。1人入社したらグループに追加するだけで、同じ権限が即座に付く。個別に設定して回らなくてよい。
アプリ（モノ）→ ロール … 商品画像をS3から読むWebアプリをEC2で動かす。ここで「アプリ用のアクセスキーをコードに直書き」は厳禁（漏れたら終わり）。代わりにS3読み取りだけを許可するロールをEC2に持たせる。EC2はそのロールを一時的に引き受けて、鍵を一切コードに書かずにS3へアクセスできる。
最小権限 … このロールに与えるのは s3:GetObject（読み取り）だけ。書き込みや削除は付けない。もしアプリが乗っ取られても、できるのは画像を読むことだけで、被害が最小限に抑えられる。

「人はグループでまとめて、モノや一時作業はロールで鍵を持たせず、権限は必要な分だけ」——この3点がIAM設計の型です。

読んでみよう

「人にはユーザー・グループ、モノや一時的な作業にはロール」という使い分けと、権限の実体はポリシー（JSON）である、という点はセットで覚えておきましょう。