让安全变得简单：简化统一策略 SASE

平衡配置和控制对于降低安全风险和管理复杂性至关重要

安全访问服务边缘 (SASE）服务及其相关架构由多个安全组件的强大组合组成。 其中包括状态检测防火墙、入侵检测和防御系统 (IDPS)、 DNS 安全、DoS/DDoS 防护、安全 Web 网关 (SWG)、零信任网络架构 (ZTNA)、 Cloud 访问安全代理（CASB）， 还有很多。 这些组件使管理员能够通过策略进行配置，提供强大的保护来保护组织的资产免受威胁，同时遵守特定的访问要求。

策略配置的作用

策略配置发挥重要作用isp发挥在加强安全方面的作用 SASE 框架。 策略配置不当的后果可能包括资源威胁和数据泄露以及意外的、过于宽松的访问。 在当今的行业格局中，组织正在努力解决两种主要的安全策略管理方法：

1. 单表方法： 包含大量策略的综合策略表，涵盖威胁管理和各种访问控制场景 SASE 组件.
2. 多表方法： 多个策略表，每个策略表都针对特定方面，例如威胁防护、访问控制、不同的应用程序和用户组。

政策管理的平衡

期望来自 SASE 很明显：它应该提供易于管理的安全策略和简化的故障排除程序。 实现这一目标需要采取平衡的方法。 一种根据组织要求降低策略复杂性的有效策略。 较大的组织可能需要使用多表方法进行划分，其中策略表粒度是根据安全功能、应用程序资源和主题（用户/组）定义的。 较小的组织可能更喜欢使用较少数量的策略表进行划分，结合多种类型的访问控制，甚至将威胁防护与访问控制相结合。 这种灵活的方法最大限度地减少了需要同时管理的策略数量，使它们更易于管理。

然而，重要的是要谨慎行事，避免过度划分，这可能会带来一系列挑战。 管理员可能会发现自己需要浏览多个策略表来识别和解决问题，这可能会导致解决问题的延迟。

了解关键要求

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

需要基于角色的安全配置管理 SASE 环境

安全访问服务边缘（SASE) 组件提供全面的安全性，包括针对不同组织（包括其员工、合作伙伴和访客）的各种资源的威胁防护和访问控制。 在此安全框架内，组织通常有不同类别的管理员负责安全的不同方面。

例如，组织可能有一组管理员专门负责管理威胁防护，而另一组则专注于访问控制。 在这些大类中，组织通常会建立针对特定类型的威胁防护和访问控制的各种管理角色。 让我们深入研究一些实际示例：

威胁防护角色：

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

访问控制角色：

• SWG配置： 指定为“访问控制 Internet 角色”的管理员负责管理安全 Web 网关 (SWG) 配置。
• SaaS 特定于应用程序的访问控制： 像“访问控制-saas1app-role”和“访问控制-saasNapp-role”专注于为特定应用程序配置访问控制策略（SaaS 服务 1 和 SaaS 服务N），确保细粒度控制。
• 耳鼻喉科erp上升应用管理： “access-control-hostedapp1-role”和“access-control-hostedappM-role”等角色专门用于处理 ent 的访问控制配置erp上升级别的应用程序，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 员工的访问控制配置。

此外，即使是非多租户企业erp上升的应用程序可能需要针对不同劳动力部分的单独管理员。 例如：

• 工程部： 具有“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 提供商可以为多个组织提供服务。 这些组织在规模、监管要求及其结构中角色的多样性方面可能存在很大差异。 某些组织可能会在本地或外部托管多个应用程序 cloud，而其他人可能完全依赖于 SaaS 提供商，有些可能会结合两者。

此外，某些组织可能不需要各种管理角色或多个管理用户。 在组织只有有限数量的应用程序并且缺乏多个管理角色的复杂性的情况下，他们可能会发现使用较少的策略表是有价值的。

SASE 预计旨在提供满足这些不同需求所需的灵活性，包括为多个相关安全功能和应用程序使用合并策略表的选项。

