本記事は、当社オウンドメディア「Doors」に移転しました。
約5秒後に自動的にリダイレクトします。
今回はCFTのAWSチームが、AWSのポリシーの種類と、同一アカウント内でのアクセス設定値の評価論理についてご紹介します！
こんにちは！新卒入社2年目、ITコンサルタントの神里です！
この記事では、AWSのポリシーについて扱います。
「アクセス制限かけたいんだけど、とうやればいいの？」
といった悩みを持つ方に向けた内容です。
AWSのポリシーは選択肢も多く、どうすればいいのかわからないですよね。
ただ、複雑だからこそ多様な要件に柔軟に対応できるのだと思います。
適切なアクセス制御を実現するために、そして、大切なデータを守るために、私が携わっている案件でも特に力を入れて検証を重ねている分野の1つです。
今回その検証で培ったナレッジ共有として
①ポリシーの種類と役割
②アクセス制御設定値の種類と評価論理
について取り上げています。何かのお役に立てたら幸いです♬
それでは行きますよー！！
1. ポリシーの種類と役割
AWSで良く使うポリシーの中には、大きく分けると「アイデンティティベースポリシー（IDベースポリシー）」と「リソースベースポリシー」の2種類がありますね！まずはその2種類の違いを確認してみましょう。
IDベースポリシー（IAMポリシー）
IAMユーザーやグループ、ロールといった、アクセスする側に付与するポリシーです。「どのリソースにアクセスし、どういうことまでやっていいよ」と、権利を与えることができます。管理者と閲覧者に与える権利は異なりますよね。そういう時に使用します。
「MFA認証（多要素認証）していないとアクセスさせないよ」といった条件をつけることもできます。
リソースベースポリシー
AWSサービスのリソースに付与するポリシーです。代表例はS3のバケットポリシーですね！その名の通り、リソースごと（バケットポリシーならS3バケットごと）に付与するので、設定が大変ではありますが、最終防衛ラインの重要な役割を担っています。リソースベースポリシーが適切に設定されていれば、ユーザーに誤って強すぎる権限を与えてしまった場合でも、想定外のアクセスをブロックすることができます。リソースベースポリシーも条件を絞ったアクセス許可が設定できます。
私は最初、貴族の晩餐会を思い描きました(笑)
IDベースポリシーが招待状です。招待状がなければ行く権利がありません。
リソースベースポリシーはセキュリティチェックをするガードマンです。例え招待状を持っていてもドレスコードを守っていない人は入れません。
招待状を持ち、ガードマンのチェックをクリアした者だけが晩餐会に参加できるのだと捉えました。
ただし、設定によっては、ガードマン（リソースベースポリシー）が招待状（IDベースポリシー）を持たないお客さんを通すこともできます。
ここでは、ポリシーは大きく2種類あり、その違いについて説明しました。次は、各ポリシーのアクセス制限に対する設定値について触れてみます。
2. アクセス制限設定値の種類と評価論理
実は、アクセス制限の設定値（各ポリシーの”Effect”に相当します）は全部で3種類あります。
①設定しない（デフォルト）
②許可
③拒否
それぞれ、公式ドキュメントでは、①implicit deny、②explicit allow、③ explicit deny と表現されています。今回の記事では、①暗黙的拒否、②明示的許可、③明示的拒否、と訳して説明していきます。
では、それぞれの設定値の関係性はどうなっているのでしょうか？
今回は、同じAWSアカウント内での、評価のされ方を解説していきます。
※クロスアカウント（複数のアカウントをまたいだ利用）での評価論理と、アクセス制御の考え方は次回掲載予定です。
公式ドキュメント「Policy evaluation logic（ポリシーの評価論理）」を見てみましょう。そこには以下のような記載がありました。（参考：ポリシーの評価論理）
- By default, all requests are implicitly denied with the exception of the AWS account root user, which has full access.
- An explicit allow in an identity-based or resource-based policy overrides this default.
- If a permissions boundary, Organizations SCP, or session policy is present, it might override the allow with an implicit deny.
- An explicit deny in any policy overrides any allows.
初見では「何言ってるの？」ってなりますよね(笑)。私も画面を鋭い眼光でにらみつけていました。
私なりに以下のように簡単にまとめてみました。※ルートユーザーやpermissions boundaryなどの要素は抜いています。
①デフォルトは暗黙的拒否
②明示的許可が暗黙的拒否を上書きする
③明示的拒否は全てのポリシーの全ての明示的許可を上書きする
つまり、明示的拒否が最強で、次点で明示的許可、最弱が暗黙的拒否（デフォルト）ということです。
明示的拒否 ＞ 明示的許可 ＞ 暗黙的拒否（デフォルト）
設定値の種類とその評価論理が分かってきました。続いてポリシーの種類との組み合わせを整理していきたいと思います。
3.複数のポリシーとアクセス制御設定値の組み合わせ
ポリシーが２種類で、それぞれ設定値が3種類ありますので、組み合わせは9通りです。
まず、評価論理上で最強の「明示的拒否」について考えてみます。
以下は公式ドキュメントで紹介されている詳細な評価論理です。
Figure 1. Details about how the decision is made (参考：ポリシーの評価論理）
左上がスタートで、まず対象となるポリシーを評価します。そして１番最初に「Is there an explict Deny?」という条件分岐がありますね。そして「Yes」の場合は「Deny」となっています。対象のポリシーはどれでもいいから明示的拒否があれば、即Deny！なのです。
9通りの内、5通りが埋まりました。
続いて、暗黙的拒否と明示的許可について確認していきます。同一アカウント内での評価論理は公式ドキュメントで以下のように紹介されています。
どちらかのポリシーが明示的許可を設定すると、アクセスできるということです。どちらも暗黙的拒否（デフォルト）の状態であれば、アクセスできません。これで残り4通りも埋まりました。まとめると以下のようになります。
5. さいごに
今回はAWSのポリシーについて、ポリシーの種類と、同一アカウント内でのアクセス設定値の評価論理についてまとめてみました。次回はクロスアカウント（複数アカウント）での、バケットポリシー設定方法とアクセス制御についてまとめてみたいと思います。
最後まで記事を読んでいただきありがとうございました！
ブレインパッドでは新卒採用・中途採用共にまだまだ仲間を募集しています。
ご興味のある方は、是非採用サイトをご覧ください！
www.brainpad.co.jp
