安全架構要參:構建企業適用的安全架構

InfoQ 2022-01-07 15:37:56 阅读数:456

安全架 安全 安全架 安全
以下內容為便於排版,有所删减。如欲閱讀全文請訪問 https://securityarchitecture.pro 或者wget https://securityarchitecture.pro -O filename.pdf 進行下載。

0x01 一些基本觀點


本章先去嘗試和讀者確立起相同的或者類似的觀點,雖然說推薦辯證思考,但如果基本觀點不相同的話,那很顯然說明這套方法可能對您起不到多少幫助。這裏的觀點雖然大都與技術無關,但需要每個安全架構師都能時常記住。

業務形態决定IT設施

業務形態决定了IT的形態,IT建設需要圍繞業務進行,更遑論安全。

沒有絕對安全的系統

沒有絕對安全的系統,任何系統都存在被攻破的可能性。無論是通過技術手段還是社會工程學等,總有辦法被攻破。

知道你的Scope

知道團隊、個人的職責範圍,權力範圍。如果不知道,務必先明確之。

關注需要的資源

當知道有多少預算時才知道能搭建多大的團隊、采用什麼級別的產品、提供什麼樣的服務、需要多少資源、多少時間、是否能够得到上級的充分支持,合作團隊的配合等。

關注生態

業務及業務周邊,同樣,安全能力建設中的合作部門,安全產品廠商,白帽子陣營等等。
 

0x02 認識業務

 
本章簡單介紹了認識業務的一些簡單方式,只有通過對業務的了解才能完成對業務的安全建設防護。

了解企業所在行業的基礎知識

充分了解企業所在行業的相關知識、最新的法規條例、如何演變的業務形態、關鍵的系統以及通訊協議、具體的業務流程以及制度等;同時關注行業領域內IT的發展 變化、IT所占業務盈利的百分比、IT中安全預算的占比以及關注同行業CIO,CTO對技術趨勢的傾向性。了解行業基礎,了解業務的核心價值以及發展趨勢。業務核心是需要安全架構主動關注的,長期關注的部分。假設一個企業的優勢在於跨境支付,那麼圍繞跨境支付的所有業務以及對應的系統就是核心價值所在。

關注企業的財報

關注企業的盈利能力,公開的財務數據能够知道企業內部是不是足够透明的,良性競爭的企業內部向來是不吝去開誠布公的討論這些指標。員工經常能在Dashboard看到有多少筆Transaction(交易),Volume(數額)。 無論是公開的還是僅限內部的財務數據,只有在足够盈利或者有著充足儲備的情况下,才能去建設安全團隊以及完善安全體系建設。

了解你的客戶

了解業務架構、應用架構、數據架構、技術架構等;了解業務的具體用戶;了解用戶的需求,結合現有的資源為客戶提供服務。對於安全架構師來說,有時候並不是直接面臨用戶,而是企業內部的團隊,客戶不是平等的,因為每個客戶都是差异化的。

了解你的行業

了解安全行業的現狀,以及各廠商的優劣,包含技術研究、售後支持、性價比等;

0x03 認識組織架構


本章通過介紹常見的一些組織架構形式,來幫助讀者認識協作的過程。

職能部門

產品部門(設計)、技術部門(包含研發、運維、運營、安全、風控等)、法務部門、財務部門、市場部門、公關部門、行政部門(人事、黨政)等。

協作方式

從職能層面來講常見的方式為自頂向下,即某委員會到某具體委員會到某具體工作組;例如:1. 企業數據委員會 → 2. 企業數據管理委員會 → 3. 企業數據管理工作小組;
分別負責:
1. 定義原則戰略政策以及做出决策、提供沖突解决;
2. 監督數據管理工作組、解决昇級問題、報告關鍵結果等;
3. 對數據進行定義分層生命周期管理、執行變更、評估質量等;
類似的還有企業架構委員會→應用架構委員會→架構評審工作小組等;除此之外對於集團性質的企業還存在虛實線匯報,本地化實線匯報以及集團的虛線匯報。推進某些項目時由工作小組牽頭,同級之間分發工作到具體團隊。在某些大型項目上往往還需要指定具體的項目經理跟踪整個進度,在日常工作中遇到資源不足時向上請求支持。當然現在還有一種能力中心三駕馬車(BP、SSC、COE)的運營模式,

安全團隊

