作者:虞雷

編輯: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

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