IAM

IAM とは

IAM (Identity and Access Management) は、AWS のアクセス管理サービスで、「誰が (Principal)」「何のリソースに (Resource)」「どのような操作を (Action)」行えるかをポリシーで制御する。最小権限の原則に基づき、必要最小限のアクセス権のみを付与する。

主要な概念

主要な概念を以下にまとめる。

概念	説明
ユーザー	人間のアカウント (コンソールログイン)
ロール	サービスやアプリケーションが引き受ける権限
ポリシー	JSON で記述されたアクセス許可のルール
グループ	ユーザーをまとめてポリシーを適用

ポリシーの構造

ポリシーの構造の例を示す。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:GetItem", "dynamodb:PutItem"],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/users"
    }
  ]
}

フィールド	説明
Effect	Allow or Deny
Action	許可する API 操作
Resource	対象リソースの ARN
Condition	条件 (IP 制限、MFA 必須など)

ポリシーを書くときは評価の順番も押さえておきたい。IAM は既定で全て拒否 (暗黙の拒否) で、適用されるポリシーのどこかに Allow があって初めて通る。そして Deny は常に最優先で、他にどれだけ Allow を並べても覆せない。許可を足しても通らないときは、権限が足りないのではなく別の層 (アクセス許可の境界や組織のサービスコントロールポリシー) の拒否に当たっていることがある。

SAM のポリシーテンプレートで、最小権限のポリシーを簡潔に記述できる。

よくある間違い

IAM ポリシーの設定ミスは、セキュリティリスクに直結する。以下は実務で頻繁に見られる間違いとその対策である。

ワイルドカードの乱用

// ❌ 全リソースに全操作を許可
{ "Effect": "Allow", "Action": "*", "Resource": "*" }

// ✅ 必要な操作と対象リソースのみ
{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/*" }

アクセスキーの使用

❌ IAM ユーザーのアクセスキーを Lambda の環境変数に設定
✅ IAM ロールを Lambda に割り当て (自動的に一時的な認証情報を取得)

IAM ロール vs IAM ユーザー

IAM ロールと IAM ユーザーの違いを以下にまとめる。

観点	IAM ロール	IAM ユーザー
認証情報	一時的 (STS)	永続的 (アクセスキー)
用途	サービス、CI/CD	人間のコンソールアクセス
セキュリティ	高い (自動ローテーション)	低い (キー漏洩リスク)

OIDC による外部 ID プロバイダー連携

アクセスキーを外部の実行環境に置きたくない場面では、OIDC 連携が使える。GitHub Actions を例にすると、ワークフロー実行時に GitHub が発行する ID トークンを AWS 側に検証させ、成立したらロールを引き受けて一時的な認証情報を得る。長期のアクセスキーをシークレットへ保存しなくて済むのがこの方式の主眼である。

要になるのは信頼ポリシーの条件で、token.actions.githubusercontent.com:sub をどこまで絞るかで安全性が決まる。組織名だけで通してしまうと自分の管理外のリポジトリからでもロールを引き受けられるため、リポジトリとブランチ (または環境) まで含めて固定する。IAM 側も信頼ポリシーの作成・更新時にこの条件キーが存在し、値がワイルドカードだけになっていないかを検査するので、条件を書き忘れたポリシーはそもそも保存できない。

IAM の背景や設計思想は関連書籍に詳しい。