与大多数教你如何担任架构师一职的显学不同，本文从对立面剖给你看，成功学容易，想要看清泥泞中的水坑，是真的需要自己多走点路。

安全架构师是信息安全这项目工作做久了之后的结果，但并不是必然结果，拥有多年的工作经验、见识广泛、大厂出身都不是充分条件。相反，一个自认为有多年经验、见过世面、系出名门的老哥走到了安全架构师职位，却犯了以下几种错误，那么他大概率上会失败。（为什么说大概率而不是一定，因为据说毛主席不会用枪。如果是这一级别的大神，这篇文章不适合您，我先走了）

一、言必称架构，却不知架构为何物

1、说不清功能架构、技术架构、应用架构之间的差异跟联系

先说说什么叫架构，答案因人而异，对我而言，架构既是骨架，也是肌肉、皮肤。

• 有一些大型的企业，管理上已经走过了很基本的初级阶段，一点点现场的变化和改善，具体流程有些哪些变化，对这样的企业来说根本起不到什么作用。它们需要从整个公司的顶层设计，工作需要进入这样一个量级。到这种规模的企业，需要的就是系统化的方法。企业架构这个东西就是从这里切入的。

• 这个道理就跟做产品也是一样的。如果说我们做一个小的产品，比如一些日用品、快消品这种生产销售的企业，你做产品设计就比较简单，直接开发就完了。而如果你是要做一个系统级的产品，比如说设计和生产汽车，或者航空发动机、飞机、电厂这样规模的产品，设计的系统性就非常重要，你必须给出一个系统级的解决方案。这种系统级的产品设计就相当于我们大企业管理的顶层设计，而小企业不需要顶层设计，或者说不需要系统级的顶层设计。

企业架构就是这样的顶层设计。企业架构通常分两种，一种叫业务架构，另一种叫 IT 架构。最早做架构的人都是搞 IT 的人，IT 人士更有这种系统性的思维。其实做流程，有一部分起因是搞业务和管理的人，还有一部分起因是搞 IT 的人。是 IT 人士把这种流程的结构化思维推向了更高的一个层面。

• 业务架构，是对企业的业务和管理的不同维度来构建的模型。比如说企业的战略绩效模型，运营模式模型，流程模型，组织模型，空间布局模型等等这些模型。现实中我们见的最多的企业架构模型就是组织架构。我们看到企业的组织机构图，它就是一种业务架构。

• 还有一个就是 IT 架构，IT 架构就是从企业信息化实现的维度来给企业构建的模型。它的目的就是描绘这种信息系统的蓝图。IT 架构分这样三个部分，数据架构、应用架构和技术架构。数据架构是研究企业里数据资源的结构；应用架构是企业部署的应用和这些应用之间的关系；技术架构就是完全技术性的东西，软件，硬件，基础设施，网络，通讯，中间件等等内容。

也就说 IT 架构是由企业架构衍生出来的。当我们进行 IT 架构设计的时候，依然还要从业务架构出发。因为道理很简单，不管你如何做 IT 规划和 IT 的开发，最后你总是要用业务来实现它，你的最终目的也是要为业务服务，否则你的 IT 就没有意义。

2、安全架构就是一通罗列，堆上去就他了

安全架构有两个衍生依据，一是业务架构，二是 IT 架构。不满足业务需求做安全是无源之水，不分析 IT 做安全是缘木求鱼。

• 业务需求又分为功能需求和合规需求，也就是对内负责和对外负责。

在实操中，安全架构的设计基本上遵循需求分析、安全功能分析、功能拆分与设计几个步骤。以登录这一功能为例子进行详细说明：

• 1、某金融类 App，该 App 有动账功能，涉及外部客户资金的转出与提现。这里需要分析的是用户群体、用户环境、用户动作以及用户业务场景，也就是谁用什么工具执行某项操作，用来开展某项业务。当然与登录相关的业务都需要搞清楚，比如用户体系来自哪里，怎么输入、更新、删除，谁来执行、审批等等。特别提示，这里的安全分析一定要深度结合业务场景，笔者曾经在银行和券商工作过，银行动账时可以选用 U 盾，那么券商银证转账能不能用 U 盾，就是不能，后者对资金转移的快速要求是第一位，就是不能搞这么复杂，你可以在后台增加风控措施，在前台就是不能这么搞双因素认证。

• 2、摘取合规要求中与登录相关的要求，如根据最新版的《网上银行系统信息安全通用规范》(JR/T 0068-2020)中“6.2 安全技术规范”要求，登录应遵循：

6.2.1.1 n) 客户端登录框应禁止明文显示密码，应使用同一特殊字符（例如，*或者.）代替。

6.2.1.1 o) 客户端程序程序登录后在一定时间内容无任何操作，应自动登出，重新登录后才能继续使用。

