【PART5 IAMポリシー 破】ぜんぜんわからなかったIAMについてまとめてみました
こんにちはこぐまです。
ぜんぜんわからなかったIAMシリーズ5回目です。
前回は「IAMポリシー」「プリンシパル」「ポリシーの呼び方」についてお話ししました。
IAMポリシーはただの手紙であること。
手紙を受け取る相手のことをプリンシパルということ。
IAMポリシーはたくさんの呼び方があるが、常に3種類をセットにして表現するということ。
その3種類とは、
①手紙の使用用途での呼び方
②手紙の作り方での呼び方
③手紙を渡す（アタッチする）ときの呼び方
であるということを説明してきました。
今回はその3種類のうち「①手紙の使用用途での呼び方」ついて、より細かく見ていきたいと思います。
「①手紙の使用用途での呼び方」とは？
まずこれがポリシーの基本となります。
ポリシーというのはただの手紙なのですが、
その手紙が何用途なのか？何の目的で使用するのか？
という観点で命名されています。
使用用途は6種類あります。
１．アイデンティティベースのポリシー
２．リソースベースのポリシー
３．アクセス許可の境界
４．Organizations SCP
５．アクセスコントロールリスト（ACL）
６．セッションポリシー
マニュアルでの日本語訳をそのまま引っ張ってきました。
統一感がなくて、わかりにくいですが(笑)
ちなみに英語だと
１．Identity-based policies
２．Resource-based policies
３．Permissions boundaries
４．Organizations SCPs
５．Access control lists (ACLs)
６．Session policies
となっています。うん、英語でもそんなに変わらないですね。
では順番に説明していきます。
１．アイデンティティベースのポリシー
「アイデンティティ」とは、日常的にもよく言葉に出てきますが、「存在証明」「自分が自分であると認識すること」みたいな意味があります。「私」が「私」であるということを、「私」も「私以外の人達」も認めている・・みたいな感じです。
哲学的な話題になってしまいそうなので、この辺にしておきますが、AWSにおいて「アイデンティティ」とは「IAMユーザ」「IAMグループ」「IAMロール」のことを指します。
つまり、アイデンティティベースのポリシーとは、IAMユーザ、IAMグループ、IAMロールにアタッチするという目的で使用するポリシーのことを示しています。
２．リソースベースのポリシー
「リソース」とは、一般的に「資産・資源」という意味です。
AWSにおけるリソースとは、AWSサービスの実体のことを示しています。
例えば、「EC2サービス」における、「EC2インスタンス」とか、「S3サービス」における「S3バケット」とか、「ECRサービス」における、「ECRリポジトリ」とかです。
つまり、リソースベースのポリシーとは、AWSサービスの「実体」に対してアタッチするという目的で使用するポリシーのことを示しています。
ただし、リソースベースのポリシーをアタッチできるリソースは限られています。すべてのリソースにアタッチできるわけではありません。
また、リソースベースのポリシーには、その手紙の中に必ず「プリンシパル」が必要となります。
「プリンシパル」とは前回説明した通り、手紙を受け取る相手のことです。
つまり、このリソースベースのポリシーは誰向けなのか？を明記する必要があるということです。
ここまでの２つ（アイデンティティベース、リソースベース）のポリシーは、アタッチしたアイデンティティ（IAMユーザ、ロール、グループ）または手紙を受け取る相手（プリンシパル）に、手紙に書かれた権限を実際に付与します。
一方、この後に続く2種類のポリシーは、その者に対して、手紙に書かれた権限を実際に付与しません。
その者の行動範囲だけを決めるものであり、その者の実際の行動を認可するには、別途アイデンティティベースのポリシーが必要です。（※1）
（※1）
たぶん現時点ではちょっと難しいかもしれません。
わかりやすい例かどうかはわかりませんが、例えば、
A.あなたはどんな帽子をかぶってもよい。
B.あなたは、赤、青、黄色のものだけを身に着けられる
という２つのポリシーがあるとします。
Aをアイデンティティベースのポリシーとしてあなたにアタッチしただけであれば、あなたはどんな帽子もかぶることができます。
Bをアイデンティティベースのポリシーとしてあなたにアタッチしただけであれば、あなた赤、青、黄色のどんな衣装も帽子もアクセサリも身に着けられます。これが、「手紙に書かれた権限を実際に付与する」という意味です。
Aをアイデンティティベースのポリシーとしてアタッチし、Bを（後述する）アクセス許可の境界としてアタッチした場合・・どうなるのか・・？
というのが、この先に続く話です。
３．アクセス許可の境界
先に説明した通り、これと次のポリシーは、行動範囲だけを決めるポリシーです。この「アクセス許可の境界」というポリシーの使用用途は、
IAMユーザ、IAMロールに対して、行動範囲を狭める役割を持っています。(※2)
(※2)IAMグループにアクセス許可の境界をアタッチすることはできないようです。
例えばあなたに、EC2の全操作を許可するアイデンティティベースのポリシーがアタッチされているとします。これだけであれば、あなたはEC2に関しては何でもできます。
そこに加えて、もう一つポリシーを作ります。中身は以下です。
・EC2の一覧を表示（DescribeInstances）
・EC2を起動（StartInstances）
このポリシーを「アクセス許可の境界」として、あなたアタッチします。
するとあなたの行動範囲が限定されます。あなたはEC2に関する全操作を許可されていましたが、「アクセス許可の境界」が追加でアタッチされたことで、行動範囲が少なくなり、実際にできるのは、EC2の一覧表示と起動だけになってしまいました。
これがアクセス許可の境界です。
なお、先ほどの（※）の問題も併せてここで考えてみます。
A.あなたはどんな帽子をかぶってもよい。
B.あなたは、赤、青、黄色のものだけを身に着けられる
Aをアイデンティティベースのポリシーとしてアタッチし、Bをアクセス許可の境界としてアタッチした場合・・どうなるのか・・？
あなたは帽子に関しては全権限を持っている（すなわち何でもかぶれる）が、あなたの身に着けられる色は、赤、青、黄色だけである。
つまり、あなたは、赤、青、黄色に限りどんな帽子でもかぶれるということになります。これがアクセス許可の境界です。
また、アクセス許可の境界は、関連性のあるアイデンティティベースのポリシーとセットで使わなければ意味がありません。例えば以下のように全く関連性のない2つのポリシーがあるとします。
A.あなたはどんな帽子をかぶってもよい。
B.あなたはどんな服を着てもよい。
Aをアイデンティティベースのポリシーとしてアタッチし、Bをアクセス許可の境界としてアタッチした場合・・どうなるのか・・？
あなたは帽子に関しては全権限を持っている（すなわち何でもかぶれる）が、あなたの行動範囲は、好きな服を着ることだけである。（帽子をかぶるという行動は許された行動範囲外である）
つまり、あなたは何もできない！・・というのが答えになります。
これをAWSで当てはめると、
「アクセス許可の境界」と、「アイデンティティベースのポリシー」で異なるサービスを指定している場合、あなたは何もできなくなるということです。ですので、アクセス許可の境界を利用する場合は慎重にテストしたほうがいいのかなと思います。基本的には使用しないほうがいいかも・・と思います。
アクセス許可の境界を入れると、行動範囲外の操作は
たとえアイデンティティベースのポリシーで許可されていたとしても行動ができなくなる。
（ただし、同一アカウント内のリソースベースのポリシーは行動制限されない。
これについてはIAMの面白いところでもあります。また後日！）
４．Organizations SCP
アクセス許可の境界は、同一AWSアカウント内の境界でしたが、
こちらの「Organizations SCP」は、AWSアカウント間における境界を決めます。
AWSには、複数のAWSアカウントをまとめて管理できる「AWS Organizations」というサービスがあります。
ここでは詳細は述べませんが、まずすべての親となるマスターAWSアカウント（いわゆる親）を決めます。
その後、「組織単位（OU）」と呼ばれるユニットを定義していき、その配下に所属させるAWSアカウント（いわゆる子供たち）を決めます。
組織単位（OU）は入れ子もできます。こんなイメージです。
この組織単位（OU）に対してアタッチするポリシーが「Organizations SCP」です。つまり「Organizations SCP」とは、組織単位（OU）に所属するAWSアカウントの行動範囲を決めるという目的で使用するポリシーのことを示しています。
アクセス許可の境界で話した通り、あくまで行動範囲だけを決めるので、
実際の権限を付与するわけではありません。
組織下の各AWSアカウントのIAMユーザごとに、アイデンティティベースのポリシーを別途付与する必要があります。
組織SCPでの大きな特徴は２つあります。
１．組織下のAWSアカウントのルートユーザの行動範囲すら制限できる
２．階層上位の組織単位で明示的な拒否「だけ」をしてしまうと、配下の組織すべてで一切の行動ができなくなります。
これは認定試験でもよく出てくるので、覚えておくといいと思います。
上位のOUで明示的な拒否だけを行った場合、下位の組織配下のAWSアカウントにどんなに強い権限があっても何も作業はできません。実際の運用で特定のサービスだけに明示的な拒否を設定したい場合は、拒否したくない他のサービスに対する「明示的な許可」を合わせてアタッチする必要があります。（なお、デフォルトでは「FullAWSAccess 」というAWS全サービスの明示的な許可を示すポリシーがアタッチされているので、それを消さずに明示的な拒否を追記する形です。）
５．アクセスコントロールリスト（ACL）
これは、S3やVPCなど、一部のサービスに付随しているポリシーの使用用途です。しかし現在のS3においては、ACLによる権限管理をしないことがマニュアルでも推奨されています。
（つまり、ちょっと古いタイプのポリシー使用用途ということですね。）
ですので、こういう使用用途のポリシーがあるということだけにとどめます。
６．セッションポリシー
こちらもやや高度なポリシーとなっています。
あるIAMユーザ（やIAMロール）が、一時的にセッションを張ってAWSにアクセスするとき、そのユーザ（ロール）のセッション中の行動範囲を制限します。ユーザやロールのアイデンティティベースのポリシーで実際に許可されている権限の一部が、セッションポリシーによって制限されることがあります。「３．アクセス許可の境界」「４．Organizations SCP」と同じく、
行動範囲だけを決めるので、実際の権限はアイデンティティベースのポリシーとして定める必要があります。
まとめ
「①手紙の使用用途での呼び方」として6種類を上げ、
それぞれの用途を簡単に記載しました。
これらは、この順番で使用頻度が高いという特徴があります。
しかし実際はほとんどが、「１．アイデンティティベースのポリシー」か「２．リソースベースのポリシー」だと思います。
同一アカウント内の場合はほぼ「１．アイデンティティベースのポリシー」です。複数のAWSアカウントを持っている場合は、「２．リソースベースのポリシー」「４．Organizations SCP」も関係してくることがあるかと思います。
もう一度大事なことなので、最後に書きます。
ポリシーは、ただの手紙です。
その手紙の呼び方がたくさんありますが、3種類をセットにして理解するとわかりやすいと考えています。
①手紙の使用用途での呼び方
②手紙の作り方での呼び方
③手紙を渡す（アタッチする）ときの呼び方
今回はそのうちの一つ「①手紙の使用用途での呼び方」について記載しました。使用用途は6種類ありますが、実際の利用としてはほとんどが「１.アイデンティティベースのポリシー」「２．リソースベースのポリシー」です。
イメージがわきましたでしょうか？
続いては、「②手紙の作り方での呼び方」に進んでいきたいと思います。
長文、読んで下さってありがとうございました！