S3署名の時刻エラーを解決する

時計や認証情報を変更する前に、S3レスポンスの正確なコードとメッセージを確認してください。RequestTimeTooSkewed、SignatureDoesNotMatch、署名付きURLの有効期限切れはそれぞれ異なる問題です。現在のdosyaゲートウェイは以下の後者2件を返しますが、RequestTimeTooSkewedレスポンスや、通常のリクエストにおける文書化された時刻ずれの許容範囲は実装していません。

始める前に: 実際のエラーを特定する

失敗した操作1件のステータスと機密情報を伏せたXMLのCode/Messageに加え、クライアントのバージョンと実際のエンドポイントのホスト・パスを保存してください。dosyaの認証XMLにはRequestId（現在は0）が含まれますが、診断用のサーバー時刻や最大時刻ずれのフィールドが必ず含まれるわけではありません。共有する情報からAuthorization、S3シークレット、署名付きURLのクエリ文字列全体を削除してください。

レスポンス	現在のdosya実装での意味
403 SignatureDoesNotMatch / The request signature does not match	再計算したSigV4署名が一致しません。シークレットの組み合わせや署名対象データの変更を調べてください。このメッセージだけでは時計のずれを証明できません。
403 AccessDenied / Request has expired	署名付きリクエストの署名時刻から指定された有効期間が過ぎています。
400 InvalidRequest / X-Amz-Expires is required for presigned requests	クエリ認証リクエストに必須の有効期間がありません。
400 InvalidRequest / X-Amz-Expires must be an integer between 1 and 604800 seconds	指定された期間が無効です。編集せず再生成してください。
400 InvalidRequest / Invalid X-Amz-Date	署名日時がパーサーのYYYYMMDDTHHMMSSZ形式ではありません。
403 AccessDenied / Missing X-Amz-Date	署名済みヘッダーのリクエストにタイムスタンプがありません。
403 InvalidAccessKeyId	アクセスIDが無効、無効化済み、有効期限切れ、またはその他の理由で利用できません。時刻を同期してもキーは復旧しません。

確認済みの署名付きURLの有効期間は**1〜604,800秒（7日）**です。サーバーは有効期限の境界時刻ちょうどを受け付け、その後は拒否します。現在のヘッダー認証コードには一般的な「±5/15分」の確認がなく、署名付きURLのコードにも未来の日時に対する時刻ずれの許容範囲はありません。古いヘッダー署名を使い続けられることや、AWSの許容範囲が適用されることを前提にせず、再試行のたびに新しいリクエストを生成してください。

クライアントがRequestTimeTooSkewedを報告する場合、ネットワークリクエストがAWSや別のサービス、プロキシではなく、実際にapi.dosya.dev/s3に送られたか確認してください。クライアントに表示される説明は、別の基になるレスポンスを要約している場合があります。AWSのトラブルシューティングガイドはAWSの時刻に関する署名エラーを説明していますが、dosyaの時刻に関するポリシーを定めるものではありません。

手順: 署名するマシンの時刻を確認する

1. 失敗している自動ジョブを一時停止し、同じ署名済みペイロードの再送を止めてください。署名がコンピューター、コンテナー、ビルドランナー、アプリケーションサーバーのどこで行われるか確認してください。別の場所で作成された署名はブラウザの時計を修正しても直りません。
2. そのシステムのUTC時刻を確認してください。以下のコマンドは時刻と状態を表示するだけで、マシンを変更しません。

# macOS or Linux
 date -u '+%Y-%m-%dT%H:%M:%SZ'
# Linux systems that use systemd (not every container has it)
 timedatectl status

