arch-validate

# ============================================================
# Rules: accuracy-rules.yaml
# 维度: Cloud_Network_Completeness (E-) + Connectivity
# 权重: Cloud_Network_Completeness=2.0（4类各25%）
#        Connectivity=1.0
# ============================================================

ruleset:
  name: "accuracy-rules"
  version: "2.0"

# ──────────────────────────────────────────────────────────────
# 维度 1: Cloud_Network_Completeness（权重 2.0）
# ──────────────────────────────────────────────────────────────
cloud_network:
  dimension: "Cloud_Network_Completeness"
  weight: 2.0
  subcategory_weight: 0.25    # 4个类别均分

  known_datacenters:
    - id: "hohhot-dc"
      name: "内蒙古DC / Hohhot DC"
      location: { city: "呼和浩特", province: "内蒙古", country: "CN" }
      expected_zones: ["DMZ", "App Zone", "DB Zone"]
    - id: "shenyang-dc"
      name: "沈阳DC / Shenyang DC"
      location: { city: "沈阳", province: "辽宁", country: "CN" }
      expected_zones: ["DMZ", "Intranet"]
    - id: "reston-dc"
      name: "Reston DC"
      location: { city: "Reston", state: "Virginia", country: "US" }
      expected_zones: ["DMZ", "APP SEN", "DB SEN"]

  rules:

    # ── E-A: 部署位置/司法区 ───────────────────────────────────
    - id: "E-001"
      category: "location"
      name: "数据中心须标注城市级位置"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        所有私有数据中心节点须标注精确到城市的地理位置。
        标注格式（任选）：
        - 城市名 + DC 名称：如 "呼和浩特 DC" / "Hohhot DC"
        - DC 名称内含位置：如 "Shenyang DC"
      check_target: "private_dc_nodes"
      validation_logic: "dc_has_city_location"
      impact: "无位置信息无法判断数据主权和合规适用法规"
      suggestion: "在数据中心节点上标注城市名称，参考 known_datacenters 配置"

    - id: "E-002"
      category: "location"
      name: "公有云须标注 Region"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        所有公有云节点须标注 Region 信息，支持全称或官方简写：
        | 云平台 | 示例全称            | 示例简写         |
        |--------|--------------------|--------------------|
        | Azure  | Azure East US      | Azure PRC北三       |
        | AWS    | AWS ap-southeast-1 | AWS Singapore      |
        | GCP    | GCP asia-east1     | GCP 东亚-台湾      |
        | 阿里云  | 阿里云 华东2（上海）  | AliCloud cn-shanghai |
      check_target: "public_cloud_nodes"
      validation_logic: "cloud_node_has_region"
      impact: "无 Region 标注无法验证数据驻留合规性"
      suggestion: "在公有云节点标题或副标题处添加 Region 标注"

    - id: "E-003"
      category: "location"
      name: "SaaS 和第三方系统须标注司法区/国家"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        所有 SaaS 服务和第三方系统节点须标注其运营所在的司法区（国家或州/省）。
        标注格式示例：
        - "Salesforce（美国）"
        - "SAP S/4 HANA（CN）"
        - "Workday（US - Oregon）"
      check_target: "saas_and_third_party_nodes"
      validation_logic: "external_node_has_jurisdiction"
      impact: "SaaS 所在司法区影响数据跨境传输合规性评估"
      suggestion: "在 SaaS/第三方节点名称后添加司法区标注"

    # ── E-B: 所有权/供应商 ────────────────────────────────────
    - id: "E-004"
      category: "ownership"
      name: "基础设施须标注所有者/供应商"
      severity: "error"
      issue_type: "must_fix"
      priority: "Medium"
      description: >
        每个云/DC 节点须标注基础设施所有者或供应商：
        - InfraSec 提供：标注 "InfraSec"（默认，若未标注则假定为 InfraSec）
        - 其他供应商：必须显式标注，如 "公司提供" / "第三方托管"
        - 业务部门自建：标注所属部门名称
      check_target: "all_infra_nodes"
      validation_logic: "node_has_owner_label"
      impact: "所有权不明确影响安全责任划分和变更管理审批"
      suggestion: "在节点标题区域添加所有者标注，格式：'[节点名称] (InfraSec)'"

    # ── E-C: 网络分段 ─────────────────────────────────────────
    - id: "E-005"
      category: "network_segmentation"
      name: "私有云须标注网络Zone"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        私有数据中心内的技术组件必须位于明确的网络 Zone 内：
        - DMZ（隔离区，对外暴露服务）
        - App Zone（应用区，业务逻辑层）
        - DB Zone（数据区，数据存储层）
        - Intranet（内网，泛指非 DMZ 区域）
        - APP SEN / DB SEN（Reston DC 专用分段）
        
        禁止技术组件"悬空"于数据中心内而不属于任何 Zone。
      check_target: "private_dc_tech_components"
      validation_logic: "component_has_network_zone"
      impact: "无网络 Zone 标注无法评估防火墙策略和横向移动风险"
      suggestion: "将每个技术组件拖入对应的 Zone 容器（DMZ/App Zone/DB Zone）"

    - id: "E-006"
      category: "network_segmentation"
      name: "Azure 须标注 VNET 和 Subnet"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        Azure 部署的技术组件须标注其所在的 VNET 和 Subnet：
        - 使用 VNET（不得写 VPC）表示 Azure 网络隔离单元
        - Subnet 须区分 Private Subnet 和 Public Subnet
        - 部分 PaaS 服务不部署在 Subnet 内（如 Azure Storage、Azure Service Bus），
          但须标注其访问方式（Public Endpoint / Private Endpoint）
      check_target: "azure_cloud_components"
      validation_logic: "azure_component_has_vnet_subnet"
      impact: "VNET/Subnet 信息缺失无法验证网络隔离和私有端点配置"
      suggestion: "在 Azure 节点中绘制 VNET 容器，内含 Private/Public Subnet 子容器，技术组件放入对应 Subnet"

    - id: "E-007"
      category: "network_segmentation"
      name: "AWS/GCP/阿里云须标注 VPC 和 Subnet"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        AWS、GCP、阿里云部署的技术组件须标注所在 VPC 和 Subnet（使用 VPC，不得写 VNET）。
        PaaS 服务若不在 Subnet 内，须标注访问端点类型。
      check_target: "aws_gcp_ali_cloud_components"
      validation_logic: "cloud_component_has_vpc_subnet"
      impact: "同 E-006"
      suggestion: "在对应云节点中绘制 VPC 容器，内含 Subnet，技术组件放入对应 Subnet"

    # ── E-D: 实体重复 ─────────────────────────────────────────
    - id: "E-008"
      category: "duplication"
      name: "禁止重复绘制同一 DC 或 Region"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        同一数据中心或公有云 Region 不得在架构图中出现多个独立节点。
        若同一 DC 内有多个 Zone，应使用嵌套结构（Zone 在 DC 容器内）而非多个 DC 节点。
      check_target: "all_infra_nodes"
      validation_logic: "no_duplicate_dc_or_region"
      impact: "重复 DC 节点导致通信路径分析错误和部署信息歧义"
      suggestion: "合并重复的 DC/Region 节点，使用嵌套 Zone 表示内部分段"

