最近安全圈里出了一件大事。7月29日，美國第七大銀行Capital One稱客戶信息遭黑客竊取，被竊取信息數量約1.06億條，涉及信息主要為2005~2009年期間該銀行的信用卡用戶的各項信息。

事件一經披露，導致Capital One股價大跌，并面臨法律賠償。作為美國第五大信用卡簽發方，Capital One此次信息泄露有可能成為美國歷史上最大規模的銀行數據泄露事件。據外媒披露，黑客可能是利用了Capital One的防火墻的錯誤配置，入侵到其托管在亞馬遜（Amazon）的AWS云端數據庫，進而實施了數據竊取。

信息防泄露一直以來就是企業安全的重中之重，商業銀行作為運營關鍵信息系統的機構歷來重視信息的防護，但是企業做安全防護是體系化建設，黑客的入侵則是單點突破，在IT技術快速迭代變化的背景下，對防護體系的不斷更新、加固提出了艱巨挑戰，特別是在歐盟GDPR、國內網絡安全法等相繼頒布的監管趨嚴態勢下，信息泄露需要銀行安全付出更多關注。從一個銀行“老安全人”的視角，我也來說說此次事件中的兩類風險。

一、 公有云被攻擊的風險

云化服務是技術趨勢，是不是采購了云服務后安全責任就移交給云服務商了呢？很遺憾不是這樣，云安全一般采用責任共擔模式，由服務雙方共同保障。安全責任主體的劃分是根據提供的云服務類型來決定的。該事件中，Capital One采購了亞馬遜的AWS基礎數據服務，但AWS要求用戶數據的安全由客戶主要負責。亞馬遜稱，云端客戶能夠完全控制他們自己開發的應用程序，且沒有何證據表明其基礎云服務受到了損害。從已披露信息看，客戶數據應該是從Capital One側泄露出去的。這里帶給我們一個啟示，對于采購了公有云服務的系統，云安全的責任主體要劃分清楚，不能采購了云服務就認為安全責任都歸屬于云服務商，哪些層面的安全由云服務商負責，哪些層面由客戶自己負責，要做到心中有數。

二、 數據庫拖庫風險

數據庫數據的泄露途經一般分為外部拖庫、內部泄露。此次Capital One事件當中，嫌疑人是通過互聯網進行的外部拖庫攻擊。從這幾年積累的經驗來看，列舉如下幾條可能的攻擊路徑：

1、 利用網絡控制不嚴格直接訪問數據庫（如數據庫端口對外暴露）；

2、 利用應用漏洞實施拖庫（例如SQL注入）；

3、 利用未知漏洞入侵內網后通過跳板間接訪問數據庫。

如前所述，在拖庫攻防博弈中，防護人員需要封堵整個環境中的所有可能漏洞，而黑客只要找準一點、從系統最薄弱的點入手，層層滲透最終獲得目標權限。攻擊和防護是不對稱的。從本次事件的角度出發，針對以上三種攻擊路徑，在此各提出一些傳統有效的應對措施：

1、 直接拖庫攻擊風險應對：

通過防火墻限制外部可訪問端口；

部署IPS防護設備。

2、 應用漏洞拖庫攻擊風險應對：

開展代碼安全測試、上線前安全驗收測試、上線后滲透測試等工作，發現應用安全漏洞并及時整改；

在互聯網邊界部署IPS、應用防火墻等安全防護設備，實時監測和阻斷SQL注入等拖庫外部攻擊行為。

3、 跳板拖庫攻擊風險應對：

DMZ區與其它業務區域嚴格隔離，重要數據庫的網絡邊界設置防火墻；

部署用戶集中管理系統，通過設置密碼錯誤次數上限、用戶操作行為錄像等方式實現事前和事中控制；

安全補丁、操作系統補丁定期更新，各類服務器、數據庫安全配置檢查定期開展；

對掃描發現的漏洞及時修補，并對漏洞修補情況進行復查；

開展滲透測試、安全評估、科技檢查來發現潛在安全隱患。

此外有媒體稱，該事件其實自3月就開始了，嫌疑人3月發動了第1次攻擊，4月發動了第2次攻擊，Capital One是在7月收到提示郵件后才察覺攻擊，對風險是無監控或監控失效的狀態。如果該系統部署了異常流量監測、數據庫用戶設置了操作行為審計、針對防護設備的報警有所關注的話，還是有可能提前發現風險并修復漏洞的，不至于對風險毫無察覺。所以在日常安全運維工作當中，提高IT運維人員的安全意識，增強安全事件處理能力顯得尤為重要。安全小伙伴兒們，信息泄露防護任重道遠，和我們一起來探討行之有效的解決之路吧。

責任編輯：Rachel