将自然语言描述的访问控制策略解析为结构化规则，支持中文策略输入，用于生成环的策略配置
接收中文自然语言描述的访问控制策略，利用大模型将其解析为可执行的结构化规则。 支持 ABAC（基于属性的访问控制）模型，生成包含主体属性、资源属性、条件约束、操作类型的规则定义。
管理员输入（中文策略描述）
│
▼
policy-parser（本 Skill）──→ 结构化规则
│
▼
access-decision（运行时消费）
{
"policy_text": "研发部成员在工作时间（周一到周五 9:00-18:00）可以读取用户表，但不可查看手机号和身份证号字段",
"context": {
"existing_roles": ["研发部", "运维部", "数据部"],
"existing_tables": ["T_USER", "T_ORDER", "T_PRODUCT"],
"sensitive_columns": {
"T_USER": ["PHONE", "ID_CARD", "PASSWORD"]
}
}
}
从自然语言中识别以下四类实体：
| 实体类型 | 说明 | 示例 |
|---|---|---|
| 主体（Subject） | 谁 | 研发部成员、角色名、用户名 |
| 资源（Resource） | 访问什么 | 用户表、T_USER、PHONE 字段 |
| 操作（Action） | 做什么 | 读取、修改、删除、导出 |
| 条件（Condition） | 什么情况下 | 工作时间、特定 IP、审批通过 |
| 消歧场景 | 处理方式 |
|---|---|
| "研发部成员" | 关联到已有角色 研发部，或提示创建新角色 |
| "用户表" | 模糊匹配到 T_USER，展示匹配结果供确认 |
| "读取" | 映射为 SQL 权限 SELECT |
| "不可查看" | 映射为列级权限排除列表 |
将解析结果转化为标准规则格式，一条自然语言策略可能生成多条规则：
每条规则包含以下字段：
| 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
rule_id | string | 是 | 规则唯一标识，格式 {policy_id}-R{n} |
effect | enum | 是 | ALLOW 或 DENY |
description | string | 是 | 规则的中文描述，便于人工审阅 |
subject | object | 是 | 主体定义，type: ROLE / USER，value: 角色名或用户名 |
resource | object | 是 | 资源定义，type: TABLE / COLUMN / SCHEMA |
resource.schema | string | 是 | 所属模式名。值为 * 时表示匹配所有模式 |
action | object | 是 | 操作定义，type: SQL_PRIVILEGE，value: SELECT / INSERT / UPDATE / DELETE |
condition | object | 是 | 条件约束，空对象 {} 表示无条件限制 |
priority | number | 是 | 优先级，数字越大越优先，DENY 规则建议 ≥ 200 |
| 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
time_range | object | 否 | 时间窗口约束 |
time_range.days_of_week | number[] | 否 | 星期几生效，1=周一，7=周日 |
time_range.start | string | 否 | 开始时间，格式 HH:mm |
time_range.end | string | 否 | 结束时间，格式 HH:mm |
ip_range | string[] | 否 | 允许的 IP 段列表，使用 CIDR 格式 |
approval_required | boolean | 否 | 是否需要审批，默认 false |
additional | object | 否 | 扩展字段，用于未来扩展（如数据量限制、行数上限等） |
当
condition为空对象{}时，表示该规则在任何条件下均生效（无约束）。
{
"policy_id": "POL-001",
"source_text": "研发部成员在工作时间（周一到周五 9:00-18:00）可以读取用户表，但不可查看手机号和身份证号字段",
"parsed_rules": [
{
"rule_id": "POL-001-R1",
"effect": "ALLOW",
"description": "研发部在工作时间读取用户表（排除敏感列）",
"subject": {
"type": "ROLE",
"value": "研发部"
},
"resource": {
"type": "TABLE",
"schema": "dbo",
"name": "T_USER",
"excluded_columns": ["PHONE", "ID_CARD"]
},
"action": {
"type": "SQL_PRIVILEGE",
"value": "SELECT"
},
"condition": {
"time_range": {
"days_of_week": [1, 2, 3, 4, 5],
"start": "09:00",
"end": "18:00"
},
"ip_range": ["192.168.1.0/24", "10.0.0.0/8"],
"approval_required": false,
"additional": {}
},
"priority": 100
},
{
"rule_id": "POL-001-R2",
"effect": "DENY",
"description": "研发部禁止查看手机号和身份证号",
"subject": {
"type": "ROLE",
"value": "研发部"
},
"resource": {
"type": "COLUMN",
"schema": "dbo",
"table": "T_USER",
"columns": ["PHONE", "ID_CARD"]
},
"action": {
"type": "SQL_PRIVILEGE",
"value": "SELECT"
},
"condition": {},
"priority": 200
}
],
"conflicts": [
{
"with_rule_id": "POL-002-R1",
"conflict_type": "EFFECT_CONFLICT",
"description": "POL-001-R1 允许研发部访问 T_USER，但 POL-002-R1 禁止研发部访问 T_USER",
"resolution": "DENY 优先原则：POL-002-R1（DENY）优先于 POL-001-R1（ALLOW）"
}
],
"ambiguities": [
{
"term": "相关人员",
"location": "POL-003 源文本第 2 段",
"suggestion": "请明确具体角色或用户组，例如「研发部」或「DBA 角色」"
},
{
"term": "适当的时候",
"location": "POL-003 源文本第 3 段",
"suggestion": "请指定具体时间范围，例如「工作日 9:00-18:00」"
}
]
}
conflicts（规则冲突）：
| conflict_type | 含义 | 示例场景 |
|---|---|---|
EFFECT_CONFLICT | 同一资源上存在 ALLOW 和 DENY 冲突 | A 规则允许 SELECT，B 规则禁止 SELECT 同一张表 |
OVERLAP_CONFLICT | 多条规则覆盖范围重叠 | 两条 ALLOW 规则针对同一张表但条件不同 |
PRIORITY_CONFLICT | 规则优先级设置不合理 | 低优先级 DENY 会被高优先级 ALLOW 覆盖 |
ambiguities（语义歧义）：
| 触发条件 | 处理方式 |
|---|---|
| 无法关联到已有角色/表/列 | 列出候选匹配项供用户选择 |
| 时间/范围描述模糊（如"适当的时候"） | 建议用户指定精确值 |
| 否定表述不明确（如"不可随意修改"） | 确认是完全禁止还是需要审批 |
| 策略描述中包含自相矛盾的语句 | 标记矛盾点，提示用户修正 |
| 规则 | 说明 |
|---|---|
| DENY 优先 | 同一资源上 DENY 规则优先级高于 ALLOW |
| 数字越大越优先 | 自定义规则优先级数字越大，越优先匹配 |
| 精确匹配优先 | 列级规则优先于表级规则，表级优先于模式级 |
ambiguities 中提示用户确认conflicts 中；EFFECT_CONFLICT 不阻断生成，由 DENY 优先原则自动解决resource.schema 为必填字段。值为 * 时表示匹配所有模式；值为具体模式名时仅匹配该模式。若自然语言中未提及模式，默认使用 *condition: {} 表示无条件限制，规则在任何时间、任何 IP 下均生效；DENY 规则建议使用空条件以确保全天候拦截