物件儲存的外洩，通常沒有任何入侵。沒有人闖進系統，沒有帳密被盜，紀錄裡也看不出異常。只是設定讓資料變成了公開。
為什麼沒有人入侵，資料卻外洩了
入侵
漏洞或帳密 → 闖入 → 取出資料
修補、驗證和監控都各有機會擋下它
設定錯誤（公開的儲存貯體）
知道（或猜到）URL → 直接取得
不是「驗證被繞過」，而是從來就不需要驗證
這類問題難以偵測的原因是存取看起來並不違法。攻擊者只是對一個真正公開的端點送出普通的 GET 請求，入侵偵測或紀錄異常幾乎沒有東西可以抓。這和絕對不能放在公開目錄的東西是同一個問題，只是發生在儲存空間而不是伺服器上。
四項設定各自擋下不同的東西
S3 Block Public Access 是四項獨立的設定，可以任意組合套用。名稱相似到常被當成一個開關，但每一項擋下的東西都不同。
- BlockPublicAcls
- 讓套用新的公開 ACL 的操作失敗（
PutBucketAcl、PutObjectAcl，或帶有公開 ACL 的PutObject）。不會修改既有的政策和 ACL，所以已經存在的公開 ACL 會繼續存在 - IgnorePublicAcls
- 讓 S3 忽略儲存貯體及其物件上所有公開的 ACL。帶有公開 ACL 的
PutObject仍會成功（這是與 BlockPublicAcls 的差別）。它不會移除既有的 ACL，也不會阻止設定新的公開 ACL - BlockPublicPolicy
- 拒絕允許公開存取的儲存貯體政策（
PutBucketPolicy及相關的存取點呼叫）。不影響既有的政策 - RestrictPublicBuckets
- 把帶有公開政策的儲存貯體的存取，限制在 AWS 服務主體和擁有帳戶內的授權使用者。它會封鎖跨帳戶存取（AWS 服務主體除外），包括對特定帳戶的非公開委派
四項設定的共同特性，幾乎所有人都忽略了
請注意上面每一項都寫著不會修改既有的政策和 ACL。文件直接寫出了這代表什麼：「封鎖公開存取的設定不會變更既有的政策或 ACL。因此，移除封鎖公開存取設定，會讓帶有公開政策或 ACL 的儲存貯體或物件再次可以被公開存取。」
所以開啟封鎖並沒有消除危險。它只是暫時擋下存取，公開的政策和 ACL 還在那裡。有人為了調查暫時解除封鎖、複製到另一個帳戶、Terraform 的差異把它還原了：任何一種情況都會讓資料再次公開。請把目標狀態定為「關閉封鎖時也不公開」，而不是「封鎖已開啟」。
「公開」的定義比你想的更廣
即使你認為儲存貯體是私有的，S3 仍可能把它評估為公開。
被評估為公開
・把權限授予 AllUsers 或 AuthenticatedUsers 的 ACL：後者指的是所有擁有 AWS 帳戶的人，不是你公司裡的所有人
・儲存貯體政策中指定主體的值含有萬用字元或政策變數
・aws:SourceIp 的範圍太寬（IPv4 比 /8 寬、IPv6 比 /32 寬，私有範圍除外）
S3 一開始先假設儲存貯體政策是公開的，再評估它是否符合非公開的條件。如果不明確，就會被評估為公開。
被評估為非公開
把存取限制為不含萬用字元的固定值的政策，例如主體、一組 CIDR 區塊、aws:SourceArn、aws:SourceVpc、aws:SourceVpce、aws:SourceOwner、aws:SourceAccount 等。
文件自己舉的例子：aws:SourceVpc 設為 vpc-* 是公開的；設為 vpc-91237329 這種固定值則不是。「我縮小了範圍」和「我縮小到了固定值」，就是這個判斷的兩邊。
在帳戶層級啟用封鎖，而不是逐一設定儲存貯體
文件建議在帳戶層級套用 BlockPublicPolicy，因為儲存貯體政策可以允許使用者變更該儲存貯體的封鎖公開存取設定。
只有儲存貯體層級
能修改儲存貯體政策的人 → 加入停用封鎖的政策 → 儲存貯體可以被設為公開
帳戶層級
即使儲存貯體政策被改寫，S3 仍會封鎖公開的政策
當存取點、儲存貯體和帳戶的設定不同時，S3 會套用限制最嚴格的組合。較嚴格的設定優先，所以在上一層（帳戶）加以限制，下層就無法放寬。這就是套用在儲存空間上的最小權限。
修正的順序
先看哪些東西是公開的，再把它藏起來
先開啟封鎖，雖然能停止外洩，但同時也會讓你看不到曾經公開了什麼。BlockPublicAcls 的說明正是如此：它能防止公開存取，「同時讓你可以稽核、調整或以其他方式變更既有的政策和 ACL」。AWS 提供 IAM Access Analyzer for S3，會列出 ACL 或政策授予公開存取的儲存貯體，並針對每項發現回報存取的來源和層級。請先在那裡做好盤點。
在帳戶層級啟用全部四項設定
AWS 建議為帳戶（以及每個儲存貯體，也就是 Security Hub 控制項 S3.8 檢查的內容）開啟全部四項封鎖公開存取設定。請先確認你的應用程式在沒有公開存取時仍能正常運作。如果確實有需要公開的東西，例如靜態網站託管，就針對那個情況個別調整，而不是在所有地方都略過這個控制。
實際移除公開的 ACL 和政策（最重要的步驟）
封鎖不會刪除既有的公開政策或公開 ACL。**回到步驟 1 的盤點結果，把它們移除或改寫。**做到這裡，才算達到「關閉封鎖時也不公開」的狀態。多數團隊停在步驟 2，而這正是本文的重點。
對必須公開的儲存貯體，控制放進去的東西
如果公開存取確實是必要的，就把儲存空間分開，讓公開的儲存貯體只放可以公開的東西。備份、資料庫傾印和客戶名單，不要和公開素材放在同一個儲存貯體。放進儲存貯體的東西，決定了它最多會外洩多少。伺服器端同樣的思路，請看在共享主機上保護 .env 不被存取。
不要依賴檔名
「沒人知道 URL」不是存取控制（這和可被猜到的識別碼是同一個問題）。**難以猜測的名稱是額外的防護，不能取代權限檢查。**需要暫時分享時，請使用會自動失效的方式，也就是有時效的簽章 URL，並讓公開設定保持關閉。
本站的看法：設定類事故，只有在狀態可以被檢查時才會減少
儲存貯體公開的問題一再發生，不是因為人不小心，而是因為狀態看不見。儲存空間是否公開，不像檔案權限或伺服器設定那樣單純，而是由政策、ACL、帳戶設定、存取點四層組合而成，任何一層單獨都無法告訴你答案。對這類領域，本站的立場是讓機器去評估組合結果，而不是依賴人的注意力：在上一層加以限制讓下層無法放寬，並定期用能直接給出公開或非公開判定的工具重新盤點。「小心一點」不是一種控制。這和我們對相依套件得出的結論相同（osv-scanner 入門）。
資料來源（一手資料）
- Amazon Web Services, "Blocking public access to your Amazon S3 storage"（Amazon S3 User Guide）— docs.aws.amazon.com（四項設定的行為、封鎖不會修改既有政策或 ACL 的說明、「公開」的定義，以及建議在帳戶層級套用的理由，皆出自這份文件）
延伸閱讀
- 放置位置：絕對不能放在公開目錄的東西／在共享主機上保護 .env 不被存取
- 帳密：.env 和 API 金鑰危險在哪裡／SSH 金鑰與最小權限
- 盤點：資產盤點檢查清單
- 同樣是「因設定而外洩」的類型：子網域接管與懸空 DNS
FAQ
Q啟用了 Block Public Access 就安全了嗎？
目前外部確實無法存取，但危險並沒有消失。AWS 文件寫明，封鎖公開存取的設定不會修改既有的政策或 ACL，因此移除封鎖設定後，帶有公開政策或 ACL 的儲存貯體或物件會再次可以被公開存取。公開的政策和 ACL 仍留在封鎖底下。你要的不是「封鎖已開啟」，而是「即使關閉封鎖也沒有任何東西是公開的」，也就是要刪除公開的政策和 ACL 本身。
Q設定應該套用在每個儲存貯體，還是整個帳戶？
整個帳戶。文件在 BlockPublicPolicy 的說明中解釋了原因：儲存貯體政策可以允許使用者變更該儲存貯體的封鎖公開存取設定，所以能修改儲存貯體政策的人，就可以加入一條停用封鎖的政策。如果在整個帳戶啟用這項設定，即使使用者修改了儲存貯體政策，S3 仍會封鎖公開的政策。儲存貯體層級的設定，能編輯儲存貯體政策的人就能移除。
Q到底什麼才算「公開」？
定義比多數人以為的更廣。如果 ACL 把權限授予預先定義的 AllUsers 或 AuthenticatedUsers 群組，就算是公開；而 AuthenticatedUsers 指的是所有擁有 AWS 帳戶的人，不是你公司裡的所有人。對於儲存貯體政策，S3 一開始先假設政策是公開的，再評估它是否符合非公開的條件；只有在存取被限制為不含萬用字元或政策變數的固定值時才算非公開。使用 aws:SourceIp 但範圍非常寬（IPv4 比 /8 更寬）的政策，也會被評估為公開。
Q新建立的儲存貯體預設是安全的嗎？
文件說，新的儲存貯體、存取點和物件預設不允許公開存取，但使用者可以修改儲存貯體政策、存取點政策或物件權限來允許公開。所以預設是安全的一方，而幾乎所有事故都發生在有人刻意、或為了某項工作暫時偏離預設的地方。不要依賴預設：你需要一個無法在局部關閉的控制（帳戶層級的封鎖），以及一個能看出設定偏移的方法。