避免混乱的配置：

某些 SASE 解决方案为了追求前面讨论的简化，选择一个单一的、包罗万象的策略表，其中可以使用各种匹配属性的值来配置策略。 在流量处理期间，策略选择基于将传入流量和其他上下文信息的值与策略中指定的属性值进行匹配。

然而，重要的是要认识到，在流量处理过程中，并非流量的所有属性都是显而易见的。 例如，在状态检测防火墙的情况下，只能提取有限的一组流量值，例如五元组信息（源IP、目标IP、源端口、目标端口和IP协议）。 同时，对于基于代理的安全组件，例如 SWG、ZTNA 和 CASB，属性值的提取可能会有所不同，并且可能涉及不同的阶段，特别是 Pre-TLS 检查和 Post-TLS 检查阶段。

在 TLS 检查/解密之前，许多 HTTP 属性仍然未知。 只有在 TLS 解密之后，其他属性（例如访问 URI 路径、HTTP 方法和请求标头）才可用于评估。

作为负责配置安全策略的管理员，期望管理员在定义策略时跟踪哪些属性在数据包处理的各个阶段有效是不切实际的。 虽然一些安全解决方案声称在策略评估中不考虑不相关的属性，但在检查复杂策略时确定哪些属性相关、哪些属性不相关可能具有挑战性。

我们坚信，将多个阶段的策略表合并到一个表中会给管理员带来复杂性和混乱。 这种方法可能难以理解，并可能导致潜在的问题。erp词法分析配置。 为了确保清晰度，建议在给定表中创建仅包含相关属性的策略，以实现一致且直接的评估。

优化拒绝和允许策略表：

某些安全解决方案采用一种结构，其中维护单独的“拒绝”和“允许”策略表。 在此设置中，“拒绝”列表中定义的策略优先并首先进行评估。 如果在“拒绝”表中没有找到匹配的策略，则评估继续到“允许”策略表。 然而，将策略划分为两个不同的表可能会给管理员带来挑战。

我们坚决主张采用更加简化的方法，其中任何给定的政策表都以有序的政策列表的形式呈现。 在这种安排中，每个策略都明确指定其操作 - 无论是“拒绝”、“允许”还是任何其他所需的操作。 在流量处理期间，策略评估遵循从最高优先级策略到最低优先级策略的逻辑进展，直到找到匹配项。 一旦识别出匹配的策略，相应的操作就会应用于流量。 如果未遇到匹配的策略，则会按照组织的安全策略的定义触发默认操作，例如“失败打开”或“失败关闭”。

这种方法通过将策略整合到单个有序列表中（无论策略操作值如何）来简化策略管理并提高管理员的清晰度，从而最大限度地降低复杂性并简化策略评估流程。 还启用了不根据操作值分隔策略表 SASE 解决方案提供商在未来相对容易地引入新的行动价值观。

制定灵活且富有表现力的政策:

正如您所收集的，管理员通过定义匹配属性的值集来制定策略。 传统上，对于流量评估期间策略匹配如何运行有一个共同的理解：只有当策略中指定的所有属性值与传入流量会话的值完全一致时，策略才被视为匹配。 这些值可以直接从流量中提取，也可以从上下文信息推断，例如经过身份验证的用户上下文和负责启动流量的设备上下文。 本质上，此匹配过程涉及策略所有属性的“AND”运算。

然而，随着安全技术的发展，许多安全设备引入了更灵活的方法，使管理员能够为属性分配多个值。 在这个演进的范例中，如果运行时上下文信息与为策略属性指定的任何值一致，则建立匹配。 本质上，匹配过程现在将跨属性的“AND”运算与跨与这些属性关联的值的“OR”运算组合起来。

在制定全面的政策时，组织将从这种灵活性中受益匪浅。 它减少了所需策略的总数，同时保持了可读性。 然而，这些多值属性只是朝着正确方向迈出的一步，通常需要进一步增强才能满足组织的独特需求：

