AWS Security Token Service (STS) とは？仕組みと使い方をわかりやすく解説

AWS Security Token Service (STS) は、一時的なセキュリティ認証情報を発行し、AWSリソースへのアクセスを安全に管理するための重要なサービスです。IAMユーザーの長期的なアクセスキーに依存せず、クロスアカウントアクセスやIDフェデレーションを実現するためには、STSの仕組みを正しく理解する必要があります。

本記事では、STSを利用すべき理由から具体的な設定手順、よくあるエラーの解決策までを網羅的に解説します。STSを適切に導入することで、認証情報の漏洩リスクを最小限に抑え、堅牢なセキュリティ環境を構築しましょう。

AWS Security Token Service (STS) 入門

AWS Security Token Service (STS) は、AWSリソースへアクセスするための一時的なセキュリティ認証情報を作成・提供するWebサービスです。通常、AWSを利用する際はIAMユーザーなどの「長期的な認証情報」を使用することがありますが、セキュリティの観点から、必要なときだけ有効な「一時的な権限」を付与する仕組みが推奨されています。この章では、AWS STSの基本的な役割と、なぜそれが現代のクラウドセキュリティにおいて重要なのかを解説します。

AWS STSの役割と基本概念

AWS STSの主な役割は、信頼されたユーザーやアプリケーションに対して、有効期限付きのアクセス権限を発行することです。これによって発行される認証情報は、アクセスキーID、シークレットアクセスキー、そしてセッショントークンの3つで構成されます。

STSが発行する認証情報は、数分から数時間という短い期間のみ有効であり、期限が切れると自動的に無効になります。これにより、万が一認証情報が漏洩した場合でも、被害を最小限に抑えることが可能です。長期的な認証情報（IAMユーザーのアクセスキーなど）とSTSによる一時的な認証情報の違いを整理すると、以下のようになります。

なぜ長期的なアクセスキーではなくSTSを使うべきなのか

AWSのベストプラクティスでは、IAMユーザーのアクセスキーのような長期的な認証情報の利用を極力減らすことが推奨されています。長期的なキーは、誤ってGitHubなどの公開リポジトリにアップロードしてしまったり、PCの紛失によって流出したりするリスクが常に伴います。

一方、STSを利用すれば、認証情報に有効期限が設定されるため、認証情報のライフサイクル管理が自動化され、セキュリティリスクを大幅に低減できるというメリットがあります。また、必要最小限の権限（最小権限の原則）を、必要な時間だけ付与するという運用が容易になるため、コンプライアンスの観点からもSTSの利用は必須と言えます。

詳細な仕様や公式のガイダンスについては、AWSの公式ドキュメントもあわせて参照してください。
AWS 公式ドキュメント: 一時的なセキュリティ認証情報

AWS STSを利用するための前提条件

AWS STSを利用して一時的な認証情報を取得するためには、いくつかの前提条件を満たす必要があります。基本的にはAWSアカウントを所有しており、適切な権限設定が行われていることがスタートラインとなります。

AWS STSの具体的な利用シーンとユースケース

AWS Security Token Service (STS) は、セキュリティを高めるために一時的な認証情報を発行するサービスですが、実際にどのような場面で使われるのかを理解することで、その重要性がより明確になります。ここでは、AWS STSが不可欠となる主要な4つの利用シーンについて解説します。

それぞれのユースケースにおける特徴と、使用される主なAPIアクションは以下の通りです。

開発環境と本番環境を分離するクロスアカウント戦略

企業でAWSを利用する場合、開発環境（Dev）と本番環境（Prod）でAWSアカウントを分けることが一般的です。この際、開発者が本番環境のデータを調査する必要が生じたときに、本番環境用のIAMユーザーを個別に作成して配布するのはセキュリティリスクが高まります。

