《微軟資深工程師：聊聊合規要求對系統設計的影響》要點：
本文介紹了微軟資深工程師：聊聊合規要求對系統設計的影響，希望對您有用。如果有疑問，可以聯系我們。

作者:虞雷

編輯:Gary

Compliance,中文通常翻譯為合規性,是軟件和云計算領域頻繁提到的一個概念.在很多國家和地區,一些特定行業和政府部門,對使用的 IT 設施,軟件和服務都制定了各種基于數據安全考慮的規范.我們有時候聽到一些術語,比如信息安全等級,可信云認證、FISMA、HIPAA、DPD 和最新的 GDPR 等都是與合規性相關的.

作為云計算平臺或者通用軟件服務的提供商,在開發和運維過程中不同的應用場景都不可避免的涉及到合規的問題.國內云計算的主要玩家,阿里巴巴、騰訊和華為,近年來開始向國際市場進軍,隨之遇到的合規問題會顯得更加復雜.而國內市場本身,隨著 IT 和互聯網環境的日趨成熟,外加政府云項目的推廣,合規性的相關問題也會更加突出.

部分工程師可能覺得這個話題和技術設計沒有最直接的關系,不會對系統架構產生特別大的影響,而更多的是公司市場或者法律團隊要操心的問題.但事實上因為合規要求所帶來的需求會在很多方面影響到系統設計.

舉個例子,一些系統中直接使用用戶名來作為用戶的唯一標識,在內部邏輯中也沒有將用戶名映射到其他的 ID 或者 hash.在生成一個和某用戶關聯的 URL 給第三方使用的時候,由于應用場景對 PII 的規定用戶名不能被泄露,所以就必須采取額外措施對用戶名進行加密等處理.而加密常常涉及到密鑰的管理、部署和更迭,無形當中就增加了開發和運維的工作量,同時還影響了運行效率.

盡管不同國家和地區,不同行業,有不同的規范,但就一般商業軟件和云計算平臺而言,仍然有一些方法和實踐是可以通用的.在適當的情況下借鑒這些經驗可以很大程度上規避由于合規性帶來的風險和額外工作量.在大型系統設計的初期,尤其企業級應用,應盡早把合規納入設計的考慮問題之列.一些針對個人用戶的網站,因為涉及到金融和支付的功能,也可以考慮參考一些類似的設計理念和注意事項,同樣做到對個人客戶負責.在這里我根據自己多年的行業經驗,和各位簡單聊一聊這個不是那么有趣,可能稍稍有點嚴肅的技術話題.

用戶身份認證

談合規性首先要談到安全和身份認證.對于現代互聯網和軟件應用來說,基于 web 的用戶認證方式是每個系統設計要解決的首要問題.云計算平臺的提供商,尤其是 PaaS 層,往往是認證方式的實現者,需要提供完善和健壯的用戶認證解決方案.

明文密碼和 token

基于 web services 的 API 可以很簡單地實現 Basic Authentication,即客戶端用 HTTP 協議的 Authorization 頭(header)來發送 base64 編碼過的用戶名和密碼.因為 web services 大多數是無狀態的,所以基本上要求每個請求都包含用戶名和密碼.這樣的認證方式最簡單,但要求服務器端全程 SSL 加密.而且因為整個過程的所有請求都帶有密碼,所以密碼被泄露風險較高.舉個例子,如果負責運維的工程師用診斷工具看到了 Authorization 頭的內容,那么他就獲取了用戶的原始密碼.

很多應用場景禁止使用 Basic Auth,例如 PCI DSS 規范就要求使用基于 token 的用戶驗證方式.在 Authorization Server 和 Resource Server 分離的情況下,應盡量使用基于 OAuth 2.0 的模式來完成用戶認證,這樣避免用戶密碼在沒有必要的情況下被傳遞到 Resource Server 上去.

Multi-Factor Authentication

一些公司和組織由于業務數據的敏感性,規定終端用戶至少需要兩種以上的認證方式進行登陸.經常聽到的 FISMA 規范就有相關條款,要求組織職員和云服務提供商的運維人員都要遵守.除傳統密碼以外,電話,短信,USB 密鑰等都可以作為其他的認證方式.

對于認證方式的提供者來說,在系統設計時候將各種物理認證方式的抽象化就顯得比較關鍵,易于從基本的用戶名密碼擴展到其他認證方式.

URL 中的信息

