为什么要在 SASE 中提高身份意识？

实现具有身份意识的 SASE 我上一篇关于解密 SASE的博客谈到了 SASE 各个安全组件中的身份意识。 本文章介绍了实现身份感知 SASE 的各种方法。 传统的以边界为中心的安全系统使用 IP 地址和服务来定义访问控制。 客户端在访问策略中表示为 IP 地址，而服务则通过域名和 IP 地址以及 TCP/UDP 端口（如 HTTP 的 80 端口和 HTTPS 的 443 端口等）来定义。 由于存在不同类型的客户–通过个人电脑/笔记本电脑/手机访问服务的人类用户、客户端应用程序、物联网设备以及各种人类用户类别，因此发明了细分方法，每个细分代表不同类型的客户。 每个网段都有自己的子网或 IP 地址范围。 这样就可以为不同类型的客户端定义访问控制。 虽然它解决了为不同客户定义访问控制的一些难题，但也带来了另一系列复杂问题–分段管理。 很快，许多组织开始看到细分市场的爆炸式增长。 企业开始意识到需要创建各种分段，以定义不同的服务质量、广域网链路选择和各种类型的安全访问控制。 细分的另一大挑战与 “随时随地工作“有关。 也就是说，用户的 IP 地址会根据用户的工作地点不断变化。 在这种情况下，用户与细分市场的关联很快就会成为一个巨大的挑战。 在指定办公室、家中、咖啡厅、其他办公室或合作伙伴办公室工作的用户，无论在何处工 作，都应受到同等对待。 识别身份的 SASE 无需创建用于区分客户的分段，从而简化了分段管理，至少对人类用户而言是如此。 不过，您可能无法完全摆脱物联网设备等客户的细分。 数字取证 “也需要具有身份识别能力的 SASE。当发生任何数据泄露事件时，重要的是要知道攻击过程中发生了什么，以了解攻击者使用的方法、被利用的薄弱点，并确定总体影响。 根据《2022 年 Verizon 数据泄露报告》，82% 的数据泄露涉及人为因素。 因此，要了解导致首次感染的访问模式、访问过的网站、用户使用的设备和应用程序，每个连接/会话的身份就变得超级重要。 这样，就能进一步帮助找出最终导致漏洞的横向攻击。 总之，SASE 中的身份意识有助于：

  • 在防火墙、SWG、CASB 和 ZTNA 上为不同用户定义不同的访问策略
  • 为不同用户定义 QoS 和路由选择方面的差异化网络策略
  • 数字取证
  • 用户行为分析

SASE 政策中的身份

SASE 组件以不同的粒度控制对各种服务/网站的访问。 在 L3/L4 层设置 SASE 控制访问的防火墙。 SWG 对 URL 的访问进行控制。 ZTNA 和 CASB 在应用程序接口层面对访问进行控制。 带有 DLP 的 SWG、ZTNA 和 CASB 可以控制数据层面的访问。 所有这些控制都需要用户作为选择者之一，原因如上所述，同时也是为了满足 NIST 规定的零信任准则。 任何访问控制策略都包含一组规则，大多是有序规则。 每次流量会话都会检查这些规则。 如果规则匹配，则执行匹配规则中指定的操作。 典型的操作包括允许流量、拒绝流量或仅监控和记录流量。 任何规则都与一组属性相匹配。 每条规则都指定了这些属性的值。 这些属性传统上包括 5 个元组（源 IP、目标 IP、协议、源端口和目标端口）、区域和位置。 新的流量会话会从数据包和上下文（区域、位置）中提取值，并与规则属性值进行匹配。 如果它们匹配，则表示规则已匹配。 通过身份识别 SASE，规则匹配属性包括用户属性。 用户属性可以是一组单独的用户名、用户组、用户角色、客户证书主体名称或证书主体候补名称。 策略匹配应包括与基于身份的 SASE 的用户上下文进行匹配。 新流量会话的典型策略匹配如下：

  • 从数据包中提取 5 个图元（源 IP 地址、目标 IP 地址、IP 协议、源端口和目标端口）。
  • 获取流量会话的源区域和位置。
  • 获取启动流量会话的用户信息（名称、用户组和用户角色）。
  • 获取流量会话来源机器的设备状态。
  • 通过将上述提取的信息与规则匹配属性值进行匹配，从上到下浏览策略规则。 如果匹配，则采取该规则指定的行动。 如果没有，请执行下一条规则。
  • 如果没有匹配规则，则采取为该策略表级别配置的措施。

