企业官网建设流程全解析

系统架构设计师这门考试里，安全架构设计是个很有意思的板块。它不是哪一本教材里的独立章节，也不会只出现在某一科的固定位置上——上午选择题里有它，下午案例分析题里经常和分布式、高可用混在一起考，到了论文阶段它还时不时作为可选方向出现。更麻烦的是，日常做业务开发的人，平时很难积累到体系化的安全设计经验，所以复习的时候容易陷入“概念都眼熟，做题答不全”的状态。

本系列更到第36期，这一篇就把安全架构设计的理论和实践尽量讲透。我会把考试里真正会考到的核心知识梳理成框架，再结合案例题的答题思路、论文的写作套路、备考中的易错点，最后落到实际架构设计里可以用的威胁建模和Checklist。这篇文章适合两类人看：一类是正在备考软考系统架构设计师的，另一类是考完试之后想把安全设计真正用到项目里的。

1. 安全架构设计在软考里的位置：为什么说它是“横切考点”

1.1 上午、案例、论文三关如何分布

上午的选择题里，安全相关知识点通常占2到4分。别觉得这个分值不高，上午题的总分要求是45分，每一分都可能在及格线上起到决定性作用。出题位置集中在信息系统安全、网络安全和信息安全基础这些章节，出题方式主要是概念辨析、算法判断、模型规则判断，比如给一个加密场景让你选算法，或者给四条操作让你判断哪个违反了BLP模型。

下午的案例分析题更值得认真对待。安全不一定每年单独占一道大题，但它经常以“穿插问”的形式出现。尤其是微服务、云原生、分布式系统这类架构题，几乎必有一问涉及“系统面临哪些安全威胁”“如何设计认证授权机制”“如何保证数据传输和存储的安全”。这种问题看起来不难，但想答得有条理并不容易。只写“加防火墙、上HTTPS”这样零散的点，得分往往不理想，阅卷人想看到的是你对整个安全体系的统筹设计。

论文题是很多人不敢碰的方向。系统架构设计师的论文题目中，“信息安全架构设计”是可选方向之一，真正敢选的人比例不高。原因很简单：如果没有完整设计过某种安全体系，论文很容易写成“安全很重要、我们要重视安全”的空话。但换个角度想，如果你在工作中参与过统一认证、权限体系、数据加密、安全审计这类项目，哪怕规模不大，这个方向反而更容易写出有血有肉的文章来，避开大路货。

1.2 为什么安全架构总被低估

安全架构在考试里看起来很“软”，没有棘手的计算公式，也没有复杂的框架结构，很多人就默认它是背一背就能过的章节。但我的实际体会是，它是最典型的“横切关注点”——不单独存在于某个模块，而是贯穿认证、授权、通信、存储、容灾和运维全部环节。这也解释了一个现象：安全相关的案例题，从来不会单独考“安全原理”，而是把安全嵌在某个具体系统里来考。

打个比方。你装修一套房子，功能分区是客厅、卧室、厨房，但安防系统呢？门锁、监控、窗户防护，这些不属于某一个房间，而是覆盖整栋房子的体系。安全架构就是整个IT系统的那套“安防体系”。抱着这种理解去复习，学高可用时会想到数据备份的安全，学微服务时会想到服务间调用的双向认证，学大数据时会想到敏感字段的脱敏与合规。把安全知识织进其他知识里去学，比单独死记一章概念有效得多。

2. 先把理论吃透：六大安全属性、三大模型与密码学基础

2.1 分清六个属性，才能看懂攻击场景

安全架构最终要解决的无非几个基本属性：机密性、完整性、可用性，以及认证、授权和审计。前三者通常叫CIA三元组，加后三者，构成安全需求的基本框架。很多考生的问题不是不知道这几个词，而是碰到具体场景时判断不准确。

最容易混淆的是完整性和可用性。完整性指数据没有被非法篡改，可用性指系统在需要的时候还能正常使用。比如一个文件服务器被黑客删掉了大量文件，这是破坏了可用性；如果黑客悄悄改了文件内容但文件还在，这是破坏了完整性。再加上机密性，就构成三个不同方向的防护目标：加密保机密性，哈希和数字签名保完整性，冗余和容错保可用性。

