はじめに

カミナシの認証認可チームのmanaty（@manaty226）です。今年もラスベガスにて12月1日から12月5日まで開催されているre:Inventに参加しています。この記事では、２日目に参加した以下のセッションについて記載します。

A deep dive on IAM policy evaluation [REPEAT] (SEC402-R1)

IAMポリシーの基本的な構文

本セッションはIAMポリシーの構文がAWS IAMによってどのように評価されるか、実際のポリシー例をもとに順を追って理解を深めていくセッションでした。まずは基本的なIAMポリシーの構文説明から始まります。

IAMポリシーはEffect、Action、Resource、Principal、Conditionの5つの句を基本として構成されます。使用頻度がそれほど高くないのはCondition句でしょう。Condition句は、Operatorと呼ばれる条件演算子（写真中のOperator）をキーとして、条件演算子の評価対象（写真中のKey）と評価値（写真中のValues）のオブジェクトをバリューとしてもちます。

本セッションでは、このCondition句を対象として、以下の2つについて深堀りしていきます。

Condition句の内容によって記述されたポリシーの評価がどう変化するか
リソースポリシーとアイデンティティポリシーのポリシーチェインとCondition句によるポリシーチェインへの影響

Condition句におけるNull値の注意

まず、Condition句では同一の条件演算子の評価対象に対して複数の評価値が記述された場合（上記写真中のValuesのような記述）の場合はOR評価となり、条件演算子内の複数の評価対象や複数の条件演算子に対してはAND評価を行います。

まず、文法的な誤りで多い例として、複数値を持つ評価対象にしか利用できない条件演算子があるということです。セッションでは例えば ForAnyValues やForAllValues という演算子がaws:TagKeysという複数値を持つ対象に利用できることを示しています。一方で、同じようにタグを示すaws:tag-keyは単一値を前提としたキーのため利用できません。

さて、この複数値評価演算子には注意点があります。例えば、ForAllValues を設定した評価対象（例えばタグ）がリクエスト時には存在しなかったらどうなるでしょうか。この場合、真であると評価されて、状況によっては意図しない対象に権限を付与してしまうことになります。これは、論理学で空虚な真と呼ばれるものに基づく動作です。集合論的には、空集合があらゆる集合の部分集合であるという整理でしょうか。ForAnyValuesの場合は偽となります。このように、ForAllValues や ForAnyValues のような複数値に対する演算子を設定した場合は、以下のようにNull値だった場合の判定動作を入れておくと安全に利用できるようです。

リソースポリシーによるポリシーチェインの変化

AWS IAMのポリシー評価の基本的な戦略は、

明示的な許可が1つ以上ある場合、明示的な拒否がなければ許可する
許可、拒否いずれも適合しなければ暗黙的に拒否する
1つ以上の拒否があれば拒否する

という形式になっています。

したがって、アイデンティティベースのポリシーがオーガニゼーション、アカウント、ロール、バウンダリ、セッションの順に評価されていくポリシーチェイン中で、1つ以上の許可と0個の拒否のとき、アクセスが許可されるという動きになります。

さて、このとき例えばS3バケットやオブジェクトに個別に付与できるリソースポリシーが存在する場合、このポリシーチェインはどのような動きになるでしょうか。リソースポリシーは、Principalに設定されたアイデンティティのタイプによって、ポリシーチェインをバイパスする動きをします。例えば、リソースポリシーのPrincipalに”AWS”: “<role_arn>”という設定がされると、オーガニゼーションとアカウント、ロールの許可に関するポリシー評価はバイパスされてます。一方で、明示的な拒否がポリシーチェインのバイパスする手前にかかれている場合は、拒否が優先されます。図はPrincipalに*などが記載されてセッションまでバイパスされている例を示しています。

それでは、リソースポリシーに対するPrincipalの条件をPrincipal句とCondition句に書くのでは、ポリシーチェインの動作にどのように影響するでしょうか。

例えば下図左のようにPrincipal句にアカウントIDを書いた場合、ポリシーチェインのアカウントまで許可判定がバイパスされますが、ロールからは通常通りポリシー判定が実行されるため、ロールによる権限管理が効いてきます。一方で、下図右のようにPrincipal句に*を入れた場合、ポリシーチェインのセッションまでバイパスされてしまうため、状況によっては意図せず過大な権限を設定してしまうということが発生するようです。

みなさんも、これで下図のポリシーの違いがはっきりと分かるようになりましたよね？

おわりに

今回はIAMポリシーにおけるCondition句の複数値条件における条件演算子の動きと、リソースポリシーを含む場合のポリシーチェインの評価動作について理解を深めるセッションのレポートを書きました。何となく分かっていたつもりでしたが、このセッションでより明確に理解できた気がしています。気がするだけで、もし間違っているところがあれば教えて下さい。

カミナシでは、IAMポリシーの評価に匹敵するほど難しい、ポケモンカードの裁定に詳しいソフトウェアエンジニアも募集しています。ご興味がある方はカジュアル面談からよろしくお願いします。