當資源充足的時候,安全團隊自身就是具備架構師,工程師,產品經理,項目經理等。在集團化企業中,會設置不同的安全防線分別用於運營及管理、內控、內審。不同的部門之間互相制約,共同建設安全體系。例如內審團隊可以通過定期審計,促使團隊優化Policy以及SOP。值得注意的是,由於不同行業的關注點不盡相同,因此安全團隊的組成也並不相同。

企業文化

小到團隊氛圍大到企業文化,想必大多數讀者應該是經曆過不少人情世故。喜樂悲愁,自是別有一番滋味。廣義正確的說法是每個人都應該始終保持身體健康,對客戶友好,對同事寬容,使用創新技術。遠離996,遠離PUA,良性競爭,避免無用消耗。

0x04 陰與陽


本章通過簡單介紹陰陽的特性,希望籍此能够消解工作中的一些情緒,從而改變自我的認知以及幫助自己與團隊進步。其後針對一些爭議性問題給出了淺薄參考。

對立制約

相互對抗,互相制約
以攻擊與防守為例;有攻擊者就會有防守者,有防守方式就會有破解的欲望。不過雖說攻擊與防守互相制約,但不得不承認黑產永遠是走在最前面的。無他,利益驅動。

互藏互化

互藏互育,相互轉化
以甲方與乙方為例;攻擊者可以服務廠商,也可以去甲方內部。防守者即可以服務企業,也可以把經驗沉澱出產品。防守者獲得廠商的服務同時又向企業內部提供服務。

互源互用

相互依存,交錯運用
以企業和監管部門為例;企業和個人一同組成行業協會,協會幫助監管部門完善法律法規,征求專業人士的意見。反之最新的標准又幫助企業建設自身,幫助行業更加規範。

消長平衡

此消彼長,此長彼消
以價值與風險為例;隨著價值的逐步增加,面臨的風險就會變大。攻擊者大多都不會浪費資源對沒有價值的目標下手。詐騙份子也不會去將流浪漢作為犯罪目標。企業代錶的利益越來越多,就會面臨國家的監管。小到消防審查,大到反壟斷法。當帶來的價值和未知的風險處相對平衡才是理想的。
 

0x05 認識架構

 
本章先是針對架構定義、目標、規範、質量進行介紹,其後分別針對業務架構、應用架構、數據架構、技術架構進行介紹。

定義

The art or science of building 一種關於構建的科學或者藝術
將構建目標的各種依賴(虛)拆解出來並將各對應組件(實)通過某種方式運轉起來以符合目標需求的一種能力.

目標

建立安全、可靠、高性能且符合成本控制的系統架構。

規範

需要具備使用指南、參考架構、以及經過審查的工具和
代碼,同時需要滿足可操作性原則。

質量

在評估架構質量時需要考慮的有以下範疇。通用的講需
要滿足三個方面:
  • 安全(Security)
  • 合規 (Legal & Regulatory)
  • 灾難恢複(DR)
針對外提供的服務需要滿足可用性(Availability)、性能(
Performance)、容量(Capacity)、隔離(Isolation)、
可視化 (Visibility);
針對內部的或者說本地化的需要滿足
  • 成本效率(Cost Efficiency)
  • 可擴展性(Extensibility)
  • 可操作性(Operability)
  • 可維護性(Maintainability)
  • 可伸縮性 (Scalability)

業務架構

Know your Business
業務架構是代錶整體的、多維的業務視圖。包含能力、端到端的價值交付、信息和組織架構、以及戰略、產品、政策、計劃和利益相關者之間的關系,並對業務流程功能進行分解。主要目標和原則為以下幾點:
  • 遵守法律:企業政策是遵守法律、政策和法規。企業信息管理流程符合所有相關法律、政策和法規。企業必須注意遵守有關數據收集、保留和管理的法律、法規和外部政策。
  • 保持業務連續性:必須評估應用程序的關鍵性和對企業任務的影響,以確定需要何種程度的連續性以及需要何種相應的恢複計劃。
  •  為企業帶來最大利益:從企業範圍的角度做出的决策比從任何特定組織角度做出的决策具有更大的長期價值。
  • 確保IT和業務相適應:IT組織負責擁有和實施IT流程和基礎架構,使解决方案能够滿足用戶定義的功能、服務級別、成本和交付時間要求。
 

數據架構

Know your Data
通過組織架構,技術管理,流程控制,策略標准等更新迭代去實現數據治理。企業數據策略通過驅動數據治理以實現商業價值。針對數據管理,詳參以下各個方面。

