一、先搞懂两个架构的核心逻辑

很多人接触网络安全架构时，会先碰到两个完全不同的防护思路：传统的网络边界防护，还有现在越来越火的零信任架构。要是你之前没接触过这些，别着急，咱们用生活化的例子来掰明白。

1.1 传统网络边界防护是什么

传统防护的核心逻辑很简单，就是“圈地”。比如你家的小区，会设围墙、大门，只有住在小区里的人（或者有门禁卡的人）才能进，进了小区之后，你想逛超市、去邻居家、甚至进自己家门，只要没出小区这个大圈，就不用再反复查身份。放到公司网络里也是一样：公司会搭一个内部网络，外面的人（比如互联网上的黑客）要进来，得经过防火墙、VPN这些“大门”，一旦你通过VPN连进公司内网，就相当于进了小区，之后访问公司的服务器、数据库、内部系统，大多不用再反复验证身份，权限也是提前给你定好的——比如你是市场部的，公司就给你开了访问市场部系统的权限，整个内网里只要是市场部能碰的，你都能碰。

这种思路的优点很明显：管理简单，不用频繁验证，适合以前那种大家都在公司办公、很少有远程访问的场景。但缺点也很致命：只要有人拿到了小区的门禁卡（比如黑客破解了VPN密码），那他在小区里就可以随便逛，甚至偷邻居家的东西，很难管。

1.2 零信任架构是什么

零信任的核心逻辑正好反过来，就是“永远不信任，始终验证”。还是拿小区举例：不管你是不是住在小区里，不管你是从大门进来的，还是从家里直接用手机连的小区内部系统，只要你想进单元门、进自己家门、甚至进小区里的超市，都得再刷一次脸、输一次密码，每次都得证明“你是谁”“你为什么能进这里”。放到公司网络里，就是不管你是在公司内网，还是远程连进来的，只要你想访问某个具体的资源（比如财务系统、数据库），都得先验证你的身份，再判断你有没有权限访问这个特定的资源，权限也会细化到“你只能看财务系统里的报销数据，不能改，更不能碰工资数据”。

零信任的优点是安全，哪怕有人拿到了小区门禁卡，也进不了具体的单元门；但缺点也很明显：每次访问都要验证，要是规则没弄好，很容易出现混乱。

二、融合的时候最容易踩的坑：授权规则冲突

现在很多公司不会直接把传统网络整个换掉，因为换的成本太高了——比如公司已经用了好几年的防火墙、VPN，还有很多老系统只能在传统内网里跑，所以大多会选择“融合”：保留原来的传统网络边界，同时在关键资源（比如核心数据库、财务系统）外面加零信任的防护。但这么一搞，就容易出问题：两个架构的授权规则撞车了。

举个实际的例子：公司的老财务系统，以前是放在传统内网里的，按照传统规则，只要是财务部门的员工，进了内网就能访问这个系统；现在公司给这个系统加了零信任防护，新的零信任规则是“只有财务经理能访问这个系统”。现在问题来了：一个普通的财务员工，用VPN连进了公司内网（符合传统规则），但访问财务系统时，零信任系统又拦着他（不符合零信任规则），这就出现了冲突。

更复杂的冲突还有：比如传统规则允许“市场部员工能访问所有内部服务器的80端口”，零信任规则允许“所有人能访问服务器的443端口”，结果市场部员工访问某台服务器的80端口时，被零信任拦了（因为零信任没开80端口的权限），但按传统规则是可以访问的，这就乱了。

三、解决冲突的核心方法：统一规则模型

要解决冲突，核心是不能让两个架构的规则各管各的，得把它们整合成一个统一的规则模型，让两个架构都按同一个标准来判断能不能访问。具体怎么做呢？咱们分步骤来，每个步骤都配实际的示例。

首先明确技术栈：所有示例都用Open Policy Agent（简称OPA），这是一个专门用来做统一授权的工具，能把不同架构的规则都转成它能识别的格式，适合用来做融合的规则管理。

3.1 第一步：把两个架构的规则转成统一的格式

不管是传统的边界规则，还是零信任的访问规则，本质上都是三个要素：访问的人是谁（身份）、访问的目标是什么（资源）、访问的动作是什么（比如读、写）。我们可以把所有规则都转成“如果满足X身份、X资源、X动作，就允许访问”的格式。

比如之前的财务系统例子，我们先把两个规则都转成OPA的格式：

# 传统规则：财务部门的人可以访问财务系统
package traditional_policy

default allow = false

allow {
    # 访问者属于财务部门
    input.user.department == "finance"
    # 访问的资源是财务系统
    input.resource == "finance_system"
}

# 零信任规则：只有财务经理可以访问财务系统
package zero_trust_policy

default allow = false