URL 很容易被客戶端和服務器端的各個部件記錄下來,尤其各種 web server 和 proxy 的 log 基本都在記錄 URL,包括瀏覽器的歷史記錄.因此諸如用戶 access token 等敏感信息不建議使用 URL 來傳遞.即便 access token 會過期,在 TTL 內被泄露仍可能造成重大損失,例如被用來執行刪除操作. 對于 web services 和一些認證協議, Authorization 頭是比較推薦的 token 載體.

同樣的道理,在進行 web 界面認證流程的時候,應該盡量使用 POST 而不是 GET 來傳遞原始 access token.一些認證系統為此專門使用相對復雜的瀏覽器端 JavaScript POST 來代替簡單的 302 重定向,就是為了避免將 token 放在 URL 里.

個人可識別信息

前面的例子提到行業里經常使用的一個術語 Personally Identifiable Information,即個人可識別信息,簡稱 PII,相關術語還有 Linked PII、OII 等.很多條文規范,例如 HIPAA,對用戶的隱私和 PII 信息的保密做了相關規定.這類信息包括用戶名、姓名、電子郵件、電話等,從在大多數系統中雖然不是用戶核心數據,但仍然可以被挖掘和惡意使用,造成個人和企業的損失.

ID 影射

前面的例子提到,使用用戶自己創建的用戶名,或者填寫的電子郵件,手機號等來作為系統內部使用的唯一標識在很多情況下并不是理想的選擇.一方面這類型的 ID 是可更改的,甚至是可以重復的,另一方面這些 ID 本身就很容易關聯到用戶的真實身份,無法滿足合規性的需求.

大型分布式系統大多都有 shard 的概念,如果基于 web 的應用協議在一個相對扁平 URL 的反向代理之內,那么在進行多方 web 跳轉時候,有的系統設計可能需要借助用戶的 ID 來重新定位原先的 shard 和節點.這種情況下就需要保證所生成的回調 URL 中不能有可識別的用戶 PII 信息.

新用戶創建以后,系統應該分配不可人為識別的用戶標識,比如 UUID 或者 sequence number 等,然后系統內部邏輯應該圍繞其進行設計.這樣的標識因為不能直接關聯用戶,需要通過某種可控的查找過程才能映射到可以識別用戶身份的信息,所以不屬于 PII 的類型.開發人員在使用此類型標識時候就有更靈活的空間.

診斷工具和系統日志

在如今的云計算時代,運維和診斷的工作基本上是由開發人員負責的.這些工程師可能屬于 IaaS 和 PaaS 的云服務提供商,也可能屬于 SaaS 的提供商.對于開發和運維人員來說,獲取盡量多的用戶信息,會讓工作變得更加容易,但這其實與合規的要求是矛盾的.很多規范都不允許云服務提供商的工程師在默認情況下能直接接觸到客戶的 PII 信息.

如前面提到,如果系統使用不可識別的內部用戶 ID,那么工程師需要檢查用戶信息時候所依賴的工具也應使用該類型.根據一些條款,診斷工具在默認情況下應該將包含 PII 的返回字段進行清洗(scrub),例如加密或者亂序(scramble)到不可識別.當然,在需要的情況下,工程師還是可以通過申請臨時權限提升來關閉 PII 清洗功能,從而看到用戶的完整信息來幫助完成工作.另外在用戶身份已知的情況下,比如用戶提供了用戶名,一般情況下用工具作反向查找獲得用戶的內部系統 ID 是被允許的.

通常情況下系統日志(log)里面很容易包含 PII 信息,因為開發人員希望能夠盡可能詳細記錄用戶請求的細節,讓診斷工作和基于日志的數據分析變得容易.但大多數情況下一個系統的日志來自很多不同組件,而大多數日志在生成和轉移過程中都是可以被負責運維的工程師直接獲得的,這樣就需要進行 PII 清洗.最嚴格的規定要求在日志生成的時候就進行 PII 清洗.可以想象,在設計日志子系統時,如果用的是有 schema 的 log 格式,就有可能需要 metadata 來標記一個字斷是否屬于 PII.

部署和運維

經常可以聽到項目組在討論一個新的微服務應該在哪里運行,或者一些相對較小的數據可以存放在哪里,能不能使用 Azure 和 AWS 上的那些大家熟知的 PaaS 服務,如果可以用的話怎樣用.比較有經驗的工程師應該能馬上根據服務和數據的類型來作出判斷.元數據、配置數據、用戶畫像數據、用戶核心數據等都是不同的數據類型,按照商業價值級別還可分為 LBI、MBI 和 HBI.

