🧢
【AWS】AssumeRoleってなんや！？

2024/10/09に公開
AWS
IAM
sts
tech
 はじめにIAM って難しいですよね。AWS 公式を見るといっぱいあって、

よくわかんないし、ドキュメント見ても「わからん！」ってなる人が多数だと思います。私もその一人です。
最近、その IAM 権限まわりで AWS Security Token Service と言われるサービスの中にあるsts:AssumeRoleという権限に、ぶち当たりました。

あとで詳細について記載しますが、中身を理解せず使用するとリスクが高い権限です。

そこで今回、私が調査し理解した内容をナレッジとして残したいと思います。

 本記事の目的今回の目的は、下記です。
AWS を利用する人たちにAssumeRoleについて、内容を共有すること
執筆を通して、AssumeRoleについて私自身の理解を深めること

 この記事の対象者本記事では、下記の方を対象に記載したいと思います。

AssumeRoleの概要を知りたい方

AssumeRoleの権限昇格について知りたい方
この記事で話さないこと
IAM ポリシーの説明
IAM ロールの説明
もし知らないよって方は、下記の記事を参考にするといいかもです。
AWS 初心者に IAM Policy/User/Role についてざっくり説明する
イラストで理解する IAM ロール

 AssumeRole についてそもそも AssumeRole って何する権限なの？って方がいると思います。この権限の内容は下記のように AWS ドキュメントに記載されています。(引用：https://docs.aws.amazon.com/ja_jp/service-authorization/latest/reference/list_awssecuritytokenservice.html)
通常アクセスできない AWS リソースにアクセスするために使用できる一時的なセキュリティ認証情報のセットを取得するアクセス許可を付与します。
はい。よくわかりませんね！AWS あるあるですね。

ざっくり言うと、「IAM ロールの権限を一時的に借りるための権限」です。

図にすると以下のようなイメージです。
なんとなくイメージつくでしょうか？

① のフローでsts:AssumeRoleという権限を使って、IAM ロール B の権限を STS に使わせてほしいとリクエストします。

②、③ のフローで A 君に IAM ロール B の権限を使わせていいか判断します。

ここで判断するのは IAM ロール B です。(後述する、信頼ポリシーで判断してます。)

問題なければ、④ のフロー STS が IAM ロール B の権限を使って AWS リソースを操作するための有効期限付きの一時認証鍵を払い出します。

これがAssumeRoleです。
実際にこれを AWS 環境で設定するにはこのようになります。

 Ａ君(AWS ユーザー)のアクセス許可{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::{AWSアカウントID}:role/{IAMロールBの名前}"
    }
  ]
}

 IAM ロールＢの信頼ポリシー信頼ポリシー：だれがロールを使っていいのか許可するもの。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{AWSアカウントID}:user/{A君のユーザー名}"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
ここでの注意点は、ユーザーと IAM ロール、お互いに許可がなければいけません。

ユーザーだけ許可をもっていても、IAM ロール側が許可していなければsts:AssumeRoleの権限は通りません。

もちろん、ユーザー側に許可がない場合もダメです。

さっきの図だと以下のようなイメージになります。

 ユーザーのみ許可の場合

 ユーザーに許可がない場合
イメージできたでしょうか？再度繰り返しますが、ユーザーと IAM ロール、お互いに許可がなければ STS は一時認証鍵を払い出すことができません。お互いに許可を出した場合にのみ STS は一時認証鍵をユーザーに払い出すことができます。
ちょっと難しいですが、この仕組みは覚えましょう！

 AssumeRole の危険性前節までは、AssumeRole についてお話しました。

ここではAssumeRoleを正しく設定しなかった際の危険性について紹介します。

いろいろあるかと思いますが、代表的な権限の昇格について紹介させて頂きます。

 権限の昇格IAM ロールに過剰な権限を付与すると、AssumeRole を使用するユーザーやサービスが本来必要としない操作を実行できるようになります。これにより、意図しないリソースの変更やデータの漏洩が発生する可能性があります。
例を１つ出します。

AdminRole というものを作りました。以下はロールの設定内容です。

(※こういうのはセキュリティ上、絶対作ったらいけません。)

 AdminRole の信頼ポリシー{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{AWSアカウントID}:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

 AdminRole の許可ポリシー{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}
そして以下は、ユーザーのアクセス許可です。

 ユーザーのアクセス許可{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::{AWSアカウントID}:role/AdminRole"
    }
  ]
}
これのなにが危険かわかりますか？

ユーザーはsts:AssumeRoleしかないし、他はなにもできないのでは？と思う方がいらっしゃると思いますが、これは非常にリスクが高いです！ユーザーはAssumeRoleを使うことで、AdminRoleの権限を使うことができます。

つまりユーザーは、AdminRoleの権限を使い、実質フルアクセスの権限で AWS を使うことができちゃうんですね。
これがよく言う、権限の昇格です。
また、ロールの信頼ポリシーも見てください。rootとはアカウント内のだれでも(ユーザーやサービス)、このロールを使えるという意味です。つまり、AdminRoleをAssumeできさえすれば AWS をフルアクセスで使えることになります。(怖い怖い。。。)
これの対策は、
ロールに付与する権限は必ず最小権限にすること。
使えるユーザー、サービスは制限すること。
なにかあってからでは遅いので、AssumeRoleは理解したうえで適切な設定をしましょう。

 最後にAssumeRoleについて記事を書いてみましたが、いかがでしょうか。

少しでも理解しやすいように、絵を描いて説明してみました。(最近、すごく意識してます。)

仕組みを分かって頂いた上で、なんとなく使うと危ない権限ということが理解できてもらえれば幸いです。
権限周りは難しいことが非常に多いですが、AWS を利用するうえで非常に重要なことなので、しっかり勉強していきましょう。
以上！
はじめに

本記事の目的

この記事の対象者

AssumeRole について

Ａ君(AWS ユーザー)のアクセス許可

IAM ロールＢの信頼ポリシー

ユーザーのみ許可の場合

ユーザーに許可がない場合

AssumeRole の危険性

権限の昇格

AdminRole の信頼ポリシー

AdminRole の許可ポリシー

ユーザーのアクセス許可

最後に

Discussion