考试里常见的一种考法，是描述一个安全事件，让你判断它破坏了哪个属性。做这类题时先看“信息流”的方向：信息被不该看的人读走了，是机密性问题；信息被改掉了，是完整性问题；系统直接不能用了，是可用性问题。方向判断对了，答案基本不会偏。

2.2 BLP、Biba与Clark-Wilson：记住规则别记混

安全模型是理论部分的硬骨头，但考点特别集中，核心就三个：BLP、Biba、Clark-Wilson。学的时候抓住一条主线——每个模型解决的问题不同。

BLP模型解决机密性问题，核心规则是“不上读、不下写”：主体不能读取高于自己密级的信息，也不能把高密级信息写到低密级的地方。目的是防止高密级信息向下流动造成泄露。记忆时可以这样想：BLP的B对应“保密”，越是高密级的东西越不能往下传。

Biba模型解决完整性问题，规则与BLP正好相反，核心是“不读低、不写高”：主体不能读取完整性等级更低的数据，也不能向完整性等级更高的对象写入数据。因为完整性关心的是数据不被低可信来源污染，所以低信任的东西不能污染高信任的数据。考试里最常见的考法，就是给你几条操作，判断哪个模型允许、哪个模型禁止。

Clark-Wilson模型强调的不再是等级，而是职责分离和良构事务。它常考的概念是“有权的操作者不能同时是审计者”“事务必须从一个合法状态到另一个合法状态”。这类考点更多出现在企业内部的安全策略设计里。把这三个模型的属性、规则、适用场景做成对比表，考前过一遍效率很高：

2.3 密码学基础与PKI：不写代码也能拿分

密码学在安全架构里的地位，相当于工具箱里的基本功。考试不会让你手写加密算法，但会把算法选型和数字签名流程考得很细。需要掌握三张牌：对称加密、非对称加密、哈希算法。

对称加密用同一个密钥加解密，速度快，典型算法是AES、DES、SM4。非对称加密用公钥和私钥一对密钥，速度慢，但解决了密钥分发问题，典型算法是RSA、ECC、SM2。哈希算法是单向的，没有密钥，用于完整性校验，典型是SHA-256、SM3。近年国密算法的出镜频率明显上升，SM2、SM3、SM4分别对应非对称、哈希、对称，这个对应关系建议直接记死。

数字签名是最容易考流程的考点。一句话记：私钥签名，公钥验证；公钥加密，私钥解密。但很多人把加密和签名混在一起。加密用公钥、解密用私钥，目的是机密性；签名用私钥、验证用公钥，目的是完整性和不可抵赖。为什么签名必须用私钥？因为私钥只有本人有，消息附带签名就等于“我确认过这条消息是我发的”，别人改一个字节签名就校验不过去，想抵赖也抵赖不了。

PKI和CA也是高频概念。CA是签发数字证书的机构，证书里绑定了公钥和实体身份，SSL/TLS之所以能防止中间人冒充，就是靠CA体系完成服务端身份验证。做案例题时，只要题目涉及Web系统通信安全，写上“部署CA体系、启用HTTPS”基本都能得分。

3. 安全方案设计怎么落地：纵深防御、认证授权与数据安全

3.1 纵深防御与安全域划分：方案要有层次感

很多人对安全架构方案的想象，还停留在“加防火墙、上SSL”这种单点措施。但案例分析题里想拿高分，方案一定要有层次。要理解这个层次，先学一个词：纵深防御。它和安全域划分往往是一起出现的。

纵深防御的核心思想是“不要把所有鸡蛋放在一个篮子里”。哪怕某一层被攻破，后面还有别的层兜底。典型的层次包括网络边界防护、主机防护、应用防护、数据防护。每层侧重不同：边界用防火墙和入侵检测，主机做补丁管理和防病毒，应用用WAF和输入校验，数据做加密和权限控制。层次之间要互相独立，不共享同一个失效点。

安全域划分是把系统按信任等级切分成不同区域。比如把内网划分成办公区、业务区、数据区，把对外的服务放到DMZ区。设计原则是：不同安全域之间默认拒绝、按需放行。我做题时的经验是，回答这类问题不要只说“划分安全域”，一定要说明哪个域信任度高、哪个域信任度低、边界上部署什么设备。比如“Web服务器放在DMZ，数据库放在高信任的DB域，应用服务器只允许通过特定端口访问数据库”，这才是一个可以得分的完整方案。

