給Twitter設計個安全修復方案

不要神化國外的安全建設web

Twitter的苦衷小程序
要解決的問題後端

設計安全方案的原則api
訪問控制架構瀏覽器
注意事項安全

不要神化國外的安全建設

安全作的不差的NetFlix（參考Netflix的DevSecOps最佳實踐），由於財報不理想最近股價大跌，Twitter有高危漏洞可是股價並未受影響，更加說明了筆者的論斷：企業業務發展遠比安全風險給股價帶來的長期影響重要.....服務器

此類漏洞觸類旁通TSRC（參考企業安全建設丨當咱們在談論推特安全事件時，咱們在談論什麼？）給出的解決辦法是1、內部系統須要零信任；2、權限類收斂採用框架集成全鏈路票據，數據操做層集中驗票的，想來在騰訊徹底落地有難度，也不能讓Twitter快速解決問題。筆者看到Twitter內部這麼久還沒閉環，做爲美國股市精神股東真替他們捉急。：）微信

根據最新的媒體報告，Twitter認爲這次漏洞緣由是」公司檢測到了一次協同式社交工程攻擊，發動者成功鎖定了一些具備訪問內部系統和工具權限的Twitter員工。黑客利用這些訪問權限控制了許多知名帳號和密碼，以後便使用其帳號發佈關於比特幣的動態。「，屬於內部的人爲失誤\蓄意破壞\信息竊取這一類風險。上一次出相似的事情是前亞馬遜工程師Paige Thompson 被指控利用工做方便來訪問Amazon雲服務上的Capital One服務器。cookie

Twitter的市值只是1/48個谷歌，1/2個百度，市值決定安全的投入，不能盲目崇拜國外科技公司的安全建設。從歷史反覆漏洞披露的信息看到，Twitter內部存在很多歷史安全問題。黑客簡單社工後便可徹底控制內部系管理統，利用內部權限能夠控制用戶Twitter帳戶，無審覈機制，直接修改郵件重置密碼，用戶信息無隱私保護和數據脫敏。網絡

Twitter的苦衷

Twitter案例中關鍵突破點是內部系統的高權限被社工或收買了。內部應用一般會涉及敏感數據或功能，例如用於生產系統的調試面板、帳戶管理系統或具備敏感公司數據的數據流和機器學習模型。Twitter安全性作的很差，是由於：

1、現有的商用防禦方案又難以覆蓋，傳統的基於網絡、員工身份的隔離方案徹底不適用。不能僅僅將這些內部應用程序經過防火牆隔離，網絡隔離仍然有可能會被意外配置暴露在公網，並且外部攻擊者仍可經過XSS+CSRF或SSRF組合拳攻擊，或者經過內網環境中已經隱藏攻擊者（黑客或內部人員）。

2、這類問題通常並視爲運維安全和辦公網安全和開發安全的三者責任間。與生產環境相比，內部應用程序一般會被安全團隊有意無心的忽略，安全團隊反饋的吐槽是兩個大問題：這類系統太多了，屬於歷史遺留問題；開發語言多樣，沒有統一的解決方案。

3、安全人員不足：Twitter的安全招聘信息已經掛了兩個月了，看來仍是缺人惹的禍。

要解決的問題

因此說如今的攻防趨勢是技術上直接攻擊愈來愈難，黑客轉而關注間接從內部獲取權限，並不只僅遵循從internert-dmz-db存儲的方式，走向了internert-內部用戶或內部系統-信任關係-db存儲。線上的生產環境通過了白帽子反覆蹂躪，基本作到了符合安全基線，背後的開發語言、應用框架、資產管理是相對完善的。可是內部的私搭亂建，各類員工機器的的CI|CD系統，重要的內部服務系統，就有五花八門的開發語言，技術和風險了。

設計安全方案的原則

風險是廣泛了，問題是須要覆盤的。假設咱們要防護相似於Twitter這樣的攻擊，須要安全建設的理念是：

不是ServiceMesh架構不能照搬lstio方案
防護方案應該是可擴展的，而且兼容後端的技術棧。
結合軟件開發和發佈流程
設計出色的技術解決方案還不夠，落地纔是
應用防護措施時，安全團隊和開發項目組都須要參與進來