6.2.1.1 p)客户端程序应配合服务器端采取有效措施，对登录请求、服务请求以及数据库查询等资源消耗较高行为的频率进行合理限制。

• 3、分析 IT 架构，可以从软件需求设计说明书中找到或参与到研发人员的前期设计会议中，了解 IT 人员用到的技术栈。例如，登录用到了 Oauth2，在技实现上用户体系哪里来，怎么管。

• 4、结合常见的威胁分析模型，如微软 STRIDE 模型，分析登录可能遇到的风险，并据此设计应对方案，模型给了一些通用的消减措施。

作为架构师，只有通用的消减措施是远远不够的，还要根据前面的分析，设计更详细的风险及应对措施。

重复上述过程，遍历所有的业务需求、IT 需求，就得到了一张大表，包括业务需求、IT 需求、安全风险、应对措施。这张表就是安全架构设计的产物，把应对措施做同类型合并，划分出明确的边界，就得到了一张安全架构图。它有以下几个显而易见的好处，原因不再赘述：

1. 作为本项目安全测试、上线前安全验收的依据；

2. 作为同类项目渗透测试的参考；

3. 长期积累，作为项目立项、初期过需求时期的安全评审的依据；

4. 安全知识库重要组成部分。

3、画不出一张合格的架构图

架构图是随意堆叠的吗？

• 为什么适用方框而不是圆形，它有什么特殊的含义吗？随意使用方框或者其它形状可能会引起混淆。

• 虚线、实线什么意思？箭头什么意思？颜色什么意思？随意使用线条或者箭头可能会引起误会。

• 架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。

架构图设计的建议

• 对于安全功能架构、安全应用架构这类比较宏观层面的图而言，架构图是为了抽象地表示功能组合的整体轮廓和各个功能之间的相互关系和约束边界，因此需要明确区分各个功能模块的内涵和边界，给每个模块起一个独特的、不易混淆的名字，列出来这个模块的具体内容，架构图中一般可以画到第三级框，图下面再用文字写全。

• 对于场景、物理、逻辑、处理逻辑等软件开发设计时的架构图，首先应该要明确架构图的读者，想清楚要给他们传递什么信息。所以，不要为了画一个架构图去画架构，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来。除了参考大神们画的 UML、时序图、开发机构等，这里其实是有业界标准供参考设计的，C4 模型。具体可以参考 C4 官网“https://c4model.com/”，The C4 model for visualising software architecture Context, Containers, Components and Code。

二、遇事不决，量子力学

整个 IT 产业都处于高速发展迭代的过程中，信息安全也不例外。技术与管理理念不断推陈出新。失败的架构师会拒绝更新知识体系，或理解不到位而生搬硬套，敷衍堆叠。

1、一招鲜吃遍天

遇到没有见过的东西，失败的架构师自然是严重依赖已有知识体系，如果凑巧心血来潮加入了新鲜的技术或者理念，基本上就是理解个大概就堆上去了，然后使用量子力学进行解释，“这个、那个，对，应该就是这个意思，我就是想说那个”，没有观察者打开黑箱实际观测导致坍塌就能一直走运。 从发展的模式来看，新的信息安全技术或新理念的出现一般可以从两个地方找到痕迹：

1. 新业务驱动

• 出来 devops 要不要 devsecops？出来个新的点对点支付你要不要考虑交易安全的事情，新的社区采购模式你要不要考虑用户安全的事情，以往的安全威胁、安全防护措施，在新的业务面前还适不适用，还合不合适，程度上要不要减弱或者加强一些，都需要考虑。

• 再次提示结合具体业务场景做安全需求分析的必要性，一定要从用户、设备、操作、业务场景做深入分析，这样才能分析出什么叫适不适用，合不合适。举个例子，给公司内部员工用的企业专用终端，终端是安卓的，统一安装管理里面的应用，不能导出和外接 PC，这种情况下里面应用还需不需要做安全加固？我认为是不需要的。

2. 新技术/新理念伴生

• 举例说明，5G 需要 5G 的安全，在不了解网络切片、边缘计算的前提下，是不了解 5G 运营商开放能力的技术理念的前提下，是分不清楚需要做哪些安全，以及这些安全哪些应该由运营商提供，哪些需要企业自己实施这些建设模式、运营模式的。搞不清楚就会眉毛胡子一把抓，运营商或者安全厂商提供什么就做什么，容易缺漏，也容易被牵着鼻子走。

• 一定要多看多学，扩充自己对知识的理解和整体知识面。 微信、支付宝在推出小程序的时候，他们是怎么做的安全控制不太清楚，从认证、访问控制这几点来说又太泛泛而谈，说不到它实际的点子上。后来看到了一张支付宝小程序的架构图，在对支付宝小程序的开发平台、运行平台有了入门了解之后，才能够提出针对性的安全思路来，也就是哪些支付宝可能已经做了，哪些还需要我企业自己着重做。 图 6 高明的架构师必然是尽快学习，调整自己的架构思路，不避讳不完善之初，所谓“遇事不决，多看多学”。

