IAMポリシーを理解するAWS特集IAM2016年05月10日kawaharakunio(17)8282件のシェア(ちょっぴり話題の記事)この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。はじめにこんにちは、川原です。AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。ポリシーの基本ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。このポリシーではS3のリソースに対する参照操作を許可しています。SDKを利用したプログラム)から、S3リソースに対する参照操作(Get、List)が可能となります。]}ポリシーの分類ポリシーを分類すると以下のような感じになると思います、多分。この全体感を理解するのが一番重要な気がします。ロールの信頼ポリシー(別名:信頼関係?)以下ではそれぞれのポリシーについて説明します。ユーザーベースのポリシーユーザーベースのポリシーは、IAMユーザー、IAMグループ、IAMロールに関連づけるポリシーになります。上の説明では、ポリシーは「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」を記述する、と述べました。このポシリーには「誰が」(つまり、操作する主体)の部分(ポリシーの記述項目で言うとPrincipal)は記述しません。「誰が」は、記述するまでもなくポリシーを関連づけた先のIAMユーザー、IAMグループ、IAMロールになるからです。上の例で示したAmazonS3ReadOnlyAccessポリシーはユーザーベースのポリシーですが、操作主体に対応するPrincipalは記述していません。このポリシーを関連づけたIAMユーザー、IAMグループ、IAMロール(IAMロールをEC2インスタンスにアタッチした場合は、EC2インスタンス)が、「誰が」の部分に該当します。AmazonS3ReadOnlyAccessポリシーを関連づけたIAMユーザー(やIAMグループ、IAMロール)がS3リソースを参照できる、という事になります。ユーザーベースのポリシーは作成者や管理方法の観点でさらに以下3つに分類できます。これらの差異の概要は以下表に記載した通りです。ご参照ください(手抜。AWSが用意している再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。ユーザーが作成した再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。各IAMユーザー(やIAMグループ、IAMロール)専用にユーザーが個別作成するポリシー。以下のキャプチャは、マネジメントコンソールのIAMサービスの画面です。アクセス許可タブでユーザーベースのポリシーの設定が行えます。リソースベースのポリシーリソースベースのポリシーはユーザーベースのポリシーと似ていますが、関連づける先がユーザーではなく「AWSサービス」であるという点が異なります。(ざっくり言うと、操作する主体(≒ユーザー)ではなく、操作を行われるモノ(AWSリソース)に関連づけるポリシーです)よく使われているリソースベースのポリシーは、S3のバケットポリシーと思います。ポリシーの記述内容レベルでの違いは、操作主体を表すPrincipalの有無です。ユーザーベースのポリシーの場合、「人(ユーザー、グループ、ロール)」に関連付けるので操作主体は「関連づけた先のユーザーやグループ、ロール」と暗黙的に決まりました。リソースベースのポリシーは「モノ(AWSリソース)」に関連づけるので暗黙的には決まらず、「誰が」の部分にあたるPrincipalの記載が必要になります。以下にS3のバケットポリシーの例を示します。S3バケット配下」に「操作:PutObject、PutObjectAcl」を「許可する」事を意味しています。リソースベースのポリシーはS3等の一部のAWSサービスのみに対応しています。表において、「リソースベース」がYesになっている行です。ロールの信頼ポリシーは、AWSのドキュメントでは「信頼関係」と記載されている箇所もあります(実はこっちが正式名称??)。このポリシーは上で紹介した2つのポリシーとは毛色が少し異なり、IAMロールの権限移譲操作に特化したポリシーになります。その名前の通り、ポリシーを関連づける先(対象)はIAMロールです。ポリシーの記載内容をざっくり言うと、当該の信頼ポリシーを関連づけたIAMロールが保有する権限を、信頼ポリシーの操作主体であるPrincipalに移譲(を許可)する、ということを記述します。うまく説明できていないと思うので、誤解を恐れずにもっとざっくり言うと、「信頼ポリシーを関連づけたIAMロール」に「Principal(主体者)」が(権限的に)なりすませる、ということです。これ以上、一般論での説明は私には難しそうなので、例で説明します。以下は信頼ポリシーの記述例です。IAMロール:kawaharaに関連づけたとします。謙譲許可すること1を意味します。IAMロールkawaharaの持っている権限と同等の権限を保有することができます。同様にAWSアカウント:999988887777配下のEC2インスタンスを起動できます2。以下のキャプチャは、マネジメントコンソールのIAMサービスの画面です。信頼関係タブで信頼ポリシーの設定が行えます。まとめAWSではポリシーによりAWSリソースに対する操作権限を制御しています。ポリシー」を理解する一助になれば何よりです。IAMロール:kawaharaを引き受ける(AssumeRole)、と言う。スイッチロール(kawaharaロール用のアクセストークン取得処理)した後に起動できるようになります。リモート】クラスメソッドの会社説明会を開催しますクラスメソッドでは、AWS・AI・ビッグデータ・モバイルなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。#cmdevio新型コロナウイルスの感染拡大を受け、本イベントを延期させていただくことになりました(開催時期未定)。お申し込みいただいた皆様には大変申し訳ございませんが、何卒ご理解いただけますようよろしくお願いいたします。AWSについてライトに色んな情報交換をしましょう。カフェ店長のオカノです。今日はオフィスに用があるので、通勤ラッシュを避けて出社しました。この子は新メンバーのさめくんです。在宅勤務が推奨されているのでオフィスが閑散としており、すこしさみしそうです。使いたいときの注意点を書きました。本が出ていたので読んでみたところよかったので紹介させていただきます。