Contents
スポンサードリンク
1. IAM の基本概念と最小権限の原則
| コンポーネント | 主な役割 | 補足 |
|---|---|---|
| ユーザー | 人間が直接操作するための認証情報（パスワード・アクセスキー）を保持 | 長期的に使用しない場合は削除、もしくはローテーションを徹底 |
| グループ | 同一権限をまとめて付与できる論理単位 | 権限変更はグループ単位で行うだけで済むので管理コストが低減 |
| ロール | 一時的な権限委譲や AWS サービス間の連携に使用 （例：EC2 インスタンスプロファイル、Lambda 実行ロール） |
アクセスキーを永続化しないため、漏洩リスクが低い |
| ポリシー | JSON で Effect, Action, Resource を定義し、許可（Allow）または拒否（Deny）を表現 |
インラインか管理型のどちらでも作成可能。ベストプラクティスでは 管理型カスタムポリシー の利用が推奨される |
1‑1. ワイルドカード * を避ける具体的手法
最小権限を実現するために、以下の観点で * を排除します。
| 項目 | 推奨例 |
|---|---|
| Action の絞り込み | s3:* → s3:GetObject, s3:ListBucket など |
| Resource の限定 | arn:aws:s3:::* → arn:aws:s3:::my-bucket、arn:aws:s3:::my-bucket/* |
| Condition の活用 | IP アドレス制限 (aws:SourceIp)・MFA 必須 (aws:MultiFactorAuthPresent) で二要素認証を強制 |
ポイント：権限は「必要最小限」の原則に基づき、過剰許可は即座に削除します。
2. ポリシー設計とベストプラクティス（統合）
2‑1. 管理ポリシー vs カスタム管理ポリシー
| 種類 | 特徴 | 適用シーン |
|---|---|---|
| AWS 管理ポリシー | AWS がメンテナンスし、サービス追加に自動追随。粒度は粗め（例：AmazonS3ReadOnlyAccess） |
初期導入や汎用的な権限付与 |
| カスタム管理ポリシー | 組織独自の要件に合わせて JSON を自由編集でき、バージョン管理が可能。 | 最小権限を徹底したい本番環境 |
| インラインポリシー | ユーザー／ロールに直接埋め込む。一時的なテストや「ロール固有の強制条件」に限定して使用 | 例外的ケースのみ |
ベストプラクティス
1. デフォルトは AWS 管理ポリシー → 必要に応じて カスタム管理ポリシー に置き換える。
2. インラインは「一時的」かつ「削除忘れのリスクが低い」場合以外は使用しない。
2‑2. ポリシー作成フロー（推奨プロセス）
- 要件定義：どのサービス・アクションを利用するかを明確化。
- 最小権限で試行：
aws iam create-policy --policy-name <name> --policy-document file://<json>で仮作成し、ステージング環境でテスト。 - レビュー & 承認：コードレビュー（GitHub PR 等）と IAM Access Analyzer の Findings を併用して確認。
- 本番デプロイ：承認済みポリシーを
attach-user-policy/attach-role-policyで付与。 - 定期的な見直し：半年に一度、もしくは新サービス導入時に再評価。
3. IAM Access Analyzer の活用
3‑1. 有効化手順（コンソール・CLI）
| 手段 | コマンド例 |
|---|---|
| コンソール | IAM → アクセスアナライザー → 「Analyzer を作成」 → ORGANIZATION（組織全体） or ACCOUNT（単一アカウント）を選択 |
| CLI | bash<br>aws accessanalyzer create-analyzer --analyzer-name my-analyzer --type ORGANIZATION # 組織全体<br>aws accessanalyzer create-analyzer --analyzer-name my-analyzer --type ACCOUNT # 単一アカウント<br> |
3‑2. Analyzer が評価する対象と Findings の概要
- 評価対象：IAM ポリシー、ロールポリシー、S3 バケットポリシー、KMS キーポリシーなどの リソースベース および アイデンティティベース ポリシー。
- 自動生成される Findings：主に次の 4 カテゴリ（公式ドキュメントで明示）
- Publicly Accessible Resource（例：S3 バケットが全員に公開）
- Cross‑Account Access（意図しない別アカウントへの共有）
- IAM Role Trust Policy Allowing All Principals（信頼ポリシーが
*） - Unintended Privilege Escalation（権限昇格の可能性）
注記：公式には「100+」という具体的な数は記載されていません。上記カテゴリに含まれる個別チェックが多数あるため、実際の Findings の件数はポリシーの規模に応じて変動します。
3‑3. Findings の取得例
|
1 2 3 4 5 |
# アクティブな Findings を一覧取得（JSON 出力） aws accessanalyzer list-findings \ --analyzer-name my-analyzer \ --filter '{"status": ["ACTIVE"]}' |
コンソールの Findings タブでは、重大度（high / medium / low）でフィルタリング可能です。
3‑4. 実践例：S3 バケットが誤って公開されたケース
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } ] } |
上記ポリシーをロールに付与すると、Analyzer は次のような Finding を生成します。
Finding:
S3 Bucket Public Access
Description:Bucket arn:aws:s3:::my-bucket is publicly accessible.
このときは以下の手順で修正します。
- ポリシーを
s3:GetObject,s3:ListBucketのみ許可に絞る。 - 再度 Analyzer で Finding が無くなることを確認。
4. 上位制御と認証層の強化
| 制御手段 | 主な効果 | 設定例 |
|---|---|---|
| Permission Boundary | ユーザー・ロールが取得できる 最大権限 を上書き。組織全体で統一した上限を設定可能。 | json<br>{<br> "Version":"2012-10-17",<br> "Statement":[{<br> "Effect":"Allow",<br> "Action":["s3:GetObject","s3:ListBucket"],<br> "Resource":"*"<br> }]<br>}<br> |
| Service Control Policy (SCP) | AWS Organizations の OU（Organizational Unit）単位で 許可/拒否 を強制。すべてのアカウントに対して上書きできない上限を設定。 | json<br>{<br> "Version":"2012-10-17",<br> "Statement":[{<br> "Effect":"Deny",<br> "Action":"*:*",<br> "Resource":"*"<br> },{<br> "Effect":"Allow",<br> "Action":["s3:GetObject","ec2:DescribeInstances"],<br> "Resource":"*"<br> }]<br>}<br> |
| MFA 必須化 | ポリシーに aws:MultiFactorAuthPresent 条件を付与し、MFA が無い場合はすべての API 呼び出しを拒否。 |
json<br>{<br> "Version":"2012-10-17",<br> "Statement":[{<br> "Effect":"Deny",<br> "Action":"*:*",<br> "Resource":"*",<br> "Condition":{"Bool": {"aws:MultiFactorAuthPresent":"false"}}<br> }]<br>}<br> |
| アクセスキーのローテーション | 定期的に新しいアクセスキーを作成し、古いものは即削除。自動化スクリプトで運用コストを低減。 | bash<br># 1. 新規キー作成（ユーザー alice）<br>aws iam create-access-key --user-name alice > new_key.json<br><br># 2. アプリに新キーをデプロイし、正常動作確認<br><br># 3. 古いキー削除（古いキー ID を取得）<br>OLD_KEY_ID=$(aws iam list-access-keys --user-name alice \\\n --query 'AccessKeyMetadata[?Status== |
| Secrets Manager の活用 | アクセスキーやパスワードを暗号化保存し、IAM ロールで取得させることでコードや環境変数に平文を書かない。 | aws secretsmanager get-secret-value --secret-id my-app/creds で取得し、アプリ起動時に注入 |
ポイント：Permission Boundary と SCP は「上位制御」、MFA・ローテーションは「認証層」の強化です。これらを組み合わせることで Defense‑in‑Depth（多層防御）を実現できます。
5. 実践ガイド：ポリシーサンプル、デプロイ、監査・バージョン管理
5‑1. ポリシーサンプル
(a) S3 読み取り限定（最小権限）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowReadOnlyToSpecificBucket", "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::example-bucket", "arn:aws:s3:::example-bucket/*" ] } ] } |
(b) EC2 起動・停止（リージョン限定）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEC2StartStopInAPNortheast1", "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:TerminateInstances", "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": ["ap-northeast-1"] } } } ] } |
5‑2. CLI でのポリシー作成・アタッチ手順
|
1 2 3 4 5 6 7 8 9 10 |
# ① ポリシー作成（例：S3 読み取り限定） aws iam create-policy \ --policy-name S3ReadOnlyExample \ --policy-document file://s3-readonly.json # ② ユーザー alice にポリシーをアタッチ aws iam attach-user-policy \ --user-name alice \ --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyExample |
5‑3. CloudTrail と AWS Config による監査
| 項目 | 設定例 |
|---|---|
| CloudTrail（管理イベント） | 全リージョンで Write / Delete イベントを有効化し、S3 バケットに保存。 |
| AWS Config ルール | マネージドルール iam-policy-no-statements-with-full-access を使用して「フルアクセス許可ステートメント」の検出を自動化。 |
Config ルールのデプロイ例
|
1 2 3 |
aws configservice put-config-rule \ --config-rule file://iam-policy-no-statements-with-full-access.json |
注意：
iam-policy-no-full-access.jsonというファイル名は公式マネージドルールと合致しません。正しいルール名はiam-policy-no-statements-with-full-accessです。
5‑4. ポリシーバージョン管理とロールバック
カスタム管理ポリシーは最大 5 バージョン を保持できます。新バージョン作成後にテストし、問題なければデフォルトバージョンへ切り替えます。
|
1 2 3 4 5 6 7 8 9 |
# ① 現在のバージョン一覧取得 aws iam list-policy-versions \ --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyExample # ② バージョン v2 をデフォルトに設定 aws iam set-default-policy-version \ --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyExample \ --version-id v2 |
ベストプラクティス：変更前に必ず新バージョンを作成し、ステージング環境で動作確認後に本番へ適用することで、ロールバックリスクを最小化できます。
6. 次のステップ（運用定着へのロードマップ）
- Access Analyzer の有効化 → サンプルポリシーを適用し、Finding が出ないことを確認。
- カスタム管理ポリシーのバージョン管理と CloudTrail / Config での監査 を本番環境に導入。
- 定期レビュー：半年ごとに IAM ポリシー全体を Access Analyzer と Config の結果から再評価し、不要な権限を削除。
- 最新ベストプラクティスの取得：AWS 公式ページ（IAM ベストプラクティス – AWS Docs）を定期的にチェックし、機能追加や推奨設定の変更に追随。
用語集
| 用語 | 説明 |
|---|---|
| IAM Access Analyzer | ポリシーが外部に対して過剰なアクセス権を付与していないか自動で検出するサービス。 |
| Finding | Analyzer が検出した問題点のこと。公開リソースやクロスアカウント共有などが対象。 |
| Permission Boundary | IAM エンティティに対し取得できる最大権限を制限するポリシー。 |
| Service Control Policy (SCP) | AWS Organizations の OU に適用できる上位レベルの許可/拒否ポリシー。 |
| Managed Rule | AWS Config が提供する、すぐに使える標準監査ルール。 |
まとめ
IAM は「誰が」「何を」行えるかを細かく制御できる反面、設定ミスは重大なセキュリティインシデントにつながります。本稿で紹介した 最小権限の原則 → ポリシー設計 → Access Analyzer の自動診断 → 上位制御と認証層強化 → 監査・バージョン管理 のフローを組織全体に展開すれば、継続的かつ安全な権限管理が実現できます。
スポンサードリンク