让安全变得简单：在统一 SASE 中简化安全策略 安全接入服务边缘（SASE）服务及其相关架构由多个安全组件组成，功能强大。 其中包括状态检测防火墙、入侵检测和防御系统（IDPS）、DNS 安全、DoS/DDoS 防护、安全 Web 网关（SWG）、零信任网络架构（ZTNA）、云访问安全代理（CASB）等。 这些组件使管理员能够通过策略对其进行配置，为保护组织的资产免受威胁提供了强大的防护，同时又符合特定的访问要求。

政策配置的作用

政策配置在 SASE 框架内执行安全方面发挥着不可或缺的作用。 配置不当的策略会造成各种影响，从资源威胁和数据泄露到意外的过度许可访问。 在当今的行业环境中，企业在安全策略管理方面主要采用两种方法：

  1. 单一表格方法：综合策略表包含大量策略，横跨所有SASE 组件的威胁管理和各种访问控制方案。
  2. 多表方法：多个策略表，每个策略表针对特定方面，如威胁防护、访问控制、不同应用和用户组。

在政策管理中取得平衡

对 SASE 的期望很明确：它应提供易于管理的安全策略和简化的故障排除程序。 要做到这一点，就必须采取一种平衡的方法。 根据组织要求降低政策复杂性的有效策略之一。 大型组织可能需要使用多表方法进行分隔，根据安全功能、应用资源和主题（用户/组）来定义策略表的粒度。 规模较小的组织可能更倾向于使用较少的策略表进行分隔，将多种类型的访问控制结合起来，甚至将威胁防护与访问控制结合起来。 这种灵活的方法最大限度地减少了需要同时管理的策略数量，使其更易于管理。 不过，重要的是要谨慎行事，避免过度分门别类，因为这样会带来一系列挑战。 管理员可能会发现自己需要浏览多个策略表来确定和处理问题，这可能会导致问题解决的延误。

了解关键要求

在深入研究错综复杂的策略管理之前，了解组织必须在 SASE 框架内满足的具体要求至关重要。 主要领域包括

SASE 环境中基于角色的安全配置管理的必要性

Secure Access Service Edge (SASE)组件提供全面的安全保护，包括为不同组织的各种资源（包括员工、合作伙伴和访客）提供威胁防护和访问控制。 在这个安全框架内，组织通常有不同类别的管理员负责不同方面的安全。 例如，一个组织可能有一组管理员专门负责管理威胁防护，而另一组则专注于访问控制。 在这些大类中，企业通常会针对特定类型的威胁防护和访问控制设立各种管理角色。 让我们深入了解一些实际例子：

威胁防护角色：

  • 入侵检测和防火墙配置：具有 “threat-protection-ngfw-role”（威胁保护-ngfw-role）角色的管理员被授予在 SASE 环境中配置入侵检测和防火墙设置的权限。
  • 信誉控制：持有 “威胁保护-信誉-角色 “的管理员可以管理与 IP 信誉控制、基于 URL 的信誉控制、基于域的信誉控制、文件信誉控制以及云服务和云组织信誉控制相关的设置。
  • 恶意软件保护：具有 “威胁-保护-恶意软件-保护-角色 “的管理员有权配置专门与恶意软件保护控制有关的设置。

访问控制角色：

  • SWG 配置：指定为 “access-control-Internet-role “的管理员负责管理安全网关 (SWG) 配置。
  • SaaS 应用程序特定访问控制：“access-control-saas1app-role “和 “access-control-saasNapp-role “等角色侧重于为特定应用程序（SaaS 服务 1 和 SaaS 服务 N）配置访问控制策略，确保细粒度控制。
  • 企业应用管理：“access-control-hostedapp1-role “和 “access-control-hostedappM-role “等角色专门用于处理企业级应用程序 app1 和 appM 的访问控制配置。

