以下内容为便于排版，有所删减。如欲阅读全文请访问 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:

图 6-5

以及 Microsoft Cybersecurity Reference Architectures：

上云与云上

讨论云

上云必然是趋势，对于一些行业却因为合规原因无法使用。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.   《高可用架构》