allow {
    # 访问者是财务经理
    input.user.role == "finance_manager"
    # 访问的资源是财务系统
    input.resource == "finance_system"
}

3.2 第二步：合并规则，明确优先级

现在两个规则都转成了统一格式，接下来要合并成一个规则集，还要明确优先级——到底是传统规则优先，还是零信任规则优先？一般来说，零信任的规则更严格，所以应该让零信任规则优先，也就是只有同时满足两个规则，或者满足更严格的零信任规则，才能访问。

合并后的规则应该是：只有当访问者是财务经理时，才能访问财务系统；普通财务员工，哪怕符合传统规则，也不能访问。具体的合并代码如下：

# 合并后的统一规则，零信任优先
package unified_policy

default allow = false

# 先判断零信任规则，如果允许，就直接通过
allow {
    # 调用零信任规则的allow结果
    zero_trust_policy.allow
}

# 如果零信任规则不允许，再判断传统规则（可选，根据需求调整）
allow {
    # 零信任规则不允许
    not zero_trust_policy.allow
    # 调用传统规则的allow结果
    traditional_policy.allow
}

3.3 第三步：统一验证入口

最后一步，要把所有访问请求都先送到这个统一的规则集里验证，不管这个请求是从传统内网来的，还是从零信任系统来的。比如，传统的防火墙要把访问请求先发给OPA，零信任系统也要把访问请求发给OPA，两个架构都按OPA返回的结果来判断能不能放行。

举个实际的访问验证示例，假设一个普通财务员工（张三）想访问财务系统，我们用OPA的测试命令来验证结果：

# 测试用例：普通财务员工访问财务系统
opa eval -i input.json -d traditional_policy.rego -d zero_trust_policy.rego -d unified_policy.rego "data.unified_policy.allow"

其中input.json的内容是：

{
    "user": {
        "name": "张三",
        "department": "finance",
        "role": "普通财务员工"
    },
    "resource": "finance_system"
}

运行结果会返回false，因为张三不满足零信任规则，所以被拒绝，解决了之前的冲突。

再测试一个财务经理（李四）的访问：

{
    "user": {
        "name": "李四",
        "department": "finance",
        "role": "finance_manager"
    },
    "resource": "finance_system"
}

运行结果返回true，符合预期。

四、应用场景、优缺点和注意事项

4.1 适用的应用场景

这种融合方案主要适合两类公司： 第一类是已经有成熟的传统网络架构，不想一次性更换，想逐步迁移到零信任的公司，比如有很多老业务系统的传统企业； 第二类是需要兼顾安全和效率的公司，比如有些内部系统的访问量很大，要是全用零信任的严格验证，会影响效率，所以可以用传统规则管普通的内部访问，用零信任规则管核心资源的访问。

4.2 技术优缺点

优点很明显：第一，能保留传统架构的优势，比如管理简单、访问效率高，不用一次性投入大量成本更换系统；第二，能叠加零信任的安全优势，核心资源的防护更严格；第三，通过统一规则模型，彻底解决了授权冲突的问题，不会出现同一个访问请求被两个架构给出不同结果的情况。

缺点也有：第一，初期的规则梳理成本高，要把原来所有的传统规则和新的零信任规则都转成统一格式，要是原来的规则很乱，梳理起来会很麻烦；第二，对运维人员的要求高，得懂两个架构的逻辑，还要会用统一授权工具（比如OPA）；第三，要是规则没设好优先级，可能会出现安全漏洞，比如把传统规则设成优先，那零信任的防护就失去意义了。

4.3 注意事项

第一，规则梳理要全面，不能漏掉任何一个传统规则，比如原来的防火墙规则、VPN规则、内网的访问控制规则，都要转成统一格式，不然会出现遗漏的授权漏洞； 第二，优先级一定要明确，一般来说，零信任规则的优先级要高于传统规则，因为零信任的核心是更严格的防护； 第三，要定期审计规则，因为公司的人员、系统、需求都会变，规则也要跟着更新，比如有人转岗了，对应的身份和角色要及时调整，不然会出现权限错误； 第四，要做灰度测试，不能一下子把所有访问都切到统一规则上，先拿非核心的系统做测试，没问题再推到核心系统，避免影响业务。

五、文章总结

零信任架构和传统网络边界防护的融合，核心难题就是授权规则冲突，本质是两个架构的防护逻辑不同，导致同一个访问请求可能有不同的判断结果。解决这个问题的核心，是把两个架构的规则转成统一的格式，合并成一个统一的规则集，明确优先级，再把所有访问请求都送到这个统一的规则集里验证。

这种方案既兼顾了传统架构的效率和成本优势，又能发挥零信任的安全优势，适合大多数正在从传统网络向零信任过渡的公司。只要做好规则梳理、优先级设置和定期审计，就能有效解决授权冲突的问题，实现两个架构的安全融合。