今回は、AWS IAMユーザーに個別にポリシーを追加する方法について、特にインラインポリシーの実装手順を中心に詳しく解説します。AWSの運用において、適切な権限管理は非常に重要です。必要最小限の権限のみを付与する「最小権限の原則」に基づいた設定を行うことで、セキュリティリスクを最小化できます。
本記事では、マネジメントコンソールとAWS CLIの両方での操作方法、インラインポリシーと管理ポリシーの使い分け、実践的なポリシー例、そしてトラブルシューティングまで包括的にカバーします。
インラインポリシーとは
インラインポリシー（Inline Policy）は、特定のIAMユーザー、グループ、またはロールに直接埋め込まれるポリシーです。そのIAMエンティティに対してのみ有効で、他のユーザーやロールと共有することはできません。
インラインポリシーの特徴
メリット：
- 特定のユーザーに固有の権限を付与できる
- ポリシーとユーザーが1対1で紐づくため、権限の所在が明確
- そのユーザー専用のカスタマイズされた権限設定が可能
デメリット：
- 複数のユーザーに同じ権限を付与する場合、管理が煩雑になる
- ポリシーの再利用ができない
- ユーザーを削除するとポリシーも一緒に削除される
マネジメントコンソールでの操作手順
それでは、AWSマネジメントコンソールを使用してIAMユーザーにインラインポリシーを追加する手順を説明します。
注意： AWSマネジメントコンソールのUIは定期的に更新されるため、以下の手順は将来的に変更される可能性があります。基本的な流れは同じですが、画面の配置やメニュー名が異なる場合があることをご了承ください。
手順1：IAMコンソールへのアクセス
- AWSマネジメントコンソールにログインします
- 検索バーに「IAM」と入力し、「IAM」サービスを選択します
- 左側のナビゲーションペインから「ユーザー」を選択します
手順2：対象ユーザーの選択
- ポリシーを追加したいIAMユーザー名をクリックします
- ユーザーの詳細画面が表示されます
- 「アクセス許可」タブを選択します
手順3：インラインポリシーの追加
- 「アクセス許可」タブ内の「インラインポリシー」セクションを探します
- 「インラインポリシーの作成」または「ポリシーの追加」ボタンをクリックします
- ポリシーエディタが表示されます
手順4：ポリシーの作成方法を選択
ここで2つの選択肢があります：
ビジュアルエディタを使用する場合：
- サービスを選択（例：S3、EC2など）
- 許可するアクションを選択
- リソースを指定（特定のリソースまたはすべて）
- 条件を追加（必要に応じて）
JSONエディタを使用する場合：
- 「JSON」タブを選択
- ポリシードキュメントをJSON形式で記述
- 構文エラーがないか確認
手順5：ポリシーの確認と保存
- ポリシー名を入力します（わかりやすい名前を推奨）
- 説明を追加します（任意ですが推奨）
- 「ポリシーの作成」ボタンをクリックします
- インラインポリシーがユーザーに追加されたことを確認します
AWS CLIでの操作方法
コマンドラインから操作する場合は、AWS CLIを使用してインラインポリシーを追加できます。自動化やスクリプト化に適しています。
基本コマンド構文
aws iam put-user-policy \
--user-name ユーザー名 \
--policy-name ポリシー名 \
--policy-document file://policy.json
実行例
まず、ポリシードキュメントをJSONファイルとして作成します：
# policy.jsonファイルを作成
cat > policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
EOF
次に、インラインポリシーを追加します：
aws iam put-user-policy \
--user-name test-user \
--policy-name S3ReadOnlyPolicy \
--policy-document file://policy.json
インラインポリシーの確認
追加されたインラインポリシーを確認するには：
# ユーザーに紐づくインラインポリシーの一覧を表示
aws iam list-user-policies --user-name test-user
# 特定のインラインポリシーの内容を表示
aws iam get-user-policy \
--user-name test-user \
--policy-name S3ReadOnlyPolicy
インラインポリシーの削除
不要になったインラインポリシーを削除する場合：
aws iam delete-user-policy \
--user-name test-user \
--policy-name S3ReadOnlyPolicy
インラインポリシーと管理ポリシーの違い
IAMには、インラインポリシーの他に「管理ポリシー」という仕組みがあります。それぞれの特徴を理解し、適切に使い分けることが重要です。
管理ポリシーとは
管理ポリシーは、独立したIAMリソースとして存在するポリシーで、複数のユーザー、グループ、ロールにアタッチできます。AWS管理ポリシー（AWSが提供）とカスタマー管理ポリシー（ユーザーが作成）の2種類があります。
比較表
| 項目 | インラインポリシー | 管理ポリシー |
|---|---|---|
| 再利用性 | 不可（1対1の関係） | 可能（複数のエンティティで共有） |
| 管理の容易さ | 個別管理が必要 | 一元管理が可能 |
| バージョン管理 | なし | あり（最大5バージョン） |
| 削除時の挙動 | エンティティと一緒に削除 | 独立して存在 |
| 適用対象数の制限 | 1つのエンティティのみ | 制限なし |
| サイズ制限 | ユーザー単位で2KB、ロール単位で10KB | 6KB |
使い分けの指針
インラインポリシーを使用すべき場合：
- 特定のユーザーにのみ必要な固有の権限
- テスト環境での一時的な権限付与
- ポリシーとユーザーの関係を厳格に1対1で管理したい場合
- ユーザー削除時にポリシーも確実に削除したい場合
管理ポリシーを使用すべき場合：
- 複数のユーザーに同じ権限を付与する場合
- チーム単位での権限管理
- 本番環境での標準的な権限セット
- ポリシーのバージョン管理が必要な場合
一般的には、管理ポリシーを基本とし、例外的なケースでのみインラインポリシーを使用することが推奨されます。
実践的なポリシーJSON例
ここでは、実務でよく使用される3つのサービス（S3、EC2、CloudWatch）のインラインポリシー例を紹介します。
例1：特定のS3バケットへの読み取り専用アクセス
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::my-project-bucket"
},
{
"Sid": "GetObjects",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::my-project-bucket/*"
}
]
}
ポイント：
- バケット自体の操作とオブジェクトの操作で権限を分けている
- バケット名を特定することで、他のバケットへのアクセスは拒否される
- 読み取りのみで書き込み権限は付与していない
例2：特定のEC2インスタンスの起動・停止権限
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DescribeInstances",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus"
],
"Resource": "*"
},
{
"Sid": "StartStopSpecificInstances",
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RebootInstances"
],
"Resource": "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-1234567890abcdef0",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Environment": "Development"
}
}
}
]
}
ポイント：
- DescribeアクションはすべてのリソースでResourceを”*”にする必要がある
- 特定のインスタンスIDを指定して操作を制限
- タグベースの条件を追加してさらに制限を強化
例3：CloudWatchログの読み取りとメトリクスの参照
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewLogs",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:GetLogEvents",
"logs:FilterLogEvents"
],
"Resource": [
"arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/lambda/my-function:*",
"arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/ec2/my-app:*"
]
},
{
"Sid": "ViewMetrics",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
}
]
}
ポイント：
- ログへのアクセスは特定のロググループに限定
- メトリクスの参照はすべてのリソースで許可（通常の運用監視に必要）
- ログの書き込み権限は含まれていない
よくあるトラブルシューティング
インラインポリシーを使用する際によく遭遇する問題とその解決方法を紹介します。
トラブル1：ポリシーのJSON構文エラー
症状： ポリシーを保存しようとすると「Invalid policy document」などのエラーが表示される
原因：
- JSONの構文ミス（カンマの位置、括弧の不一致など）
- 必須フィールドの欠落（VersionやStatementなど）
- 不正なARN形式
解決方法：
# AWS CLIでポリシーの構文検証
aws iam simulate-custom-policy \
--policy-input-list file://policy.json \
--action-names s3:GetObject \
--resource-arns arn:aws:s3:::my-bucket/test.txt
または、オンラインのJSONバリデーターを使用して構文をチェックします。
トラブル2：ポリシーを追加しても権限が反映されない
症状： インラインポリシーを追加したのに、該当の操作が「Access Denied」エラーになる
原因：
- 明示的な拒否（Deny）ポリシーが優先されている
- リソースARNの指定ミス
- 必要なアクションが不足している
解決方法：
- IAMポリシーシミュレーターを使用して権限を検証
- マネジメントコンソールの「アクセスアドバイザー」で実際のアクセス履歴を確認
- CloudTrailログで拒否された理由を確認
# AWS CLIでポリシーの評価をシミュレート
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:user/test-user \
--action-names s3:GetObject \
--resource-arns arn:aws:s3:::my-bucket/file.txt
トラブル3：インラインポリシーのサイズ制限エラー
症状： 「Policy document exceeds the maximum size」エラーが表示される
原因：
- ユーザーに付与できるインラインポリシーの合計サイズは2KBまで
- 複雑なポリシーや多数のリソースARNを含むと制限に達する
解決方法：
- 管理ポリシーに移行する（管理ポリシーは6KBまで）
- ポリシーを簡略化（ワイルドカードを活用）
- 複数の管理ポリシーに分割して運用
トラブル4：ポリシーの優先順位が不明確
症状： 複数のポリシーが適用されている場合、どれが優先されるか分からない
IAMの評価ロジック：
- デフォルトですべてのリクエストは暗黙的に拒否
- 明示的な許可（Allow）があれば許可される
- 明示的な拒否（Deny）があれば、他のすべての許可より優先される
- 組織のSCP、アクセス許可の境界なども評価される
解決方法：
- ポリシーシミュレーターで評価の詳細を確認
- 不要なポリシーを削除してシンプルに保つ
- Denyステートメントは慎重に使用する
トラブル5：権限の変更が反映されるまでに時間がかかる
症状： ポリシーを変更したが、すぐに反映されない
原因： IAMの変更は「結果整合性」モデルで、完全に反映されるまで数秒から数分かかる場合がある
解決方法：
- 通常は数秒で反映されるため、少し待ってから再試行
- 緊急の場合は、ユーザーに一度ログアウト・ログインしてもらう
- AWS STSで新しい一時的な認証情報を取得
セキュリティのベストプラクティス
インラインポリシーを使用する際は、以下のセキュリティプラクティスを遵守しましょう。
1. 最小権限の原則
必要最小限の権限のみを付与します。「まず広い権限を与えて後で制限する」のではなく、「必要な権限から始めて必要に応じて追加する」アプローチを取りましょう。
2. ワイルドカード（*）の慎重な使用
// 悪い例
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
// 良い例
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::specific-bucket/*"
}
3. 条件の活用
時間帯、IPアドレス、MFAの有無などの条件を追加して、さらにセキュリティを強化できます。
{
"Effect": "Allow",
"Action": "ec2:TerminateInstances",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
},
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
4. 定期的なアクセス権限のレビュー
- IAMアクセスアドバイザーを使用して、実際に使用されている権限を確認
- 90日以上使用されていない権限は削除を検討
- AWS Configを使用して、ポリシーの変更を追跡
5. CloudTrailでのログ監視
すべてのIAM操作はCloudTrailに記録されます。不審なアクティビティがないか定期的に確認しましょう。
その他のポリシー追加方法（簡易説明）
インラインポリシー以外にも、IAMユーザーに権限を付与する方法があります。
管理ポリシーのアタッチ
マネジメントコンソール：
- IAMユーザーの「アクセス許可」タブを開く
- 「許可を追加」→「ポリシーを直接アタッチ」を選択
- AWSが提供する管理ポリシーまたはカスタマー管理ポリシーを選択
AWS CLI：
aws iam attach-user-policy \
--user-name test-user \
--policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
IAMグループ経由での権限付与
ユーザーをIAMグループに追加し、グループにポリシーをアタッチする方法です。複数のユーザーに同じ権限を付与する場合に効率的です。
AWS CLI：
# グループにユーザーを追加
aws iam add-user-to-group \
--group-name Developers \
--user-name test-user
IAMロールの引き受け
ユーザーが一時的に別の権限セットを引き受ける方法です。特権操作を行う場合などに使用します。
まとめ
今回は、AWS IAMユーザーにインラインポリシーを追加する方法を中心に、権限管理の実践的な手法を解説しました。
重要なポイント：
- インラインポリシーは特定のユーザーに固有の権限を付与する際に使用
- 基本的には管理ポリシーを使用し、例外的なケースでインラインポリシーを選択
- マネジメントコンソールとAWS CLIの両方で操作可能
- JSONポリシーは慎重に作成し、必ず最小権限の原則に従う
- トラブルシューティングにはIAMポリシーシミュレーターが有効
AWSの権限管理は、セキュリティの根幹を成す重要な要素です。本記事で紹介した手法を参考に、適切な権限設定を行い、安全なAWS環境を構築してください。実際の運用では、定期的な権限のレビューと監査を行うことで、セキュリティリスクを継続的に低減できます。
権限管理は一度設定したら終わりではなく、継続的な改善が必要なプロセスです。ビジネス要件の変化に応じて柔軟に対応しながら、セキュリティを維持していきましょう。
コメント