AWS IAM

IAMとは

IAM（Identity and Access Management）は、AWSリソースへのアクセスを安全に管理するためのサービス。「誰が」「何に」「何をできるか」を制御する、AWSセキュリティの根幹を担うサービス。

IAMは無料で利用できる。IAM自体に料金は発生せず、IAMで制御されたAWSリソースの利用に対してのみ課金される。

なぜIAMが重要か

IAMの基本構成要素

全体像

ルートユーザー

AWSアカウント作成時に生成される、全ての権限を持つユーザー。メールアドレスとパスワードでログインする。

ルートユーザーのルール:

• 日常業務では絶対に使わない
• MFA（多要素認証）を必ず有効にする
• アクセスキーを作成しない
• ルートユーザーが必要な操作（アカウント設定変更、請求情報のアクセス設定等）のみで使用

IAMユーザー

AWSを利用する個人やアプリケーションを表すエンティティ。ユーザー名とパスワード（コンソールアクセス用）、またはアクセスキー（API/CLIアクセス用）で認証する。

推奨事項: IAMユーザーの代わりにIAM Identity Center（旧AWS SSO）を使い、フェデレーション認証を導入する。長期的な認証情報（パスワードやアクセスキー）の管理が不要になる。

IAMグループ

IAMユーザーの集合。グループにポリシーをアタッチすると、所属する全ユーザーにそのポリシーが適用される。

開発者グループ → 開発者ポリシー
  ├── ユーザーA
  ├── ユーザーB
  └── ユーザーC

管理者グループ → 管理者ポリシー
  ├── ユーザーD
  └── ユーザーE

• ユーザーは複数のグループに所属可能
• グループのネスト（グループの中にグループ）は不可
• ユーザーに直接ポリシーをアタッチするのではなく、グループを経由するのがベストプラクティス

IAMロール

AWSサービスや他のAWSアカウント、フェデレーションユーザーが一時的に引き受ける（Assume）ことで権限を取得するエンティティ。ロール自体は認証情報を持たない。

ロールを使うべき場面:

• EC2上のアプリからAWSサービスにアクセスする場合（アクセスキーを使わない）
• Lambda関数からDynamoDBにアクセスする場合
• 別アカウントのリソースにアクセスする場合

IAMロールの深掘り: AssumeRoleと信頼ポリシー

IAMロールには2つのポリシーがアタッチされる。この2つの役割を正確に理解することが、IAMロールを使いこなす鍵。

信頼ポリシー（Trust Policy）: 「誰が」このロールを引き受けられるかを定義するリソースベースポリシー。Principal要素で引き受け元を指定する。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Principalの種類:

権限ポリシー（Permissions Policy）: ロールを引き受けた後に「何ができるか」を定義する。通常のアイデンティティベースポリシーと同じ構造。

AssumeRoleの流れ（詳細）

ロールチェイニング: あるロールを引き受けた後、そのロールからさらに別のロールを引き受けることが可能。ただし、チェイニングされたセッションの最大有効期限は1時間に制限される。

IAMポリシー

ポリシーの種類

推奨: カスタマー管理ポリシーを使用する。再利用性が高く、変更管理がしやすい。インラインポリシーは特殊なケースを除き使用しない。

管理ポリシー vs インラインポリシー（詳細比較）

インラインポリシーを使う正当な場面:

• ポリシーとエンティティを厳密に1対1で紐づけたい場合（エンティティ削除時にポリシーも確実に削除される）
• Permissions Boundaryと組み合わせて、特定のロールだけに適用する例外的な制限を設ける場合

カスタマー管理ポリシーのバージョン管理:

ポリシー: MyAppS3Policy
├── v1 (作成時): s3:GetObject のみ
├── v2: s3:GetObject + s3:PutObject 追加
├── v3: s3:DeleteObject 追加
├── v4: Condition追加（IP制限）
└── v5 (現行): Resource を特定バケットに限定  ← デフォルトバージョン

最大5バージョンまで保持可能。ロールバックが必要な場合は過去のバージョンをデフォルトに変更するだけで済む。

アイデンティティベースポリシー vs リソースベースポリシー

ポリシーの構造（JSON）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

ポリシー要素の詳細

ポリシーの評価ロジック

重要な原則:

1. デフォルトは全て拒否（暗黙的Deny）
2. 明示的なAllowがあれば許可
3. 明示的なDenyは全てに優先する（Allow + Deny → Deny）

条件（Condition）の活用

