各种代理的融合 SASE

统一 SASE 角色网络威胁追踪

为什么代理 SASE?

数据包级安全性被认为足够的日子已经一去不复返了。 由于攻击的复杂性,对各种保护进行深度内容检查变得势在必行。 由于分布式劳动力和分布式应用程序,身份识别访问是一项关键要求。 这 博客文章 详细研究了与身份感知访问相关的要求。 API/应用程序资源级别的深度内容检查和身份感知访问需要终止客户端连接、威胁检测的内容检查和访问控制以及通过代理发起连接。 因此,许多 SASE 方案, 通过代理实现安全性。

代理类型

您可能听说过各种类型的代理——正向、反向和透明。 所有类型代理的主要功能都是相同的。 此处列出了高级功能。

  • 掌握流量
  • 终止客户端连接。
  • 对客户端进行身份验证。
  • 获取用户身份。
  • 发起与服务器的连接。
  • TLS 解密和加密
  • 检查 IP 和域信誉。
  • 执行基于身份的访问控制。
  • 演出 CASB 功能。
  • 检查数据是否丢失并防止丢失。
  • 执行入侵检测/预防功能。
  • 执行Web应用程序防火墙功能。
  • 寻找流量中的恶意软件和漏洞利用指标并采取行动。

它们之间的差异取决于以下因素:

  • 获取流量以进行威胁检查和访问控制
  • 验证用户身份并识别用户

透明代理类型

在这种类型中,客户端和服务器不知道代理的存在。 这些代理从流量经过的网络路由器捕获流量。 网络管理员有责任确保来自办公室用户的流量和来自WFH用户的流量通过entity引导。erp上升路由实体。 确保WFH用户的流量经过Enterp上升路由器,这是正常的做法利用 VPN 客户端连接到 Enterp上升网络。 如果是 SD-WAN, VPN 隧道终止于 VPN 最近的 PoP 位置的集中器。

用户身份验证和相应的用户识别通过

  • 显式门户
  • 点播门户
  • VPN 隧道建立
  • TLS 客户端证书

在“显式门户”的情况下,用户主动登录门户。 Portal 服务借助 ent 来验证用户身份erp崛起认证系统。 成功验证用户凭据后,它会记下用户的 IP 地址(来自连接的源 IP),并通知代理用户 ID 和 IP 地址映射信息。 一旦代理知道这些映射,代理就会根据流量的 IP 地址识别用户并执行身份感知策略实施。

如果用户在没有主动向门户进行身份验证的情况下发起会话,则代理可以将用户重定向到门户。 由于Portal访问是按需进行的,因此这种认证方式也称为按需Portal认证。 需要注意的一件事是,只有当连接基于 HTTP/HTTPS 时,才可能将用户重定向到门户。 对于 HTTPS,只有在 TLS 解密后才能进行重定向。 如果访问非enterp上升服务/站点,需要用ent模仿服务器证书erp上升拥有CA证书。 此外,如果用户不是使用浏览器的人类用户,则重定向没有帮助。 即使有这些警告,它仍然是代理对用户进行身份验证和识别的强大方法。

正如简要讨论的那样,成为企业的一部分erp崛起网络,WFH(在家工作)用户需要连接到实体erp通过上升网络 VPN 隧道。 VPN 隧道建立后已经进行了用户认证。 VPN 集中器为每个客户端分配唯一的私有IP地址。 客户端可以配置为使用 VPN 隧道,因此该 IP 地址作为大多数连接的源(包括禁用的分割隧道)。 VPN 集中器能够向外部各方通告分配给客户端的 IP 地址、映射的用户 ID(发起者 ID)。 当客户端稍后启动会话时,代理使用此映射来识别用户的会话。

如果建立的 TLS 会话客户端程序具有 TLS 客户端证书,则可以使用它来验证和识别用户。 如今,这种方法很少被使用 SASE,但它是可用的选项之一。

透明代理类型的一大好处是它可以捕获所有协议流量,而不仅仅是 HTTP/HTTPS。 另一个主要好处是在entry上没有特殊的配置erp上升客户端机器或服务器机器。

这种类型的代理没有什么缺点。 由于它根据流量中观察到的 IP 地址来识别用户,因此该用户计算机中的所有应用程序都会得到相同的安全处理。 如果是多用户计算机,则该计算机的所有用户都将获得相同的安全处理/权限。 如果此 IP 地址对多台计算机进行 NAT,则该 NAT IP 地址后面的所有计算机都会获得相同的访问和安全处理。 想象一下用户笔记本电脑感染恶意软件的情况。 恶意软件获得与为该用户定义的相同的访问权限,因为恶意软件是用户登录门户的同一台计算机的一部分。 因此,应谨慎使用透明代理类型,至少对于 HTTP/HTTPS 会话而言。

另一个缺点是这种类型的代理需要 VPN 客户端存在于设备中。 虽然这对于托管设备来说不是问题,但说服员工安装可能是一个挑战 VPN 员工拥有的设备上的客户端。

转发代理类型

转发代理适用于与外部服务/站点通信的客户端设备。 客户端应用程序配置为通过转发代理与外部服务进行通信。 客户端应用程序配置有代理 FQDN/IP 和代理侦听的端口。 在透明代理的情况下,会话的源和目标 IP 地址永远不会有代理 IP 地址。 在转发代理的情况下,来自客户端的连接将来自代理 IP 地址,而与服务器的连接将来自代理 IP 地址。

