📚 课程目录第4章最小权限策略设计

4、最小权限策略设计：基于属性的访问控制（ABAC）模型、策略即代码（Policy as Code）实践、细粒度API级权限管控

最小权限，说白了就是给每个实体刚刚好的权限——不多给一分，也不少给一毫。但在边缘网关这种动态环境里，传统RBAC（基于角色的访问控制）已经有点力不从心了。角色太粗，权限太死，改一次策略要折腾半天。

我这些年做零信任落地，踩过最大的坑就是权限策略设计得太「静态」。设备换了、用户换了、环境变了，策略跟不上，要么太松出安全事件，要么太紧业务跑不动。后来全面转向ABAC，才算是找到了平衡点。

为什么是ABAC？

先看个对比，你就明白了。

维度	RBAC（基于角色）	ABAC（基于属性）
权限粒度	角色级别，粗粒度	属性级别，细粒度
动态性	静态，角色变更需管理员操作	动态，属性实时计算
扩展性	角色爆炸，维护成本高	属性组合，灵活扩展
上下文感知	不支持	支持时间、地点、设备状态等
边缘网关适配	差，离线场景难处理	好，策略可本地缓存执行

ABAC的核心思想很简单：谁（主体属性）在什么环境（环境属性）对什么资源（资源属性）能做什么操作（动作）。每个决策都是一次属性匹配计算。

关键点：ABAC不是要完全替代RBAC。我个人的习惯是「RBAC做粗筛，ABAC做精调」——先用角色过滤掉大部分无关权限，再用属性做最终裁决。这样性能更好，策略也更清晰。

ABAC模型在边缘网关中的落地

边缘网关的场景很特殊：网络可能断连、设备可能离线、计算资源有限。所以ABAC模型不能照搬云端那一套。

我画了一张图，帮你理解边缘网关ABAC的核心架构：

你看，整个流程其实不复杂。主体、环境、资源三组属性汇入策略决策引擎，引擎根据预定义的策略规则输出决策。边缘网关的特殊之处在于：策略必须本地缓存。我曾经遇到一个客户，他们的边缘节点经常断网，云端策略下不去，结果所有请求都被拒绝——业务直接瘫痪。后来改成本地缓存+异步同步，问题才解决。

实战建议：边缘网关的策略缓存建议使用LRU（最近最少使用）淘汰算法，保留最常用的策略条目。缓存大小根据网关内存来定，一般建议不超过10MB。我习惯在策略里加一个版本号字段，每次同步时比对版本，只更新变更的部分，节省带宽。

策略即代码（Policy as Code）实践

策略即代码，就是把访问控制策略当成软件代码来管理。版本控制、代码审查、自动化测试、CI/CD——一个都不能少。

为什么要这么做？你想想看，传统策略管理是什么样子？登录管理后台，点几个下拉框，保存。出了问题，谁改的？什么时候改的？改之前是什么样？全凭记忆。这在零信任体系里是致命的。

我个人推荐使用 OPA（Open Policy Agent） 配合 Rego 语言来编写策略。Rego 的声明式语法非常适合描述ABAC规则。

来看一个实际的边缘网关策略例子：

package edge_gateway.policy

# 默认拒绝
default allow = false

# 规则1：运维人员在办公时间可通过SSH访问网关管理接口
allow {
    input.subject.role == "operator"
    input.subject.security_level >= 3
    input.resource.path == "/api/v1/gateway/manage"
    input.action == "ssh"
    input.environment.time >= "09:00"
    input.environment.time <= "18:00"
    input.environment.network_type == "corporate"
}

# 规则2：传感器设备在非高危状态下可上报数据
allow {
    input.subject.type == "sensor"
    input.subject.trust_score >= 0.7
    input.resource.path == "/api/v1/data/report"
    input.action == "write"
    input.environment.risk_level < 8
}

# 规则3：审计员可读取所有非敏感资源的日志
allow {
    input.subject.role == "auditor"
    input.resource.classification == "internal"
    input.action == "read"
}

这段代码看起来是不是很清晰？每个规则就是一个逻辑与（AND）组合。Rego 还支持更复杂的逻辑，比如或（OR）、非（NOT）、集合运算等。

注意：策略即代码不是把策略写在代码里就完事了。你还需要：

把策略文件纳入Git仓库管理
每次变更必须走Pull Request + Code Review
编写自动化测试用例覆盖所有规则分支
在CI流水线中执行策略语法检查和单元测试
灰度发布策略，先推送到少量边缘节点验证