# ──────────────────────────────────────────────────────────────
# 维度 2: Connectivity（权重 1.0）
# ──────────────────────────────────────────────────────────────
connectivity:
  dimension: "Connectivity"
  weight: 1.0

  connection_types:
    - "互联网（Internet）"
    - "IPSec VPN"
    - "SSL VPN"
    - "MPLS 专线"
    - "SD-WAN"
    - "Azure ExpressRoute"
    - "AWS Direct Connect"
    - "GCP Cloud Interconnect"
    - "阿里云高速通道"

  rules:

    - id: "E-009"
      dimension: "Connectivity"
      name: "跨 DC/云/SaaS 连接须标注连接方式"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        不同数据中心之间、数据中心与公有云之间、以及与 SaaS/第三方之间的连接，
        须在连接线旁或使用图标标注连接方式（见 connection_types）。
        此标注位于 DC/云节点层级，不要求标注在每条通信流箭头上。
      check_target: "inter_dc_cloud_connections"
      validation_logic: "cross_boundary_connection_has_type_label"
      scoring:
        formula: "missing_label_count / total_cross_boundary_connections * dimension_weight"
      impact: "连接方式不明确无法评估传输安全性和带宽/延迟风险"
      suggestion: "在 DC/云之间的连接线旁添加连接方式图标或文字标注"

    - id: "E-010"
      dimension: "Connectivity"
      name: "跨区连接须标注是否加密"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        DC 间和 DC 与云间的连接须明确标注是否加密及加密方式：
        - VPN 连接：标注 IPSec 或 SSL
        - 专线/MPLS：标注是否叠加 IPSec 加密
        - 互联网直连：必须标注 TLS 加密
      check_target: "inter_dc_cloud_connections"
      validation_logic: "cross_boundary_connection_has_encryption_label"
      scoring:
        formula: "missing_encryption_count / total_cross_boundary_connections * dimension_weight"
      impact: "跨区明文传输存在数据泄露风险，可能违反等保/ISO27001 要求"
      suggestion: "在连接方式标注旁补充加密方式，如 'IPSec VPN (AES-256)'"

# ──────────────────────────────────────────────────────────────
# 维度 3: Technical_Component_Completeness（权重 2.0）
# ──────────────────────────────────────────────────────────────
technical_component:
  dimension: "Technical_Component_Completeness"
  weight: 2.0
  subcategory_weight: 0.333   # 3个类别均分

  component_types:
    - "Web Frontend"
    - "Backend Service / API"
    - "Background Job / Worker"
    - "Database"
    - "Message Queue"
    - "Cache"
    - "Integration Platform"
    - "API Gateway"
    - "Identity Provider"

  runtime_types:
    - "Container (Docker)"
    - "Kubernetes Pod"
    - "Virtual Machine (VM)"
    - "Physical Machine"
    - "PaaS Managed Service"
    - "Serverless Function"

  rules:

    - id: "E-011"
      category: "name_and_type"
      name: "技术组件须标注名称和类别"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        每个技术组件节点须包含：
        1. 服务/进程名称（非泛称，如 "OrderService" 而非 "微服务"）
        2. 组件类别（见 component_types）
        缺少任一视为不完整。
      check_target: "all_tech_components"
      validation_logic: "component_has_name_and_type"
      scoring:
        formula: "incomplete_count / total_components * subcategory_weight * dimension_weight"
      impact: "组件名称模糊导致无法与 IaC 代码对应，影响部署验证"
      suggestion: "使用实际服务名称（如部署在 K8s 中的 Deployment name）标注组件"

    - id: "E-012"
      category: "tech_stack"
      name: "技术组件须标注语言/框架/关键库"
      severity: "error"
      issue_type: "must_fix"
      priority: "Medium"
      description: >
        自研技术组件须标注：
        - 编程语言（Java / Python / Node.js / Go / .NET 等）
        - 主要框架（Spring Boot / FastAPI / Express / Gin 等）
        - 关键库（可选，用于安全审查）
        
        公有云托管服务须标注服务类型（如 Azure App Service / AWS Lambda）。
        第三方商业软件（SAP、Salesforce）不要求标注语言/框架。
      check_target: "custom_dev_components"
      validation_logic: "custom_component_has_tech_stack"
      scoring:
        formula: "missing_stack_count / custom_component_total * subcategory_weight * dimension_weight"
      impact: "缺少技术栈信息无法进行安全漏洞扫描范围界定"
      suggestion: "在组件节点副标题或注释中添加：语言 + 框架，如 'Java / Spring Boot'"

    - id: "E-013"
      category: "runtime_environment"
      name: "技术组件须标注运行环境"
      severity: "error"
      issue_type: "must_fix"
      priority: "High"
      description: >
        每个技术组件须通过以下方式之一标注运行环境（见 runtime_types）：
        1. 将组件放置在技术平台 Frame 内（如 Kubernetes Frame、VM Frame）
        2. 在组件节点上使用运行环境图标
        3. 在组件节点注释中文字说明
        
        技术平台自身须标注所有者（自建须注明所属部门）。
      check_target: "all_tech_components"
      validation_logic: "component_has_runtime_label"
      scoring:
        formula: "missing_runtime_count / total_components * subcategory_weight * dimension_weight"
      impact: "运行环境不明确无法评估补丁管理责任和容器安全策略"
      suggestion: "将技术组件放入对应的技术平台 Frame（K8s/VM）中，或在节点上标注运行环境"

# ============================================================
# Rules: diagram-rules.yaml
# 维度: Terminology_Expression (V-) + 部分 Interaction (W-)
# 说明: 可由规则引擎(Rust)进行静态检查的图形规范规则
#       无法静态检查的（如箭头语义）由 arch-validate-skill 负责
# ============================================================

ruleset:
  name: "diagram-rules"
  version: "2.0"
  dimension: "Terminology_Expression"
  weight_contribution: 1.0      # 本规则集对 Terminology_Expression 的贡献权重

