上一期讲述了安全架构的安全性架构。实际上一个综合架构的设计不可能只考虑或者过分的考虑安全性，业务架构与安全架构的综合分析才是一个综合架构应该考虑的事情。那么如何做到鱼与熊掌兼得？

这里涉及一个问题，业务架构应该是什么样子的？初期为了更好的融入架构师这个角色，我特意请教了业务开发架构师与运维架构师。

开发架构师大概的意思是，开发架构的设计要基本是成套体系，比如 maven库的设计 ，比如spring 开发框架 方便代码规范，比如 升级业务版本 的tomcat jar包覆盖，比如 多个业务的关联性与架构的可复制性 等等。

说实话我没有加入过大型项目的开发团队，对于一套开发体系了解的不够多，开发架构师的大概意思能够听懂，但是细节还是需要进一步琢磨，相关于业务的架构设计是相当复杂的，安全人员能了解详细的业务架构设计是最好不过的，但是一般只需要了解架构师在设计架构落实会用到哪些组件就可以了，这是一个比较低的要求。

运维架构师给我的回复是要保证业务的 稳定性 、保证业务的 网络 不会瘫痪，这里运维总监还小小的幽默了一下：你看阿里的运维工程师，每年双11都要晒扛了多少多少流量，如果我们也能做到还用担心没钱赚吗。是的，运维架构师关心的是系统、业务的稳定性，体现最多的还是服务器和网络层面，应用层面是开发架构师考虑的。

但是不管是开发架构还是运维架构，一套体系是必须要存在的，就是 监控与告警系统 。

先从开发架构讲起，有人说业务告警要怎么告警？难道就是监控哪个IP返回403？哪个IP返回200？当然不可能是这么简单的，监控的意义在于方便排查问题发生的原因以及及时的修正问题。业务监控大致分为几种：

1. 业务中断监控

2. 业务恶意访问监控

3. 业务实际问题（比如转账金额与现实不符，转1.1111元之类）

4. 业务BUG监控

针对于业务中断，顾名思义是针对业务的可用性做的监控，哪些原因会导致业务中断？比如服务端口down了，比如线程跑满了等等，这是从应用层的角度说，从网络层角度可能是DNS服务器出现问题了或者网络堵塞等问题，记忆犹新前几个月的114DNS服务器出现故障，直接导致使用此DNS服务器的业务出现大面积瘫痪，当然这里还是建议要配置静态双DNS解析，这样对于整个生产环境会减少一些不必要的麻烦。

针对业务恶意访问的监控，体现在垃圾报文的发送堆积，举个小小的例子，我们要进行网上支付交易，正常情况我会拉一个账单，付款，收单等待拿货，那么非正常情况是什么样子呢？我会拉一个账单，不付款，在拉一个账单，不付款……如此循环上万次，这样的行为就算是恶意访问，由于此恶意访问属于业务的恶意访问，所以需要开发架构设计监控。

针对于业务实际问题，这个范围比较广，实际上应该是在代码规范中就想到的问题，比如输入了20位的手机号、33位身份证等等非合规的信息。

业务BUG监控其实是实时进行的，这里说的BUG不仅仅是致命的代码缺陷，还包括UI的优化设计等等，如何监控这些效果反馈也是开发需要做的。

运维监控大致分为以下几种：

1. 服务器状态监控（CPU、内存、磁盘容量等等）

2. 网络流量监控

3. DNS解析监控

4. 日志监控

5. 物理监控（机房状态等等）

服务器状态监控很简单，这是每个运维都必须掌握的基本技能，监控CPU使用率、内存使用率、磁盘容量、线程、I/O读写速率、配置文件是否变更等等，这么做的意义在于保证服务器的可用性。

此处附一个简单监控CPU的小脚本：

#!/bin/bash
for ((i=1;i<=3;i++))
do
echo `top -b -n 1 |grep top|awk '{print $3}'|cut -f 1 -d'.'` >> cpu.txt
echo `top -b -n 1 |grep Cpu|awk '{print $8}'` >> cpu.txt
sleep 10
done

脚本持续记录时间与CPU空闲率。

