原創丨志剛（返町）

現任美團安全部安全架構師。曾在國內外知名大型網際網路公司出任安全專家、架構師等職。在應用系統安全架構評審以及安全方案設計和實施領域擁有豐富的經驗。

綜述

確定一個應用的安全狀況，最直接的方法就是安全評審。安全評審可以幫我們發現應用系統中的安全漏洞，也能瞭解當前系統，乃至整個防護體系中的不足。完整的安全評審會包含安全架構評審、安全程式碼稽核和安全測試三個手段。

安全架構評審，著眼於發現安全設計的漏洞，從宏觀的視角整體評價一個應用的安全性，快速識別業務系統核心安全需求以及當前安全防護機制是否滿足這些需求，是投入產出比最高的活動。因此安全架構評審，直接影響整個安全評審的質量，併為安全編碼和安全測試指明重點。

本文透過從方法論到實際模型，對安全架構評審過程進行闡述。不論你是安全從業人員對第三方應用系統進行安全評審，還是作為產品的研發人員、架構師，依據本文提到的方法深入學習、反覆實踐都能提高自己的架構評審能力。

那麼安全架構評審具體看什麼？ 什麼樣的安全評審是好的？ 是發現越多的漏洞？在解答這些問題之前，我們先簡單說一下什麼是好的安全架構設計。

理論篇：安全架構設計的特點

安全架構設計是指遵循安全設計的基本原則，在充分理解現有的業務和應用場景，並對面臨的攻擊威脅充分了解的前提下，正確的部署、使用安全控制技術以滿足保護資訊資產的安全需求。

安全設計的系統不會只著眼於眼前的攻擊和已知漏洞，還應該對未知的漏洞0day都具備一定的抵禦能力。安全架構評審著眼於設計缺陷，與常規的實現型漏洞存在區別。正本清源，筆者從安全設計基本原則、安全防護框架和安全防護技術棧三個維度說明什麼是好的安全架構設計。

遵循安全設計原則

安全設計基本原則是網路安全領域經過無數前輩經驗的總結，是安全防護理論的高度抽象。他告訴我們，在特定的場景下，什麼是正確的做法，為什麼這麼做。對這些基本的設計原則準確、深入理解，反覆在實際工作中實踐，是提高架構設計能力的必由之路。

• 縱深防禦

縱深防禦原則，多年以前就比較盛行，說是防禦體系第一原則不為過。具體定義可以參考Cisco的《網路安全架構》以及OWASP的相關定義。其核心思想就是不要依賴單一的防護機制，而要依賴互相補充的多層次、多方位和多角度機制來構建防禦體系。這樣既能實現防護的靈活性，又能做到防禦效果最大化。因為，不管任何一種防禦機制，都有其適用場景，也有其侷限。這種侷限可以表現為其防護的粒度和範圍、對使用者的應用和業務的影響以及防護成本，或者運維、效率或者效能方面影響等等。

縱深防禦體系可以是按照物理-應用不同層級、物理位置不同控制點、外圍還是內建、防護時機和階段等維度部署。良好的部署縱深防禦體系，可以保證在一種防護失效時，攻擊不輕易得手，或者在部分得手後，損失可控。好的縱深防禦系統建設可以給管理者以足夠的信心和心理穩定性。

要建立好縱深防禦體系，前提是必須對各種防禦手段有深入的理解。需要每種防禦在其特定的成熟度和指標上能給人以足夠的信心，並不是說大家都一鍋粥或者認為有了縱深防禦，某一部分就可以不做，或者降低要求。我們看到，像Google的縱深防禦在每一個細分層次都做到合格乃至極致。即使像Amazon這樣業務驅動的公司，也會在每一個環節做到確認和心中有數。

•  最小許可權

這是一個大家都公認正確，但絕大多數都沒有做到的原則。因為從字面上似乎更傾向於管理而非技術手段能實現的。造成這種誤解的原因很多，其中主要因素是大家對許可權控制還停留在傳統的中央集權，人肉申請、審批的認知。隨著微服務和DevOps等新框架發展，新型公司在業務上對效率的訴求，使得這種模式不被新興公司接受。實現最小許可權也越來越難。不過隨著新一代的許可權控制模型ABAC，及與之配套的如Oauth、Federation等控制技術的發展，並在Google、Amazon等大廠的落地，實現分散式、自助或半自動細粒度許可權控制成為可能。另外說一句，能否實現最小許可權，往往是對一個公司對安全努力程度，以及對應的技術水平的試金石。

