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

步骤一：目标与范围

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

【图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】“安全架构概览图”核心

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

安全评审

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

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

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

小结

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

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

参考资料：

本文作者：钱君生，科大讯飞集团安全技术专家，先后从事IAM、安全审计、WAF、RASP等产品研发，目前主要负责应用安全、安全平台、团队能力建设等安全相关工作。微博：weibo.com/heyongv

-------------------------------------------

如您有涉及以下方向原创文章，乐于分享，可以后台联系，君哥将会第一时间回复和联系：

1、解决企业安全建设实践的具体问题，比如安全资产管理、漏洞运营、应用账户滥用检测、隧道穿越流量检测、反弹Shell防护和检测等；

2、各类安全实践或解决方案，如远程办公安全实践、开源组件检测、内网全流量检测、终端数据安全实践等；

3、各类安全事件复盘思考、攻防对抗复盘总结、安全工作推进方法、安全度量指标建设、安全汇报和安全管理思考等；

4、安全合规、监管要求落地、安全审计等；

5、安全从业感悟、安全职业发展、安全培训和认证历程、安全团队和人才培养等。

---------------------------------------------------------------------------

企业安全建设，离不开“守望相助”。金融业企业安全建设微信群，入群方式：请加以下微信为好友，备注：姓名-公司-负责领域。销售从业人员暂时不邀请入群，不保证每位申请者入群，敬请谅解。

扫一扫，加入企业安全建设实践群

未能加入“企业安全建设实践群”的朋友，可以加入知识星球，查阅每周实践群讨论话题和发言记录。

知识星球：金融企业安全建设实践

附注：

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!