リージョナル AWS STS エンドポイントの使用方法

本稿は、2024 年 2 月 26 日に AWS Security Blog で公開された “How to use Regional AWS STS endpoints” を翻訳したものです。

このブログ記事では、グローバル (レガシー) AWS Security Token Service (AWS STS) エンドポイントで、可用性が担保できない場合の回復力の向上に役立つ推奨事項を提供しています。グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com の可用性は高いですが、米国東部 (バージニア北部) という単一の AWS リージョンでホストされており、他のエンドポイントと同様に、他のリージョンのエンドポイントへの自動フェイルオーバーは提供されていません。この投稿では、設定にリージョナル AWS STS エンドポイントを使用することで、ワークロードのパフォーマンスと耐障害性を向上させる方法を紹介します。

認証には、認証情報の不注意による開示、共有、盗難などのリスクを減らすために、長期間の認証情報の代わりに一時的な認証情報を使用するのが最善です。AWS STS を使用すると、信頼できるユーザーは、権限が制限された一時的な認証情報をリクエストして、AWS リソースにアクセスできます。

一時的な認証情報には、アクセスキーペアとセッショントークンが含まれます。アクセスキーペアは、アクセスキー ID とシークレットキーで構成されています。AWS STS は一時的な認証情報を動的に生成し、要求に応じてユーザーに提供します。これにより、長期間の保管が不要になります。一時的な認証情報には有効期間が限られているため、管理したりローテーションしたりする必要はありません。

これらの認証情報を取得するには、いくつかの方法があります。

ロール、ユーザー、サービスなどの AWS プリンシパル
外部 ID プロバイダーの SAML を使用したフェデレーション
OAuth 2.0 や OpenID Connect (OIDC) アプリケーションによって提供されるようなウェブトークン

図 1: AWS STS に認証情報をリクエストする方法

グローバル (レガシー) とリージョナル AWS STS エンドポイント

AWS のサービスにプログラムから接続するには、エンドポイントを使用します。エンドポイントは、AWS STS のエントリポイントの URL です。

AWS STS は、すべてのリージョンにリージョナル AWS STS エンドポイントを提供します。AWS は当初、米国東部 (バージニア北部) リージョン (us-east-1) でホストされているグローバル AWS STS エンドポイント (現在はレガシー) https://sts.amazonaws.com を使用して AWS STS を構築しました。リージョナル AWS STS エンドポイントは、AWS アカウントの中でデフォルトで有効になっているリージョンでは、デフォルトで有効になっています。たとえば、 https://sts.ap-northeast-1.amazonaws.com はアジアパシフィック (東京) のリージョナル AWS STS エンドポイントです。デフォルトでは、AWS サービスはリージョナル AWS STS エンドポイントを使用します。たとえば、IAM Roles Anywhere は、トラストアンカーに対応するリージョナル AWS STS エンドポイントを使用します。各リージョンの AWS STS エンドポイントの完全なリストについては、「AWS Security Token Service エンドポイントとクォータ」を参照してください。リージョンが無効になっている場合は、AWS STS エンドポイントをアクティブ化することはできません。デフォルトでアクティブ化される AWS STS エンドポイントと、アクティブ化または非アクティブ化できるエンドポイントの詳細については、「リージョンとエンドポイント」を参照してください。

前述のように、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com は、米国東部 (バージニア北部) という単一のリージョンでホストされており、他のエンドポイントと同様に、他のリージョンのエンドポイントへの自動フェイルオーバーは提供されていません。AWS または AWS 外のワークロードがグローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com を使用するように設定されている場合は、米国東部 (バージニア北部) という単一のリージョンに依存することになります。万が一、そのリージョンでエンドポイントが使用できなくなったり、リソースとそのリージョンの間の接続が失われたりした場合、ワークロードは AWS STS を使用して一時的な認証情報を取得できなくなり、ワークロードに可用性のリスクが生じます。

