帳票の二つの共有経路

顧客向け帳票を置くオブジェクトストレージで、公開設定の変更と署名付きURLの大量発行が見つかった。保存時暗号化は有効だが、匿名利用者が帳票を取得できた疑いがある。暗号化、アクセス制御、共有URLは別の層であり、一つが有効でも他の誤設定は防げない。S3に似た架空サービスの設定・アクセス記録を使って判断する。

読む順序は、用語→実際の構成と処理→記録の照合→異常の成立条件→変更・復旧→短答演習です。以下の組織、アドレス、時刻、識別子、ログは教材用の架空例です。観測できた事実と、追加調査が必要な推論を分けて読みます。

1. 用語をこの事案の判断に結び付ける

用語	意味とこの事案での判断の限界
オブジェクトストレージ	キーで識別するオブジェクトをバケット等に保存する。ファイルシステムの階層に見える接頭辞と、アクセス制御のリソース境界は同じとは限らない。
公開設定	バケットやオブジェクトを匿名で読める設定。ポリシー、ACL、公開ブロック、CDNの経路を合わせて実効権限を判定する。
バケットポリシー / IAM	リソース側と主体側の許可・拒否条件。明示拒否や組織の制約、キー権限も関わる。画面に『private』とあるだけで全経路を断定しない。
署名付きURL	権限を持つ主体が、対象操作・オブジェクト・期限等を署名して一時的に共有するURL。URLを持つ人が使えるため、ログやメールへの漏えいに注意する。
保存時暗号化	保存先でデータを暗号化する措置。サービスが権限を持つ利用者へ復号して返すなら、匿名公開の誤設定による取得を自動的には防がない。
KMS鍵	鍵の利用を別権限で管理できる仕組み。ストレージのGet許可とKMSのDecrypt許可の双方が必要な構成もある。鍵の破棄・停止は正規復旧にも影響する。
アクセスログ / 管理ログ	GetObject等のデータ操作と、ポリシー変更等の管理操作を分けて収集する。収集設定が無効なら過去の取得を完全には追えない。
バージョニング / 変更不能	上書き・削除からの復旧を助ける。公開設定の事故や署名付きURLの漏えいそのものを防ぐものではない。

2. 構成と判断する位置