用户识别和认证

由于在对流量会话进行策略检查之前需要先识别用户，因此会出现以下几个问题：

  • SASE 如何验证用户身份？
  • SASE 在接收流量时如何识别用户？

在此之前，让我们看看SASE 解决方案应考虑的一些因素。 SASE 需要考虑以下类型的客户：

  • 使用浏览器访问服务的人类用户
  • 使用非浏览器应用程序访问服务的人类用户
  • 无需人工干预即可访问服务的非浏览器应用程序
  • 使用 CA 证书销号的非浏览器应用程序
  • 访问服务的物联网设备

这意味着 SASE 解决方案不能假定总是有人类用户发起流量会话。 启动流量会话的可能是程序实体和设备。SASE将为这两种客户提供服务，因此 SASE 解决方案支持多种认证方法。 SASE 需要考虑以下用户体验挑战：

  • 用户体验：人类用户在获取用户凭证时不会看到或更少的弹出屏幕
  • 用户体验，让人类用户了解特定访问被拒绝的原因
  • 用户使用自己的设备访问服务
  • 用户使用雇主管理的设备访问服务
  • 为用户提供统一的体验，无论他们是在家还是在办公室工作

鉴于上述要求和影响，SASE 解决方案采用了各种身份验证模式。 这里列出了 SASE 解决方案支持的大多数身份验证模式。

  • 反向代理身份验证
  • 前向代理身份验证
  • 基于门户的身份验证
  • 隧道认证
  • 客户端证书验证
  • 基于 API 密钥的身份验证

一旦客户通过上述方式向 SASE 进行身份验证，SASE 将有办法把用户发起的流量会话与正确的用户关联起来。 使用了两种识别映射方法。 它们是

  • 令牌映射：SASE 解决方案通过 HTTP/HTTPS 流量会话请求标头中的认证/身份/承载令牌识别用户。 作为身份验证的一部分，客户端会获得令牌，客户端在流量会话中也会出示令牌。
  • 代表 IP 映射：在这种方法中，IP 地址代表用户。 SASE 解决方案使用流量会话的源 IP 地址来识别用户。 当用户首次成功通过 SASE 验证时，SASE 会记录该用户的用户 IP 地址。 随后，来自该 IP 地址的任何流量会话都会与该用户相关联。

令牌只对 HTTP/HTTPS 流量会话有效。 对于非 HTTP/HTTPS 流量会话，SASE 解决方案使用 “代表 IP “映射。 请注意，”代表 IP “映射方法存在一些问题，因为 IP 地址会被机器中的所有应用程序使用。也就是说，即使浏览器用户通过了 SASE 解决方案的身份验证，不仅浏览器，机器上运行的所有其他客户端应用程序也将拥有相同的访问权限。如果是多用户系统，即使一个用户成功通过了 SASE 解决方案的身份验证，该系统的所有用户都将获得访问权限。更危险的是，如果用于验证 SASE 系统的系统位于 NAT 设备后面。该 NAT IP 地址后面的所有用户都将获得访问权限。因此，只有在必要时才使用 “代表 IP “功能，并尝试将此映射限制在非HTTP/HTTPS 会话上，这一点尤为重要。 由于令牌（通过代理授权标头或授权标头或通过 cookie）是每个 HTTP 请求的一部分，因此只有通过 SASE 解决方案验证的客户端应用程序才能发送令牌。 其他需要访问的基于网络的客户端应用程序应向 SASE 解决方案进行身份验证，以获得访问权限。 出于安全考虑，强烈建议对所有 HTTP/HTTPS 会话使用令牌映射方法。