如果组织使用多租户应用程序，则可能需要引入额外的角色来有效管理安全配置。 例如，可以建立角色，为组织员工、每个租户员工甚至访客配置政策。 考虑一个 “X “应用程序，其安全配置由不同的管理员管理：

  • 业主劳动力安全：具有 “access-control-hostedappX-role “和 “access-control-owner-workforce-role “角色的管理员协作管理所有者员工对应用程序 “X “的访问控制配置。
  • 针对租户的应用程序租户特定劳动力：“access-control-hostedAppX-role “和 “access-control-owner-tenantA-workforce-role “等角色可让管理员为租户 A 的员工配置访问控制设置。
  • 租户 B 的应用程序租户特定劳动力：对于多租户应用程序 “X”，有多种角色，如 “access-control-hostedAppX-role “和 “access-control-owner-tenantB-workforce-role”，便于管理租户 B 员工的访问控制配置。

此外，即使是非多租户企业应用程序，也可能需要为不同的员工群体配备不同的管理员。 例如

  • 工程部：具有 “access-control-hostedappY-role “和 “access-control-eng-role “的管理员主要负责管理工程部内应用程序 “Y “的访问控制配置。
  • 销售和营销：“access-control-hostedappY-role “和 “access-control-sales-role “等角色指定用于配置销售和营销团队的访问控制设置。
  • IT 部门：具有 “access-control-hostedappY-role “和 “access-control-it-role “的管理员负责与 IT 部门相关的访问控制配置。

基于角色的安全配置管理的一个显著优势是，它能够提供针对具体职责的细粒度控制。 这种方法与使用单一、包罗万象的政策表时可能出现的挑战形成鲜明对比：

  • 容易出错：在添加、删除或修改策略时，使用同一策略表和重叠权限的多个管理员可能会无意中引入错误。
  • 复杂的故障排除：在单一策略表中解决问题既耗时又具有挑战性。
  • 策略超载：将涵盖各种应用和威胁防护方案的所有策略合并到一个表中，可能会导致策略管理体验变得繁琐笨重，并在策略评估过程中面临潜在的性能挑战。

总之，在 SASE 环境中采用基于角色的安全配置管理，可使组织有效地委派责任、增强安全性和简化策略管理，同时避免与单表方法相关的复杂性。

与配置变更控制管理部门合作

各组织正越来越多地采用针对所有配置（包括 SASE 配置）的变更控制管理，以便在实施前主动发现和纠正配置错误。 这种做法不仅是一种保障措施，而且还引入了第二层审查，允许第二双眼睛在配置生效前对其进行审查和批准。 安全策略配置直接应用于流量中，因此策略中的任何错误都可能导致服务中断，并产生直接的经济后果。 为了应对安全策略配置固有的复杂性，通常的做法是将更改序列化。 这意味着在修改一种配置时，不会启动其他同类型的配置会话，直到前一个会话被应用或撤销。 不过，在使用包含所有威胁和访问控制功能的单一策略表时，序列化更改可能会延误其他管理员执行的配置调整。 相比之下，多表方法可以有效解决这种情况，允许不同的管理员同时处理不同的表，从而简化配置更改流程。

并非所有组织都有相同的要求：

SASE 通常是作为一种服务提供的，SASE 提供商可将多个组织作为客户服务。 这些组织在规模、监管要求和结构内角色的多样性方面可能存在很大差异。 一些组织可能会在内部或云端托管多个应用程序，而另一些组织可能会完全依赖 SaaS 提供商的服务，还有一些组织可能会将两者结合起来。 此外，某些组织可能不需要各种管理角色或多个管理用户。 如果组织只有数量有限的应用程序，且不具备多个管理角色的复杂性，那么它们可能会发现使用较少策略表的价值。 预计 SASE 的设计将提供满足这些不同需求所需的灵活性，包括为多个相关安全功能和应用使用综合政策表的选项。

避免配置混乱：

