どーも！shihopowerです！今回はAWSの権限についてお話します。
先日、とある研修でEC2をつくろうとしたら、権限が付与されていなくてつくれなかったということがありました。他にも調べてみると、リソースを作成する権限が受講生に割り当たっていなかったという。。。
事務局の方のミスだったのですが、もし自分が事務局だったとしても同じようなミスをしていただろうし、「権限を付与して」といわれてもこの場合は何をどうやって操作して、どのくらいの権限を付与すればよいのかわからないと思いました。
これを機に、権限まわりの知識を体系的にとらえなおして実務で実践的に使えるようにしようと思います。この連載では全4本にわたってAWSの権限管理を整理していきます。
この記事で扱うこと
- IAMとは何か・プリンシパルという概念
- 権限評価の基本ルール
- IAMアイデンティティの3種類と選び方
- ポリシーの7種類の全体像
- アイデンティティベースのポリシー（AWS管理・カスタマー管理・インライン）
- リソースベースのポリシー（S3・KMS・Lambda等）
1. IAMとは何か
IAM（Identity and Access Management） は、AWSリソースへのアクセスを安全に管理するためのウェブサービスです。
IAMを使うと「誰が」「何に」「どんな操作を」できるかをJSON形式のポリシーで定義できます。
プリンシパルという概念
IAMを理解するうえで最初に押さえておきたい概念がプリンシパルです。プリンシパルとはAWSにリクエストを送る主体のことで、具体的には以下が該当します。
- IAMユーザー（人間が使うアカウント）
- IAMロール（EC2・Lambdaなどのサービス、または人間が一時的に引き受けるもの）
- AWSサービス自体（例：LambdaがS3を呼び出すときのLambda）
- フェデレーションユーザー（社内IdPなど外部IDプロバイダー経由でログインする人）
- AWSアカウントのルートユーザー
「誰がAWSに対して操作を要求しているか」を表す概念で、リソースベースのポリシーの Principal 要素で「このプリンシパルにアクセスを許可する」と明示的に指定する際にも使われます。
2. 権限評価の基本ルール
AWSの権限評価には3つの重要なルールがあります。
ルール1：デフォルトで全リクエストを拒否する
IAMユーザーを作っただけでは何もできません。明示的にAllowするポリシーをアタッチして初めてAWSリソースを操作できるようになります。
ルール2：明示的なDenyはすべてのAllowに優先する
1つのポリシーでリクエストが拒否されると、そのリクエストはAWS全体で拒否され、ポリシーの評価が停止します。これを明示的な拒否と呼びます。
明示的なDeny > デフォルトの拒否 > 明示的なAllow
ルール3：有効な権限 = 全ポリシーの共通部分（∩）
複数のポリシーが適用される場合、すべてのポリシーで許可されているアクションだけが実際に実行できます。どれか1つでもDenyがあればそのアクションは拒否されます。
有効な権限 = アイデンティティベースのポリシー ∩ リソースベースのポリシー ∩ SCP ∩ ...
SCPやRCP、アクセス許可の境界などを組み合わせると、この「共通部分」がより複雑になっていきます。詳しくは第2本・第3本で扱います。
3. IAMアイデンティティの3種類と選び方
AWSには3種類のIAMアイデンティティがあります。
IAMユーザー（原則非推奨）
AWS公式のベストプラクティスでは、IAMユーザーはほぼどんなユースケースでも利用しないことを推奨しています。
理由は以下のとおりです。
- 個人のアカウント向けに設計されているため、組織の成長に合わせてスケールしない
- 長期的な認証情報（アクセスキー）を管理する必要があり、漏洩リスクが高い
- 一元的に可視化して監査する機能がなく、コンプライアンス維持が難しい
IAMユーザーを使うべき例外的なケースは以下に限られます。
- AWSアカウントへの緊急アクセス
- IAMロールを使えないワークロード（CodeCommit・Amazon Keyspacesなど）
- サードパーティAWSクライアントで IAM Identity Centerが非対応のもの
- IAM Identity Centerが利用できず、他にIDプロバイダーがない場合
IAMグループ
IAMグループは複数のIAMユーザーの集合体です。グループにポリシーをアタッチすると、グループに属するすべてのユーザーにそのポリシーが適用されます。
グループ「開発チーム」にAmazonEC2FullAccessをアタッチ
→ グループに属するユーザー全員がEC2を操作できる
→ ユーザーが増えてもグループに追加するだけでよい
→ ポリシーを変更するときもグループ側を1か所変えるだけ
IAMロール（推奨）
IAMロールは特定の許可を持つアイデンティティで、特定のユーザーに紐づいていません。EC2・LambdaなどのAWSサービスや、フェデレーションユーザーが一時的に引き受けて使うものです。
IAMロールの最大の特徴は**一時的な認証情報（短期間で自動的に失効）**を使う点です。長期的なアクセスキーを管理する必要がなく、漏洩しても自動的に無効になるためセキュリティリスクが大幅に下がります。
| 要件 | 使うべきアイデンティティ |
|---|---|
| 社内エンジニアがAWSコンソールにログインする | IAM Identity Center（フェデレーション）推奨 |
| EC2・LambdaなどがAWSサービスを呼び出す | IAMロール（一時認証情報） |
| 複数ユーザーに同じポリシーを適用する | IAMグループ |
| サードパーティツールでIAM Identity Center非対応 | IAMユーザー（長期認証情報・非推奨） |
4. ポリシーの7種類の全体像
AWSでアクセスを管理するには、ポリシーを作成してIAMアイデンティティやAWSリソースにアタッチします。ポリシーは7種類あります。
SCP・RCP・アクセス許可の境界・セッションポリシーは「許可を付与するものではなく上限を定義するもの」です。詳しくは第2本・第3本で扱います。
この記事では最もよく使うアイデンティティベースのポリシーとリソースベースのポリシーを詳しく見ていきます。
5. アイデンティティベースのポリシー（最もよく使う）
アイデンティティベースのポリシーは、IAMユーザー・グループ・ロールにアタッチするポリシーです。「このアイデンティティが何をできるか」を定義します。3種類あります。
5.1 AWS管理ポリシー
AWSが作成・管理するポリシーです。多くの一般的なユースケースに対応したアクセス許可があらかじめ定義されており、すぐに使えます。
代表的なものは以下のとおりです。
| ポリシー名 | 内容 |
|---|---|
AmazonEC2FullAccess |
EC2に関するすべての操作を許可 |
AmazonS3ReadOnlyAccess |
S3の読み取り専用アクセス |
AdministratorAccess |
すべてのサービスへのフルアクセス |
PowerUserAccess |
IAM管理を除くすべてのサービスへのフルアクセス |
AWS管理ポリシーは自分では編集できません。AWSが新しいサービスを追加したときなどに自動で更新されます。
5.2 カスタマー管理ポリシー
自分のAWSアカウントで作成・管理するポリシーです。AWS管理ポリシーよりも細かい制御ができます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*"
}
]
}
上記の例では「EC2インスタンスの起動・開始・停止は許可するが削除は許可しない」という設定ができます。
カスタマー管理ポリシーはバージョン管理（最大5バージョン）ができるため、変更前に戻すことも可能です。また複数のユーザー・グループ・ロールにアタッチして使い回せます。
5.3 インラインポリシー
特定のIAMユーザー・グループ・ロールに直接埋め込むポリシーです。そのIDを削除すると一緒に削除されます。
インラインポリシーの特徴
| 項目 | 管理ポリシー | インラインポリシー |
|---|---|---|
| 複数IDへの再利用 | できる | できない（1対1） |
| 変更の一元管理 | 1か所変えれば全IDに反映 | 各IDを個別に変更 |
| バージョン管理 | 最大5バージョン保存 | なし |
| IDを削除したとき | ポリシーは残る | 同時に削除される |
| 文字数上限 | 大きい（6,144文字） | 小さい |
インラインポリシーを使うべき場面
「ポリシーとIDの厳密な1対1の関係を維持する必要がある場合」に使います。具体的には「このポリシーの権限が意図したID以外に絶対に付与されてはならない」というケースです。
管理ポリシーは複数のIDに自由にアタッチできるため、誤って別のロールに付けてしまうリスクがあります。インラインポリシーは構造上、他のIDにアタッチされることがないため誤付与を防げます。
原則として管理ポリシーを使い、インラインポリシーは特殊なケースに限定するのがAWS公式の推奨です。
また、IAMユーザー・グループ・ロールへの埋め込みは可能ですが、「サービスにリンクされたロール」にはインラインポリシーを埋め込めません。
管理ポリシーとインラインポリシーを比較してします。
6. リソースベースのポリシー
リソースベースのポリシーは、AWSリソース側にアタッチするポリシーです。「誰がこのリソースにアクセスできるか」を定義します。
アイデンティティベースのポリシーとの大きな違いが2点あります。
1つ目は、ポリシーの中に Principal（誰が）を明示的に書く点です。
2つ目は、リソースベースのポリシーはすべてインライン形式のみという点です。アイデンティティベースのポリシーにはAWS管理ポリシー・カスタマー管理ポリシー・インラインポリシーの3種類がありましたが、リソースベースのポリシーに管理ポリシー版は存在しません。リソースベースのポリシーは特定のリソースに直接埋め込む形式のため、複数のリソースに「使い回す」という概念がそもそもないためです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
}
]
}
代表的なリソースベースのポリシーを整理します。
S3バケットポリシー
S3バケット自体にアタッチします。どのプリンシパルがそのバケットやオブジェクトに何をできるかを定義します。クロスアカウントアクセスやパブリック公開の制御に広く使われます。
IAMロールの信頼ポリシー（Trust Policy）
IAMロールにアタッチするリソースベースのポリシーで、そのロールを引き受けられるプリンシパルを定義します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
上記の例は「EC2サービスがこのロールを引き受けることを許可する」という信頼ポリシーです。
AWS KMSのキーポリシー
KMSキーにリソースベースのポリシーをアタッチしたものです（キーポリシーと呼びます）。すべてのKMSキーにキーポリシーが必要で、キーポリシーで明示的に許可されていない限り、IAMポリシーだけではKMSキーへのアクセスを許可できません。 KMSはリソースベースのポリシーが必須な唯一のサービスに近い存在です。
Lambda関数ポリシー
Lambda関数にアタッチするリソースベースのポリシーです。S3がLambda関数をトリガーする場合、「S3からの呼び出しを許可する」という設定をこのポリシーで行います。
SQSキューポリシー
SQSキューにアタッチします。別アカウントのサービスやSNSトピックからキューへ送信を許可する際に使われます。
Secrets Managerのリソースポリシー
シークレットにアタッチします。クロスアカウントでシークレットへのアクセスを許可する際に使われます。
クロスアカウントアクセスにおけるリソースベースのポリシーの役割
同じアカウント内では、アイデンティティベースのポリシーとリソースベースのポリシーのどちらか一方で許可があれば（かつDenyがなければ）アクセスできます。
しかし別アカウントからのアクセスには両方の許可が必要です。
アカウントA のユーザーが アカウントB のS3バケットにアクセスする場合
アカウントA側：ユーザーのアイデンティティベースのポリシーで S3へのアクセスを Allow
アカウントB側：S3バケットポリシーで アカウントAのユーザーを Principal に指定してAllow
→ 両方の許可が揃って初めてアクセスできる
まとめ
| ポリシータイプ | 誰・何にアタッチ | 主な用途 |
|---|---|---|
| AWS管理ポリシー | IAMユーザー・グループ・ロール | AWSが用意した定番の権限セット |
| カスタマー管理ポリシー | IAMユーザー・グループ・ロール | 自分で定義する細かい権限制御 |
| インラインポリシー | IAMユーザー・グループ・ロール | 誤付与を防ぎたい特殊なケース |
| S3バケットポリシー | S3バケット | バケットへのアクセス制御 |
| KMSキーポリシー | KMSキー | 暗号化キーへのアクセス制御（必須） |
| Lambda関数ポリシー | Lambda関数 | 他サービスからの呼び出し許可 |
| SQSキューポリシー | SQSキュー | キューへのメッセージ送受信制御 |
次の記事では、AWS Organizationsを使って組織全体にガードレールを設けるSCPとRCPを解説します。