生活里做个类比：纵深防御就像小区安防。门口保安是第一道，单元门禁是第二道，自家门锁是第三道。哪怕外来人混进了小区，单元门进不去；就算进了单元，门锁也能挡住。每道防线单独看都有漏洞，叠起来之后安全性就是乘法而不是加法。当然代价也直观——复杂度和成本上去了，这正好是题目里常常让你权衡的地方。

3.2 认证授权选型：RBAC、ABAC与OAuth2/JWT

认证授权是安全架构里最贴近代码的部分。早期考题喜欢考“基于角色的访问控制”概念，后来逐渐转向分布式环境下怎么设计认证鉴权体系。

RBAC的核心是“用户-角色-权限”三层结构，权限挂到角色上，再把角色分配给人。它管理简便，组织结构清晰的企业系统非常适用。ABAC则基于属性动态决策，比如按用户部门、访问时间、来源IP动态决定是否放行，适合多租户和复杂权限场景。两者的对比方向比较固定：RBAC灵活度低但性能好、易维护；ABAC灵活但策略复杂，策略一多就容易出逻辑漏洞，排查也费劲。

如果是微服务或分布式系统的安全设计，OAuth2和JWT几乎是绕不开的考点。OAuth2解决的是“第三方应用如何获得授权”的问题，核心思想是发令牌而不是给账号密码。JWT则是一种无状态令牌，把用户信息、角色和过期时间编码进Token自身。实际使用中，你会遇到一个高频问题：Token过期了怎么办？解决方案一般是引入refresh token机制，让用户在令牌失效后静默刷新，而不是频繁跳回登录页。

下面是一段项目里常见的网关鉴权概念示意，帮助理解组件之间怎么协作：

请求到达 API 网关 网关从 Authorization Header 提取 JWT 校验签名和过期时间（公钥由认证服务下发） 从 Token 解析 userId 与 roles 按 RBAC 策略判断是否有权限访问目标接口 将 userId 注入转发请求的 header，透传给下游服务

实际落地时，网关层负责统一鉴权，业务层还要再做细粒度权限校验。两层都做，才符合纵深防御的思想。

3.3 数据安全与隐私保护：静态、传输、使用三态

数据安全在软考里的比重近几年明显上升。考察方向围绕数据的三个状态：静态数据、传输数据、使用中的数据。

静态数据安全的核心是加密存储和密钥管理。数据库里的敏感字段要加密，备份文件也要加密。传输安全的核心是HTTPS和TLS，保证数据在网络上不被窃听。使用中的数据安全则更难，涉及访问控制、字段级脱敏、水印追踪。比如客服系统查看用户手机号时只显示后四位，就是典型的使用态脱敏场景。

密钥管理是这个部分最容易被忽略的考点。不管算法选得多好，密钥一旦管理不善就全部白搭。考试里常问的点包括：密钥不能硬编码在代码里、密钥要有轮换机制、建议用密钥管理系统或加密机统一管理。我见过真实项目里因为数据库密码写在配置文件明文里导致的大规模泄露，这种教训放在考场上回答“如何保证加密有效性”时，写上一句“密钥独立管理、定期轮换、应用与密钥分离”，就是加分项。

隐私保护的设计原则也值得整理成答题框架：数据最小化收集、明确告知用户、允许用户删除自己的数据。案例题里出现用户隐私保护相关问题时，把这些原则和技术措施结合起来回答，方案会显得完整很多。

4. 案例分析题实战：四步框架拆解安全架构设计

4.1 案例题怎么问安全：从场景描述看考点

系统架构设计师的案例题风格比较固定：给一段系统场景描述，配一个架构图或需求列表，然后提三到四个问题。安全相关的问法通常是“请分析该系统面临的安全威胁”“请设计该系统的安全架构方案”“请说明你所设计方案的优点和不足”。

这类题目最大的特点是：场景越具体，越要求你结合场景回答。题目里说了“系统部署在公有云上，面向多租户”，答案里就必须出现租户隔离、虚拟网络隔离、共享资源带来的攻击面扩大。题目里强调“系统存储大量用户隐私数据”，那加密存储和访问审计就是必答项。如果只是机械地把所有安全技术都堆上去，反而显得没有重点。

