1. 前言

2020年最后幾天，也算是把這篇文章補上了。修修補補，簡單講下在最近工作中對數(shù)據(jù)安全架構的一些認識。希望有用。下文將以三塊進行闡述，分別為數(shù)據(jù)安全的基礎架構，運營管理和產品自研。文中部分場景受限于自身經歷，可能各行業(yè)之間稍有差異。但道理應該大致相同。

2. 數(shù)據(jù)安全的基礎架構

在絕大部分情況下，做數(shù)據(jù)安全的同學可能并不會參與到數(shù)據(jù)安全的基礎架構中去，而是更多的focus在運營和服務交付層面。比如說提供相應的咨詢，處理內外客戶的需求。而數(shù)據(jù)安全相關的設備/軟件的部署運維大都還是由基礎安全的同學進行維護。這樣對于新人來說，其實比較容易進入的一個“點”上的誤區(qū)。只能看到手中所處理的相關服務，從而忽視了整個面上的東西。甚至忽略了處理業(yè)務的生命周期鏈。了解業(yè)務才能更好的服務于業(yè)務。在數(shù)據(jù)安全的基礎架構中，至少應該關注三點，一是流程和策略的制定，二是工具和設備的維護，三是相應服務的提供（咨詢，運營等）。這三點都應該有一個框架去約束，讓其能像劇本(Playbook)一樣跑起來。

所以在數(shù)據(jù)安全的基礎架構中，即應該關注策略也應該關注產品和服務交付的部分，這也是最先需要的做的事情——了解業(yè)務架構。因為數(shù)據(jù)安全更貼合業(yè)務，需要去知道哪里提供了什么樣的服務，服務需要受到什么樣的監(jiān)管，現(xiàn)有的設計是否能夠滿足監(jiān)管的要求等等。所以沒有業(yè)務的深入理解是做不好數(shù)據(jù)安全的。其次需要從組織架構上需要建立協(xié)作的流程規(guī)范，例如獲取生產數(shù)據(jù)的流程，唯一途徑來自哪里（是不是需要收攏入口？）假設說只有合規(guī)部門可以取數(shù)據(jù)，那么即便法務部門需要相應的數(shù)據(jù)，也需要經過合規(guī)部門的審批。而所有的操作流程也都應該有相應的審批記錄。從技術架構上建設相應的解決方案，數(shù)據(jù)怎么存儲，存儲在哪，怎么傳輸，靜態(tài)數(shù)據(jù)有沒有實現(xiàn)加密(DARE)，權限有沒有管控，使用的工具是不是符合相應的標準等等，都是技術架構上需要解決的問題。

下面會以不同的視角簡單的介紹一下相關的工作內容，在不同的視角下，把安全過程中涉及到的內容分散開了，乍一看會有點懵，但是事實上這種思考方式將會使安全工作更完善。例如，從銀聯(lián)獲取數(shù)字證書的流程。那么從業(yè)務視角來看，作為接入機構需要通過證書來做身份認證，僅需要通過提供相應的行政流程（書面申請，蓋章等等）即可獲取。但對于如何設定證書接收人，證書接收人的信息如何處理，如何滿足獲取證書的環(huán)境安全，如何確保證書獲取的過程可以審計，又如何使獲取后的證書安全存儲？是不是也屬于業(yè)務范疇之內呢。除此之外從應用視角來看時，就是提供該證書給應用進行調用即可。在這個過程中其實還需要考慮基礎架構，多活、災備機房、不同的虛擬化技術下的部署，是不是有預讀取等。而回歸到數(shù)據(jù)本身來看，就是怎么樣把等級為xx的一對公私鑰密鑰對，公鑰可以任意分發(fā)，私鑰僅能應用在內存中讀取。那如何規(guī)避非法的讀取，權限的控制，以及對私鑰的保護等等又是回歸到了數(shù)據(jù)本身。

2.1 業(yè)務視角

// 僅以個例說明下業(yè)務視角下數(shù)據(jù)安全涉及到一些事情。

業(yè)務上更多的會關注在流程和合規(guī)。而無論是在國內還是國外，合規(guī)基本上可以說是企業(yè)的生死線了。單從金融支付的業(yè)務來說，涉及到的合作伙伴就有中國網(wǎng)聯(lián)(NUCC),中國銀聯(lián)（CUP),互金協(xié)會(NIFAC)，清算協(xié)會(PCAC)。除此之外，無論是中央政府還是地方政府又有著相應的政策策略要求。中央性質的比如中央人民銀行(PBOC)，中國金融協(xié)會(CFA)，公安部。地方性質的比如PBOC的北京辦公室、上海辦公室，上海的浦東金融服務辦公室。作為四方（用戶=持卡人、線下/線上商戶、發(fā)卡機構、收單機構）模式中的角色，是難免和這些部門進行打交道。當然，更多的時候是法務部門去進行接洽，以及傳達相應的政策。但實際上的安全合規(guī)只能由技術中心互相協(xié)作完成。 無論是CFA的支付業(yè)務的支付持牌認證，還是接入銀聯(lián)的UPDSS認證，亦或者是比較通用的等保認證(MIPS)，以及一些網(wǎng)警的臨檢，或者是央行新發(fā)的第X號令，都是無法避免的的工作量。