代碼安全

這里指的代碼安全是指產品代碼在從源代碼控制工具(如 GitHub)到部署,再到運行的過程中,不會被個人更改和替換.一些產品的核心部分代碼要求使用帶有數字簽名的編譯文件來實現,防止被有 bin 目錄訪問權限的個人更改.值得一提的是,這種嚴格的要求甚至可能會對編程語言的選擇帶來影響.

一些初創型的互聯網公司,代碼交付和部署就是一個人手動搞定的事,輪到誰值班就誰來,被戲稱為牛仔式部署(cowboy deployment)方式.尤其在使用諸如 AWS Lambda 和 Azure Functions 等 serverless computing 方案的時候,甚至可以在控制臺里直接粘貼代碼上去.可以想象這種部署方式是不滿足合規要求的.

團隊應該對最終交付代碼的權限有清晰的管理制度,避免單個工程師可以對系統作較大的改動,并且盡量使用自動化工具來進行管控.需要指出的是,這樣做的目的并非不信任團隊成員,而是為了達到合規要求,獲得相關認證所需要實施的舉措.

權限提升

運維過程中不可避免地要更改配置,查看原始日志,連接到服務器終端,甚至有的時候需要更改用戶數據.這些對數據安全有影響,甚至危險的操作(例如前段時間的某網站誤刪數據庫),都應該按照一定的流程來管控.在運維人員申請權限提升時候,應該有相應的流程來審批和授權,工程師的操作也應該被記錄和 audit,臨時權限提升不應該超過四小時.

數據備份和保留

備份和容災

對于云服務的提供商來說,用戶數據的冗余存儲和跨地域備份是基本要求.不同的云服務客戶可能會根據自身需求和預算來選擇高可用性和數據備份的方案,但一些規范則對跨地域存儲和容災備份有明確規定,不符合規定的提供商無法參與競標. 另外需要注意的是,如果數據中心的地理位置跨國家和地區的話,在做跨地域設計時候,某些有合規要求的用戶數據不能隨便跨國家備份和 failover.

Document Retention

根據美國證監會(SEC)的 SOX 法案,上市公司的一些電子文檔需要保存三年,并且要在會計和審計的時候要能夠進行查詢和導出操作.事實上市場上很多企業電子郵件備份解決方案就是根據這個法案的要求誕生的.這也意味著一些公司員工在刪除電子郵件的時候其實并不能徹底刪除數據.除第三方開發的郵件和數據備份軟件外,像 Office 365 這樣的企業應用產品也自身集成了這些功能.另外法案中對各種類型的用戶文檔的保留時長做了比較詳細的規定,相應產品的功能設計也應該圍繞具體條款進行.

在以個人用戶數據為中心的系統中,關于備份的要求可能會影響基本存儲模型的選擇和設計.產生數據的企業應用,作為第一方,可以選擇將備份和保留的數據存在用戶的基本存儲單元和 shard 里,但必須有相對應的訪問控制模型來區分用戶可寫數據和系統數據,對用戶操作進行隔離,這樣保證用戶無法真正改寫和刪除數據.而第三方的備份產品,則可能需要復制相似的用戶目錄結構來存儲備份的數據,還要應對用戶變更和重命名的情況.

除了以上討論的幾點以外,合規性要求也會對云服務的基礎設施產生影響.微軟數據中心對壞硬盤的銷毀方式也根據數據價值級別有所區別,有的只要打孔,有的則需要把整個硬盤絞碎.除了上面討論的內容外,還有一些非技術的相關流程,比如 FISMA 中規定了手提電腦丟失的上報時間期限等.

本文只討論了合規性的一小部分內容,而且只涵蓋了那些基本適用大多數行業的方法和實踐.特定的行業還有大量特定的需求,會對系統的方方面面造成影響.總而言之,負責總體設計的工程師,應當和產品經理緊密溝通,嚴肅對待合規性的問題,從第一天就帶入設計的考量中,避免將來產生安全問題或者法律上的糾紛.

作者介紹

虞雷 (Jason Yu), 微軟 Office 365 Core 部門首席軟件工程師,在生態系統項目組主要負責 Connectors,Actionable Message 和 Bots 等項目的架構設計.https://www.linkedin.com/in/zeromemory

文章來自微信公眾號：聊聊架構

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4147.html