rules:

  # ── 实线/虚线规范 ──────────────────────────────────────────
  - id: "V-001"
    name: "物理实体必须使用实线边框"
    severity: "error"           # error=must_fix / warning=suggestion
    issue_type: "must_fix"
    priority: "High"
    description: >
      数据中心、VPC/VNET、Subnet、网络 Zone、技术组件等物理实体必须使用实线（solid）边框表示。
      逻辑概念（云订阅、Resource Group、用户组、用户角色）必须使用虚线（dashed）边框表示。
    check_target: "all_entities"
    validation_logic: "border_style_matches_entity_class"
    impact: "实线/虚线混用导致物理与逻辑边界模糊，评审者无法判断实际部署范围"
    suggestion: "物理实体改为实线；云订阅/Resource Group/用户角色改为虚线"

  # ── 箭头规范 ───────────────────────────────────────────────
  - id: "V-002"
    name: "禁止使用双向箭头"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      架构图中所有通信流箭头必须为单向箭头。
      若两组件互相调用，须用两条独立的单向箭头分别表示，并各自标注协议和认证方式。
      例外：Kafka 的生产者和消费者可各自画单向箭头指向 Kafka，不视为双向箭头。
    check_target: "all_arrows"
    validation_logic: "arrow_is_bidirectional"
    impact: "双向箭头无法区分调用方与服务方，造成认证方向、协议标注歧义"
    suggestion: "将双向箭头拆分为两条单向箭头，分别标注协议（如 HTTPS）和认证方式"

  - id: "V-003"
    name: "Kafka 连接箭头必须指向 Kafka"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      所有与 Kafka 交互的组件（生产者和消费者）的通信箭头必须以 Kafka 为箭头指向目标。
      即：Producer → Kafka，Consumer → Kafka（消费关系也用指向 Kafka 的箭头）。
    check_target: "kafka_connections"
    validation_logic: "arrow_target_is_kafka"
    impact: "箭头方向错误导致无法判断数据流向，混淆生产者/消费者角色"
    suggestion: "统一将所有 Kafka 相关箭头方向改为指向 Kafka 节点"

  # ── 节点形状规范 ───────────────────────────────────────────
  - id: "V-004"
    name: "技术组件/服务使用圆角矩形"
    severity: "warning"
    issue_type: "suggestion"
    priority: "Low"
    description: "技术组件或服务节点应使用圆角矩形（rounded rectangle）表示，与数据中心/Zone 的直角矩形区分。"
    check_target: "tech_component_nodes"
    validation_logic: "shape_is_rounded_rectangle"
    impact: "形状不统一降低图表可读性"
    suggestion: "将技术组件节点形状统一改为圆角矩形"

  - id: "V-005"
    name: "数据中心/网络Zone使用直角矩形"
    severity: "warning"
    issue_type: "suggestion"
    priority: "Low"
    description: "数据中心和网络 Zone（DMZ、App Zone、DB Zone）使用直角矩形（rectangle）表示。"
    check_target: "dc_zone_nodes"
    validation_logic: "shape_is_rectangle"
    impact: "形状混用影响层次识别"
    suggestion: "数据中心和 Zone 节点统一使用直角矩形"

  - id: "V-006"
    name: "技术平台使用 Frame 表示"
    severity: "warning"
    issue_type: "suggestion"
    priority: "Low"
    description: "Kubernetes、容器平台等技术平台使用 Frame（带标题栏的容器框）表示，技术组件放置于其内部。"
    check_target: "platform_nodes"
    validation_logic: "shape_is_frame"
    impact: "技术平台形状不规范，无法直观表示组件的宿主关系"
    suggestion: "将技术平台改为 Frame 形状，并将其承载的技术组件放置在 Frame 内部"

  # ── 命名规范 ───────────────────────────────────────────────
  - id: "V-007"
    name: "节点命名规范"
    severity: "warning"
    issue_type: "suggestion"
    priority: "Low"
    description: >
      节点名称须满足：
      1. 使用 PascalCase 或 kebab-case
      2. 不允许未定义缩写
      3. 名称长度 ≤ 40 字符
    check_target: "all_nodes"
    validation_logic: "name_matches_naming_convention"
    impact: "命名不规范影响图表可读性和自动化解析"
    suggestion: "统一节点命名风格，使用完整词汇或组织预定义缩写表中的缩写"

  # ── 图例规范 ───────────────────────────────────────────────
  - id: "V-008"
    name: "架构图必须包含图例"
    severity: "error"
    issue_type: "must_fix"
    priority: "Medium"
    description: "每张技术架构图必须包含图例区域，说明图中使用的所有自定义形状、颜色和线型含义。"
    check_target: "diagram_legend"
    validation_logic: "legend_exists"
    impact: "无图例导致读者无法解读图形语义，特别是自定义颜色和线型"
    suggestion: "在架构图右下角或底部添加图例区域，列出形状/颜色/线型说明"

  # ── 颜色规范 ───────────────────────────────────────────────
  - id: "V-009"
    name: "同类实体颜色一致"
    severity: "warning"
    issue_type: "suggestion"
    priority: "Low"
    description: "同一类实体（如所有内部应用、所有数据库）在全图中应使用一致的颜色，避免随机配色。"
    check_target: "all_entities_by_type"
    validation_logic: "same_type_same_color"
    impact: "颜色不一致使得类型识别困难，降低图表信息密度"
    suggestion: "参考 diagram-style.yaml 中定义的颜色规范，统一各类实体颜色"

  # ── 集成平台位置规范 ────────────────────────────────────────
  - id: "V-010"
    name: "集成平台不得标注在连接线上"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      WSO2、Kafka、APIH、SFTP/MFT、Talend 等集成平台必须作为独立节点绘制在架构图中，
      不得以文字标注形式写在两个组件之间的连接线上。
    check_target: "integration_platform_nodes"
    validation_logic: "integration_platform_is_node_not_label"
    impact: "集成平台标注在线上无法表达其物理部署位置、所在网络 Zone 及认证关系"
    suggestion: "将集成平台提取为独立节点，标注其所在网络 Zone，并连接相关应用"

# ── 颜色语义参考（与 diagram-style.yaml 保持一致）─────────────
color_reference:
  internal_app:      "#4A90E2"    # 蓝色：内部应用/服务
  external_app:      "#888888"    # 灰色：外部系统/SaaS/第三方
  data_store:        "#F5A623"    # 橙色：数据库/对象存储/消息队列
  network_private:   "#D4EDDA"    # 浅绿底：私有网络Zone（App Zone/DB Zone/Intranet）
  network_dmz:       "#FFF3CD"    # 浅黄底：DMZ区
  network_public:    "#F8D7DA"    # 浅红底：公网区/Public Subnet
  integration_platform: "#E8D5F5" # 浅紫底：集成平台

# ============================================================
# Rules: interaction-rules.yaml
# 维度: Interaction_Integration (W-)
# 权重: 2.0 / 子项各 25%
# ============================================================

ruleset:
  name: "interaction-rules"
  version: "2.0"
  dimension: "Interaction_Integration"
  weight_contribution: 2.0
  subcategory_weight: 0.25      # 4个子项均分

subcategories:
  - id: "arrow_direction"       # W-A 箭头方向
  - id: "bidirectional_arrow"   # W-B 双向箭头（与 V-002 共享检测）
  - id: "protocol_label"        # W-C 协议标注
  - id: "integration_platform"  # W-D 集成平台规范