SASE 各组件对用户进行认证和识别

许多为网络应用程序/服务提供安全性的 SASE 组件往往通过 HTTP 请求头、客户端证书或 API 密钥中的令牌来识别用户并将其与流量会话关联起来。 以下各节提供了相关和最佳认证模式与 SASE 各组件的映射。

ZTNA

如上一篇博客所述，ZTNA 的目的是保护企业应用程序免受恶意客户端和受感染客户端的攻击。 ZTNA 通过前端应用服务提供以下功能。

  • 非 TLS/SSL 应用程序和不支持强加密算法的应用程序的 TLS/SSL 安全性
  • 为不支持任何 RBAC 的应用程序和需要二级 RBAC 的应用程序提供 RBAC / 最低权限访问支持
  • 多一级 MFA 的权限访问管理
  • 在多个应用实例之间实现流量负载平衡
  • 为应用程序提供 WAF 和 API 级威胁保护

ZTNA 越来越成为一种必需品，因为它将安全责任从应用服务中剥离出来。 这样做的好处包括提高企业应用程序开发的效率，在多个应用服务中统一安全配置，减少攻击面。 ZTNA 主要用于保护网络应用程序的安全。 应用程序开发人员不仅利用网络协议创建新的应用程序，而且还对现有的应用程序进行网络化，以利用网络协议的创新。 即使是 SSH 等传统管理协议，也正在通过Apache Guacamole 等项目实现网络化。 尽管如此，非网络应用始终存在。 作为 SASE 的一部分，防火墙为企业实例化的非网络服务提供访问控制和威胁防护安全。 详情请参见防火墙部分。 ZTNA 如何获取流量？ ZTNA 通过两种方式获取流量：DNS 方式和透明代理方式。 企业应用程序的管理员会配置权威域服务器，使其指向应用程序的 ZTNA。 也就是说，管理员配置 DNS 服务器，以 ZTNA IP 地址响应对应用程序 FQDN 的 DNS 查询。 在透明代理方法中，预计 ZTNA 将处于流量线路中，或预计流量线路中的实体将拦截流量并将流量发送到 ZTNA。 应用程序管理员还可代表应用程序服务使用 TLS/SSL 证书/私钥对配置 ZTNA。 ZTNA 如何验证用户身份并将流量会话映射到用户？ ZTNA 支持反向代理验证、客户端证书和 API 密钥验证模式，以验证各种类型的客户端（人类用户和程序实体）。 其工作原理如下：

  • ZTNA 终止 TLS/SSL 连接
  • 如果客户证书通过协商，则验证客户证书。 如果有效，则提取证书主题名和 SAN（主题别名）。 这些都是客户用户的身份。 如果已配置任何用户组或角色，则会从配置数据库中提取组和角色信息。
  • 如果客户端提供了 API 密钥，它就会调用内部数据库（已配置）来提取用户身份。 如果已配置任何用户组或角色，则会从配置数据库中提取组和角色信息。
  • 如果 HTTP 请求有相关的身份验证/身份令牌，则表示用户之前已通过身份验证。 这也意味着 ZTNA 知道用户上下文（用户名、用户组和用户角色（如有））。
  • 如果令牌无效或没有令牌，则会要求用户通过 OIDC 进行身份识别和验证。 而 ZTNA 的 OIDC 代理可使用各种认证协议，让用户通过企业认证服务进行认证。 对于特权账户，ZTNA 会执行自己的 MFA，以确保用户确实是真正的用户。
  • 如果用户认证成功，ZTNA 的 OIDC 组件就会设置身份令牌。 它还会记录用户信息（用户名、用户组（如有）和用户角色（如有））。
  • 然后，ZTNA 与其中一个应用服务实例建立连接。
  • 它对每个 HTTP 事务执行基于用户的访问控制决策。
  • 如果 ZTNA 配置为高级威胁防护，它还会扫描流量，检查是否存在漏洞、恶意软件和敏感数据泄漏。