以業(yè)務的視角來看，數(shù)據(jù)的分類分級和數(shù)據(jù)移動（包含傳輸）在此處顯得尤為重要（因為大部分時間下，業(yè)務方關注的是方案“可用”，但不關注背后的實現(xiàn)是否“可行”，最常見的是關注如何獲取數(shù)據(jù)，而非數(shù)據(jù)怎么存儲的）。那么針對數(shù)據(jù)的分類分級是由法務部門來做呢？還是安全合規(guī)部門來做呢？又怎么樣設計流程化的約束，和行為的審計去滿足數(shù)據(jù)移動過程的安全要求呢？簡單舉例，如何安全的提供持卡人人臉識別信息給到一些部門做身份驗證？如何通過流程獲取接入機構的數(shù)字證書？如何定期的同步政要信息（已公開的）？如何驗證投訴用戶的個人信息？如何提取一定時間內用戶的賬單？商用密碼的要求、網(wǎng)絡IPv6的改造等等。都需要能夠針對已有業(yè)務進行梳理，不僅包含于生產上的業(yè)務，還包含安全部門對外提供的業(yè)務。

2.2 應用視角

大的趨勢是往云原生在走，對應服務網(wǎng)格的概念也有同行提出了安全切面。應用和服務是業(yè)務的最直觀體現(xiàn)，用代碼承載了業(yè)務流程，用IT基礎設施存儲了業(yè)務數(shù)據(jù)。簡單的來看，是用戶發(fā)起了請求，應用進行了響應。而實際的應用可能部署在不同的數(shù)據(jù)中心，不同的安全域內。不同應用下的不同服務也在進行著調用。畫了一個簡單的圖來表面應用視角下數(shù)據(jù)的流向。