我曾经在一个项目中吃过亏。当时写了一条Rego规则，逻辑看起来没问题，但实际运行时因为属性名拼写错误（把"security_level"写成了"security_leve"），导致规则永远匹配不上，所有请求都被默认拒绝。生产环境炸了半小时才定位到问题。从那以后，我强制要求每条策略必须有对应的单元测试。

策略测试示例：

package edge_gateway.policy.test

import data.edge_gateway.policy

# 测试：运维人员在工作时间通过公司网络访问管理接口
test_operator_allowed {
    policy.allow with input as {
        "subject": {"role": "operator", "security_level": 3},
        "resource": {"path": "/api/v1/gateway/manage"},
        "action": "ssh",
        "environment": {"time": "14:00", "network_type": "corporate"}
    }
}

# 测试：运维人员在非工作时间被拒绝
test_operator_denied_outside_hours {
    not policy.allow with input as {
        "subject": {"role": "operator", "security_level": 3},
        "resource": {"path": "/api/v1/gateway/manage"},
        "action": "ssh",
        "environment": {"time": "22:00", "network_type": "corporate"}
    }
}

细粒度API级权限管控

边缘网关暴露的API，少则几十个，多则上百个。每个API的每个操作（GET/POST/PUT/DELETE）都需要精细管控。你不能让一个温度传感器去调用网关的固件升级接口，对吧？

细粒度API管控，我一般分三层来做：

路由层过滤：基于URL路径和方法做第一层粗筛，拦截明显不合法的请求。
策略层裁决：调用ABAC策略引擎，基于属性做精细决策。
数据层过滤：对响应结果做字段级别的脱敏或过滤，防止数据泄露。

来看一个实际的API权限配置示例（YAML格式，配合OPA使用）：

api_version: v1
resources:
  - path: "/api/v1/sensor/data"
    methods: ["POST"]
    description: "传感器数据上报"
    policy_ref: "sensor_data_report"
    rate_limit: 1000/minute

  - path: "/api/v1/gateway/config"
    methods: ["GET", "PUT"]
    description: "网关配置管理"
    policy_ref: "gateway_config_management"
    rate_limit: 10/minute

  - path: "/api/v1/logs/audit"
    methods: ["GET"]
    description: "审计日志查询"
    policy_ref: "audit_log_query"
    rate_limit: 30/minute

policies:
  - name: "sensor_data_report"
    rules:
      - subject.type: "sensor"
        subject.trust_score: ">= 0.6"
        environment.risk_level: "< 9"
        effect: "allow"
      - effect: "deny"

  - name: "gateway_config_management"
    rules:
      - subject.role: "admin"
        environment.network_type: "corporate"
        effect: "allow"
      - subject.role: "operator"
        action: "GET"
        environment.time: "09:00-18:00"
        effect: "allow"
      - effect: "deny"

  - name: "audit_log_query"
    rules:
      - subject.role: "auditor"
        effect: "allow"
      - subject.role: "admin"
        effect: "allow"
      - effect: "deny"

这个配置里，每个API都绑定了对应的策略引用。策略规则支持条件组合，从上到下匹配，命中即返回。最后一条兜底的deny确保所有未明确允许的请求都被拒绝。

核心原则：API权限管控要遵循「默认拒绝，显式允许」的原则。不要试图列举所有被拒绝的情况，而是只列出允许的情况，其余全部拒绝。这样即使漏写了一条规则，也是安全的——请求被拒绝，而不是被放行。

嗯，这里还要提一个容易被忽略的点：API版本管理。边缘网关的API会迭代，旧版本API可能包含安全漏洞。我建议在策略中强制要求客户端声明API版本，只允许使用当前支持的版本。比如：

allow {
    input.resource.path == "/api/v2/sensor/data"
    input.subject.api_version == "2.0" or input.subject.api_version == "2.1"
    # 其他条件...
}

这样，当某个API版本被废弃时，只需要更新策略，所有使用旧版本的客户端自动被拒绝，不需要修改网关代码。

最后，总结一下最小权限策略设计的三个关键动作：

用ABAC替代纯RBAC，引入属性维度，让策略能感知上下文
把策略当代码管，版本化、测试化、自动化，告别「黑盒策略」
API级精细管控，三层过滤+默认拒绝，不给攻击者留任何缝隙

做到这三点，你的边缘网关权限体系就算立住了。下一层，我们聊聊身份与设备信任评估——毕竟，策略再完美，如果连请求方是谁都搞不清楚，那也是白搭。