用户只需在屏幕上提供一次凭证，直到身份令牌过期。 由于客户端采用了同源策略，因此在面向应用服务的 HTTP 交易中，客户端始终出示正确的身份令牌。 如果身份令牌有效，ZTNA 就会使用该信息将会话映射到正确的用户。

SWG 和 CASB

SWG 组件可防止用户访问恶意软件、网络钓鱼和不安全网站。 它还能保护客户端应用程序在感染后不与 C&C 僵尸网络网站联系。 此外，SWG 还提供了一种方法，可根据用户在组织中的角色以及用户所属的组别，提供对不同网站的不同访问权限。 SWG 还能记录流量会话元数据和用户信息，有助于进行各种分析和数字取证。 CASB 组件利用各种 SaaS 应用程序的 API 级访问控制，确保只有正确的用户才能访问和修改数据，从而保护 SaaS 提供商维护的企业数据。 CASB 和 SWG 一样，也会记录 API 元数据和用户信息，以便进行各种分析和数字取证。 SWG 和 CASB 组件都需要检查从用户到互联网网站的 HTTP/HTTPS 流量。 SWG 和 CASB 会终止客户端连接，在允许的情况下进行 SSL 拦截，并进行更深入的内容检查，以检测和防止恶意软件，并阻止任何敏感数据泄漏。 SWG 和 CASB 如何获取流量？ SWG 和 CASB 代理通过两种方法获取流量：代理/PAC 方法和透明方法。 在代理/PAC 方法中，客户端机器/应用程序要么手动配置代理设置，要么客户端应用程序通过自动发现代理进行自动配置。 一旦客户端应用程序知道代理，客户端应用程序就会使用 HTTP CONNECT 方法对数据会话（通常是 HTTP 和 HTTPS 交易）进行隧道传输。 HTTP CONNECT URI 表示内部 HTTP 和 HTTPS 事务的预定目的地。 代理使用此 URL 与目标网站建立连接。 代理在允许数据从客户端和服务器之间传递之前，会执行任何访问控制和威胁保护服务，反之亦然。 在透明代理方法中，客户端不知道代理的存在。 人们希望代理服务器能在流量线路中掌握流量。 SWG/CASB 代理如何验证用户身份并将流量会话映射到用户？ 如果使用代理/PAC 方法到达 SWG/CASB 代理，那么代理就有机会在 HTTP CONNECT 事务中对用户进行身份验证。 这就是所谓的 “前向代理身份验证”。 这里对基于 HTTP CONNECT 的前向代理身份验证进行了详细介绍。 虽然该链接描述的是 NTLM 身份验证，但类似的流程也同样适用于 Kerberos 身份验证。 由于 HTTP CONNECT 在每个 HTTP/HTTPS 流量会话之前进行，因此代理在每个会话中都知道用户。 这种方法的一个好处是，除了浏览器应用程序外，大多数本地客户端应用程序也尊重代理设置，并能与代理进行身份验证，从而涵盖了大多数互联网接入使用案例。 在透明代理方法中，没有 HTTP CONNECT 事务。 因此，前向代理身份验证是不可能的。 任何用户身份验证都需要使用常规的 HTTP 身份验证方案，如将 HTTP 请求重定向到 SASE 门户，而 SASE 门户则使用 OIDC 和 SAML 方法对用户进行身份验证。 这种身份验证被称为 “基于门户的身份验证”。 一旦用户成功登录，门户网站就可以设置 cookie，但由于浏览器的同源策略，用户浏览互联网网站时，代理看不到 cookie。 由于存在这种挑战，一旦用户成功登录，门户网站就会在用户名和用户身份验证会话的源 IP 地址之间创建映射，并将此映射通知代理。 代理稍后会使用此映射将流量会话映射到用户。 如果没有可用的映射，代理就会将流量会话重定向到门户网站进行登录。 这种 “映射 “被称为 “代表性 IP 映射”。 如前所述，应谨慎使用这种映射方法，因为这种方法可能会向意外方开放访问权限。 透明代理方法依赖于重定向传入的 HTTP 事务。 这意味着它需要通过 SSL 拦截来获取清晰的流量。 在某些情况下，不允许或不可能截获 SSL/TLS。 由于在这些情况下不可能进行重定向，因此预计用户将通过其他机制对 SASE 进行身份验证，例如通过门户网站或 “隧道身份验证 “进行主动身份验证。

