整体架构
QXJ（MCS 信息安全传输控制软件，项目编号 IIE-MCS-ISTCS）是面向气象卫星地面系统的 「终端 + 认证平台 + 传输加密 + 业务接入」安全方案，由中国科学院信息工程研究所 第二研究室研制，部署于国家卫星气象中心。系统需要支撑三类完全不同的业务， 理解这三类业务是理解整个架构的前提。
业务场景
场景一：移动设备观测需求信息传输
观测人员使用鸿蒙平板（安全浏览器 APP）经互联网访问 DMZ 区的 MCS 系统。 终端完全不可信、网络完全开放，因此要求：
- 设备与服务器之间双向身份认证（设备注册 + SM2 密钥协商）；
- 用户名口令 + 短信验证码的多因子用户认证；
- 业务请求与回复全程 SM4-GCM 加密完保；
- 基于时间、区域、设备三维条件的细粒度访问控制。
这是整个系统最核心、组件最多的场景，本文档 90% 的篇幅围绕它展开。
场景二：主站与灾备站之间的传输
北京主站与乌兰察布灾备站之间需要同步任务时间表、调度令、公共配置参数。 两端均为部署了传输加密子系统的固定站点，通信链路同样要求机密性与完整性保护， 由服务端侧的传输加密能力（PCIE 密码卡支撑）保证。
场景三：数据外部流转的溯源
气象数据需要向外部单位流转，必须能够证明"数据从哪来、有没有被改过"：
- L0 数据溯源及篡改检测接口库：为 L0 数据封装唯一来源标识，接收方可解封装 并验证来源真实性、检测篡改；
- 图像数据版权保护接口库：面向外发图片嵌入高鲁棒不可见数字水印， 泄露后可追溯责任（PSNR 38.10 dB / SSIM 0.9815）。
两个接口库以库（SDK）形式交付，部署在气象数据业务系统 / 图片存储服务器上， 被业务系统直接调用，没有独立的服务进程与界面。
逻辑架构总览
要点：
- 认证后端与业务后端分离：认证后端签发 NSP-SM token 并管理会话密钥； 业务后端不接触用户口令，只通过 qxj-backend-sdk 本地验签 token、从 Redis 取 会话密钥——业务后台即使脱离鉴权后端也能独立完成验签；
- 传输加密子系统面向主站-灾备站场景，依赖 PCIE 密码卡，与面向互联网的 认证平台共用国密算法体系但部署形态不同；
- L0 / 水印是接口库而非服务：无独立进程，链接入业务进程内被调用；
- 应用商店是独立静态站点，与认证平台无运行时依赖；
- 当前工程现状：没有 Celery、没有 Casbin、没有独立网关微服务，无 CI 流水线。
分层说明
终端层：鸿蒙安全浏览器
一多工程结构：AppScope + common HAR + 5 个 feature HAR （browser / device / helloworld / showcase / qxj_sdk，共 6 个 HAR）， 3 个产品 entry（tablet / phone 功能完整，pc 为骨架；无 tv / wearable 产品）。 终端侧的密钥对、token 等关键资产通过 Asset Store Kit（关键资产存储）保存， Native 国密能力经 AKI 以 C 动态库提供。详见 鸿蒙架构与鸿蒙仓库。
Web 层
- 管理前端：Vue 3 + Element Plus + ECharts，PC 与移动双 UI，消费 qxj-frontend-sdk，承担用户 / 角色 / 设备 / 策略 / 日志全部管理功能；
- 业务前端：接入方页面通过 JSBridge 从安全区获得凭据与加密能力， 业务页面自身不接触密钥、不在 localStorage 存 token；
- 应用商店：Vue 3 + TS 数据驱动的静态站，按设备型号分发 HAP。
服务端层：认证后端
apps/ 下 14 个业务 app，按职能分组：
| 职能 | App |
|---|---|
| 认证与会话 | auth（NSP-SM 令牌、sm2_jwt）、sms（短信验证码）、captcha（验证码） |
| 用户与角色 | users、roles、user_roles |
| 设备 | devices、device_public_keys |
| 策略 | geofences、role_geofences、time_rules、role_time_rules |
| 审计 | security_logs |
| 密钥协商 | keymgr（SM2 握手服务端、服务器密钥对、二维码、握手 native 库） |
安全接口库层
| 接口库 | 部署位置 | 能力 |
|---|---|---|
| L0 数据溯源及篡改检测接口库 | 气象数据业务系统服务器 | L0 数据标识封装 / 解封装、来源验证、篡改检测 |
| 图像数据版权保护接口库 | 图片存储服务器 | BCH + DCT 高鲁棒水印嵌入 / 提取 / 攻击检测 |
水印算法的核心技术（BCH 纠错编码 + DCT 中频系数嵌入 + 聚类选择嵌入位置）与 16 组攻击鲁棒性实验数据，见 技术总结 · 关键技术。
数据与缓存层
生产设计数据库为 MySQL，开发默认 SQLite（DB_ENGINE=mysql 可切换）； Redis 统一由 django-redis 访问：JSONSerializer（禁用 pickle）、 KEY_PREFIX=qxj、VERSION=1。
| 数据 | Key（含前缀 / 版本的实际存储形态） | TTL |
|---|---|---|
| 设备会话密钥 | qxj:1:sm2:device_session_key:{device_id} | 7 天 |
| 握手中途会话 | qxj:1:sm2:session:{uuid} | 10 分钟 |
| 待 ACK 登记 | qxj:1:sm2:pending_ack:{...} | 10 分钟 |
| 登录短信验证码 | qxj:1:sms:login:{username} | 5 分钟 |
| jti 黑名单 / sid 撤销 | 由 auth 模块管理 | token 有效期内 |
完整数据库表结构（NSP_WB_UM_* / NSP_WB_DM_* / NSP_WB_SLM_*）与 Redis 模型， 见 技术总结 · 数据库设计。
SDK 层
| SDK | 消费方 | 形态 |
|---|---|---|
| @nsp/qxj-sdk（qxj_harmony_next_sdk） | 鸿蒙浏览器（file: HAR，AKI + C 库） | 握手 / 国密原语 / 帧构建 |
| qxj-frontend-sdk | 管理前端、业务前端（vendor tgz） | JSBridge 封装 / 国密 |
| qxj-backend-sdk | 业务后端（vendor wheel） | token 校验 / SM4-GCM 加解密 |
核心数据流
场景一：握手 → 加密登录 → 业务访问
业务后端验 token（双层校验）
访问控制执行顺序
登录认证通过后，对非超管依次校验：时间规则（按角色，DENY 优先） → 地理围栏（按角色，haversine 距离判定）； 设备状态贯穿握手与每次鉴权（0 禁用 / 2 挂失 / 3 年审中一律拒绝）。 任一环节拒绝均写入安全审计日志。详见 访问控制。
部署架构
部署位置规划
当前单机实现形态
开发与小规模部署为单机形态：Nginx（443）+ gunicorn（:4607）+ Redis（6379）+ SQLite/MySQL，业务后端为独立进程。
- Nginx 终结 TLS 后以 HTTP 回源，Django 端
CSRF_TRUSTED_ORIGINS与TRUSTED_PROXY_COUNT需相应配置； - 日志落后端
logs/；静态文件由 whitenoise / Nginx 提供； - 前端管理端可
pnpm build:backend输出到后端frontend_dist/同源托管。
完整生产部署步骤（Python 环境 / gunicorn / Nginx / Supervisor / Systemd / 回滚 / FAQ）见 部署文档（完整版）。
安全特性（实际实现）
| 特性 | 实现 |
|---|---|
| 传输加密 | HTTPS（TLS），生产强制 |
| 应用层加密 | SM4-GCM（握手后登录信封、业务加解密接口） |
| Token | NSP-SM：SM2withSM3 外层签名 + SM3-HMAC 内层，双层校验 |
| 前向安全 | 每次握手中临时密钥对，会话密钥经 SM3-KDF 独立推导，不落地网络 |
| 防重放 | INIT / 登录密文 SHA256 指纹 SET NX 去重 |
| 密钥存储 | 服务器私钥 SM4 加密入库，主密钥由环境变量 QXJ_KEY_ENC_KEY 提供 |
| 终端凭据 | 浏览器侧密钥 / token 走关键资产存储（Asset Store Kit） |
| 硬件支撑 | PCIE 密码卡（站点侧）、TF 卡（终端侧） |
| JSBridge | 全页面注入 + 应用侧 origin 白名单，结构化 JSON、永不 reject |
| 审计 | SecurityLog 全链路记录，敏感字段脱敏 |