实现身份感知 SASE

为什么身份意识 SASE?

我以前的博客 解密 SASE 讨论了各种安全组件中的身份识别 SASE。 这篇文章描述了实现身份识别的各种方法 SASE.

传统的以外围为中心的安全中的访问控制是使用 IP 地址和服务定义的。 客户端在访问策略中表示为 IP 地址，服务则使用域名和 IP 地址以及 TCP/UDP 端口，例如 HTTP 的端口 80 和 HTTPS 的 443 端口等。由于存在不同类型的客户端 - 通过 PC/笔记本电脑/手机、客户端应用程序、物联网设备和各种人类用户类别访问服务的人类用户，因此采用分段方法代表不同类型客户的每个段都是被发明的。 每个网段都有自己的子网或 IP 地址范围。 这使得为​​不同类型的客户端定义访问控制成为可能。

尽管它解决了定义各种客户端访问控制的一些挑战，但它引入了另一组复杂性 - 段管理。 很快，许多组织开始看到细分市场的爆炸式增长。 组织开始意识到需要创建各种细分来定义差异化 QoS, WAN 链接选择和各种类型的安全访问控制。

细分的另一个大挑战与“从任何地方工作”。 也就是说，用户 IP 地址根据用户的工作地点不断变化。 在这种情况下，用户与细分的关联很快就成为一个巨大的挑战。 在指定办公室、家里、咖啡店、其他办公室或合作办公室工作的用户应受到相同的对待，无论用户在哪里工作。

身份感知 SASE 通过消除为差异化客户（至少对于人类用户）创建细分的需要，使细分管理变得更加简单。 不过，您可能无法完全摆脱物联网设备等客户端的分段。

身份感知 SASE “数字取证”也需要。 当发生任何数据泄露时，重要的是要了解攻击期间发生的情况，以了解攻击者使用的方法、利用的弱点并确定总体影响。 根据“2022 年 Verizon 数据泄露报告”，82% 的数据泄露涉及人为因素。 因此，每个连接/会话的身份对于了解导致首次感染的访问模式、访问的站点、用户使用的设备和应用程序变得非常重要。 然后，这可以进一步帮助找出最终导致违规的横向攻击。

综上所述，身份意识 SASE 有助于：

• 定义跨防火墙、SWG 的差异化访问策略、 CASB 和 ZTNA 适用于各种用户
• 定义差异化的网络策略 QoS, 不同用户的路由
• 数字取证
• 用户行为分析

身份在 SASE 政策

SASE 组件 以不同的粒度控制对各种服务/站点的访问。 防火墙 SASE 控制 L3/L4 层的访问。 SWG 在以下级别控制访问 URLs。 ZTNA 和 CASB 在 API 级别控制访问。 SWG、ZTNA 和 CASB 使用DLP可以控制数据级别的访问。 出于上述原因并满足 NIST 指定的零信任准则，所有这些控制都需要用户作为选择者之一。

任何访问控制策略都包含一组规则，大部分是有序规则。 每个流量会话都会检查这些规则。 如果规则匹配，则执行匹配规则中指定的操作。 典型的操作包括允许流量、拒绝流量或仅监视和记录流量。 任何规则的匹配都是通过一组属性来进行的。 每个规则都用这些属性的值指定。 这些属性传统上包括 5 元组（源 IP、目标 IP、协议、源端口和目标端口）、区域和位置。 在新的流量会话中，从数据包和上下文（区域、位置）中提取值并与规则属性的值进行匹配。 如果它们匹配，则称该规则匹配。

具有身份意识 SASE，规则匹配属性包括用户属性。 用户属性可以是一组单独的用户名、用户组、用户角色、客户端证书使用者名称或证书使用者备用名称。 策略匹配应包括与基于身份的用户上下文进行匹配 SASE.

新流量会话的典型策略匹配如下：

• 从数据包中提取 5 个元组（源 IP 地址、目标 IP 地址、IP 协议、源端口和目标端口）。
• 获取流量会话源自的源区域和位置。
• 获取发起流量会话的用户信息（名称、用户组、用户角色）。
• 获取流量会话起源处的计算机的设备状态。
• 通过将上述提取的信息与规则匹配属性值进行匹配，从上到下遍历策略的规则。 如果存在匹配项，则执行该规则中指定的操作。 如果没有，请转到下一条规则。
• 如果没有匹配的规则，则采取为该策略表级别配置的操作。

