【初心者向け】AWS  IAM (Identity and Access Management ) 入門

グループ

グループは、IAM ユーザの集まりです。グループを使う主な理由としては、IAM ユーザをグループに割り当てて、ポリシーをグループに適用することを通じて、グループ内のユーザに権限を付与することです。グループやロールをグループに所属させることができません。

個別の IAM ユーザにポリシーを直接アタッチすることもできますが、ベストプラクティスとしては、IAM ユーザをグループにまとめて、グループに対してポリシーをアタッチすることです。同一ユーザは最大 10 個のグループのメンバーになることができます。

ポリシー

ポリシーは、JSON 式のドキュメントであり、アイデンティティ（IAM ユーザ、グループ、ロール、フェデレーションユーザ） または AWS リソース（S3、EC2 など）にアタッチして、アイデンティティまたは AWS リソースのアクセス権限を定義します。

ポリシーの構成は、バージョンとステートメント二つのセクションに大きく分けられます。

Version：JSON ポリシー言語のバージョンを指定します。現時点で 2008-10-17 と 2012-10-17 二つのバージョンがあります。最新バージョン 2012-10-17 の使用が推奨されています。

注）バージョンは、ポリシー自体のバージョン管理をするものではありません。

Statement：コンテナみたいなもので、ステートメントの中に以下のポリシーの要素を記述します。ポリシーには一つまたは複数のステートメントを含めることができます。

Sid：オプション要素で、複数のステートメントを区別するための任意の文字列です。

Effect：Allow または Deny を使って、アクセスを許可するか拒否するかを示します。

Action：ポリシーが許可または拒否するアクションのリストです。

Principal：プリンシパルは、AWS リソースに対するアクションをリクエストできる IAM ユーザ、ロール、フェデレーションユーザ、またはアプリケーションを指します。リソースベースのポリシーを作成する時、アクセスを許可または拒否するプリンシパルを指定する必要があります。

Resource：アイデンティティベースのポリシーを作成する時、アクションが適用されるリソースを指定する必要があります。リソースは、そのリソースリストを示します。

注）リソースベースのポリシーを作成する時、リソースの指定はオプションとなります。リソースが指定されていない場合、アクションはポリシーがアタッチされているリソースに適用されます。

Condition：オプション要素で、どの条件でアクセスを許可または拒否するのかを指定します。

AWS には、アイデンティティベースのポリシー、リソースベースのポリシー、アクセス許可の境界、 SCP、ACL とセッションポリシーの計 6 種類のポリシーがあります。最も使用頻度の高いアイデンティティベースのポリシーとリソースベースのポリシーについて説明します。

アイデンティティベースのポリシー

アイデンティティベースのポリシーは、IAM ユーザ、グループもしくはロールにアタッチされ、それらのアイデンティティがどのリソースに対してどの操作を実行できるかを定義します。

アイデンティティベースのポリシーは、さらに次のように分類できます。

• AWS 管理ポリシー：AWS が作成および管理するポリシーです。各 AWS サービスにフルアクセス権限や読み取り権限などのポリシーがあらかじめ用意されています。例えば、下記の AmazonS3ReadOnlyAccess ポリシーではアカウント内の全ての S3 バケットに対して、Get/Listの操作が許可されています。

• カスタマー管理ポリシー：利用者が作成及び管理するポリシーです。AWS 管理ポリシーに比べて、より細かめにアクセス権限を管理できます。例えば、利用者は特定の S3 バケットに対して特定の操作権限を付与するポリシーを作成することができます。
• インラインポリシー：特定の IAM ユーザ、グループもしくはロールに専用に作成され、それらのアイデンティティに直接埋め込まれるポリシーです。インラインポリシーはアイデンティティの一部だと考えてもよくて、アイデンティティを削除すると、インラインポリシーも削除されます。

リソースベースのポリシー

リソースベースのポリシーは、AWS リソースにアタッチされ、そのリソースに対して誰がどの操作を実行できるかを定義します。「誰が」の部分はポリシーの中のプリンシパルで指定します。

S3 バケットポリシーがよく使われるリソースベースのポリシーです。下記の S3 バケットポリシーの例では、AWS アカウント（123456789012）の IAM ユーザ（Jack）が S3 バケット（examplebucket）配下の全てのオブジェクトに対して、 s3:PutObject と s3:PutObjectAcl のアクセスを許可します。

プリンシパル要素を削除すれば、このポリシーはアイデンティティにもアタッチできます。

リソースベースのポリシーをサポートするサービスのリストについては、IAM と連携する AWS のサービス をご参照ください。

ポリシーの評価ロジック

プリンシパルが AWS を利用しようとすると、そのプリンシパルは AWS にリクエストを送信します。 AWS のサービスがリクエストを受け取ると、適用されるポリシーに基づいて、プリンシパルのリクエストを許可するか拒否するかを決めます。

次のフローチャートは、許可／拒否がどのように行われるかの詳細を示しています。

引用元：ポリシーの評価論理

デフォルトでは、フルアクセス権限を持つルートユーザを除いて、全てのリクエストが暗黙的な拒否から評価されます。つまり、アクセス権限を明示的に許可するまで、全てのアクセスが拒否されます。

アクセスを許可するには、アイデンティティベースのポリシーまたはリソースベースのポリシーで明示的な許可を記載する必要があります。ただし、本記事で説明していないアクセス許可の境界、SCP、またはセッションポリシーが存在する場合、許可が暗黙の拒否でオーバーライドされる可能性があることにご注意ください。

許可／拒否の強さについては、明示的な拒否 > 明示的な許可 > 暗黙的な拒否 のような関係があります。ポリシー内の明示的な拒否は全ての許可をオーバーライドできます。

ロール

ロールは複数のポリシーによって構成されます。ロールの役割は、AWS サービス（EC2、Lambda など）にアクセス権限を付与して、その AWS サービスが IAM ユーザのように行動できるようにすることです。

例を挙げて説明します。EC2 インスタンス上で稼働するアプリケーションがあって、そのアプリケーションは S3 バケットにアクセスする必要があるとします。

AWS では、ポリシーを直接 IAM ユーザとグループにアタッチすることができますが、ポリシーを直接 AWS サービスにアタッチすることができません。この時は、まず S3 バケットポリシー（例えば、AmazonS3FullAccess）をロールにアタッチします。次に、ロールを EC2 インスタンスにアタッチする必要があります。

IAM ロールを作成する時、許可ポリシーと信頼されたアイデンティティを指定する必要があります。

例えば、上記の例なら、許可ポリシーは AmazonS3FullAccess であり、S3 バケットにフルアクセス権限を持っています。許可ポリシーの中身はアイデンティティベースのポリシーです。

一方、信頼されたアイデンティティは EC2 であり、EC2 インスタンスはユーザに代わって AWS サービスを呼び出すことが許可されます。信頼されたアイデンティティの中身はリソースベースのポリシーです。

まとめ

IAM は全ての AWS 利用者にとって非常に重要なサービスで、一歩間違ってしまえばセキュリティ事故にも繋がります。IAM の概念は少々複雑で、初心者にとって理解するのは難しいと思います。今回の記事では、IAM を理解するための必要最小限の用語や概念を解説しました。最後までお読みいただいた読者の皆さんは、IAM とはこういうことだなと理解していただければ嬉しいです。

では、ソフトバンク Advent Calendar 2022 の 3日目にバトンを渡します。寺尾さんよろしくお願いします。

関連サービス