署名付きURL・SAS漏えい時の初動対応｜S3・Azure・GCS確認チェックリスト

冒頭要約：完全なURLを秘密情報として扱う

S3のPresigned URL、Azure StorageのSAS、Google Cloud StorageのSigned URLが、公開リポジトリ、チャット、チケット、ログ、メールなどへ出た疑いがある場合、完全なURLをAPIキーやトークンと同じ秘密情報として扱います。

最初に、クラウドサービス、対象リソース、許可された操作、期限、署名元、露出した場所を記録します。不正利用や機密データの露出が続く場合は、記録・依存関係の棚卸しが終わるまで待たず、責任者とアクセス制限・緊急失効を判断します。 URLを別のチャットや外部URL検査サービスへ貼らず、アクセス証跡と業務影響の確認を並行します。

2026年10月25日にAWS・Microsoft・Google Cloudの公開資料を再確認した、情シス・開発者・クラウド管理者向けのガイドです。実環境の構成・失効結果や過去の取得有無を、このページだけで判定できるものではありません。

必要な確認へ進む：サービス別の失効単位／期限切れ後に残る処理／秘密値を含めない記録。報告は漏えい疑い初動テンプレートへ進めます。実際のURLはこのサイトへ入力しないでください。

• 認可を特定

  署名方式・対象・操作・期限を確認。URLの秘密値は共有しない。

• 今後の利用を制限

  露出元とクラウド側を並行して封じ込め、反映遅延や他URLへの影響を確認。

• 残件を引き継ぐ

  転送・アップロード・取得済みデータとログ不足を分けて記録する。

---

署名付きURL・SASとは

Signed URLは、リソース、許可操作、有効期限などを署名に含め、通常のログインを求めずに一時アクセスを許可するURLです。AWSではPresigned URL、Azure StorageではShared Access Signature（SAS）、Google Cloud StorageではSigned URLという名称が使われます。

利用者側からは「期限付きの共有リンク」に見えますが、セキュリティ上は、URLを持つこと自体がアクセス許可になります。転送されたURLを受け取った第三者も、有効期限内であれば、署名に許可された読み取り、アップロード、削除などを実行できる場合があります。

サービス	主な名称	署名・認可の基礎	失効判断で最初に見るもの
Amazon S3	Presigned URL	URLを生成したIAMユーザー、ロール、または一時認証情報の権限を使用する	署名元、認証情報の有効期間、URL期限、バケットポリシー
Azure Storage	User delegation SAS	Microsoft Entra資格情報から取得したUser delegation keyで署名する	User delegation key、発行主体のRBAC、SAS期限
Azure Storage	Service SAS / Account SAS	ストレージアカウントキーで署名する	保存済みアクセスポリシーの有無、使用したアカウントキー、依存システム
Google Cloud Storage	Signed URL	多くの場合、権限を持つサービスアカウントの署名を使用する	署名したアカウント・鍵、URL期限、対象オブジェクト、許可操作

同じ「期限付きURL」でも失効単位が異なります。1本だけ止められる場合もあれば、同じ鍵で作られた複数URLや業務アプリまで影響する場合があります。認証と認可の違いを踏まえ、URLの見た目ではなく、誰の権限で何を許可したかを確認します。

読者別の影響

読者	主な影響	最初に確認すること
個人・一般利用者	共有ファイルが転送され、期限内に第三者が閲覧できる	送信元、期限、対象ファイル、共有した相手、サービスの正式な失効手段
情報システム担当者	顧客情報、社内資料、バックアップの外部取得	データ所有者、データ分類、URLの配布先、ログ保持、報告要否
開発者・DevOps	ビルドログ、エラー監視、CI/CD、ソースコードへのURL混入	発行コード、署名元ロール、環境、ログ、キャッシュ、依存アプリ
クラウド管理者	鍵やロールを失効した際の広範な業務影響	署名方式、失効単位、関連URL、代替経路、監視、変更承認
SaaS管理者	チャット、チケット、メール、外部共有への二次拡散	投稿・添付・通知履歴、外部ゲスト、保持期間、削除・監査機能
CSIRT・法務	取得の有無、個人情報・契約上の報告判断	確認済み事実、未確認範囲、アクセス可能期間、対象データ、証跡