訪問控制架構

以上是成形的架構。具體的解決辦法是分爲五步走：

設置中間層代理，以往員工直接單獨訪問內部系統進行操做，危害性參考有：無網絡隔離直接訪問內部系統裏面可能包含未脫敏信息缺乏鑑權機制這時候加個訪問層的代理是解決問題的第一步。加入代理的好處多多，能夠收斂入口，設置網絡隔離，訪問系統管理。一切的機制是在隔層的代理上作，代理的形式能夠是api網關、統一portal。
傳輸層加密。在準備推動代理的時候，不用等系統開發完成，能夠調研引入全鏈路的tls進行傳輸層的加密。這裏的理由有兩個：Twitter這樣和客戶隱私強相關的企業，必需要防止內部網絡層的竊聽，每一層的安全措施都要作到底。借鑑google自研的ALTS，參考https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security?hl=zh-cn 或者FaceBook的方案 https://engineering.fb.com/security/service-encryption/ ，保證應用傳輸的安全，借用pki證書或者Kerberos機制能夠用來表示服務的身份模型，並且具有極強的架構伸縮性。
作到訪問的統一收口，基於代理開發sso+u2f的機制作到訪問的統一收口，逐步梳理系統讓加入此機制。u2f機制必定層面上杜絕密碼猜解、調用、離職員工訪問的途徑，後續添加FIDO等零信任訪問控制措施。
收斂員工的使用新版瀏覽器，先後端加入監控，日誌，埋點，行爲檢測等功能，由運營風險分析（ORA）團隊處置審計。
代理添加通用CSRF保護（添加SameSitecookie標誌）和XSS保護（Content-Security-Policy標頭+隨機數），設置內網waf。好比攻擊者有個xss，可使用csrf獲取內部系統信息，這個時候在代理層設置csrf策略，對防禦者成本極低，內部應用也無感知，可是收斂面向內部高權限人員xss的危害收益極高。內網的waf聽起來會受到的接入阻力較多，可是內網場景固定，干擾項少，實際上內網waf的誤報會不多，沒有不少的噪音。

注意事項

拍腦殼出具安全方案不是問題，落地有防禦效果纔是，如下是幾個要注意的點：

安全需聯合技術團隊合做開發維護代理層，並在出現問題隨時響應。有數字取證，安全工程或隱私工程方面的技術經驗很重要，有維護高可用、系統穩定性運營經驗的團隊更重要！
基於存量系統增長安全防禦系統首先要考慮可維護性，可用性高於安全性，必定要避免出case。
在不影響業務運營的時候同步進行開發和部署。理想狀況下，若是代理服務器出現故障，背後存在關鍵系統，會阻止正常工做，假設若是代理後面有堡壘機，則若是代理髮生故障，將再也沒法再登陸堡壘機故障排除......
推動的節奏不用全面收斂，優先關注高危的風險。 如何肯定要收斂的風險範圍作到不遺漏呢？內部多打就行了。
向上管理。這個框架能夠幫助肯定Twitter距離谷歌的差距在哪裏，將來的安全投資方向是什麼。有基於事件驅動的安全不可怕，沒有將策略傳達給高級管理層纔可怕。筆者這裏提供個簡單的示例，點擊可右移滑動：

	定義	防護	檢測	響應	恢復
須要讓哪些團隊參與	帳戶、運維	社會工程學	異地登陸、xss、異常感知	應急流程、公關	恢復異常帳戶
必須構建什麼技術	開發流程、數據安全技術	培訓、郵件網關、零信任	身份認證、行爲檢測	工單、操做審計	私信、公告板
建立什麼流程	背景調查，安全顧問理事會	培訓機制	應急響應流程，知識庫	應急響應流程	媒體應急發佈流程

週年贈書福利

參與方式一：點擊下方抽獎小程序，關注公衆號安全樂觀主義，將本文轉發到朋友圈和微信看一看便可參與！公衆號後臺將隨機抽選取幸運用戶，每人贈書一本！

參與方式二：爲本公衆號投稿一篇安全相關的文章，內容形式不限，便可得到贈書一本！趕快參與起來吧~

本文分享自微信公衆號 - 安全樂觀主義（gh_d6239d0bb816）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。