支持“NOT”装饰： 管理员需要能够使用“NOT”修饰来定义策略属性值。 例如，应该可以将“源 IP”属性值指定为“NOT 10.1.5.0/24”，表示当流量会话的源 IP 不属于 10.1.5.0/24 子网时，策略将成功匹配。

支持属性的多个实例： 许多传统安全设备仅支持策略中给定属性的一个实例。 要创建全面的策略，在单个策略中包含同一属性的多个实例的能力至关重要。 例如，管理员可以 wan允许来自 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 请求标头）的属性受益于“exact”、“starts_with”和“ends_with”等修饰。 这些装饰增强了富有表现力的政策的制定。

对正则表达式模式的支持： 在某些情况下，策略需要流量值内的模式匹配。 例如，策略可能规定仅当“用户代理”请求标头值中的任何位置存在特定模式时才允许流量会话。 在这种情况下，对正则表达式模式的支持至关重要。

支持动态属性： 虽然策略中的传统属性是固定和预定义的， SASE 环境有时需要动态属性。 考虑请求和响应标头或 JWT 声明，其中标准与大量自定义标头和声明共存。 SASE 应该授权管理员创建适应自定义标头和声明的策略。 例如， SASE 应允许使用请求标头“X-custom-header”作为属性和值“matchme”创建策略。 在流量时，任何以“X-custom-header”作为请求标头之一、以“matchme”作为值的 HTTP 会话都应与策略匹配。

对对象的支持： 此功能允许创建各种类型的对象，其值可用作策略中的属性值，而不是指定立即值。 可以跨多个策略引用对象，并且可以在对象级别进行任何未来的值更改，从而简化策略修改并确保一致性。

这些增强功能有助于创建灵活、富有表现力且高效的安全策略，使组织能够有效地根据独特的安全需求和场景定制策略。

通过流量修改增强策略集成

某些安全功能需要对流量进行修改，最常见的用例涉及添加、删除或修改 HTTP 请求/响应标头及其值、查询参数及其值，甚至请求/响应正文。 这些修改可能会根据管理员的配置而有很大差异。 通常，具体修改取决于流量值，例如目标应用程序/站点服务，以及流量运行时期间可用的上下文信息。

将这些修改对象包含在访问策略本身中通常更有效，而不是为流量修改维护单独的策略表。 这种方法简化了策略管理，并确保修改直接与管理流量行为的策略保持一致。

流量修改至关重要的一个突出场景是在 Cloud 访问安全代理（CASB）解决方案，特别是当组织需要多租户限制时。 这些限制通常涉及添加特定的请求标头和值以强制执行特定于协作的策略。 此外，还有其他实例，例如添加用于端到端故障排除和性能分析的自定义标头，其中流量修改起着至关重要的作用。

因此，组织期望 SASE 支持无缝政策的解决方案ssly 与修改对象集成。 在流量处理过程中，当匹配的策略与适当的修改对象关联时，就会执行流量修改，从而为流量管理和策略执行提供统一且高效的方法。

增强可观察性：

出于可观察性的目的，通常的做法是在会话结束时记录每个流量会话。 在涉及大量或“大象”会话的情况下，通常还会定期记录访问信息。 这些会话日志通常包含有价值的数据，包括流量元数据、会话期间采取的操作以及有关客户端和服务器之间传输的数据包和字节的详细信息。

一项重大进步由 SASE 是安全功能的整合以及单遍、运行时完成架构的采用，从而产生统一的会话日志。 这与非SASE 安全部署，其中每个单独的安全组件生成自己的会话日志，通常包含有关匹配的策略和匹配过程中使用的关键属性值的信息。 重要的是，虽然 SASE 生成单个日志，但期望它不应该在关键信息的包含方面妥协。

当由于跨各种安全功能和策略表的多个策略评估而允许流量会话时，生成的日志应包含有关每个匹配策略的信息。 此外，如果策略由于特定流量或上下文属性的值而匹配，则日志应提供有关导致策略匹配的属性值的精确详细信息。

