Conclusion
この記事の結論
配信元の読み取り条件を対象ディストリビューションに限定し、保存済みポリシーを照合しました。
静的サイトでは閲覧者が開くURLと、CloudFrontがオブジェクトを取得する配信元は役割が異なります。サイトを公開し続けながらS3側の読み取り条件を狭めたい場合は、「誰が」「どの配信から」「何を読み取るか」を一組にしてポリシーを確認します。
今回の対応
11月1日、配信元バケットに対するCloudFrontからの読み取りを、対象のディストリビューションに絞りました。ポリシーを保存後に読み戻し、許可の対象と条件が意図した組み合わせになっていることを確認しました。
ポリシーを読み戻す理由
対象がS3のウェブサイトエンドポイントか通常のバケットオリジンかで、利用できる仕組みが異なります。今回のように指定したディストリビューションからの読み取りを絞る場合、ポリシー保存後に対象と条件の組み合わせを読み戻すと、意図と実際の記述を比較できます。アプリや閲覧者にS3の直接アクセス権を付ける変更は別の要件です。
状況別の判断と次の対応
| 観察した状態 | そこから判断できること | 次に確認すること |
|---|---|---|
| 対象の配信に限定した条件 | その許可がどの配信に適用されるかを説明できる | 保存済みポリシーと変更前を比較する |
| 公開ページが表示される | 閲覧側で表示できた | キャッシュの有無と配信元の検証を区別する |
| 別の許可が存在する | 今回変更した設定文だけで全体は決まらない | 他の許可は対象範囲を定めてレビューする |
「サイトが見えた」だけで終わらせない
キャッシュされているページは、配信元の読み取り設定に問題があっても表示される場合があります。配信の動作まで確認する試験では、閲覧URLだけでなく、変更後の配信元読み取りを確かめられる条件を選びます。11月1日の記録で確かめたのは保存済みポリシーの内容です。
- 01配信元と対象ディストリビューションを対応付ける
- 02保存済みの読取り条件を照合する
- 03閲覧側と配信元側の動作確認を計画する
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認