用户识别和认证

由于在对流量会话进行任何策略检查之前需要识别用户，因此出现了一些问题：

• 如何 SASE 对用户进行身份验证？
• 如何 SASE 在收到流量时识别用户？

在去那里之前，让我们先看看一些注意事项 SASE 应照顾。 SASE 需要考虑以下类型的客户：

• 使用浏览器访问服务的人类用户
• 使用非浏览器应用程序访问服务的人类用户
• 非浏览器应用程序无需人工干预即可访问服务
• 具有 CA 证书固定的非浏览器应用程序
• IoT 设备访问服务

这意味着 SASE 解决方案不能假设总是有人类用户发起流量会话。 可以有启动流量会话的编程实体和设备。 SASE 预计会为两种类型的客户提供服务，因此 SASE 解决方案支持多种身份验证方法。

SASE 需要考虑以下用户体验挑战：

• 用户体验中，不会向人类用户显示或显示更少的用于获取用户凭据的弹出屏幕
• 用户体验，人类用户被告知特定访问被拒绝的原因
• 用户使用自己的设备访问服务
• 使用雇主管理的设备访问服务的用户
• 无论用户在家还是在办公室工作，都能获得统一的体验

有了上述要求和影响， SASE 解决方案实现了多种认证模式。 支持的大多数认证模式 SASE 此处列出了解决方案。

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

一旦客户端验证到 SASE 通过上述， SASE 应有一种方法将用户发起的流量会话与正确的用户相关联。 使用两种识别映射方法。 他们是：

• 令牌映射： SASE 解决方案根据 HTTP/HTTPS 流量会话的请求标头中的身份验证/身份/承载令牌来识别用户。 作为身份验证的一部分，客户端会获得令牌，并且客户端在流量会话中也会提供令牌。
• 代表性IP映射： 在此方法中，IP 地址代表用户。 SASE 解决方案使用流量会话的源 IP 地址来识别用户。 当用户第一次通过 SASE 成功地， SASE 记录该用户的用户 IP 地址。 稍后，来自该 IP 地址的任何流量会话都会与该用户关联。

令牌仅对 HTTP/HTTPS 流量会话有效。 由于令牌直接或通过 cookie 间接存在于每个 HTTP 会话中，因此它被认为比“代表性 IP”更安全。 对于非 HTTP/HTTPS 流量会话，“代表性 IP”映射由 SASE 解决方案。 请注意，“代表性 IP”映射方法存在一些挑战，因为计算机中的所有应用程序都使用 IP 地址。 也就是说，即使浏览器用户已通过身份验证 SASE 解决方案中，不仅浏览器而且计算机上运行的所有其他客户端应用程序都将具有相同的访问权限。 在多用户系统的情况下，即使一个用户成功通过了身份验证，该系统的所有用户都将获得访问权限。 SASE 解决方案。 更危险的是，如果系统用于验证 SASE 系统位于 NAT 设备后面。 该 NAT IP 地址后面的所有用户都将获得访问权限。 因此，仅在必要时使用“代表性 IP”功能并尝试将此映射仅限于非 HTTP/HTTPS 会话尤为重要。

由于令牌（通过代理授权标头或授权标头或通过 cookie）是每个 HTTP 请求的一部分，因此只有使用该令牌进行身份验证的客户端应用程序 SASE 解决方案可以发送令牌。 其他需要访问的基于 Web 的客户端应用程序应向 SASE 解决方案来获取访问权限。 由于安全优势，强烈建议对所有 HTTP/HTTPS 会话使用令牌映射方法。

用户身份验证和身份识别 SASE 组件

更多来自Google的 SASE 为基于 Web 的应用程序/服务提供安全性的组件倾向于通过 HTTP 请求标头、客户端证书或 API 密钥中的令牌来识别用户并将其关联到流量会话。

以下部分提供了相关和最佳身份验证模式与各种身份验证模式的映射 SASE 组件。

中泰通讯社

ZTNA，正如本文所讨论的 以前的博客，旨在保护耳鼻喉科erp来自马里的申请增加cio我们和受感染的客户。 ZTNA通过前端应用服务，提供以下功能。

