English abstract: This document describes the security architecture of Tyk Console, designed to comply with GB/T 22239-2019 Level-3 (China's Cybersecurity Multi-Level Protection Scheme, also known as "等保 2.0 三级"). It covers identity authentication, access control (three-role separation / 三员分立), security auditing with HMAC integrity, mandatory access control (MAC) with 4 security levels, and healthcare data protection per GB/T 39725-2020. The implementation leverages PostgreSQL Row-Level Security (RLS), column-level views, pgjwt for JWT authentication, pgcrypto for bcrypt password hashing, and an append-only audit log table.

本文档描述 Tyk Console 的安全架构设计，符合 GB/T 22239-2019 三级标准（等保 2.0 三级）。

Project: Tyk Console (tyk-console) Standard: GB/T 22239-2019 — Information Security Technology — Baseline for Classified Protection of Cybersecurity (Level 3) Industry Supplement: GB/T 39725-2020 — Health and Medical Data Security Guidelines Version: v2.0 / 2026-07-07

┌─────────────────────────────────────────────────────┐
│                    浏览器 (React SPA)                │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐             │
│  │ 系统管理员 │ │ 安全管理 │ │ 审计管理 │  ← 三员分立  │
│  │ Dashboard │ │ 安全策略 │ │ 审计日志 │             │
│  └──────────┘ └──────────┘ └──────────┘             │
│  ┌──────────┐ ┌──────────┐                          │
│  │ 业务用户  │ │ 只读用户  │  ← 业务角色              │
│  │ API CRUD │ │ 仪表板    │                          │
│  └──────────┘ └──────────┘                          │
├─────────────────────────────────────────────────────┤
│              PostgREST (JWT 验证 + 路由)             │
│         PGRST_JWT_SECRET + db_pre_request            │
├─────────────────────────────────────────────────────┤
│              PostgreSQL 17 (数据 + 权限)             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐             │
│  │ RLS 策略 │ │ 列级视图 │ │ 审计日志 │             │
│  │ (行级)   │ │ (列级)   │ │ (HMAC)   │             │
│  └──────────┘ └──────────┘ └──────────┘             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐             │
│  │ pgjwt    │ │ pgcrypto │ │ 速率限制 │             │
│  │ JWT 签发 │ │ 密码哈希 │ │ 滑动窗口 │             │
│  └──────────┘ └──────────┘ └──────────┘             │
└─────────────────────────────────────────────────────┘

网络层访问控制由 Tyk Gateway + 部署环境防火墙共同实现，不在本应用代码范围内。

这是权限系统设计的核心依据，逐条落实：

落实: 每个用户有独立账户（ichse.users），登录后分配角色和权限。

ichse.users 表结构:
  id (UUID PK)         — 唯一标识
  email (UNIQUE)       — 登录标识
  phone (UNIQUE)       — 登录标识（中国用户习惯）
  display_name         — 显示名称
  role                 — 业务角色（5 种）
  password_hash        — bcrypt 哈希
  status               — 账户状态（active/disabled/locked）
  secret_level         — 安全标记（等保 8.1.4.2g）
  last_login_at        — 最近登录时间
  password_changed_at  — 最近改密时间
  failed_attempts      — 登录失败计数
  locked_until         — 锁定到期时间

落实:

• 生产环境不存在 dev_admin 角色（仅在开发库存在）
• PostgreSQL 默认 postgres 用户不使用（Alpine 镜像以 ichse 替代）
• 种子账号创建后须立即修改密码

落实:

• status 字段支持 disabled（禁用）和 locked（锁定）
• 系统管理员可禁用/删除账户
• 连续 5 次登录失败自动锁定 30 分钟
• 每用户独立账户，无共享账号设计

落实: 5 角色模型，严格权限分离。

三员隔离原则:

• 系统管理员：只能看到系统层面数据（服务器状态、用户账号状态），绝对不能看到业务数据
• 安全管理员：只能看到安全策略和权限配置，绝对不能看到业务数据
• 审计管理员：只能看到审计日志，绝对不能看到原始业务数据

技术实现:

• PostgreSQL RLS（行级安全）策略：三员角色对 api_definitions、api_keys、api_definition_log 表无任何访问权限
• 列级视图：users_sysadmin_view（屏蔽密码哈希和角色）、users_secadmin_view（屏蔽密码哈希和登录信息）、users_biz_view（只显示业务用户）

-- RLS 示例：业务数据仅 business_user 和 viewer 可读
CREATE POLICY ad_select ON ichse.api_definitions
FOR SELECT TO authenticated
USING (ichse.is_role('business_user') OR ichse.is_role('viewer'));

-- 列级视图示例：sysadmin 不可见 password_hash 和 role
CREATE VIEW ichse.users_sysadmin_view AS
SELECT id, email, phone, display_name, is_system,
       status, last_login_at, failed_attempts, locked_until,
       password_changed_at, created_at
FROM ichse.users;

落实: 安全管理员（security_admin）是唯一的授权主体，负责：

• 给用户分配角色（将 user 提升为 business_user 等）
• 设置用户安全标记（secret_level）
• 配置安全策略

三员互相不能修改对方的权限：

• 系统管理员能创建/禁用账号，但不能分配角色
• 安全管理员能分配角色，但不能创建账号
• 审计管理员只能查看日志，不能修改任何配置

落实:

• 主体粒度：用户级——每个用户的 JWT 包含 sub（用户 UUID）、biz_role、secret_level
• 客体粒度：数据库表级——PostgreSQL RLS 策略覆盖全部 5 张业务表
• 列级控制：通过视图实现不同角色可见不同列

落实: 强制访问控制（MAC），四级安全标记。

用户标记: ichse.users.secret_level 数据标记: ichse.api_definitions.secret_level、ichse.api_keys.secret_level

MAC 规则: 用户的安全等级必须 ≥ 数据的安全等级才能访问。

-- 安全等级比较函数
CREATE FUNCTION ichse.secret_level_compare(user_level TEXT, data_level TEXT)
RETURNS INTEGER LANGUAGE SQL IMMUTABLE AS $$
    SELECT CASE user_level
        WHEN '机密' THEN CASE data_level
            WHEN '机密' THEN 1 WHEN '敏感' THEN 1 WHEN '内部' THEN 1 WHEN '公开' THEN 1 END
        WHEN '敏感' THEN CASE data_level
            WHEN '机密' THEN -1 WHEN '敏感' THEN 1 WHEN '内部' THEN 1 WHEN '公开' THEN 1 END
        ...
    END;
$$;

落实: 独立的 ichse.audit_log 表，记录全部用户操作。

落实: audit_log 表完整字段：

event_time      TIMESTAMPTZ    — 日期和时间
user_id         UUID           — 用户
user_email      TEXT           — 用户邮箱（冗余，方便查询）
user_role       TEXT           — 操作时的角色快照
event_type      TEXT           — 事件类型
event_success   BOOLEAN        — 是否成功
target_type     TEXT           — 操作对象类型（user/api_definition/api_key/config）
target_id       TEXT           — 操作对象标识
target_detail   JSONB          — 操作对象描述
changes         JSONB          — 变更内容（before/after diff）
error_message   TEXT           — 失败原因
client_ip       TEXT           — 客户端 IP
user_agent      TEXT           — User-Agent

落实:

• append-only: RLS 策略禁止任何人 UPDATE/DELETE audit_log
• HMAC 防篡改: 每条记录写入时自动计算 HMAC-SHA256 签名
• 写入隔离: 仅通过 write_audit_log() SECURITY DEFINER 函数写入，绕过 RLS
• 备份: PostgreSQL 定期备份策略覆盖 audit_log 表
• 留存 ≥ 6 年: 符合医疗行业要求（《医疗卫生机构网络安全管理办法》）

-- HMAC 防篡改
v_hmac := encode(
    hmac(v_row_data::BYTEA, current_setting('app.jwt_secret')::BYTEA, 'sha256'),
    'hex'
);

-- RLS：任何人不可修改/删除审计日志
-- 仅 audit_admin 可 SELECT
CREATE POLICY al_select ON ichse.audit_log
FOR SELECT TO authenticated
USING (ichse.is_role('audit_admin'));

落实:

• write_audit_log() 函数使用 SECURITY DEFINER，以函数 owner 身份运行
• 审计日志写入在业务操作同一事务中完成，保证一致性
• 审计管理员仅可查看日志（SELECT），不可修改/删除
• 审计日志表受 PostgreSQL 事务保护，无法被绕过

系统管理员可见页面:

• 系统仪表板（CPU/内存/Redis/Gateway 状态）
• 网关管理（Docker 容器生命周期）
• 用户管理（创建/禁用/删除账号）
• 系统配置

系统管理员不可见:

• 业务 API 定义和密钥
• 业务变更日志
• 审计日志
• 安全策略配置

审计管理员可见: 审计日志（全部事件类型），支持查询、筛选、导出 审计管理员不可见: 业务数据原始内容、系统配置、安全策略、任何管理员密码

脱敏要求: 审计日志中涉及业务数据的部分进行脱敏处理（日志中不显示患者姓名等敏感字段，仅显示记录 ID）

安全管理员可见: 用户角色列表、权限配置、安全标记、安全告警 安全管理员不可见: 业务数据、系统底层配置、审计日志

1. 用户提交 手机号/邮箱 + 密码
2. PostgREST POST /rpc/login → PostgreSQL login() 函数
3. login() 校验 bcrypt 密码哈希（pgcrypto）
4. 校验通过 → pgjwt.sign() 签发 JWT
5. JWT 包含:
   - role: "authenticated" (PostgREST PG 角色)
   - sub: 用户 UUID
   - biz_role: 业务角色
   - email/phone/display_name
   - secret_level: 安全标记
   - iat/exp: 签发/过期时间
6. 前端存储 JWT，每次请求带 Authorization: Bearer <jwt>
7. PostgREST 验证 JWT 签名 → SET LOCAL ROLE authenticated
8. db_pre_request() 运行：解析 JWT claims → 检查用户状态 → 设置会话变量 → 速率限制
9. RLS 策略根据 app.role / app.user_id / app.secret_level 控制数据访问

• 算法: bcrypt (Blowfish)，通过 pgcrypto.crypt(password, gen_salt('bf'))
• 锁定策略: 连续 5 次失败 → 自动锁定 30 分钟
• 强制定期改密: password_changed_at 字段支持（Phase 2 实现检查逻辑）

• JWT 有效期: 8 小时
• 无 refresh token（过期后重新登录）
• Token 存储在浏览器 localStorage
• 登出时清除 localStorage

# 测试各角色登录
TOKEN=$(docker exec ichse-postgres psql -U ichse -d ichse -t -A \
  -c "SELECT ichse.login('dev_biz@ichse.local', 'Test1234!');" \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['token'])")

# 测试认证
printf -v header "Bearer %s" "$TOKEN"
curl -s -o /dev/null -w "HTTP %{http_code}" -H "$header" \
  http://localhost:3001/api_definitions

生产部署前必须删除所有 dev 账号，修改 JWT secret。