テクニカルトレーナーと学ぶ AWS IAM ロール
~ ここが知りたかった ! つまずきやすい部分を理解してモヤっとを解消
Author : 杉本 圭太
こんにちは ! テクニカルトレーナーの杉本圭太です !
最近読んで面白かった漫画は「あかねさす柘榴の都」と「クジマ歌えば家ほろろ」です。
今回は IAM ロールの説明を、私なりに感じた「理解する時につまずきやすい部分」を紹介する形式でお伝えします ! これは自身の経験やトレーニングの受講者からよくいただく相談などを踏まえたものなので、今まで IAM ロールの説明を聞いたり読んだりしてきたけどいまいちピンときていない方に、ぜひモヤッとを解消していただきたいです ( ･∀･)=b
というのも、私は業務でお客様に AWS の様々なトレーニング を提供しているのですが、AWS Identity and Access Management (IAM) について説明をした後に「トレーニングを受講したことで、今まで難しいと感じていた IAM ロールを理解できた !」と言っていただくことがあります。そのため AWS を自分で勉強されている方の中には、IAM ロールを学んでみた・使ってみたけど「モヤッとしているな」「理解が難しいな」と感じている方がまだまだいらっしゃるのではないでしょうか ?
例えばこんな疑問を抱いたことはありませんか ?
- 🤔 IAM ロールは IAM ユーザーと似ていて AWS の認証情報を提供できるリソースだけど、結局は何が違ってどう使い分けるの ?
- 🤔 🤔 IAM ユーザーと違って IAM ロールでは、ロールの使用者自身が必要な度に認証情報を発行すると聞いたけど、どういう仕組み ? それに AWS Security Token Service (STS) なるものが必要って聞いたけど一体何 ?
- 🤔 🤔 🤔 IAM ロールを使用して発行した認証情報は「一時的」なものらしいけど、どういう意味 ? AWS を操作する権限をずっと与えたい場合は IAM ロールは使えないの ?
- 🤯 🤯 🤯 EC2 インスタンスや Lambda 関数で IAM ロールを使用したことあるけど、「一時的」ではなく常に権限を渡せてるように感じるのはなんで ?
私の考えではありますが、IAM ロールの仕組みは多くの人が知っているものにバチッと当てはめて喩えづらいものであり、ある程度使って慣れてみないと特徴が捉えにくいため、学び初めた時に難しいと感じやすいのかなと思います。ちなみに私が初めて IAM ロールを学んだ時は混乱で頭の中が爆発しました (｡•̀ω-)b
ということで、悩んでいるのはみなさんだけではないはず !
それでは一緒にこれらの IAM ロールに関する疑問点を解消し、IAM の初級者から抜け出して中級者以上を目指していきましょう !
1. はじめに
IAM について説明し始めると機能が豊富すぎてキリがないため、今回の記事で扱う内容は一度 IAM ロールを学んでみたけれど理解しづらいのでは ? と私が感じる「IAM ロールのつまづきやすい部分とその解説」に関わる範囲に絞っています。そのため、この記事の対象者と目的を明記しておきます。
対象者
以下の前提知識を持っている方を対象にしています。とくに「IAM ロールの仕組みと理解する時のつまずきポイント」の章以降は中級者向けの内容になっていますのでご了承ください。
- IAM ユーザーと、紐付けたポリシーの "Resource" , "Action" , "Effect" で操作権限を制御できることを知っている
- ポリシーはアイデンティティベースのポリシーとリソースベースのポリシーに分類できることを知っている
- AWS は API で操作することを知っている (AWS の API を理解しよう ! 初級編 を読んで理解できる程度の知識がある)
なお、AWS の認証情報やアクセスキーについても少し触れるため、より詳しく知りたい方は AWS の API を理解しよう ! 中級編 を読んでいただくことをおすすめします !
目的
- IAM ロールと IAM ユーザーの違いを理解する
- IAM ロールを使用して認証情報を発行する場合に必要な、ロールのプリンシパルと AWS Security Token Service (STS) の関係を理解する
- IAM ロールが提供する「一時的な」認証情報とは、何が「一時的」なのかを理解する
- IAM ロールを使用するのが「人」の場合と「AWS のサービスやリソース」の場合で、認証情報を発行する担当者が違うことを理解する
2. IAM の基本
まずは本題に入る前に AWS アカウントと IAM の役割や用語について簡単に確認しておきます。
φ(•ᴗ•๑) 今回のキーワードはこちら !!
「IAM ユーザーや IAM ロールを使用して AWS を操作する」というのは「IAM ユーザーや IAM ロールで AWS の認証情報を発行し、その認証情報を使用してユーザー (人) やアプリケーションが AWS へ API をリクエストしている」と考える
IAM ロールを理解するための基本的な知識なので、このキーワードの意味がわかる方は次の「IAM ユーザーから見る IAM ロールとの違い」へ進んでいただいて大丈夫です !
AWS アカウントとルートユーザー
AWS を使用するには、まず最初に AWS アカウント作成 をします。みなさんが個人でショッピングサイトや SNS などの Web サービスで作成するアカウントとは違い、企業や組織で AWS を使用する場合は 1 つの AWS アカウントをシステム開発に関わる複数人で使用したり、複数の AWS アカウントを使用したりすることもあります !
アカウント作成が完了すると AWS 上で一意のアカウント番号が付与された AWS アカウントが用意されるので、AWS アカウント作成時に指定したメールアドレスとパスワードを認証情報としてログインすると、AWS アカウントの「ルートユーザー」として AWS のサービスを操作できます。
しかしルートユーザーを使用すると、AWS アカウント自体の削除や請求情報に関する操作など全てが可能であり、権限の制限もできません。そのため AWS では ルートユーザーは通常操作では使用しないことが推奨 されています。AWS を使用するメンバー全員がこの強力な権限で操作できてしまったり、そもそも複数人で認証情報を共有するのは避けたいですよね !
ではどうすれば良いかというと、認証と認可の機能を提供する IAM を使用して、AWS アカウント管理者用の IAM ユーザーや IAM ロールを用意します。そして管理者は、メンバーごとに必要な権限を持たせた IAM ユーザーや IAM ロールを使用できるようにしていきます。
※ 現在は必要な場合を除き IAM ユーザーは作成せずに、IAM ロールを使用することが推奨 されています。AWS アカウント作成後には AWS IAM Identity Center (AWS SSO の後継) を使用 すれば、IAM ユーザーを作ることなく IAM Identity Center で管理するユーザーと IAM ロールで認証・認可の制御ができます。
IAM ユーザーと IAM ロール
AWS では IAM ユーザーや IAM ロールのリソースと、ポリシーを組み合わせることで AWS アカウント内で「誰に」「どんなサービスやリソースに対して」「どんな操作を許可するか」を細かく制御できます。
※ 現在は必要な場合を除き IAM ユーザーは作成せずに、IAM ロールを使用することが推奨 されています。
IAM ユーザーや IAM ロールの使用している場面を、いくつか簡略図で表現してみました。
このような場合に「IAM を使用する」と言ったりすることがありますが、もう少し踏み込んでみると、なぜ AWS に対して「自分は IAM ユーザー (X) です ! Amazon S3 のバケットを作成お願いします !」や「自分は IAM ロール (Y) です ! AWS Lambda 関数の設定を変更します !」のように、自分が何者なのかを伝えることができるのでしょうか ?
これがなぜかを知るために、キーワードで挙げた内容を思い出してください φ(•ᴗ•๑)
「IAM ユーザーや IAM ロールを使用して AWS を操作する」というのは「IAM ユーザーや IAM ロールで AWS の認証情報を発行し、その認証情報を使用してユーザー (人) やアプリケーションが AWS へ API をリクエストしている」と考える
実際に AWS へ API をリクエストしているのは「人」や「アプリケーション」などですが、 認証情報があることで AWS は「この認証情報を使ったリクエストは IAM ユーザー (X) だな !」「このリクエストは IAM ロール (Y) からだ !」と判断できるわけです。このように捉えるとこの後の説明が理解しやすくなるはずですので、頭に入れておきましょう !
ここまでで IAM ロールを理解するために知っておいてほしい IAM の基本を紹介しました。ではいよいよ次から本題に入っていきます !
3. IAM ユーザーから見る IAM ロールとの違い
IAM ユーザーと IAM ロールはどちらも AWS の認証情報を提供できるリソースですが、その認証情報の違いを知ることで IAM ロールの特徴が明確になってきます !
そのためにまずは「IAM ユーザーの特徴から見た IAM ロールとの違い」という観点で確認してみます。
φ(•ᴗ•๑) 今回のキーワードはこちら !!
- IAM ユーザーの認証情報は「長期的 (永続的) な」認証情報と呼ばれる
- IAM ユーザーは特定の 1 人もしくは 1 つのアプリケーションに関連づけられる
それでは、これらを詳しく説明していきます。
IAM ユーザーの認証情報の特徴
IAM ユーザーの特徴を理解するために、まずは IAM ユーザーのとあるユースケースを挙げてみます。以下の状況を想像してみてください。
※ 現在は必要な場合を除き IAM ユーザーは作成せずに、IAM ロールを使用することが推奨 されています。
AWS アカウントを使って開発をしているプロジェクトに新メンバーに Alice が参加した場合、IAM リソースの管理権限がある人 (IAM 管理者) が IAM ユーザー alice を用意して認証情報 (マネジメントコンソールのログインパスワードやアクセスキー) を発行し、Alice に使用してもらう。Alice は IAM ユーザー alice に許可されている操作のみ可能。
▼ IAM ユーザーを新規作成し、認証情報を発行して使用する流れ (①と②は 1 つの操作で同時に行うこともあります)
会社や学校で社内/学内システムにアクセスするため、システム管理者が自分用に発行してくれた ID とパスワードを使用する流れに似ているので、イメージしやすいかと思います。
ではここでキーワード 1 つ目を確認してみましょう φ(•ᴗ•๑)
IAM ユーザーの認証情報は「長期的 (永続的) な」認証情報と呼ばれる
これは IAM ユーザーで発行した認証情報は、明示的に無効化したり変更しない限り変わらないという意味です。つまり IAM ユーザー alice を使用するために認証情報を発行した後、何もしなければその認証情報はずっとそのまま使い続けることができてしまいます。何を当たり前のことを ? と感じるかもしれませんが、実はなんと、IAM ロールを使用すると必ず有効期限がある認証情報を使用することになります Σ( ºωº ﾉ)ﾉ
後ほどあらためて説明しますが、IAM ロールを使用して発行した認証情報は有効期限付きという特徴から「一時的な」認証情報と呼ばれます。そのため認証情報が不要になった際にローテーションしたり、明示的に取り消したりする必要がありません。これは、認証情報が漏洩した時のリスクを減らすことにつながります。IAM ロールの「一時的な」認証情報にはアクセスキーに加えてセッショントークンも含まれます。
それぞれの認証情報がどんな値なのかの例を挙げておきます。AWS の認証情報である「アクセスキー」とは「アクセスキー ID とシークレットアクセスキーのペア」のことを指します。
▼ IAM ユーザーを使用して発行した認証情報 (アクセスキー) の例
# これらの値は発行した後、無効化しない限りずっと使い続けることが可能
ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY※ もし IAM ユーザーの認証情報を発行する場合は、定期的にローテーションすることがベストプラクティス とされています。
※ 厳密には IAM ユーザーでも期限付きの認証情報も発行できますが、今回はその機能の話はしません。
▼ IAM ロールを使用して発行した認証情報 (アクセスキーとセッショントークン) の例
# この値には必ず有効期限があり、期限が切れると使用できなくなる
ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE
SECRET_ACCESS_KEY=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
SESSION_TOKEN=AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAEということで、認証情報が期限付きかどうかというのが 1 つ目の違いでした。
IAM ユーザーの認証情報と使用者の関係
続けて 2 つ目のキーワードを見てみましょう φ(•ᴗ•๑)
IAM ユーザーは特定の 1 人、もしくは 1 つのアプリケーションに関連づけられる
こちらのドキュメント で以下のように書かれている通り、1 つの IAM ユーザーは複数の人や複数のアプリケーションで共有して使用するものではありません。
A user is uniquely associated with one person or application
例えば今回挙げたユースケースだと、IAM ユーザー alice は Alice だけのものです。こちらも認証情報を扱うならそりゃそうだろうと感じるかもしれませんが、なんと IAM ロールでは 1 つの IAM ロールを複数の人や複数のアプリケーションで使用することもあります Σ( ºωº ﾉ)ﾉ
そんなことして良いの !? と感じるかもしれませんが、これは後ほどの IAM ロールの仕組みで説明しますので、今は「IAM ユーザーと IAM ロールでは関連づけられる相手が単数か複数かで違う」ということを認識できれば OK です !
▼ 1 つの IAM ユーザーを複数人で共有しない (①と②は 1 つの操作で同時に行うこともあります)
ここまで IAM ユーザーの認証情報の特徴を大きく 2 つ挙げましたが、これらの特徴を持っているため、みなさんが複数のアカウントを使用する場合に IAM ユーザーを使用すると、アカウントごとに用意している複数の長期的な認証情報を管理することになってしまいます。普段から仕事やプライベートでたくさんの ID とパスワードを管理するのは面倒だと感じますよね ! つまりそれと同様な状態になってしまい、さらに管理する ID とパスワードが多ければ多いほど漏洩のリスクも増えちゃうので嬉しくありません 🥺
しかし IAM ロールの場合は IAM Identity Center と組み合わせれば、社内の IdP もしくは AWS 上で管理された長期的な認証情報 (つまり ID とパスワード) が 1 つあれば、アカウント内で複数の IAM ロールを使い分けたり、複数のアカウントにある IAM ロールを使い分けたりできます ! いわゆる「シングルサインオン (SSO)」と呼ばれている仕組みですね !
IAM Identity Center の説明はこの記事では省きますが、ご興味があればこの記事を読み終えた後に ユーザーガイド をご覧になってみてください (σ・∀・)σ
ここでは「IAM ユーザーの特徴から見た IAM ロールとの違い」をいくつか知っていただきました。すでに IAM ロールの嬉しい部分もチラッと顔を出し始めましたが、これらを踏まえて今回の最大の目的である IAM ロールの理解を深めていきましょう !
4. IAM ロールの仕組みと理解する時につまずきやすい部分
それではいよいよ本題ですが、冒頭でも伝えた通り今回は IAM ロールの役割や機能を網羅的に説明するというより、IAM ロールを学び始めた時につまずきやすい部分を軸に話を進めます。
φ(•ᴗ•๑) 今回のキーワードはこちら !!
- IAM ロールを使用して認証情報を発行する場合はロールのプリンシパルと STS も必要
- IAM ロールの認証情報の「一時的」とは「発行した認証情報自体の期限」を指すので、IAM ロールを使用して AWS を操作できる期間が一時的という意味ではない
- IAM ロールを使用して AWS を操作するのが「人」の場合と違い、AWS のサービスやリソースで IAM ロールを使用する場合は AWS 側で定期的に認証情報の発行をしてくれている
今はまだ「?」な用語が多くても大丈夫です、これから解説していくので安心してください !
IAM ロールの使い方の確認
あらためてですが、IAM ロールを使用することで開発メンバーや AWS のリソースなどに許可したい権限のみを渡せます。こちらのドキュメント にも IAM ロールのよくあるシナリオが載っています。
-
▼ IAM ロールでマネジメントコンソールを使用する場合 (再掲)
-
▼ IAM ロールを AWS のリソースが使用する場合 (再掲)
-
▼ IAM ロールでマネジメントコンソールを使用する場合 (再掲)
-
-
▼ IAM ロールを AWS のリソースが使用する場合 (再掲)
-
IAM ロールを使用すると実際は認証情報が発行されるのですが、この場合の認証情報や発行の仕組みは IAM ユーザーと違う部分が色々あります ! ではどのように違うかを、つまずきやすい部分と共に確認していきましょう !
<つまずきやすい点その 1> IAM ロールの認証情報発行の仕組みと登場人物
IAM ロールの理解を難しくしている要因の 1 つが、認証情報発行の仕組みが IAM ユーザーより単純ではないことだと思います。しかし逆にこの仕組みを把握できれば、IAM ロールと今まで以上に仲良くなれるはずです !
そこでこの仕組みの概要を掴むため、私なりに図を描いてみました。
重要な登場人物としてこちらが出てきますので、それぞれどんな役割なのかを眺めてみましょう ! 詳細は図の後に解説します !
- IAM リソースの管理権限がある人 (IAM 管理者)
- IAM ロール
- IAM ロールの認証情報を依頼して受け取る人 (ロールのプリンシパル)
- AWS Security Token Service (STS)
流れはほぼ同じですが IAM ロールを使用するのが「人」の場合と「AWS リソース」の場合の 2 パターン用意しています。
IAM ユーザーで IAM 管理者が認証情報を発行していたのと違い、IAM ロールでは認証情報を発行するのはロールの使用者自身です ! (図の②と③の部分)
認証情報を発行するまでに必要な登場人物も比べてみましょう。
図の通り IAM ユーザーでは、認証情報の発行をするまでの登場人物は次の 2 つだけでした。
- IAM リソースの管理権限がある人 (IAM 管理者)
- IAM ユーザー
極端に言うと IAM ユーザーの認証情報は「誰が使用するか」は決まっていなくても発行はできます。しかし IAM ロールではそうはいきません、認証情報の発行は IAM ロールを使用する当事者が STS へ発行依頼をする必要があります。これがキーワードの 1 つ目に挙げた内容です φ(•ᴗ•๑)
IAM ロールを使用して認証情報を発行する場合はロールのプリンシパルと STS も必要
もう少し詳しく解説してみます。
IAM ロールには「信頼ポリシー」というリソースベースのポリシーが必要で、信頼ポリシーの "Principal" 要素にその IAM ロールを誰が使用できるかを定義します。これは IAM ロールの認証情報を発行して良い相手を指定しているのですが、これを「信頼する」と言ったりもします。
また、IAM ロールが信頼した相手を今回の記事では「ロールのプリンシパル」と呼ぶことにします。ロールのプリンシパルには、企業の IdP で管理されている社員の ID、EC2 インスタンスや IAM ユーザー、別の AWS アカウントなどがあります。
▼ IAM ロールの信頼で "Principal" を定義することでロールを使用できる相手を指定
するとロールのプリンシパルは IAM ロールの認証情報を発行できるようになるのですが、認証情報を発行して使用することを「ロールを引き受ける」と言います。ロールを引き受けるためには STS というサービスへ API をリクエストして認証情報を受け取るのですが、ロールのプリンシパルによって AssumeRole , AssumeRoleWithSAML , AssumeRoleWithWebIdentity のどれかが使用されます。今回の記事ではこれらのロールを引き受ける API をまとめて AssumeRole* とします。
▼ STS へ AssumeRole* リクエストできるのは、信頼ポリシーで STS への "Action" が "Allow" されているため
一度ここまで紹介した用語を整理しましょう。
「IAM ロールを使用する」という一言の中で、実際にはこんなことが起きているのです !
- IAM ロールには信頼ポリシーの "Principal" でロールのプリンシパルを指定する
- ロールのプリンシパルが STS へ IAM ロールの引き受けリクエスト (AssumeRole*) を送る
- STS は AssumeRole* の送信者が、ロールのプリンシパルとして正しければ認証情報を発行する
- ロールのプリンシパルは受け取った認証情報を使うことで、IAM ロールで許可された権限で AWS のサービスを操作できる
では STS はどのように AssumeRole* をリクエストしたのが「信頼された相手からなのか」を判断できるのでしょうか ?
これはロールのプリンシパルによっても異なるのですが、こちら を参考に、どんな情報を STS へ送っているかまとめてみました。
| ロールのプリンシパル | ロールの引き受けで使用する API | STS へ「自分が誰か」を伝えるために送る情報 |
| IAM ユーザーや IAM ロール | AssumeRole | アクセスキーなど、AWS の認証情報 |
| IAM Identity Center や SAML を使用できる外部の IdP を経由して認証されたユーザー | AssumeRoleWithSAML | SAML 認証レスポンス |
| Amazon、Facebook、Google、または OpenID Connect (OIDC) に対応している任意の IdP などの、パブリック IdP を経由して認証されたユーザー | AssumeRoleWithWebIdentity | ウェブ ID トークン |
| EC2 インスタンスや Lambda 関数などの AWS サービスやリソース | AssumeRole | ※ AWS 内での通信のため、AWS 利用者が意識する必要はない |
ここで勘の良い方であれば「信頼ポリシーの設定次第では、1 つの IAM ロールに対してロールのプリンシパルを複数指定すると同じロールを共有できてしまうので、 CloudTrail のログなどでロールのプリンシパルが誰かの区別がつかないのでは ?」と感じたかもしれません。
しかし IAM ロールは引き受け時にそれぞれでセッションが確立され、セッションごとに認証情報も別で用意されます。さらにロールの引き受けの時に「ロールセッション名」を指定 することで「IAM ロールを使用しているxxxです」というのが CloudTrail のログで識別 できるようになっています !
▼ IAM ロールを使用した EC2 インスタンス (i-1234567890abcdefg) の CloudTrail のイベント履歴例
# "arn" が "arn:aws:sts::<アカウントID>:assumed-role/<ロール名>/<ロールセッション名>" で表示される
{
"userIdentity": {
"type": "AssumedRole",
"principalId": "XXXXXXXXXXXXXXXXXXXXX:i-1234567890abcdefg",
"arn": "arn:aws:sts::123456789012:assumed-role/AppRole/i-1234567890abcdefg",
...
"eventTime": "2023-03-01T00:00:00Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "DescribeTags",
...
}
長くなりましたが、この仕組みを 1 度で完璧に覚えるのは難しいので安心してください ! まずは「へえ、そんな仕組みなのか」となんとなく認識をしていただいて、キーワードで挙げたこちらを押さえていただければ OK です !
IAM ロールを使用して認証情報を発行する場合はプリンシパルと STS も必要
ということで、ここまでで IAM ロールの認証情報を発行する仕組みについて整理しました。が、仕組みを知ったことでさらなる疑問が湧いてくることもあります。
しかしこれは理解が進んだという証です ! そのため、よくある疑問点をもう少し紹介していきます。
<つまずきやすい点その 2> IAM ロールを使用して発行した認証情報は「一時的」とは ?
IAM ロールで認証情報を発行する場合、IAM ロール側の設定、もしくは引き受けリクエスト (AssumeRole*) 時に指定した値で有効期限が設定されます。つまり 1 時間の有効期限の認証情報を STS で発行すると、その認証情報は 1 時間後には使用できなくなるため「一時的な」認証情報とも呼ばれます。
ここで勘違いしやすいのですが、「一時的」と言いながらIAM ロールの信頼ポリシーの条件に合致する限りは何度でも認証情報を発行できるので、「それって一時的に AWS の操作権限を渡すとは言わないのでは ?」と感じてしまう方もいらっしゃいます。この認識は IAM ロールの認証情報の「一時的」が何を指しているのかを理解すれば明確になります。
これが 2 つ目のキーワードで伝えたいことです φ(•ᴗ•๑)
IAM ロールの認証情報の「一時的」とは「発行した認証情報自体の期限」を指すので、IAM ロールを使用して AWS を操作できる期間が一時的という意味ではない
こちらを理解しやすくするため、私なりに図を書いてみました。
▼ 「一時的」なのは STS が発行した認証情報で、AssumeRole* ができる期間のことではない
この場合だと IAM ロールは何度でも認証情報を発行できてしまうのであれば、有効期限がない IAM ユーザーの「長期的な」認証情報と AWS の操作権限を渡している期間が実質変わらないのでは ? と感じるかもしれません。
しかし IAM ロールを使用して長期間 AWS を操作する場合でも必ず認証情報がローテーションされるため、認証情報が漏洩してしまった場合でも、長期間に渡って悪用されるリスクを減らせる可能性が上がります。IAM ユーザーで認証情報を定期的にローテーションをする場合は、自分たちで仕組み作りをしないといけないので手間がかかっちゃいますし、ミスも起こりやすくなっちゃいますよね ><
※ IAM ロールの認証情報だからといっても盗まれると有効期限内は悪用はされるため、もちろん漏洩しないようには注意しましょう。とくに管理者権限の IAM ロールの認証情報が奪われれば、短期間の間に IAM のリソースを勝手に変更したり作成したりされる可能性はあります。
ただし「そうじゃなくて、ある人に特定の期間だけ AWS の操作権限を渡したいんだ !」という目的で「一時的な」認証情報が必要な場合は、以下のようにポリシーの 日付条件演算子 を使用することで実現が可能です。
- IAM ロールのアクセス許可ポリシーに "Condition" を設定し、その IAM ロール に付与された "Action" を許可する期間を絞る
- IAM ロールの信頼ポリシーに "Condition" を設定し、STS がその IAM ロールの認証情報を発行できる期間を絞る
ここでは IAM ロールの仕組みの中で「一時的」がどの部分を指すのかを明確にしてみました !
次でいよいよ IAM ロールの説明は最後です。
<つまずきやすい点その 3> 認証情報を「いつ・誰が」発行するかは IAM ロールのプリンシパルが鍵
先ほど説明したように IAM ロールの認証情報には有効期限があるため、長期的に AWS の操作をしたい場合は「定期的に認証情報を発行する」必要があります。
例えば IAM Identity Center など、シングルサインオンの仕組みで IAM ロールを引き受けてマネジメントコンソールを操作したり、開発者が個人の PC で AWS CLI の操作をするために IAM ロールを引き受けたりしますが、操作中に認証情報の有効期限が切れると再発行の作業が必要になります。
しかしここで、EC2 インスタンスへ IAM ロールのアタッチや Lambda 関数の作成時に実行ロールを指定したことがある方はこんな疑問が出るかもしれません。
「一時的な認証情報なのに、EC2 インスタンスや Lambda 関数、その他の AWS サービスやリソースで IAM ロールを使用したときに、定期的に認証情報の発行を意識した記憶がないけどどうなっているのだろう ?」
▼ EC2 インスタンスで IAM ロールを使用した時に誰が AssumeRole するのか ?
実はこれ、結論から言うとキーワードの 3 つ目に書いたこんな仕組みになっています φ(•ᴗ•๑)
IAM ロールを使用して AWS を操作するのが「人」の場合と違い、AWS のサービスやリソースで IAM ロールを使用する場合は AWS 側で定期的に認証情報の発行をしてくれている
そのためみなさんは AWS のサービスやリソースで IAM ロールを使用する場合に、認証情報を発行する作業を意識しなくても良いのです。つまり「IAM ロールのポリシーに紐づく権限を常に AWS のサービスやリソースに渡しつつ、認証情報は定期的にローテーションされている状態」を実現しています。素敵ですね !
▼ AWS サービスやリソースで IAM ロールを使用すれば AWS が定期的に AssumeRole してくれる !
IAM ロールを使用するのが「人」の場合と、AWS のサービスやリソースの場合で「認証情報発行の担当者」が異なるので、「一時的」な認証情報と言いつつ AWS のサービスやリソースは「常に」権限を持っている状態ではないのか ? と混乱しやすい部分なのでお伝えしましたが、仕組みがわかればスッキリですね !
AWS CloudTrail のイベントを見ると、IAM ロールをアタッチしたサービスやリソースが定期的に AssumeRole をしていることがわかります !
5. まとめ
最後に今回お話しした部分で IAM ユーザーと IAM ロールの比較を表でまとめてみましたので、情報を整理しておきましょう !
IAM ユーザー |
IAM ロール |
|
認証情報 |
・アクセスキー ID ・シークレットアクセスキー |
・アクセスキー ID ・シークレットアクセスキー ・セッショントークン |
認証情報発行の段取り |
アカウント管理者が IAM ユーザーの作成と、その認証情報を発行 (CreateAccessKey や CreateLoginProfile) する | アカウント管理者がプリンシパルを設定した IAM ロールを作成し、プリンシパルが必要に応じて STS へ発行依頼 (AssumeRole* のリクエスト) をする |
発行された認証情報の期間 |
長期的 (明示的に無効化したりローテーションしない限り認証情報は変わらない) | 一時的 (必ず有効期限付きで発行される、ただし信頼ポリシーの条件に合致する限り引き受けは何度でも可能) |
使用者 |
IAM ユーザーごとに特定の 1 人もしくは 1 つのアプリケーション | 信頼ポリシーに設定されているプリンシパルで、1 つの IAM ロールを複数のプリンシパルが使用する場合もある |
また IAM というサービスはとても機能が豊富で、他にも IAM ロールをクロスアカウントで使用 したり、サービスにリンクされたロール というものがあったり、EC2 で IAM ロールを使用するには インスタンスプロファイル という仕組みがあったり、ロールチェイン、IAM ユーザーには今回紹介していない種類の認証情報 などなどがありますので、より深く知りたい方は色々調べてみてください !
このようにテクニカルトレーナーは、自学だけではつまずきやすい部分などを含め、みなさんにより AWS を理解してもらいやすくなる工夫を日々行いながら トレーニング を提供しております ! 質問もリアルタイムでできるため分からない部分はとことんお付き合いしますし、ほとんどのコースには演習の時間も多くあるため学んだ内容を AWS 環境で実践できます !
AWS のトレーニングについてもっと知りたい方は、以下の連載記事も参考にどうぞ〜
これまで自分で勉強してきたけど AWS を体系的に学ぶことでもっと詳しくなって業務で活用したい ! という方はぜひ AWS のトレーニングを受講してみてください !
筆者プロフィール
杉本 圭太
アマゾン ウェブ サービス ジャパン合同会社
トレーニングサービス本部 テクニカルトレーナー
新しいことを知るのが好きなので、多くの人に「AWS を知るのは面白い ! もっと学んでみよう ! 活用しよう !」と思っていただけるよう工夫しながらテクニカルトレーナーをしています。
最近は面白い漫画が増えすぎていて、時間が足りなくて困っています。
さらに最新記事・デベロッパー向けイベントを検索
AWS を無料でお試しいただけます