PAC 文件用于配置客户端应用程序,例如具有代理设置的浏览器。 PAC 文件允许根据目标服务域选择将流量路由到各种代理。 PAC 文件通过系统管理解决方案或通过 WPAD(Web 代理自动发现)服务分发到客户端浏览器。

具有代理设置的客户端应用程序始终与代理进行通信。 这就是转发代理捕获流量的方式。 对于 TLS 连接(例如 HTTPS),每个 TCP 连接以“HTTP CONNECT”事务开始。 此事务仅在客户端和代理之间进行。 在 HTTP CONNECT 事务之后,客户端和服务器之间的数据由代理进行中介。 “HTTP CONNECT”事务具有主机头字段,代理使用该字段的值来确定最终目标 FQDN 和端口。 对于 HTTP2.0,每个流连接都以“HTTP CONNECT”事务开始。 正如您可能已经观察到的,不需要将流量发送到 Enterp为代理增加路由器来捕获流量。 也就是说,流量直接进入代理。 这样,它就与网络无关。

转发代理还可以通过代理验证和代理授权标头对用户进行身份验证和识别。 对于 TLS 连接,这些标头分别在 HTTP CONNECT 事务中作为响应和请求发送。 需要注意的一点是,无需为了验证和识别用户而解密 TLS 连接。 无需进行Portal认证。 还有一个额外的优点是许多浏览器和客户端应用程序支持 Kerberos 作为代理身份验证的一部分。 这样,任何登录设备的用户都可以自动通过代理验证自己的身份,而无需额外的登录弹出窗口(也称为 SSO)。

对于与外部服务通信的客户端来说,使用转发代理类型有几个优点。 下面列出了其中一些。

  • 用户认证和识别是确定性的。 在透明代理类型的情况下,如果用户忘记主动向门户进行身份验证,则只有在 TLS 解密后才能进行按需门户或强制门户重定向以进行用户身份验证。 一些人erp不允许对收集 PII 的网站进行 TLS 解密。 如果站点采用证书固定,则透明代理不会模仿证书,因此不可能进行 TLS 解密。 在这些情况下,无法确定用户是否提供身份感知策略实施。 在转发代理类型中,由于代理身份验证阶段发生在任何 TLS 交换之前,因此用户身份验证和识别是确定性的。
  • 如前所述,转发代理与网络无关,只要客户端应用程序配置了代理设置,就可以与任何网络一起使用。 没有必要 VPN 即使用户在家工作,客户端也存在于设备中。
  • 由于许多客户端应用程序支持 Kerberos,因此用户可以获得 SSO 体验。
  • TLS 1.3+ 中的加密 Client Hello (ECH) 正在受到业界的关注。 当采用ECH时,SNI不可见,因此透明代理类型将无法完成基本的操作 URL 过滤和访问控制。 在转发代理类型中,由于 HTTP CONNECT 事务,即使采用 ECH,代理也知道目标 FQDN。 也就是说,转发代理类型是 ECH 安全的。
  • 没有IP白名单。 每个客户端应用程序都需要通过代理单独进行身份验证,因此非常安全。

也有一些缺点。 它仅适用于 HTTP/HTTPS 流量。 尽管大多数客户端应用程序支持代理设置,但有些不支持。

反向代理类型

反向代理用于前端服务器应用程序。 反向代理用于保护服务免受威胁、提供 RBAC、终止 TLS 会话以及在多个服务实例之间对流量会话进行负载平衡。

反向代理捕获流量通过 DNS 方法。 每个实体的 FQDNerp暴露给员工或公共用户的rise服务在ent中配置erp上升 DNS 服务器指向反向代理实例的 IP 地址。 因此,每次任何用户尝试连接到实体时erp上升服务后,相应的流量落在反向代理上。

反向代理还会终止 HTTPS/HTTP 会话。 作为此过程的一部分,他们还对用户进行身份验证,然后通过 OIDC、SAMLv2 和 SPENGO/Kerberos 方法识别会话的用户。 在应用程序到应用程序通信的情况下,也可以通过 TLS 证书来识别用户。

SASE 代理

对于入门 SASE,请阅读博客文章 解密 SASE。 正如您可能已经观察到的那样, SASE 解决方案有望提供全面的安全性——保护客户、保护 SaaS 数据和安全实体erp上升应用程序。 如中所述 身份意识-SASE 博客文章,基于身份的访问控制是关键功能 SASE。 虽然很多人进入erp崛起可以单独使用 HTTP/HTTPS 访问,有些可能还需要其他协议的访问控制。 由于这些需求,我们相信 SASE 代理应对非 HTTP 流量和不支持代理设置的客户端应用程序透明。 这 SASE 代理应充当访问互联网的客户端应用程序的转发代理 SaaS 服务提供基于确定性身份的访问控制,并在采用 ECH 时提供面向未来的证明。 这 SASE 代理还应充当反向代理以保护实体erp上升应用程序。 多种代理类型的融合是成功的必要条件 SASE 的解决方案。

  • CTO 见解博客

    Aryaka CTO 见解博客系列提供网络、安全和技术方面的思想领导力 SASE 主题。 为了 Aryaka 产品规格参考 Aryaka 数据表。

关于作者

Srini Addepalli
Srini Addepalli 是一位拥有 25 年以上经验的安全和边缘计算专家。 Srini 拥有多项网络和安全技术专利。 他拥有 BITS, Pilani 的电气和电子工程学士学位(荣誉) India.