0. 綜述

之前也寫過幾篇關于數據安全的文章，有興趣的可以翻下之前的博客。本文整理了一份腦圖，不過不會詳細介紹數據分類分級，也不會去講全站TLS之類的安全項目，以及KMS、PKI等如何建設。更多的是關注在整體的聯系。

img

整體來說是通過一些政策/規范去支撐技術實現，然后通過定期的安全教育和審計檢查實際運營的狀況。安全教育和企業安全文化看起來很虛，實際上在基礎建設到一定程度之后就顯得很重要。因為意識往往在第一防線，甚至超過了工具。腦袋里要保持什么數據可以傳輸到什么地方，什么數據不可以在什么地方保存。永遠保持對外部輸入信息的警惕。

(相關資料圖)

數據分類分級是進行數據治理（數據治理是個話題復雜且實踐更復雜的東西）的第一步，當然考慮到不同的業務、產品、基礎設施。不同企業推進的方式也不一樣，可能落在數據團隊上，也可能是風控團隊，也可能是內控團隊，或者共同協作（數據治理的標準方式，不過注意要在最初就區分開不同團隊的職責）。實際來說，安全團隊推動分類分級的落地成本要遠比想象的高，而輸出分類分級政策可能是較為合適。通過對不同級別數據在整個生命周期里的約束，來保障數據安全。但常用的保障技術又絕非僅僅數據安全技術。實際在架構設計中，除了加密，令牌化，脫敏之外還需要考慮身份認證及授權，網絡訪問控制，日志監控和審計。換句話說，需要作用在基礎設施的安全控制之上。只有劃分好了不同等級的安全域，建立了網絡隔離之后，才能把對應等級的數據放到對應的區域中去。受限訪問的PCI存儲和控制區域和非受限的PCI存儲和控制的訪問也是不同的。至于到對應區域內，應用服務和管理后臺又是不同的訪問方式，身份認證的要求，傳輸的要求等等。另外針對客戶的端上數據存儲也需要有對應規范。

下面簡單的看一下辦公網和生產網整體的數據安全架構設計。

1. 數據安全架構

1.1 辦公網數據安全架構設計

本來是想展示原有架構怎么過渡到目標架構的。但后來一想實際情況各家又不一樣，不如簡單挑一下幾個關鍵點說一說。

img

分離服務和控制平面 這個借鑒了微服務的術語，其實比較好理解，就是把資源生產和資源使用分開。比如AWS Console就是控制平面，創建的都是服務資源。不過這種劃分并不盡然，在AWS EKS中，對EKS的訪問又屬于控制平面，對SVC的訪問則屬于服務資源。遵循的原則就是SOD及最小化權限原則。確保非必要的權限不會流轉出去。

分級控制訪問終端 企業內的辦公終端除了Laptop，手機之外一般還會有虛擬桌面，AVD，VDI之類的，這一類一般稱之為瘦終端。針對不同級別的終端在建立標準化的安全控制之外，仍需要分級控制。例如Mobile端可以訪問Service，但不可以訪問Portal，一些敏感系統需要在Laptop和Citrix之后。同樣，針對不同用戶群體也不相同，客服的終端永遠不應該訪問Bastion等等。

NACL 這個話題比較常見，后面在生產網的架構圖里也會討論。這里先聊辦公網的，針對網絡ACL，協議，端口這些都不做討論。需要注意一點就是層級依賴導致的NACL傳遞失效以及目標系統對NACL的支持。比如某Cloud Service配置了SSO登錄，SSO做了NACL限制了訪問IP，但在登錄Wiki成功之后，由于該系統本身沒有配置NACL，導致Session可用的情況下避開了檢測并能直接導出數據造成數據泄漏

條件訪問、SSO與特權賬戶管理不同的系統必須采用統一的IDP進行登錄認證，并完成授權。并且能夠針對登錄行為通過網絡位置、認證難度等條件進行限制，允許登錄與否。同時針對特權賬戶進行單獨管理。比如拆分特權賬戶和普通賬戶之后，再結合條件訪問，僅當允許來自某某IP段的可信設備完成MFA之后，方允許登錄。在此之外，還需要做相應的日志和監控。

檢測及處置 運營模式會放到后文數據驅動的SOC安全架構里面去講。關于檢測來說，辦公網的數據大多為非結構化數據，而且類型復雜。在用戶權限降低，賬戶登錄受限并僅能訪問到合適的文件，安裝必要的軟件之后，仍需要檢測出向的數據。一方面通過信息標簽，設置默認控制手段，并敦促用戶手動調整文件等級。一方面通過DLP工具，在端上和網絡層進行檢測。技術手段之外就是考核和培訓了。辦公網的數據安全主要集中在終端的管控上，可以參考之前寫的淺談終端安全與DLP治理, 而對于向終端用戶提供服務的，屬于Corp這一側的東西后面暫時以Prod緯度去看（注意不是以Corp/Site緯度）

1.2 生產網數據安全架構設計

相對于辦公網而言，生產網的數據結構良好，模式固定。生產網的數據安全治理遠比辦公網要輕松的多。

img

邊界防護 需要關注訪問控制與網絡隔離，外部流量透過邊界進來需要流量清洗，IDS，WAF等，辦公網到生產網的邊界隔離及控制。生產網內部不同區域的網絡隔離等等。不過NACL這里，需要考慮四層和七層。以AWS EKS舉例設置安全組時如果使用AWS CNI插件并且采用的是ENI，那么ENI綁定的IP發生變化時可以被檢測到并自動調整，所以并不影響POD級別的安全組。不過如果使用的是Trunk模式，就安全組只能作用到Node級別。如果使用K8S的network policy則需要要求Pod內沒有四層svc才行，否則也無法解決安全組響應IP的變化。