---

まず確認すること：最初の15分チェックリスト

「15分」は整理の目安で、連絡や封じ込めを待つ時間ではありません。確認が終わらない項目は、未確認の担当者と期限を置きます。

• AWS、Azure、Google Cloudのどのサービス・アカウント・プロジェクトか特定する。
• URLそのものを貼らず、バケット・コンテナ・オブジェクトの識別子を記録する。
• 発見時刻、発見場所、発見者、公開範囲、削除済みかを記録する。
• 許可操作が読み取りだけか、アップロード・上書き・削除も含むか確認する。
• 対象、開始時刻、期限、IPやヘッダー等の制約、署名元を確認する。
• 個人情報、顧客情報、認証情報、秘密鍵、バックアップを含むか確認する。
• 同じ発行処理・鍵の他URLと、失効で止まる業務・代替経路を確認する。
• 利用ログの事前有効化、対象範囲、保持期間と、CSIRT・法務・所有者への引き継ぎ条件を確認する。
• 完全なURLを別のチケット・チャット・外部スキャナーへ追加送信しない。

---

初動対応1：署名方式と失効単位を特定する

最初の判断は「URLを削除できるか」ではなく、何が署名し、どの単位なら無効化できるかです。

Amazon S3 Presigned URL

AWS公式資料では、Presigned URLは設定した期限、または生成に使った認証情報の期限・失効のうち、早い方で利用できなくなります。一時認証情報で作成したURLは、そのセッションが終了すると、URLにより長い期限が設定されていても失効します。

初動では、生成元がIAMユーザー、AssumeRole、インスタンスやコンテナのロール、その他の一時認証情報のどれかを確認します。認証情報の無効化は同じ主体を使う他の処理にも影響するため、依存関係を確認し、バケットポリシーや対象オブジェクトの一時隔離など、より限定的な封じ込めが使えるかを検討します。

Azure Storage SAS

AzureではSASの種類によって対応が異なります。

• User delegation SASは、User delegation keyの失効、または発行主体のRBAC・ACL変更で無効化できます。ただし、公式資料はキャッシュにより反映まで遅延する可能性を説明しています。
• 保存済みアクセスポリシーに紐づくService SASは、ポリシーの有効期限変更や削除で無効化できます。
• 保存済みアクセスポリシーを使わないアドホックService SASは、署名に使ったアカウントキーの再生成が即時失効手段になります。これは同じキーを使うアプリへ大きく影響します。
• Account SASもアカウントキーで署名されるため、キー変更前に利用箇所と切り替え手順を確認します。

保存済みアクセスポリシーを同じ名前で作り直さない点にも注意します。MicrosoftのService SAS資料では、期限がまだ残る旧SASは、削除したポリシーを同名で再作成すると再び有効になり得ると説明しています。漏えい対応の切り戻しで、旧URLのアクセス権を復活させないよう変更記録へ残してください。

Microsoftは、可能な場合はアカウントキーではなくMicrosoft Entra資格情報で署名するUser delegation SASを推奨しています。初動後は、SAS有効期間ポリシー、最小権限、短い期限、保存済みアクセスポリシーの利用可否を見直します。

Google Cloud Storage Signed URL

Google Cloud公式資料では、Signed URLを知る人は、有効期間中、指定された操作を実行できます。V4 Signed URLの最大有効期間は7日で、期限到達または署名に使った鍵のローテーションまで利用可能と説明されています。

まず、サービスアカウント、署名方式、ユーザー管理鍵かGoogle管理鍵か、対象オブジェクト、許可操作を確認します。鍵の無効化・交換は、同じサービスアカウントを使う他の署名やアプリへ影響する可能性があります。影響範囲を確認できないまま一括変更せず、対象リソースの一時隔離、配信停止、鍵の切り替えを変更管理の下で選びます。

期限が切れても、開始済み処理や取得済みコピーは別に残る

