企业信息安全架构设计与评审目录一、引言 (3)二、什么是安全架构 (3)三、安全架构的基石 (4)四、安全设计原则 (7)五、安全架构设计关键点 (8)六、安全评审 (14)七、小结 (15)一、引言业界谈论安全架构的文章很多，但基于系统架构去讨论其安全架构设计不多，本文从安全架构定义为出发点，结合系统架构方法论，阐述安全架构设计思路和设计关键点，抛砖引玉，为想从事安全架构设计与评审工作的小伙伴们提供快速导入的思路。
二、什么是安全架构关于什么是安全架构，安全架构到底需要做什么，似乎很多人一直没有清晰的概念，这一点可以从各大企业在招聘网站上发布的安全架构师招聘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的问题。