rules:

  # ── W-A: 箭头方向 ─────────────────────────────────────────
  - id: "W-001"
    subcategory: "arrow_direction"
    name: "箭头方向：箭尾=调用方，箭头=服务方"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      通信流箭头必须满足：
      - 箭尾端（无箭头一侧）是通信的发起方/调用方
      - 箭头端（有箭头一侧）是通信的服务提供方/被调用方
      特殊规则：
      - Kafka：所有生产者和消费者的箭头均指向 Kafka 节点（Producer → Kafka，Consumer → Kafka）
      - API网关（WSO2/APIH）：箭头方向取决于具体调用语义，允许双方互为调用方
    check_target: "all_communication_arrows"
    validation_logic: "arrow_direction_semantic_correct"
    scoring:
      deduction_unit: "per_wrong_arrow"
      formula: "wrong_arrow_count / total_arrow_count * subcategory_weight * dimension_weight"
    impact: "箭头方向错误导致调用链路无法追溯，认证机制标注位置混乱"
    suggestion: "逐条检查每条箭头，确认调用发起方在箭尾，被调用方在箭头端"

  # ── W-B: 双向箭头 ─────────────────────────────────────────
  - id: "W-002"
    subcategory: "bidirectional_arrow"
    name: "禁止使用双向箭头表示单一交互"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      双向箭头（<→ 或同线上两端均有箭头）表示单一交互关系时为违规。
      若 A 和 B 相互调用，须绘制两条独立单向箭头：
        A → B（标注 A 调用 B 的协议和认证）
        B → A（标注 B 调用 A 的协议和认证）
    check_target: "all_arrows"
    validation_logic: "is_bidirectional_arrow"
    scoring:
      deduction_unit: "per_bidirectional_arrow"
      formula: "bidirectional_count / total_arrow_count * subcategory_weight * dimension_weight"
    impact: "双向箭头无法区分调用语义，导致认证方向、协议标注歧义"
    suggestion: "将双向箭头拆分为两条带协议和认证标注的单向箭头"

  # ── W-C: 协议标注 ─────────────────────────────────────────
  - id: "W-003"
    subcategory: "protocol_label"
    name: "通信箭头必须标注通信协议"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      每条通信流箭头必须标注通信协议。支持的协议枚举：
      - HTTPS（Web/API 调用，需标注是否 TLS 加密）
      - Kafka（事件流，需同时标注 SASL/SCRAM 认证）
      - SFTP（文件传输，含 MFT 平台）
      - JDBC（数据库连接，Java）
      - ODBC（数据库连接，通用）
      - gRPC（高性能 RPC）
      - RFC（SAP 远程调用）
      - TCP（裸 TCP，需补充端口和用途说明）
      - 其他协议：需完整说明
    check_target: "all_communication_arrows"
    validation_logic: "arrow_has_protocol_label"
    scoring:
      deduction_unit: "per_missing_protocol"
      formula: "missing_protocol_count / total_arrow_count * subcategory_weight * dimension_weight"
    impact: "缺少协议标注无法评估通信安全性，也无法验证防火墙规则是否正确"
    suggestion: "在每条箭头旁标注协议名称，格式示例：HTTPS/TLS、Kafka/SASL-SCRAM"

  - id: "W-004"
    subcategory: "protocol_label"
    name: "通信箭头必须标注认证方式"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      每条通信流箭头（或其对应的通信关系说明）必须标注认证机制：
      | 认证方式              | 适用场景                        |
      |----------------------|-------------------------------|
      | OAuth2.0 Client Cred | 服务间 API 调用                 |
      | Basic Auth           | 简单 HTTP 场景                  |
      | mTLS（客户端证书）    | 高安全要求服务间通信              |
      | Azure SAS            | Azure 存储/服务                 |
      | SASL/SCRAM           | Kafka 生产者/消费者              |
      | 用户名/密码（PWD）    | 数据库连接                      |
      | Kerberos             | 内部企业系统                    |
      | API Key              | 第三方 API（需说明传输方式）     |
    check_target: "all_communication_arrows"
    validation_logic: "arrow_has_auth_label"
    scoring:
      deduction_unit: "per_missing_auth"
      formula: "missing_auth_count / total_arrow_count * subcategory_weight * dimension_weight"
    impact: "缺少认证标注无法判断系统是否有未受保护的通信路径"
    suggestion: "在协议标注旁补充认证方式，格式示例：HTTPS/TLS + OAuth2.0"

  - id: "W-005"
    subcategory: "protocol_label"
    name: "跨网络边界通信须标注加密方式"
    severity: "warning"
    issue_type: "must_fix"
    priority: "High"
    description: >
      跨越不同网络边界（DC 之间、DC 与公有云之间、公网暴露的服务）的通信箭头须标注加密方式：
      - TLS 1.2+ / TLS 1.3（HTTPS、gRPC 等）
      - SSL（遗留系统）
      - IPSec（VPN 隧道）
      内网内部同 Zone 组件间通信的加密标注为建议项，不强制。
    check_target: "cross_boundary_arrows"
    validation_logic: "cross_boundary_arrow_has_encryption"
    scoring:
      deduction_unit: "per_missing_encryption"
      formula: "missing_encryption_count / cross_boundary_total * subcategory_weight * dimension_weight"
    impact: "跨界通信未加密存在数据泄露风险，也可能违反 GDPR/等保等合规要求"
    suggestion: "标注跨界通信的加密方式，格式：HTTPS/TLS 1.3"

  # ── W-D: 集成平台规范 ──────────────────────────────────────
  - id: "W-006"
    subcategory: "integration_platform"
    name: "跨应用通信必须经过集成平台"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      不同应用/系统之间的通信必须经过集成平台，禁止直连：
      - WSO2 API Gateway：API 类集成
      - APIH（内部 API 网关）：内部 API 类集成
      - Kafka：事件/消息类集成
      - SFTP/MFT 平台：文件类集成
      - Talend：ETL/数据类集成
      
      例外（允许直连）：
      - 同一应用内部的模块间通信
      - 技术组件与其直属数据库之间的连接
      - 技术组件与 Key Vault 等基础设施服务之间的连接
    check_target: "cross_application_connections"
    validation_logic: "cross_app_has_integration_platform"
    scoring:
      deduction_unit: "per_direct_connection"
      formula: "direct_connection_count / cross_app_total * subcategory_weight * dimension_weight"
    impact: "跨应用直连绕过集成层，导致治理缺失、版本耦合、认证不一致"
    suggestion: "在直连的应用间插入适当的集成平台节点（WSO2/Kafka/APIH）"

  - id: "W-007"
    subcategory: "integration_platform"
    name: "集成平台必须标注所在网络位置"
    severity: "error"
    issue_type: "must_fix"
    priority: "Medium"
    description: >
      集成平台（WSO2、Kafka、APIH、SFTP/MFT、Talend）作为独立节点存在时，
      必须位于特定的网络 Zone 或 Subnet 内，不能悬空在图中。
    check_target: "integration_platform_nodes"
    validation_logic: "node_has_network_location"
    scoring:
      deduction_unit: "per_floating_platform"
      formula: "floating_count / platform_total * subcategory_weight * dimension_weight"
    impact: "集成平台网络位置不明确，无法判断其访问控制策略和安全域"
    suggestion: "将集成平台节点放置在对应的网络 Zone 或 Subnet 容器内"

