如何假装纵深防御
0x01 前言
最近很忙，压力很大。
0x02 正文
回到设计理念本身，原文是Defense in Depth，其实是只有深度概念的，我们今天就简单讨论一下什么算是纵深防御。
Defense in Depth的设计理念一般来说是作用在Layered Architecture上，个人理解没有分层架构就没有纵深防御 ，通过提供多层次的控制措施来缓解威胁。（区分场景对使用设计理念很重要。就像之前写Shift to left一样，这个理念是作用在正向建设过程，把防御能力前置。所以做事后建设的时候是不适合采用这个设计理念的。如果非要去使用，就显得有点牵强附会））
纵深防御设计的关注点一般需要关注四个方向：
-
系统
-
网络
-
权限
-
数据
下面开始看系统，这里的概念比较宽泛。可以理解为提供服务的一套软硬件支撑共同作为一个系统。对于系统来说，显然是分层架构的，从硬件到OS，再到虚拟化或者容器化，之后去运行相应的应用/进程等。假设我们的关注点从硬件开始，就需要TPM，TEE，Root Of Trust， Hardware Based Encryption等防御技术，其次OS层面考虑VMP，HIDS，EDR，AV等，乃至RASP，Security SDK等等都是应用层面可以做的事情，以及永远不要忘了log。如果现在我们算是完成了单体System的Defense in Depth，那么在微服务的场景里，多个单体系统连接到一起就构成了服务平面。
既然已经构成了服务平面，对于终端用户来说，访问链路是从端开始经过CDN、Firewall、WAF、NIDS等等一系列的安全设备/工具。如果是自建的机房，就会可能出现下图左侧的情况。然后通过BGP或者其他协议实现旁路引流，选择感兴趣流量丢给安全设备，这样就意味着不同Rack上的机器流量都会经过防火墙进行检测，否则就会出现一种情况，用户在正常经过访问链路使用服务的同时，部署在不同安全域的微服务之间并没有安全检测。类似支付业务和钱包业务部署在不同VPC内，但是VPC之间的流量是没有经过检测的，也就意味着一旦边界失陷，就意味着无尽的横向移动。在这个过程中又涉及到OSI模型，如下右图所示。应用层流量到传输层，然后到网络层的过程。有一个transmit和receive的过程，虽然安全设备已经内嵌了不同Layer的防御措施，但架构师在设计的时候也需要关注到。
0x03 总结
纵深防御是做安全设计都会挂在嘴边的话，实际落地的质量有待考究。很多时候并不能意识到数据的价值，更别提安全设计的重要性了。
文章里没写权限和数据的Defense in Depth，因为不知道怎么样很好的用图来表述，就暂时就没画图了。权限和数据都比较抽象，权限维度的Defense In Depth的话，一般会去做SOD（权责分离），比如以Root Of Trust为例，根密钥一定是分片给到不同的人去持有。同样的针对密钥管理，Import和Assign给应用以及Enable/Disable的过程也要分给不同的Role。从管理流程上来说，运营操作员，管理员，分析师，审计员这种角色在系统中较为常见，其次是工具上的演变，从sms 2fa到app的mfa，使mfa也进入了defense in depth的领域。类似的还有从一次鉴权，到每次鉴权。数据也是，系统内部的逻辑处理，系统间的，DB内的。从hash以及签名，到传输的tls，到DB内的aes，binlog的加密同步等等。
回头理理再写吧，困了。前面本来看到最近招数据安全架构师的企业增加了，还想写点啥，最后也没有精力写完。