AWS では、グローバル (レガシー) AWS STS エンドポイントではなく、リージョナル AWS STS エンドポイント (https://sts.<リージョン名>.amazonaws.com) を使用することを推奨しています。

回復力の向上に加えて、リージョナル AWS STS エンドポイントには他の利点もあります。

隔離と封じ込め — ワークロードと同じリージョンのリージョナル AWS STS エンドポイントにリクエストを送信することで、リージョン間の依存関係を最小限に抑え、リソースの範囲を一時的な認証情報の範囲に合わせて、可用性とセキュリティ上の懸念に対処できます。たとえば、ワークロードがアジアパシフィック (東京) リージョンで実行されている場合、アジアパシフィック (東京) リージョン (ap-northeast-1) のリージョナル AWS STS エンドポイントをターゲットにして、他のリージョンへの依存関係を削除できます。
パフォーマンス — サービスやアプリケーションに近いエンドポイントにAWS STS リクエストを送信することで、より低いレイテンシーと短い応答時間で AWS STS にアクセスできます。

図2は、一時的な認証情報のセットを返すAWS STS AssumeRole APIを呼び出すことで、AWS のプリンシパルが AWS Identity and Access Management (IAM) ロールを引き受けるプロセスを示しています。

図2: リージョナル AWS STS エンドポイントを使用して API を呼び出し、IAM ロールを引き受ける

同じリージョン内のリージョナル AWS STS への呼び出し

特定のリージョン内のワークロードを、そのリージョンのリージョナル AWS STS エンドポイントのみを使用するように設定する必要があります。リージョナル AWS STS エンドポイントを使用すると、ワークロードと同じリージョンで AWS STS を使用でき、リージョン間の依存関係がなくなります。たとえば、アジアパシフィック (東京) リージョンのワークロードは、リージョナルエンドポイント https://sts.ap-northeast-1.amazonaws.com のみを使用して AWS STS を呼び出す必要があります。リージョナル AWS STS エンドポイントにアクセスできなくなった場合、ワークロードは運用リージョン外のリージョナル AWS STS エンドポイントを呼び出すべきではありません。ワークロードにマルチリージョンの耐障害性要件がある場合、他のアクティブリージョンまたはスタンバイリージョンは、そのリージョンのリージョナルAWS STSエンドポイントを使用し、リージョンに障害が発生してもアプリケーションが機能するようにデプロイする必要があります。STSへのトラフィックは、他のリージョンから隔離された独立した同じリージョン内のリージョナル STS エンドポイントに送り、グローバル (レガシー) AWS STS エンドポイントへの依存関係を削除する必要があります。

AWS の外部から AWS STS への呼び出し

AWS 外のワークロードは、AWS 外にあるワークロードのレイテンシーが最も低い適切なリージョナル AWS STS エンドポイントを呼び出すように設定する必要があります。ワークロードにマルチリージョンの耐障害性要件がある場合は、リージョナル AWS STS エンドポイントにアクセスできなくなった場合に備えて、他のリージョンのリージョナル AWS STS エンドポイントへのフェイルオーバーロジックを構築してください。リージョナル AWS STS エンドポイントから取得した一時的な認証情報は、デフォルトのセッション期間、または指定した期間の間、全てのリージョンで有効です。

AWS CLI や SDK でリージョナル AWS STS エンドポイントを設定する方法

AWS STS API を呼び出すには、AWS コマンドラインインターフェイス (CLI) または AWS SDK の最新のメジャーバージョンを使用することをお勧めします。

AWS CLI

デフォルトでは、AWS CLI バージョン 2 は、現在設定されているリージョンのリージョナル AWS STS エンドポイントに AWS STS API リクエストを送信します。AWS CLI v2 を使用している場合は、追加の変更を加える必要はありません。

AWS CLI v1 は、デフォルトでは AWS STS リクエストをグローバル (レガシー) AWS STS エンドポイントに送信します。使用している AWS CLI のバージョンを確認するには、次のコマンドを実行します。$ aws --version

AWS CLI コマンドを実行すると、AWS CLI は特定の順序で認証情報の設定を探します。最初はシェルの環境変数で、次にローカルの AWS 設定ファイル (~/.aws/config) の設定を探します。

AWS SDK

AWS SDK は、さまざまなプログラミング言語と環境で利用できます。2022 年 7 月以降、AWS SDK の主要な新バージョンはデフォルトでリージョナル AWS STS エンドポイントに設定され、現在設定されているリージョンに対応するエンドポイントを使用します。2022 年 7 月以降にリリースされた AWS SDK のメジャーバージョンを使用する場合は、追加の変更を加える必要はありません。

AWS SDKは、認証情報の設定値が見つかるまで、さまざまな設定場所を探します。たとえば、AWS SDK for Python (Boto3) は、ソースを介して設定値を探す場合、次の探索順序に従います。

SDK のクライアント作成時に、AWS 設定パラメータとして渡される設定オブジェクト
環境変数
AWS 設定ファイル ~/.aws/config

まだ AWS CLI v1 を使用している場合、または AWS SDK バージョンがデフォルトでリージョナル AWS STS エンドポイントに設定されていない場合は、以下のオプションでリージョナル AWS STS エンドポイントを設定できます。

オプション1 — 共有の AWS 設定ファイルを使用する

AWS 設定ファイルは、LinuxまたはmacOSでは ~/.aws/config にあり、
Windows では C:\Users\USERNAME\.aws\config にあります。リージョナル AWS STS エンドポイントを使用するには、sts_regional_endpoints パラメータを追加してください。

次の例は、AWS 設定ファイルのデフォルトプロファイルを使用して、アジアパシフィック (東京) リージョン (ap-northeast-1) のリージョナル AWS STS エンドポイントの値を設定する方法を示しています。

[default]
region = ap-northeast-1
sts_regional_endpoints = regional

AWS STS エンドポイントパラメータ (sts_regional_endpoints) の有効値は次のとおりです。

legacy — グローバル (レガシー) AWS STSエンドポイント sts.amazonaws.com を使用します。
regional — 現在設定されているリージョンのリージョナル AWS STS エンドポイント sts.<リージョン名>.amazonaws.com を使用します。

注: 2022 年 7 月以降、AWS SDK の主要な新バージョンはデフォルトでリージョナル AWS STS エンドポイントに設定され、現在設定されているリージョンに対応するエンドポイントを使用します。AWS CLI v1 を使用している場合、AWS STS エンドポイントパラメータを使用するにはバージョン 1.16.266 以降を使用する必要があります。

AWS CLI コマンドで --debug オプションを使用すると、デバッグログを受け取り、どの AWS STS エンドポイントが使用されたかを検証できます。

$ aws sts get-caller-identity \
> --region ap-northeast-1 \
> --debug

デバッグログで useGlobalEndpoint を検索すると、useGlobalEndpoint パラメータが False に設定されていることがわかります。共有 AWS 設定ファイルまたは環境変数でリージョナル AWS STS エンドポイントが設定されている場合は、リージョナル AWS STS エンドポイントプロバイダーの完全修飾ドメイン名 (FQDN) が表示されます。

2024-09-05 12:14:12,870 - MainThread - botocore.regions - DEBUG - Calling endpoint provider with parameters: {'Region': 'ap-northeast-1', 'UseDualStack': False, 'UseFIPS': False, 'UseGlobalEndpoint': False}
2024-09-05 12:14:12,871 - MainThread - botocore.regions - DEBUG - Endpoint provider result: https://sts.ap-northeast-1.amazonaws.com

リージョナル AWS STS エンドポイントの共有 AWS 設定ファイル設定をサポートする AWS SDK のリストについては、「AWS SDK との互換性」を参照してください。

オプション2 — 環境変数を使用する

環境変数は、認証情報の設定を指定する別の方法を提供します。環境変数は、シェルセッション内でグローバルに AWS サービスへの呼び出しに影響します。ほとんどの SDK は環境変数をサポートしています。環境変数を設定すると、SDK はシェルセッションが終了するまで、または変数を別の値に設定するまで、その値を使用します。変数を今後のセッションでも維持するには、シェルの起動スクリプトで変数を設定します。

次の例は、環境変数を使用してアジアパシフィック (東京) リージョン (ap-northeast-1) のリージョナル AWS STS エンドポイントの値を設定する方法を示しています。

Linux または macOS

$ export AWS_DEFAULT_REGION=ap-northeast-1
$ export AWS_STS_REGIONAL_ENDPOINTS=regional

以下のコマンドを実行して、環境変数を確認できます。

$ (echo $AWS_DEFAULT_REGION; echo $AWS_STS_REGIONAL_ENDPOINTS)

出力は次のようになります。

ap-northeast-1
regional

Windows

C:\> set AWS_DEFAULT_REGION=ap-northeast-1
C:\> set AWS_STS_REGIONAL_ENDPOINTS=regional

次の例は、環境変数を設定して、AWS SDK for Python (Boto3) で STS クライアントがリージョナル AWS STS エンドポイントを使用するように設定する方法を示しています。

import boto3
import os
os.environ["AWS_DEFAULT_REGION"] = "ap-northeast-1"
os.environ["AWS_STS_REGIONAL_ENDPOINTS"] = "regional"

メタデータ属性 sts_client.meta.endpoint_url を確認して、STS クライアントがどのように構成されているかを調べたり、検証したりできます。出力は次のようになります。

>>> sts_client = boto3.client("sts")
>>> sts_client.meta.endpoint_url
'https://sts.ap-northeast-1.amazonaws.com'

リージョナル AWS STS エンドポイントの環境変数設定をサポートする AWS SDKのリストについては、「AWS SDK との互換性」を参照してください。

オプション 3 — エンドポイント URL を指定する

特定のリージョナル AWS STS エンドポイントのエンドポイント URL を手動で指定することもできます。

次の例は、特定のエンドポイント URL を設定することで、AWS SDK for Python (Boto3) で STS クライアントがリージョナルの AWS STS エンドポイントを使用するように設定する方法を示しています。

import boto3
sts_client = boto3.client('sts', region_name='ap-northeast-1', endpoint_url='https://sts.ap-northeast-1.amazonaws.com')

AWS STS で VPC エンドポイントを使用する

Amazon VPC にデプロイしたリソースから、AWS STS へのプライベート接続を作成できます。AWS STS は、インターフェイス VPC エンドポイントを使用して AWS PrivateLink と統合します。AWS PrivateLink のネットワークトラフィックは、グローバルAWSネットワークのバックボーンにとどまり、パブリックインターネットを経由しません。AWS STS の VPC エンドポイントを設定すると、リージョナル AWS STS エンドポイントのトラフィックはその VPC エンドポイントを使用して通信を行います。

デフォルトでは、VPC の DNS はリージョナル AWS STS エンドポイントのエントリを更新して、VPC 内の AWS STS の VPC エンドポイントのプライベート IP アドレスに解決します。Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行した以下のコマンドの結果は、AWS STS エンドポイントの DNS 名が、AWS STS の VPC エンドポイントのプライベート IP アドレスに解決されることを示しています。

[ec2-user@ip-10-120-136-166 ~]$ nslookup sts.ap-northeast-1.amazonaws.com
Server: 10.120.0.2
Address: 10.120.0.2#53

Non-authoritative answer:
Name: sts.ap-northeast-1.amazonaws.com
Address: 10.120.138.148

使用しているリージョンで AWS STS のインターフェイス VPC エンドポイントを作成したら、同じリージョンの AWS STS にアクセスするために、環境変数を使用してそれぞれのリージョナル AWS STS エンドポイントの値を設定します。

次のログの出力は、リージョナル AWS STS エンドポイントに対して AWS STS 呼び出しが行われたことを示しています。

POST
/

content-type:application/x-www-form-urlencoded; charset=utf-8
host:sts.ap-northeast-1.amazonaws.com

AWS STS リクエストのログ

AWS CloudTrail イベントを使用して、AWS STS に使用されたリクエストとエンドポイントに関する情報を取得できます。この情報は、AWS STS のリクエストパターンを特定し、グローバル (レガシー) STS エンドポイントをまだ使用しているかどうかを確認するのに役立ちます。

CloudTrail のイベントは、AWS アカウントでのアクティビティの記録です。CloudTrail イベントは、AWS マネジメントコンソール、AWS SDK、コマンドラインツール、その他の AWS サービスを通じて行われた API と非 API の両方のアクティビティの履歴を提供します。

ログの場所

リージョナル AWS STS エンドポイント https://sts.<リージョン名>.amazonaws.com へのリクエストは、それぞれのリージョン内のCloudTrailに記録されます。
グローバル (レガシー) AWS STS エンドポイント sts.amazonaws.com へのリクエストは、米国東部 (バージニア北部) リージョン (us-east-1) に記録されます。

ログフィールド

リージョナル AWS STS エンドポイントとグローバル (レガシー) AWS STS エンドポイントへのリクエストは、CloudTrail の tlsDetails フィールドに記録されます。このフィールドを使用して、リクエストがリージョナル AWS STS エンドポイントに送信されたのか、グローバル (レガシー) AWS STS エンドポイントに対して行われたのかを判断できます。
VPC エンドポイントからのリクエストは、CloudTrail の vpcEndpointId フィールドに記録されます。

次の例は、VPC エンドポイントを持つリージョナル AWS STS エンドポイントへの STS リクエストの CloudTrail イベントを示しています。

"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"vpcEndpointId": "vpce-021345abcdef6789"",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.2",
"cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
"clientProvidedHostHeader": "sts.ap-northeast-1.amazonaws.com"
}

