AWS IAMポリシーを理解する

はじめに

こんにちは、川原です。

AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。 AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。

ポリシーの基本

ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。 記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。

例えば、以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。 このポリシーではS3のリソースに対する参照操作を許可しています。このポリシーをEC2インスタンスに関連づけると(正確にはIAMロールを経由して関連づける)、そのEC2インスタンス上のプログラム(AWS CLI、AWS SDKを利用したプログラム)から、S3リソースに対する参照操作(Get、List)が可能となります。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}

ポリシーの分類

ポリシーを分類すると以下のような感じになると思います、多分。 この全体感を理解するのが一番重要な気がします。

1. ユーザーベースのポリシー

* AWS管理ポリシー * カスタマー管理ポリシー * インラインポリシー 1. リソースベースのポリシー 1. IAM ロールの信頼ポリシー(別名：信頼関係?)

以下ではそれぞれのポリシーについて説明します。

ユーザーベースのポリシー

ユーザーベースのポリシーは、IAMユーザー、IAMグループ、IAMロールに関連づけるポリシーになります。

上の説明では、ポリシーは「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」を記述する、と述べました。 しかし、このポシリーには「誰が」(つまり、操作する主体)の部分(ポリシーの記述項目で言うとPrincipal)は記述しません。 なぜならば、「誰が」は、記述するまでもなくポリシーを関連づけた先のIAMユーザー、IAMグループ、IAMロールになるからです。

上の例で示したAmazonS3ReadOnlyAccessポリシーはユーザーベースのポリシーですが、操作主体に対応するPrincipalは記述していません。 このポリシーを関連づけたIAMユーザー、IAMグループ、IAMロール(IAMロールをEC2インスタンスにアタッチした場合は、EC2インスタンス)が、「誰が」の部分に該当します。 なので、AmazonS3ReadOnlyAccessポリシーを関連づけたIAMユーザー(やIAMグループ、IAMロール)がS3リソースを参照できる、という事になります。

ユーザーベースのポリシーは作成者や管理方法の観点でさらに以下3つに分類できます。これらの差異の概要は以下表に記載した通りです。詳細は管理ポリシーとインラインポリシー をご参照ください(手抜。。。

以下のキャプチャは、マネジメントコンソールのIAMサービスの画面です。アクセス許可タブでユーザーベースのポリシーの設定が行えます。

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

リソースベースのポリシーはユーザーベースのポリシーと似ていますが、関連づける先がユーザーではなく「AWSサービス」であるという点が異なります。 (ざっくり言うと、操作する主体(≒ユーザー)ではなく、操作を行われるモノ(AWSリソース)に関連づけるポリシーです) よく使われているリソースベースのポリシーは、S3のバケットポリシーと思います。

ポリシーの記述内容レベルでの違いは、操作主体を表すPrincipalの有無です。 ユーザーベースのポリシーの場合、「人(ユーザー、グループ、ロール)」に関連付けるので操作主体は「関連づけた先のユーザーやグループ、ロール」と暗黙的に決まりました。一方、リソースベースのポリシーは「モノ(AWSリソース)」に関連づけるので暗黙的には決まらず、「誰が」の部分にあたるPrincipalの記載が必要になります。

以下にS3のバケットポリシーの例を示します。

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::example-bucket/*"
}
}

この例では、「AWSアカウント：777788889999のIAMユーザー：bob」 が 「example-bucket S3バケット配下」に「操作：PutObject、PutObjectAcl」を「許可する」事を意味しています。

リソースベースのポリシーはS3等の一部のAWSサービスのみに対応しています。 対応しているAWSサービスは IAM と連携する AWS サービス の表において、「リソースベース」がYesになっている行です。 また、Principal に指定できる値については、この辺り をご参照ください。

IAMロールの信頼ポリシー

IAM ロールの信頼ポリシーは、AWSのドキュメントでは「信頼関係」と記載されている箇所もあります(実はこっちが正式名称??)。

このポリシーは上で紹介した2つのポリシーとは毛色が少し異なり、IAMロールの権限移譲操作に特化したポリシーになります。また、その名前の通り、ポリシーを関連づける先(対象)はIAMロールです。

ポリシーの記載内容をざっくり言うと、当該の信頼ポリシーを関連づけたIAMロールが保有する権限を、信頼ポリシーの操作主体であるPrincipalに移譲(を許可)する、ということを記述します。 うまく説明できていないと思うので、誤解を恐れずにもっとざっくり言うと、「信頼ポリシーを関連づけたIAMロール」に「Principal(主体者)」が(権限的に)なりすませる、ということです。

これ以上、一般論での説明は私には難しそうなので、例で説明します。 以下は信頼ポリシーの記述例です。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/bob""
},
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
"Action": "sts:AssumeRole",
}
]
}

例えば、この信頼ポリシーをAWSアカウント：999988887777 の IAMロール：kawaharaに関連づけたとします。 すると、この場合、AWSアカウント：999988887777 の kawahara ロールの権限を、AWSアカウント：123456789012 の IAMユーザー：bob に謙譲許可すること¹を意味します。つまり、IAMユーザー：bob は IAMロールkawaharaの持っている権限と同等の権限を保有することができます。 もし、IAMロール：kawahara がAWSアカウント：9999888777 配下のEC2インスタンスを起動する権限(この権限はユーザーベースのポリシーでIAMロールに関連づけている)を保有していれば、(AWSアカウント：123456789012の)IAMユーザー：bob も同様にAWSアカウント：999988887777配下のEC2インスタンスを起動できます²。

以下のキャプチャは、マネジメントコンソールのIAMサービスの画面です。信頼関係タブで信頼ポリシーの設定が行えます。

まとめ

AWSではポリシーによりAWSリソースに対する操作権限を制御しています。 本ブログの内容が皆様の「AWS ポリシー」を理解する一助になれば何よりです。

参考情報

AWS再入門 AWS IAM (Identity and Access Management) 編

[AWS IAM] 経験者向けManaged Policy対応ガイド

IAM ポリシーエレメントの参照