•  預設安全

人是不可靠的，我們更相信機器。預設安全的基本原則就是，讓安全一開始就成為內建的屬性。如果需要對策略進行放鬆，你需要額外的工作和努力。這在當下DevOps和微服務架構，處理海量資料、賬戶以及主機、應用系統場景下尤為重要。因為一個帶有漏洞的容器映象釋出出去，可能就意味著幾萬乃至幾十萬的主機存在漏洞的副本。預設安全需要大量額外的工作，但這些工作又絕對是值得的。說白了，預設安全更像是一種文化，能給你一個可信的基礎架構。

•  註定失效

這個原則是與縱深防禦有關聯。在設計安全系統時，需要考慮到你的防護註定會失效，並充分考慮並演練不同的失效場景，確保你的安全性在失效時依然能夠得到保證。這點除了透過按縱深防禦原則部署你的防控機制外，每個系統事先設計、反覆演練失效時的應急預案至關重要。其中保證系統可用性的降級方案，不能犧牲安全性是首先需要考慮的。

•  適用性原則

為了避免安全功能喧賓奪主，你的安全方案設計需要考慮業務生產的實際需要。說到底，安全還是為業務服務的。但注意一點，安全註定要提高成本。然而好的安全性設計，以及應用適當的技術，是能夠有效降低這種成本，這也就體現了安全專家的價值。所以，安全要有助於業務，但不是完全為業務讓路不作為。另外，有些安全特性本身就是業務，比如隱私、資料保護，本身也是為使用者提供保護，提振使用者的信心。要想做到適用性，安全專家要充分理解業務和業務所採用的技術，不斷學習，與時俱進。這雖然讓安全專家這個職業非常具有挑戰，但也讓安全專家更具有價值和不可替代性。

•  開放性設計

簡單說就是不要自創演算法。尤其是像加密、認證等關鍵的安全方案。這裡不是說不能創新。外面的演算法和實現都已經很成熟，並經歷過無數研究、測試。而你自己的東西很大機率沒有這方面的積累。當然像Google等頂級公司除外，因為他們可以投入各種專業資源對他們的方案進行驗證、測試，而且他們也把一部分開放出來讓大家一起驗證。即便如此，對於一般的公司，一定不要自創演算法。如果真的自創了，那也要經過各種專業的評審、測試。

安全防護的三大支柱

上文所提到的安全原則，最重要的抓手就是安全控制技術，筆者定義為安全武器庫。熟悉並構建一套完整、先進強大的武器庫是實現良好的安全架構設計的基礎。當前有很多框架包括CIS Top20 Controls、OWASP 以及NIST關鍵基礎設施安全框架都給我們列出了控制技術清單。針對安全控制清單，筆者會在後面的章節進一步進行說明。需要說明的是簡單的羅列這些技術不是重點，重要的是我們需要準確的評估這些控制技術，並在應用系統，乃至整個企業的場景正確的運用適當控制手段。要想做到這一點，我們需要一套評價體系，對某一特定控制領域的控制技術成熟度進行度量。筆者經過多年安全架構評審和安全體系建設的經驗，推薦本章的三大支柱框架。這個框架是筆者的導師，Amazon前首席安全架構師Jesper博士提出的，廣泛運用於Amazon內部安全專案、安全架構評審。筆者也在近些年反覆實踐，融入了自己的理解。這個框架可以透過下圖進行說明：

防禦與保健

這根柱子主要是功能是防控，簡稱事前。部署好這類安全措施，會防止安全攻擊、事件的發生，防患於未然。典型的防護包括防火牆和網路隔離、認證和許可權控制、加密等。此外預設安全映象，標準化配置以及補丁修復，屬於清潔保健（hygiene）範疇。這部分是預設安全原則的集中體現。這種防護的效果直接，給防禦者最強的信心。但這種方法也是對業務影響最大的：包括業務需要更多的流程，更精細化的訪問控制；運維，使用中犧牲一定的便利性和時效性以及安全特性引起額外的工作負載需要更多系統資源，同時導致效能和效率的下降等等。該類控制往往適應成熟度比較高，規則比較清晰的場景。對於靈活度高，動態變化的業務系統，在規則設計中要做到一定平衡。注意，由於其對業務的“負面”影響，又不會看到直接的收益（這部分收益只有做得不好時才會顯現出來，例如Facebook今年的使用者洩漏事件等等）。這部分需要有安全部門領銜，獲得高層的支援，自上而下進行推動。

