《微軟資深工程師：聊聊合規(guī)要求對系統(tǒng)設(shè)計的影響》要點(diǎn)：
本文介紹了微軟資深工程師：聊聊合規(guī)要求對系統(tǒng)設(shè)計的影響，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者:虞雷

編輯:Gary

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

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

部分工程師可能覺得這個話題和技術(shù)設(shè)計沒有最直接的關(guān)系,不會對系統(tǒng)架構(gòu)產(chǎn)生特別大的影響,而更多的是公司市場或者法律團(tuán)隊要操心的問題.但事實(shí)上因?yàn)楹弦?guī)要求所帶來的需求會在很多方面影響到系統(tǒng)設(shè)計.

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

盡管不同國家和地區(qū),不同行業(yè),有不同的規(guī)范,但就一般商業(yè)軟件和云計算平臺而言,仍然有一些方法和實(shí)踐是可以通用的.在適當(dāng)?shù)那闆r下借鑒這些經(jīng)驗(yàn)可以很大程度上規(guī)避由于合規(guī)性帶來的風(fēng)險和額外工作量.在大型系統(tǒng)設(shè)計的初期,尤其企業(yè)級應(yīng)用,應(yīng)盡早把合規(guī)納入設(shè)計的考慮問題之列.一些針對個人用戶的網(wǎng)站,因?yàn)樯婕暗浇鹑诤椭Ц兜墓δ?也可以考慮參考一些類似的設(shè)計理念和注意事項,同樣做到對個人客戶負(fù)責(zé).在這里我根據(jù)自己多年的行業(yè)經(jīng)驗(yàn),和各位簡單聊一聊這個不是那么有趣,可能稍稍有點(diǎn)嚴(yán)肅的技術(shù)話題.

用戶身份認(rèn)證

談合規(guī)性首先要談到安全和身份認(rèn)證.對于現(xiàn)代互聯(lián)網(wǎng)和軟件應(yīng)用來說,基于 web 的用戶認(rèn)證方式是每個系統(tǒng)設(shè)計要解決的首要問題.云計算平臺的提供商,尤其是 PaaS 層,往往是認(rèn)證方式的實(shí)現(xiàn)者,需要提供完善和健壯的用戶認(rèn)證解決方案.

明文密碼和 token

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

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

Multi-Factor Authentication

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

對于認(rèn)證方式的提供者來說,在系統(tǒng)設(shè)計時候?qū)⒏鞣N物理認(rèn)證方式的抽象化就顯得比較關(guān)鍵,易于從基本的用戶名密碼擴(kuò)展到其他認(rèn)證方式.

URL 中的信息

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

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

個人可識別信息

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

ID 影射

前面的例子提到,使用用戶自己創(chuàng)建的用戶名,或者填寫的電子郵件,手機(jī)號等來作為系統(tǒng)內(nèi)部使用的唯一標(biāo)識在很多情況下并不是理想的選擇.一方面這類型的 ID 是可更改的,甚至是可以重復(fù)的,另一方面這些 ID 本身就很容易關(guān)聯(lián)到用戶的真實(shí)身份,無法滿足合規(guī)性的需求.

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

新用戶創(chuàng)建以后,系統(tǒng)應(yīng)該分配不可人為識別的用戶標(biāo)識,比如 UUID 或者 sequence number 等,然后系統(tǒng)內(nèi)部邏輯應(yīng)該圍繞其進(jìn)行設(shè)計.這樣的標(biāo)識因?yàn)椴荒苤苯雨P(guān)聯(lián)用戶,需要通過某種可控的查找過程才能映射到可以識別用戶身份的信息,所以不屬于 PII 的類型.開發(fā)人員在使用此類型標(biāo)識時候就有更靈活的空間.

診斷工具和系統(tǒng)日志

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

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

通常情況下系統(tǒng)日志(log)里面很容易包含 PII 信息,因?yàn)殚_發(fā)人員希望能夠盡可能詳細(xì)記錄用戶請求的細(xì)節(jié),讓診斷工作和基于日志的數(shù)據(jù)分析變得容易.但大多數(shù)情況下一個系統(tǒng)的日志來自很多不同組件,而大多數(shù)日志在生成和轉(zhuǎn)移過程中都是可以被負(fù)責(zé)運(yùn)維的工程師直接獲得的,這樣就需要進(jìn)行 PII 清洗.最嚴(yán)格的規(guī)定要求在日志生成的時候就進(jìn)行 PII 清洗.可以想象,在設(shè)計日志子系統(tǒng)時,如果用的是有 schema 的 log 格式,就有可能需要 metadata 來標(biāo)記一個字?jǐn)嗍欠駥儆?PII.

部署和運(yùn)維

經(jīng)?？梢月牭巾椖拷M在討論一個新的微服務(wù)應(yīng)該在哪里運(yùn)行,或者一些相對較小的數(shù)據(jù)可以存放在哪里,能不能使用 Azure 和 AWS 上的那些大家熟知的 PaaS 服務(wù),如果可以用的話怎樣用.比較有經(jīng)驗(yàn)的工程師應(yīng)該能馬上根據(jù)服務(wù)和數(shù)據(jù)的類型來作出判斷.元數(shù)據(jù)、配置數(shù)據(jù)、用戶畫像數(shù)據(jù)、用戶核心數(shù)據(jù)等都是不同的數(shù)據(jù)類型,按照商業(yè)價值級別還可分為 LBI、MBI 和 HBI.

代碼安全

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

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

團(tuán)隊?wèi)?yīng)該對最終交付代碼的權(quán)限有清晰的管理制度,避免單個工程師可以對系統(tǒng)作較大的改動,并且盡量使用自動化工具來進(jìn)行管控.需要指出的是,這樣做的目的并非不信任團(tuán)隊成員,而是為了達(dá)到合規(guī)要求,獲得相關(guān)認(rèn)證所需要實(shí)施的舉措.

權(quán)限提升

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

數(shù)據(jù)備份和保留

備份和容災(zāi)

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

Document Retention

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

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

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

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

作者介紹

虞雷 (Jason Yu), 微軟 Office 365 Core 部門首席軟件工程師,在生態(tài)系統(tǒng)項目組主要負(fù)責(zé) Connectors,Actionable Message 和 Bots 等項目的架構(gòu)設(shè)計.https://www.linkedin.com/in/zeromemory

文章來自微信公眾號：聊聊架構(gòu)

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4147.html