热词里常被提到的“2017年下半年系统架构设计师·案例分析试题一”，是历届考生讨论很多的经典题。它的典型考法是先给系统背景，再围绕安全和可用性提问。这类早年真题的价值不在于题目本身，而在于它展示的出题逻辑和答题套路，直到今天都没怎么变：紧扣场景、分层作答、说清选型理由。想了解案例题风格，找最近的真题做两三套，比只翻教材有用得多。

4.2 四步答题框架：识别威胁、定义需求、选择机制、权衡代价

做安全类案例题，我建议固定一个答题框架：识别威胁、定义需求、选择机制、部署权衡。这四个词记在脑子里，遇到任何安全场景都不会没话写。

第一步，识别威胁。把场景里可能出现的威胁列出来，比如越权访问、数据窃听、身份冒用、日志被篡改、单点故障。这一步不用求全，而是给后续方案找靶子。第二步，把威胁翻译成安全需求。例如“防止越权访问”对应“需要细粒度授权机制”，“防止窃听”对应“需要传输加密”。这一步能向阅卷人展示你的分析能力。第三步，选择具体机制，并说明为什么选它。比如“采用OAuth2授权码模式配合JWT，因为系统是B/S架构且需要支持第三方接入”。第四步，说清部署位置和代价。比如“TLS卸载放在网关层，减少后端加解密开销，但网关本身必须做高可用设计”。

举个例子。假设场景是“某电商系统改造成微服务架构，需要设计安全方案”，我会这样组织答案：

• 威胁识别：外部攻击（SQL注入、暴力破解）、服务间调用被伪造、用户越权访问、审计日志不完整。
• 需求定义：通信机密性、用户统一认证、接口授权、操作可审计。
• 机制选择：外部流量经WAF过滤；网关层统一做OAuth2/JWT鉴权；服务间调用使用mTLS双向证书；敏感操作记录审计日志并定期归档。
• 代价说明：mTLS会增加服务间通信的握手开销，所以只对关键服务启用；统一网关鉴权避免了每个服务重复造轮子，但网关本身不能成为性能瓶颈。

这样一段话，有分析、有选型、有取舍，比一句“加防火墙、上HTTPS、做好安全防护”要扎实得多。

4.3 失分点复盘：从“堆名词”到“给方案”

我帮别人批改过不少模拟卷，安全题失分主要是三种情况。第一种是只答名词不答场景。写了“采用RBAC、使用AES加密、部署WAF”，但完全没有解释这些措施解决场景里的哪个问题，阅卷人看下来只觉得是名词堆砌。第二种是没有权衡。安全方案都有代价，只写优点不写缺点，答案会显得特别单薄。第三种是缺少位置感。只写“做加密”，但没说在哪里做、谁来做、密钥谁管，这就不像一个架构师在画方案，更像学生在背概念。

补救办法其实很直接。做练习时，每写一个安全措施，后面强制加一句话：“部署在XX层，解决XX问题，代价是XX”。坚持用这个句式练完20道案例题，安全类的问答基本不会低于平均分。平时做项目评审时，也可以用这个句式逼自己把方案说明白。

5. 备考阶段最容易错的点与论文写作思路

5.1 高频易错点速查表：考前一周就背它

安全知识的易错点其实高度集中，我整理了一张考前用来对照的速查表。复习到后期，这张表的密度比教材里一整章都管用：

每一行背后都是选择题里常设的陷阱。比如“数字签名不是加密”这个点，真题反复考。理解到位之后，很多判断题扫一眼就能确定答案。

5.2 论文选安全方向：用真实项目素材撑起结构

论文是三个科目里最需要提前准备素材的一科。如果计划选“信息安全架构设计”方向，建议准备一个自己真正参与过的系统，哪怕规模不大，也要把安全设计的细节想透。

架构设计师论文通常要求“项目背景、你的职责、设计理念、具体设计、效果评估”的结构。安全论文最忌通篇讲大道理，必须落在一个具体的方案上。比如你设计过统一认证平台，可以写清楚：为什么选OAuth2加JWT，令牌生命周期怎么设计，上线后遇到过什么真实问题，比如过期策略导致用户频繁掉线，最后怎么用refresh token解决。有真实问题的论文才有说服力。

备考阶段，建议每做过一次安全相关决策，都用“问题-方案-代价-验证”四步记进素材库。到了考场上从素材里挑一个最合适的套进论文结构，效率和文章质量都会好很多。平时没有项目经验的考生，也可以找一个开源系统，认真分析它的安全设计并重构一遍，用这种模拟项目做素材。