如前所述，某些 SASE 解决方案在追求简化的过程中，会选择一个单一的、包罗万象的策略表，在该表中可以为各种匹配属性配置策略值。 在流量处理过程中，策略选择基于将传入流量和其他上下文信息的值与策略中指定的属性值进行匹配。 不过，我们必须认识到，在流量处理过程中，并非所有流量属性都是已知的。 例如，在状态检测防火墙中，只能提取有限的流量值，如 5 元组信息（源 IP、目的 IP、源端口、目的端口和 IP 协议）。 同时，对于 SWG、ZTNA 和 CASB 等基于代理的安全组件，属性值的提取可能会有所不同，并可能涉及不同的阶段，特别是前 TLS 检查和后 TLS 检查阶段。 在 TLS 检查/解密之前，许多 HTTP 属性仍然未知。 只有在 TLS 解密后，访问 URI 路径、HTTP 方法和请求标头等附加属性才可用于评估。 作为负责配置安全策略的管理员，期望管理员在定义策略时跟踪哪些属性在数据包处理的各个阶段有效是不切实际的。 虽然一些安全解决方案声称在策略评估中不会考虑无关属性，但在检查复杂策略时，确定哪些属性相关、哪些不相关可能是一项挑战。 我们坚信，将多个阶段的策略表合并为一个表会给管理员带来复杂性和混乱。 这种方法可能难以理解，并可能导致令人困惑的配置。 为确保清晰，建议在给定表格内创建只包含相关属性的政策，以便进行一致和直接的评估。

优化拒绝和允许策略表：

某些安全解决方案采用的结构是分别维护 “拒绝 “和 “允许 “策略表。 在此设置中，”拒绝 “列表中定义的策略优先，并首先进行评估。 如果在 “拒绝 “表中没有找到匹配的策略，则继续评估 “允许 “策略表。 然而，将政策分为两个不同的表格可能会给管理员带来挑战。 我们坚决主张采用更简化的方法，即任何给定的政策表都以有序的政策清单形式呈现。 在这种安排下，每项策略都明确指定了自己的操作–无论是 “拒绝”、”允许 “还是任何其他所需的操作。 在流量处理过程中，策略评估遵循从最高优先级策略到最低优先级策略的逻辑顺序，直到找到匹配的策略。 一旦确定了匹配策略，就会对流量采取相应措施。 在没有遇到匹配策略的情况下，会触发组织安全策略规定的默认操作，如 “无法打开 “或 “无法关闭”。 这种方法可简化政策管理，并通过将政策合并到一个有序的单一列表中（无论政策操作值如何）来提高管理员的清晰度，从而最大限度地降低复杂性并简化政策评估流程。 不根据操作值分离策略表也使 SASE 解决方案提供商能够相对容易地在未来引入新的操作值。

制定灵活而富有表现力的政策：

正如你所了解的，管理员通过定义匹配属性的数值集来制定策略。 传统上，人们对流量评估过程中策略匹配的操作方式有一种共识：只有当策略中指定的所有属性值与传入流量会话的值完全一致时，策略才被认为是匹配的。 这些值可以直接从流量中提取，也可以从上下文信息中推断，如经过验证的用户上下文和负责发起流量的设备上下文。 从本质上讲，这一匹配过程涉及对政策的所有属性进行 “和 “操作。 不过，随着安全技术的发展，许多安全设备都引入了更灵活的方法，允许管理员为属性分配多个值。 在这一演进模式中，如果运行时上下文信息与为策略属性指定的任何值一致，就会建立匹配。 从本质上讲，现在的匹配过程是将跨属性的 “AND “操作与跨这些属性相关值的 “OR “操作相结合。 在制定综合政策时，各组织可从这种灵活性中大大获益。 它在保持可读性的同时，减少了所需的政策总数。 不过，这些多值属性只是朝着正确方向迈出的一步，通常还需要进一步改进，以满足组织的独特要求：支持 “NOT “装饰：管理员需要能够定义带有 “NOT “装饰的策略属性值。
例如，应该可以将 “源 IP “属性值指定为 “NOT 10.1.5.0/24″，表示当流量会话的源 IP 不属于 10.1.5.0/24 子网时，策略将成功匹配。支持一个属性的多个实例：许多传统安全设备只支持策略中给定属性的一个实例。 要创建全面的策略，必须能够在单个策略中包含同一属性的多个实例。 例如，管理员可能希望允许来自 10.0.0.0/8 子网中任何 IP 地址的会话，同时拒绝来自 10.1.5.0/24 子网的流量会话。 这应该可以在单个策略中实现，也许可以指定两次 “源 IP “值：”源 IP == 10.0.0.0/8 “和 “源 IP == NOT 10.1.5.0/24″。 这样就不需要创建两个单独的策略，策略管理也更加直观。支持字符串类型值的装饰：接受字符串值的属性，如 URI 路径、域名和许多 HTTP 请求标头，都能从 “精确”、”starts_with “和 “end_with “等装饰中受益。
这些装饰增强了策略创建的表现力。支持正则表达式模式：在某些情况下，策略需要在流量值中进行模式匹配。 例如，一项策略可能规定，只有在 “用户代理 “请求头值的任何地方出现特定模式时，才允许进行流量会话。 在这种情况下，对正则表达式模式的支持至关重要。支持动态属性：传统策略中的属性是固定和预定义的，而 SASE 环境有时需要动态属性。 考虑到请求和响应标头或 JWT 声明，标准与众多自定义标头和声明并存。 SASE 应授权管理员创建适应自定义标题和索赔的政策。 例如，SASE 应允许创建将请求头 “X-自定义头 “作为属性且值为 “matchme “的策略。在流量发生时，任何以 “X-custom-header “作为请求头之一、以 “matchme “作为值的 HTTP 会话都应与策略相匹配。支持对象：该功能允许创建各种类型的对象，这些对象的值可用作策略中的属性值，而不是直接指定值。 对象可在多个策略中引用，未来的任何值更改都可在对象级别上进行，从而简化策略修改并确保一致性。 这些增强功能有助于创建灵活、富有表现力和高效的安全策略，使企业能够根据独特的安全需求和场景有效地调整策略。

