■AWS STS（Security Token Service）の特徴
- AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。
- 固有のプロファイル認証情報を通しての認証ではありません。
※「一時的」とありますが、STSは時間的な期限付きのアクセスキー／シークレットアクセスキー／セッショントークンになります。
一時的なセキュリティ認証情報をリクエストするには、AWS Security Token Service (AWS STS) を使用できます。
STSは 期限付きのアクセスキー／シークレットアク
AWS Security Token Service（AWS 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/bPxRfiCY
EXAMPLEKEY) の 2 つの部分から構成されます。
ユーザー名とパスワードと同様に、リクエストを認証するために、
アクセスキー ID とシークレットアクセスキーの両方を使用する必要があります。ユ ーザー名とパスワードと同様に、アクセスキーをしっかり管理して ください。
一方で、STS では「セッションポリシー」を条件に追加すること
セッションポリシーは、ロールまたはフェデレーティッドユーザー
の一時セッションをプログラムで作成する際にパラメータを渡す高 度なポリシーです。
セッションのアクセス許可は、セッションの作成に使用する IAM エンティティ (ユーザーまたはロール) のアイデンティティベースのポリシーとセッションポリシーの共通
部分です。
また、リソースベースのポリシーからアクセス許可が派生する場合
もあります。 これらのポリシーのいずれかを明示的に拒否した場合、その許可は 無効になります。
STS により一時的に AssumeRole が割り当てら
STS の AssumeRole API によって、IAM ユーザーや EC2 インスタンスなどのエン
つまり、アプリケーションは STS を呼び出して必要な IAM ロールを取得します。（ロールを引き受けます。）
一時的なセキュリティ認証情報のリクエスト
https://docs.aws.amazon.com/ja
IAM ユーザーのアクセスキーの管理
https://docs.aws.amazon.com/ja
IAM でのポリシーとアクセス許可 – セッションポリシー
https://docs.aws.amazon.com/ja
AssumeRole — クロスアカウントの委任とカスタム ID ブローカーを経由したフェデレーション
https://docs.aws.amazon.com/ja
更に 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 など
コメント