{
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "ap-northeast-1"
    },
    "Bool": {
      "aws:MultiFactorAuthPresent": "true"
    },
    "DateGreaterThan": {
      "aws:CurrentTime": "2026-01-01T00:00:00Z"
    },
    "IpAddress": {
      "aws:SourceIp": ["203.0.113.0/24", "198.51.100.0/24"]
    }
  }
}

最小権限の原則

原則

「必要な権限だけを、必要なリソースに、必要な期間だけ付与する。」

これはIAMの最も重要な原則であり、セキュリティインシデントの被害を最小限に抑えるための基本。

実践方法

IAM Access Analyzer

IAM Access Analyzerは、外部エンティティと共有されているリソースを検出し、ポリシーの検証を行うツール。

主な機能:

• 外部アクセス分析: S3バケット、IAMロール、KMSキーなどが外部と共有されていないか検出
• 未使用アクセス分析: 未使用のロール、アクセスキー、パスワード、権限を検出
• ポリシー生成: CloudTrailのアクティビティログから最小権限のポリシーを自動生成
• ポリシー検証: ポリシーのベストプラクティス違反をチェック

悪い例と良い例

悪い例（過剰な権限）:

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

良い例（最小権限）:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::my-app-uploads/*"
}

AWS STS（Security Token Service）

STSは、一時的な認証情報を発行するサービス。IAMロールを引き受ける（AssumeRole）際に使用される。

一時認証情報のメリット

STSの主要APIアクション

AssumeRole

import { STSClient, AssumeRoleCommand } from '@aws-sdk/client-sts';

const stsClient = new STSClient({ region: 'ap-northeast-1' });

const response = await stsClient.send(
  new AssumeRoleCommand({
    RoleArn: 'arn:aws:iam::987654321098:role/CrossAccountRole',
    RoleSessionName: 'my-session',
    DurationSeconds: 3600,
  })
);

// 取得した一時認証情報を使って他のAWSサービスにアクセス
const { AccessKeyId, SecretAccessKey, SessionToken } = response.Credentials;

GetSessionToken（MFA認証付き一時認証情報の取得）

IAMユーザーが自身のMFAデバイスで認証し、一時認証情報を取得するために使用する。MFA必須のポリシーと組み合わせることで、重要な操作にMFAを強制できる。

# AWS CLIでMFA付き一時認証情報を取得
aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/my-mfa-device \
  --token-code 123456 \
  --duration-seconds 3600

AssumeRole vs GetSessionToken:

フェデレーション

外部のIDプロバイダー（IdP）で認証されたユーザーに、AWSの一時認証情報を付与する仕組み。

GitHub Actions での OIDC連携例

# .github/workflows/deploy.yml
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: ap-northeast-1

      - run: aws s3 sync ./dist s3://my-bucket/

クロスアカウントアクセス

複数のAWSアカウント間でリソースにアクセスする仕組み。

クロスアカウントロールの設定

本番アカウント側の信頼ポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "StringEquals": {
          "sts:ExternalId": "unique-external-id"
        }
      }
    }
  ]
}

開発アカウント側のポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::999999999999:role/ProductionReadOnlyRole"
    }
  ]
}

サービスロール

AWSサービスがユーザーに代わって他のAWSサービスにアクセスするためのロール。

主なサービスロール

Lambda/EC2/ECSからのロール利用パターン

各サービスがロールを利用する仕組みは微妙に異なる。以下に実務でよく使うパターンをまとめる。

EC2: インスタンスプロファイル

EC2インスタンスにIAMロールを割り当てるには「インスタンスプロファイル」を使用する。EC2上のアプリケーションはインスタンスメタデータサービス（IMDS）から自動的に一時認証情報を取得する。

// 信頼ポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

重要: EC2上にアクセスキーをハードコードしてはならない。必ずインスタンスプロファイル経由でロールを使用する。IMDSv2（トークン必須）を有効にしてセキュリティを強化する。

Lambda: 実行ロール

Lambda関数には必ず1つの実行ロールが必要。関数実行時にAWSが自動的にAssumeRoleを行い、一時認証情報を環境変数にセットする。

// 信頼ポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lambda.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

権限ポリシー（例: DynamoDB + CloudWatch Logs）:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789:table/Orders"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789:*"
    }
  ]
}

ECS: タスクロールとタスク実行ロール

ECSでは2種類のロールを区別する必要がある。これはよく混同されるポイント。

// タスク実行ロールの権限ポリシー（典型例）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789:log-group:/ecs/my-app:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789:secret:my-app/*"
    }
  ]
}

Permissions Boundary

Permissions Boundary（権限の境界）は、IAMユーザーやロールに設定できる権限の上限。管理者が「この範囲内で自由にポリシーを作成してよい」という枠組みを定義できる。

仕組み

有効な権限 = アイデンティティベースポリシー ∩ Permissions Boundary

両方で許可されている場合のみアクセスが許可される。

ユースケース

開発者にIAMロールの作成を許可しつつ、権限エスカレーション（自分より強い権限のロールを作成すること）を防ぐ。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*",
        "sqs:*",
        "sns:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

AWS Organizations と SCP

SCP（Service Control Policy）

AWS Organizationsのメンバーアカウントに適用する権限の上限。Permissions Boundaryがユーザー/ロール単位なのに対し、SCPはアカウント単位。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonTokyoRegion",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
        }
      }
    }
  ]
}

この例では、東京リージョンとバージニア北部（グローバルサービス用）以外のリージョンでの操作を全て拒否する。

実務でのIAMベストプラクティス一覧

認証

認可

監査・運用

マルチアカウント

MFA（多要素認証）

MFAとは

MFA（Multi-Factor Authentication）は、パスワードに加えて追加の認証要素を求める仕組みである。IAMユーザーやルートアカウントに対して設定でき、不正アクセスのリスクを大幅に低減する。

MFAの種類

MFAの強制

IAMポリシーで「MFAを有効にしていないユーザーの操作を拒否」するパターンが一般的。

{
  "Sid": "DenyAllExceptMFAManagement",
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateVirtualMFADevice",
    "iam:EnableMFADevice",
    "iam:GetUser",
    "iam:ListMFADevices",
    "sts:GetSessionToken"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

ベストプラクティス: ルートアカウントには必ずMFAを設定する。IAMユーザーにもMFAを必須とするポリシーを適用する。

IAM Identity Center（旧AWS SSO）

IAM Identity Centerとは

IAM Identity Center（旧AWS Single Sign-On）は、複数のAWSアカウントやビジネスアプリケーションへのシングルサインオンを提供するサービス。AWS Organizationsと統合して、組織全体のアクセス管理を一元化する。

IAMユーザー vs IAM Identity Center

現在のベストプラクティス: 人間のユーザーにはIAM Identity Centerを使い、IAMユーザーの作成は最小限にする。

よくあるIAMのミスと対策

1. ルートアカウントの日常使用

ミス: ルートアカウントで日常の開発作業を行う。

対策: ルートアカウントにはMFAを設定し、アクセスキーを作成しない。日常業務はIAMユーザーまたはIAM Identity Center経由で行う。

2. AdministratorAccessの乱用

ミス: 全員にAdministratorAccessポリシーを付与する。

対策: 最小権限の原則に従い、業務に必要な権限だけを付与する。まずReadOnlyAccessから始め、必要に応じて権限を追加する。

3. アクセスキーの放置

ミス: 退職者や使われなくなったアクセスキーがアクティブなまま残っている。

対策: IAM Access Analyzerで未使用のアクセスキーを定期的に確認する。90日以上未使用のキーは無効化する。

4. ポリシーのResource: "*"

ミス: すべてのリソースに対して権限を付与する "Resource": "*" を安易に使う。

対策: 可能な限りリソースARNを具体的に指定する。特にS3バケットやDynamoDBテーブルは名前で限定する。

5. インラインポリシーの多用

ミス: 管理ポリシーを使わず、各ユーザー/ロールにインラインポリシーを直接記述する。

対策: 管理ポリシー（カスタマーマネージド）を作成して再利用する。インラインポリシーは例外的なケースのみ。

6. クロスアカウントで外部IDを使わない

ミス: サードパーティにロールを委任する際、外部IDなしで信頼ポリシーを設定する。

対策: 外部IDをConditionに含めることで、混乱した代理（Confused Deputy）問題を防ぐ。

参考文献

公式ドキュメント

• AWS IAM 公式ドキュメント
• IAM ベストプラクティス
• IAM ポリシーリファレンス
• IAM ポリシー評価ロジック
• AWS STS ドキュメント
• IAM Access Analyzer
• AWS IAM Identity Center
• AWS Organizations SCP
• Permissions Boundary
• IAMロールの信頼ポリシー
• EC2 インスタンスプロファイル
• ECS タスクロール
• Lambda 実行ロール

AWS公式ブログ・ガイド

• IAM ポリシータイプの使い分け
• 条件キーの一覧（グローバル）
• 混乱した代理問題の防止
• MFA を使用した安全なAPIアクセス
• AWS Well-Architected Framework - Security Pillar