監控和響應

對於快速成長的業務、系統業務邏輯複雜且變化快，安全策略不清晰，防控會大大制約業務的敏捷度、增加運維成本。此時監控將是好的補充。日誌、告警和風控系統都屬於這個範疇。這類防護的質量主要體現在日誌的覆蓋率以及告警的響應速度和準確程度。隨著大資料和AI技術發展，這類系統在防護體系中作用越來越凸顯。

恢復和止損

再安全的系統，安全事件也不可避免。但透過精心的安全設計，你應該能保證，當單點或者部分防護被攻破時，攻擊造成的損失依然可控。例如在加密系統中，按照時間和空間對金鑰進行輪換，保證當部分金鑰洩漏時只會影響部分資料。或者對賬戶許可權進行細粒度限制，當賬戶洩漏時，只能影響到部分功能和資料。此外支援SDN的網路隔離機制，無伺服器化或者容器化等技術發展，你下掉、隔離被汙染的系統、服務的速度和能力，也直接影響你的恢復止損的能力。

注意，很多防護技術可能會跨多個領域，如防火牆、認證系統都可以設定成混雜模式。依據縱深防禦的原則，你的防護體系設計應該是多重防護並存的。從上圖我們看到，越往左，越可控，限制也越大也需要更多的努力；越往右，越靈活，也越混亂。隨著業務和安全防護成熟度的提高，應該越發靠近事前防控，事後救火應該越來越少。隨著新業務、新特性的引入，這種狀態又會發生變化。一個安全系統成熟度越高，表現就在事前防禦的比重越大。在評價特定領域特定安全控制技術時，你要清楚評估你的應用和企業當前成熟度水平，這個粒度可以細到具體的每一個細分控制技術或者某一個具體的應用系統。同時針對所面臨的風險以及企業的業務需要和企業文化，老闆對安全的投入等因素，選擇適當的方案。

安全控制技術武器庫

這裡羅列了一些常規的安全控制技術，在關鍵的信任邊界適當的選擇這些技術，就能落實應用的安全目標。武器可以自己生產，也可以採購。二者都需要對這些武器具有深入的研究。對應的技術有比較成熟的方案，也有基於新的技術演進。每種技術都有其適用場景，也有自身的缺陷。要想設計出合適的方案，需要在各個領域投入精力研究，並保持與時俱進，知其然還要知其所以然。安全架構評審會幫你發現問題，但這只是安全建設的開始，重點在如何透過可複用的技術解決你的問題。因為每個領域都非常複雜，這裡就不展開討論了，感興趣的同學可以查詢對應領域的專業文獻、書籍。

• 認證和訪問控制：如IAM、會話管理，都屬於這一類，是最直接建立網路世界信任的一種機制。原則上，任何跨邊界的訪問，都需要認證和許可權控制。這裡又涉及到人機之間的UI和機器間的服務呼叫兩類訪問的控制。

• 加密：加密是除認證之外資料保護的又一利器，包括傳輸加密和儲存加密。加密方案具有複雜度高、實現難度大、業務影響深的特點。因此加密方案必須精心設計，建議採用外部已經成熟的方案，如TLS/https、KMS/HSM等。此外，加密還是其他防護技術的基礎：認證憑據密碼、會話ID的建立，儲存都需要密碼學介入。密碼學就提一點，千萬別自創演算法。

•  日誌、審計和風控：這塊主要屬於事中和事後範疇。當下一般企業都有自建日誌中心，資料處理能力也都能上升到PB級別。日誌能否覆蓋所有的訪問入口，能否針對異常行為觸發告警是一個核心的能力。

• 網路隔離：傳統的網路防火牆以及主機防火牆，或者網路ACL，這類因為業務無關性，控制效果非常好，但也非常複雜，維護成本高，加上對縱深防禦，以及零信任網路理解的偏差，導致很多網際網路公司把防火牆邊緣化。近年出現的SDN技術，可以透過軟體自動對訪問規則進行定義編排，實現ACL自助化的趨勢，讓防火牆又能夠產生更好的效果。