鉴于组织依赖全面的日志来实现有效的可观察性， SASE 解决方案有望在日志中提供全面的信息，确保管理员能够访问有效监控和分析网络流量所需的数据。

SASE 政策管理方法：

重要的是要认识到并非所有 SASE 解决方案是相同的。 组织应仔细评估特定的 SASE 解决方案符合其特定的组织要求，而不牺牲可用性。 虽然组织最初可能不具备上面列出的所有要求，但这只是一个 matt这些要求对于他们的运营变得越来越相关和重要还需要一段时间。

具有所有上述要求的组织可以在定制其产品时获得完全灵活性的优势 SASE 政策以满足他们的具体需求。 另一方面，目前不具备所有这些需求的组织通常会寻求更简单的用户体验，同时随着需求的发展不断关注引入附加功能。 这种方法使组织能够在当前需求和未来增长之间取得平衡，确保他们的 SASE 解决方案仍然能够适应不断变化的情况并做出响应。

除非 SASE 解决方案提供了充分的灵活性，定制变得具有挑战性。 因此，我们相信 SASE 解决方案应提供以下核心能力：

1. 模块化策略管理： SASE 解决方案包含多种安全功能，每种功能都有自己的一组策略配置。 这些配置应包括启用/禁用选项、在没有策略匹配的情况下设置默认操作、管理多个策略表的集合、在每个策略表中定义多个策略、建立策略的有序列表以及设置操作设置、修改对象、每个策略的匹配属性和值。
2. 政策链： 为了实现更具体、更精细的政策， SASE 解决方案应支持政策链。 这意味着允许跨集合中的多个策略表排列策略。 例如，组织可以针对不同的应用程序拥有单独的策略表，主表策略使用应用程序/域名作为匹配标准来选择适当的策略表。 这通常是通过使用具有称为“跳转”操作的策略来完成的，该操作将策略评估重定向到引用的策略表。 策略链的概念在 Linux IPTables 中流行起来，许多安全解决方案随后都融入了此功能。

内部安全功能的全面性 SASE 可以很广泛，可能包括：

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

每个安全功能的策略管理的灵活性，以及​​通过具有策略链的多个策略表来管理每个功能内的策略的能力，是一项强大的功能。 具有各种监管要求的地理分布式组织尤其可以从这种灵活性中受益。

然而，较小的组织可能更喜欢对策略表进行某种形式的整合。 在这种情况下，应该可以通过以下方式自定义配置：

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

因此，组织应该寻求 SASE 提供充分灵活性的服务，同时还提供自定义控件来整合相关安全功能的配置。 这种方法确保 SASE 策略是根据组织的特定需求量身定制的，同时随着需求的发展保持易于管理和可扩展性。

平衡用户体验与面向未来的灵活性

安全策略管理历来是一项复杂的工作。 许多产品专门针对特定安全设备进行策略管理，从而导致格局分散。 SASE 通过将多个安全设备整合到一个统一的解决方案中来解决这种复杂性。 虽然这种整合带来了优势，但它本身也带来了复杂性。

传统的策略管理方法（例如单一策略表）最初似乎很有吸引力。 然而，它们带来了许多挑战，并且常常无法满足本文中概述的要求。 相反，拥有过多的策略引擎也会导致复杂性。 在灵活性和简单性之间取得适当的平衡至关重要。

该行业面临的一项重大挑战是政策的泛滥。 过多的策略不仅会降低用户和故障排除体验，还会带来性能影响。 如前所述，多表方法和策略表达是减少策略表内策略数量的重要策略。

SASE 解决方案越来越多地通过提供更复杂的政策管理来解决这些复杂性。 我们相信 SASE 解决方案将继续发展，在不久的将来实现本文中详细介绍的许多要求。 这种演变将使组织能够在用户体验、灵活性和性能之间取得最佳平衡，确保其安全策略在快速变化的威胁环境中保持有效和适应性。

• CTO 见解博客

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