转载

钱君生：安全架构设计与评审

引言

业界谈论安全架构的文章很多，但基于系统架构去讨论其安全架构设计不多，本文从安全架构定义为出发点，结合系统架构方法论，阐述安全架构设计思路和设计关键点，抛砖引玉，为想从事安全架构设计与评审工作的小伙伴们提供快速导入的思路。

什么是安全架构

关于什么是安全架构，安全架构到底需要做什么，似乎很多人一直没有清晰的概念，这一点可以从各大企业在招聘网站上发布的安全架构师招聘JD上看出来，好在对这些招聘要求归类分析后，总的来说，对安全架构的要求基本集中在以下两个方向：

钱君生：安全架构设计与评审

【图1】安全架构的含义

管理型安全架构，此类安全架构的含义是负责企业的整体安全规划，包括安全组织、角色分工、岗位职能、团队建设、安全体系、预算投入甚至整个安全部门的发展与规划。工作内容比较繁杂，兼有技术管理和职能管理两方面要求。这种职能下的安全架构人员从本质上说更偏向于职能型的安全管理人员，承担着企业安全建设中的高level层级的日常工作。
技术型安全架构，与管理型的安全架构不同，此类的招聘在岗位描述上对应聘者的要求往往更明确。比如负责网络与信息安全项目建设、安全架构设计、安全事件处理、内部安全技术培训等；负责安全风险评估和安全日志审核，指导并跟进开发团队的问题修复；负责对接外部，响应安全需求，支持客户特性问题的解决和咨询。准确地说，此类安全架构的招聘要求更符合在大多数企业的IT信息化部门对安全技术人员的安全架构的定位。

了解了这些背景，我们把本文的安全架构的范围定义在技术型安全架构中，讨论的内容主要围绕着信息系统的安全架构设计而展开，以减少安全架构定义不清晰给阅读者带来的困惑。

安全架构的基石

我们知道安全架构是围绕着信息系统架构的安全性而展开的设计工作，那么它的基础是信息系统架构。离开了信息系统架构，而大谈安全架构就成了无水之源。所以，在谈安全架构之前，我们先了解一下信息系统的架构方法论，并统一讨论中所使用的规范语言，方便参与安全架构的各利益方对安全架构的理解。

在信息系统的架构设计中，UML当之无愧的成为了统一的官方语言，基于UML进行系统分析和架构设计是每一个架构师的必备技能，同样作为安全架构师，也是如此。安全架构师不但要熟悉UML语言，也要熟悉当前所在的企业中业务架构师们在日常工作中所使用的系统架构设计规范，能通过系统架构设计的文档的阅读，理解架构设计意图，识别架构设计中的安全缺陷点，补充安全设计和安全改进建议。

在这里，我们主要讨论大中型信息系统的安全架构（小型系统或者简单如CMS，因为它们太简单，甚至实际工作连系统性的架构设计都不需要，更谈不上安全架构），信息系统架构是通过在不同组件间的设计输出标准设计产物来完成架构设计的，一个完整的架构设计主要包含逻辑架构、物理架构、开发架构、部署架构、技术组件选型5个部分。其中每一种架构主要关注的内容如下：

逻辑架构：逻辑架构关注的主要是功能，从逻辑上对整个信息系统的分层，比如MVC所表示“模型层、展示层、逻辑控制层”经典的三层结构；比如大型信息化系统的表示层、应用层、服务层、数据层四层结构。如下图所示：

钱君生：安全架构设计与评审

【图2】某校园系统逻辑架构图

物理架构：物理架构主要关注是机房、网络、服务器、数据存储等方面内容，是整个架构设计中最关键的架构视图。通常由各类资源的物理位置、网络与服务器的部署情况、使用产品的规格参数等细节以及基于整个架构上的高可用性、可伸缩性、性能参数、备份与恢复策略等内容构成。其概览图如下：

钱君生：安全架构设计与评审

【图3】物理架构示意图

