AWSのポリシーとロールの基本から最新運用法まで徹底解説

2025 9/27

2025/09/27

はじめに

この記事では、AWSにおける「ポリシー」と「ロール」の基礎から運用のコツまでをわかりやすく解説します。クラウドの権限管理は一見むずかしく感じますが、仕組みを押さえれば安全で使いやすい環境を作れます。

対象読者

AWSの基本は知っているが権限まわりに自信がない方
開発者や運用担当で実務に活かしたい方

本章で得られること

この記事全体の構成と読み進め方が分かります
ポリシー／ロールの違いについて直感的に理解できます（具体例あり）

簡単な例え

ポリシー＝「図書館の利用ルール」、ロール＝「貸出カードや職員の肩書き」です。ルールを作って、肩書きを通じて誰がどのルールを使うか決めます。

この記事は、実務で使える感覚を重視して進めます。次章からは具体的な種類や書き方、運用上の注意点を順に見ていきましょう。

AWSにおける「ポリシー」と「ロール」の基本

はじめに

AWSでのアクセス制御は「ポリシー」と「ロール」で成り立ちます。ここではまず両者の役割と使い方をやさしく説明します。

ポリシーとは

ポリシーは誰が何をできるかを書いたJSONドキュメントです。主に「アクション（例: s3:GetObject）」「リソース（例: arn:aws:s3:::my-bucket/*）」「条件（例: IP制限）」で構成します。ユーザー、グループ、ロールにアタッチして権限を与えます。

ロールとは

ロールは一時的に権限を与えるための“仮想ユーザー”です。人やサービス（EC2やLambdaなど）が引き受けることで、そのロールに付いたポリシーの権限で操作できます。ロール自体に長期的な認証情報はありません。

実際のイメージ

EC2がS3にファイルを置く：EC2インスタンスにロールを割り当て、S3書き込み権限のポリシーを付与します。
クロスアカウント：別アカウントのユーザーに対してロールを引き受ける権限を与え、安全に権限委譲します。

注意点

デフォルトは無権限です。必要最低限の権限を付与（最小権限の原則）、有効期限や条件を使って制御すると安全です。

ポリシーの種類と管理

はじめに

AWSのポリシーは「誰が何をできるか」を決める設計図です。用途に応じて使い分けると運用が楽になります。

アイデンティティベースポリシー

IAMユーザー、グループ、ロールに直接付けるポリシーです。たとえば「開発者グループにS3の読み取りだけを許可する」といった個別の権限設定に使います。マネージド（再利用可能）とインライン（特定エンティティ専用）があります。マネージドは共通設定を配布しやすく、インラインは細かい例外に向きます。

リソースベースポリシー

S3バケットやLambda関数など、リソース自体に設定するポリシーです。外部アカウントからのアクセスを許可したいときに便利です。例：別アカウントのサービスにバケットへのPutObjectを許可する場合、バケットポリシーでアクセス元のアカウントを指定します。

マネージドポリシー（AWS提供とカスタム）

AWSが用意する「AmazonS3ReadOnlyAccess」などはすぐ使えます。手軽ですが権限が広めの場合があります。必要に応じてカスタムのマネージドポリシーを作り、最小権限を意識して設計してください。

管理のポイント

最小権限の原則で不要な許可を減らす。
グループやロールでまとめて管理する。
ポリシーは命名・バージョン管理して追跡する。
ポリシーシミュレータで想定通り動くか事前に確認する。
定期的に見直しと監査を行う。

IAMロールの具体的な利用例（EKS/ECS/EC2）

EKS（Kubernetes）

クラスターロール：信頼ポリシーでPrincipalにeks.amazonaws.comを指定します。クラスタ管理用にAmazonEKSClusterPolicyなどを割り当て、コントロールプレーンが必要な操作を行えるようにします。
ノードロール（Worker）：Principalにec2.amazonaws.comを指定し、AmazonEKSWorkerNodePolicy、AmazonEC2ContainerRegistryPullOnly、AmazonEKS_CNI_Policyなどを付与します。ノードがイメージをプルしたり、CNIを操作したりできます。
IRSA（Podごとの権限）：OIDCプロバイダーを作成し、KubernetesのServiceAccountにIAMロールを紐付けます。これによりPod単位で最小権限を実現できます。

ECS

タスクロール（Task Role）：各タスクに割り当てるロールです。アプリがS3やDynamoDBへアクセスする場合、必要な権限だけを付与します。
実行ロール（Task Execution Role）：コンテナイメージをECRから取得したりログを送るための権限を与えます（例：AmazonECSTaskExecutionRolePolicy）。
EC2起動タイプの場合はインスタンスロール（Principal=ec2.amazonaws.com）を用い、ECSエージェントやログ用権限を付与します。

EC2

インスタンスプロファイル：EC2にアタッチするIAMロールです。SSMやS3アクセスなど用途に合わせてAmazonSSMManagedInstanceCoreや最小限のカスタムポリシーを設定します。

運用上のポイント

ロールは「信頼ポリシー（誰が使えるか）」と「権限ポリシー（何ができるか）」を分けて設計します。
Podやタスク単位でロールを分け、必要最小限の権限を付与することが重要です。これによりリスクを小さく保てます。

ポリシーの構造と評価方法

ポリシーの基本構造

ポリシーはJSONで表現され、主にStatementの配列で構成されます。各Statementは次の要素を持ちます。
– Effect：AllowまたはDenyを指定します。明示的なDenyが優先されます。
– Action：許可・拒否するAPI（例：s3:GetObject）を指定します。
– Resource：対象リソースのARN（例：arn:aws:s3:::example-bucket/*）を指定します。
– Principal：誰に対するポリシーか（リソースベースのみ）。
– Condition：アクセスの条件（IPやMFAなど）を指定します。
– Sid/Version：説明や互換性のための補助フィールドです。

Conditionの使い方（具体例）

Conditionは細かな制御を可能にします。よく使う演算子はStringEquals、Bool、IpAddress、ArnLikeなどです。例：
– 企業ネットワークからのみ許可：{“IpAddress”:{“aws:SourceIp”:”203.0.113.0/24″}}
– MFA必須：{“Bool”:{“aws:MultiFactorAuthPresent”:”true”}}
– 自分のユーザー名だけにアクセス許可：”Resource”:”arn:aws:iam::123456789012:user/${aws:username}”

ポリシー評価の流れ

AWSはリクエスト時に全ての関連ポリシーを評価します。評価の基本ルールは次の通りです。
1. 明示的なDenyがあれば拒否されます。
2. Allowがあれば許可されます。
3. いずれでもなければ暗黙のDenyとなります。
これにはアイデンティティベース、リソースベース、セッションポリシー、権限境界、Service Control Policyなどが含まれ、組み合わされて最終判定を行います。