數據治理

  • 組織架構及運營模型
  • 策略及流程
  • 數據域模型及所有者
  • 數據問題管理
  • 數據變更管理

數據質量

  • 數據分析
  • 業務規則和閾值
  • 數據清洗
  • 數據補救
  • 數據質量報告 

元數據

  • 業務分類
  • 數據字典
  • 元數據管理維護
  • 元數據訪問

數據風險管理

  • 風險管理 

數據保護

  • 數據安全
  • 數據隱私

主從數據

  • 標准及聚合
  • 業務和數據規則
  • 數據中心和常用服務
  • 主從數據持久化
  • 主從數據訪問

數據運營

  • 數據生命周期管理
  • 數據供應及源認證
  • 數據轉移和持久化
  • SLA管理
  • 數據認證

平臺及架構

  • 數據模型
  • 數據管理平臺
  • 數據整合
  • 數據架構

應用架構

Know your Services
此處主要針對單一系統的應用架構進行介紹,在單一系統的應用架構中,實現了技術層面的
在類和代碼的層級上有:
  • SRP(單一職責原則)
  • OCP(開閉原則)
  • LSP(裏氏替換原則)
  • ISP(接口隔離原則)
  • DIP(依賴反轉原則)
在組件的層級上有:
  • REP(複用、發布等同原則)
  • CCP(共同閉包原則)
  • CRP(共同複用原則)
處理組件依賴問題的三原則:
  • 無依賴環原則
  • 穩定依賴原則
  • 穩定抽象原則

技術架構

Know your Technology
技術架構一般是包含了整個技術範疇,在藍圖級別將整體的業務架構映射到具體的IT技術設施上。通常由架構師委員會制定,包含了基礎設施的技術棧(兩種左右的編程語言,常用框架,數據庫等),系統設計(Restful,SOA,SOAP,MicroService等),預研方向等。此處以金融支付類企業舉例。
基礎設施: 基礎設施,數據平臺,開發平臺,集團服務等;
通用平臺: 卡,風險,支付,認證,合規,金融,客戶服務等;
產品線:具體到各個產品線等;
客戶: 消費者,商戶(小微,企業,合作夥伴),全球本地化等;

0x06 認識企業安全

 
本章先簡單介紹安全及威脅的特性,其後針對安全治理進行介紹。包含治理範圍,設計原則以及技術範疇、合規範疇、管理範疇、運營範疇等相關領域。通過安全治理為企業架構增加安全性,從而構建安全,可靠,高性能並滿足成本控制的架構系統。

定義

在各方面不同方式的企業架構提供安全特性並通過各種機制確保流程正常。

安全特性

  • 機密性(Confidentiality):確保數據在傳輸和存儲時的機密性,避免未經授權的用戶有意或無意地泄露數據。
  • 完整性(Integrity)):確保數據在傳輸或存儲的生命周期內,始終保持正確性和一致性。
  • 可用性(Availability):確保用戶在需要通過信息系統進行操作時,數據和服務必須保持可用並滿足需求。
 
除CIA之外還有3A, 認證——識別信息用戶的身份,並記錄訪問和使用信息;授權——根據實際需求給予實體授予適當的權限,一般采用最小權限;計帳——記錄用戶與系統間的交互數據。

威脅分類

  • 欺騙
  • 篡改
  • 否認
  • 信息暴露
  • 拒絕服務
  • 提昇權限

安全治理

在不同領域通過技術、運營、管理的方式確保使企業架構具有安全特性。

治理領域(Scope)

主要包含以下幾點,另建議參考AWS,Azure等雲廠商關注方向。
  • 合規(Compliance)
  • 數據保護(Data Protection)
  • 基礎設施(Infrastructure)
  • 身份認證和訪問管理(IAM)
  • 應用和服務(Application and Service)

驅動力

基於事件的驅動往往意味著風險已經成為現實
1. 監管驅動
執法必嚴,違法必究;
2. 事件驅動
吃一塹,長一智;
3.價值驅動
未雨綢繆,上策;

安全設計原則

  • 適應業務目標
  • 為攻擊者設計
  • 最低容忍
  • 最小化攻擊面 
  • 强身份認證與權限管理
  • 彈性設計
  • 安全左移
  • 縱深防禦
  • 默認安全
  • 安全內生
  • 讓系統容易使用以及自動化
  • 平衡投資

合規範疇

