公開ストレージの情報漏えいとは？S3・Blob・GCSの公開設定ミスと共有リンク事故を防ぐ方法

公開ストレージの情報漏えいとは何か

「公開バケット」だけが事故ではない

公開ストレージ事故は、一般には「public bucket」の問題として語られます。たしかに、その理解は半分正しいです。Amazon S3 の Block Public Access↗、Google Cloud Storage の public access prevention↗、Azure Blob Storage の 匿名アクセス 制御↗は、いずれも「誤って public にしない」ための仕組みとして用意されています。つまり、ベンダー側も公開設定ミスを重大な事故パターンとして扱っているわけです。

ただし、企業の現場で起きる事故はそれだけではありません。実際には、匿名アクセスが有効で Authorization なしで読める、「allUsers」や public policy が残っていて外部公開される、共有URL が長寿命のまま共有される、SAS が過剰権限のまま残る、静的公開用 bucket に内部向け data が混在する、といった複数のパターンが混ざります。問題の本質は、ストレージが public か private かの二択ではなく、どの方式で外部アクセスが成立しているかを組織が説明できるかです。

「匿名アクセス / 共有URL / 署名付きURL / SAS」の違いを先に整理する

ここは曖昧にすると事故原因の整理を間違えやすいので、先に切り分けます。匿名アクセスは、認証なしで誰でも読める状態です。Azure Blob では storage account 側で匿名アクセスを許可し、そのうえで container 側でも明示的に公開設定を入れたときに anonymous read が成立します。GCS では「allUsers」や「allAuthenticatedUsers」の IAM policy や ACL が public を作り、S3 では bucket policy、ACL、access point policy などが public access を成立させます。

一方でpre署名付きURL、署名付きURL、SASは public 公開ではありません。認証情報や鍵を持つ側が、期間と権限を限定した URL を発行し、その URL を知っている相手にアクセスを委任する仕組みです。ここが重要です。「public ではない」からといって安全とは限りません。URL 自体が一時的な秘密だからです。URL が GitHub、チャット、チケット、ログ、Wiki に残った時点で、結果的には情報漏えいと同じ窓口になります。

なぜ公開ストレージ事故は企業で起きやすいのか

バックアップ、export、静的配布、委託先連携で例外 bucket が増える

企業で オブジェクトストレージ が危険になりやすい理由は、使い方の幅が広すぎるからです。ストレージは本番アプリの本体というより、画像や動画の静的配布、ログやレポートの export、バックアップ やアーカイブ、分析用データの受け渡し、委託先への一時共有など、周辺業務の置き場として増えがちです。しかも多くは「短期間だけ」「一部担当だけ」「特定相手だけ」で始まりやすく、半年後には管理責任者が分からない、共有 URL の TTL が異常に長い、静的公開のつもりで作った bucket に別用途 data が混ざる、といった状態になりやすくなります。

特に公開ストレージは、社内から見るとクラウドの裏側に見えても、外からは普通の HTTP endpoint や CDN origin として見えることがあります。つまり内部では「ただの storage 設定」でも、攻撃者から見れば外部公開資産の一部です。この意味では、未管理の外部公開資産リスクやアタックサーフェスと同じ外部観点の論点に入ります。

「secure by default」でも古い運用と例外が残りやすい

最近のクラウドは secure by default の方向へかなり寄っています。AWS は新しい bucket で Block Public Access を強く推奨し、GCS も public access prevention を organization 単位で強制できます。Azure も匿名アクセスは既定で無効です。ここだけ見ると「今はもう誤公開しにくいのでは」と思えます。

ですが事故は依然として起きます。理由は単純で、事故は新しい defaultではなく、既存 workload と例外運用に宿るからです。静的配布が必要な bucket、委託先連携の一時 URL、過去の export container、管理責任者不明の archive storage は、技術的には正当な例外でも、台帳と見直しに戻さなければ事故窓口になります。secure by default は出発点であって、例外管理を代わりにやってくれるわけではありません。

S3・GCS・Azure Blob で危険な状態をどう見分けるか