开发架构：开发架构是面向研发人员所提供的对系统逻辑架构中各个组件的定义，是指导和约束开发人员在进行代码开发时如何对逻辑组件进行划分。比如逻辑架构示意图中的表现层，分别拆分出portal.war（对应于门户）、common-query.war(对应于综合查询)、reports.war（对应于报表）。当然在做架构设计阶段，你也可以不用设计的这么细，把所有表现层功能放到一个war包里面,比如front-server.war，包含门户、综合查询、报表的功能。如果项目不涉及软件开发，则通常没有此架构输出产物。
部署架构：部署架构是指整个信息系统中的各个组件部署在IT环境（主要是服务器）中所呈现的状态或相互关系，是对物理架构中各个组件以部署的形式所呈现更细致的描述。比如上图中的门户组件在哪个区域部署，涉及哪几台服务器，每台服务器上要部署几个portal.war；数据库服务器部署在哪个区域的哪几台服务器上，如果是Oracle数据库RAC是怎么部署的等等；在很多IT信息化架构设计中，把部署架构作为物理架构的一个子部分，不会单独出来。
技术组件选型：主要是各个组件的详细清单，包含组件类型（操作系统、数据库、负载均衡、中间件、编程语言运行环境、安全设备等）、组件使用范围（所有服务器都使用、网络出口使用、某个子系统使用等）、组件名称及版本、为什么选择此组件等。

基于上述5个架构设计视图，当我们在开展安全架构设计工作时，需要依附于它们之上，添加必要的安全性设计，以满足信息系统的安全性需求。同时，我们也要明白，不同的架构设计视图关注的侧重点不同，我们所做的安全设计也要分布在不同的架构设计视图之中，而不是脱离原有架构设计，去单独的弄一个安全架构设计（当然，如果是项目建设中客户强诉求，要单独做安全架构设计方案或者因为等保合规，那就另当别论了。如果是自建项目，建议还是以实用为主）。

安全设计原则

接触过安全架构设计或者学习过安全架构设计相关知识的同学，可能在不同的书籍或者安全会议上听说过许许多多的安全设计原则，比如公开原则、最小特权、默认不信任等。实际情况是，过多的安全设计原则往往不利于架构师做出正确的选择，尤其是安全专业知识储备不够的架构师。在这里，我们说安全设计原则只包含两条，分别是：

5A 原则：即身份认证Authentication、授权Authorization、访问控制Access Control、可审计性Auditable、资产保护Asset Protection [1]，这五个词的第一个英文字母简称，其含义是我们在做安全架构设计时，对于物理层、网络层、系统与平台层、应用与数据层的安全架构设计，都要从这5个方面考量设计的合理性。
纵深防御原则：纵深防御通常是指不能只依赖单一安全机制，建立多种机制，互相支撑以达到比较安全的目的。比如为了保障某个住户家里现金的安全，第一道防线是小区的保安，在小偷进入小区时鉴别；如果保安被欺骗了，则还有楼道口的防盗门；若楼道口的防盗门也被小偷破解了，则住房室外的大门是第三道防线。小区保安、楼道口防盗门、住房室外的大门他们之间的防护，就构成了我们说的纵深防御原则。

5A原则重点强调每一层安全架构设计的合理性，是横向的安全防护，强调的是宽度；纵深防御是对同一问题从不同的层次、不同的角度做安全防护，是纵向的，强调的是深度。这两个原则相结合，共同将我们的安全架构设计构成一个有机的防护整体。

安全架构设计关键点

在前面的章节我们已经谈到了架构设计过程中出现 不同的架构视图 ，同时,也了解到 架构设计主要是在系统的组件间进行的 。业界的架构方法论大多数是围绕软件设计去做的，而在实际工作中很多架构设计不一定涉及所有的架构视图，所以我们先将上述架构方法论的逻辑架构、物理架构、开发架构、部署架构、技术组件选型5类架构视图中安全关注点标明出来。内容如下：