法務部門對接相關行政機關,轉交給到對應合規部門,隨之根據行政法規,判斷是否需要作出相應的調整去滿足合規需求。例如是采購具備資質的乙方廠商的安全產品,或者使用指定的加密算法等。從分類上講一般可劃分為地域性的和行業性的:
1. 地域性合規
  • 國際合規
  • 本地化合規
  • 區域合規
2. 行業性合規
金融,醫療,保險,汽車等不同行業面臨的行業合規標准也是不盡相同的。

技術範疇

技術是解决問題的第一生產力
  • 入侵檢測和防禦(Intrusion Detection and Protection):例如入侵檢測、文件完整性保護、威脅情報、態勢感知等,以及對流量進行清洗(包含四層及七層流量清洗)等;
  • 集中化的日志管理(Centralized Log Collection):例如Splunk、ELK等;
  • 統一身份認證及權限管理(Identity and Access Management):例如AD、SSO、MFA、FIDO等;
  • 持續掃描及監控(Continuous Scanning and Monitoring):例如針對文件、網絡、主機、存儲、應用、代碼等資產進行持續性的掃描及監控;
  • 根信任(Root of Trust):例如根密鑰,隨機數生成器,硬件加密模塊,金杯體系;
  • 公鑰基礎設施(Public-Key Infrastructure)
  • 數據防泄漏(Data Leak Protection):例如針對郵件、流量、文檔;
  • 安全開發套件(Security SDK):例如加密套件、過濾器等;
  • 運行時防護(Runtime Protection):例如容器層級、應用層級;
  • 創新技術的探索性應用:例如Web3.0、AI、Blockchain、創新沙盒等;
 

運營範疇

持續性維護及優化需要實現的安全目標
在持續的運營過程中交付安全能力並發現新的問題,以下嘗試通過一種非技術的角度來介紹部分運營內容。
生命周期管理
包含對實體的申請、創建、分發、更新、輪換、吊銷、删除等操作
  • 證書
  • 密鑰
  • 數據
  • 漏洞
  • 補丁
  • 賬戶
  • 權限
  • 許可證
  • 敏感信件(代錶著紙媒所載的敏感信息)
值守
7x24遵循SOP的監控與響應
  • 監控
  • 檢測
  • 告警
  • 應急響應
演練
日常熟練緊急事件下的處置流程
  • 攻防對抗
  • 灾難演練
日常
日常工作自動化
以下按照能自動或自助與否進行劃分,簡單列出部分工作內容:
 
  • 同類產品部署
  • 主機/應用/網絡掃描等
  • 規則提取以及數據檢測
  • 自助服務
  • 培訓
  • 諮詢
  • 技術支持
  • 系統管理及維護
  • 編寫一些制度,策略,SOP

管理範疇

資源需要得到合理的安排
  • 策略管理
  • 風險管理
  • 生態運營
  • 項目管理
  • 成本管理
  • 文檔管理
  • 資產管理
  • 流程管理

安全框架

  • SABSA
  • O-ESA
  • NIST CyberSecurity Framework
  • MLPS(等級保護)

行業標准與最佳實踐

行業標准提供了一種概念性的規範,企業依照自身實際情况實施形成最佳實踐。設計企業安全架構時應當持續關注行業內最佳實踐,一般像AWS、Azure、Google、阿裏等都會定期發布或者更新相關白皮書。例如AWS Well-Architected Framework:
null
圖 6-5
以及Microsoft Cybersecurity Reference Architectures:
null

上雲與雲上

討論雲

上雲必然是趨勢,對於一些行業卻因為合規原因無法使用。CSP固然能够提供基礎設施層面的默認安全,但對於應用、服務、權限以及數據層面的威脅仍需要時刻關注平臺安全。期待密碼學的發展能够為租戶帶來更高的數據安全體驗。

討論雲原生

雲上將快速敏捷的持續交付作為雲原生的目標,其中所涉及的流程及基礎設施整體如果同安全能力
[82]
不相匹配,只會導致暴露更多更被動的攻擊面。

0x07 安全架構基礎

本章通過介紹安全架構以便達到能够對企業架構目標進行拆分或組合,並使其具備安全特性的能力。

定義

提供一種供企業實現架構安全特性的一系列原則、流程等組合方式。

目標

關注價值與威脅

包含價值所在以及來自內外部的威脅
  • 確定當前價值
  • 確定風險與差距
  • 確定優先級