ここでSTSの「スイッチロール（Switch Role）」機能が活躍します。開発アカウントのユーザーに対し、本番アカウントの特定のロール（役割）を引き受ける許可を与えることで、一時的な権限で本番環境へアクセス可能になります。

この仕組みは、複数のAWSアカウントを一元管理するAWS Organizations環境下でも頻繁に利用される、最も基本的なSTSの活用法です。

モバイルアプリ向けのWeb IDフェデレーション活用

スマートフォンアプリやWebアプリケーションから、S3への画像アップロードやDynamoDBへのデータ保存を行いたい場合、アプリ内にAWSのアクセスキー（長期的な認証情報）を埋め込むことは絶対に行ってはいけません。アプリの解析によってキーが流出し、不正利用される危険があるためです。

この問題を解決するために、STSを使用したWeb IDフェデレーションを利用します。ユーザーはGoogle、Facebook、Apple、Amazonなどの外部IDプロバイダーでログインし、そこで得られたトークンをSTSに渡すことで、AWSリソースへの一時的なアクセス権を取得します。

現在では、この仕組みをより簡単に実装するために Amazon Cognito が利用されるケースが大半ですが、Cognitoの裏側ではSTSの AssumeRoleWithWebIdentityが動作しており、セキュアな認証基盤を支えています。

社内ディレクトリと連携したSAMLフェデレーション

多くの企業では、社員のID管理にMicrosoft Active DirectoryやOktaなどのIDプロバイダー（IdP）を利用しています。AWSを利用するたびに専用のIAMユーザーを作成・管理するのは二重管理となり、退職者の削除漏れなどのリスクにつながります。

SAML 2.0（Security Assertion Markup Language 2.0）を利用したフェデレーションを行うことで、社内のIDを使ってAWSマネジメントコンソールへのシングルサインオン（SSO）が可能になります。

これにより、管理者は社内ディレクトリ側でユーザーを無効化するだけで、AWSへのアクセスも即座に遮断できるため、組織全体のガバナンス強化に繋がります。

EC2インスタンスプロファイルでのSTS自動利用

EC2インスタンス上で動作するアプリケーションが、S3バケットからファイルを読み込んだり、CloudWatchへログを出力したりする場合にも認証情報が必要です。この際、サーバー内の設定ファイルにアクセスキーを直接書き込む（ハードコーディングする）ことは推奨されません。

代わりに「IAMロール」をEC2インスタンスに関連付けます（インスタンスプロファイル）。これにより、EC2上のアプリケーションはAWS SDKやAWS CLIを通じて、メタデータサービスからSTSが発行した一時的な認証情報を自動的に取得・利用できるようになります。

この仕組みの最大のメリットは、認証情報のローテーション（定期的な変更）をAWS側が自動で行ってくれる点です。開発者は鍵の管理を意識することなく、安全にAWSリソースを利用したアプリケーション開発に専念できます。

AWS STSの設定とトラブルシューティング

AWS Security Token Service (STS) を安全かつ効果的に利用するためには、IAMポリシーによる適切な権限管理と、CLIやSDKを通じた正しい操作手順の理解が不可欠です。設定ミスはセキュリティリスクやアプリケーションの動作不良に直結するため、ここでは実務で押さえておくべき設定のポイントと、エラー発生時の対処法を具体的に解説します。

IAMポリシーでのSTS権限設定のポイント

STSを利用してロールを引き受ける（AssumeRole）ためには、IAMポリシーにおいて「誰が（Principal）」「どのロールに対して（Resource）」「何ができるか（Action）」を明確に定義する必要があります。特に重要なのが、ロール自体に設定する「信頼ポリシー（Trust Policy）」と、ロールを利用するユーザーやリソースに設定する「アイデンティティベースのポリシー」の整合性です。

設定を行う際は、セキュリティを高めるために以下の点に注意してください。

以下は、特定のIAMユーザーに対してロールの引き受けを許可するアイデンティティベースのポリシーの記述例です。