次の例は、グローバル (レガシー) AWS STS エンドポイントへの STS リクエストの CloudTrail イベントを示しています。

"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.2",
"cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
"clientProvidedHostHeader": "sts.amazonaws.com"
}

AWS STSのログデータをインタラクティブに検索して分析するには、Amazon CloudWatch Logs Insights または Amazon Athena を使用してください。

Amazon CloudWatch Logs Insights

次の例は、CloudWatch Logs Insightsクエリを実行して、グローバル (レガシー) AWS STS エンドポイントに対して行われた API 呼び出しを探す方法を示しています。CloudTrail イベントをクエリする前に、CloudWatch Logs にイベントを送信するように CloudTrail の証跡を設定する必要があります。

filter eventSource="sts.amazonaws.com" and tlsDetails.clientProvidedHostHeader="sts.amazonaws.com"
| fields eventTime, recipientAccountId, eventName, tlsDetails.clientProvidedHostHeader, sourceIPAddress, userIdentity.arn, @message
| sort eventTime desc

クエリ出力には、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com に対して行われた AWS STS 呼び出しのイベントの詳細が表示されます。

図 3: CloudWatch Logs Insights のクエリを使用して STS API 呼び出しを検索します

Amazon Athena

次の例は、Amazon Athena で CloudTrail イベントをクエリし、グローバル (レガシー) AWS STS エンドポイントに対して行われた API 呼び出しを検索する方法を示しています。