逻辑架构：从横纵两个方面，关注组件的安全设计。纵的方面是指从安全性考虑，组件之间是否符合其相互独立性，比如说：管理端应用和用户端应用，从前端到后端在组件设计上哪些应该相互隔离；横的方面是指分层架构是否合理，例如上文提及的表示层、服务层、数据层三层是否在架构设计上满足区域隔离条件下的组件部署要求，表示层的门户服务与服务层的restful接口服务是否拆分，如果未做合理拆分，部署时仅将门户服务放在DMZ区则变得不可行。
物理架构：是安全架构设计关注的重点视图，基本涵盖我们通常说的从物理层、网络层、系统与平台层、应用与数据层的安全设计。我们将在接下来的章节中重点阐述其内容。
开发架构 ：在安全架构设计阶段，安全关注的内容更多是在组件间的交互，也就是我们通常说的业务安全。要结合业务场景，通过时序图来描述安全性设计。比如，涉及支付流程，订单支付安全校验是如何设计的；门户登录认证的安全性是如何设计的。一般来说，架构设计阶段关注的重点是组件，不会关注到具体场景业务流程的安全性（大多数在详细设计时关注），除非高危场景的安全设计才会在此阶段关注。如果真的有必要在当前架构视图中做此类安全设计，建议安全人员整理一个checklist，指导业务架构师去设计。checklist可以整理一系列类似于当前系统是否提供列表查询页面、列表查询页面是否可以不包含敏感信息、列表页面单次查询最大数据条数不得超过多少条、连续查询多少次记入安全审计流程等等的安全策略。
部署架构：在安全方面，此视图重点关注服务器上的部署情况，比如当前主机上部署哪些组件，是服务部署还是容器化部署，使用什么账号来部署，文件权限控制是什么，必须开放哪些端口，启用哪些服务，多个相同服务之间进程的独立性如何等等。
技术组件选型 ：从组件选型和版本包含的漏洞两个方面考虑，比如说，可以选择linux不建议使用Windows操作系统；可以选择Java语言开发则不建设使用PHP语言开发；可以使用Gson不建议选择fastjson；可以使用新版本包含CVE漏洞少的Spring组件不建议使用老版本的Spring等等。

理解了各个架构视图与安全关注的重点，接下来我们将结合安全架构设计步骤和5A设计原则，讨论物理架构视图中的安全设计关键点。

步骤一：目标与范围

通过上述内容我们明白了不同的架构视图对应于不同的分层，但当我们在实际工作中从事架构设计时，首先是分析需求，通过需求来明确做架构设计的目标。当然，做安全架构设计也是如此，我们通过需求分析，来获取安全防护的目标，同时，也是明确做安全架构设计所涉及的范围。如下图所示：

钱君生：安全架构设计与评审

【图4】IT信息化分层结构

如果你做的安全架构设计仅仅是SAAS服务，其他层次均依赖于公有云，则重点应关注Application、Data、Runtime三个层面的安全，其他的安全则需要和公有云提供商明确安全边界与协作流程；如果你做的安全架构设计是一个系统总集成的安全方案，则从Networking、Storage至Application都需要关注，这就是步骤一强调明确目标和范围的含义。通过目标和范围的明确来明确参与系统建设的各方的安全责任边界，这也让架构师知道自己设计的重点在哪些分层上，该考虑如何去设计，这也是安全评审第一个需要check的问题。

从源头看，明确目标和范围的上游是安全需求分析，只有需求分析清楚了，才能做出正确的设计。至于需求分析的过程中，是使用微软的STRIDE做威胁建模还是使用专家知识库，那不是本文讨论的内容，这里仅仅提及一下，大家明白为什么要做步骤一的事情即可。

步骤二：5A原则与分层设计

上文中我们已经讨论了各个架构视图中安全关注的重点，对于物理架构视图因涉及内容较多，我们接下来就结合5A原则，从架构中每一个分层去看安全架构设计中的关键点。

物理层

主要是机房的建设为主，大多数架构师不涉及，在此不做过多讨论。

网络层

网络层涉及的内容最多，我们主要从纵深防御和5A两个原则去讨论。在传统IT系统建设中，网络边界和区域划分是纵深防御思想的体现，从南北向看安全防护的设计。而身份认证、授权、访问控制主要依赖于设计在架构中的各个安全组件。比如常用网络安全套件中的防火墙、NAM、NAC、网关、网闸；比如不同用户、不同角色的安全访问通道。可审计性主要体现在事前、事中、事后的可监控、可发现、可溯源性，对应于入侵检测和安全审计，既要提供入侵时的检测，又要具有事后的日志分析，提供溯源证据。资产保护在网络层主要指抗DDoS防护、链路冗余备份、资产管理与漏洞扫描等。在私有云或共有云的网络环境中，网络边界和区域划分可能没有传统IT环境那么清晰，但大的区域划分还是存在，只是不同内部系统间通过VPC控制边界线。这类环境里，大多数系统建设时部署的网络结构是IDC人员分配的，这是安全架构时需要注意的。典型的网络层安全架构如下图所示：