# ============================================================
# Rules: platform-rules.yaml
# 维度: Cloud_Network_Completeness + Security_Compliance
# 来源: AWS Cloud Architecture Standard v1.0
#        Azure Cloud Architecture Standard v1.0
# 说明: 特定于 AWS / Azure 平台的必检规则，
#       对 accuracy-rules 和 security-rules 的扩展和细化
# ============================================================

ruleset:
  name: "platform-rules"
  version: "2.0"

# ══════════════════════════════════════════════════
# AWS 专属规则
# ══════════════════════════════════════════════════
aws_rules:

  - id: "E-AWS-001"
    dimension: "Cloud_Network_Completeness"
    name: "AWS 必须采用 Hub-Spoke 拓扑"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      AWS 云架构必须采用 Hub–Spoke 模型（强制）。
      Hub VPC 须包含：AWS Network Firewall/Security Appliance、
      Transit Gateway、Route 53 Resolver & Private Hosted Zones、
      Centralized SIEM（CloudWatch/CloudTrail/Security Hub/GuardDuty）。
      Bastion 首选 Privileged Access Workstation (PAW)，备选 AWS Systems Manager Session Manager 或 EC2 Bastion。
      Spoke VPC 只允许承载：应用工作负载、平台工作负载、API Gateway（WSO2）、
      Ingress 组件（ALB/NLB/WAF）。
    check_target: "aws_vpc_nodes"
    validation_logic: "aws_hub_spoke_topology_present"
    impact: "缺少 Hub VPC 导致安全检查点分散，防火墙和网关资源重复，治理困难"
    suggestion: "架构图中明确绘制 Hub VPC 和 Spoke VPC，Hub 包含上述共享服务"

  - id: "E-AWS-002"
    dimension: "Cloud_Network_Completeness"
    name: "AWS 每个 Region 必须有独立 Hub VPC"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      每个物理 AWS Region 需要一个独立的 Hub VPC。
      生产和非生产工作负载必须分别使用独立的 Hub VPC 和独立的 AWS 账户。
    check_target: "aws_region_hub_vpcs"
    validation_logic: "each_region_has_dedicated_hub"
    impact: "共用 Hub VPC 导致爆炸半径扩大，违反数据驻留合规要求"
    suggestion: "为每个 Region 分别绘制 Hub VPC，Prod 和 Non-Prod 分开标注账户"

  - id: "E-AWS-003"
    dimension: "Cloud_Network_Completeness"
    name: "AWS 工作负载不得部署在 Public Subnet"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      应用工作负载（ECS Task、Lambda、RDS 等）不得部署在 Public Subnet。
      所有托管 AWS 服务（RDS/S3/DynamoDB/EventBridge 等）必须仅通过 VPC Endpoints 访问。
    check_target: "aws_workload_subnet_placement"
    validation_logic: "no_workload_in_public_subnet"
    impact: "工作负载在 Public Subnet 直接暴露于互联网，属于高危架构缺陷"
    suggestion: "将应用/数据组件移至 Private Subnet；PaaS 服务通过 VPC Endpoint 访问"

  - id: "E-AWS-004"
    dimension: "Interaction_Integration"
    name: "AWS 外部 Web 流量必须经过 ALB + WAF"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      所有对外的 HTTP/S Web 应用流量必须经过 ALB + AWS WAF（必选）。
      流量路径：Internet → ALB(WAF) → Backend(PrivateLink) → Database/Internal Services。
      WAF 策略必须遵循 OWASP 核心规则集。
    check_target: "aws_ingress_web_path"
    validation_logic: "web_traffic_has_alb_waf"
    impact: "缺少 WAF 使 Web 应用直接暴露于 OWASP Top 10 攻击"
    suggestion: "在 Internet 与后端之间插入 ALB + WAF 节点，标注 OWASP 规则集"

  - id: "E-AWS-005"
    dimension: "Interaction_Integration"
    name: "AWS 外部 API 必须经过 WAF + WSO2 API Gateway"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      外部合作伙伴/客户 API 流量路径：
      Internet → ALB(WAF) → WSO2 API Gateway（Spoke VPC，Private 模式）→ Backend via PrivateLink。
      WSO2 API Gateway 必须部署在 Spoke VPC（不在 Hub VPC）。
      WSO2 负责：认证/授权、限流/配额、协议转换。
    check_target: "aws_api_ingress_path"
    validation_logic: "api_traffic_has_waf_and_api_gw"
    impact: "API 直接暴露缺少认证/限流/协议验证，存在滥用和注入风险"
    suggestion: "添加 WSO2 API Gateway 节点（标注在 Spoke VPC Private Subnet），前置 ALB+WAF"

  - id: "E-AWS-006"
    dimension: "Security_Compliance"
    name: "AWS 凭证必须使用 IAM Role + Secrets Manager/KMS"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      应用必须使用 IAM Roles 或 Service-linked Roles，禁止硬编码凭证。
      Secrets/Keys/Certificates 必须存储在 AWS Secrets Manager 或 KMS。
      KMS 密钥必须启用自动轮换（key rotation enabled）。
    check_target: "aws_credential_management"
    validation_logic: "aws_uses_iam_role_and_secrets_manager"
    impact: "硬编码凭证或明文存储密钥导致凭证泄露风险"
    suggestion: "在架构图中标注 AWS Secrets Manager 或 KMS 节点，并连接使用方"

  - id: "E-AWS-007"
    dimension: "Interaction_Integration"
    name: "AWS 所有托管服务必须通过 VPC Endpoint 访问"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      RDS、S3、DynamoDB、EventBridge 等所有托管 AWS 服务必须仅通过
      VPC Endpoints/PrivateLink 访问，禁止公网端点访问。
    check_target: "aws_managed_service_endpoints"
    validation_logic: "managed_services_use_vpc_endpoint"
    impact: "公网访问托管服务产生数据出口费用并增加攻击面"
    suggestion: "为每个托管服务标注 VPC Endpoint 连接，并标注 Private DNS Zone"

  - id: "E-AWS-008"
    dimension: "Security_Compliance"
    name: "AWS 运维访问必须通过 Privileged Access Workstation (PAW) 或 Systems Manager"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      运维访问路径：Privileged Access Workstation (PAW)（首选）或 AWS Systems Manager Session Manager（备选）。
      EC2 Bastion 仅作最后备选方案。禁止公网 SSH/RDP。
    check_target: "aws_operational_access"
    validation_logic: "no_direct_ssh_rdp_from_internet"
    impact: "公网 SSH/RDP 是常见入侵入口"
    suggestion: "标注 PAW 或 Systems Manager 作为运维入口，Security Group 仅允许 Bastion IP"