• 传输层安全/SSL 非 TLS/的安全性SSL 应用程序以及不支持强加密算法的应用程序
• RBAC/最低权限访问支持，适用于不支持任何 RBAC 的应用程序以及需要二级 RBAC 的应用程序
• 具有多一级 MFA 的权限访问管理
• 跨多个应用程序实例的流量负载平衡
• WAF 和 API 级威胁保护应用程序的安全

ZTNA 越来越成为必需品，因为它正在将安全责任从应用程序服务中解放出来。 由此产生的好处包括提高耳鼻喉科的生产力erp提高应用程序开发、跨多个应用程序服务的统一安全配置以及更少的攻击面。

ZTNA 主要用于保护基于 Web 的应用程序。 应用程序开发人员不仅使用 Web 协议创建新的应用程序，而且还对现有应用程序进行网络化，以利用 Web 协议上发生的创新。 即使是传统的管理协议（例如 SSH）也正在使用以下项目进行网络化： 阿帕奇鳄梨酱。 也就是说，总会有非 Web 应用程序。 防火墙作为一部分 SASE 为 Ent 提供访问控制和威胁防护安全erp上升实例化非Web服务。 请参阅防火墙部分了解更多详细信息。

ZTNA如何获取流量？

ZTNA 通过两种方式获取流量 – 通过 DNS 方法和透明代理方法。

耳鼻喉科管理员erp上升应用程序将权威域服务器配置为指向应用程序的 ZTNA。 也就是管理员配置 DNS 服务器以 ZTNA IP 地址进行响应 DNS 查询应用程序的FQDNs。 在透明代理方法中，期望ZTNA处于流量线路中，或者期望流量线路中的实体拦截流量并将流量发送到ZTNA。 应用程序管理员还使用 TLS/配置 ZTNASSL 代表应用程序服务的证书/私钥对。

ZTNA 如何对用户进行身份验证并将流量会话映射到用户？

ZTNA 支持反向代理身份验证、客户端证书和 API 密钥身份验证模式来对各种类型的客户端（人类用户以及编程实体）进行身份验证。 其工作原理如下：

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

用户会看到一个屏幕，仅需要提供一次凭据，直到身份令牌过期。 由于客户端的同源策略，它们始终在面向应用程序服务的 HTTP 事务中提供正确的身份令牌。 如果身份令牌有效，ZTNA 将使用该信息将会话映射到正确的用户。

SWG 和 CASB

SWG 组件可保护用户免遭恶意软件、网络钓鱼和不安全网站的访问。 它还可以保护客户端应用程序在感染后不与 C&C 僵尸网络站点联系。 此外，SWG 还提供了一种根据用户在组织中的角色和用户所属组提供对各种站点的差异化访问的方法。 SWG 还记录流量会话元数据以及用户信息，这有助于各种分析和数字取证。 CASB 组件保护耳鼻喉科erp上升数据维护者 SaaS 通过使用 API 级访问控制确保只有正确的用户才能访问和修改数据 SaaS 领域广泛应用，提供了卓越的解决方案。 CASB与 SWG 一样，也记录 API 元数据以及用户信息，用于各种分析和数字取证。

SWG 和 CASB 组件需要检查从用户到 Internet 站点的 HTTP/HTTPS 流量。 SWG 和 CASB 终止客户端连接，执行 SSL 如果允许，则进行拦截，并进行更深入的内容检查以检测和防止恶意软件并阻止任何敏感数据泄漏。

SWG 和 CASB 获得流量？

SWG & CASB 代理通过两种方法获取流量——代理/PAC 方法和透明方法。

在 Proxy/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 流量会话之前，因此代理在每个会话中都知道用户。 这种方法的一个好处是，除了浏览器应用程序之外，大多数本机客户端应用程序也支持代理设置，并且可以通过代理进行身份验证，从而覆盖大多数 Internet 访问用例。