實踐篇：實施安全架構評審

上篇介紹了安全架構設計的通用原則和方法，這是安全架構評審的理論基礎。那麼針對一個具體的應用系統面臨了哪些威脅，在何處部署哪種防護機制，防護的完整性和強度是否到位，這就是安全架構評審需要回答的問題。本篇為大家介紹安全架構評審模型，是基於微軟SDL、威脅建模模型進行了改造，更簡單、實用，適合微服務、DevOps等高效開發、快速迭代的模式。

該模型的主要流程可以透過下面一張圖說明。

安全架構評審的產出主要包含下面幾個檔案：

安全需求分析

安全架構評審說白了就是看安全需求是否得到滿足。理想情況，安全需求應該作為非功能需求在應用開發早期提出，並在應用設計和實現中得到實現。然而，絕大多數應用就沒有做過安全需求。所以評估初期需要進行安全需求分析，並落在紙面上。後面安全生命週期都會圍繞安全需求展開，並且隨著評估過程推進，安全需求也會不斷更新。安全需求主要包括：

安全目標綜述

依據應用的核心功能，對應用的整體安全目標進行描述，說明應用處理的關鍵資產，這些資產面臨的風險以及安全防護的要求。安全需求描述例子：系統儲存的使用者姓名、手機號等個人資訊，在儲存、傳輸過程中必須得到保護，一旦防護失效，導致大批次洩漏會直接影響使用者資產乃至導致公司聲譽、業務收到嚴重影響；資料庫root許可權一旦洩漏，將導致所有資料洩漏，或者被刪除。

通用安全需求

基於安全策略和安全最佳實踐結合業務特點，對通用防護措施的要求包括資料加密和保護要求、身份認證、會話管理、許可權控制、日誌和審計以及網路隔離等方面的控制要求。

常規的安全需求包括：

• 身份認證的安全需求
• 會話安全需求
• 許可權控制安全需求
• 日誌審計安全需求
• 資料加密安全需求
• 網路以及其他隔離安全需求
• 基礎設施安全需求
• 安全編碼相關需求

關於安全需求業界有很多現成的庫可以作為參考。筆者比較推薦的是OWASP的ASVS以及各種安全防護專案主頁。OWASP基本涵蓋了web應用和常規的安全需求內容。此外還有對應不同型別系統的安全配置標準如NIST和CIS的作業系統、資料庫等。雖然外界的權威的參考很多，筆者認為都需要深入研究，需要依據公司的業務特徵以及現有的安全方案，形成適合自己的安全需求清單，也叫安全基線。

架構review

架構評審主要目的是準確、詳細的還原應用系統的原貌。我們的方法是透過幾張圖，對整個應用的元件進行分解，展現互相之間的訪問關係。建議安全評審人員參考應用原來的文件，結合訪談，必要時透過檢視業務程式碼、實測，自己畫出產品的架構圖。系統的架構圖是否準確、完整，直接會影響到評審的質量。

首先要有一個整體的架構圖，具體的架構圖可以依據應用的複雜度分層次給出。以下給出圖的樣本供大家參考。

邏輯架構圖

以服務為粒度畫出應用的內外部元件以及相互間的訪問關係。對於複雜的系統還要給出更深層次的詳細架構圖，可以細到微服務，或者單個叢集的單個主機，包含所有的中介軟體如負載均衡、訊息佇列等。

元件說明：

應用場景的資料流圖

注意，應用場景要儘量全，不僅要涉及日常使用場景，還需要覆蓋從服務註冊、接入到使用乃至登出變更等生命週期的所有場景都覆蓋。（注：可以透過審查系統日誌、配置等資訊進行確認）。

下圖是筆者依據Oauth2服務委託場景的一個資料流圖。圖中每個訪問資料流都進行了標記和說明。你也可以把說明放在圖後面列出，這樣圖更簡潔。

這是Oauth2 的典型場景，部件先描述一下：

1. Resource Owner： 資源所有者，實際上就是使用者，屬於許可權委託方；

2. User Agent： 使用者端裝置的應用程式，如瀏覽器，或者手機的App，也有類似於微信小程式的東東；

