IAMによるAWS権限管理 – IAMポリシーの記述と評価論理

よく訓練されたアップル信者、都元です。本日は、IAMユーザやロール等に与えられるポリシーについて。

IAMは、AWSの操作に関するIDと権限を管理するためのサービスです。IAMユーザ等を作ることにより、そのIDで「誰が操作を行うのか」というアイデンティティを管理し、ポリシーによって「その主体はその操作を行う権限があるのか」を管理します。

関連エンティティの整理

IAMの世界には、ユーザ・グループ・ポリシー等のエンティティが出てきますので、まずはその関係を整理しましょう。

左の方はそこそこ理解しやすいと思います。ユーザはグループに所属でき、多対多の関係があります。ロールについては別エントリIAMロール徹底理解 〜 AssumeRoleの正体を御覧ください。

各ユーザ・グループ・ロールには、複数の「ポリシー」と呼ばれるものを0個または複数個付与できます。ポリシーというのは1つのJSONドキュメントで、下記のような形式です。

{
  "Version": "2012-10-17",
  "Statement": [...]
}

これを見ると分かると思いますが、ポリシーというのは0個または複数個の「ステートメント」から構成されています。もちろん上記の...の部分に記述されるものなので、ステートメントもJSON形式のドキュメントです。

{
  "Effect": "Allow",
  "Action": [
    "s3:ListAllMyBuckets"
  ],
  "Resource": [
    "arn:aws:s3:::*"
  ]
}

この中身を見てみると、ステートメントはEffect, Action, Resourceで構成されているのが分かると思います。Effectの値はAllowまたはDenyの何れかで、ActionとResourceは複数の指定ができます。

結果として、1つのステートメントは「あるリソースに対する、あるアクションを、許可する（または拒否する）」という表現ができます。

あるアイデンティティ（ユーザやロール）には、最終的に複数のステートメント（ステートメントの集合）が紐づく構造になっていることが分かるでしょう。

評価論理

各ポリシーそれぞれの結果の出し方

あるアイデンティティがリソースXに対してアクションYを実行しようとした際に、まず、そのアイデンティティに付与された全てのポリシーがそれぞれ評価されます。各ポリシーの評価結果は「明示的拒否 (explicit deny)」「許可(allow)」「デフォルト拒否 (default deny)」の何れかとなります。

前述の通り1つのポリシーには複数のステートメントが含まれています。それぞれのステートメントについて評価を行い、許可ステートメントがあるかないか、拒否ステートメントがあるかないか、という2つの真偽値にまで落とし込みます。

結局、拒否ステートメントがある場合、何はともあれ「明示的拒否」となります。明示的な許可の有無は関係ありません。次に、許可ステートメントがある場合は「許可」となります。該当するステートメントが1つも無い場合は「デフォルト拒否」となります。

最終結果の出し方

全てのポリシーを評価した結果、明示的拒否が1つでもあった場合、最終結果は拒否となります。許可がいくつあっても関係ありません。明示的拒否のほうが優位です。

次に、明示的拒否が1つも無かった時、許可が1つでもあれば、最終結果は許可となります。デフォルト拒否はいくつあっても関係ありません。

残ったケースとして、明示的拒否が0個、許可が0個、つまりは全てデフォルト拒否だった場合。これは最終結果は拒否となります。

まとめ

AWSのAPIコールがある毎に、このような評価を行い、操作の可否を判断しているんですね。この評価論理が分かっていないと、ポリシーを書きミスって、セキュリティに問題のあるシステムを作ってしまいかねません。ポリシーを書く場合は必ず理解しておきたいですね。

参考文献

IAM ポリシーの評価論理