# ══════════════════════════════════════════════════
# Azure 专属规则
# ══════════════════════════════════════════════════
azure_rules:

  - id: "E-AZ-001"
    dimension: "Cloud_Network_Completeness"
    name: "Azure 必须采用 Hub-Spoke 拓扑"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      Azure 云架构必须采用 Hub–Spoke 模型（强制）。
      Hub VNET 须包含：Central Firewall（出口）、Bastion、
      Virtual Network Gateway、DNS & DNS Forwarding、Monitoring/SIEM Collector。
      APIM 位于 Spoke VNET（Internal VNET Mode），不在 Hub。
    check_target: "azure_vnet_nodes"
    validation_logic: "azure_hub_spoke_topology_present"
    impact: "缺少 Hub VNET 导致防火墙/网关资源重复，治理困难"
    suggestion: "明确绘制 Hub VNET（含 Firewall/Bastion/Gateway）和 Spoke VNET"

  - id: "E-AZ-002"
    dimension: "Cloud_Network_Completeness"
    name: "Azure 工作负载不得部署在 Public Subnet"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      应用工作负载不得部署在 Public Subnet。
      所有 PaaS 服务必须仅使用 Private Endpoint，公网访问必须禁用。
    check_target: "azure_workload_subnet_placement"
    validation_logic: "no_azure_workload_in_public_subnet"
    impact: "同 E-AWS-003"
    suggestion: "将应用/数据移至 Private Subnet；PaaS 服务通过 Private Endpoint 访问，禁用公网访问"

  - id: "E-AZ-003"
    dimension: "Interaction_Integration"
    name: "Azure 外部 Web 流量必须经过 Application Gateway（WAF v2）"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      所有 HTTP/S Web 应用流量必须经过 Azure Application Gateway（WAF v2）。
      流量路径：Internet → App Gateway(WAF) → Backend(Private IP/PrivateLink) → DB & Internal。
      WAF 策略必须遵循 OWASP 核心规则集。
      Azure Firewall 不是强制要求，须基于风险/成本/运营权衡决定是否部署。
    check_target: "azure_ingress_web_path"
    validation_logic: "web_traffic_has_app_gateway_waf"
    impact: "缺少 WAF 使 Web 应用直接面临 OWASP Top 10 攻击"
    suggestion: "在 Internet 与后端之间插入 Application Gateway WAF v2"

  - id: "E-AZ-004"
    dimension: "Interaction_Integration"
    name: "Azure 外部 API 必须经过 WAF + APIM（Spoke Internal 模式）"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      外部 API 流量路径：
      Internet → App Gateway(WAF) → APIM（Spoke VNET Internal 模式）→ Backend via Private Endpoint。
      APIM 必须部署在 Spoke VNET（Internal VNET Mode），不在 Hub。
      APIM 负责：认证/授权、限流/配额、协议/转换策略。
    check_target: "azure_api_ingress_path"
    validation_logic: "api_traffic_has_waf_and_apim"
    impact: "同 E-AWS-005"
    suggestion: "添加 APIM 节点（标注 Spoke VNET Internal 模式），前置 App Gateway WAF"

  - id: "E-AZ-005"
    dimension: "Security_Compliance"
    name: "Azure 必须使用 Managed Identity + Key Vault"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      应用必须使用 Managed Identity（禁止硬编码凭证）。
      Secrets/CMK keys/Certificates 必须存储在 Azure Key Vault（必选）。
      Key Vault 必须启用 soft-delete 和 purge-protection。
    check_target: "azure_credential_management"
    validation_logic: "azure_uses_managed_identity_and_key_vault"
    impact: "硬编码凭证或明文存储密钥导致凭证泄露风险"
    suggestion: "在架构图中标注 Key Vault 节点，并连接使用方；标注 Managed Identity 使用"

  - id: "E-AZ-006"
    dimension: "Security_Compliance"
    name: "Azure 运维访问必须通过 Azure Bastion（Standard）"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      Azure Bastion（Standard）是唯一跳板机，禁止公网 SSH/RDP。
      JIT（Just-In-Time）访问通过 Microsoft Defender for Cloud 启用。
      托管 VM 的 Subnet NSG 仅允许来自 Bastion IP 范围的 SSH/RDP。
    check_target: "azure_operational_access"
    validation_logic: "azure_uses_bastion_not_direct_rdp"
    impact: "公网 SSH/RDP 是常见入侵入口"
    suggestion: "标注 Azure Bastion 节点在 Hub VNET，NSG 规则仅允许 Bastion IP"

  - id: "E-AZ-007"
    dimension: "Cloud_Network_Completeness"
    name: "Azure 混合连接必须使用 ExpressRoute，Gateway 在 Hub VNET"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      ExpressRoute 是首选混合连接方式（Virtual Network Gateway 必须在 Hub VNET）。
      Spoke 通过 VNET Peering 可达，但 UDR 须确保混合流量经过防火墙（除非正式豁免）。
    check_target: "azure_hybrid_connectivity"
    validation_logic: "azure_gateway_in_hub_vnet"
    impact: "Gateway 部署在 Spoke 导致每个 Spoke 重复部署网关，成本高且治理分散"
    suggestion: "将 Virtual Network Gateway 移至 Hub VNET，Spoke 通过 VNET Peering 访问"

  - id: "E-AZ-008"
    dimension: "Cloud_Network_Completeness"
    name: "Azure 所有 PaaS 服务必须通过 Private Endpoint 访问"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      所有 Azure PaaS 组件必须使用 Private Endpoint（禁用公网访问）。
      Private DNS Zone 必须集中管理；DNS 解析通过 DNS Forwarder + Firewall DNS Proxy。
    check_target: "azure_paas_endpoints"
    validation_logic: "azure_paas_uses_private_endpoint"
    impact: "PaaS 公网访问产生攻击面和数据出口风险"
    suggestion: "为每个 PaaS 服务标注 Private Endpoint，并连接到 Private DNS Zone"

