IAMポリシーの作り方!マネージド・インライン・カスタムの違いと構文解説【初心者向けAWS IAM】
先生と生徒の会話形式で理解しよう
生徒
「IAMポリシーって種類がたくさんありますよね?マネージドとかインラインとか、違いがよくわからなくて…」
先生
「IAMポリシーには目的や使い方に応じた違いがあります。まずは種類の違いを整理して、その構文についても一緒に見ていきましょう。」
生徒
「はい!どのポリシーを使えばいいのか、初心者でもわかるように教えてください!」
先生
「それでは、IAMマネージドポリシー、インラインポリシー、カスタムマネージドポリシーの違いと、基本構文を丁寧に解説しましょう!」
1. IAMポリシーの種類と違い
AWS IAMポリシーには大きく三種類あります:
- AWSマネージドポリシー:AWSが提供・管理する既定のポリシーです。
迅速に使えて手軽ですが、柔軟性は限定的です。 - カスタムマネージドポリシー:ユーザーや組織が独自に作成・管理するポリシーです。再利用性が高く、保守性にも優れます。
- インラインポリシー:特定のユーザー、グループ、ロールに直接埋め込む形で設定するポリシーです。柔軟ですが再利用が難しく、管理が煩雑になりがちです。
用途や管理性によってポリシーを使い分けることがAWS IAM運用の基本です。
2. どれを使うべき?使い分けのポイント
- AWS管理された標準の権限が必要なとき:
→AWSマネージドポリシー - 独自の権限セットを何度も使いたい:
→カスタムマネージドポリシー - 特定のユーザーやロールにだけ権限を限定したい:
→インラインポリシー
3. IAMポリシーの構文(JSON形式)の基本
IAMポリシーはJSON形式で記述します。基本的な構文は以下のようになります:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example-bucket"
}
]
}
以下が構文の要素です:
- Version:ポリシーのバージョンです。固定値をそのまま使います。
- Statement:許可や拒否のルールを配列で複数定義できます。
- Effect:許可(Allow)か拒否(Deny)かを指定。
- Action:許可または拒否するアクション(例:s3:GetObject)。
- Resource:どのリソースに対して適用するか(ARN形式)。
4. カスタムマネージドポリシー作成例
以下は、S3のバケット内オブジェクトの読み取りと書き込みを許可するカスタムマネージドポリシーの例です:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
このようにActionに配列で複数指定、Resourceにワイルドカードを使うことで柔軟な定義が可能です。
5. インラインポリシー設定の注意点
インラインポリシーは特定のエンティティにだけ直接設定できますが、以下の点に注意しましょう:
- 同じポリシーを複数エンティティに適用する際、再利用性が低くなります。
- インラインポリシーは複雑化しやすく、一覧性や監査性が低下しがちです。
- ポリシー更新時に対象ごとに修正が必要となり、ミスが増えるリスクがあります。
6. IAMポリシー運用のベストプラクティス
- 最小権限の原則:本当に必要なActionだけ許可すること。
- 複数利用にはカスタムマネージドポリシー、特定用途にはインラインも有効に。
- 命名規則の統一:例:
MyServiceReadOnlyPolicyのようにわかりやすく。 - ポリシー変更履歴の管理:監査ログやGit管理で追跡可能に。