AWS CLIでのSTSコマンド実行例

開発現場やトラブルシューティングの際には、AWS CLI（Command Line Interface）を使用して一時的な認証情報を取得するケースが頻繁にあります。最も基本的なコマンドは aws sts assume-role です。

このコマンドを実行することで、AccessKeyId、SecretAccessKey、SessionTokenを含むJSON形式のレスポンスが返されます。これらを環境変数にセットすることで、一時的にそのロールの権限で操作が可能になります。

取得した一時クレデンシャルを利用するには、OSに応じて以下のように環境変数を設定します。

よくあるエラーと解決策

STSを利用する際によく遭遇するエラーコードとその原因、対処法をまとめました。エラーメッセージを確認し、適切な対応を行うことで迅速に問題を解決できます。

これらのエラーは、権限設定の不備やクレデンシャルの管理ミスが原因であることが大半です。特にクロスアカウントアクセスを行う場合は、双方のアカウントでのポリシー設定を入念に確認することをおすすめします。

よくある質問（FAQ）

AWS Security Token Service (STS) の導入や運用において、エンジニアや管理者からよく寄せられる疑問点をQ&A形式で解説します。

AWS STSとは簡単に言うと何ですか

AWS STS（Security Token Service）は、一時的なセキュリティ認証情報を作成して提供するAWSのWebサービスです。

通常、IAMユーザーには長期的に有効なアクセスキーを発行できますが、これらが漏洩すると永続的に不正利用されるリスクがあります。一方でAWS STSが発行する認証情報は、数分から数時間という有効期限が設定されており、期限が切れると自動的に無効になります。

物理的な鍵ではなく、「必要な権限を、必要な時間だけ貸し出すデジタルな合鍵」のようなものだとイメージすると分かりやすいでしょう。

AWS STSの料金体系について教えてください

AWS STSの利用自体に追加料金はかかりません。基本的に無料で利用できるサービスです。

ただし、STSのAPIを呼び出す際にリージョンを跨ぐ通信が発生する場合など、通常のAWSデータ転送量としての課金対象になることがあります。主なコスト構造は以下の表の通りです。

AWS STSのセッショントークンが切れたらどうなりますか

セッショントークンの有効期限が切れた瞬間に、その認証情報を使用したAWSリソースへのアクセスは拒否（Access Denied）されます。

システムを停止させないためには、アプリケーション側で有効期限が切れる前に新しいトークンを再取得するロジックを実装するか、AWS SDKが標準で提供している自動更新機能を利用するのが一般的です。エラーが発生してから対処するのではなく、事前に更新される設計にすることが推奨されます。

AWS STSはどのような人が使うべきサービスですか

セキュリティのベストプラクティスに従うすべてのAWS利用者が対象ですが、特に以下のような要件があるケースでは必須となります。

AWS STSの設定は難しいですか

基本的な利用、例えばEC2インスタンスにIAMロールを割り当ててSTSを裏側で利用するようなケースであれば、マネジメントコンソール上の操作だけで完結するため、それほど難しくありません。

一方で、クロスアカウントアクセスやSAML認証連携を行う場合は、「信頼ポリシー（Trust Policy）」のJSON記述や、IDプロバイダー側の設定が必要になります。これらを適切に設定するには、IAMの権限モデルに関する正しい理解が必要です。

詳細な設定方法やAPIのリファレンスについては、AWS Security Token Service API Referenceもあわせて参照してください。

まとめ

本記事では、AWS Security Token Service (STS) の仕組みから具体的な活用方法までを解説しました。STSは、一時的な認証情報を発行することで、長期的なアクセスキー漏洩のリスクを最小限に抑え、セキュアなAWS環境を実現するための重要なサービスです。

記事の要点は以下の通りです。

まずは開発環境でのスイッチロール設定など、身近なところからSTSの導入を試し、より安全で堅牢なクラウド運用を実践してみましょう。