# ══════════════════════════════════════════════════
# 私有云专属规则（补充 accuracy-rules）
# ══════════════════════════════════════════════════
private_cloud_rules:

  - id: "E-PC-001"
    dimension: "Security_Compliance"
    name: "私有云所有入站必须经过 F5 网关"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      来自 Internet 或合作伙伴网络的所有入站流量必须经过 Company F5 入口网关栈。
      F5 负责：TLS 终止/透传、Layer-7 访问控制、流量路由和负载均衡、威胁检测和协议验证。
      任何系统不得绕过 F5 直接暴露到公共网络。
    check_target: "private_dc_ingress_path"
    validation_logic: "f5_gateway_on_ingress_path"
    impact: "绕过 F5 意味着缺少 TLS 终止、L7 访问控制和威胁检测"
    suggestion: "在 Internet 与 DMZ 之间插入 F5 节点，标注其功能（WAF/TLS/LB）"

  - id: "E-PC-002"
    dimension: "Security_Compliance"
    name: "私有云应用间通信必须经过集成平台"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      所有应用间通信必须经过集成平台（WSO2/APIH/Kafka/SFTP-MFT/Talend），
      无论数据中心网络布局如何。
      禁止：应用A直接访问应用B的数据库；应用A绕过集成平台调用应用B的服务层；
      未经正式批准的跨Zone资源访问。
    check_target: "private_dc_app_to_app_connections"
    validation_logic: "cross_app_uses_integration_platform"
    impact: "直接跨应用连接导致服务治理缺失、数据耦合和审计盲区"
    suggestion: "在跨应用连接之间插入 WSO2/Kafka/APIH 集成平台节点"

  - id: "E-PC-003"
    dimension: "Security_Compliance"
    name: "私有云用户认证必须使用 ADFS（内部）或 EnterpriseID（外部）"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      内部员工访问：必须通过 ADFS 认证。
      外部用户访问：必须通过 EnterpriseID 认证。
      授权必须通过 AuthZ Platform（Unified Permission Management Platform）执行。
    check_target: "private_dc_user_auth"
    validation_logic: "user_auth_uses_adfs_or_companyid"
    impact: "缺少统一认证导致身份管理分散，无法实现 SSO 和账号生命周期管理"
    suggestion: "在用户访问入口处添加 ADFS（内部）或 EnterpriseID（外部）节点，连接 AuthZ Platform"

  - id: "E-PC-004"
    dimension: "Security_Compliance"
    name: "私有云运维访问必须通过 PAW 堡垒机"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      运维访问路径：内部办公网络 → PAW（堡垒机）→ 私有云内网 → 目标系统。
      禁止：从公网直接进行运维访问；禁止从工作站直接访问数据中心。
      MFA 对所有管理操作为必须；JIT 审批适用于特权操作；所有会话须记录和可审计。
    check_target: "private_dc_operational_access"
    validation_logic: "ops_access_through_paw"
    impact: "直接运维访问绕过审计和身份验证"
    suggestion: "标注 PAW 节点，从办公网络通过 PAW 连接目标系统的路径"

  - id: "E-PC-005"
    dimension: "Cloud_Network_Completeness"
    name: "私有云 DC 间连接必须使用 MPLS 专线"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      私有云 DC 间连接必须使用 MPLS 或等效专线（不得使用公网互联网）。
      私有云到 Azure 使用 ExpressRoute；到 AWS 使用 Direct Connect。
      所有混合流量必须经过已批准的网关，遵循网络分段和安全检查。
    check_target: "private_dc_interconnect"
    validation_logic: "dc_interconnect_uses_mpls_or_expressroute"
    impact: "使用公网互连私有 DC 数据面临泄露风险且不满足合规要求"
    suggestion: "在 DC 间连接标注 MPLS 图标和加密方式（IPSec）"

# ============================================================
# Rules: security-rules.yaml
# 维度: Security_Compliance (S-)
# 权重: 2.0 / 子项各 ~33%
# ============================================================

ruleset:
  name: "security-rules"
  version: "2.0"
  dimension: "Security_Compliance"
  weight_contribution: 2.0
  subcategory_weight: 0.333     # 3个子项均分

subcategories:
  - id: "system_auth"           # S-A 系统间认证
  - id: "user_auth"             # S-B 用户认证
  - id: "credential_protection" # S-C 凭证保护

