【ITニュース解説】AWS Security Token Service STS and usage

AWS Security Token Service（AWS STS）は、AWSのリソースにアクセスするための「一時的なセキュリティ認証情報」を発行する重要なサービスである。システムエンジニアとしてAWSを扱う上で、このSTSの理解は欠かせない。通常、AWSの管理コンソールやプログラムからリソースにアクセスするには、IAMユーザーに紐付けられた永続的なアクセスキーや、IAMロールが持つアクセス許可が必要となる。しかし、永続的な認証情報は、もし誤って漏洩した場合、悪意のある第三者に無期限でAWSリソースを操作されるリスクがあるという大きなセキュリティ上の懸念を抱えている。STSは、この永続的な認証情報の課題を解決するために設計されたサービスで、短期間だけ有効な「鍵」を必要に応じて生成し、その利用を許可する役割を担っている。

STSが発行する一時的なセキュリティ認証情報には、アクセスキーID、シークレットアクセスキー、セッショントークン、そして有効期限が含まれる。これらの情報は、通常の永続的なアクセスキーと似ているが、セッショントークンが付与され、特定の時間（数分から数時間）が経過すると自動的に無効になる点が大きく異なる。この一時的な特性が、AWSのセキュリティを大幅に向上させる。

STSの主な用途は多岐にわたるが、特に重要な利用シナリオがいくつか存在する。まず、IAMユーザーやIAMロールに対して、必要最小限の時間だけAWSリソースへのアクセスを許可する場合である。例えば、ある開発者が特定のプロジェクトのために一時的にAWSリソースにアクセスする必要があるが、永続的なアクセスキーは発行したくない場合に、STSを使って短期間だけ有効な認証情報を与えることができる。これにより、プロジェクトが終了したり、必要な時間が経過したりすれば、認証情報は自動的に失効するため、鍵の管理負担や漏洩リスクを大幅に軽減できる。

次に、複数のAWSアカウント間でリソースを共有する「クロスアカウントアクセス」の実現にもSTSは不可欠である。例えば、本番環境と開発環境をそれぞれ異なるAWSアカウントで運用している企業で、開発環境のアカウントから本番環境のアカウントのリソース（例えばデータベース）に一時的にアクセスしたいといった状況が考えられる。このような場合、開発アカウントのIAMロールがSTSのAssumeRoleというAPIを呼び出し、本番アカウントに作成された特定のIAMロールの権限を一時的に「引き受ける」ことで、安全にリソースにアクセスできるようになる。これにより、永続的な認証情報をアカウント間で共有する必要がなくなり、各アカウントのセキュリティ境界を維持しながら協力作業が可能になる。

さらに、「フェデレーテッドアクセス」は、企業が既に利用している既存のIDプロバイダー（例えばMicrosoft Active Directory、Okta、Google Workspaceなど）の認証情報を使って、AWSにアクセスできるようにする仕組みであり、ここでもSTSが重要な役割を果たす。この方式では、AWS上に個々のユーザーに対応するIAMユーザーをいちいち作成する必要がない。ユーザーは自社のIDプロバイダーで認証を受け、STSはその認証結果に基づいて一時的なAWS認証情報を発行する。これにより、従業員は普段使い慣れた企業のログイン情報でAWSサービスにアクセスできるようになり、企業はIAMユーザーの管理の手間を省きつつ、セキュリティと利便性を両立できる。シングルサインオン（SSO）をAWSで実現する際の基盤技術が、このSTSとフェデレーテッドアクセスの組み合わせだと言える。

モバイルアプリケーションやウェブブラウザベースのアプリケーションからAWSリソースにアクセスする際も、STSは活躍する。例えば、ユーザーがスマートフォンアプリからS3バケットに画像をアップロードするような場合、アプリに永続的なAWSアクセスキーを埋め込むのはセキュリティ上非常に危険である。このようなケースでは、Amazon CognitoといったサービスとSTSを連携させることで、アプリのユーザーに一時的な認証情報を提供し、安全にAWSリソースへのアクセスを許可する。ユーザーがアプリにログインすると、CognitoがSTSを通じて一時的な認証情報を取得し、アプリはその情報を使ってAWSサービスにアクセスする。これにより、アプリ開発者は永続的なアクセスキーの管理や漏洩のリスクを心配することなく、AWSの機能を活用できる。

STSの利用は、システム全体のセキュリティ体勢を強化する上で極めて重要である。永続的なアクセスキーは、一度漏洩するとその影響が広範囲に及び、長期にわたってリスクをもたらす可能性がある。対して、STSが発行する一時的な認証情報は、有効期限が設定されているため、万が一漏洩したとしても、その影響は限定的であり、時間と共に自動的にリスクが解消される。この「短命な認証情報」という考え方は、「最小権限の原則」とともに、クラウドセキュリティのベストプラクティスとして強く推奨されている。

実際にSTSを利用する際には、例えばAssumeRoleやGetSessionTokenといったSTSのAPIをプログラムから呼び出すことで、一時的な認証情報を取得する。これらのAPIコールには、どのロールの権限を引き受けるか、あるいはどの程度の期間認証情報を有効にするかといったパラメータを含めることができる。STSからの応答として、アクセスキーID、シークレットアクセスキー、セッショントークン、そしてその認証情報がいつまで有効であるかを示す有効期限の情報が返却される。アプリケーションやスクリプトは、これらの情報を受け取り、AWS SDKやAWS CLIを通じてAWSサービスへのリクエストを認証する際に利用する。有効期限が切れると、その認証情報ではAWSリソースにアクセスできなくなるため、必要に応じて再度STSから新しい一時認証情報を取得する必要がある。

システムエンジニアとしてAWSを設計・運用する際には、これらのSTSの機能とユースケースを深く理解していることが求められる。特に、AWS認定試験では、一時的なアクセス、クロスアカウントアクセス、フェデレーテッドアクセスのシナリオでSTSの知識が頻繁に問われる。これは、実際のシステム構築においても、これらのセキュリティ要件が非常に重要であることの表れだと言える。永続的な認証情報ではなく、一時的かつ最小限の権限でAWSリソースにアクセスさせる設計は、セキュアなクラウド環境を構築するための基本中の基本であり、STSはその実現において中心的な役割を果たすサービスなのである。