自動化技術導致的七大嚴重安全事件
澳大利亞網絡安全評估初創公司UpGuard梳理了過去幾年的信息安全事件，列出了7大本為自動化公司IT系統卻招致重大信息泄露的安全實例。
1. Healthcare.gov：一個疏忽葬送美國政府的醫療健康網站
2013年10月，美國政府推行《平價醫療法案》的網上登記工具時，Healthcare.gov被寄予厚望;而數百萬公民健康保障的交付壓力，讓風險越來越高。于是，當該網站上線僅2小時就因重大軟件故障而崩潰時，政府遭到了相當大的抵制。由于缺乏集成、可見性和測試，該項目從一開始就埋下了重大隱患——Healthcare.gov的賬戶創建功能“ Account Lite ”中存在超過100個缺陷。
由于其功能，Account Lite 是 Healthcare.gov 網站的重要組成部分，供人們創建賬戶并訪問自己的醫療健康選項。該模塊問題太多，注定要引發災難。盡管如此，承包商還是照原樣推進了。
軟件發布失敗了，讓數百萬公民無法獲得醫療保障。更遭的是，網站崩潰還引發了政治衍生影響，讓《平價醫療法案》的反對者開始援引該事件作為政府無法發展成功醫療保障項目的鐵證。網站最終穩定了下來，但并應在發布前就集成的工作，卻是在崩潰發生后才做完。
2. Dropbox：讓Dropbox掉線的小缺陷
沒有哪個IT團隊會喜歡掉線經歷，尤其是掉線造成團隊必須快馬加鞭實現應急規程的時候。2014年1月，Dropbox就對一次計劃產品升級造成的3小時掉線抓狂不已。
Dropbox腳本中的一個“小缺陷”，自動將其更新應用到了幾臺活動主機上，于是，上千臺產品服務器受到影響，引發該公司在線服務崩潰。幸運的是，Dropbox的應急規程設計良好且有效。IT團隊在備份和恢復策略的幫助下，在3小時內成功恢復了大部分服務。然而，某些大型數據庫的恢復就慢得多了——全部核心服務完全恢復花去了Dropbox數天的時間。
3. 亞馬遜/DynamoDB：DynamoDB數據庫攪亂亞馬遜基礎設施
正如物流之類物理服務需要道路交通這樣的物理基礎設施，公司企業的數字服務也依賴于底層數字基礎設施。2015年9月，亞馬遜自動化基礎設施過程中斷，造成AWS平臺宕機。從簡單網絡中斷級聯反應成大面積服務掉線，亞馬遜經歷了傳統內部數據中心才會經歷的那種斷網——盡管它有非常先進和集成的云平臺。
亞馬遜的網絡中斷影響到其一部分DynamoDB云數據庫的存儲服務器。此事發生時，一些存儲服務器還在請求其成員資格數據。于是，斷線造成了檢索和傳輸超時，這些服務器無法獲得自己的成員資格數據，自動退出了服務。
當那些無法獲得請求的服務器開始重新嘗試請求的時候，DynamoDB超時問題便引發了更大面積的斷網。如此，惡性循環產生，亞馬遜客戶有5個小時無法使用AWS。
4. Opsmatic：后患無窮
托管在傳統服務器管理之下時，自動化往往也面臨同樣的古早IT問題。其中一個經典假定是：“沒壞就別修復”——假定所有系統都按預設方式運行。所以，Opsmatic的常規服務器維護搞攤了其整個運營時，根源就出在事情并沒有像他們原以為的那樣進行。
該案例中，名為“清除默認用戶”的方案在該公司AWS實驗早期階段被創建。如今，測試過去很久之后，該流程仍在生產服務器上悄悄運行，維護人員根本不得而知。
就像很多重大故障一樣，該事件也是長期的無心之失造成的，這些小過失逐漸積累，終釀大禍。
5. Knight Capital：拼寫錯誤致10億美元損失
不僅僅是管理性IT過程，其算法交易也被 Knight Capital 自動化了。然而，不幸的是，在真金白銀處理事務中，這些改變和計劃外的錯誤是有可能很快發生的。2012年，因為一個微小的錯誤，Knight Capital 在45分鐘里以 $172,222/秒 的速度大量損失資金。
大規模數據中心運營中，服務器集群通常都會執行單個功能。這樣可以將負載分配到更多的運算資源上，為高流量應用提供更好的性能表現。該模式要求集群中所有服務器都采用相同的配置，無論功能用到的是集群中哪個具體的服務器，這樣所有的應用就會有相同的表現。然而，配置這種東西，即便籌備的時候是相同的，也總是會逐漸出現偏差的。
盡管做了自動化，Knight Capital 在服務器陣列上的代碼部署卻還是手動的，而一個不可避免的人為錯誤，導致了其8臺服務器的配置與其他服務器不同。Knight Capital 的技術人員在部署新服務器代碼時出了這個小錯誤，但卻沒人發現。IT員工便一直在這些服務器都是相同配置的錯誤認知下操作。
同時，一段已經退役的代碼在錯誤配置的服務器上仍然可用。因此，該服務器開始向特定交易中心發送指令，圍繞股票交易的多米諾骨牌效應產生，4.65億美元交易損失不可避免。
6. 達美航空：自動化致航班停飛
大型物流運營依靠自動化系統達成規模化所需的速度要求。有些航空公司在維持這些系統運行上舉步維艱。就像傳統的人工系統管理方式，自動化系統也受到錯誤配置的傷害。最近幾年的最糟情形，便是這些系統宕機造成航空公司上億美元的損失，及其客戶信譽的喪失。
錯誤配置發生時，通過自動化機制，錯誤會被很快推送，造成整個系統宕機。對航空公司而言，這意味著航班運營中斷，飛機延誤，資金析出。2017年1月就發生過類似事件，達美航空自動化系統中的一個小故障引發斷電，給航空公司造成1.5億美元經濟損失。
7. 谷歌Gmail：您有新郵件?Gmail崩潰事件
當技術巨頭經歷偶發自動化相關中斷，一個小時的宕機所引發的后果會比表面上的損失更為深遠。這些行業巨頭想做任意改變，都必須覆蓋成千上萬臺服務器。身處技術前沿的谷歌自動化其配置管理毫不意外。雖然是為了讓操作更簡單而設，當錯誤修改在自動化系統里發生，便意味著該錯誤會在數秒內廣泛傳播。
2014年，谷歌內部自動化配置系統里的一個小故障，讓Gmail崩潰了大約半小時。該錯誤配置被發送到了在線服務上，導致用戶日期請求被無視，相關服務接連出錯。
經驗教訓在于，配置自動化并不等同于配置管理。自動化僅確保所做修改會被推送到所有系統上。
【本文是51CTO專欄作者“”李少鵬“”的原創文章，轉載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權】
