AWS IAM 基本ガイド - ユーザー、ロール、ポリシー管理
AWS IAM(Identity and Access Management)は、AWSリソースへのアクセスを安全に制御するためのWebサービスです。ユーザー、グループ、ロール、ポリシーを通じて、誰が何にアクセスできるかを細かく制御し、最小権限の原則に基づいたセキュリティ設計を実現します。
IAMの基本概念
IAMの4つの主要コンポーネント
1. IAMユーザー(Users)
個人またはアプリケーションを表すアイデンティティです。永続的な認証情報を持ち、独自のアクセスキーやパスワードを所有します。
IAMユーザーの特徴:
認証情報:
- ユーザー名とパスワード(コンソールアクセス)
- アクセスキーとシークレットキー(プログラムアクセス)
- 一時的な認証情報(STSトークン)
用途:
- 個人開発者アカウント
- サービスアカウント(非推奨)
- 緊急時アクセス用アカウント
2. IAMグループ(Groups)
複数のIAMユーザーをまとめて管理するコレクションです。グループにポリシーを添付することで、効率的な権限管理を実現します。
IAMグループ設計例:
Developers:
- 開発者向け権限
- EC2、S3、CloudWatch読み取り
- 特定リソースの操作権限
Administrators:
- 管理者向け権限
- ほぼ全てのAWSサービスアクセス
- セキュリティ関連設定権限
ReadOnly:
- 読み取り専用権限
- 監査、監視用途
- 本番環境参照権限
3. IAMロール(Roles)
一時的にアクセス権限を引き受けることができるアイデンティティです。永続的な認証情報を持たず、AssumeRoleによって一時的な認証情報を取得します。
IAMロールの種類:
EC2インスタンスロール:
- EC2インスタンス用の権限
- メタデータサービス経由でアクセス
- 自動的な認証情報ローテーション
Lambda実行ロール:
- Lambda関数の実行権限
- CloudWatch Logs書き込み
- 他のAWSサービスアクセス
クロスアカウントロール:
- 他のAWSアカウントからのアクセス
- 外部IDによる追加認証
- AssumeRoleによる権限引き受け
4. IAMポリシー(Policies)
権限を定義するJSONドキュメントです。Allow(許可)またはDeny(拒否)のステートメントで構成され、具体的なアクションとリソースを指定します。
ポリシーの種類:
AWS管理ポリシー:
- AWS提供の事前定義ポリシー
- 一般的な権限パターン
- AWS更新により自動改善
顧客管理ポリシー:
- カスタムビジネス要件対応
- 細かい権限制御
- バージョン管理機能
インラインポリシー:
- 単一エンティティに直接添付
- 1対1の関係
- 特殊用途での使用
ポリシーの基本構造
JSON ポリシードキュメント
IAMポリシーはJSON形式で記述され、以下の要素で構成されます:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ReadAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
}
]
}
ポリシー要素の詳細
1. Version(必須)
ポリシー言語のバージョンを指定します。最新バージョンは "2012-10-17" です。
2. Statement(必須)
権限の定義を含む配列です。複数のステートメントを組み合わせて複雑な権限を定義できます。
3. Effect(必須)
"Allow"(許可)または "Deny"(拒否)を指定します。明示的なDenyは常にAllowより優先されます。
4. Action(必須)
許可または拒否するAPIアクションを指定します。ワイルドカード(*)による部分一致も可能です。
Action 記述例:
特定アクション: "s3:GetObject"
複数アクション: ["s3:GetObject", "s3:PutObject"]
ワイルドカード: "s3:*"
サービス全体: "ec2:*"
全アクション: "*"
5. Resource(一部必須)
アクションの対象となるAWSリソースをARN(Amazon Resource Name)で指定します。
Resource ARN 例:
S3バケット: "arn:aws:s3:::bucket-name"
S3オブジェクト: "arn:aws:s3:::bucket-name/*"
EC2インスタンス: "arn:aws:ec2:region:account:instance/instance-id"
Lambda関数: "arn:aws:lambda:region:account:function:function-name"
全リソース: "*"
6. Condition(任意)
条件付きアクセス制御を定義します。IPアドレス、時間、リクエストパラメータなどに基づいて権限を制限できます。
"Condition": {
"IpAddress": {
"aws:SourceIp": "192.0.2.0/24"
},
"DateGreaterThan": {
"aws:CurrentTime": "2025-01-01T00:00:00Z"
},
"StringEquals": {
"ec2:InstanceType": "t3.micro"
}
}
実践的なポリシー設計パターン
基本的なポリシー例
IAMポリシーは、JSON形式で権限を定義します。初心者にとって重要なのは、複雑な条件文よりも基本的な構造の理解です。
開発者向けポリシーの考え方:
- EC2インスタンスの参照と基本操作権限
- S3バケットの読み書き権限(特定バケットのみ)
- CloudWatchログの参照権限
- 本番環境リソースへのアクセス制限
S3アクセス制御の考え方:
- バケット一覧の表示権限
- 特定バケットへのアクセス権限
- ユーザーごとのフォルダ分離
- オブジェクトの操作権限(読み取り、書き込み、削除)
ポリシーの設計では、以下の点を考慮することが重要です:
設計要素 | 考慮点 | 初心者向けアプローチ |
---|---|---|
権限の範囲 | 必要最小限の権限付与 | AWS管理ポリシーから開始 |
リソース指定 | 特定リソースへの制限 | ワイルドカード(*)の使用を最小限に |
条件設定 | アクセス条件の追加 | 基本設定後に段階的に追加 |
IAMロールの設計パターン
EC2インスタンスロール
EC2ロール設計:
信頼ポリシー:
- Principal: ec2.amazonaws.com
- Action: sts:AssumeRole
権限ポリシー:
- CloudWatch メトリクス送信
- S3特定バケットアクセス
- Systems Manager セッション管理
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Lambda実行ロール
Lambda ロール設計:
基本実行権限:
- CloudWatch Logs作成・書き込み
- ENI管理(VPC Lambda用)
カスタム権限:
- DynamoDB読み書き
- S3オブジェクトアクセス
- SES メール送信
クロスアカウントアクセスロール
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT-B:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "unique-external-id"
},
"IpAddress": {
"aws:SourceIp": "192.0.2.0/24"
}
}
}
]
}
セキュリティベストプラクティス
最小権限の原則
最小権限設計指針:
段階的権限付与:
1. 必要最小限の権限から開始
2. 業務要件に応じて段階的に追加
3. 定期的な権限レビューと削減
時間ベース制限:
- 条件付きアクセス(勤務時間のみ)
- 一時的な権限昇格
- セッション時間制限
MFA(多要素認証)強制
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:GetAccountSummary",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswords",
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "DenyAllExceptUnlessSignedInWithMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
アクセスキー管理
アクセスキー管理指針:
ベストプラクティス:
- IAMロール優先使用
- アクセスキーの定期ローテーション
- 使用されていないキーの削除
- CloudTrail による使用状況監視
代替手段:
- IAMロール(EC2、Lambda等)
- AWS CLI の assume-role
- AWS SDK の自動認証情報取得
IAM 監視と監査
CloudTrail による API 監視
監視対象 IAM イベント:
重要なアクション:
- CreateUser, DeleteUser
- AttachUserPolicy, DetachUserPolicy
- CreateRole, DeleteRole
- AssumeRole(頻度とパターン)
アラート設定:
- ルートアカウント使用
- 新規IAMユーザー作成
- 権限昇格の検知
Access Analyzer の活用
Access Analyzer 機能:
外部アクセス検出:
- 意図しない外部共有検出
- リソースベースポリシー分析
- クロスアカウントアクセス可視化
ポリシー検証:
- ポリシー構文検証
- 論理エラー検出
- 最小権限提案
定期的な権限レビュー
権限レビュープロセス:
月次レビュー:
- 未使用IAMユーザーの確認
- アクセスキー最終使用日確認
- 過度な権限の検出
四半期レビュー:
- IAMポリシーの最適化
- クロスアカウントアクセスの見直し
- セキュリティグループとの連携確認
トラブルシューティング
一般的な IAM 問題
1. 権限不足エラー
診断手順:
1. CloudTrail でアクセス拒否イベント確認
2. IAM Policy Simulator でテスト
3. 明示的Denyポリシーの確認
4. SCPによる組織レベル制限確認
2. AssumeRole 失敗
確認項目:
- 信頼ポリシーの Principal 設定
- 外部ID条件の一致
- ロールの権限境界設定
- セッション時間制限
3. MFA関連問題
対処法:
- MFAデバイスの同期確認
- 時刻同期の確認
- バックアップMFAデバイス設定
- 緊急アクセス手順の準備
まとめ
AWS IAMは、クラウドセキュリティの基盤となる重要なサービスです。ユーザー、グループ、ロール、ポリシーの適切な設計により、最小権限の原則に基づいた安全なアクセス制御を実現できます。定期的な権限レビュー、MFA の強制、適切な監視により、セキュリティ態勢を継続的に向上させることが重要です。IAMロールの活用により、長期的な認証情報管理の負担を軽減し、より安全なクラウド環境を構築できます。
引用元:
- https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html