AWS 安全组与帕洛阿尔托网络虚拟防火墙的区别

AWS 安全组与帕洛阿尔托网络虚拟防火墙的区别

57189
Created On 09/25/18 15:12 PM - Last Modified 04/21/20 00:20 AM


Resolution


介绍

随着企业继续接受公共云资源, 重要的是要注意保护应用程序和数据. 不是因为企业数据可能驻留在非自己的数据中心, 而是因为它仍然是企业数据,而不管其区域设置如何. 企业内部的安全组织需要对驻留在任何地方的公司应用程序和数据进行调整, 并且可以从无处不在的任何设备中访问。这有效地削弱了安全的标准外围模型。无论它们驻留在何处, 外围区域现在都围绕着应用程序和数据。

 

这一转变需要了解公共云供应商可以提供哪些安全功能, 同样重要的是, 什么是不提供的. 公共云中的内置安全产品与帕洛阿尔托网络安全平台提供的不一样。本文档重点介绍了其中的一些差异-特别是对于 AWS, 但同样的概念适用于 Azure。还显示了如何在私有数据中心中使用相同的平台方法必须扩展到公共云--或者无论您的应用程序和数据是可访问的。

 

两者的比较容易看出, 内置的安全功能是现实的, 没有比帕洛阿尔托网络平台的方法. 事实上, 它们是补充的, 应该一起部署。对于 AWS, 无法禁用内置安全性, 并且是一个要求。然而, 离开你的安全姿态, 只有内置引擎的东西, 甚至 AWS 建议[1].

 

比较

下表并非详尽无遗, 而是突出显示了一些未作为 AWS 公共云内内置安全引擎一部分提供的功能。表的末尾列出了一些 AWS 特定的安全控件。重要的是要记住, 对组织的决定不是 "一个或另一个", 而是利用这两种方法来实现全面的安全态势。

 

关键功能

AWS

防火墙

 

 

数以千计的应用程序的能见度和控制;能够创建自定义应用程序;基于策略管理未知通信量的能力

x

 

用户识别和控制: vpn、WLAN 控制器、固定门户、代理、活动目录、eDirectory、Exchange、终端服务、日志分析、XML API

x

 

粒状 SSL 解密和检查 (入站和出站);每策略 SSH 控制 (入站和出站)

x

 

网络: 动态路由 (RIP、OSPF、bgp、多协议 bgp)、DHCP、DNS、NAT、路由再分配、ECMP、LLDP、BFD、隧道内容检查

x

 

QoS: 基于 DSCP 分类的每个应用的基于策略的流量整形 (优先级、保证、最大值) 每条隧道

x

 

基于区域的网络分割与区域保护防止新会议泛滥的 DoS 保护措施

x

 

威胁预防

 

 

防止各种威胁, 包括漏洞利用、恶意软件和僵尸网络

x

 

通过集中于有效负载而不是哈希或文件名来阻止多态恶意软件

x

 

保护每五分钟自动更新一次野火

x

 

高级恶意软件保护 (野火)

 

 

动态分析: 在自定义构建的、防规避的虚拟环境中对文件进行爆轰, 使检测到零天恶意软件和利用

x

 

静态分析: 检测恶意软件和企图规避动态分析的漏洞;现有恶意软件变体的即时识别

x

 

机器学习: 从每个文件中抽取数以千计的独特特性, 训练一个预测机器学习分类器来识别新的恶意软件和利用

x

 

裸金属分析: 规避威胁自动发送到一个真正的硬件环境中引爆, 完全消除了对手部署反 VM 分析的能力

x

 

自动签名更新每五分钟的零天恶意软件和攻击发现的任何野火订户

x

 

上下文威胁智能服务 (自动对焦)

 

 

围绕攻击、对手和运动的上下文, 包括目标产业

x

 

加速分析和响应工作, 包括针对最关键威胁的优先级警报

x

 

URL 筛选

 

 

防止恶意站点将您的人员和数据暴露给恶意软件和开发工具包

x

 

通过检查网页来确定内容和目的是否是恶意的, 从而防止凭据仿冒。自定义 URL 类别、可自定义警报和通知页。

x

 

文件和数据筛选

 

 

双向控制文件类型和社会保险号、信用卡号和自定义数据模式的未经授权的传输

x

 

移动安全 (全局保护)

 

 

远程访问 VPN (SSL、IPSec、clientless) 和基于应用程序、用户、内容、设备和设备状态的移动威胁预防和策略执行

x

 

BYOD: 用于用户隐私的应用程序级 VPN

x

 

管理和可见性工具 (中央策略管理)

 

 

具有应用程序、用户、威胁、高级恶意软件保护、URL、文件类型、数据模式的直观策略控制-所有这些都在同一策略中

x

 

使用应用程序命令中心 (ACC) 对通信和威胁进行可操作的洞察, 完全可自定义的报告

x

 

聚集日志记录和事件关联

x

 

对所有硬件和所有 VM 系列、基于角色的访问控制、逻辑和分层设备组以及模板的一致性管理

x

 

GUI、CLI、基于 XML 的 REST API

x

 

策略自动化的动态标记

 

 

使用粒状过滤策略和自动标记结合在安全组之间移动已损坏的主机。即。例如, 如果看到命令和控制通信量, 则隔离主机。

x

 

使用标记策略在安全违规时自动将相关数据发送到票务系统

x

 

一般特点

 

 

基于 IP/端口/协议的安全性

x

x

策略中使用的端口范围

x

x

策略中的源和/或目标 (注意: AWS 将入站和出站分隔为单独的规则)

x

x

基于 CIDR 的规则