• S3のダウンロード：AWSの説明では、期限はHTTPリクエスト時に確認されます。期限直前に開始した転送は、その後に期限が過ぎても継続し得ます。「期限切れになったので進行中の転送も停止した」と記録しないでください。
• GCSの再開可能アップロード：Google Cloudの説明では、開始後はセッションURIが認証情報として働きます。元のSigned URLの期限だけでアップロード経路が止まったとは判断せず、セッションURIの露出、対象オブジェクトと開始済み処理を管理者へ確認します。
• 取得済みデータ：URLや資格情報を失効しても、相手が取得済みのコピーは回収されません。取得の有無・範囲が不明ならそのまま記録し、データ所有者・CSIRT・法務へ判断を引き継ぎます。

この節は防御上の残件を説明するものです。漏えいURLを使った転送の再現や、失効をすり抜ける試験は行いません。

初動対応2：これ以上の利用と二次拡散を止める

封じ込めは、URLが掲載された場所とクラウド側の両方で行います。

1. 公開リポジトリ、Webページ、チャット、チケット、メールなどの露出場所を記録する。
2. URLを削除または閲覧制限し、検索キャッシュや通知メールなどの二次配布先を確認する。
3. 対象データの重要度と許可操作を確認し、承認済み手順で今後のアクセスを止める。
4. 鍵・ロール・ポリシーを変える場合は、影響するURLと業務処理、安全な復旧条件を記録する。漏えいした認可を再有効化する切り戻しにしない。
5. 新しい共有手段を発行する場合は、対象、権限、期限、受取人を最小化する。
6. 旧URLが利用できなくなったことを、外部サービスへ送らず、管理された環境と公式ログで確認する。

対象オブジェクトの削除は、証拠と業務データを失う可能性があります。緊急性が高い場合でも、バージョニング、保持ポリシー、法的保全、バックアップ、参照元を確認し、隔離やアクセス拒否などの代替手段を優先します。

初動対応3：アクセス証跡と影響範囲を確認する

AWS

S3では、CloudTrailデータイベントまたはS3サーバーアクセスログを事前に有効化していれば、オブジェクト単位のリクエスト確認に使えます。CloudTrailは既定でS3データイベントを記録しないため、設定状況と対象バケットを確認します。

AWSのPresigned URL向け公式ガイダンスでは、ログ上の認証方式からPresigned URL利用を識別できると説明しています。アプリケーションログ、APM、プロキシ、チケットに完全なクエリ文字列を残さないよう、署名パラメーターを伏せる運用も確認します。

Azure

Azure Monitorへ診断ログを送信していれば、SASで認証されたストレージリクエストを確認できます。対象アカウント、サービス、操作、時刻、認証種別、応答、送信元を確認します。ただし、SASの種類をログだけで区別できない場合があるため、発行コード、保存済みアクセスポリシー、アカウントキー利用状況と突き合わせます。

Google Cloud

Cloud StorageのData Access監査ログは、事前に明示的な有効化が必要です。Signed URLはXML APIエンドポイントで使われるため、Cloud Audit Logs、Cloud Storage usage logs、CDN・アプリログの対象範囲を確認します。ログの種類、保存先、保持期間、配信遅延を記録し、記録されないアクセスがあり得ることを前提に判断します。

どのサービスでも、ログが見つからない場合は「利用されていない」ではなく、現時点で保持済みログからは確認できないと記録します。URLが置かれた場所の閲覧者、公開期間、対象データ、許可操作を合わせて影響を評価します。

---

やること・やらないこと・記録すること

やること

• URLを秘密情報として扱い、通常の連絡では署名値と完全なクエリを伏せる
• 署名元、対象、許可操作、期限、制約、公開場所を一つの記録へ集約する
• 同じ鍵、ロール、コードから発行された他のURLと利用システムを棚卸しする
• ログ、設定、発行コード、SaaS監査履歴を変更前に保全する
• 読み取りだけでなく、アップロード、上書き、削除が可能だったか確認する
• 失効後に代替URLや認証方式へ移行し、旧経路の利用を監視する

やらないこと

• 完全なURLをURLスキャナー、検索エンジン、AIサービス、個人端末へ貼り付けない
• URLを試す目的で対象ファイルをダウンロード、上書き、削除しない
• 依存アプリを確認せず、アカウントキーやサービスアカウント鍵を一括ローテーションしない
• チャット投稿を削除しただけで、URL自体も失効したと判断しない
• ログがないことを、アクセスがなかった証拠として扱わない
• 新しい署名付きURLを長期限・広い権限で再発行して暫定対応にしない

