为什么云安全离不开“可视性即服务”

无论您是一名网络管理员、安全管理员还是首席信息官,您是否考虑过如果不能对大部分网络环境进行查看和管理将是一种怎样的场景?而如今,这就是各企业机构将应用程序和工作负载迁移到公有云后所面临的两难问题。由于提供商拥有公有云基础构架,所以各企业机构对于应用程序和网络数据的访问权限往往非常有限。

公有云必须按需处理超大规模部署、资源池和持续的配置更改,而这将给可视性、安全性和合规性带来独特挑战。今年2月份,Ixia对多家企业机构的220多名资深IT人员进行了云计算安全问题调查,其中,76%的受访者表示对云环境的安全性 “非常担心”或表示“担心”。采用云的首要安全问题是“无法控制网络数据”(56%),以及无法获得整个公司网络的全面可视性(47%)。

传统的可视性架构存在局限性。它们无法提供确保云工作负载正常运行和安全性所需的敏捷性和洞察力。部署内部解决方案则取决于物理硬件、探针以及企业网络部署不太可能在一夜之间增减的事实。此外,虽然虚拟化部署能够以前所未有的速度推动改变,但物理服务器架构并没有实质变化。因此,尽管硬件通过虚拟探针和虚拟数据包中转设备转向了软件,而原可视性架构仍保留了下来。

被云端遮挡的可视性

向公有云迁移让一切都发生了变化。云端为我们实现的诸多优势——灵活性、敏捷性、弹性以及快速的水平和垂直扩展性对于洞察和监测公有云环境的性能和安全却造成了重重挑战。而工作负载行为缺乏独立的应用监测和分析,公有云提供商的环境性能监测工具不涵盖数据包数据,而这些数据对于网络可视性非常关键。

没有专门的工具探查提供商的数据中心,您的网络和安全团队将束手无策,无法诊断问题或快速修复针对关键业务应用的威胁和攻击。

如果使用不慎,直接采纳云数据将会很危险。分布式可视性架构可以充分发挥公有云的功能并提供服务器工作负载的全面可视性,但这种构架同样也带来了两大劣势:

捕获和过滤流量——在传统数据中心里,可以通过插入物理网络探针和网络数据包中转设备完全控制网域。但物理设备无法植入公有云,且只能控制有限网域。

保证输出适量数据的情况下扩大规模—— 公有云规模的扩大,将满足高峰需求。然而当扩展应用得以满足需求的同时,新的用例也随之产生。因此,您的云端网络可视性解决方案必须要充分适应这种可扩展性才能真正有效。

依赖于单一专用软件代理程序检测数据包的可视性解决方案可能会引发单点故障,且可扩展性有限。因此,无需让物理网络可视性技术适应云环境,云原生可视性架构才是真正所需。而且,此架构部署简单,IT团队不必进行复杂的配置和调整。因此,扩展式云可视性必须以“可视性即服务”(Visibility-as-a-Service)的方式实施。

洞悉云端

构建“可视性即服务”架构的首要步骤是创建一个编排层,并可通过基于“软件即服务”(Software-as-a-Service)的Web界面进行访问。理想情况下,它可以利用云原生服务提供商的数据库、身份管理、API和其他服务。这意味着企业不再需要安装或管理该产品的任何部分。它能实现类似云存储供应商为您的文件提供存储空间、管理和维护功能。

然后,编排层将连接到源实例的云端传感器,以及各种安全和监测工具的连接器。这些传感器和连接器的最高效和可扩展的部署方法就是将其置于容器内,如同各企业基于微服务的工作负载和工具一般嵌入用例中。由于直接嵌入用例,因此传感器可以在应用程序的源头过滤相关的可视性流量。

将传感器嵌入源用例不仅有效,还有另一个重要优势:可最大程度减少云间带宽量,由于只将相关数据传送给工具,这将显著节省成本。传感器可以将云端工作负载(如:数据库或Web)传送到编排层。利用该元数据,各企业机构可以将工具与各种工作负载类型关联起来,并创建包含传感器和相关工具的“组群”。由于特定服务的其他用例交错启动,这将立即创建其他传感器,然后再连接到安全和监控工具中的相关连接器。此外,由于这些额外的传感器在一个组群内联机,因此位于可扩展容器环境中的工具连接器也将自动扩展。这将实现真正的云原生弹性,而无需手动干预。

按需扩展传感器、连接器以及利用云原生服务的能力,对于可视性即服务至关重要,这将为基于OpEx的消费模型提供智能可视性,并与企业使用的其他可视性即服务协调一致。简单且可扩展的云可视性将改善安全性和合规性,同时保留公共云部署的成本优势。

本文转自d1net(转载)

上一篇:《Python面向对象编程指南》——2.8 __new__()方法和不可变对象


下一篇:Java10 初体验(实战)