钱君生：安全架构设计与评审

【图5】某医院网络安全架构拓扑图

系统与平台层

主机和平台层的身份认证、授权、访问控制主要依赖于主机安全基线或镜像以及安全组，比如用户远程登录方式、账号与口令、端口开放等；而资产保护和审计主要依赖于安全漏洞管理、主机入侵检测、主机防病毒等。在架构设计时，可以通过引入安全组件解决此类问题，比如HIDS、IAM、堡垒机等。

应用与数据层

仅是IT基础设施建设，可能不包含此层的内容。如果包含应用与数据层，从5A原则的思路去分析，其中身份认证、授权、访问控制大多数都是通过PKI+SSO+RBAC权限控制模型来解决的，而对于API接口的身份认证、授权、访问控制大多数是引入API安全网关。比如采用RBAC+用户关系，通过用户—>角色—>菜单—>按钮—>链接—>数据维度，构建整个应用层的身份认证、授权、访问控制；同样，通过在API网关中引入API生命周期管理，注册—>发布—>认证鉴权—>限流或熔断—>销毁来提高API的安全性。对于应用与数据层的可审计性，也可以引入安全审计平台，接入中间件（tomcat、nginx、mysql等）日志、应用操作日志达到可审计的目的；应用与数据层的资产保护包含WAF、数据脱敏与加密、加密算法的安全以及与业务场景相关的业务安全。

通过上文的分析我们可以看出，在架构设计中，大多数场景下的安全保障都可以依赖引入安全组件来解决。

步骤三：安全架构概览

通过分层的安全架构设计，最终我们会得到一个整体的安全架构设计图，这里我们称之为“安全架构概览图”，将其抽象一下，其表达的内容大体类似于下图所示：

钱君生：安全架构设计与评审

【图6】 “安全架构概览图” 核心

在安全架构概览图，我看到了设计中重点关注的安全项：

整个系统与外部的边界、系统内部DMZ与核心应用、数据的区域边界以及各区域分布。
不同区域的用户或不同的角色访问方式与通信链路安全设计。
不同区域之间，应用的分层与安全交互协议。
不同区域的部署的应用和敏感数据类型以及安全保护措施。

安全评审

安全评审的本质的验证安全架构设计的合理性，评审人员通过阅读上述的5个架构设计视图，分析其安全设计是否满足安全要求，起到审核安全架构设计的目的。

但事实上，大多数情况下是前期的安全架构设计做不好，等到安全评审阶段就变成了一次技术性的安全风险评估，安全人员评估后提出安全设计思路和改进建议。这是违背安全架构设计的本意的，相当于跳过安全设计直接到评估和整改，缺少了设计的过程。同时，安全架构设计在企业内部应该由业务架构师去担任此项工作，安全评审应该由安全架构师或安全专家担任。两个不同的角色可以从多个角度去审视系统的安全架构，才能更好的保障安全架构设计的合理性。

至于安全评审的内容，熟悉安全架构设计的人自然也就是熟悉了安全评审时所需要关注的内容。不同的是，作为安全评审的安全人员，结合了自己的安全经验，从专家视角，来弥补业务架构师安全视野的缺陷，起到审核、把关的作用，而不是更多的参与到安全架构设计中去。

小结

站在业务的视角去看，无论是安全人员还是业务架构人员去做安全架构设计，都不重要，如何通过标准化的流程来保障架构设计的安全性、如何通过标准化的设计语言让参与架构落地的各方都能看明白安全架构设计才是重要的。我们也了解到作为安全架构人员，需要熟悉架构设计的基本表达语言和安全设计经验，这都是需要很长时间的积累。但同时我们也看到了安全架构设计是有它的可操作流程和设计规范，所谓“通则不痛、痛则不通”，一旦理顺了其实也没有那么难。

系统架构设计本身就是一件复杂的事情，融入安全架构设计就更为复杂，在本文有限的篇幅内，通过系统架构设计+安全的设计思路，粗浅地谈论了安全设计关键点，希望能在安全架构设计上给予你些许帮助！关于某个安全场景下的安全架构设计实战，建议你去阅读郑云文《数据安全架构设计与实战》一书。

参考资料：