架空のA社はreports-prodバケットのreports/*に顧客別PDFをSSE-S3で保存し、業務アプリAPP-1が24時間の署名付きURLを発行する。private/*の社内資料は別途KMS鍵K-1で暗号化する。通常は匿名公開をブロックする。09:00に運用IDが公開ブロックを無効化し、09:03にreports/*の匿名読取を許可した。09:10に匿名GETが記録され、09:15にAPP-1が同じPDFの署名付きURLを発行した。どの経路で取得されたかを分ける。

帳票の二つの共有経路

1. 匿名GET
2. URL要求
3. 公開許可
4. 署名付きURL

匿名公開と署名付きURLの権限を別に確認する。

匿名GETと署名付きURLは異なるアクセス経路。reports/*のSSE-S3は保存時の保護であり、S3が匿名GETを許可して復号して返せば公開事故は成立する。一方、AWS S3のSSE-KMSオブジェクトは匿名公開できない。CDNを挟む場合はキャッシュとオリジン権限も加えて調べる。

3. 正常時の処理と管理

帳票の分類と顧客別の読取範囲を決め、匿名公開を禁止し、APP-1の発行権限を対象接頭辞と必要操作に絞る。
公開ブロック、バケットポリシー、ACL、IAM、KMS鍵ポリシー、CDNを合わせた実効権限を検証する。
署名付きURLは対象オブジェクト、GET/PUT等の操作、期限、発行主体、必要ならネットワーク条件を絞り、ログにURL全体を残さない。
データ操作と設定変更の監査を有効にし、発行記録、取得記録、請求先や顧客IDを関連付ける。
公開設定・鍵・署名主体の変更時には匿名GET試験、正規顧客の取得試験、失効手順と復旧手順を確認する。

署名付きURLはバケットを公開せず一時共有できるが、URLが漏れれば期限内に第三者が使える。URL発行の権限は発行元資格の権限を超えない。期限はURLに書いた時刻と、発行元の一時資格自体の期限の短い方で失効する場合がある。

4. 設定・記録のフィールドを読む

項目	読み方と注意点
bucket / object key	対象バケットと完全なキー。接頭辞reports/*がどこまで含むか、テストデータや他顧客データも調べる。
principal / auth type	匿名、IAM、署名付きURL、CDNサービスIDを区別。User-AgentやIPだけで認証方式を推定しない。
policy / ACL / block	許可・拒否、公開ブロックの実効状態と変更時刻。アカウントとバケットの双方の制約を確認する。
operation / result	GetObject、PutObject、ListBucket、DeleteObject等を分け、成功したデータ取得の証拠を確認する。
URL expiry / signer	発行時刻、期限、操作、対象、発行元資格の状態。既に配布したURLの失効手段を確認する。
encryption / key	SSE-S3、SSE-KMS等と鍵ID。保存時暗号化がアクセス制御の誤設定を補うと考えない。
download bytes / CDN	実際に転送したバイト数とキャッシュ経由の取得。オリジンログだけではCDNからの配布を見落とす。

以下は架空のS3風の監査記録。実際のクラウド製品によってイベント名とログ取得設定は異なる。

text

09:00 actor=ops-1 action=BlockPublicAccess disable result=ok
09:03 actor=ops-1 action=PutBucketPolicy
  resource=reports-prod/reports/* principal=* read=true
09:10 actor=anonymous action=GetObject
  key=reports/customer-41.pdf bytes=82000 result=200
09:15 actor=APP-1 action=PresignGetObject
  key=reports/customer-41.pdf expiry=24h
09:20 actor=ops-2 action=BlockPublicAccess enable result=ok

09:10の匿名GetObject成功は署名付きURL発行より前であり、09:03の公開ポリシーが実効だったと考える根拠がある。09:15の発行は別経路で、URLを誰が利用したかは発行記録だけでは分からない。09:20に公開ブロックを戻しても、配布済みURLやCDNキャッシュの影響を別に確認する。

5. 異常が成立する条件と証拠

状態・攻撃	成立条件、証拠、対策の位置
匿名公開	公開ブロック解除と匿名読取ポリシーが有効なら、保存時暗号化済みでもサービスが復号して返す場合がある。実GETで確かめる。
過大な接頭辞	reports/*に全顧客のPDFを置けば一つの許可で広範囲公開。キー設計と権限境界を見直す。
署名付きURL漏えい	URLをログ・チャット・Refererに残すと期限内に使われ得る。短い期限と限定操作、発行・利用監査を行う。
長い発行元資格	URL期限だけ短くしても発行主体が過大権限なら大量URLを発行できる。APP-1のIAMとKMS権限を絞る。
KMS誤設定	Get権限があってもDecrypt不可なら正規利用者も取得不能。事故対応で鍵を急停止すると業務復旧へ影響する。
ログ欠落	データ操作ログが無効なら取得の全容が分からない。CDN・アプリ・ネットワーク側の証拠と不確実性を残す。

保存時暗号化、転送時TLS、認可は目的が違う。暗号化を有効にしているという事実は、匿名GetObjectを許す設定の安全性を証明しない。逆に公開ブロックを入れただけで、既に取得されたデータやURLの配布は取り消せない。

6. 調査で結論を強くする順序

判定段階	必要な証拠と結論の上限
誰が変えたか	管理操作ログの主体、MFA、端末、作業票、変更前後のポリシーを確認。正規IDでも乗っ取りを調べる。
何が公開されたか	ポリシーの範囲、バケット・オブジェクトACL、公開ブロック、CDNを評価。
取得されたか	匿名・署名付き・IAMを区別したデータ操作ログ、転送バイト数、CDNログを確認。
止められたか	公開設定、発行元資格、既存URL、キャッシュの失効・影響を確認。
業務が戻ったか	顧客別取得、暗号鍵、アクセス拒否、監査、再公開防止の試験を行う。

オブジェクトストレージでは、アカウントの公開ブロック、バケットの公開ブロック、バケットポリシー、ACL、IAM、組織制約が重なる。画面の一つの項目が『private』でも、CDNの公開キャッシュや別バケット複製があり得る。実効権限を匿名リクエストと正規主体の両方で試す。

署名付きURLは発行者の権限に基づいて対象操作を一時的に委任する。URLを持つ人は追加ログインなしで利用できる構成が多いため、URL自体を秘密として扱う。ログにはクエリ文字列全体を保存せず、監査用IDと発行者・対象・期限を記録する。

期限を過ぎると新しいリクエストは拒否されるが、大きなダウンロードが期限前に開始され継続する場合がある。期限前に発行者の一時資格が失効すれば、URLも早く使えなくなる場合がある。事故時には発行方式と実際の資格を確認して失効手段を選ぶ。

保存時暗号化は媒体上のデータを保護する。SSE-S3のreports/*では、S3が許可された匿名Get要求へ復号して返すため、公開誤設定による取得を暗号化だけで止められない。対してAWS S3のSSE-KMSオブジェクトを匿名公開することはできず、ストレージ権限とKMSの鍵利用権限が必要である。private/*の復旧試験ではその両方を確認する。

公開事故の範囲は『バケットに保存した全ファイル』とは限らない。ポリシーがreports/*だけか、ListBucketが許可されたか、オブジェクト名を推測できたか、CDNが以前にキャッシュしたかを分ける。実際に取得された量はデータ操作ログが有効だった期間と保持範囲に制限される。

署名付きURLを止めるために発行元資格を無効化すると、APP-1の正規配布や他のAPIも停止し得る。対象URLの発行方式、資格の寿命、ネットワーク条件、鍵更新、オブジェクト名変更を比較し、業務影響を示して選ぶ。URLの削除はできないため、認可条件を変える必要がある。

事故後は公開設定の差分をIaCや構成履歴で追い、ポリシー変更に承認と自動検査を入れる。匿名GET試験だけでなく、顧客AのURLで顧客Bのオブジェクトを読めないこと、発行権限が最小範囲であること、監査ログが残ることを確認する。

オブジェクトのバージョニングを有効にしていても、古い版が同じ公開ポリシーの下で取得できる場合がある。事故時は現行版だけでなく過去版と複製先の権限を確認する。削除マーカーで一覧から見えないことと、読取不能であることも分けて試験する。

7. 変更・障害・例外運用

運用場面	崩れやすい条件と確認
CDN併用	オリジンを非公開にしてもCDNキャッシュに残る場合がある。署名・無効化・ログをCDN側でも確認する。
鍵更新	新旧鍵の利用権限と既存オブジェクトの暗号化方式を確認。デフォルト変更だけで既存物が再暗号化されるとは限らない。
URL再発行	短い期限にした後も旧URLの有効性を確認。発行元の一時資格の失効時刻に依存する。
監査コスト	データ操作ログは量が多い。重要バケットの対象、保持、改ざん耐性を決め、事故時に空白を作らない。
誤った全拒否	公開を閉じた結果APP-1や顧客も取得できなくなる。匿名拒否と正規許可を両方試験する。

顧客PDFを既に第三者が取得した可能性があれば、公開設定の修正後も対象顧客・期間・ファイルと実際のダウンロードを調べる。監査ログが欠ける場合は確定範囲と推定範囲を分けて報告する。

8. 封じ込めと復旧条件

ストレージ公開事故の対応

1. 記録保全：対応設定と取得を保存／確認する証跡管理・データログ
2. 公開停止：対応匿名許可を閉じる／確認する証跡匿名GET拒否
3. URL対処：対応発行資格を評価／確認する証跡期限と利用記録
4. 再開：対応顧客取得を試す／確認する証跡 IAM・KMS・監視

公開、URL、鍵、監査を別に扱う。

匿名公開を閉じてもURLは独立に残り得る。K-1を停止するとprivate/*の正規利用者もアクセスできなくなる。鍵の対象を確認せずに事故対応として一律停止しない。

公開ブロック、バケットポリシー、ACL、IAM、鍵、CDN設定の変更前後を保全する。
匿名読取を止め、外部からの匿名GETが拒否されることを確認する。
発行済みURLと発行者資格の範囲・期限・利用履歴を調べ、必要な失効・再発行を行う。
データ操作ログとCDNログで取得されたキー・時刻・量を整理し、ログ空白を明示する。
正規顧客だけが自分のPDFを取得でき、private/*はKMS鍵を持つ正規主体だけが取得でき、監査も動くことを試験して再開する。

保存時暗号化の有効性を確認しても、匿名Get成功の事実は消えない。漏えいした可能性がある帳票の特定と対外連絡の判断は、技術的な公開停止と並行して進める。

9. 科目B（午後）の解答手順

『公開設定』『署名付きURL』『暗号化』『IAM/KMS』を別の列にして実効許可を判断する。データ操作ログの200は実際の取得を示すが、発行記録だけは利用を示さない。変更・取得・失効の時刻を順に答える。

匿名公開と署名付きURLを混同しない。
保存時暗号化をアクセス制御の代替にしない。
発行者資格・期限・対象操作を確認する。
管理ログとデータ操作ログ、CDNログを分ける。

10. 短答演習

演習1：SSE-S3

条件：reports/*のSSE-S3暗号化PDFに匿名GET 200。

質問：漏えい可能か。

解答：可能。S3は許可された匿名要求へ復号して返す。

誤答の理由：保存時暗号化を匿名公開防止と誤解している。

演習2：発行前

条件：09:10匿名GET、09:15署名付きURL発行。

質問：URL経由の取得か。

解答：この発行URLによる取得ではない。公開ポリシーを確認する。

誤答の理由：時系列を無視している。

演習3：期限

条件：URL期限24時間、発行元一時資格は2時間。

質問：必ず24時間使えるか。

解答：いいえ。発行元資格の失効で早く使えなくなる。

誤答の理由：URL記載の期限だけを見ている。

演習4：発行記録

条件：APP-1がURLを作成。

質問：第三者取得は確定か。

解答：確定しない。GetObjectとCDNの利用ログを調べる。

誤答の理由：発行と利用を混同している。

演習5：公開ブロック復旧

条件：09:20に公開ブロックを再有効化。

質問：事故は完了か。

解答：既存URL、CDNキャッシュ、取得済みデータ、再公開経路を調べる。

誤答の理由：一つの設定変更で全経路が閉じると考えている。

演習6：KMS鍵停止

条件：漏えい対策でprivate/*用K-1を即停止。

質問：どんな影響か。

解答：社内資料の正規利用者も復号・取得不能になり得る。鍵の利用先を評価する。

誤答の理由：鍵の対象を確認していない。

11. 一次資料

Microsoft：Azure Blobの匿名・SASアクセス

オブジェクトストレージの公開設定・署名付きURL・暗号化