IAM の評価論理をやんわり押さえるセッション「やんわり押さえよう IAM の評価論理」で登壇しました #devio2021

---

【やんわり】（副詞） ━ものやわらかであるさま。おだやかなさま。
（デジタル大辞泉より）

---

コンバンハ、千葉（幸）です。

皆さんは IAM の評価論理って難しいと思っていませんか？

実は……

…

　……

　　………

その通り、難しいんです。

やれアインディティベースポリシーとリソースベースポリシーだの、アカウントをまたぐまたがないだの、ガードレールがどうだの、暗黙的だの明示的だの、覚えることがたくさんあって難しいです。

詳細な内容は必要に迫られたときに考えるとして、「だいたいこういうことでしょ」とやんわり理解する状態を本セッションでは目指していきます。

セッションの雰囲気

これが……

こうなる感じ雰囲気のセッションです。

セッションで学べること

章ごとにサマリを描きます。

1. IAM JSON ポリシー

• IAM のポリシータイプは 6 つあること
• IAM JSON ポリシーの構成要素として Effect、Principal、Action、Resource などがあること
• 評価論理は以下のいずれかとなること
  • 暗黙的な拒否
  • 明示的な許可
  • 明示的な拒否

2. 同一アカウントでの評価論理

• 同一アカウントで以下のポリシータイプのみが評価対象の場合、いずれかで Allow があれば明示的な許可となること
  • アイデンティティベースポリシー
  • リソースベースポリシー
• リソースベースポリシーでの Allow はアカウント単位かエンティティ単位かで評価結果が変わる場合があるということ
• Allow と Deny の両方があった場合、Deny が優先され明示的な拒否となること

3. クロスアカウントでの評価論理

• クロスアカウントの場合、以下の両方で Allow がないと明示的な許可とならないこと
  • アイデンティティベースポリシー
  • リソースベースポリシー
• クロスアカウントアクセスのためにスイッチロールという仕組みが使われることが多いこと

4. ガードレール

• 今回取り上げるポリシータイプのうち、以下のポリシータイプはガードレールとして機能すること
  • Organizations SCP
  • Permissions boundary
• ガードレールそのものでは Allow が与えられず明示的な許可とならないこと
• ガードレールで Allow がないものは以下の両方で Allow があっても暗黙的な拒否となること
  • アイデンティティベースポリシー
  • リソースベースポリシー
• Permissions boundary はアイデンティティベースポリシーが評価対象となる場合にのみ評価対象となること

5. 異端！VPC エンドポイントポリシー

• VPC エンドポイントポリシーもガードレールとして機能すること
• 分類上はリソースベースポリシーだけどちょっと異端だなと筆者が思っていること

セッションの動画

まったくどうでもいい情報ですが、収録した音声を 1.07 倍速にしているので私の地声より若干高いです。

セッションの概要

資料を引用しつつ概要を説明します。

1. IAM JSON ポリシー

IAM において、ポリシーは 6 つのポリシータイプに分類されます。

• IAM でのポリシーとアクセス許可 - AWS Identity and Access Management

このうちアクセスコントロールリストを除く 5 つのポリシータイプは JSON ポリシーとなっており、ほとんど共通した要素を持っています。

• IAM JSON ポリシーの要素のリファレンス - AWS Identity and Access Management

JSON ポリシー要素が正しい形で定義されていれば、各ステートメント内の Effect 要素により Allow もしくは Deny が与えられます。（例えば Action 要素の値に対応していない Resouce 要素の値を定義していると無効な定義となり、 Allow も Deny も与えられません。）

Allow もしくは Deny の組み合わせにより、リクエストは「暗黙的な拒否」「明示的な許可」「明示的な拒否」のいずれかの評価となります。

2. 同一アカウントでの評価論理

この章では同一アカウントでのアイデンティティベースポリシーとリソースベースポリシーの組み合わせにおける評価論理について考えます。

以下のようなケースを……

このようないらすとで考えます。

暗黙的な拒否

両者で Allow がない状態では、暗黙的な拒否となりリクエストは失敗します。

明示的な許可

どちらか一方で Allow があれば、明示的な許可となりリクエストは成功します。

ここで、リソースベースポリシー側で Allow を与えるためにはアカウント単位の許可ではなくエンティティ単位の許可が必要です。ここでのエンティティとは、IAM ユーザーや IAM ロール、それを引き受けたセッションなどを指しています。

• IAM ロールとリソースベースのポリシーとの相違点 - AWS Identity and Access Management

リソースベースポリシーでは以下のような形式でアカウント全体を示すプリンシパルを定義できますが、これだけでは IAM エンティティに対する Allow は与えられていません。

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

"Principal": { "AWS": "123456789012" }

