IAM（Identity and Access Management）
AWSのアクセス管理の基盤であるIAMについて学びます。ユーザー、グループ、ロール、ポリシーの概念と、セキュアなAWS環境を構築するためのベストプラクティスを理解します。
所要時間
約45分
学べること
- IAMの基本概念（認証と認可の違い）
- IAMユーザー、グループの作成と管理
- IAMロールの仕組みと活用パターン
- IAMポリシーのJSON 構造と評価ロジック
- MFA（多要素認証）の設定
- STS（Security Token Service）による一時的認証情報
- IAMのベストプラクティス
前提知識
- AWS基礎の内容
- 認証と認可の基本概念
目次
- IAMの概要
- IAMユーザーとグループ
- IAMロール
- IAMポリシー
- ポリシーの評価ロジック
- MFA（多要素認証）
- STS（Security Token Service）
- IAMのベストプラクティス
- IDサービスでの活用
1. IAMの概要
IAMとは
IAM（Identity and Access Management）は、AWSリソースへのアクセスを安全に管理するためのサービスです。「誰が」「何に対して」「何をできるか」を制御します。
┌─────────────────────────────────────────────────────────────┐
│ IAMの役割 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 認証（Authentication） 認可（Authorization） │
│ ┌──────────────────────┐ ┌──────────────────────┐ │
│ │ あなたは誰ですか？ │ │ 何をしていいですか？ │ │
│ │ │ │ │ │
│ │ ・ユーザー名/PW │ ──→ │ ・S3読み取りOK │ │
│ │ ・アクセスキー │ │ ・EC2起動NG │ │
│ │ ・MFAトークン │ │ ・RDS接続OK │ │
│ └──────────────────────┘ └──────────────────────┘ │
│ │
│ IAMは「認証」と「認可」の両方を担う │
│ 追加料金なし（AWSアカウントに無料で付属） │
│ │
└─────────────────────────────────────────────────────────────┘
IAMの主要コンポーネント
| コンポーネント | 説明 | 例 |
|---|---|---|
| ユーザー | AWSを操作する個人やアプリケーション | 開発者、CI/CDパイプライン |
| グループ | ユーザーの集合（権限をまとめて管理） | 開発者グループ、管理者グループ |
| ロール | 一時的に引き受ける権限セット | EC2用ロール、Lambda用ロール |
| ポリシー | 権限を定義するJSONドキュメント | S3読み取り許可、EC2全権限 |
┌──────────────── ─────────────────────────────────────────────┐
│ IAMの構成要素 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ポリシー（何ができるか） │
│ ┌─────────────┐ │
│ │ S3ReadOnly │─────┐ │
│ └─────────────┘ │ │
│ ┌─────────────┐ ├──→ グループ ──→ ユーザー │
│ │ EC2FullAccess│─────┘ ┌──────┐ ┌──────┐ │
│ └─────────────┘ │開発者 │─ ──│田中 │ │
│ ┌─────────────┐ │グループ│───│佐藤 │ │
│ │ RDSConnect │───────────│ │ └──────┘ │
│ └─────────────┘ └──────┘ │
│ │
│ ポリシー ──→ ロール │
│ ┌─────────────┐ ┌──────────────┐ │
│ │ SecretsRead │───│ AppServerRole│ ← EC2/ECSが │
│ │ KMSDecrypt │───│ │ 引き受ける │
│ └─────────────┘ └──────────────┘ │
│ │
└─────────── ──────────────────────────────────────────────────┘
2. IAMユーザーとグループ
IAMユーザー
IAMユーザーは、AWSを操作するエンティティです。人間のユーザーだけでなく、アプリケーションやサービスアカウントとしても使用されます。
┌───────────────────────────── ────────────────────────────────┐
│ IAMユーザーの認証方法 │
├─────────────────────────────────────────────────────────────┤
│ │
│ コンソールアクセス（人間向け） │
│ ┌──────────────────────────────────────────┐ │
│ │ ユーザー名 + パスワード + MFA │ │
│ │ → マネジメントコンソールにログイン │ │
│ └──────────────────────────────────────────┘ │
│ │
│ プログラマティックアクセス（プログラム向け） │
│ ┌──────────────────────────────────────────┐ │
│ │ アクセスキーID + シークレットアクセスキー │ │
│ │ → CLI / SDK から操作 │ │
│ └──────────────────────────────────────────┘ │
│ │
│ 注意: アクセスキーは漏洩リスクがあるため、 │
│ 可能な限りIAMロール（一時的認証情報）を使うべき │
│ │
└─────────────────────────────────────────────────────────────┘
IAMユーザーの作成（CLI）
# ユーザー作成
aws iam create-user --user-name developer-tanaka
# グループへの追加
aws iam add-user-to-group --user-name developer-tanaka --group-name developers
# コンソールアクセス用パスワード設定
aws iam create-login-profile --user-name developer-tanaka \
--password 'TempPassword123!' --password-reset-required
# MFAデバイスの有効化（仮想MFA）
aws iam create-virtual-mfa-device \
--virtual-mfa-device-name developer-tanaka-mfa \
--outfile /tmp/qrcode.png \
--bootstrap-method QRCodePNG
IAMグループ
グループは、ユーザーに権限を効率的に割り当てるための仕組みです。
┌─────────────────────────────────────────────────────────────┐
│ グループ設計の例 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Admins グループ │
│ ├── ポリシー: AdministratorAccess │
│ └── メンバー: admin-user │
│ │
│ Developers グループ │
│ ├── ポリシー: PowerUserAccess（IAM以外の全権限） │
│ ├── ポリシー: IAMReadOnlyAccess │
│ ├── メンバー: dev-tanaka │
│ └── メンバー: dev-sato │
│ │
│ ReadOnly グループ │
│ ├── ポリシー: ReadOnlyAccess │
│ └── メンバー: auditor-suzuki │
│ │
│ ベストプラクティス: │
│ ・ユーザーに直接ポリシーを付けない（グループ経由で管理） │
│ ・グループは職務や役割に基づいて設計する │
│ ・1人のユーザーは複数のグループに所属できる │
│ │
└─────────────────────────────────────────────────────────────┘
3. IAMロール
IAMロールとは
IAMロールは、特定のユーザーに紐づかない権限セットです。必要なときに「引き受ける（Assume）」ことで、一時的な認証情報を取得します。
┌─────────────────────────────────────────────────────────────┐
│ IAMユーザー vs IAMロール │
├─────────────────────────────────────────────────────────────┤
│ │
│ IAMユーザー IAMロール │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ 長期的な認証情報 │ │ 一時的な認証情報 │ │
│ │ (パスワード, │ │ (STS経由で発行) │ │
│ │ アクセスキー) │ │ │ │
│ │ │ │ 有効期限あり │ │
│ │ 特定の人/物に │ │ (15分〜12時間) │ │
│ │ 紐づく │ │ │ │
│ │ │ │ 誰でも引き受け │ │
│ │ 漏洩リスクが │ │ 可能（信頼 │ │
│ │ ある │ │ ポリシーで制御） │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
│ 原則: 可能な限りロールを使い、長期的な認証情報を避ける │
│ │
└─────────────────────────────────────────────────────────────┘
ロールの主な利用パターン
AWSサービス用ロール
EC2やECS、Lambdaなどのサービスが他のAWSリソースにアクセスするために使用します。
┌─────────────────────────────────────────────────────────────┐
│ EC2インスタンスプロファイル │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────────────┐ ┌──────────┐ │
│ │ EC2 │ ──→ │ インスタンス │ ──→│ S3 │ │
│ │ instance │ │ プロファイル │ │ Bucket │ │
│ │ │ │ (IAMロール) │ │ │ │
│ └──────────┘ └──────────────────┘ └──────────┘ │
│ │
│ EC2上のアプリケーションは、アクセスキーを埋め込まなくても │
│ 自動的にロールの権限でAWSリソースにアクセスできる │
│ │
│ ※ ECSタスクロール、Lambdaの実行ロールも同じ仕組み │
│ │
└─────────────────────────────────────────────────────────────┘
クロスアカウントロール
異なるAWSアカウント間でリソースにアクセスする場合に使用します。
┌─────────────────────────────────────────────────────────────┐
│ クロスアカウントアクセス │
├─────────────────────────────────────────────────────────────┤
│ │
│ アカウントA（開発） アカウントB（本番） │
│ ┌──────────────────┐ ┌──────────────────────┐ │
│ │ │ │ │ │
│ │ 開発者 │ │ CrossAccountRole │ │
│ │ (IAMユーザー) │──────→│ 信頼ポリシー: │ │
│ │ │ STS │ 「アカウントAを │ │
│ │ │ Assume│ 信頼する」 │ │
│ │ │ Role │ │ │
│ └──────────────────┘ │ 権限ポリシー: │ │
│ │ 「S3読み取りのみ」 │ │
│ └──────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
ロールの信頼ポリシー（Trust Policy）
ロールを「誰が引き受けられるか」を定義するポリシーです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ecs-tasks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
この例では、ECSタスクがこのロールを引き受けられることを定義しています。
4. IAMポリシー
ポリシーの構造
IAMポリシーは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"
}
}
}
]
}
ポリシー要素の詳細
| 要素 | 必須 | 説明 |
|---|---|---|
| Version | はい | ポリシー言語バージョン（"2012-10-17"固定） |
| Statement | はい | 権限ルールの配列 |
| Sid | いいえ | ステートメントの識別子（任意の文字列） |
| Effect | はい | Allow（許可）または Deny（拒否） |
| Action | はい | 対象のAWSアクション（例: s3:GetObject） |
| Resource | はい | 対象のリソースARN |
| Condition | いいえ | 条件（IP制限、MFA必須、時間制限等） |
ポリシーの種類
┌─────────────────────────────────────────────────────────────┐
│ ポリシーの種類 │
├─────────────────────────────────────────────────────────────┤
│ │
│ AWS管理ポリシー │
│ ┌──────────────────────────────────────────┐ │
│ │ AWSが作成・管理する汎用ポリシー │ │
│ │ 例: AmazonS3ReadOnlyAccess │ │
│ │ 例: AdministratorAccess │ │
│ │ → すぐに使えて便利だが、粒度が粗い場合も│ │
│ └──────────────────────────────────────────┘ │
│ │
│ カスタマー管理ポリシー │
│ ┌──────────────────────────────────────────┐ │
│ │ 自分で作成するポリシー │ │
│ │ 例: 特定S3バケットの特定プレフィックスのみ│ │
│ │ → 最小権限の原則に沿った細かい制御 │ │
│ │ → 複数のユーザー/ロールで再利用可能 │ │
│ └──────────────────────────────────────────┘ │
│ │
│ インラインポリシー │
│ ┌──────────────────────────────────────────┐ │
│ │ 特定のユーザー/ロール/グループに直接埋め込む│ │
│ │ → 他のエンティティと共有不可 │ │
│ │ → エンティティ削除時に一緒に削除される │ │
│ │ → 管理が煩雑になるため、通常は非推奨 │ │
│ └──────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
実用的なポリシー例
特定S3バケットの読み書き
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3BucketAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::idp-config-bucket/*"
},
{
"Sid": "AllowListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::idp-config-bucket"
}
]
}
Secrets ManagerとKMSへのアクセス
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSecretsAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:idp/*"
},
{
"Sid": "AllowKMSDecrypt",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/key-id"
}
]
}
5. ポリシーの評価ロジック
AWSがリクエストを受け取ったとき、IAMポリシーは以下のロジックで評価されます。
┌─────────────────────────────────────────────────────────────┐
│ IAMポリシー評価フロー │
├─────────────────────────────────────────────────────────────┤
│ │
│ リクエスト受信 │
│ │ │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ デフォルト: 暗黙的なDeny │ │
│ │ (何も許可されていない) │ │
│ └────────────┬─────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────┐ はい ┌──────────┐ │
│ │ 明示的なDenyがあるか？ │───────────→│ 拒否 │ │
│ └────────────┬─────────────┘ └──────────┘ │
│ │ いいえ │
│ ▼ │
│ ┌──────────────────────────┐ はい ┌──────────┐ │
│ │ SCPでAllowされているか？ │──いいえ──→│ 拒否 │ │
│ │ (Organizations使用時) │ └──────────┘ │
│ └────────────┬─────────────┘ │
│ │ はい │
│ ▼ │
│ ┌──────────────────────────┐ はい ┌──────────┐ │
│ │ 明示的なAllowがあるか？ │───────────→│ 許可 │ │
│ └────────────┬─────────────┘ └──────────┘ │
│ │ いいえ │
│ ▼ │
│ ┌──────────┐ │
│ │ 拒否 │ ← 暗黙的なDeny │
│ └──────────┘ │
│ │
│ 重要: 明示的なDeny > 明示的なAllow > 暗黙的なDeny │
│ │
└─────────────────────────────────────────────────────────────┘
評価の優先順位
| 優先度 | 種類 | 結果 |
|---|---|---|
| 1（最高） | 明示的なDeny | 無条件で拒否（他のAllowで上書き不可） |
| 2 | 明示的なAllow | 許可される |
| 3（最低） | 暗黙的なDeny | Allowがなければデフォルトで拒否 |
複数ポリシーの結合
ユーザーに複数のポリシーが付与されている場合、全てのポリシーを統合して評価されます。
┌─────────────────────────────────────────────────────────────┐
│ 複数ポリシーの評価例 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ユーザー: dev-tanaka │
│ │
│ グループポリシー: インラインポリシー: │
│ ┌──────────────────┐ ┌──────────────────────┐ │
│ │ Effect: Allow │ │ Effect: Deny │ │
│ │ Action: s3:* │ │ Action: s3:Delete* │ │
│ │ Resource: * │ │ Resource: * │ │
│ └──────────────────┘ └──────────────────────┘ │
│ │
│ 結果: │
│ ・s3:GetObject → 許可（Allowあり、Denyなし） │
│ ・s3:PutObject → 許可（Allowあり、Denyなし） │
│ ・s3:DeleteObject → 拒否（明示的Denyが優先） │
│ │
└─────────────────────────────────────────────────────────────┘
6. MFA（多要素認証）
MFAとは
MFAは「知っているもの」（パスワード）に加えて「持っているもの」（デバイス）で認証を強化する仕組みです。
MFAデバイスの種類
| 種類 | 説明 | 推奨度 |
|---|---|---|
| 仮想MFAデバイス | スマートフォンアプリ（Google Authenticator等） | 一般ユーザー向け |
| ハードウェアMFAキー | FIDO2セキュリティキー（YubiKey等） | セキュリティ重視の環境 |
| ハードウェアTOTPトークン | 専用のワンタイムパスワード生成器 | 厳格なコンプライアンス要件 |
MFAを強制するポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllExceptMFASetup",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
このポリシーは「MFAなしではMFAの設定操作以外を拒否」します。ユーザーはまずMFAを有効化しないと何もできません。
7. STS（Security Token Service）
STSとは
STS（Security Token Service）は、一時的なセキュリティ認証情報を発行するサービスです。
┌─────────────────────────────────────────────────────────────┐
│ STSの仕組み │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ AssumeRole ┌──────────┐ │
│ │ 呼び出し │ ────リクエスト──→ │ STS │ │
│ │ 元 │ │ │ │
│ │ │ ←──一時認証情報── │ │ │
│ └──────────┘ └──────────┘ │
│ │ │
│ │ 一時認証情報を使って │
│ │ AWSリソースにアクセス │
│ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ 一時認証情報の内容: │ │
│ │ ・AccessKeyId (一時的なキー) │ │
│ │ ・SecretAccessKey (一時的なシークレット) │ │
│ │ ・SessionToken (セッショントークン) │ │
│ │ ・Expiration (有効期限) │ │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
主なSTS API
| API | 用途 |
|---|---|
| AssumeRole | IAMロールを引き受けて一時認証情報を取得 |
| AssumeRoleWithSAML | SAML認証後にロールを引き受ける |
| AssumeRoleWithWebIdentity | OIDC認証後にロールを引き受ける |
| GetSessionToken | MFA認証付きの一時認証情報を取得 |
| GetCallerIdentity | 現在の認証情報の身元を確認 |
AssumeRoleの実行例
# ロールを引き受ける
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/ProductionReadRole \
--role-session-name debug-session
# 返却される一時認証情報
# {
# "Credentials": {
# "AccessKeyId": "ASIAXXXXXXXXXXXXXXXX",
# "SecretAccessKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
# "SessionToken": "FwoGZXIvY...(長い文字列)",
# "Expiration": "2024-01-15T10:30:00Z"
# }
# }
# 一時認証情報を環境変数に設定して使用
export AWS_ACCESS_KEY_ID="ASIAXXXXXXXXXXXXXXXX"
export AWS_SECRET_ACCESS_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export AWS_SESSION_TOKEN="FwoGZXIvY..."
# この認証情報でAWSリソースにアクセス
aws s3 ls s3://production-bucket/
# 現在の認証情報を確認
aws sts get-caller-identity
# → AssumeRoleしたロールの情報が表示される
8. IAMのベストプラクティス
基本原則
┌─────────────────────────────────────────────────────────────┐
│ IAMベストプラクティス │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. ルートアカウントを保護する │
│ ├── ルートのアクセスキーを削除する │
│ ├── MFAを有効にする │
│ └── 日常作業にルートを使わない │
│ │
│ 2. 最小権限の原則 │
│ ├── 必要最小限の権限のみを付与する │
│ ├── ワイルドカード（*）の使用を最小限にする │
│ └── 定期的に権限を見直す │
│ │
│ 3. IAMロールを活用する │
│ ├── AWSサービスにはロールを使う │
│ ├── 長期的なアクセスキーを避ける │
│ └── クロスアカウントはロール経由で │
│ │
│ 4. グループで権限を管理する │
│ ├── 個別ユーザーへの直接ポリシー付与を避ける │
│ └── 職務に基づいたグループを設計する │
│ │
│ 5. 監査と監視 │
│ ├── CloudTrailでAPI操作を記録する │
│ ├── IAM Access Analyzerで外部アクセスを検出する │
│ └── 未使用の認証情報を定期的に削除する │
│ │
└─────────────────────────────────────────────────────────────┘
アクセスキーの管理
| プラクティス | 説明 |
|---|---|
| ロール優先 | EC2/ECS/Lambdaではアクセスキーではなくロールを使用 |
| 定期ローテー ション | アクセスキーを使う場合は定期的に更新 |
| 漏洩検知 | git-secretsなどで誤ったコミットを防止 |
| 環境変数 | コードにアクセスキーをハードコードしない |
IAM Access Analyzer
IAM Access Analyzerは、リソースポリシーを分析して外部からのアクセスを検出するサービスです。
# Access Analyzerの作成
aws accessanalyzer create-analyzer \
--analyzer-name my-analyzer \
--type ACCOUNT
# 検出結果の確認
aws accessanalyzer list-findings \
--analyzer-arn arn:aws:access-analyzer:ap-northeast-1:123456789012:analyzer/my-analyzer
9. IDサービスでの活用
idp-serverのIAMロール設計
idp-serverをAWSで運用する際、以下のようなIAMロール設計が必要です。
┌─────────────────────────────────────────────────────────────┐
│ idp-server IAMロール設計 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ECSタスクロール（idp-server-task-role） │
│ ├── Secrets Manager │
│ │ └── GetSecretValue: DB接続情報、外部APIキーの取得 │
│ ├── KMS │
│ │ ├── Decrypt: 暗号化された秘密鍵の復号 │
│ │ ├── Encrypt: データの暗号化 │
│ │ └── GenerateDataKey: データキーの生成 │
│ ├── S3 │
│ │ └── GetObject: 設定ファイルの読み取り │
│ └── CloudWatch Logs │
│ └── PutLogEvents: アプリケーションログの送信 │
│ │
│ ECSタスク実行ロール（idp-server-execution-role） │
│ ├── ECR │
│ │ └── GetDownloadUrlForLayer: コンテナイメージの取得 │
│ ├── CloudWatch Logs │
│ │ └── CreateLogStream: ログストリームの作成 │
│ └── Secrets Manager（コンテナ環境変数注入用） │
│ └── GetSecretValue: コンテナ起動時の秘密情報取得 │
│ │
│ CI/CDロール（idp-server-deploy-role） │
│ ├── ECS │
│ │ └── UpdateService: デプロイ実行 │
│ ├── ECR │
│ │ └── PushImage: イメージのプッシュ │
│ └── CloudFormation │
│ └── インフラ変更の適用 │
│ │
└─────────────────────────────────────────────────────────────┘
IAMとidp-serverの関係
idp-serverはOAuth 2.0/OIDC準拠のIDプロバイダーです。IAMとは異なるレイヤーで動作しますが、概念的に共通する部分があります。
| 概念 | AWS IAM | idp-server |
|---|---|---|
| 認証 | IAMユーザー/ロール | OAuth 2.0 / OIDC |
| 認可 | IAMポリシー | スコープ / クレーム |
| 一時トークン | STS一時認証情報 | アクセストークン / IDトークン |
| 権限委譲 | AssumeRole | Authorization Code Flow |
| 多要素認証 | MFA | FIDO2 / WebAuthn |
ECSタスクロールのポリシー例
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSecretsManagerAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:idp/database-*",
"arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:idp/signing-key-*"
]
},
{
"Sid": "AllowKMSForEncryption",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/idp-encryption-key-id"
},
{
"Sid": "AllowCloudWatchLogs",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/ecs/idp-server:*"
}
]
}
ポイントは、Resource要素で対象を限定していることです。"Resource": "*" ではなく、必要なリソースのARNを明示的に指定します。これが最小権限の原則の実践です。
まとめ
| 概念 | ポイント |
|---|---|
| IAM | AWSの認証・認可を管理する無料のサービス |
| ユーザー/グループ | グループでまとめて権限管理、個別付与は避ける |
| ロール | 長期認証情報よりロール（一時認証情報）を優先 |
| ポリシー | JSON形式、Effect/Action/Resourceで権限定義 |
| 評価ロジック | 明示的Deny > 明示的Allow > 暗黙的Deny |
| MFA | 特にルートアカウントと管理者には必須 |
| STS | 一時的認証情報でセキュリティを向上 |
| 最小権限 | 必要最小限の権限のみ付与、定期的に見直し |
次のステップ
- VPC・ネットワーキング - AWSのネットワーク基盤を学ぶ