3. Client：前端應用，接受使用者的一手請求，並要受使用者resource owner的委託，代替使用者訪問其他服務中的屬於使用者的資源，包括資料資源；

4. Resource Server： 實際儲存並提供資料資源的後臺應用，他無法和使用者直接接觸，需要一定途徑驗證使用者的委託行為： 誰Resource owner，委託誰Client 訪問什麼？這裡注意，Oauth 只負責可靠的驗證委託關係，但Resource owner 是否具有資料的訪問許可權，並不負責，這個User - resource 的mapping關係，需要許可權控制系統完成。這是我們另外一個專案鑑權服務；

5. Authorization Server： Oauth的核心服務，實現委託申請、驗證、發牌、驗牌的全過程。

識別關鍵技術

除了畫出架構和資料流圖，還要列出系統各個元件使用的技術、模組，包括但不侷限於作業系統、資料庫和其他中介軟體儲存元件，給出技術清單。對於內部依賴的元件，要求必須經過評審；對於外部元件，要求必須進行過掃描和安全配置評審，確保沒有漏洞。

識別關鍵資產

形成系統處理的資料清單，並明確它的生成、傳輸、儲存是否加密，訪問控制是否到位。明確這些資料的密級，以及保護需求。這裡要注意，除了業務資料、訪問系統的密碼、加密的金鑰等資料憑證需要作為最核心的資產首先要標示出來。

形成應用的資產清單，從域名、微服務ID、主機叢集、IP地址，域名，使用的各種元件清單。

此外，還包括應用的研發、專案資源，如程式碼倉庫，製品庫，系統映象。

安全防護配置記錄

要深入理解當前安全防護的設計和實現機制。這部分需要安全專家詳細評審，並依據安全需求進行一一確認。

主要審查以下幾項： 安全防護機制是否覆蓋所有的訪問入口和資源？防護技術採用的演算法和具體實現是否存在缺陷？是否有明確的安全策略，配置是否進行過審計？尤其要注意自創的演算法和實現方案，往往容易出現漏洞。

具體的防護機制需要採集的資訊有：

• 認證系統相關資訊
• 許可權控制系統相關資訊
•  加密方案以及實現機制
• 包括密碼和憑據的生成，儲存方案
• 業務敏感資料的儲存加密方案
• 傳輸通道的加密方案
• 日誌審計和監控方案
• 網路隔離方案

攻擊面分析和威脅建模

安全架構分析的核心，就是威脅建模。威脅建模是微軟2000年左右，作為SDL的核心模組提出並實踐的安全架構分析方法。微軟當初本想一統軟體安全方法論，威脅建模一度成為事實的標準。即使在今天，威脅建模依然是安全領域的主要架構評估方法。

但SDL兩個問題制約了它的發展：第一個是太重了，流程化的東西太過繁瑣、僵化。面對微服務、DevOps等小、快、零的開發模式明顯頭重腳輕，無法整合到產品的流水線當中；第二是太追求傻瓜化，和微軟其他軟體理念一樣，希望教給一個小白都可以完成安全評審，忽略了安全系統中的複雜性和專業性。

筆者針對網際網路公司微服務化，快速迭代等特徵，對SDL和威脅建模進行了一定的簡化，保留和其核心的攻擊面分析以及威脅列表部分元素。威脅建模過程主要分攻擊面分析（過程）和威脅列表（結果）兩部分。

攻擊面分析

就像大廈只有入口才會部署門禁和保安一樣。數字世界也有牆，也有門。你需要的是識別這些牆和入口。簡單來說，信任邊界就是數字世界的牆。而Web UI訪問介面如API、RPC等網路訪問入口就是數字世界的門。識別信任邊界和訪問入口就是攻擊面分析的核心內容。

識別信任邊界

常用的信任邊界有哪些？

• 網路邊界：常用的有Internet、辦公網、開發測試網、生產網，或安全生產網（Security Zone）。這些邊界往往由防火牆把守，實現四層的隔離。
• 應用、服務邊界：不論是微服務還是單體架構，服務往往會形成自己的叢集，服務內部相當於一個可信區，內部元件可以自由訪問。
• 主機邊界：主機通常是服務的載體，也是服務實現的原子單位。
• 使用者邊界：你懂的。
• 租戶、專案邏輯邊界：對於SaaS層服務，使用者資源是共享在一個公用的叢集，並沒有明顯的物理邊界，實際的邊界是透過基於認證和許可權的訪問控制隔離的。