關注基礎能力建設

包含技術、運營、管理三個基本面的能力建設
  • 用於技術支撐的安全基礎架構
  • 梳理資產及資產屬性
  • 基本策略和過程控制

關注生命周期治理

包含安全治理中各方面生命周期的運營管理
  • 引用業界參考模型以及確定適用的管理階段
  • 追踪不同階段的治理效果
  • 采用平臺或者自動化工具

安全模式

為系統架構附加安全特性的設計模式
  • 代理模式:Inbound/Outbound Proxy
  • 分層模式:Data Access Layer, Traffic Access Layer, ORM.
  • 聚合模式:API Gateway
  • 分離模式:Sanbox

安全服務

引入並對外提供安全服務
可以是提供產品出去,亦或是產品提供的服務,亦或人工服務,例如技術支持,客戶諮詢等。針對安全服務需要另從雇傭關系上需要注意外包人員的管理,尤其是“外包的外包”,例如x公司作為許多企業的外包服務提供者,其自身還會雇傭外包為雇主企業提供服務。
  • 基礎運維:Logging & Monitoring, Auditing, Administration, Alerting, Telemetry, NTP, Password Management, User Role, Port(eg. baseline 443, 2222) ACL etc;
  • 技術支持:Application Support, IT Support, Technical Support, Architecture Review, Code Reveiew, Penetration testing etc;
  • 意識培訓:Awareness Training, Anti-Corruption Training, Security Development etc;
  • 定制開發:Service Integration,  Self Service,  Security SDK etc;
  • 客戶諮詢: Customer Service, Security Solution;
 
針對提供的服務應通過確定衡量指標、收集服務反饋以達到對服務質量管理以及優化用戶體驗。

0x08 解决方案

 
本章介紹如何去尋找一個合適的度,去設計簡單的解决方案以及相關內容模塊。

明確需求

期望的範圍(原始需求的目標期望)
詳細描述方案的原始需求,並給出目標期望。衡量自己的資源,是否要削减非必要需求或者延緩低優先級需求,確保能够在當前的資源條件下進行實施。例如可以將需求分階段實施,一期去實行緊急且重要的需求。

適用場景

需求的範圍(基礎設施、應用、數據等)
原始的需求結合當前的實際情况確定出有哪些適用的場景。例如進行商密改造(負載均衡、API網關、Web服務器、應用服務、密碼學庫等);Ipv6改造(線路、路由、安全防護、DNS服務器、應用服務等);代碼掃描(發布系統、源代碼控制系統等);流量監控(多端、進出口流量等);

需求依賴

風險與資源的範圍(預算、人力、技術、項目管理等)
需要什麼資源(預算、采購、周期、關鍵人員、關鍵技術等),有哪些已知的風險(資源不足、遺留系統、整改有期限等)。衡量已知的風險和實現需求目標的資源,判斷是否能够解决,或者是需要尋求哪些進一步的支持。

最佳實踐

參考答案的集合(需求、場景、資源、風險等)

方案設計

包含技術架構、流程、運營等,是邏輯架構到上下文架構的具體體現。通過基礎設施的組合實現技術方案,同時提供日常操作、維護、特例等處置的參考案例。

驗收規範

通過一定的測試用例來判斷是否符合目標期望,以及能否維持SLA,具備SOP,符合驗收規範後可以進行Sign Off。

參考架構

提供行業標准、行業最佳實踐的相應說明以作參考。

項目管理

明確範圍,减少待定的過程
從明確需求到具體的適用場景,以及梳理依賴到輸出最佳實踐的過程都離不開項目管理。上至尋求支持,下至任務分配。即便在整個過程中存在專業的項目經理時,作為安全架構師還是應該能够完成跨團隊溝通,通過會議、郵件、IM等形式確定好關鍵利益人(Stakeholder)、接口人等。簡單的來說,務必要求對每一個輸入都有一個輸出以及减少輸出中的待定項。

0x09 持續服務

 
方案實施包含了部署,技術支持,客戶諮詢等方面。這意味著在方案落地之後項目只是達到了階段性交付,並未結束,依舊需要持續運營。本章通過介紹實施過程中的相關問題以及持續運營來認識持續交付。

以客戶為中心

理解每個客戶的差异性,統一基礎上提供定制化服務,並通過PDCA持續改進。

部署

