はじめに
IAMポリシーやS3のバケットポリシーなどの権限回りはポリシージェネレータを使用したりググったりしてそこまで理解せずにやってきましたが、その度に毎回調べているので、どこかにまとめて整理しておきたいなと思い、備忘がてら書きます。
公式からの引用多いです。
目次
関連用語
今回のポリシーの話を書くにあたって、エンティティやリソースといった用語が出てきますが、それぞれ何のことかよくわからなくなるので、最初に書いておきます
| 用語 | 説明 |
|---|---|
| リソース | いわゆるAWSサービス(IAM等)のこと。リソースはオブジェクトというもので構成されている |
| IAMリソース | IAM関連のリソースのこと。ユーザー、グループ、ロール、ポリシーなどのオブジェクトで構成されている |
| アイデンティティ | アクセス許可を定義するIAMリソースのこと。上記オブジェクトが指定される |
| エンティティ | AWSによって認証に使用されるIAMリソースのこと。上記オブジェクトのユーザー、ロール等が指定される |
| プリンシパル | エンティティを通じてAWSにサインインしてリクエストを行う人、アプリケーションのこと。 |
参照先はこちら
docs.aws.amazon.com
ポリシーとは
AWSではIAMユーザが使用可能なサービスを制限したり、S3バケットにアクセス可能なサービス・ユーザ等を制御できますが、それらを制御する際はJSON形式で記述されたポリシーというもので詳細に設定することが可能です。
AWSのポリシーの定義は以下のようになっています。
ポリシー は AWS のオブジェクトであり、エンティティやリソースに関連付けて、これらのアクセス許可を定義します。 AWS は、ユーザーなどのプリンシパルがリクエストを行ったときに、それらのポリシーを評価します。ポリシーでのアクセス許可により、リクエストが許可されるか拒否されるかが決まります。 大半のポリシーは JSON ドキュメントとして AWS に保存されます。
参照先はこちら
docs.aws.amazon.com
ポリシータイプ
ポリシーについてざっくり確認しましたが、ポリシーには複数のタイプが存在します。 また、それらのタイプは２種類に分類分けすることができます。
それぞれの分類の説明は以下の通りです。
* アクセス許可ポリシー
AWSのリソースに直接アタッチし、そのリソースへのアクセス許可を定義する。 例えばS3バケットポリシーはアクセス許可ポリシーなので、対象のS3バケットへのアクセスをポリシーで制御することができる。 だたし、逆にS3から他のリソースへのアクセスについては制御ができない。
* アクセス許可の境界
ポリシーをアタッチすることでエンティティ(ユーザ/ロール)のアクセス許可(どのリソースにアクセスできるか)の境界を定義する。 例えば特定のIAMユーザーにS3へのフルアクセスを許可するポリシーをアタッチすることで、そのIAMユーザーでS3バケットや格納されたオブジェクトにアクセスができる。
それぞれの分類に応じて、各ポリシータイプも分類ごとに分けることができます。
分類ごとのポリシータイプは以下の通りです。
アクセス許可ポリシー
| ポリシータイプ名 | 説明 |
|---|---|
| アイデンティティベースのポリシー | 管理ポリシー、インラインポリシーをIAMアイデンティティ(ユーザー、グループ、ロール)にアタッチ可能 |
| リソースベースポリシー | AWSの一部リソースにインラインポリシーをアタッチ可能(S3やIAM等) |
| アクセスコントロールリスト(ACL) | ACLを使用してリソースにアクセスできるプリンシパルをコントロール可能(JSON構造を使用しない唯一のポリシータイプ) |
アクセス許可の境界
| ポリシータイプ名 | 説明 |
|---|---|
| 組織のSCP | AWS Organizationsで使用されるポリシーでアクセス許可の境界を組織単位に適用可能 |
| IAMユーザ/IAMロール | ユーザーまたはロールのアクセス許可の境界としてポリシーを使用可能 |
※１つ特筆すると、IAMユーザーとロールに関してはどちらの分類にも存在しており、両方の性質を持ったポリシーになります。
アクセス許可ポリシー
2種類のポリシーの分類とそれに紐づくポリシータイプについて記載しましたが、その中でもアクセス許可ポリシーに分類されている３つのポリシータイプはよく利用されます。
そのうち、２つのポリシータイプはさらに細かく分類することができます。
アイデンティティベースのポリシー
| ポリシー名 | 説明 |
|---|---|
| 管理ポリシー | IAMユーザ、グループ、ロールにアタッチ可能なスタンドアロンなポリシー。AWSが管理するAWS管理ポリシーとAWSアカウントで特定のアクセス許可を作成管理するカスタマー管理ポリシーの２種類がある |
| インラインポリシー | AWSアカウントで特定のアクセス許可を作成管理するポリシーだが、IAMユーザ、グループ、ロールに直接埋め込んで設定する。非推奨 |
リソースベースのポリシー
| ポリシー名 | 説明 |
|---|---|
| インラインポリシー | リソースベースはインラインポリシーのみ。指定したプリンシパルが実行可能なリソースと条件を制御する |
ここまでのまとめ
確認してきたポリシーについて、簡単に図示化してみました。
概念的なところですが、それぞれの可能なこと不可能なことがイメージできたので、多少は理解が進んだ気がします。
括弧の中は対象となるリソースを記載しています。
プリンシパルからAWSリソースを操作するまでの流れ
ざっくりポリシーとその種類について確認できたところで、実際にどのような流れで認証・許可されてAWSサービスが操作されているのか、公式の図を元に説明を追加してみました。
こう見てみると、以下のように複数の認証で制御されているのがよくわかります。
①リクエストを送るための認証(ログインやアクセスキー)
②対象リソースへアクセスするための認証(ポリシー)
③リクエストされたリソースへのアクション(オペレーション)を行うための認証
例えば特定のS3バケットにIAMユーザがコンソールからアクセスしてバケット内のオブジェクトを確認しようとした場合に、
・そもそもログインできないとアクセスできない(①)
・IAMユーザにアタッチされたポリシーでS3サービスへのオペレーション許可がないと操作できない(②)
・S3のバケットポリシーで対象バケットへのアクセス許可がないとアクセスできない(③)
という３つの認証が正しくされていないと、アクセス自体が拒否されてしまいます。
もしかしたら知識不足で他にも要因があるかもしれませんが、アクセスができないときはどの部分で拒否されているのかをまず確認してみてみようと思います。
参照先はこちら
docs.aws.amazon.com
まとめ
本当はもっとさっくりまとめるはずが、調べていくと全然情報が多すぎてさっくりまとめきれませんでした。。
