从防火墙到 “下代防火墙” 的变迁,标志着安全领域从专注IP地址的模式转变到瞄准应用、用户和内容的模式。这一重大转变为我们所保护的东西提供了更多可见性与上下文。
但随着向云端的迁移,“下代防火墙” 也不再是 “下代”,看起来更像是必将与恐龙同命运的 “爷爷辈” 了。下代防火墙用例中,应用可见性使深度包检测成为可能,可以用来识别和检查应用。而在云端,大部分流量都是加密的,意味着网络没办法检查流量。即使用什么神奇的手法得以执行 “中间人” 攻击解密流量数据,云的规模和可扩展性也让当前下代防火墙毫无用武之地。
下代防火墙追不上云的脚步
基础设施即服务(IaaS)环境中的应用程序是定制的,没有已知签名可供识别应用。即便能够识别应用程序,其安全配置也是各用例不同的。从通信模式看,两个数据库应用的安全配置和行为完全不同,但从启动的角度看,这又是同一个应用程序。下代防火墙无法区分启动和通信模式以理解应用行为或所需的策略。
容器、Kubernetes和和无服务器计算同样让下代防火墙完全抓瞎,因为下代防火墙就从未预想过要理解这些新一代的微服务。
IaaS实际上正演变为平台即服务(PaaS),云端的任何应用都会用到来自云提供商的大量原生服务。对这些原生云服务的所有活跃访问根本不会跨越网络,所以下代防火墙对此毫无所觉。
云端用户识别
由于不同环境中同个用户对相同应用可能具备不同权限,下代防火墙还可能令云端用户识别变得更加困难。换句话说,生产vs开发环境改变用户互动方式。下代防火墙没有关于部署模型的任何上下文——因为它们出现在持续集成/持续交付(CI/CD)概念之前。
云端绝大部分活动并非真是用户所为,而是机器或应用程序承担角色来执行的。但下代防火墙执行任务用的是不会在网络流量中出现的API,所以它们完全看不到这些用户。
在云端,用户使用服务账户或SUDO工作,这意味着你无法仅凭检查网络流量或活动目录(AD)就将行为归结到正确的用户身上,因为有效用户未必是做了这些事的原始用户。
在云端实施规则
规则实施功能是防火墙的主要功能,但在云端,服务提供商有自己的防火墙策略设置能力,比如AWS的安全组就能提供更多控制,且支持扩展与能提供更细粒度控制的标签。下代防火墙在可扩展性上举步维艰,而且不具备机器标签环境。
下代防火墙采用静态规则构建,这种东西即便在静态环境下也无法维护。几乎每个防火墙配置里都有至少10条规则是没人能够解释清楚怎么来的,但没有任何一个人敢动这些规则,因为他们不知道动了之后会毁掉什么。在云端这种弹性环境里,构建和维护规则就更不可能了。
云端需要新数据集
想识别云端应用和用户,你需要网络流量中不存在的新数据集。而且规则和签名是无法使用的,因为你要用行为和上下文来做应用和用户溯源。
下面列出云端的重要应用、用户和行为,并附上 “下代防火墙” 和云原生解决方案的对比。
应用可见性 | 下代防火墙 | 云解决方案 |
定制应用 | 不可见 | 应用识别采用行为和上下文 |
容器 | 不可见 | 支持 |
Kubernetes | 不可见 | 支持 |
云服务 | 不可见 | 支持 |
加密流量 | 不可见 | 在主机端,能识别应用和用户 |
虚拟机内流量 | 不可见 | 所有主机端流量可见 |
无服务器 | 不可见 | 支持 |
机器/云标签 | 不可见 | 支持 |
应用可见性 | 下代防火墙 | 云解决方案 |
假定角色 | 不可见 | 应用识别采用行为和上下文 |
SSH用户 | 不可见 | SSH跟踪可将行为溯源至正确用户 |
云管理员 | 不可见 | 用账户API管理活动 |
杀伤链行为 | 下代防火墙 | 云解决方案 |
网络通信 | IP地址级 | 应用/用户/容器/Kubernetes |
权限修改 | 不可见 | 跟踪用户及其权限 |
文件修改 | 不可见 | FIM |
用户行为 | 不可见 | SSH跟踪以溯源行为至正确用户 |
云配置修改 | 不可见 | 最佳实践与合规 |
账户API行为 | 不可见 | 基于账户的IDS |
应用启动 | 不可见 | 应用启动跟踪 |
文件恶意软件 | 不可见 | 基于SHA的恶意软件检测 |
用户需改变往云端部署基础设施的方式,需找到用云来守护云的安全解决方案。下代防火墙的理念需改个名字,从 “下代” 改成 “爷爷辈”,这样才能更好地适应新云技术。
声明:本文来自安全牛,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。