以應用視角來看，在應用生命周期內，鑒權和加解密是至關重要的一項。全鏈路TLS，不僅需要從client到application，還需要service之間進行加密傳輸。怎么設計CA，怎么使用證書，需要明確哪些policy，傳輸過程需要支持相應的TLS Cipher Suite， Version， Algorithoms等等。又需要明確哪些啟用國密算法。除去業(yè)務應用之外，基礎服務例如APM， Logging數(shù)據(jù)等又該如何存儲，這些服務了服務的服務(為應用提供基礎服務的Service），自身是否實現(xiàn)了同一個安全等級的要求？在不同Zone間交互的ACL策略又能否遵循最小化原則？加解密服務是否做了權限控制？如果再回到SDLC中去，那么是否存在可能的越權（或其他）漏洞，使得在應用中解密了相應的加密數(shù)據(jù)， 源碼是否泄漏到公開的托管網(wǎng)站？會不會存在針對掃描服務器的白名單“陷阱”。回到線上的話，又有多少惡意流量被清洗掉，無論是四層還是七層。當然這些似乎已經脫離了數(shù)據(jù)安全，實際并不然。正如前文所述，均為互相依賴。是不是可以在流量清洗時補充相關的風控數(shù)據(jù)？更新的feed源是不是有可能被污染？諸如此類不勝枚舉。

所以在關注應用的時候，還需要關注承載應用的基礎設施，以及網(wǎng)絡流量的清洗，和應用本身的代碼相關。并不是說堆了多少設備，買了多少服務就能夠解決問題的。

2.3 數(shù)據(jù)視角

談完了應用視角和業(yè)務視角。終于回歸到了數(shù)據(jù)本身。數(shù)據(jù)視角的處理方式，最根本最直接的就是對不同類型的數(shù)據(jù)提供安全存儲（加解密）的同時能夠在可審計的授權下確保數(shù)據(jù)轉移過程中的一致性。當然可以跳過這句話去看看DSMM之類，之所以在此時才提到DSMM，是因為DSMM模型本身缺乏在業(yè)務和應用上的框架約束。當然更深入的應該還是讀書和實踐。簡單舉例來說，在數(shù)據(jù)安全工作中，涉及到的有用戶數(shù)據(jù)，不僅出現(xiàn)在流量中，還出現(xiàn)在日志中了，數(shù)據(jù)庫中。在不同的位置，數(shù)據(jù)在什么時候是明文的，又有什么時候是加密的？什么場景下取什么數(shù)據(jù)都是需要根據(jù)相應的策略和約束進行的。除此之外，在考慮到數(shù)據(jù)等級和數(shù)據(jù)類別的同時，還需要考慮到是不是這個數(shù)據(jù)能在這里獲取/打開，是不是能夠存儲。例如針對持卡人數(shù)據(jù)是不是能存儲在本地，是不是能出境等等都需要考慮。在針對靜態(tài)數(shù)據(jù)的加密，動態(tài)數(shù)據(jù)的分類掃描以及相應的權限管理等安全控制之后，還有一項必要措施就是針對所有的行為進行審計。而所有的審計日志，無論是數(shù)據(jù)庫審計還是DAL層，亦或者是針對不同設備的常見的操作日志。都應該推送到集中的日志集群。冷熱分離，計算分析。同樣在這個過程中有哪些場景需要針對敏感數(shù)據(jù)的脫敏？

在數(shù)據(jù)視角上還是需要回歸到數(shù)據(jù)本身，豐富數(shù)據(jù)的屬性，關注數(shù)據(jù)的流動以及相應的流程制度。那談完了數(shù)據(jù)安全的基礎架構之后，我們可以看看怎么在基礎架構上做相應的運營管理。

3. 數(shù)據(jù)安全的運營管理

上面在基礎治理方面做好了運維部署，產品的運營管理之外，最主要的是對外提供服務的運營部分。一般來說體系的建設離不開標準的制定和專項的服務。而大多數(shù)時候，提供技術運營占據(jù)了工作的大頭。但細看一下，可以分為三類，一種是技術咨詢，一種是合規(guī)審計，最后一類專項服務才是技術運營。至于標準的制定，往往是管理者進行，當然也不乏許多一線工程師進行編寫然后逐級批準的案例。(最好還是專項的manager負責或者資深的技術專家)

1 策略 就策略而言，準確的來說是策略-標準-流程-指南的一個過程，策略告訴了你why，標準告訴了你what，流程告訴了how，而指南就是step by step.

2 協(xié)作 協(xié)作是至關重要的，本來我是抽出來放到了策略流程里。但是后來想了下這些約定似乎并沒有明確的流程規(guī)定。例如，規(guī)范統(tǒng)一的接口團隊和接口人。

3 咨詢 咨詢是一項繁復又考驗自控力的工作，就像運營工作中難免遇到一些傻傻的問題，那我們應該撒氣或者生悶氣嗎，顯然不必要的。這也是極為考研提供咨詢答疑之類support角色的心理。下面提到的專項中的合規(guī)審計其實也有很大一部分是咨詢的工作。但是對于很多企業(yè)并不會單獨為該項服務設立單獨的角色。

4 專項 具體可以做的一些基礎工作可以參考之前寫的一篇文章?淺談數(shù)據(jù)安全?，當然這篇文章也并不是列出了全部。下面也就簡單舉例一二。（由于每一項都需要有系統(tǒng)的基礎運維日志收集監(jiān)控等，因此暫時不列在下面了）

有一點值得一提的是，對外提供服務運營涉及到數(shù)據(jù)安全部分的工作需要有留存的審批流程，以及相應的審計日志。同時在完成對應操作之前需要確保背后的解決方案是否可行。不過在運營階段很多時候技術架構師已經確認的了。簡單舉例來說，有一個被approve的數(shù)據(jù)移動請求，如果是第一次接觸則需要背后的技術架構是否允許相應的動作，為什么移動，移動到哪，移動的數(shù)據(jù)級別。否則僅是流程允許是不可以的。假設獲取的是高敏感數(shù)據(jù)，同時不允許在某些設備上存儲或獲取，那原有的方案就需要調整。

4. 數(shù)據(jù)安全的產品自研

在企業(yè)安全的成熟度模型里，很少有企業(yè)能夠發(fā)展到安全產品自研階段，更不要提數(shù)據(jù)安全產品了。能喊得上來的也屈指可數(shù)。由于我本人只寫過一些小工具，并沒有參與研發(fā)過工程化的企業(yè)級安全產品中去，因此僅就觀察到的一些經驗加以闡述。在數(shù)據(jù)安全產品自研的過程中，或者說在安全產品的自研過程中。絕大部分是為了解決企業(yè)內部場景的適應性問題。這些產品具有商業(yè)化產品的類似功能，但又能適應場景。比如拿KMS來說，外部的KMS可能無法很好的集成到現(xiàn)有的基礎設施中去，無法使自有的腳手架代碼快速Build。亦或者HSM，如果沒錢買HSM，那么Softhsm就成了一個可選項，配合著TPM對自有的加密服務進行集成。亦或者是加密即服務，結合HSM做根密鑰管理，KMS做密鑰管理，提供對應用服務的加密服務，亦或者是數(shù)據(jù)庫審計服務，日志分析等等。亦或者內部的自助服務，比如自助證書申請，數(shù)據(jù)分類分級工具。這里面的一個關鍵問題就是工程化問題，很多時候安全工程師能夠給出原型代碼，但大多數(shù)不是工程化的代碼，不能提供出來性能功能兼?zhèn)涞漠a品。當然這并不是絕對的，還是有很多優(yōu)秀的工程師可以以一己之力完成。不過互相配合豈不更好。

在企業(yè)中很多時候在自研安全產品上，必須給出足夠的說服力，否則老板會想我已經花了2kw買產品，你為什么又要招安全研發(fā)工程師呢？而向上闡述安全的價值，自我了解到的現(xiàn)狀看來，絕非易事。

5. 后記

不同于基礎安全的High risk， 應用安全的High threat，數(shù)據(jù)安全本身的特性更加偏向于High Value. 這也意味著數(shù)據(jù)安全工程師需要投入更多的精力，但是這些工作又絕非孤立能夠完成的，必須要聯(lián)合起其他方向的安全工程師一起努力，持續(xù)運營。