5.3 安全知识复习节奏与时间分配

安全这部分不适合考前一周突击。因为它和其他章节联动紧密，前期学教材时把安全章节和其他内容交叉理解，后期再用真题检验，效果最好。我自己的节奏是：第一轮跟着教材过概念，重点是六大属性和密码学基础；第二轮收集历年案例题里的安全问答，专门练四步答题框架；第三轮整理论文素材和速查表。

时间分配上，选择题靠碎片时间刷题足够；案例题必须拿出整块时间，认真写、认真改、对比标准答案；论文至少完整写两篇。整体看，安全架构分配的时间不需要太多，但每一轮都要有明确产出，不能变成“学完了又好像什么都没学”。

6. 考完之后怎么用：威胁建模与实战Checklist

6.1 STRIDE威胁建模：替代“凭感觉做安全”

考试不是终点。在真实项目中，安全设计通常从威胁建模开始。最常用的方法是微软提出的STRIDE，它把威胁分成六类，正好和前面说的安全属性一一对应：假冒对应认证，篡改对应完整性，否认对应审计，信息泄露对应机密性，拒绝服务对应可用性，权限提升对应授权。

STRIDE好用的原因，是它强迫你按分类思考。给一个新系统做安全评审时，可以建一张表，一行代表一条数据流，逐列检查这六类威胁是否覆盖，覆盖不了的标注风险说明。做完这张表，方案里哪里要加认证、哪里要加限流、哪里要加审计，基本一目了然。考试案例题里用STRIDE组织威胁分析，也比凭感觉写更全面。

6.2 云化与微服务化下的三个安全重点

现在做系统架构，和十年前最大的区别是云化、微服务化和数据合规要求全面上升。安全设计重心也明显变化。第一个重点是云安全，包括云上身份的访问管理、虚拟网络隔离、密钥管理。第二个重点是应用安全，API数量暴增之后，网关的认证鉴权、限流、审计成了刚需。第三个重点是数据安全，尤其是隐私数据的分类分级、加密存储和合规使用。

一个典型的云上微服务系统，安全设计通常长这样：接入层用WAF加HTTPS，网关层做统一认证鉴权，服务间用mTLS双向认证，数据层敏感字段加密存储，日志系统接入审计平台。每层看起来都很标准，但真正的设计工作全在细节：密钥多久轮换一次、Token有效期多长、哪些请求要做细粒度权限校验、审计日志保留多长时间。这些细节才是架构师价值的体现。

我和同事讨论时常说，安全设计不怕方案不高级，就怕没有原则。默认拒绝、最小权限、纵深防御、可审计，这四个原则加在一起，已经能挡住绝大多数常规攻击。方案的高级感来自对场景的理解，不来自技术名词的堆砌。

6.3 架构评审中可复用的安全设计Checklist

最后分享一份我实际做架构评审时用的Checklist，同样适合备考时拿案例题场景来自测：

• 身份认证：是否有统一认证入口？是否支持多因素认证？密码是否加盐哈希存储？
• 授权：使用RBAC还是ABAC？接口层是否做细粒度权限校验？是否存在越权路径？
• 通信安全：是否强制HTTPS？服务间是否双向认证？证书由哪一方管理？
• 数据安全：静态数据是否加密？敏感字段是否脱敏？备份是否加密存储？
• 审计与监控：是否有统一日志平台？关键操作是否可追溯？日志是否防篡改？
• 可用性：是否存在单点？是否有备份与恢复计划？容灾演练多久做一次？
• 合规：是否遵循数据最小化原则？是否支持用户删除数据？

拿这份清单过一轮系统，通常能发现几个平时根本注意不到的薄弱点。备考的时候，随便找一道案例题的场景，用清单逐条对照，也能帮你想明白“标准答案”到底覆盖了哪些安全维度。

我在备考系统架构设计师的时候，安全部分不是最难啃的，但确实是最容易“冤枉丢分”的。明明知识点都见过，一到案例题就写不完整。后来想明白，问题出在我一直把它当成一门独立的知识来背，而不是当作横切整个系统设计的视角。当你带着“在哪里部署、解决什么问题、付出什么代价”三个问题去学安全，前面的选择题、案例分析题、论文都会顺手很多。希望这篇梳理能帮你把安全架构从“会背”变成“会用”。