AWS STS(Security Token Service)

■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/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_jp/IAM/latest/UserGuide/id_credentials_access-keys.html

 

IAM でのポリシーとアクセス許可 – セッションポリシー
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html#policies_session

 

AssumeRole — クロスアカウントの委任とカスタム ID ブローカーを経由したフェデレーション
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerole

 

 

更に Balck Belt で STS が出てくる資料を以下に抽出しました。

理解度が増すとか新しい気づきがあるかもしれません。

AWS STS(Security Token Service)

 

 

 

 

 

 

 

 

AWS STS(Security Token Service)

 

 

 

AWS STS(Security Token Service)

 

STSが利用できる API Action です。

AssumeRole は設定したことはありますが、こうして資料を確認すると他にも4つ API があります。

AWS STS(Security Token Service)

 

 

 

 

AWS STS(Security Token Service)

 

 

 

AWS STS(Security Token Service)

 

 

AWS STS(Security Token Service)

 

 

 

AWS CloudTrail

 

 

 

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 など

 

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

AlphaOmega Captcha Medica  –  What Do You See?
     
 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください