如何假装纵深防御
2023-2-27 22:8:28 Author: mp.weixin.qq.com(查看原文) 阅读量:3 收藏


最近很忙,压力很大。

回到设计理念本身,原文是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的防御措施,但架构师在设计的时候也需要关注到。

纵深防御是做安全设计都会挂在嘴边的话,实际落地的质量有待考究。很多时候并不能意识到数据的价值,更别提安全设计的重要性了。

文章里没写权限和数据的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的加密同步等等。

回头理理再写吧,困了。前面本来看到最近招数据安全架构师的企业增加了,还想写点啥,最后也没有精力写完。


文章来源: https://mp.weixin.qq.com/s?__biz=Mzg3ODAzNjg5OA==&mid=2247485144&idx=1&sn=204339ad4b4cf14885d173177059252e&chksm=cf189415f86f1d03fde0f6cd12f2461f2c996b7aafb2e7773b64edbd7048808b01ceb4ddb925&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh