目次
スポンサーリンク
公開サイトと非公開ファイルでは目的が異なる
S3のバケットを非公開にしたら、すべてのファイルが意図した相手だけに届くとは限りません。署名付きURLを持つ人や、CloudFrontなどの配信経路から閲覧できる場合があるためです。「匿名でS3へ直接アクセスできない」と「業務上許可した人だけが見られる」を区別する必要があります。
本記事は2026年10月18日にAWSの一次資料を確認した、非公開データの共有・配信に関する解説です。特定の漏えい事件の速報ではありません。既存のS3静的Webサイトの公開や403解消の記事とは目的が異なり、公開を前提としないデータの境界を扱います。以下の顧客向けPDF配信は仮想例です。
Block Public Accessの役割を過大評価しない
Block Public Accessは、公開につながるポリシーやACLなどを制限するための重要な仕組みです。設定の適用範囲と組み合わせをAWSの資料に沿って確認します。一方で、認証された主体に与えた権限をすべて取り消すための機能ではありません。
アプリが使うIAMロールへ広い読み取り権限があれば、そのアプリを通じてファイルが読める可能性があります。公開アクセスの状態と並べて、どの主体がどのオブジェクトを読めるかを確認します。アカウントやバケットの設定だけを撮影して点検完了にしないことが重要です。
本サイトは、公開用画像、顧客向け書類、バックアップなどを用途別に整理し、アプリのロールと保存先を対応させることを勧めます。パスの命名規則だけを認可に使わず、実際に必要な範囲へ権限を絞ります。名前が分かりにくいファイルでも、秘密にすべきデータのアクセス制御は省略できません。
基本となる資料：Amazon S3 Block Public Access。
スポンサーリンク
署名付きURLは持っている人が使える秘密として扱う
署名付きURLは、作成した主体の権限をもとに、一定の条件で操作を可能にするURLです。リンクを知っている人が使える性質を持つため、単なるファイルの場所ではなくアクセスのための秘密として扱います。一度メールで送った後に、宛先の本人だけが使えると考えないでください。
有効期間はURLに指定した期限だけで決まるとは限らず、署名に使った資格情報の有効期間などにも制約されます。発行時刻、操作の種類、対象オブジェクト、期限を把握し、アプリで必要な長さに制限します。短くすれば常に良いわけではなく、配送の遅延や大きなファイルの利用条件も検証します。
期限内に繰り返し使えることと、一度だけ使えるリンクは別です。一度限りの配布が必要なら、アプリ側で利用者と消費状態を管理するなど別の設計が必要になります。期限切れは、すでに相手が保存したファイルを消す機能でもありません。
発行前の認可がファイルごとの境界になる
仮想の顧客ポータルで、ログインしているだけで任意のファイルIDから署名付きURLを発行できると、顧客間の境界が崩れます。URLの署名が正しくても、発行対象を選ぶ処理が間違っていれば安全にはなりません。
発行前に、現在の利用者が対象の契約や書類へアクセスできるかをアプリ側で確認します。外部から受け取ったS3キーをそのまま署名せず、許可された業務上のIDから保存先へ対応付ける方式を検討します。アップロード用URLでも、保存先、操作、必要な条件を限定します。
発行の記録には利用者の内部ID、対象の内部ID、結果、期限の方針を残し、署名付きURLの全文を保存しないことを勧めます。問い合わせ対応のために秘密をログへ残すと、ログ閲覧権限が新しいファイル閲覧権限になるおそれがあります。
スポンサーリンク
CloudFrontのOACと閲覧者の制限を分ける
CloudFrontのOrigin Access Control（OAC）は、S3オリジンへのアクセスを制限するために使います。S3へ直接アクセスする経路を絞っても、CloudFront側の配信が一般公開なら、閲覧者はそこからファイルを取得できます。オリジンの保護と利用者の認可は別の層です。
会員だけに配信するなら、CloudFrontの署名付きURL・署名付きCookieなど、用途に合う閲覧者側の制御も別途検討します。アプリへログインしたという事実が、そのままCDNのすべてのURLへ反映されるわけではありません。
AWSは、S3のWebサイトエンドポイントを使う場合はカスタムオリジンとして扱い、OACを使う通常のS3オリジンとは異なることを説明しています。静的Webサイトの構成へそのままOACを追加できると考えず、利用しているエンドポイントと配信方式を確認してください。
キャッシュとリンク失効の違いを試す
S3へのアクセスを遮断しても、すでに配信経路に保存された応答や利用者が取得したコピーの扱いは別に検討が必要です。S3のURLの期限と、CloudFrontなど別経路の閲覧条件やキャッシュの有効期間を一つの設定として扱わないでください。
本サイトの提案は、直接のS3 URL、CloudFront URL、アプリ経由のダウンロードを一覧にし、未ログイン、別顧客、期限切れの各条件で確認することです。権限を変更した後に、どの経路でいつから拒否されるかを記録します。緊急時に止める操作と、その副作用も把握しておきます。
機密データは、共有URLをチャットや解析ツールへ不用意に貼り付けない運用も必要です。ブラウザー履歴やアクセスログへの記録を完全になくせない場合、その前提で期限や配布方法を選びます。ダウンロード後の再配布まで防ぐ要件なら、S3の権限設定だけでは満たせません。
顧客向け書類を配る前の確認表
仮想の請求書配信で、顧客Aと顧客Bの書類を同じバケットへ保存しているとします。バケット自体が非公開であっても、アプリが顧客Aへ顧客Bの署名付きURLを発行すれば、S3から見れば正規の取得として処理される場合があります。ストレージの設定を正しくすることと、業務上の配布先を正しくすることは別の責任です。
本サイトは、まず二つのテスト顧客と各顧客の専用ファイルを用意することを勧めます。通常の画面操作で自分の書類だけを取得できることを確かめ、対象の業務IDを入れ替えたときはURLの発行前に拒否されることを確認します。ストレージ側で拒否されることだけに頼らず、アプリの発行記録で判断を追えるようにします。
期限切れの試験では、発行時刻と期限を記録し、期限前に開始した取得と期限後の新しい取得を分けます。実際の判定条件はAWSの資料と利用方式に沿って確認してください。テストのために、通常より長い期限を本番設定へ残さないようにします。大容量の書類では、利用者が再試行した場合の案内も用意します。
共有停止の試験には、リンクの期限を待つ操作と、権限や配信条件を変更して止める操作の両方を含めます。緊急停止が必要な業務では、どの操作がどの範囲のリンクへ影響するかを把握します。ある顧客の停止が、全顧客への書類配信を止めるほど広い操作になっていないかも確認します。
| 確認項目 | 許可される条件 | 拒否・抑止する条件 |
|---|---|---|
| S3への匿名取得 | 公開すると決めたものだけ | 非公開書類への直接取得 |
| URLの発行 | 本人と書類の権限が一致 | 別顧客の業務IDでの発行 |
| 共有URLの利用 | 定めた操作と有効期間 | 期限後の新しい取得 |
| 配信経路 | 認めた閲覧者の利用 | 非公開オリジンを公開配信する設定 |
日常の共有手順に秘密の扱いを組み込む
ファイルそのものだけでなく、共有URLにも閲覧権限を制御します。問い合わせの再現用にURLをサポートチケットへ貼ると、チケットの閲覧者へアクセスを広げる可能性があります。内部の書類IDと発行時刻で問い合わせできるようにし、必要なら利用者が画面から正規のリンクを再発行できる手順を整えます。
ファイル名やオブジェクトのキーに個人情報を含めると、URLを隠す対象が増えます。命名規則、アクセスログ、監視先、解析サービスへ渡す情報をまとめて点検してください。秘密の共有を前提とした経路では、権限と期限の設計をアプリ担当者とクラウド担当者が共同で確認することが重要です。
スポンサーリンク
共有する必要性から保存先を決める
誰でも見られる商品画像と顧客だけに渡す契約書を同じ方針で扱わないようにします。データを作る段階で公開区分を決め、必要な共有経路と保存期間を対応させると、後から機密ファイルだけを探して閉じる作業を減らせます。画像のように見えるファイルでも、内容によっては個人情報を含むため用途で判断します。
運用担当者の手動共有もアプリの自動発行と同じ基準へそろえます。緊急だからという理由でバケット全体を公開して問題を解決しないようにし、正規の配布手順と権限を用意します。変更の承認と記録があれば、後から誰へ何を渡したかを調べやすくなります。
不要になったファイルを削除する処理と、アクセスを停止する処理の順序も決めます。法令や契約上の保存が必要なデータは単純に消せない場合があるため、保存と閲覧の権限を別に考えることが重要です。
段階的に変更して正常な配信も守る
最初にデータ区分と公開すべき経路を決め、次に不要な権限と直接アクセスを減らし、最後に署名とキャッシュの条件を検証します。既存の公開コンテンツまで一括で止める変更を行わず、検証用オブジェクトから始めます。
テスト用の主体を分け、許可されたアプリでは取得できるが無関係の主体や匿名では取得できないことを確かめます。外部公開の有無を検査する機能と、アプリが正しい顧客へ発行するかを試すテストは、両方必要です。
403の減少だけを成功の指標にしないことが大切です。非公開データでは、正しい拒否が維持されていることが成功になります。公開アクセス、IAM、アプリ認可、共有URL、配信キャッシュの五つを分けて説明できる状態にすると、便利さを保ちながら誤公開を減らせます。
スポンサーリンク
参考資料
以下は本文の作成時に直接確認した一次資料です。確認日は2026年10月18日です。設定や提供条件は、利用環境に対応した資料も確認してください。