2、重技巧，轻本源

我们先来看一个问题，是不是所有的新技术或者新理念都涉及安全？

1. 吴军在《硅谷之谜》这本书中，曾经用控制论、信息论、系统论来解释硅谷成功的奥秘，我们来看看这三论的含义： 系统论、控制论、信息论三者是相互联系的，其中的概念、原理是相互渗透的，把三者作为一个整体来看待，可以抽象出三条最基本的原理：反馈、有序、整体。

• 控制论：是指的是任何系统只有通过反馈信息，才能实现控制，或者说没有反馈信息的系统，要实现控制是不可能的。

• 信息论：指的是任何系统只有开放，与外界有信息交换，才有可能有序，或者说与外界无信息交换的封闭系统，要使之有序是不可能的。

• 系统论：指的是任何系统都是有结构的，系统整体的功能不等于各孤立部分功能之和，或者说没有结构的、反由孤立部分组成的系统是不可能的。

三论是现代所有信息技术的基础，从三论的含义能够看到，在缺少有效控制、有效信息传播和系统化结构的地方，存在不确定性，风险是不确定性的产物，而有风险的地方，就有安全。这是信息安全技术产生的根本原因。

2. 回溯风险的定义，风险=可能性*严重性。这是一切信息安全问题的定义。可能性和严重性都是实际业务场景的属性，这也是我在上面反复强调安全需求来自业务需求的深入分析这一原因，没有场景，就没有能够落到纸面上的信息安全。换句话说，纵深防御、安全评估、代码审计、安全测试、渗透测试等等所有的技术都是降低风险可能性和严重性的手段，所有手段都有一个你要保护什么场景的前提，这个前提不搞清楚，总是会有遗漏。场景是什么？我再说一次，是对用户群体、设备/环境、操作、业务的分析。

三、描述空洞，缺少灵魂

我在入行时首先接触到的是渗透测试、上线前的安全测试，我一直觉得自己非常幸运，一开始就碰到了信息安全最基本的攻防。后来我考虑，如果起点是防病毒、防火墙、IPS、WAF、服务器加固的策略编写者、维护人员，只要这个人尽心尽责，努力理解规则的内涵与外延，应该也能够奠定比较好的安全意识和基础，快速成长为架构师。 简单依靠年头、资历，希望熬成架构师，就如同身体好的运动员想依靠球龄成为球星一样，很容易被替代。意识、经验、善于总结的心思和好身体一样，一个都不能少。

• 以下图为例，我说这是我为某电商平台设计的安全架构，有什么问题？如果我又说这是我为某银行交易系统设计的安全架构，它也没什么问题。

• 它的问题在于空洞，所有信息技术的控制技术本来就是这几个点，只有更深入的二级模块、三级模块、特色模块，才能体现架构的价值。

在这里给安全设计提供一些建议，供交流参考：

1. 找一个深入了解的点，长期跟踪下去，在这个领域做到亲手干过、亲自看过、能够看懂最新的发展和变化。——这是要培养你的安全意识和敏感性，我个人在从事企业信息安全建设工作的过程中，一直在跟渗透测试报告，因为我自己干过，能看懂，也希望了解最新的技术和危害，所以也会对报告提出这样的要求。

2. 在出现新技术时，为了加深理解当然大家都会查很多资料，我的一个方法是同类型技术对比，他们的差异往往是新技术的关键点。举个例子，ABAC（Attribute Base Access Control） 基于属性的权限控制到底是什么意思，如果把它跟你用过的 windows 文件夹授权背后的自主访问控制技术（Discretionary Access Control，DAC）、你在管理后台用户管理功能上配过的基于角色的权限控制根据（Role Base Access Control，RBAC）做比较，就容易理解了，他们的不同就是答案。

3. 多总结、借鉴有相通性的技术理念，让他们成为你安全设计的新武器。我在理解谷歌零信任安全架构时对架构中描述的移动终端、移动用户持续鉴权印象深刻，后来接触到 ABAC，它是动态计算一个或一组属性来是否满足某种条件来进行授权判断，发现这两种理念其实是类似的。我上面说的场景分析方法也是从这些技术和理念中逐步形成的。正如乔布斯所言，

你在回头看的时候才知道点点滴滴是如何串在一起的。

当然，除了这些之外，作为一名架构师还需要文字能力、口头表达能力、持续跟踪最新技术和漏洞等，可以参考某些安全公司搞的技能树，但一定要形成自己的特色技能树。

祝你我持续进步，共同成长。