Salesforce：一支未限定範圍的資料庫指令碼開放所有 Pardot 資料，並使 105 個執行個體停擺

2019 年 5 月 17 日，Salesforce 執行了一支與其 Pardot 行銷產品相關的資料庫指令碼，該指令碼「導致使用者取得比預期更廣泛的資料存取權」：現任與前任 Pardot 使用者可以讀取並編輯其組織內的所有內容，無視權限設定。為了控制暴露範圍，Salesforce 封鎖了所有包含受影響客戶的執行個體——共 105 個——連與 Pardot 毫無關係的租戶也一併停擺。

全面中斷持續 15 小時 8 分鐘，於 5 月 18 日太平洋夏令時間 0104 結束——而同一分鐘又開始了新一波中斷。為了讓執行個體能安全重新開放，Salesforce 清除了受影響使用者的權限，只還原管理員帳號，並要求客戶手動重新指派使用者權限。週末期間，它建置了一支從備份還原權限的指令碼，但到了週日，它回報成功率為 89%，因此大約每十個組織仍有一個的使用者權限遭到清除——而且在某些執行中，該指令碼重新授予了它原本要移除的廣泛存取權。

修復工作延續到隔週：到了 5 月 20 日週一，已有數千張工單開啟，沙箱執行個體仍處於停擺狀態，工程資深副總裁 Anmol Bhasin 在客戶通話中致歉，表示第一次修復「並未成功」，且所有可用的工程資源都已投入此問題。這次修復反而成為比原始故障更長的第二次中斷。

105 個執行個體離線；約 15 小時全面中斷，隨後數天的唯讀清理；週末的還原指令碼對大約每 10 個組織中的 1 個失敗

這項變更遠遠超出其預定範圍：針對部分 Pardot 組織的權限修復影響了整個平台，而在使用者看到他們根本不該看到的資料之前，沒有任何防護機制察覺到範圍擴大。

唯一安全的控制方式是將整個執行個體離線，因此一個產品團隊的錯誤，變成同一基礎設施上不相關客戶的共同中斷。

回滾從未經過設計：還原指令碼是在週末壓力下寫成的，對約 11% 的組織失敗，有時還重新授予了它原本要移除的存取權。

復原工作把負擔推給客戶——管理員手動重建使用者權限——使原本一天的 incident 拉長成一周的清理與支援負荷。

未限定範圍的資料庫指令碼是公司層級的風險。為每項變更限定範圍、分階段推出，並先建置回滾方案——否則解藥會比疾病本身鎖住更多客戶。

存取權自 5 月 18 日起逐步恢復；大多數組織在 5 月 20 日週一已恢復運作，沙箱與落後的組織則還需數天，因為 Salesforce 逐一執行個體執行其還原指令碼。Salesforce 表示，對大多數客戶而言，除了檢查權限之外無需採取其他行動，但這起事件已成為多租戶 SaaS 在變更範圍界定與影響半徑控制上的標準案例——也成為平台團隊以對待程式碼部署的同等謹慎來對待生產環境資料庫指令碼的理由。