秘密値を含めない記録テンプレート

以下を承認された社内の記録へ転記します。署名値・完全なURL・セッションURIは通常のチケットやこのサイトへ記入しません。原本が必要な場合は、指定された証拠保管先への参照だけを記録します。

項目	記録内容
発見	日時、発見者、検知元、公開場所、管理用インシデントID
対象	クラウド、アカウント、リージョン、バケット・コンテナ、オブジェクト
URL条件	種類、開始時刻、期限、許可操作、IP・ヘッダー制約、署名元
データ	分類、件数、個人情報・顧客情報・認証情報、所有者
露出	公開期間、閲覧可能者、検索・通知・キャッシュ・外部ゲスト
封じ込め	実施時刻、方法、実施者、承認者、影響した業務・他URL
証跡	監査ログ、アクセスログ、発行ログ、設定、保存先、保持期限
判断	確認済み事実、未確認事項、アクセス可能性、報告要否
復旧	代替経路、新URLの期限・権限、鍵切り替え、監視、責任者

対応を閉じる前の確認

• 投稿削除とクラウド側の制限を別々に確認し、要求時刻・反映確認時刻・実施者を残す。
• 管理された環境での承認済み・非破壊の確認とログを根拠にし、失効要求だけで完了扱いにしない。
• 開始済み処理、取得済みコピー、他URL・業務への影響を残件として評価する。
• ログ不足、判定できない期間、報告判断の担当と期限を漏えい疑い初動テンプレートで引き継ぐ。

再確認の際はこの記事を「あとで読む」に保存し、保存・学習の続きから再開できます。作業記録そのものは社内へ保管してください。

---

危険度とエスカレーションの判断基準

優先度	判断条件	推奨する動き
緊急	個人情報・顧客情報・認証情報が対象で、URLが有効。書き込み・削除も可能、または利用痕跡がある	即時封じ込め、CSIRT招集、証拠保全、法務・経営を含む判断
高	機密データへの読み取りURLが公開され、公開期間・閲覧者・ログのいずれかが不明	URL失効を優先し、影響調査、データ所有者確認、報告要否を判断
中	公開用データだが、期限が長い、権限が広い、所有者や配布先が不明	期限・権限を縮小し、所有者、台帳、監視、再レビュー日を設定
低	公開目的、対象、受取人、短い期限、読み取り専用、ログが確認できる	記録を残し、標準発行手順と定期レビューへ反映

次のいずれかに該当する場合は、開発担当者やクラウド管理者だけで完結させません。

• 個人情報、顧客情報、契約、財務、人事、認証情報、秘密鍵が含まれる
• アップロード、上書き、削除、複数オブジェクトへのアクセスが許可されている
• URLが公開Web、公開リポジトリ、大人数のチャット、外部チケットへ掲載された
• 有効期限、署名元、公開期間、アクセス履歴のいずれかを確認できない
• 鍵のローテーションが複数サービス、顧客、バックアップ、配信へ影響する
• 顧客、委託先、保険、規制当局、契約上の通知判断が必要になる可能性がある

復旧と再発防止

• 署名付きURLの発行主体、用途、受取人、期限、許可操作を台帳化する。
• 読み取りとアップロードで発行経路・保存先・検証を分離する。
• URLをアプリログ、APM、分析、チャット、チケットへ記録しない設定を確認する。
• 短い有効期限と最小権限を既定値にする。
• AWSの署名経過時間制限、AzureのSAS有効期間ポリシーなどのガードレールを評価する。
• AzureではUser delegation SAS、Google Cloudではユーザー管理鍵を避ける署名方式を検討する。
• 発行イベントと利用イベントを追跡できる監査ログ・アクセスログを設計する。
• 緊急失効の影響範囲、代替経路、承認者、連絡先を手順化する。
• 公開用データと機密データを別の保存先・アカウントへ分離する。

有効期限は重要ですが、それだけでは十分ではありません。URLが不要になった時点で止められる設計、誰が発行したか追跡できる記録、広い鍵を使わない署名方式を組み合わせます。

