CareerOn联合创始人、首席技术官周燃Mccoy做客《老司机的安全“套”路》系列线上分享会，并担任第二期的主讲人。

本次分享会的主要内容围绕着：从架构角度看安全方面展开，下面是本次分享会内容的详细文字版。

产品⻆度的云安全

⼀般性设计原则

《老司机的安全“套”路》第二期：从架构角度看安全 上篇实际更多强调的是运维团队在“安全”这件事上该如何做。

作为安全架构团队，除了要做好运维团队的定位外，对安全产品及研发团队的⼯作思路和团队定位⼀样⾮常重要。

接下来讲讲安全产品在“安全”这件事上的具体思路和定位。

⾸先要搞清楚云安全各个产品线的具体内容以及其主要作⽤和协作关系，包括⼀些要注意的问题。

以下将要说的产品类型之间并不是同⼀标准下的分类，所以多个分类间的安全产品有不完全的重合。

之所以会把不同分类标准下的产品同时列出，原因在于每个分类都⽆法涵盖云安全的⽅⽅⾯⾯，很多产品⽆法按同⼀标准分类，⽽且以下的列举也并⾮是完整的，更多⽬的是做演示说明。

1、边界防御性产品

防⽕墙（主机型，⽹络型）；WAF（主机型，⽹络型），漏洞扫描与补丁推送等等。

边界防御产品在⽬前很多⼈⿎吹⽆边界的时代仍然有其不可替代的地位，其意义在于以较低的成本解决绝⼤多数安全问题。完全阻断边界安全问题不是边界防御的⽬标，也是不可实现的。⽐如漏洞问题，这是个永远⽆法杜绝的问题。

边界防御性产品的基本评价标准有⼏点：

A、不给边界功能引⼊故障：⽐如不能因为装了WAF导致web容器挂了，或者资源占⽤率过⾼等等问题。

B、没有明显的程序bug，⽐如明确设置了80端⼝不允许被访问，这个端⼝如果仍然能被某个客户端访问，这就是明显程序bug。这⾥的bug不包括⼀些安全效果性问题，⽐如未识别的攻击类型就不在此之列。

C、安全问题识别率符合预期：这⾥之所以不说具体识别率要到多少，这是因为任何⼀个产品都有它的发展阶段；任何业务对安全性的要求也都有⼀个限度控制。只要产品是符合设计预期的，符合具体业务对安全性要求的，就算合格。

D、产品间功能重合度低：不同的边界防御产品间要有明确的功能定位，杜绝叠床架屋；多个边界防御产品间的“安全间隙”要尽可能低，充分覆盖边界安全问题的⽅⽅⾯⾯。

2、纵深防御性产品

所谓纵深防御型产品，实际上并⾮指某个或者某些特定产品。纵深防御更多指的是安全产品间的协作关系，纵深防御型产品与边界防御产品有不完全的重合关系，⼆者考量标准不同⽽已。

通常，某个具体的安全点，不可能有任何安全产品能做到滴⽔不漏；⽽且，基于投⼊产出⽐考虑，也没有必要把它做到滴⽔不漏的程度。

⼀个产品，通常只解决某个安全点的绝⼤多数问题，那些被漏掉的安全问题，并⾮不管了，⽽是需要进⼀步的其它产品，在更合适的安全点上予以处理，这就是纵深防御的通常做法。

以病毒⽂件扫描为例：

通常以ReadDirectoryChange(windows 系统)或者inotify(linux系统) 监控绝⼤多数的⽂件变动，并予以实时处理；

但是因为这两种⽅式都是⾮阻塞的，所以仍然有部分⽂件会逃过检查逻辑。

基于此，通常会在系统的模块加载处再加⼀个阻塞式处理逻辑，对恶意程序的运⾏予以直接阻断。

这个过程中，通过⾮阻塞的⽅式处理掉了绝⼤多数恶意⽂件，获得了系统性能的提升；

同时，⼜以阻塞式的处理，对可能的极少数漏⽹之⻥予以最后的阻截，解决了安全性遗漏。

这就是典型的纵深防御思路。

纵深防御产品的⼏个基本评价标准：

A、是否以最低的成本解决尽量多的安全问题：这⾥是定性的，具体标准还是要结合实际情况分析，但基本原则是解决其所在安全点的绝⼤多数安全问题，个⼈认为⾄少解决80%以上问题。

B、漏掉的少数安全问题是否有补救⽅案，补救⽅案所在安全点是否合理：成本⾜够低，效果⾜够好。

C、多个纵深防御产品间功能重合度低，避免叠床架屋的做法。

3、主机反⼊侵产品

主机反⼊侵产品的基本⽬标是阻断或者实时发现主机被⼊侵的⾏为，⽬前市⾯上这类产品⾥⽤户量最⾼、检测及防御效果最好的是安全狗系列产品，但是其缺点在于过于依赖本地⾏为分析，对⼤数据分析以及运维⽀持不⾜。

除了有agent 的主机反⼊侵产品外，还有另⼀类⽆agent、基于⽹络⼤数据分析的主机反⼊侵产品。这类产品的优势在于不需要侵⼊⽤户主机，⽤户体验好，但缺点在于因为很多重要数据拿不到，⼊侵发现效果实在差强⼈意。

