署名付き URLsの概要

署名付き URL は、 AWS Identity and Access Management (IAM) サービスによって認識される HTTP リクエストの一種です。このタイプのリクエストを他の AWS すべてのリクエストと区別するのは、X-Amz-Expires クエリパラメータ です。他の認証されたリクエストと同様に、署名付き URL リクエストには署名が含まれます。署名付き URL リクエストの場合、この署名は で送信されますX-Amz-Signature。署名は、署名バージョン 4 の暗号化オペレーションを使用して、他のすべてのリクエストパラメータをエンコードします。

メモ

• 署名バージョン 2 は現在、 の廃止中ですが、一部の では引き続きサポートされています AWS リージョン。このガイドは、署名バージョン 4 の署名に適用されます。

• 受信側サービスは署名なしヘッダーを処理できますが、そのオプションのサポートは、ベストプラクティスに従って制限され、ターゲットを絞ったものです。特に明記されていない限り、リクエストを受け入れるにはすべてのヘッダーに署名する必要があると仮定します。

X-Amz-Expires パラメータを使用すると、エンコードされた日付時刻から大きく逸脱して署名を有効として処理できます。署名の有効性のその他の側面は引き続き評価されます。署名認証情報が一時的に有効になる場合は、署名の処理時に期限切れにしないでください。署名認証情報は、処理時に十分な権限を持つ IAM プリンシパルにアタッチする必要があります。

署名付き URLsは、署名付きリクエストのサブセットです。

署名付き URL は、将来のリクエストに署名する唯一の方法ではありません。Amazon S3 は、一般的に署名付き POST リクエストもサポートしています。署名付き POST 署名は、署名付きポリシーに準拠し、そのポリシーに有効期限が埋め込まれているアップロードを許可します。

リクエストの署名は将来の日付になる場合がありますが、これは一般的ではありません。基盤となる認証情報が有効である限り、署名アルゴリズムは将来の日付を禁止するものではありません。ただし、これらのリクエストは有効なタイミングウィンドウまで正常に処理できないため、ほとんどのユースケースでは将来の日付設定が実用的ではありません。

署名付きリクエストで許可されるもの

署名付きリクエストは、リクエストの署名に使用された認証情報によって許可されるアクションのみを許可できます。認証情報が署名付きリクエストで指定されたアクションを暗黙的または明示的に拒否した場合、署名付きリクエストは送信時に拒否されます。これは、以下に適用されます。

• 認証情報に関連付けられているセッションポリシー

• 認証情報に関連付けられているプリンシパルに関連付けられているポリシー

• セッションまたはプリンシパルに影響するリソースポリシー

• セッションまたはプリンシパルに影響するサービスコントロールポリシー

署名付きリクエストを使用する動機

セキュリティエンジニアは、ソリューションビルダーが署名付き URLs を使用する動機となるものを認識する必要があります。何が必要で、何がオプションであるかを理解することは、ソリューションビルダーとの通信に役立ちます。動機には次のようなものがあります。

• Amazon S3 のスケーラビリティのメリットを得ながら、非 IAM 認証メカニズムをサポートするため。主な動機は、Amazon S3 と直接通信して、このサービスが提供する組み込みのスケーラビリティのメリットを享受することです。この直接通信がない場合、ソリューションは PutObjectおよび GetObject呼び出しで送信されるバイトを再送信することによる負荷をサポートする必要があります。総負荷に応じて、この要件により、ソリューションビルダーが回避する可能性のあるスケーリングチャレンジが追加されます。

  AWS Security Token Service （AWS STS) で一時的な認証情報を使用したり、URLs の外部で署名バージョン 4 の署名を使用したりするなど、Amazon S3 と直接通信するその他の方法は、ユースケースには適していない場合があります。Amazon S3 は認証情報を使用して AWS ユーザーを識別しますが、署名付きリクエストは AWS 認証情報以外のメカニズムによる識別を前提としています。データの直接通信を維持しながらこの違いを分割することは、署名付きリクエストによって実現できます。

• ブラウザが URLs。URLsはブラウザによって理解されますが、 AWS STS 認証情報と署名バージョン 4 の署名は理解されません。これは、ブラウザベースのソリューションと統合する場合に便利です。代替ソリューションにはより多くのコードが必要で、大きなファイルにはより多くのメモリが使用され、マルウェアやウイルススキャナーなどの拡張機能によって異なる処理が行われる可能性があります。

一時的な AWS STS 認証情報との比較

一時的な認証情報は、署名付きリクエストに似ています。どちらも有効期限が切れ、アクセス範囲指定が許可され、一般的に AWS 認証情報を必要とする使用状況に IAM 以外の認証情報をブリッジするために使用されます。 

一時的な AWS STS 認証情報を 1 つの S3 オブジェクトとアクションに厳密にスコープできますが、 AWS STS APIs には制限があるため、スケーリングの課題が発生する可能性があります。（詳細については、AWS re:Post ウェブサイトの「IAM および の API スロットリングまたは「レート超過」エラーを解決する方法 AWS STS」を参照してください。） さらに、生成された各認証情報には AWS STS API コールが必要です。これにより、レイテンシーと、回復力に影響する可能性のある新しい依存関係が追加されます。一時的な AWS STS 認証情報の有効期限も最小 15 分ですが、署名付きリクエストではより短い期間をサポートできます (適切な条件では 60 秒が実用的です）。

署名のみのソリューションとの比較

署名付きリクエストの本来のシークレットコンポーネントは、署名バージョン 4 の署名のみです。クライアントがリクエストの他の詳細を知っており、それらの詳細に一致する有効な署名が提供されている場合は、有効なリクエストを送信できます。有効な署名がないと、署名できません。

署名付き URLsと署名のみのソリューションは、暗号的に類似しています。ただし、署名のみのソリューションには、クエリ文字列パラメータの代わりに HTTP ヘッダーを使用して署名を送信する機能など、実用的な利点があります (「インタラクションと緩和のログ記録」セクションを参照）。また、管理者は、クエリ文字列がより一般的にメタデータとして扱われ、ヘッダーはそれほど一般的に扱われないことも考慮する必要があります。

一方、 AWS SDKs、署名を直接生成して使用するサポートが少なくなります。署名のみのソリューションを構築するには、より多くのカスタムコードが必要です。実用的な観点からは、セキュリティ上のカスタムコードの代わりにライブラリを使用することが一般的なベストプラクティスであるため、署名のみのソリューションのコードには追加の精査が必要です。

署名のみのソリューションは、X-Amz-Expiresクエリ文字列を使用せず、明示的な有効期間も提供しません。IAM は、明示的な有効期限がない署名の暗黙的な有効期間を管理します。これらの暗黙的な期間は公開されません。通常、これらは変更されませんが、セキュリティを念頭に置いて管理されるため、有効期間に依存するべきではありません。有効期限を明示的に制御することと、IAM が有効期限を管理することにはトレードオフがあります。

管理者として、署名のみのソリューションが望ましい場合があります。ただし、実際には、構築されたソリューションをサポートする必要があります。