通过交通修改加强政策整合

某些安全功能需要对流量进行修改，最常见的用例涉及添加、删除或修改 HTTP 请求/响应头及其值、查询参数及其值，甚至请求/响应体。 根据管理员的配置，这些修改可能会有很大不同。 通常情况下，具体修改取决于流量值，如目的地应用程序/站点服务，以及流量运行时可用的上下文信息。 与其为流量修改维护一个单独的策略表，不如将这些修改对象包含在访问策略中，这样往往更有效。 这种方法可简化策略管理，确保修改与管理流量行为的策略直接保持一致。 在云访问安全代理（CASB）解决方案中，尤其是当企业需要多租户限制时，流量修改是必不可少的。 这些限制通常涉及添加特定的请求标头和值，以执行特定的协作政策。 此外，在其他一些情况下，例如为端到端故障诊断和性能分析添加自定义标头时，流量修改也发挥着至关重要的作用。 因此，企业希望 SASE 解决方案能够支持与修改对象无缝集成的策略。 在流量处理过程中，当匹配的策略与适当的修改对象相关联时，就会执行流量修改，从而为流量管理和策略执行提供统一高效的方法。

增强可观察性：

通常的做法是在每个流量会话结束时记录该会话，以便观察。 在涉及大量或 “大象 “会话的情况下，定期记录访问信息也是一种惯例。 这些会话日志通常包含宝贵的数据，包括流量元数据、会话期间采取的行动以及客户端和服务器之间传输的数据包和字节的详细信息。 SASE 的一个重大进步是整合了安全功能，并采用了单通道、运行时完成架构，从而形成了统一的会话日志。 这与非 SASE 安全部署形成了鲜明对比，在非 SASE 安全部署中，每个单独的安全组件都会生成自己的会话日志，其中通常包含已匹配策略的信息以及匹配过程中使用的关键属性值。 重要的是，虽然 SASE 生成的是单一日志，但人们期望它在包含关键信息方面不打折扣。 当一个流量会话因各种安全功能和策略表中的多个策略评估而被允许时，生成的日志应包含每个匹配策略的信息。 此外，如果由于特定流量或上下文属性的值导致策略匹配，日志应提供有关导致策略匹配的属性值的精确细节。 鉴于企业依赖全面的日志来实现有效的可观察性，SASE 解决方案有望在日志中提供全面的信息，确保管理员能够获得有效监控和分析网络流量所需的数据。

SASE 政策管理方法：