例えば IAM ユーザーに対するエンティティ単位の許可を与える場合、プリンシパル要素を以下のように定義します。

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }

• AWS JSON ポリシーの要素: Principal - AWS Identity and Access Management

また、アイデンティティベースポリシー側で Allow がある場合、リソースベースポリシー側でまったく Allow が必要ないか（アカウント単位の許可は必要ではないか）はリソース種別により考え方が異なる場合があります。

大枠では「同一アカウントではどちらか一方でOK」とイメージしつつ、細部は各サービスごとに詳細を確認するようにしてください。

明示的な拒否

どちらか一方で Deny があれば他方の状態に関わらず明示的な拒否となります。Allow より Deny が優先度高く解釈されるため、一つのステートメントで Allow と Deny が同居している場合にも明示的な拒否となります。

これはアイデンティティベースポリシーとリソースベースポリシーの関係だけにとどまらず、すべてのポリシータイプで共通する考え方です。

• ポリシーの評価論理 - AWS Identity and Access Management

3. クロスアカウントでの評価論理

クロスアカウントにおけるアイデンティティベースポリシーとリソースベースポリシーの組み合わせを考えます。

基本的には同一アカウントの場合と変わりませんが、両方で Allow が必要という点が明確に違います。

• クロスアカウントポリシーの評価論理 - AWS Identity and Access Management

片方だけでの許可だと暗黙的な拒否となります。

クロスアカウントアクセスの場合、対向のアカウントに存在する IAM ロールを引き受けてスイッチロールする、というパターンもよく使用されます。

その場合、IAM ロールを引き受ける際に両方での許可が必要となります。

4. ガードレール

ガードレールとして機能するポリシータイプとして以下を取り上げます。

• Organizations SCP
• Permissions boundary

これらのポリシーで Allow が与えられていても、それだけで明示的な許可という結果にはなりません。あくまでアイデンティティベースポリシーもしくはリソースベースポリシーで Allow があった上で、その上限を設けるために機能するのがガードレールです。

アイデンティティもしくはリソースで Allow があるけれどもガードレールで Allow がない、という場合には暗黙的な拒否となります。

Organizations SCP

AWS Organizations の機能を使用する場合、管理対象の AWS アカウントに 1 つ以上の SCP が適用されます。アカウント内のすべてのエンティティによるアクションは SCP による評価を受けます。

Organizations SCP で Allow があれば他のポリシータイプの評価が行われますし、なければその時点で暗黙的な拒否となります。 SCP で Deny があればもちろん明示的な拒否となります。

Permissions boundary

Permissions boundary はアクセス許可の境界とも呼ばれ、IAM ユーザーもしくは IAM ロールに関連づけて使用します。

アイデンティティベースポリシーとセットで考えると理解が進みやすいかと思います。リソースベースポリシー側の許可の有無、クロスアカウントか否かにより挙動が変わります。

• IAM エンティティのアクセス許可の境界 - AWS Identity and Access Management

同一アカウントでリソースベースポリシー側での Allow がない場合、ガードレールとして機能します。Permissions boundary で Allow が無いと暗黙的な拒否となる、といった部分は Organizations SCP と同じです。

同一アカウントでリソースベースポリシー側で Allow がある場合、Permissions boundary で Allow がなくても明示的な許可となります。

クロスアカウントの場合は両方での Allow が必要となりますので、Permissions boundary も評価対象となります。

以下資料の　P50,P55 を見ると理解がしやすいかと思います。

5. 異端！VPC エンドポイントポリシー

分類としてはリソースベースポリシーになるものの、少し特殊な扱いとなるのが VPC エンドポイントポリシーです。

• VPC エンドポイントでサービスへのアクセスを制御する - Amazon Virtual Private Cloud

これは Organizations SCP や Permissions boundary のようなガードレールとして機能するものとイメージするとわかりやすいかと思います。

エンティティが VPC 上からリクエストを実行し VPC エンドポイントを経由してサービスエンドポイントに到達する場合には、新たな評価軸が一つ加わる、というイメージです。

まとめ

リクエストを実行する際にいろんなポリシータイプが評価対象になることがあります。

組み合わせが複雑になると評価論理を追うのが難しくなりますが、基本的な考え方を押さえておきましょう。

セッションの資料

IAM の評価論理、完全に理解した

ここまでで IAM の評価論理についてやんわりと理解いただけたかと思います。やんわりと理解できたということは完全に理解したということとほぼ等しいかと思います。

細かいところはいくらでも掘る余地が残っているのですが、まずは全体像として各ポリシーの関係性を理解していただけるようになっていれば幸いです。

みなさんが IAM の評価論理について考える度、警備員さんや門番の姿が頭にチラつく状態になっていることを祈っています。

以上、 チバユキ (@batchicchi) がお送りしました。