View a markdown version of this page

署名URLs の概要 - AWS 規範ガイダンス
署名付きリクエストを使用する動機

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

署名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 呼び出しで送信されるバイトを再送信することによる負荷をサポートする必要があります。総負荷に応じて、この要件により、ソリューションビルダーが回避する可能性のあるスケーリングチャレンジが追加されます。

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

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

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

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

一時的な 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 で有効期限を管理することにはトレードオフ があります。

管理者は、署名のみのソリューションを使用することをお勧めします。ただし、実際には、構築されたソリューションをサポートする必要があります。