云安全离不开“可视性即服务”
2017-03-09
公有云必须按需处理超大规模部署、资源池和持续的配置更改,这将给可视性、安全性和合规性带来独特挑战。
传统可视性架构存在局限性。其无法提供确保云工作负载正常运行和安全性所需的敏捷性和洞察力。此外,虽然虚拟化部署能够以前所未有的速度推动改变,但物理服务器架构并没有实质变化。因此,尽管硬件通过虚拟探针和虚拟数据包中转设备转向了软件,而原可视性架构仍保留了下来。
被云端遮挡的可视性
云端为我们实现的诸多优势——灵活性、敏捷性、弹性以及快速的水平和垂直扩展性对于洞察和监测公有云环境的性能和安全却造成了重重挑战。而工作负载行为缺乏独立的应用监测和分析,公有云提供商的环境性能监测工具不涵盖数据包数据,而这些数据对于网络可视性非常关键。
没有专门的工具探查提供商的数据中心,网络和安全团队将束手无策,无法诊断问题或快速修复针对关键业务应用的威胁和攻击。
如果使用不慎,直接采纳云数据将会很危险。分布式可视性架构可充分发挥公有云功能并提供服务器工作负载的全面可视性,但这种构架同样也带来两大劣势:
捕获和过滤流量——在传统数据中心里,可以通过插入物理网络探针和网络数据包中转设备完全控制网域。但物理设备无法植入公有云,且只能控制有限网域。
保证输出适量数据的情况下扩大规模——公有云规模的扩大,将满足高峰需求。然而当扩展应用得以满足需求的同时,新的用例也随之产生。因此,云端网络可视性解决方案必须要充分适应这种可扩展性才能真正有效。
依赖于单一专用软件代理程序检测数据包的可视性解决方案可能会引发单点故障,且可扩展性有限。因此,无需让物理网络可视性技术适应云环境,云原生可视性架构才是真正所需。而且,此架构部署简单。因此,扩展式云可视性必须以“可视性即服务”的方式实施。
洞悉云端
构建“可视性即服务”架构的首要步骤是创建一个编排层,并可通过基于“软件即服务”的Web界面进行访问。理想情况下,它可以利用云原生服务提供商的数据库、身份管理、API和其他服务。这意味着企业不再需要安装或管理该产品的任何部分。它能实现类似云存储供应商为您的文件提供存储空间、管理和维护功能。
然后,编排层将连接到源实例的云端传感器,以及各种安全和监测工具的连接器。这些传感器和连接器的最高效和可扩展的部署方法就是将其置于容器内,如同各企业基于微服务的工作负载和工具一般嵌入用例中。由于直接嵌入用例,因此传感器可在应用程序的源头过滤相关的可视性流量。
将传感器嵌入源用例可最大程度减少云间带宽量,由于只将相关数据传送给工具,这将显著节省成本。传感器可以将云端工作负载(如:数据库或Web)传送到编排层。利用该元数据,各企业机构可以将工具与各种工作负载类型关联起来,并创建包含传感器和相关工具的“组群”。由于特定服务的其他用例交错启动,这将立即创建其他传感器,然后再连接到安全和监控工具中的相关连接器。此外,由于这些额外的传感器在一个组群内联机,因此位于可扩展容器环境中的工具连接器也将自动扩展。这将实现真正的云原生弹性。
按需扩展传感器、连接器以及利用云原生服务的能力,对于可视性即服务至关重要,这将为基于OpEx的消费模型提供智能可视性,并与企业使用的其他可视性即服务协调一致。简单且可扩展的云可视性将改善安全性和合规性,同时保留公共云部署的成本优势。