AWS は「Block Public Access」と「Access Analyzer for S3」を基準に見る

AWS で最初に見るべき基準は、Block Public Access↗が account / bucket / organization のどこまで効いているかです。S3 は bucket policy、ACL、access point policy など複数の経路で public access が成立しうるため、一箇所だけ見て安心、が通用しません。公式 docs でも、4 つの設定を account と bucket に対して有効化することが強く推奨されています。

加えて実務上かなり有効なのが、IAM Access Analyzer for S3↗です。これは bucket が public か、他アカウントから見えるかを Region 横断で一覧化できる仕組みで、S3 console から global summary を見られます。ポイントは、見つかった public bucket をどう扱うかまで運用が用意されていることです。意図した例外は archive して残し、意図しないものは 是正対応 に戻す。この整理ができるかどうかが大きい差になります。

GCS は「public access prevention」と「allUsers」を基準に見る

GCS では、public access prevention↗が最も分かりやすい基準です。これを enforce すると、「allUsers」や「allAuthenticatedUsers」を使った public access が上書きで無効になります。しかも project、folder、organization で強制できるため、個別 bucket の事情に引きずられにくい設計です。

一方で GCS docs が丁寧なのは、有効化する前に public resources を台帳しろと明示している点です。さらに読者が見落としやすいのが、public access prevention は署名付きURLs↗には効かない、という点です。つまり「public を禁止したから共有 URL のリスクも消えた」と誤解すると、実際の事故を取り逃します。

Azure Blob は「AllowBlobPublicAccess」と「SAS」を分けて見る

Azure Blob で混乱しやすいのは、匿名アクセスが二段階で成立することです。まず storage account 側で匿名アクセスを許可するかを決め、次に container 側の access level 設定があります。Microsoft Learn↗でも、この 2 つを分けて説明しています。つまり account 側で匿名アクセスを拒否すれば、container 側で public 設定が残っていても anonymous read は成立しません。

さらに Azure は、SAS overview↗で 匿名アクセス と SAS を別問題として整理しています。匿名アクセスを切っても、SAS による委任は別に残ります。ここでも、public 公開禁止と共有URL 管理は分けて見る必要があります。

共有リンク・pre署名付きURL・署名付きURL・SAS をどう扱うべきか

「public」ではなくても URL を持つ人は使える

AWS の pre署名付きURL、GCS の 署名付きURL、Azure の SAS は、いずれも「bucket policy を変えずに、限定的な URL を発行して委任する」仕組みです。公式 docs は共通して、期限付きと権限制限を強調しています。つまり本来は、public 公開より安全な共有方式です。

ただし、ここには運用上の落とし穴があります。URL を知っている人は、その有効期限内でアクセスできるという点です。AWS も、pre署名付きURL は生成した IAM principal の権限を使ってアクセスを成立させると説明しています。GCS も、署名付きURL を持つ人は有効期限か 鍵の更新 まで使えると明記しています。Azure も、SAS は URI に token を付けて委任する仕組みで、token 自体を secret として扱うべきだと読み取れます。つまり 共有URL はpublic ではないが、secret と同じ水準で扱うべき URLです。

長寿命 token と tracking 不足が事故を広げる

ここが public bucket 問題よりさらに難しいところです。public bucket なら analyzer や policy で比較的見つけやすいですが、共有URL は個別発行されるため、棚卸しが難しくなります。Azure の公式 docs はこの点をかなり率直に書いており、SAS は生成数を Storage 側が追跡しないと説明しています。つまり、どれだけ発行されたかを後から API 一覧で取り出すことはできません。

AWS と GCS も本質は同じです。長寿命 pre署名付きURL や 署名付きURL は、たとえ公開バケットではなくても、URL を知っている第三者が有効期間中アクセスできるという意味で、事故窓口を長く残します。期限を短くし、再発行を前提にし、配布先と用途を台帳化しなければ、あとから追えません。

TTL、最小権限、鍵の更新、例外台帳が必要

共有URL 系の再発防止は、技術設定と運用の両方が必要です。技術側では、TTL を短くする、読み取り専用や単一 object など最小権限にする、account key より user delegation や service account ベースを優先する、鍵の更新 や revoke の手順を先に決める、といった条件が基本になります。運用側では、どの業務で 共有URL を使うのか、誰が発行できるのか、最大 TTL は何か、どのログを見るのか、例外用途はどこへ記録するのかを先に固定する必要があります。

最初に監査すべきポイント

組織 / account / project で公開禁止ガードを先に確認する

公開ストレージの監査を始めると、つい bucket 一覧から見たくなります。しかし順番としては逆です。最初に見るべきなのは上位ガードです。AWS なら account / organization / bucket の Block Public Access、GCP なら organization / project / bucket の public access prevention、Azure なら storage account の 匿名アクセス 制御です。ここが弱いと、下位リソースをいくら監査しても次々に再発します。

analyzer、資産台帳、policy で公開例外を洗い出す

次に必要なのが、現実に何が 公開 / 共有 なのかの台帳です。AWS なら Access Analyzer for S3、GCP なら bucket policy と Cloud Asset Inventory、Azure なら Policy や Resource Graph で匿名アクセス許可の状態を監査するのが出発点になります。重要なのは、手作業で 1 bucket ずつ見るのではなく、例外の一覧を先に出すことです。

ここで分類したいのは、明確に意図した 公開 / 共有、意図はあるが管理責任者と期限が曖昧、そもそも意図が説明できない、の 3 つです。一番危険なのは最後ですが、実務で数が多いのは「なんとなく必要そう」で残っている例外です。ここを台帳に戻すだけでも、事故リスクはかなり下がります。

高リスク data と管理責任者不明 bucket から優先する

全部を同時に直そうとすると止まります。優先順位はdata sensitivityと管理責任者 clarityで切るのが実務的です。顧客データ、レポート、export、バックアップ、内部文書、source archive、認証情報や設定ファイルを含みうる storage、管理責任者不明の bucket / container / shared link は優先度を高く置くべきです。逆に、静的配布の公開 assets だけが入っていて管理責任者と例外理由が明確なものは、直ちに危険とは限りません。

再発防止の運用フロー

公開ストレージ事故の再発は、設定変更の瞬間より例外が通常運用に埋もれた瞬間に起こります。以下の 90 日プランは、S3 / GCS / Azure の公式コントロールを前提にしつつ、例外 bucket と 共有URL の運用を現実的に減らすための最小構成です。

0-30日で 公開 / 共有 の実態を可視化する

最初の 30 日では、完全修正より台帳を優先します。AWS は Access Analyzer、GCP は Cloud Asset Inventory と IAM、Azure は Policy / Resource Graph を使って、public / anonymous / shared の候補を洗い出します。ここで大事なのは bucket の数を数えることではなく、例外がどれだけあるかを知ることです。

31-60日で例外 bucket と共有方式を減らす

次の 30 日では、例外の整理に入ります。public bucket や匿名 container を減らし、静的配布が必要なものは専用 bucket や専用 account へ隔離し、SAS や 署名付きURL の TTL と権限を縮めます。ここでは「全部 private にする」より、公開が必要な例外を狭くする方が現実的です。

61-90日で見直し、policy、期限切れ 監視を定着させる

最後の 30 日では、例外を個人判断にしない仕組みへ落とします。monthly見直し、policy audit、期限切れ 監視、例外台帳、鍵の更新 手順、log 確認先を決めます。公開ストレージ事故の再発は「一時共有」のまま close 条件がなく残ることが多いため、見直し頻度 を持つことが本体です。

企業で失敗しやすい典型パターン

「静的公開が必要な bucket」に内部 data を混在させる

public 配布が必要な用途は実際にあります。問題は、その例外 bucket に別の internal data が混ざり始めることです。最初は画像配布専用でも、あとから export や検証ファイルを置き始めると、一気に危険度が上がります。公開用途は専用に分けるが基本です。

SAS や 署名付きURL を secret として扱わない

