Amazon S3 アップデート — SigV2 の廃止時期、延期と変更

Amazon S3 API に対して行うすべてのリクエストは、それが本物であることを確認するために署名する必要があります。初期の AWS では、署名バージョン2 または SigV2 と呼ばれる署名モデルを使用していました。2012年には、より柔軟な署名方法である SigV4 を発表し、2013年以降に開始されたすべてのリージョンでは、こちらを唯一の署名方法としました。また、その時点で、すべての新しい S3 アプリケーションにこちらのSigV4を使用することをお勧めしました。

2018年に、我々はSigV2のサポート終了を2019年6月後半とするという発表をしました。多くのお客様がアプリケーションを更新してくださいました（多くのケースで単純にSDKのアップデートを行うだけです）が、SigV4を使用するために、サポートを延期してもらえないかという多くのご要望をいただきました。

新しい日付、新しいプラン
オリジナルのプランに関するフィードバックに応じて、重要な変更を行っていきます。概要は次のとおりです。

オリジナルのプラン — SigV2のサポートは2019年6月24日に終了します。

改訂されたプラン — 2020年6月24日以降に作成された新しいバケットは SigV2 署名付きリクエストはサポートされません。ただし、既存のバケットについて引き続き SigV2 がサポートされますが、我々はお客様が古いリクエスト署名方法から移行するよう働きかけます。

既存のバケット、それは SigV2 をサポートする一部のAWSリージョンにおいて、SigV2 を引き続き使用することはできますが、SigV4 に移行することを強くお勧めします。そのことで重要なセキュリティ上のメリットと効率性のメリットが得られます。この新しい署名方法では、長期のAWSアクセスキーから派生した、別途これに特化した署名キーを使用します。このキーは、サービス、地域、および日付に固有です。これにより、サービスとリージョン間の分離が強化され、キーの再利用に対する保護が強化されます。内部的に、SigV4 実装では認証チェックの結果を安全にキャッシュすることができます。これにより、レイテンシーが改善され、アプリケーションの全体的な堅牢性向上が期待できます。詳細については、「署名バージョン4の変更点」を参照してください。

SigV2 を使っているかどうかの判断方法
S3 は 2006年以来からのAWSサービスです。あなたやあなたの前任者が書いたコードの一部はまだまだ現役で利用されている可能性があり、SigV2で署名された要求を忠実に行っているかもしれません。CloudTrailのデータイベントまたは S3 サーバーアクセスログを使用して、この古風なリクエストを見つけることができますので、そのアプリケーションを更新対象にしてください。

CloudTrailのデータイベント — 各 CloudTrail イベントエントリの additionalDataElement 内で SignatureVersion 要素を探します（詳細については、「AWS CloudTrail を使用して Amazon S3 署名バージョン2リクエストを識別する」を参照してください）。

S3 サーバーアクセスログ — このログから SignatureVersion 要素を探します（詳細については、「Amazon S3 アクセスログを使用して署名バージョン2リクエストを識別する」を参照してください）。

SigV4へ更新するには

“私たちは、コードを変える必要があるでしょうか?”

ヨーロッパ (フランクフルト)、米国東部 (オハイオ州)、カナダ (中央)、ヨーロッパ (ロンドン)、アジアパシフィック (ソウル)、アジアパシフィック (ムンバイ)、ヨーロッパ (パリ)、中国 (寧夏)、ヨーロッパ (ストックホルム)、アジアパシフィック (大阪ローカル)、AWS GovCloud (米国東部)、アジアパシフィック (香港) のリージョンは 2013 年以降に開始されたため、SigV4 はサポートされますが、SigV2はサポートされていません。言い換えると、もし、これらのいずれかのリージョンの S3 バケットにアクセスするコードをお持ちの場合は、すでに SigV4 を排他的に使用していることになります。

最新バージョンの AWS SDK を使用している場合は、2020年6月24日以降に作成する新しいバケットを利用するにあたって、すでにSigV4 要件を満たす準備が整っていることになります。もし、古いSDKを使用している場合は、詳細なバージョン一覧を参照してください。詳細については、「署名バージョン2から署名バージョン4への移行」を参照してください。

コードにいくつかの変更を加える必要がある状況がいくつかあります。たとえば、AWS Java、JavaScript(node.js)、または Python SDK で署名付きURLを使用している場合です。この場合、クライアント設定で正しいリージョンと署名バージョンを指定する必要があります。また、SigV4 署名付きURLは最大で7日間有効ですが、SigV2 署名付きURLは、数週間または数年になる最大有効期限を作成できます（ほとんどのユースケースで、時間制限されたURLを使用することをはるかに良い方法としています）。SigV4 を使用することでセキュリティプロファイルが改善されるのですが、この違いのために、署名付きURLの作成、保存、使用方法の変更が必要になる場合があります。長期間有効な署名付き URL の使用は開発者にとって簡単で便利なこともありましたが、有効期間が限られたURLとなるSigV4を利用する方が、セキュリティ対策としてははるかに優れています。

Amazon EMR を使用している場合は、クラスターをバージョン 5.22.0 以降にアップグレードして、S3 へのすべてのリクエストが SigV4 を使用して行われるようにしてください（詳細については、Amazon EMR 5.x リリースバージョンを参照してください）。

S3 オブジェクトが Amazon CloudFront で前面に存在し、独自のリクエストに署名する場合は、必ず SigV4 を使用するようにコードを更新してください。オリジンアクセスアイデンティティーを使用して S3 へのアクセスを制限する場合は、x-amz-content-sha256 ヘッダーと適切なリージョンの S3 ドメインエンドポイントを含めてください。

我々がお手伝いします
AWS チームは、SigV4 への移行を可能な限りスムーズでたやすいものにするお手伝いしたいと考えています。問題が発生した場合は、「AWS サポートの使用開始」で説明されているように、AWS サポートを活用することを強くお勧めします。

また、Redditにて、こちらのポストで議論することができます！

– Jeff;

（翻訳は SA 焼尾が担当しました。原文はこちらです。）