防火墙和基于 L3/L4 的功能

防火墙和相关的 NAT、路由、QoS 功能在 L3/L4 层对数据包起作用。 这些功能需要安装在交通线路上的系统中。 更常见的情况是，具有这些功能的 SASE 系统是来自站点和远程用户流量的网关。 由于防火墙在访问控制、反向代理和前向代理方面处理 HTTP 和 HTTPS 以外的各种协议，因此不可能采用按需门户认证机制。 用户身份验证主要有两种模式–明确门户身份验证和隧道身份验证。 在显式门户验证模式下，用户应通过将浏览器指向 SASE 门户来验证 SASE 门户。 SASE 门户与 OIDC 一起对用户进行身份验证。 在这种情况下，SASE 也使用 “代表性 IP “映射方法。 用户身份验证成功后，SASE 门户会将 IP 地址与用户映射发送到防火墙。 防火墙和 L3/L4 功能使用这些映射记录将流量会话与用户关联起来。 隧道身份验证模式需要在客户端设备上安装特殊软件。 客户主动与 SASE 进行隧道会话。 该隧道的一部分通过 SASE 验证。 如果使用基于 IPSec 的隧道，隧道身份验证由 SASE/IKEv2 组件负责。 SASE/IKEv2 组件向 SASE 安全和网络服务公布用户（启动程序 ID）和虚拟 IP 地址映射。 防火墙和 L3/L4 功能使用 “代表 IP “映射方法将流量会话映射到用户。 尽管这里明确提到了这两种身份验证模式，但当用户在 “反向代理 “和 “前向代理 “模式下对代理进行身份验证时，IP 地址到用户的映射也可能来自代理。 这里需要注意的一点是，如果要使用户特定规则有效，就必须进行用户身份验证。 如果用户未通过身份验证，则策略匹配逻辑会假定用户未知。 因此，防火墙和 L3/L4 层基于用户的策略被认为是机会主义的。 为了激励/提醒用户主动登录，SASE 解决方案往往会生成浏览器通知，通知用户登录 SASE 门户。

统一 SASE 和身份

这里讨论过统一 SASE，该帖子提供了企业从 “统一 SASE “产品中获得的各种优势。 如果 SASE 是由不同的独立组件构建而成，用户认证可能会发生多次，这并不是一个很好的用户体验。 使用 “统一 SASE”，用户只需对整个 SASE 进行一次身份验证。 这是 “统一 SASE “的一个额外优势。统一 SASE 产品以统一、全面的方式将用户信息添加到相关日志信息中，从而形成一个通用的可观察性平台。 它通过监控跨 SDWAN 和安全服务的用户行为，帮助进行各种分析和异常检测。

摘要

需要采用微分法，但将微分法扩展到对各种用户进行分类并不是一个可扩展的解决方案。 SASE 解决方案越来越多地支持基于身份的策略定义和执行。 SASE 解决方案通过验证用户身份，然后将流量会话映射到用户来实现这一目标。 SASE 解决方案为用户提供了多种认证 SASE 的方法。 本帖介绍了其中的一些方法。 Aryaka 开始了 “身份意识 SASE “之旅。 Aryaka SWG 解决方案支持执行用户特定策略。 点击此处了解有关 Aryaka SWG 解决方案的更多信息： https://www.aryaka.com/secure-web-gateway/

  • CTO Insights 博客

    Aryaka CTO Insights博客系列提供有关网络、安全和SASE主题的思想领导。
    有关Aryaka产品规格，请参阅Aryaka数据表。