結合基礎設施完成解决方案的部署並滿足架構質量。例如采用負載均衡、完成域名申請並增加相應DNS解析、開通防火牆規則、接入日志平臺、增加監控告警、設置權限分組等。整體大致可分為初始化配置、上線測試、對外服務、系統維護等。

運營

持續服務的主要體現就是運營,主要包含了日常操作、客戶諮詢、技術支持、專項治理等;

交付

基於已有方案,根據不同的需求交付新的功能。

系統集成

集成其他服務,以及被其他服務集成。例如:Vault和Nessus、Aqua集成;HSM和KMS、AD、PKI集成;NTP、Zabbix同許多基礎設施集成等;

定制開發

集成、部署、運營的過程均可將日常工作自動化。例如自助服務(代碼掃描、證書申請等),定制服務(擴展功能、支持新的平臺等);

0x10 成為安全架構師

 
總有獵頭問候選人:“你帶過團隊嗎?”,以此判斷對方是否具備管理經驗。但實際上並不是去打KPI才會管理,同樣的也並不是只有架構師的角色才會承擔安全架構的設計。本章簡單介紹一些心得,重在持之以恒。

品格

拒絕貪腐,嚴守底線;

心態

戒急、戒忿、戒貪、持續學習、虛懷若穀;

健康

身體健康最重要,照顧好自己、家庭,保持健康的身體有利於思維創新;

技能

主要包括對技術,運營,管理等各方面的宏觀認識,以及對具體方案的細節把握。持續研究行業最佳實踐,尋找機會落地;

知行

有知有行,知行合一;

附錄. 推薦閱讀

 
1.     AWS安全最佳實踐:
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/wellarchitected-security-pillar.pdf
2.     AWS Well-Architected Framework: 
https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
3.     Google Infrastructure Security Design: 
https://cloud.google.com/security/infrastructure
4.     Microsoft Cybersecurity Reference Architecture:
https://docs.microsoft.com/en-us/security/cybersecurity-reference-architecture/mcra
5.     Microsoft SDLC:https://www.microsoft.com/en-us/securityengineering/sdl
6.     OpenSecurityArchitecture Pattern Library: 
https://www.opensecurityarchitecture.org/cms/library/patternlandscape
7.     A Detailed guide on building your own pki: 
https://www.encryptionconsulting.com/a-detailed-guide-on-building-your-own-pki/
8.     Secret Management Best Practice: 
https://zhaokunpeng.medium.com/hashicorp-vault-advanced-tutorial-for-enterprise-56223aae39bb
9.     Cloud Security and DevSecOps Best Practices by SANS: 
https://sansorg.egnyte.com/dl/OTrn2Tyq3n
10.   零信任架構綜述:
https://mp.weixin.qq.com/s/yQIZKFBQuNuTzvy-e1ZI_g
11.   全面解决零信任安全架構by 奇安信:
https://www.gartner.com/teamsiteanalytics/servePDF?g=/imagesrv/media-products/pdf/Qi-An-Xin/Qi-An-Xin-1-1OKONUN2.pdf
12.   數據安全技術與產業發展研究報告2021: 
http://www.caict.ac.cn/kxyj/qwfb/ztbg/202112/t20211221_394364.htm
13.   隱私計算白皮書: 
https://gw.alipayobjects.com/os/bmw-prod/73c5f163-d091-487a-bf5c-41841f546bc0.pdf
14.   解構安全運行能力體系建設:
https://www.qianxin.com/topic/rsac/newsDetails?id=40
15.   《Enterprise Security Architecture》 - Nicholas Sherwood
16.   《Designing Security Architecture Solutions》 - Jay Ramachandran
17.   《Security Patterns In Practice - Designing Secure Architectures Using Software Patterns》- Eduardo Fernandez
18.   《Practical Cybersecurity Architecture》 - Ed Moyle, Diana Kelley
19.   《Hands-on cybersecurity for architects plan and design robust security architectures》- Aslaner, MiladRerup, Neil
20.   《互聯網企業安全高級指南》
21.   《大型互聯網企業安全架構》
22.   《Google系統架構解密》
23.   《架構整潔之道》
24.   《代碼整潔之道》
25.   《Getting Real》
26.   《Web信息架構》
27.   《企業應用架構模式》
28.   《網絡安全法——網絡安全等級保護2.0》
29.   《微服務設計》
30.   《高可用架構》
版权声明:本文为[InfoQ]所创,转载请带上原文链接,感谢。 https://gsmany.com/2022/01/202201071537558197.html