SELECT
eventtime,
recipientaccountid,
eventname,
tlsdetails.clientProvidedHostHeader,
sourceipaddress,
eventid,
useridentity.arn
FROM "cloudtrail_logs"
WHERE
eventsource = 'sts.amazonaws.com' AND
tlsdetails.clientProvidedHostHeader = 'sts.amazonaws.com'
ORDER BY eventtime DESC

クエリ出力には、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com に対して行われた STS 呼び出しが表示されます。

図 4: Athena を使用して STS API 呼び出しを検索し、STS エンドポイントを特定します

まとめ

この投稿では、リージョナル AWS STS エンドポイントを使用して、AWS で使用しているリージョンの回復力を高め、レイテンシーを減らし、セッショントークンの有用性を向上する方法を学びました。

環境内の AWS STS エンドポイントの設定と使用状況を確認し、CloudTrail ログで AWS STS のアクティビティを検証し、リージョナル AWS STS エンドポイントが使用されていることを確認することをおすすめします。

質問がある場合は、セキュリティ、アイデンティティ、コンプライアンスの re:Post トピックに投稿するか、AWS サポートに連絡してください。

著者について

Darius Januskis は AWS の Senior Solutions Architect で、世界中の金融サービスを提供しているお客様のクラウドへの移行を支援しています。彼は情熱的なテクノロジー愛好家で、お客様と協力し、well-architected なソリューションを構築できるよう支援することを楽しんでいます。彼の関心事には、セキュリティ、DevOps、自動化、サーバーレステクノロジーが含まれます。

翻訳はクラウドサポートエンジニアの森永が担当し、大金がレビューしました。

Amazon Web Services ブログ