共有URL は public 公開ではないので、つい軽く扱われます。しかし Azure の公式 docs が書いているとおり、SAS は発行数の追跡ができません。つまり漏れたときの把握が難しい。AWS と GCS も本質的には同じで、URL を持つ相手がアクセスできる以上、secret と同じ扱いが必要です。

「共有は一時的」のつもりで例外を放置する

一時共有ほど長く残ります。緊急共有、委託先納品、分析チーム向け配布、障害対応時の一時公開は、その場では合理的でも close 条件がなければ常設化します。例外は「一時」と言うだけでは閉じません。期限、管理責任者、再確認日まで必要です。

公開ストレージ露出の初動整理なら ASM診断 PRO

公開ストレージ事故の対策そのものは、クラウドネイティブな access control や policy が主役です。AWS の Block Public Access、GCP の public access prevention、Azure の 匿名アクセス 制御や SAS 運用を、ASM診断 PRO が直接置き換えるわけではありません。ここは切り分けるべきです。

そのうえで、企業で事故が止まりにくい理由は、クラウド設定と外から見える公開導線が別々に管理されるからです。静的サイト、配布 URL、カスタムドメイン、関連サブドメイン、委託先向け公開面がどこから見えているのかを外部観点で整理しないと、policy だけ整えても現場は動きません。ASM診断 PRO は、この外から見える公開導線の 現状確認を始める入口として相性があります。

特に、storage bucket にカスタムドメインや公開導線がぶら下がるケース、bucket 自体は private でも関連する配布導線が多数あるケース、管理責任者が曖昧な公開面が増えているケースでは、まず外部観点で公開面の棚卸しをする意味があります。「どのクラウド設定が危ないか」は cloud-native controls や CSPM の役割ですが、「どの外部導線を誰が持つか」は別の運用問題です。

まずは無料診断で、今見えている公開面と related asset を把握してください。そこから「どの bucket / container / 共有方式が例外になっているか」を台帳へ戻す方が、公開ストレージ事故の再発防止は前に進みます。全体像はアタックサーフェスとはと未管理資産リスクともつながります。

よくある質問（FAQ）

「Block Public Access」や「public access prevention」を有効にすれば十分ですか

十分ではありません。非常に重要な基盤ですが、pre署名付きURL、署名付きURL、SAS のような共有方式は別に残ります。また、例外 bucket や静的配布の用途がある場合は、「なぜ例外なのか」を見直しへ戻さないと再発します。

pre署名付きURL や 署名付きURL は公開設定と同じですか

違います。public 公開ではありませんが、URL を知っている相手には有効期限までアクセスを委任します。つまり公開設定ミスではなく、共有 secret の運用問題として扱うべきです。

Azure の SAS は何が難しいのですか

SAS は細かく制御できて便利ですが、Azure Storage 側で発行数を追跡しません。さらに account key ベースの SAS は強く、長寿命や過剰権限だと事故時の把握が難しくなります。Microsoft は可能なら user delegation SAS を推奨しています。

静的サイト配信に公開 bucket を使うのは危険ですか

危険というより例外として強く管理すべきです。公開が必要な用途自体はありますが、内部向け data を混在させないこと、管理責任者を明確にすること、例外台帳と見直しを持つことが前提です。

まず bucket の中身を見る前に何を整理すべきですか

まず、どの account / project / storage account が public を許す設計かを確認し、そのあとどの bucket / container が例外かを一覧化するのが先です。中身の機密度確認はその次です。上位 guardrail が弱いと、見つけてもすぐ再発します。

まとめ

公開ストレージの情報漏えいは、「public bucket を切れば終わり」の問題ではありません。匿名アクセス、共有URL、署名付きURL、SAS、静的公開用の例外、管理責任者不明の storage が重なって起きます。だからこそ、public を禁止する設定と例外共有を統制する運用を分けて管理する必要があります。

今日から着手するなら、まずaccount / project / storage account の公開禁止ガードを確認する、公開 / 共有 の例外一覧を出す、期限付き共有 URL を secret と同じ水準で扱うの 3 つです。この 3 つができるだけで、公開ストレージ事故は「クラウドの設定問題」から「組織で管理できる運用問題」へ変わります。