S3のPresigned URL、Azure StorageのSAS、Google Cloud StorageのSigned URLが漏えいした疑いがあるときの初動対応を解説。情シス・開発者・クラウド管理者向けに、期限、許可操作、発行元、アクセスログ、失効方法、影響範囲を確認する実務チェックリストです。
この記事の目次 14項目から選ぶ
冒頭要約：完全なURLを秘密情報として扱う
S3のPresigned URL、Azure StorageのSAS、Google Cloud StorageのSigned URLが、公開リポジトリ、チャット、チケット、ログ、メールなどへ出た疑いがある場合、完全なURLをAPIキーやトークンと同じ秘密情報として扱います。
最初に、クラウドサービス、対象リソース、許可された操作、期限、署名元、露出した場所を記録します。そのうえで、URLを別のチャットや外部URL検査サービスへ貼らず、サービスの仕組みに合った方法で今後の利用を止め、アクセス証跡と業務影響を確認します。
この記事は、2026年7月22日時点で確認したAWS、Microsoft、Google Cloud、NISTの公式情報をもとに、情シス、開発者、クラウド管理者、SaaS管理者、CSIRTが使える初動対応と判断基準を整理した実務ガイドです。
漏えいした可能性がある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分チェックリスト
URLを実際に利用できるか試す前に、露出範囲と封じ込め方法を確定します。
- AWS、Azure、Google Cloudのどのサービス・アカウント・プロジェクトか特定した
- URLそのものを貼らず、バケット・コンテナ・オブジェクトの識別子を記録した
- 発見時刻、発見場所、発見者、公開範囲、削除済みかを記録した
- GET、PUT、POST、DELETEなど、許可された操作を確認した
- 対象リソース、開始時刻、有効期限、IPやヘッダーなどの制約を確認した
- URLを生成したユーザー、ロール、サービスアカウント、鍵を特定した
- 個人情報、顧客情報、認証情報、秘密鍵、バックアップを含むか確認した
- 同じ発行処理・鍵から作られた他のURLがないか棚卸しした
- CloudTrail、Azure Monitor、Cloud Audit Logs、ストレージアクセスログの有効化状況と保持期間を確認した
- 失効により停止するアプリ、CDN、バッチ、顧客ダウンロードを確認した
- URLをチケット、チャット、メール、ブラウザ履歴、外部スキャナーへ追加送信していない
- CSIRT、法務、データ所有者へ引き継ぐ条件を確認した
通常の連絡では署名値と完全なクエリ文字列を伏せます。一方、調査原本が必要な場合は、承認された証拠保管先へアクセス制限付きで保存し、取得者、保管時刻、ハッシュ、保持期限を記録します。
初動対応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は、可能な場合はアカウントキーではなくMicrosoft Entra資格情報で署名するUser delegation SASを推奨しています。初動後は、SAS有効期間ポリシー、最小権限、短い期限、保存済みアクセスポリシーの利用可否を見直します。
Google Cloud Storage Signed URL
Google Cloud公式資料では、Signed URLを知る人は、有効期間中、指定された操作を実行できます。V4 Signed URLの最大有効期間は7日で、期限到達または署名に使った鍵のローテーションまで利用可能と説明されています。
まず、サービスアカウント、署名方式、ユーザー管理鍵かGoogle管理鍵か、対象オブジェクト、許可操作を確認します。鍵の無効化・交換は、同じサービスアカウントを使う他の署名やアプリへ影響する可能性があります。影響範囲を確認できないまま一括変更せず、対象リソースの一時隔離、配信停止、鍵の切り替えを変更管理の下で選びます。
初動対応2：これ以上の利用と二次拡散を止める
封じ込めは、URLが掲載された場所とクラウド側の両方で行います。
- 公開リポジトリ、Webページ、チャット、チケット、メールなどの露出場所を記録する。
- URLを削除または閲覧制限し、検索キャッシュや通知メールなどの二次配布先を確認する。
- 対象データの重要度と許可操作を確認し、承認済み手順で今後のアクセスを止める。
- 鍵・ロール・ポリシーを変える場合は、影響するURLと業務処理、切り戻し条件を記録する。
- 新しい共有手段を発行する場合は、対象、権限、期限、受取人を最小化する。
- 旧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を長期限・広い権限で再発行して暫定対応にしない
記録テンプレート
| 項目 | 記録内容 |
|---|---|
| 発見 | 日時、発見者、検知元、公開場所、管理用インシデントID |
| 対象 | クラウド、アカウント、リージョン、バケット・コンテナ、オブジェクト |
| URL条件 | 種類、開始時刻、期限、許可操作、IP・ヘッダー制約、署名元 |
| データ | 分類、件数、個人情報・顧客情報・認証情報、所有者 |
| 露出 | 公開期間、閲覧可能者、検索・通知・キャッシュ・外部ゲスト |
| 封じ込め | 実施時刻、方法、実施者、承認者、影響した業務・他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では署名したアカウントと鍵を確認します。広い鍵の変更は業務影響が大きいため、依存関係を把握し、最小の封じ込めから実施します。
最後に、データ分類、公開期間、閲覧可能者、許可操作、利用ログをもとにエスカレーションを判断します。ログが不足している場合はアクセスなしと断定せず、確認できない範囲を記録し、短い期限、最小権限、発行・利用ログ、緊急失効手順を再発防止へつなげます。
公式情報・参考情報
- 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 - 検知、対応、復旧をリスク管理へ接続するインシデント対応ガイド。
