互联网安全架构设计原则

1、纵深防御

整个企业的安全架构是由多层次的安全域和对应的安全机制构成的，要保护关键数据，需要层层设防，层层包围，这样就不太可能被攻击者得手一点就全部失守。

从产品设计层面来讲，即使软件依赖的外层系统安全机制破坏时，仍然能保障应用自身数据的安全性，例如在 iOS 越狱的环境下，系统沙箱失效而应用的数据使用自加密。在 HTTPS 被劫持的状态下，仍然能保证 post 数据中的敏感信息难以破解。

2、多维防御

对同一种攻击有多种维度的防御和检测手段，逃过一层还有额外机制，例如，对抗 SQL 注入，第一层 WAF，第二层 Web 日志分析，第三层 RASP，第四层 SQL 审计。又譬如从 SDL 环节来看多维：防御漏洞第一层是静态代码扫描，第二层是编译过程，第三层是运行时保护，确保的是当其中一层失效时还不至于功亏一篑。

3、降维防御

降维防御是针对降维攻击而言的，大意是在攻击者不可达、不可控、无感知的更底层进行检测和拦截。例如在内核态检测用户态攻击，使用 RASP 在运行时而不是在 cgi 层面检测 webshell, HIDS 的攻击检测不在本机判定，而是在云端计算，入侵者对其无感知。

4、实时入侵检测

实时入侵检测偏重的是事中进行时的检测能力而不是事后的指标。大规模 IDC 下，例如 10 万多台服务器规模仍然能做到 30 分钟以内即时告警，对正在进行中的入侵活动实时发现，例如攻击者刚上传了 webshell 就能立即告警，而不是等入侵活动阶段性结束，攻击者装了 rootkit 才告警。

5、伸缩性、可水平扩展

因为互联网的业务架构本身追求水平扩展，所以传统上支持几千个节点的产品，如 QRadar、Arcsight 等在互联网环境下基本无用武之地。不能随业务增长而扩展的安全解决方案是一个致命伤。任何安全手段，无论是 WAF、HIDS，还是 IPS，只要不能水平扩展，就一定不是好的解决方案。

6、支持分布式 IDC

互联网公司的生产网络一般是多 IDC 部署，传统的单层 C/S 架构往往只能解决一个 IDC 中服务器集中管控的情况。对于海量 IDC 规模，需要支持去中心化，多级部署，解决一系列的失效、冗余和可用性问题。

7、支持自动化运维

服务器数量一多，不能自动化运维就不具有实际可操作性、可维护性。例如 10 万台服务器的安全 Agent 如果不能自动化分发、自动注册、报告状态，统一策略推送，那就会变成灾难。

8、低性能损耗

安全解决方案理论上有很多种可能。从架构设计的角度讲，可以 hook 内核，可以 hook 库函数，可以 hook 运行时容器，可以埋很多点，做很多的检测和限制，或者安全工程师可以要求从用户浏览器到反向代理到应用服务器，到数据库的连接全部走 SSL/TLS 加密。但实际上，纯安全设计角度可行的方案，在现实中未必可行，安全带来的性能损耗一大，业务方就不能接受，最后只能成为理论上可行但实际上不可操作、不可落地的纸上谈兵。

另一方面，实操层面也有很多性能损耗的大敌，例如扫描漏洞的爬虫爬到网站负载严重增加，HIDS 在上万并发的 Nginx 服务器上运行了一个 netstat 或 lsof，服务器瞬间“僵”掉……这些都是理论上没错但实际上不可行的安全措施。

9、能旁路则不串联

“分光”、“旁路”是互联网偏爱的一种方式，究其原因是不想对业务逻辑改动，串联型安全措施最有可能产生的问题是：1）业务响应的延迟，这种延迟没法通过堆叠扩展更多的服务器来解决。2）误杀，阻断了正常用户的请求。3）对业务逻辑的影响，因为是串联，业务改动都要受制于这个安全设备，有时候牵一发动全身。

10、业务无感知

所谓业务无感知就是安全方案的落地尽可能地对业务侧：不断网、不改变拓扑、不改变业务逻辑、无性能损耗。无缝集成有时也是这个意思。

11、去“信息孤岛”

传统解决方案中单个安全设备注重解决“自己的事”。例如 IPS 只关注网络而不关注其他，而互联网环境下单点的安全检测和防御是不行的，信息不能封闭在一个程序或设备中，必须可联动，可关联。IOC 的信息必须在企业内部做到兼容、共享和流通，这也是多维和纵深防御的一个前提。

12、TCO

可控有些商业安全产品也许效果还凑合，小规模 IDC 部署可能没太多问题，而一旦进入海量 IDC 环境，即使给大客户折扣价也是个天文数字，这个数字甚至足以开几家上千人的安全公司。无论如何这种 TCO 的解决方案都是不可行的，跟业务侧去 IOE 一样，在互联网行业，这是一个潜规则而不是明规则，TCO 过高的安全方案就像吸毒，一开始没感觉，随着 IDC 规模的扩大会慢慢无法承受，此时再转型就比较被动。而商业产品很多功能其实都是多余的，实际环境简陋的东西往往很有效，这就是自研的必然性。