x

x

策略中的 ACL 类似功能

x

x

通信进入 VPC 后应用的安全性

x

x

在策略中丢弃 vs 拒绝区分

x

 

特定于 AWS 的功能

 

 

将 AWS 安全组用作源/目标。* 注: 帕洛阿尔托网络替代方案可能是在 VPC 之间使用 IPSec 来控制通信量。

*

x

在通信进入 VPC 之前应用的安全性。* 注: 这将是与帕洛阿尔托网络虚拟防火墙结合使用的补充功能。

 

x

 

仅使用 AWS 安全的效果

仅利用 AWS 中可用的安全组和 acl, 将在保护方面将您的安全态势恢复25年。这是由于安全组以端口/协议为中心的方法。有一段时间, 使用这种方法是所有需要的。当仅在 tcp 端口80上看到 HTTP 通信, 或者仅在 tcp 端口23上看到 Telnet 通信时。这种情况不再是这样了--多年来一直没有这样的情况发生。应用程序通信不仅驻留在更大范围的端口上, 而且这些端口在自然界中通常可以是动态的, 覆盖着巨大的频谱。这使得无法基于端口或端口范围创建安全策略, 因为这会打开可能使用这些已知端口的恶意软件的大门。

 

使用严格的基于端口/协议的安全性的另一个问题是, 许多应用程序可能使用相同的端口范围。现代安全需要一种方法来区分应用程序, 而不管使用的是端口还是协议。下面的截图显示了在 AWS 模型中内置的基于端口/协议的安全机制:

 

Picture1.png

 

请注意示例中的 "类型" 列。这不应与应用程序识别混淆。这只是从列表中选择应用程序的一种方法, 只有将标准端口插入到实际规则中。要执行应用程序标识, 无论端口或协议如何, 都需要对会话数据包进行深入检查。但是, 这不是基于端口/协议的引擎的工作原理。

 

无论企业数据是位于企业数据中心还是公共云中, 都必须在安全态势内减少攻击面。通过白名单业务所需的应用程序和消除未知应用程序, 攻击面可能会大大减少。当与限制用户仅访问基于角色或组所需的应用程序/数据时, 攻击面仍然进一步减少。这需要帕洛阿尔托网络下一代防火墙的高级功能。无论数据驻留在何处, 这都是正确的。

 

AWS 的内置安全功能在哪里出现?它们被用作安全的补充层, 而不是取代现代的交通检查。例如, 可以使用 VPC 外围 (外部) 上的 "安全组" 功能从特定 IP 范围 (即基于地理的或 ip 地址等) 删除通信量。另一个潜在的用例是控制管理到 VPC 或控制 VPC 之间的通信。对于高级检查功能的要求仍然存在于使用 AWS 内置安全组件之外。

 

摘要

总而言之, 当涉及到公共云安全的 "一个或另一个" 方法时, 有两个问题要问。

 

  1. 你愿意放弃你的 NGFWs 在总部和分支地点保护用户和公司数据 (外围和数据中心), 并完全用 AWS 防火墙 (安全组和 acl) 替换它吗?

  2. 如果答案是 "否", 那么仅使用 AWS 安全保护公共云中的公司数据是否合理?

这两个组件是补充的, 应该与您在总部和分支办公室使用多个层一样部署在一起。

 

参考和注释

[1] AWS 共担责任模式: https://aws.amazon.com/compliance/shared-responsibility-model/ 

 

在公共云中部署 AWS 和帕洛阿尔托网络 VM 系列防火墙的最佳做法是什么?

在 AWS VPC 中, 安全组和网络 acl 控制入站和出站通信量;安全组管理对 EC2 实例的访问, 而网络 acl 则管理对子网的访问。由于您正在部署帕洛阿尔托网络 VM‐Series 防火墙, 请在安全组和网络 acl 中设置更多许可规则, 并允许防火墙安全地在 VPC 中启用应用程序, 同时检查针对恶意软件和恶意活动的会话。 

 

AWS 安全组使用端口/协议:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_Network_and_Security.html 

您可以使用安全组来控制谁可以访问您的实例。它们类似于入站网络防火墙, 使您可以指定允许到达实例的协议、端口和源 IP 范围。您可以创建多个安全组, 并为每个组分配不同的规则。然后, 您可以将每个实例分配给一个或多个安全组, 并且我们使用这些规则来确定允许哪些通信量到达该实例。您可以配置安全组, 以便只有特定的 IP 地址或特定的安全组才能访问该实例。

 

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html 

"安全组充当虚拟防火墙, 用于控制一个或多个实例的通信量. 启动实例时, 将一个或多个安全组与该实例关联。可以向每个安全组添加规则, 使其与关联的实例通信。 "

 

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html 

如果安全组没有满足要求, 则除了使用安全组之外, 还可以在任何实例上维护自己的防火墙.

 

安全组和 acl 组合在 AWS 中被称为 "防火墙":

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html

网络访问控制列表 (ACL) 是您的 VPC 的可选安全层, 它充当用于控制一个或多个子网中进出的防火墙. 您可以使用与安全组类似的规则设置网络 acl, 以便为 VPC 添加额外的安全层。 "

 

AWS 规则类型被简单地替换为应用程序通常使用的标准端口:

 

Picture2.png

 

 

Picture3.png

AWS 出站规则遵循相同的端口/协议语法:

 

Picture4.png

以下是仅支持 IPv4 的 VPC 的默认网络 AWS ACL 示例:

 

Picture5.png

 

创建 AWS ACL 的示例:

 

Picture6.png



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClDGCA0&lang=zh_CN&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language