rules:

  # ── S-A: 系统间认证 ────────────────────────────────────────
  - id: "S-001"
    subcategory: "system_auth"
    name: "每对直连技术组件之间必须标注认证机制"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      架构图中有通信连接的每一对技术组件之间，必须在连接线上明确标注认证机制。
      
      支持的认证方式及典型适用场景：
      ┌─────────────────────────┬──────────────────────────────────────┐
      │ 认证方式                 │ 典型场景                              │
      ├─────────────────────────┼──────────────────────────────────────┤
      │ OAuth2.0 Client Cred    │ 服务间 API 调用（首选）               │
      │ Basic Auth              │ 简单 HTTP 场景（需配合 TLS）           │
      │ mTLS（客户端证书）       │ 高安全服务间通信、Service Mesh        │
      │ Azure SAS               │ Azure Blob Storage / Event Hub 等     │
      │ SASL/SCRAM              │ Kafka 生产者/消费者                   │
      │ 用户名/密码（PWD）       │ 数据库连接（JDBC/ODBC）               │
      │ Kerberos                │ 内部企业系统、Active Directory 集成    │
      │ API Key                 │ 第三方 API（必须说明 Key 传递方式）    │
      └─────────────────────────┴──────────────────────────────────────┘
    check_target: "all_component_connections"
    validation_logic: "connection_has_auth_mechanism"
    scoring:
      deduction_unit: "per_missing_auth"
      formula: "missing_auth_count / total_connections * subcategory_weight * dimension_weight"
    impact: "未标注认证机制的通信路径可能是未受保护的攻击面"
    suggestion: "在每条连接线旁补充认证方式标注；若使用 OAuth2.0，建议同时注明 Grant Type"

  - id: "S-002"
    subcategory: "system_auth"
    name: "网络安全边界规则：外部流量必须经过 DMZ"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      来自公网（Internet）的流量不允许直接进入私有网络区域（App Zone / DB Zone / Private Subnet）。
      必须经过 DMZ 层的安全组件中转，例如：
      - WAF（Web Application Firewall）
      - API Gateway（WSO2、APIH、AWS API GW、Azure APIM）
      - Reverse Proxy / Load Balancer
      
      禁止的直连场景：
      - Internet → App Zone（直接）
      - Internet → DB Zone（直接）
      - Internet → Private Subnet（直接）
    check_target: "external_to_private_paths"
    validation_logic: "no_direct_internet_to_private"
    scoring:
      deduction_unit: "per_violation"
      formula: "violation_count / external_connection_total * subcategory_weight * dimension_weight"
    impact: "绕过 DMZ 的直连路径使内网完全暴露于互联网，属于高危架构缺陷"
    suggestion: "在外部流量和私有网络之间插入 DMZ 层组件（WAF/API Gateway）"

  - id: "S-003"
    subcategory: "system_auth"
    name: "数据存储禁止部署在公网区域或 DMZ"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      所有数据存储组件（关系型数据库、NoSQL 数据库、对象存储、消息队列、缓存）
      不允许部署在：
      - 公网区域（Public Subnet / Internet Zone）
      - DMZ 区域
      
      数据存储必须部署在：
      - DB Zone（私有云）
      - Private Subnet（公有云）
      - 受私有端点（Private Endpoint）保护的 PaaS 存储服务
    check_target: "data_store_network_location"
    validation_logic: "data_store_not_in_public_or_dmz"
    scoring:
      deduction_unit: "per_violation"
      formula: "violation_count / data_store_total * subcategory_weight * dimension_weight"
    impact: "数据存储暴露在公网区域是极高危风险，可能导致数据泄露和合规违规"
    suggestion: "将数据存储移至 Private Subnet / DB Zone，并通过私有端点访问"

  # ── S-B: 用户认证 ──────────────────────────────────────────
  - id: "S-004"
    subcategory: "user_auth"
    name: "内部用户访问须通过 ADFS 认证"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      企业内部员工访问系统时，前端或后端必须连接到 ADFS（Active Directory Federation Services）
      进行身份认证。ADFS 节点必须在架构图中明确标注，并通过箭头连接到系统访问入口。
      
      必须在用户/前端 → ADFS 的连线上标注认证协议：
      - SAML 2.0（最常见）
      - CAS（Central Authentication Service）
      - OAuth2 Authorization Code Grant
    check_target: "user_facing_entry_points"
    validation_logic: "internal_user_has_adfs_connection"
    scoring:
      deduction_unit: "per_missing_adfs"
      formula: "missing_adfs_count / internal_entry_total * subcategory_weight * dimension_weight"
    impact: "内部用户直连系统无企业级统一认证，无法实现单点登录和账号生命周期管理"
    suggestion: "在内部用户入口处添加 ADFS 节点，并标注认证协议（SAML/CAS/OAuth2）"

  - id: "S-005"
    subcategory: "user_auth"
    name: "外部用户访问须通过 EnterpriseID 认证"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      企业外部用户（合作伙伴、客户、供应商）访问系统时，必须通过 EnterpriseID 进行身份认证。
      EnterpriseID 节点须在架构图中标注，并通过箭头连接到外部用户访问入口。
      
      认证协议标注要求同 S-004。
    check_target: "external_user_entry_points"
    validation_logic: "external_user_has_companyid_connection"
    scoring:
      deduction_unit: "per_missing_companyid"
      formula: "missing_companyid_count / external_entry_total * subcategory_weight * dimension_weight"
    impact: "外部用户缺少统一认证，无法实现外部身份管理和访问审计"
    suggestion: "在外部用户访问入口处添加 EnterpriseID 节点，并标注认证协议"

  - id: "S-006"
    subcategory: "user_auth"
    name: "须标注用户访问控制组件"
    severity: "warning"
    issue_type: "must_fix"
    priority: "Medium"
    description: >
      架构图中须明确标注用户授权/访问控制机制，二选一：
      1. 使用统一访问控制服务（UCA）：标注 UCA 节点及其与系统的连接
      2. 使用应用自建访问控制组件：在技术组件信息中标注（如"内置 RBAC 模块"）
    check_target: "authorization_components"
    validation_logic: "authorization_component_exists"
    scoring:
      deduction_unit: "per_missing_authz"
      formula: "missing_authz_count / system_total * subcategory_weight * dimension_weight"
    impact: "缺少授权机制标注无法验证最小权限原则，存在越权访问风险"
    suggestion: "标注使用 UCA 服务或描述应用内置的授权组件（RBAC/ABAC）"

  # ── S-C: 凭证保护 ──────────────────────────────────────────
  - id: "S-007"
    subcategory: "credential_protection"
    name: "必须声明凭证与密钥保护方案"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      架构图或其附注中必须明确声明凭证（API Key、密码、证书）的保护方案：
      
      ┌─────────────────────┬──────────────────────────────┐
      │ 部署环境             │ 推荐/要求方案                 │
      ├─────────────────────┼──────────────────────────────┤
      │ Azure               │ Azure Key Vault              │
      │ AWS                 │ AWS Secrets Manager          │
      │ Kubernetes / 私有云  │ Kubernetes Secrets           │
      │ 混合/其他           │ 须明确说明具体方案             │
      └─────────────────────┴──────────────────────────────┘
      
      密钥轮换策略须以注释（Notes）形式在架构图中标注，或在附带文档中说明。
    check_target: "credential_management_declaration"
    validation_logic: "key_vault_or_equivalent_declared"
    scoring:
      deduction_unit: "binary"    # 有/无，无则全扣
      formula: "0 if declared else subcategory_weight * dimension_weight"
    impact: "未使用密钥管理服务意味着凭证可能以明文存储在代码或配置文件中"
    suggestion: "在架构图中添加 Azure Key Vault / AWS Secrets Manager / K8s Secrets 节点，并用箭头连接使用方"

  - id: "S-008"
    subcategory: "credential_protection"
    name: "跨境数据流须标注数据分类与合规依据"
    severity: "error"
    issue_type: "must_fix"
    priority: "High"
    description: >
      当数据流跨越国家/司法区边界，且涉及以下数据类型时，
      必须在连接线或注释中标注数据分类和合规依据：
      - PII（个人身份信息）
      - 金融数据
      - 医疗数据
      - 绝密级/受限级数据（按组织信息分级）
      
      合规依据示例：GDPR、中国数据安全法、PDPA（泰国）、CCPA（美国加州）
    check_target: "cross_border_data_flows"
    validation_logic: "cross_border_pii_has_compliance_label"
    scoring:
      deduction_unit: "per_violation"
      formula: "violation_count / cross_border_total * subcategory_weight * dimension_weight"
    impact: "PII 跨境传输未标注合规依据可能导致违反数据主权法规，面临重大法律风险"
    suggestion: "在跨境数据流箭头上标注：数据类型（PII/Financial）+ 合规依据（GDPR等）"

  - id: "S-009"
    subcategory: "credential_protection"
    name: "高密级数据存储须标注加密方式"
    severity: "warning"
    issue_type: "suggestion"
    priority: "Medium"
    description: >
      绝密级或受限级数据的存储组件须在架构图中标注加密方式。
      标注方法（任选一）：
      1. 在存储组件图标上叠加加密图标（锁形）
      2. 在组件名称旁标注文字，如"AES-256"或"TDE"
      
      常见加密方式：
      - AES-256（对称加密，最常见）
      - TDE（Transparent Data Encryption，SQL Server/Oracle 等）
      - 列级加密（针对特定敏感字段）
    check_target: "sensitive_data_stores"
    validation_logic: "sensitive_store_has_encryption_label"
    scoring: null    # suggestion 类型，不扣分
    impact: "高密级数据未加密存储违反信息安全基线要求"
    suggestion: "在敏感数据存储组件上添加加密标注（AES-256 / TDE），并在 Key Vault 中管理加密密钥"