---

よくある誤解

「URLなので、漏れてもパスワードほど深刻ではない」

署名付きURLは、保持者が追加認証なしで許可された操作を行えるため、期限付きのBearer資格情報として扱う必要があります。画面キャプチャ、ブラウザ履歴、アクセス解析、Referer、チケットへの混入も確認します。

「バケットを非公開に戻せば、署名付きURLも止まる」

署名付きURLは、匿名公開とは異なる認可経路です。バケットの公開設定を止めても、署名元の権限とURLが有効ならアクセスできる場合があります。

「期限が短いので、ログ確認は不要」

短時間でもデータを取得、アップロード、上書きできる可能性があります。データ分類、許可操作、公開場所、利用痕跡を確認し、期限切れだけで対応を終えません。

「すべての署名付きURLは1本ずつ取り消せる」

失効単位はサービスと署名方式で異なります。Azureの保存済みアクセスポリシーのように管理できる仕組みもあれば、アカウントキー変更など広い影響を伴う場合もあります。

「URLを削除したので、誰も使えない」

投稿やログから削除しても、通知メール、端末履歴、キャッシュ、コピー済みメッセージに残る可能性があります。クラウド側の失効と、二次拡散先の確認を分けて行います。

---

関連用語・関連ページ

次に確認すること	ページ
用語と権限範囲	Signed URL、Token Scope、最小権限
公開設定との違い	クラウドストレージ誤公開の初動対応、認証と認可の違い
データの重要度判断	Data Classification、データ分類の始め方
証拠保全と報告	漏えい疑い初動テンプレート、インシデント証拠保全の初動
共有経路の棚卸し	SaaS権限棚卸しチェックリスト、SaaS外部共有リンクの棚卸し
ログを読む演習	SaaS監査ログの異常を読み解く、クラウド監査ログ
学習と復習	インシデントレスポンス、セキュリティ用語クイズ

---

まとめ：URL削除ではなく認可の失効まで確認する

署名付きURLやSASの漏えい疑いでは、完全なURLを秘密情報として扱い、サービス、対象、許可操作、期限、署名元、公開場所を記録します。URLを第三者サービスへ貼って確認せず、公式ログと管理された環境で影響を調べます。

失効方法はサービス名だけでは決まりません。AWSでは署名元認証情報、AzureではUser delegation SAS、保存済みアクセスポリシー、アドホックSASの違い、Google Cloudでは署名したアカウントと鍵を確認します。広い鍵の変更は業務影響が大きいため、依存関係を把握し、最小の封じ込めから実施します。

最後に、データ分類、公開期間、閲覧可能者、許可操作、利用ログをもとにエスカレーションを判断します。ログが不足している場合はアクセスなしと断定せず、確認できない範囲を記録し、短い期限、最小権限、発行・利用ログ、緊急失効手順を再発防止へつなげます。

---

公式情報・参考情報

2026年10月25日の改訂では、下記のAWS・Microsoft・Google Cloudの公開資料で失効・期限・ログの条件を再確認しました。記録表と完了基準は編集部の整理で、実環境での失効試験や専門家の監修を意味しません。

• AWS: Download and upload objects with presigned URLs - S3 Presigned URLの有効期限、署名元認証情報との関係、ポリシーによる制限。
• AWS Prescriptive Guidance: Identifying presigned requests - S3サーバーアクセスログとCloudTrailデータイベントによる利用確認。
• Microsoft Learn: Create a user delegation SAS - User delegation SASの仕組み、失効方法、反映遅延の注意点。
• Microsoft Learn: Create a service SAS - Service SAS、保存済みアクセスポリシー、アドホックSASの失効条件。
• Microsoft Learn: Configure an expiration policy for SAS - SAS有効期間ポリシーとUser delegation SASの最大有効期間。
• Google Cloud: Signed URLs - Cloud Storage Signed URLの権限、期限、署名鍵との関係。
• Google Cloud: Cloud Audit Logs with Cloud Storage - Data Accessログの事前有効化と監査ログの制約。
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - 検知、対応、復旧をリスク管理へ接続するインシデント対応ガイド。