クラウド

AWS IAMロールとポリシーの違いとは？使い分けと許可の決まり方

2026/10/16 （更新: 2026/10/17） シリーズ「AWS 入門」 第3回 / 全4回

🤖 AIを使用して執筆

IAM ポリシーとは：何を許すかを書いた文書

IAM（Identity and Access Management）は、AWS のアカウントの中の ID と、その権限を管理するサービスである。IAM ポリシーは、権限を書いた文書で、ほとんどは JSON の形で書く¹。文ごとに、許すか拒むか（Effect）、操作（Action）、対象のリソース（Resource）を書き、必要なら条件（Condition）を加える²。あるバケットのファイルを読むことだけを許すポリシーは、次のようになる。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

arn:aws:s3:::example-bucket/* は、このバケットのすべてのファイルを表す。* は「すべて」を表す記号で、ワイルドカードと呼ぶ。

ポリシーは、付ける先で二つに分かれる。ユーザーやロールなどの ID に付けて、その ID が何をできるかを書くものを ID ベースのポリシーと呼ぶ。S3 のバケットなどのリソースに付けて、誰がそのリソースを使えるかを書くものを、リソースベースのポリシーと呼ぶ¹。

IAM ロールとは：信頼ポリシーと権限ポリシーを持つ ID

IAM ロールも ID の一つである。AWS は、ロールには二つのポリシーを付けると説明している³。

• 信頼ポリシー：誰がそのロールを引き受けられるかを決める³。
• 権限ポリシー：ロールを引き受けた者が何をできるかを決める。AWS の日本語の文書では「アクセス許可ポリシー」と呼ぶ³。

ロールを使う側は、ロールを引き受ける（AssumeRole）操作をして、期限のある認証情報を受け取る。期限が切れた認証情報は使えなくなる⁴。

ロールとポリシーの違いは、次のようにまとめられる。ポリシーは、何を許すかを書いた文書で、それだけでは誰も使えない。ロールは、ポリシーを付ける ID で、決まった誰か一人のものではなく、信頼ポリシーが認めた相手が、必要なときに引き受けて使う。

ロールは 2012 年 6 月に、EC2 で動くプログラムにアクセスキーを配る手間をなくす仕組みとして加わった。認証情報の受け渡しと入れ替えは、AWS が自動で行う⁵。

ロールとポリシーの使い分け：相手ごとの渡し方

AWS は、人の利用者にも、AWS の上で動くプログラムにも、期限のある認証情報を使わせるよう求めている⁶。そのため、権限は多くの場合ロールを通じて渡し、渡す相手によって仕組みを使い分ける。

人の利用者については、AWS は IAM Identity Center で、アカウントへのアクセスと権限を一か所で管理するよう勧めている⁶。Identity Center で「権限セット」を割り当てると、各アカウントに IAM ロールが作られ、権限セットのポリシーがそのロールに付く⁷。

外部の会社については、外部 ID を使う。外部 ID は、外部の会社が顧客ごとに決める識別子で、秘密の値ではない⁸。顧客は、自分のロールの信頼ポリシーに「この外部 ID が付いた依頼だけを認める」と書く。こうしておけば、別の顧客が他人のロールを指定して外部の会社に依頼しても、その依頼には別の顧客の外部 ID が付くので、他人のロールは引き受けられない。AWS は、外部 ID で防ぐこの問題を「混乱した代理」の問題と呼んでいる⁹。

許可の決まり方：既定は拒否、明示的な拒否が優先

リクエストに複数のポリシーがかかるとき、AWS は次の三つの規則で判定する¹⁰。

1. 既定は拒否する。 どのポリシーも許していないリクエストは拒否される。これを暗黙の拒否と呼ぶ。アカウントを作ったときの ID であるルートユーザーは、この既定の拒否の対象にならない¹⁰。
2. 明示的な拒否が一つでもあれば拒否する。 どの種類のポリシーでも、当てはまる「Deny」が一つあれば、ほかにどんな許可があっても拒否になる¹⁰。
3. 許可は、原則として、与えるポリシーと上限のポリシーの両方を満たすときに出る。 許可を与えるポリシーのどれかに「Allow」があり、上限を決めるポリシーがあればそのすべてが許しているとき、リクエストは許可される¹⁰¹¹。

ポリシーは、この判定での働きで二つに分かれる¹。

同じアカウントの中では、原則として、許可を与えるポリシーは、どれか一つに許可があれば足りる。上限のポリシーは、すべてが許していなければならない¹¹。ただし、ロールを引き受けるときは、ID ベースのポリシーに許可があっても、信頼ポリシーがその相手を許していなければ引き受けられない¹⁰。

AWS の Well-Architected フレームワークは、セキュリティの柱の最初の設計原則で、最小権限の原則を実装するよう求めている¹²。既定で拒否する仕組みの下では、許可を書いた操作しか通らないので、必要な操作と、必要なリソースだけを書けば、権限は最小になる。

ポリシーは、人の手では確かめにくい

規則は短くても、ポリシーが実際に何を許すかを確かめるのは難しい。AWS の Neha Rungta は 2022 年の論文で、一つのポリシーでも、文と条件が多いと、文どうしの働きを人の手で確かめるのは難しいと書いている¹³。実務者の Scott Piper は 2019 年に、IAM のポリシーは書くのも理解するのも難しく、AWS 自身もときどき誤ると書いた¹⁴。Policy Sentry の作者 Kinnaird McQuade は、手で書く手間が大きいので、利用者は AWS が用意した既製のポリシーやワイルドカードに頼りがちだと書いている¹⁵。

AWS は、この問いに計算で答える道具を作った。2018 年に論文で報告した Zelkova は、ポリシーを数学的に解析して、「このリソースに、特定の利用者はアクセスできるか」といった問いに答える¹⁶。2019 年に公開した IAM Access Analyzer は、論理と数学による推論（自動推論）で、リソースのポリシーが許すすべてのアクセスの経路を求める¹⁷。Rungta によれば、AWS は問いを「このポリシーは正しいか」から「誰がアクセスできるか」に変え、Zelkova を土台に Access Analyzer を作った。道具は誰がアクセスできるかの一覧を示し、セキュリティの担当者が、それぞれを直すべきか、認めてよいかを判断する¹³。

ポリシーは何を許すかを、ロールは誰が使うかを決める

IAM のポリシーは、どの操作を、どのリソースに許すか、または拒むかを書いた文書である。IAM ロールは、ポリシーを付ける ID で、信頼ポリシーが認めた相手が引き受け、期限のある認証情報で使う。AWS は、人には IAM Identity Center を、プログラムにはサービスに付けるロールを、外部の会社には外部 ID を条件にしたロールを使うよう勧めている。

AWS は、リクエストを既定で拒否し、明示的な拒否を優先し、許可を与えるポリシーと上限を決めるポリシーを重ねて判定する。重ねることで、組織とアカウントの管理者が、それぞれの範囲で権限を絞れる。その代わり、ポリシーが実際に何を許すかは目で追いにくく、AWS は、あるリソースに誰がアクセスできるかを計算して一覧にする道具を用意している。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。