# Windows PowerShell
(Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
w32tm /query /status

3. 組織が使用する信頼できる時刻源と比較してください。UTCはタイムゾーンにかかわらず同じ瞬間を表します。表示タイムゾーンを変更するだけでは時計は同期されません。サーバーのHTTP Dateヘッダーは大きな差を見つける助けになりますが、権威ある時刻同期サービスではなく、プロキシやキャッシュによって誤解を招く場合があります。
4. 時刻が間違っている場合は、OSがサポートする自動時刻設定または管理者の時刻サービスを使用してください。macOSの「日付と時刻」設定では日付と時刻の自動設定を利用でき、Windowsの「日付と時刻」には時刻の同期設定があります。systemd Linuxでは表示されるNTPの状態を確認してください。管理対象デバイス、VM、コンテナーではホスト管理者による同期の修正が必要な場合があります。変更後にUTC出力をもう一度確認してください。

これらのコマンドには、環境によってサービスや権限が必要な場合があります。timedatectlまたはw32tmコマンドが実行できなくても、dosyaの認証情報が無効である証拠にはなりません。HTTPS検証を無効にしたりキーの権限を広げたりせず、署名元を同期した状態に保ってください。

手順: 新しく署名した読み取り専用テストを実行する

正しく設定されたAWS CLI v2プロファイルを使用してください。ここではdosya-help-checkという名前にします。S3のアクセスIDとシークレットのペアを設定し、リージョンをus-east-1、s3.addressing_styleをpathに設定する必要があります。プロフィール → API（APIキー）からS3を有効にしたキーを展開し、「S3」認証情報 → 有効化を選んでペアを取得してください。シークレットは生成時のダイアログでのみ表示されます。診断にはワークスペースに固定し、S3ゲートウェイを許可した読み取り専用キーを使用してください。ワークスペースロールでもS3と一覧取得を許可する必要があります。

シークレットをシェル引数に渡さず、aws configure --profile dosya-help-checkで対話的にプロファイルを設定してください。無関係な既存プロファイルを上書きしないでください。aws configure set s3.addressing_style path --profile dosya-help-checkでパス形式を設定してください。以下のws_exampleを連携 → S3のBucketに置き換えてください。

aws --profile dosya-help-check --region us-east-1 --endpoint-url https://api.dosya.dev/s3 s3api list-objects-v2 --bucket ws_example --max-keys 1 --no-paginate

このコマンドの実行時には新しいリクエストに署名します。保存された署名付きURLの再試行では新たに署名されません。一覧の1ページが返り、CLIの終了ステータスはゼロになります。空の場所ではContentsが含まれない場合があります。読み取り専用の一覧取得ではファイルの上書きや削除は行われません。プロトコル、ロール、IP、有効時間帯、使用量による拒否に変わった場合、時刻や署名の症状は解消していますが、アクセス設定を別途修正する必要があります。キーの権限はロールを超えられません。署名の修正だけにプランのアップグレードは不要ですが、キー数と通常の許容量のルールは引き続き適用されます。

署名付きリンク、プロキシ、署名の不一致

URLの有効期限切れ。 URLを生成した信頼できるアプリケーションの署名元の時刻を修正した後、新しいURLの作成を依頼してください。X-Amz-Expiresの延長、X-Amz-Dateの書き換え、パラメーターの手動削除はしないでください。これらの値は署名に含まれます。署名付きURLは認証情報を含むリンクです。意図した受信者にのみ共有し、公開の診断情報には貼り付けないでください。再生成されるのは新しいURLであり、永続的な公開dosya共有リンクではありません。元の認証情報を無効化するとアクセスも失われます。

時計は正しいがSignatureDoesNotMatchが続く場合。 DOSYA…のIDが、そのキーに対して生成されたシークレットと一致するか確認してください。エンドポイントに/s3が含まれ、パス形式のアドレス指定が有効で、署名対象のメソッド、オブジェクトパス、エンコード済みクエリ、Hostヘッダー、ペイロードハッシュヘッダーが変更されずに届くことを確認してください。署名対象の要素を書き換えるプロキシは署名を無効にする場合があります。実際に失敗したジョブが選択するプロファイルを確認してください。--profileオプションを明示しないコマンドでは環境変数の認証情報が使われる場合があります。aws configure list --profile dosya-help-checkで意図した情報源を非公開で確認してください。

キャッシュまたは再送されたリクエスト。 ジョブが保存済みのAuthorizationヘッダーや署名付きURLを再利用しないようにし、送信時にSDKが各リクエストに署名するようにしてください。同じバイト列を再送するだけでは古い有効期限が残ります。プロキシを通さず直接アクセスしてテストする場合は、異なるホスト間で同じ署名を使い回さず、それぞれ新しい署名を使って動作を比較してください。

シークレットの紛失または漏えい。 S3の有効・表示ではシークレットを復元できません。漏えいの疑いがなくシークレットを紛失した場合は、代替の認証情報を作成し、対象の署名元を更新して代替情報を検証してから古いキーを無効化してください。漏えいが疑われる場合は、先に漏えいしたAPIキーを無効化し、一時的なクライアントの停止を受け入れてください。代替情報をテストする間、キーを有効なままにしないでください。無効化は元に戻せず、そのキーとペアを使用するすべてのクライアントに影響しますが、クラウド上のファイルは残ります。無効化時にキャッシュの無効化が始まりますが、他のアイソレートやエッジキャッシュには認可が一時的に残る場合があります。影響のない読み取り専用リクエストで古い認証情報が拒否されることを確認してください。1件のリクエストの形式が不正だったというだけで、他のクライアントのキーをローテーションしないでください。

期待される結果

新しく生成した読み取り専用リクエストが目的のdosyaバケットに対して成功するか、別途診断できる正確なアクセス拒否が返ります。署名の動作確認にデータの変更は不要です。次回の定期ジョブで同じ設定を使用できるよう、修正した署名元、エンドポイント、タイムスタンプを非公開で記録してください。

関連ガイド

• AWS CLIプロファイルと転送のテスト
• S3接続フィールドと権限の境界
• その他のS3アクセスエラーを解決する