出網審計 其實也是邊界的一部分，單獨挑出來是因為出向流量著重被管控到。其實也是收攏數據傳輸通道之后，開辟受限的安全通道，并只允許針對固定的協議等。

密鑰及加密 之前講太多了，不講了。一是密鑰的價值等同于數據的價值，二是注重根信任的傳遞，不要使用自創的加密算法。看了一些“復雜的”自創加密算法，簡直頭大。建議采用被批準的加密算法，通過根信任傳遞去創建密鑰。不過需要量力而行，考慮到預算，畢竟HSM和公簽的證書都不便宜。

備份及恢復 小到數據庫的快照，大到DR中心的建立，備份的恢復算是最后一道防線了。是通過同步實現備份，還是通過快照備份？如何對快照加密？對備份的訪問控制？誰有權限進行恢復，備份的完整性等等。

檢測及處置 這部分放到了SOC的架構中，見下文

這里ServeMesh內部細分的話還有一張單獨的架構圖，暫時不講。另外除了數據保護平臺之外，還需要數據掃描平臺，數據字典，元數據查詢等工具。

1.3 數據驅動的SOC安全架構

之所以把這一塊單獨拎出來，是因為數據安全的事件運營其實是可以合并到SOC中去的，并做到Data-Driven。這里隱去了一部分細節，著重關注下SOC的Workflow。數據安全事件的檢測和處置也只是其中一種，原理類似。

img

采購或自研的系統或者產品完成標準化的系統能力之后，通過對不同場景的運營并針對具體工具形成SOP，并由此切入自動化運營，而具體playbook的執行又是作用于相應的系統之上。在這個過程中，完成了運營的第一階段，而數據驅動就是以此為基礎，將各種數據匯集處理之后進行檢測等等，以此產生新的告警和事件，并觸發相應的SOP。而針對整個運營質量，則以可視化看板為主。告警的誤報率，部署的覆蓋率，平均響應的時間，場景的觸發等等。

還是要吐槽一下，搞運營不是搞話術，東扯西拉的。水平不夠就要學，不能瞎逼逼。另一方面，沒有經驗的Leader也無法有效識別輸出的質量。

還有一個老生常談的話題，就是運營-技術-管理，做一件事，尤其是運營（運營去處置，架構去設計等等）一定需要體現政策，流程，工具的結合作用。要有政策支持，標準化的流程，以及平臺或工具實現。無論是架構設計還是安全咨詢等等，最后都要進入常態化運營階段的。野路子另說，野路子太野了。舉例來說，沒有Policy約束的話，日志應該跨云怎么辦，能不能跨？

另外時常看到有人無法區分政策規范流程的，這里我簡單畫了個圖

另外定Policy的時候需要考慮到是為了落地適應現狀，還是說為了引導現狀的改變。如果只是為了適應現狀，具備某個Policy，以便通過某些檢測。那就變成了，我已經有了某些合乎標準/或不合乎標準的東西存在，然后把這些東西放在文檔里。檢測的時候我們有了這個Policy，只是政策的顆粒度不夠細，所以“后面會修改”。當然更多的時候可能只是你有這個Policy就行了，內容甚至都沒有人看。另一種是，通過Policy支撐技術約束落地，即便現有的基礎設施或者應用不符合，后續也會向這個方向過渡。這是很重要的兩種區別，前者并非毫無意義，但這種階段性的折騰往往不能改變什么現狀。（在過檢前補寫過各種SOP和Policy的人應該理解我的意思。）

2. 數據安全架構案例

從過去一年里精選里一些數據安全相關的架構設計案例。出于篇幅原因不能每個都展開和分析，僅作分享。你能想到哪些細節？

img

3. 總結

通過以上可以看到在這些控制措施中并非僅僅只關注數據安全的技術手段，還會考慮到安全培訓，日志監控等等。另外考慮到數據生命周期，還需要把相關技術應用到不同階段。以及針對技術的bypass，例如針對文件的刪除，是wipe，purge還是destroy？曾有人認為使用Serverless即可避免應用層之外的漏洞，類似的有了MFA就能避免權限問題，密碼復雜度達到一定程度就是足夠安全的。但有時候我們是不是想的太簡單了？

企業內的IT基本環境可區分為 IDC（On-Prem） , Cloud（Serverless， IAAS，PAAS，SAAS）, SAAS。從IDC到Cloud到SAAS過程中，Self-Managed的東西越來越少（可以查看這張圖 ）。換個視角說可能有更多的精力/資源投入對Data的控制中。但實際情況卻是恰恰相反。在IAAS到SAAS的過程中，企業對自己數據的管理手段越來越少，即便SAAS服務提供商受GDPR約束，也無法提供完整的數據管理功能給到客戶。因為廠商在提供SAAS服務的過程中，對用戶來說雖然是屏蔽了底層的控制行為，但實際的數據還是存儲在Data Center。那么如果需要開放這部分能力給到客戶，就會帶來很高的成本。作為甲方，更希望能夠獲取對數據的完整控制能力，而不是僅僅關注數據防泄漏上。只有獲取了完整的控制能力，才能處理數據流動所產生的相關問題。我看到大部分的文章，一談數據安全，就是分類分級，生命周期管理，數據防泄漏三大塊話題。至于密鑰加密，架構設計，日志監控等，則在數據安全中提到的很少，且不能因為云化過程基礎設施被屏蔽而忽視基礎設施的重要性。

有興趣的同學可以閱讀下之前寫的關于數據安全的一些文章。

再聊聊數據安全

淺談加密基礎設施

關鍵詞：