⽽且在公有云环境，这种⽅案对第三⽅安全⼚商实在不够友好，⽬前这种⽅案基本⽆⼈使⽤。但在某些特定场合，配合agent 数据也能提⾼主机⼊侵问题的检出率，⽐如DNS 隧道类⽊⻢的检测、内⽹扫描⾏为等等。

这类产品的基本评价标准为：

A、较⾼的⼊侵发现率。之所以不说⼀个定量的数字，原因与之前说过的⼀样，产品的不同阶段以及针对的不同业务，对⼊侵发现率都应该有相对合理的要求，⽽不是⼀律100%，这样本身不现实，也不符合投⼊产出⽐的原则。

B、对于有阻断功能的主机防御产品，对发现的⼊侵事件，其阻断成功率必须100%，否则产品不合格。

C、较低的资源占⽤，按经验，1分钟平均cpu 使⽤率不得⾼于0.1%；10分钟平均内存占⽤不得⾼于50MB；峰值CPU占⽤率不得⾼于25%，峰值内存占⽤不得⾼于100MB。这些定量的数字，你要是问我是怎么来的，我确实说不出⼀个靠谱的理由，这些更多来⾃于经验。

D、系统不得因为装了主机防御产品后有明显性能下降。

E、可运维性：是否⽅便运维，是否对关键操作和关键数据有记录、可追溯。

4、应⽤安全产品

这类产品最⼴为⼈知的就是WAF，还有诸如数据库加密产品、数据库防注⼊产品、账户防爆破产品等⼀系列产品。这类产品通常防御效果较好，但存在⼏个问题：

A、深度侵⼊⽤户应⽤，容易导致兼容性问题和⽤户应⽤稳定性问题。

B、⼤量接触⽤户数据，存在数据泄密可能性以及⽤户隐私等法律问题，通常在接⼊前必须得到⽤户授权。

这类产品通常有以下⼏个评价标准：

A、兼容性问题：在其应⽤领域是否兼容常⻅应⽤及其各个常⻅版本，否则不合格。

B、是否有不经授权获取并使⽤⽤户数据的⾏为。

C、资源占⽤及对性能影响是否在⽤户可接受范围内。

D、可运维性：是否⽅便运维，是否对关键操作和关键数据有记录、可追溯。

E、安全问题发现率是否满⾜预期。

5、⽹络安全产品

这类产品最⼴为⼈知的就是DDOS⾼防了，除此之外还有基于分光模式的WAF，以及基于cname 的云WAF等等。

这⾥可以明显看出，不同分类标准下，同⼀个产品可能落在不同的产品类型⾥。这个问题在上⾯有过说明，不必在意。

这类产品通常有以下⼏个评价标准：

A、使⽤复杂度：⽐如cname 模式的云WAF因为很多⽤户觉得使⽤复杂⽽拒绝使⽤。

B、检出率及拦截率满⾜业务需求，符合设计预期，之所以⽤这种定性标准，之前有说过，不再重复。

C、不因⾃身故障或者其他原因导致客户⽹络接⼝故障。

D、对安全产品运营⽅的资源消耗在预期范围内。

E、对客户⽹络接⼝性能的影响在预期范围内、满⾜业务需求。

6、安全运维类产品

⽐如威胁情报、态势感知、运维⼯具、扫描器等等。这类产品更多满⾜运维需求，根据云平台是公有云还是私有云的区别，会有不同产品要求，⼀般有如下评价标准：

A、数据覆盖范围是否满⾜业务需求。

B、数据及时性、使⽤便利性、详细度是否满⾜业务需求。

C、数据准确度是否满⾜业务需求。

D、是否有与之配套的分析、存储⼯具。

E、噪⾳数据的剔除度是否符合预期。

7、云平台对各个产品的取舍原则

A、根据公有云、私有云及企业内⽹的情况，依据上⾯说过的业务及客户特点确定产品重点和优先级。

B、根据平台⽬标和平台需求以及客户特点确定哪些产品是要直接⾯向客户的，哪些产品需要以运维为缓冲然后输出加⼯过的结果的。

C、保证平台稳定与安全的产品，⽐如DDOS产品必须有且必须与云平台同时投⼊使⽤。

D、应⽤安全类产品因为涉及到具体应⽤和⽤户数据等原因，通常不应作为默认选项，⽽应该根据⽤户请求做出处理。

E、各个产品间应该有协作关系，不能出现孤⽴的产品点；“安全间隙”应该⾜够⼩，安全点应该⾜够⻬全，但各安全点间必须重点突出，不能平均⽤⼒。

F、平台只做重点的、核⼼的功能，其它安全功能尽可能开放给第三⽅安全⼚商，形成安全⽣态。

以上内容其实就是对于安全产品团队的基本要求，我以安全架构的⻆度分享了：安全运维该怎么做，安全产品及技术该怎么做。

其中，安全运维因为涉及的⾯⽐较多和杂，只是做了些原则性讲解。

架构⻆度，安全运维有更多细节和注意的地⽅值得⼀说，有机会的情况下，我会专⻔针对安全运维做更细⼀些的分享。