能否畫出一個架構圖中的所有信任邊界呢？應該很難。從邏輯架構圖上，識別網路邊界、服務邊界相對容易。但更細粒度進行標記，就會很亂。所以這部分邊界你只要記住，在訪問入口識別的時候就可以了。

識別攻擊入口

正向攻擊入口識別很簡單。我們之前不是畫出所有場景的資料流圖了嗎？每一個資料流入、流出的入口點就是攻擊入口。你需要在每一個資料入口點對應的信任邊界識別有哪些必要的防護機制缺失，就能識別出漏洞，生成威脅列表了。把缺失的防護機制補上，就相當於修復了，是不是很簡單？

威脅列表

威脅列表是整個安全架構評審中重要的產出。筆者憑多年的安全評審經驗，奔著簡單、實用的原則對威脅列表進行了改造。具體欄位和描述如下：

•  威脅ID
•  威脅描述
• 某某資產物件，在某過程中，未做XX防護或者xx防護缺失，導致XX資訊洩漏。
• 威脅分類
• 有多種分類方法，為找出漏洞的共性與解決方案掛鉤，筆者做了如下分類。如果公司內部已經有了一套漏洞分類機制，建議整合一下，方便統計。
• 值
• 身份認證
• 日誌審計
• 許可權控制
• 流量加密
• 靜態或者儲存加密
• 賬戶、憑據保護
• 服務鑑權
• 特權賬戶或服務保護
• 網路隔離
• 威脅等級
• 兩個因素： 產生的影響和觸發的容易程度，可以參考DREAD模型
• 值：高中低
• 威脅來源
• 這塊結合整個安全評審上下文，重點是反映漏洞發現能力的指標
• 值
• 架構評審
• 程式碼稽核
• 安全測試
• 外報和滲透測試
• 威脅狀態
• 跟蹤威脅進度
• 值
• 建立
• 已確認（程式碼確認、測試確認、人為確認）
• 修復（未驗證）
• 修復（已驗證）
• 修復方案
• 通用問題，需要啟動安全控制專案，本欄位做專案-漏洞關聯
• 值
• 更新程式碼、配置（快速修復）
  
• 解決方案修復（指明解決方案ID）
  

深度分析和解決方案

到輸出威脅列表為止，安全架構評審的主要工作算完成了。不過，目前為止威脅列表還是零散的。如果只是單個系統，也就把一個個漏洞都修了算了。但現實情況是，你可能不僅僅有一個應用，而是成百上千、成千上萬的應用；單個應用也要不斷增加新功能、迭代新版本。因此安全架構評審的目標，不僅僅輸出安全的結果，還要輸出安全的能力。

對嚴重的、重複出現的安全問題進行根因分析，發掘導致漏洞的背後的原因，可以分析出目前安全建設的主要缺失。主要從安全流程、平臺和技術支撐和人員的安全意識和能力幾個方面進行復盤，孵化出後面的重點工作和安全專案。並在整體安全原則、安全理念達成共識，制定出總體和細分領域的安全策略、安全基線，構建強大的安全技術棧、安全火藥庫，從技術上解決問題。

總 結

本文給大家介紹了進行安全架構評審的方法，看起來似乎不是很難。的確，按照這個方法，在評審的完整度和覆蓋率上會有很大的提高。但要記住，在網路安全的世界，發現問題比解決問題容易。真正的專家是有對問題的閉環能力，就是落實安全解決方案的能力。簡單來說，這個方法只是給你的一個皮。如果沒有對安全技術的紮實的理解的這個肉，你的評審的準確度、權威性會受到挑戰。具體如何紮紮實實的提高安全技術，可以參考一些文獻，最重要的是要多學習，多實踐。

參考

OWASP Top 10

OWASP ASVS

構建安全的軟體

微軟威脅建模

Cisco 網路安全體系結構

Amazon Security

Google Security

DevOps Security

NIST SP800 系列

CIS security Benchmark

Nist Framework for Improving Critical Infrastructure Cybersecurity

CIS Top20 Security Controls

團 隊 介 紹

一 個 廣 告

美團安全2019年招聘火熱進行中~

如果你想加入我們，歡迎簡歷請發至郵箱zhaoyan17@meituan.com。