目次
AWS STS（Security Token Service）の特徴
AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。固有のプロファイル認証情報を通しての認証ではありません。
※「一時的」とありますが、STSは時間的な期限付きのアクセスキー／シークレットアクセスキー／セッショントークンになります。
一時的なセキュリティ認証情報をリクエストするには、AWS Security Token Service (AWS STS) を使用できます。
STS は期限付きのアクセスキー／シークレットアクセスキー／セッショントークン
AWS Security Token Service（AWS STS）は、期限付きのアクセスキーペア（アクセスキー/シークレットアクセスキー）とセキュリティトークンで構成される、「一時的セキュリティ認証情報」を提供するサービスです。つまり STS は、一時的な鍵を作って配る窓口です。
AWS STS API オペレーションは、アクセスキーペアやセキュリティトークンを含
む一時的セキュリティ認証情報で新しいセッションを作成します。
アクセスキーペアは、アクセスキー ID とシークレットキーで構成されます。
ユーザー（またはユーザーが実行しているアプリケーション）はこれらの認証情報を使用して、リソースにアクセスできます。
AWS STS API オペレーションを使用して、ロールセッションを作成し、プログラムでセッションポリシーとセッションタグを渡すことができます。
トークンだけでなくアクセスキーとシークレットアクセスキーにも期限があるか
IAM ユーザー作成時に生成可能なアクセスキーとシークレットア
アクセスキーは、IAM ユーザーまたは AWS アカウント ルートユーザー の長期的な認証情報です。
アクセスキーを使用して、AWS CLI または AWS API (直接または AWS SDK を使用) にプログラムでリクエストに署名することができます。詳細については、『Amazon Web Services 全般的なリファレンス』の「AWSAPI リクエストの署名」を参照してください。
アクセスキーは、アクセスキー ID (例: AKIAIOSFODNN7EXAMPLE) とシークレットアクセスキー (例: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) の 2 つの部分から構成されます。
ユーザー名とパスワードと同様に、リクエストを認証するために、
アクセスキー ID とシークレットアクセスキーの両方を使用する必要があります。ユ ーザー名とパスワードと同様に、アクセスキーをしっかり管理して ください。
一方で、STS では「セッションポリシー」を条件に追加すること
セッションポリシーは、ロールまたはフェデレーティッドユーザーの一時セッションをプログラムで作成する際にパラメータを渡す高度なポリシーです。
セッションのアクセス許可は、セッションの作成に使用する IAM エンティティ (ユーザーまたはロール) のアイデンティティベースのポリシーとセッションポリシーの共通部分です。
また、リソースベースのポリシーからアクセス許可が派生する場合
もあります。 これらのポリシーのいずれかを明示的に拒否した場合、その許可は 無効になります。
STS により一時的に AssumeRole が割り当てられる
STS の AssumeRole API によって、IAM ユーザーや EC2 インスタンスなどのエンティティがロールを引き受け、一時的な権限を得ることが可能になります。つまり、アプリケーションは STS を呼び出して必要な IAM ロールを取得します。（ロールを引き受けます。）
一時的なセキュリティ認証情報のリクエスト
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_request.html
IAM ユーザーのアクセスキーの管理
https://docs.aws.amazon.com/ja
IAM でのポリシーとアクセス許可 – セッションポリシー
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html#policies_session
AssumeRole — クロスアカウントの委任とカスタム ID ブローカーを経由したフェデレーション
https://docs.aws.amazon.com/ja
sts:AssumeRoleとは
IAM ポリシーや信頼ポリシーで「sts:AssumeRole」がよく使われています。
sts:AssumeRole とは、ポリシーで書く「許可の単位」（アクション名）です。具体的には、STS の AssumeRole API を呼んでロールを引き受ける権限です。
使われる場所は呼び出し側と引き受けられる側と、信頼ポリシーと権限ポリシーの 4 つがあります。
- ① 利用する方 … 呼び出し側（sts:AssumeRole を実行する）
- ② 利用される方 … 引き受けられる側（sts:AssumeRole されるロール）
- ③ 信頼ポリシー … 誰を受け入れるか（誰に利用されるか）を決める
- ④ 権限ポリシー … sts:AssumeRole を実行する権限がある
利用する方
sts:AssumeRole を呼び出す側（実行する側）です。IAM ユーザー、IAM ロール、EC2 のインスタンスプロファイル、別 AWS アカウントのロールなどです。
この利用する方には sts:AssumeRole を実行するための ④ 権限ポリシーが必要です。sts:AssumeRole の権限がなければ利用できません。以下のように Action に sts:AssumeRole がなければいけません。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::222222222222:role/sample_target_role"
}
]
}このリソース（Resource）にはどのロールに対して sts:AssumeRole を実行してよいかを指定しています。上の信頼ポリシーの例では sample_target_role に対して sts:AssumeRole を実行できる権限が割り当てられています。sample_target_role をsts:AssumeRole してよい（sample_target_role を利用してよい）という意味です。
利用される側
利用される側は AssumeRole される側です。引き受けられる側です。利用される側です。信頼ポリシーを設定しておく必要があります。信頼ポリシーは誰を信頼するか、そのロールが誰に AssumeRole されるかを決めます。
以下は、信頼ポリシーの例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
}
}
]
}信頼ポリシーには Principal で誰を信頼するかを明確に記載します。利用される側には、Principalに誰がこの IAM ロールを利用できるか？を記述します。AWSアカウント・IAMロール・IAMユーザー・サービス などを書きます。
【例】Lambda 関数の場合
Lambda 関数を実行する際に CloudWatch Logs にログを送信します。その際に、Lambda 関数が利用する（呼び出す）IAM ロールに CloudWatch Logs への書き込み権限が必要です。更に Lambda 関数が利用する（呼び出す）IAM ロールに Lambda 関数が利用できるように信頼ポリシーに lambda.amazonaws.com の指定が必要です。
信頼ポリシーの例
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}誰がこの IAM ロールを利用できるのか？の部分には、Lambda 関数の場合はlambda.amazonaws.com のようにサービスプリンシパルを記述します。
Black Belt の資料
更に Balck Belt で STS が出てくる資料を以下に抽出しました。理解度が増すとか新しい気づきがあるかもしれません。
STSが利用できる API Action です。
AssumeRole は設定したことはありますが、こうして資料を確認すると他にも4つ API があります。
STS の使い方（全社員の S3 バケットへのアクセスを管理したい場合）
ID プロバイダーとフェデレーション
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers.html
STS の使い方（ユースケース）としては、例えば数千人規模の社員がいるとします。その全社員に S3 バケットにアクセスをさせてファイルやコンテンツを取得させているとします。毎月数十人規模で入社したり退社している環境で、毎回 IAM ユーザーを作成するのは運用がかなり大変になります。しかも全社員に対してはすでに情シスが Active Directory などでアカウントを発行して管理しているなら二重管理にもなります。
そのような環境の場合は、すでにある認証機能（Active Directory、Ldap、Googleアカウント等）を利用して AWS のリソースに対する認証をすることができます。
そこで STS（Security Token Service）が利用されます。STS と IDブローカーを連携させて AssumeRole を呼び出して、一時的なセキュリティ認証情報を取得し、IAM フェデレーションユーザー認証情報を使用してAWSリソースにアクセスします。
・SAML(Security Assertion Markup Language)・・・Ldap、Active Directory など
フェデレーション（federation）とは？
federation … 連邦、連合、連盟
AWS 公式サイトでよく見かけるフェデレーションとは、AWS の外（会社のID基盤など）で本人確認（認証）した結果を AWS が信頼して、AWS内で “ロール” を一時的に貸してアクセスさせる仕組みを言います。
フェデレーションを使うと、AWSアカウント内に人ごとの IAMユーザー（長期アクセスキー含む） を大量に作らなくてすみます。ユーザー管理は外部IdP（IDプロバイダー）側 でやり、AWS 側は 一時的な認証情報（STS） を発行して使わせます。
外部 IdP（IDプロバイダー）とは、Entra ID / ADFS / Okta などを言います。
コメント