必须认识到，并非所有 SASE 解决方案都是相同的。 各组织应仔细评估特定的 SASE 解决方案是否符合其特定的组织要求，同时又不牺牲可用性。 虽然各组织最初可能并不具备上述所有要求，但这些要求对其运营的相关性和重要性与日俱增只是时间问题。 具备上述所有要求的组织可以完全灵活地根据自身的具体需要制定 SASE 政策。 另一方面，目前还不具备所有这些要求的组织通常会寻求更简单的用户体验，同时随着需求的发展而不断引入其他功能。 这种方法使企业能够在当前需求和未来发展之间取得平衡，确保其 SASE 解决方案能够适应和应对不断变化的环境。 除非 SASE 解决方案具有充分的灵活性，否则定制工作就会变得具有挑战性。 因此，我们认为 SASE 解决方案应具备以下核心功能：

  1. 模块化策略管理：SASE 解决方案包含多种安全功能，每种功能都有自己的一套策略配置。 这些配置应包括启用/禁用选项、设置无策略匹配时的默认操作、管理多个策略表的集合、在每个策略表中定义多个策略、建立策略有序列表，以及为每个策略设置操作设置、修改对象、匹配属性和值。
  2. 政策链：为实现更具体、更细化的政策，SASE 解决方案应支持政策链。 这意味着允许在一个集合中的多个策略表之间安排策略。 例如，企业可以为不同的应用设置不同的策略表，主表策略使用应用/域名称作为匹配条件，以选择适当的策略表。 这通常是通过使用具有 “跳转 “操作的策略来实现的，”跳转 “操作会将策略评估重定向到引用的策略表。 策略链的概念在 Linux IPTables 中大行其道，许多安全解决方案随后都采用了这一功能。

SASE 内的安全功能非常全面，可包括

  • NGFW（下一代防火墙）：提供 L3/L4 访问控制、DDoS 保护、IP 信誉、域信誉和入侵检测与防御系统 (IDPS)
  • SWG（安全 Web 网关）：提供 TLS 检查、TLS 前网络访问控制、TLS 后网络访问控制、URL 信誉、文件信誉和恶意软件保护。
  • ZTNA（零信任网络访问）：与 SWG 类似，但侧重于确保托管应用程序的安全。
  • CASB（云访问安全代理）：涵盖云服务信誉和云服务访问控制。
  • DLP（数据丢失防护）：根据个人身份信息 (PII)、标准机密文件和企业特定敏感文件实施访问控制。

每个安全功能的策略管理都非常灵活，还能通过策略链的多个策略表管理每个功能内的策略，这是一项强大的功能。 具有各种监管要求的地理分布组织尤其能从这种灵活性中受益。 不过，规模较小的组织可能更倾向于对政策表格进行某种合并。 在这种情况下，应该可以通过以下方式定制配置：

  • 将所有 TLS 前安全功能配置整合到多个 SWG/ZTNA 组件的单一策略表集合中。
  • 在多个 SWG/ZTNA 组件中，将所有后 TLS 安全功能配置整合到另一个单一的策略表集合中。
  • 将 CASB、恶意软件和 DLP 功能作为独立实体保留，因为这些功能需要复杂的策略定义。
  • 在策略表集合中选择单个策略表，从而避免策略链。

因此，企业应寻求既能提供充分灵活性，又能提供定制控制以整合相关安全功能配置的 SASE 服务。 这种方法可确保 SASE 政策符合组织的特定需求，同时随着需求的变化保持易于管理和可扩展性。

兼顾用户体验和面向未来的灵活性

安全策略管理历来是一项复杂的工作。 许多产品专门针对特定的安全设备进行策略管理，导致产品格局分散。 SASE 将多个安全设备整合为一个统一的解决方案，从而解决了这一复杂性。 虽然这种合并具有优势，但也带来了自身的复杂性。 传统的策略管理方法（如单一策略表）最初似乎很有吸引力。 然而，它们面临着诸多挑战，往往无法满足本文概述的要求。 相反，过多的策略引擎也会导致复杂性。 在灵活性和简洁性之间取得适当的平衡至关重要。 该行业面临的一个重大挑战是政策泛滥。 过多的策略不仅会降低用户体验和故障排除体验，还会影响性能。 如前所述，多表方法和政策表达能力是减少政策表内政策数量的基本策略。 SASE 解决方案通过提供更先进的政策管理，越来越多地解决这些复杂问题。 我们相信，SASE 解决方案将继续发展，在不久的将来实施本文详述的许多要求。 这种演变将使企业能够在用户体验、灵活性和性能之间取得最佳平衡，确保其安全策略在瞬息万变的威胁环境中保持有效性和适应性。

  • CTO Insights 博客

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