当然要配合联动告警脚本一起使用才能达到自动化监控的作用。

但是在这里推荐使用zabbix实现自动化监控，详细见https://www.zabbix.com

网络流量监控意在防范大流量导致网络堵塞，这里有可能是正常的流量，像双11那样的大型业务导致流量激增，也可能是流量攻击，不管怎样，有一套成体系的监控告警应急系统对于运维来说是非常必要的。同样zabbix也可以达到此效果。

有时服务器本身与业务本身并没有故障，但是DNS解析出了问题，像前几个月的114DNS解析服务器故障，像DNS污染攻击等等都会导致业务故障，监控DNS也是运维的工作之一。

日志监控与物理监控就没有什么好说的了，基本上是日常工作。

针对运维与业务的特性，综合考虑这些情况，加之安全架构特性，设计安全逻辑架构图如下：

当然咱们在上期其实讨论了安全性与可用性，没有涉及保密性的内容，其实保密性是3部分，一是动态数据加密，比如传输加密等，二是静态数据加密，比如数据库加密等，三是访问加密，比如跳板机。

综合所有情况设计以下架构图：

每个业务都存在特殊性，整体架构的设计也同样大不相同，但是基本的设计理念大同小异，掌握架构设计理念，在拥有一部分实战经验，相信大部分安全人员都能设计出属于自己的一套架构体系。

根据第一期所接收到的情况来看，很多人其实对于体系建设是有疑问的，为什么要进行安全系体的建设 ？在这里想与大家讨论这么几个问题：

1.体系建设的必要性
2.高层在业务建设与战略发展过程中关心的事情
3.体系建设带来的优势与好处
4.体系建设的运营与维护

第一点：体系建设的必要性

基本上每个月都会有几篇文章来讲述如何建设安全体系架构，但是很少有文章会阐述为什么要建立安全体系架构，其实安全体系架构是一个企业在安全方面的综合实力体现，从管理到落实，安全体系架构不仅仅是提高了业务的安全性、合规性，更是企业实力与底蕴的体现，举个例子，我所在的是一家互联网金融公司，对数据安全极为重视，毕竟跟钱打交道的安全性一定不能差，那么在项目洽谈的时候合作方都会问：你们的安全架构是怎样？怎么保证合作中数据的安全 等等，这时候一套标准的安全体系架构设计图或者分析报告建设报告给到对方，对方会觉得在安全方面真的是下功夫，而且比较专业，合作的意向也就会多一些。当然这只是从安全的角度，业务本身也要有过硬的实力。

第二点：高层在业务建设与战略发展过程中关心的事情

高层其实对于体制建设，甚至有没有体系架构都不关心，他们关心的是业务不要中断，不要被黑，或者被黑了能尽快恢复减少损失。而高层的这种需求会体现在中层设计架构中，在架构的整体设计上会考虑到安全架构的设计，因为第三方是不可控的，不可能祈祷黑客永远不会黑进业务，也不可能祈祷网络永远不出现故障。那么想到一切会影响业务的情况后，针对这种情况进行架构设计，最大程度保证高层的需求才是架构的意义。

第三点：体系建设带来的优势与好处

其实第一点中涉及了一部分好处，但是并不全面，体系建设带来的好处不仅仅是业务合作上的，还有业务本身安全性的提高，最想说的是还有合规信誉的问题。目前在安全领域我所在的公司通过了计算机等级保护3级、PCI DSS、非金行业支付过检等等认证，其实每一个认证背后都有体系的支持，每一套业务在设计初期就考虑了安全性，考虑了安全认证的问题，才能很顺利的通过这些认证，从而提高公司在安全领域的信誉。

第四点 ：体系建设的运营与维护

一个体系的推出必然少不了运营和维护工作，包括文档记录、管理制度建立等等，这些文案要合乎业务，同样要被贯彻落实，否则体系就是个空架子。

体系不是一个概念，而应该是一个地基，只有打好地基，房子才会盖的更高，更加坚固。

下期将讲解具体安全脚本的开发与使用。

*本文作者：煜阳yuyang，本文属 FreeBuf 原创奖励计划，未经许可禁止转载。