在透明代理方法中，没有HTTP CONNECT事务。 因此，转发代理身份验证是不可能的。 任何用户身份验证都需要使用常规 HTTP 身份验证方案进行，例如将 HTTP 请求重定向到 SASE 门户，而门户又使用 OIDC 和 SAML 方法对用户进行身份验证。 这种认证称为“Portal认证”。 用户成功登录后，门户可以设置 cookie，但由于浏览器中的同源策略，当用户浏览 Internet 站点时，代理看不到此设置。 由于此质询，一旦用户成功登录，门户就会创建用户名和用户身份验证会话的源 IP 地址之间的映射，并将此映射通知代理。 代理稍后使用此映射将流量会话映射到用户。 如果没有可用的映射，则代理会将流量会话重定向到门户以进行登录。 这种“映射”称为“代表性 IP 映射”。 如前所述，应谨慎使用此映射方法，因为此方法可能会向非预期方开放访问。

透明代理方法依赖于重定向传入的 HTTP 事务。 这意味着它需要通过以下方式获得畅通的流量 SSL 拦截。 有些情况下 SSL/TLS 拦截是不允许的或不可能的。 由于在这些情况下不可能进行重定向，因此期望用户经过身份验证 SASE 通过其他机制，例如通过门户进行主动身份验证或通过“隧道身份验证”。

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

防火墙和相关的 NAT、路由、 QoS 功能在 L3/L4 层级别的数据包上工作。 这些功能需要位于交通线上的系统中。 更多时候， SASE 具有这些功能的系统是来自站点和远程用户的流量的网关。

由于防火墙在访问控制、反向代理和正向代理方面处理 HTTP 和 HTTPS 之外的各种协议，因此无法实现按需门户认证机制。 主要用于对用户进行身份验证的模式有两种：显式门户身份验证和隧道身份验证。

Portal显式认证方式中，用户需要向Portal进行认证 SASE 通过将浏览器指向门户 SASE 门户网站。 这 SASE 门户与 OIDC 一起对用户进行身份验证。 在这种情况下，也是如此， SASE 使用“代表性IP”映射方法。 这 SASE 用户身份验证成功后，门户将 IP 地址与用户映射发送到防火墙。 防火墙和 L3/L4 功能使用这些映射记录将流量会话与用户相关联。

隧道认证模式需要在客户端设备上安装特殊的软件。 客户与以下人员建立隧道会话 SASE 积极主动。 该隧道的一部分经过身份验证 SASE。 如果使用基于 IPSec 的隧道，则隧道身份验证由 SASE/IKEv2 组件。 SASE/IKEv2 组件将用户（发起者 ID）和映射到的虚拟 IP 地址通告给 SASE 安全和网络服务。 防火墙和 L3/L4 功能使用“代表性 IP”映射方法将流量会话映射到用户。

尽管这里明确提到了这两种身份验证模式，但当用户在“反向代理”、“正向代理”模式下对代理进行身份验证时，IP 地址到用户的映射也可以来自代理。

这里需要注意的一点是，如果特定于用户的规则要有效，则需要进行用户身份验证。 如果用户未经过身份验证，策略匹配逻辑会假定该用户未知。 因此，防火墙和 L3/L4 级别的基于用户的策略被认为是机会主义的。 为了激励/提醒用户主动登录， SASE 解决方案倾向于生成浏览器通知来通知用户登录 SASE 门户网站。

统一 SASE 和身份

统一 SASE 被讨论了 此处，那篇文章提供了各种优势 Enterp上涨来自“统一 SASE” 的祭品。

如果 SASE 由于由各种分立组件构建，用户身份验证可能会发生多次，这不是一个很好的用户体验。 与“统一 SASE，'用户预计在整个过程中只需要进行一次身份验证 SASE。 这是“统一”的另一项好处 SASE“。

统一 SASE 产品以统一且全面的方式将用户信息添加到相关日志消息中，并发送到公共可观察平台。 它通过监控 SD 中的用户行为来帮助进行各种分析和异常检测WAN 和安全服务。

总结

微细分方法是必要的，但扩展微细分以对各种用户进行分类并不是一个可扩展的解决方案。 SASE 解决方案越来越多地支持基于身份的策略定义和执行。 SASE 解决方案通过对用户进行身份验证然后将流量会话映射到用户来实现此目的。 SASE 解决方案为用户提供多种身份验证方式 SASE。 这篇文章描述了一些方法。 Aryaka 开启“身份感知”之旅 SASE“。  Aryaka SWG 解决方案支持执行特定于用户的策略。 学习更多关于 Aryaka SWG 解决方案在这里： https://www.aryaka.com/secure-web-gateway/

• CTO 见解博客

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