一、前置思考

1.1 为什么企业级应用需要"架构级"安全

中大型企业的鸿蒙应用，安全不再是"加几个工具类"的问题，而是体系化建设问题。监管部门看的是合规（个保法、等保2.0），用户看的是体验与信任，攻击者看的是漏洞。一套真正落地的企业安全架构，必须回答：

• 数据从生成、存储、传输、使用到销毁，全生命周期如何保护？
• 通信链路如何保证防窃听、防篡改、防重放？
• 代码层面如何防逆向、防篡改、防漏洞？
• 隐私合规如何落地并有证据可查？

这就是"数据安全/通信安全/代码安全/隐私合规"四位一体的安全架构。

1.2 单点安全 vs 体系安全

维度	单点安全（零散工具）	体系安全（架构化）
覆盖范围	只覆盖某几个环节	数据全生命周期
一致性	各业务自行实现，标准不一	统一安全 SDK，标准一致
合规证据	拿不出完整证据链	审计日志 + 检查记录可导出
演进能力	补丁式堆叠	平台化演进，可扩展
责任归属	责任分散	安全团队统一负责

企业级安全的本质是治理，不是技术堆叠。技术手段（加密、权限、审计）是基础，但真正决定安全水平的是：有没有统一标准、有没有自动化门禁、有没有证据留痕。

1.3 本文结构

本文从四位一体安全架构出发，分别深入数据安全、通信安全、代码安全、隐私合规四个维度的设计要点，然后给出安全 SDK 统一封装与合规自动化流水线的工程化落地。

二、核心原理

2.1 四位一体安全架构

┌─────────────────────────────────────────────────────┐
│                   企业级安全架构                       │
│                                                     │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│  │ 数据安全  │ │ 通信安全  │ │ 代码安全  │ │ 隐私合规 │ │
│  │  💾      │ │  📡      │ │  🧬      │ │  🔍     │ │
│  ├──────────┤ ├──────────┤ ├──────────┤ ├────────┤ │
│  │静态加密   │ │HTTPS全覆盖│ │混淆加固   │ │权限最小化│ │
│  │传输加密   │ │SSL Pinning│ │防逆向    │ │隐私政策 │ │
│  │备份脱敏   │ │证书校验   │ │完整性校验 │ │数据可删除│ │
│  │密钥轮换   │ │防中间人   │ │依赖扫描   │ │合规审计 │ │
│  └──────────┘ └──────────┘ └──────────┘ └────────┘ │
│                                                     │
│  ┌─────────────────────────────────────────────┐   │
│  │            安全SDK统一封装层                  │   │
│  │  加密引擎 · 权限框架 · 审计框架 · 加固SDK       │   │
│  ├─────────────────────────────────────────────┤   │
│  │            合规自动化流水线                   │   │
│  │  静态扫描 · 依赖扫描 · 权限扫描 · 签名校验      │   │
│  └─────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────┘

四个维度覆盖了数据安全的全部生命周期（数据安全）、全部传输路径（通信安全）、全部代码资产（代码安全）、全部合规义务（隐私合规）。上层的安全 SDK 统一封装让业务"零成本接入"，下层的自动化流水线让合规"持续可验证"。

2.2 数据安全设计

环节	措施	标准
采集	最小化采集，仅收必需字段	个保法
存储	敏感字段 AES/SM4 加密，密钥走 HUKS	等保2.0
传输	TLS1.3 加密通道	等保2.0
使用	权限校验 + 访问审计	等保2.0
销毁	用户注销后数据删除/匿名化	个保法

数据安全设计的五个环节对应数据生命周期的五个阶段：

采集：只采集业务必需的字段。多采集一个字段，就多一份泄露风险和合规义务。采集前做"最小化论证"：这个字段真的需要吗？

存储：敏感字段加密存储，密钥走 HUKS。数据库、偏好、缓存、日志全链路覆盖，不留明文死角。

传输：数据在传输过程中同样需要保护，全流量 HTTPS + TLS1.3。

使用：数据访问要有权限校验和审计，谁在什么时候读写了哪些数据都要留痕。

销毁：用户注销后数据删除/匿名化是法定义务。删除要覆盖所有副本（数据库、缓存、备份、日志），不能只删主库。

2.3 通信安全设计

客户端 ── HTTPS(TLS1.3) + SSL Pinning ──> 服务端
   │                                        │
   │  证书链校验 · 防中间人 · 请求签名         │
   └────────── 证书有效期监控 ──────────────┘

• 全流量 HTTPS，禁明文 HTTP
• SSL Pinning 防中间人
• 请求签名防篡改、防重放

通信安全的三道防线：

第一道：全流量 HTTPS。明文 HTTP 是中间人攻击的温床，企业应用必须全流量 HTTPS。构建门禁强制检查：出现明文 HTTP 请求直接阻塞发布。

第二道：SSL Pinning。标准 HTTPS 校验"证书链有效"，Pinning 校验"证书必须是我认识的"。两者叠加，即使攻击者把自签证书装进信任库，也无法解密流量。

第三道：请求签名。即使流量被解密，请求签名 + 时间戳 + 随机数可以防篡改、防重放。攻击者拿到明文请求也无法伪造合法签名。

2.4 代码安全设计

• 混淆加固 + 字符串加密
• 签名/完整性校验防重打包
• 依赖漏洞扫描（CVE）
• 组件导出收敛（exported: false 默认）

代码安全的四条线：

防逆向：混淆 + 字符串加密 + 控制流平坦化，提高逆向分析成本。核心业务逻辑（支付、验签）建议放 native 层。

防篡改：签名 + 完整性校验，重打包的应用无法运行。

防供应链攻击：依赖漏洞扫描是供应链安全的第一道闸门。CI 中集成 ohpm audit，高危 CVE 阻塞发布。

防暴露：组件导出收敛，默认 exported: false，只开放必须跨应用调用的能力。

2.5 隐私合规设计

隐私合规闭环：
权限清单 → 隐私政策 → 用户同意 → 数据使用 → 数据可删 → 审计留痕

合规要点：

• 权限最小化，申请时机跟随业务场景
• 隐私政策与权限声明联动
• 提供数据导出/删除入口（用户权利）
• 合规审计日志留存

隐私合规闭环的每一环都要有"证据"：

环节	证据
权限清单	权限清单表（权限/用途/时机/场景）
隐私政策	政策文档 + 版本记录
用户同意	同意记录（时间/版本/用户）
数据使用	权限使用审计日志
数据可删	删除接口 + 删除执行记录
审计留痕	审计日志 + 合规检查报告

关键认知：合规不是"写一份隐私政策"就完事，而是"每个环节都有可验证的证据"。证据链完整，审查才能通过。

三、实战落地

对应 Demo 页面：entry/src/main/ets/pages/SecurityComplianceDemo.ets

Demo 包含三个 Tab：

1. 四位一体：展示数据/通信/代码/隐私四维安全评分及各维度落地项，支持计算整体评分
2. 合规检查：展示合规检查清单（签名校验/加密存储/HTTPS/权限最小化/日志脱敏/组件导出），支持执行合规检查
3. 发布门禁：展示发布安全门禁（安全扫描/隐私合规/签名校验/性能安全），支持修复未通过项演示全部门禁通过

// Demo 核心：整体安全评分
private calcOverallScore(): void {
  let sum: number = 0;
  for (let i: number = 0; i < this.pillars.length; i++) {
    sum += this.pillars[i].score;
  }
  this.overallScore = Math.floor(sum / this.pillars.length);
  this.complianceSummary = '整体安全评分：' + this.overallScore.toString() +
    '/100，评级 ' + (this.overallScore >= 90 ? 'A（优秀）' : 'B（良好）');
}

3.1 安全 SDK 统一封装层设计

四个维度的安全能力要收敛为统一安全 SDK，业务零成本接入：

SDK 模块	提供能力	业务接入方式
加密引擎	AES/SM4 加解密、HUKS 密钥管理	一行调用 encrypt/decrypt
权限框架	check/request/ensure 统一封装	一行调用 ensure
审计框架	审计事件采集/上报	一行调用 record
加固 SDK	完整性校验、运行时检测	启动时初始化

统一封装的价值：

• 标准一致：所有业务走同一套安全逻辑，不存在"某业务绕过了"
• 升级可控：安全策略升级只改 SDK，全业务自动生效
• 合规可控：审计/加密行为统一留痕，证据链完整
• 责任清晰：安全团队维护 SDK，业务团队只调接口

3.2 合规自动化流水线

合规检查不能靠人工，要自动化流水线持续执行：

CI 流水线（每次构建/发版触发）
   │
   ├── 静态扫描：检测明文日志/拼接SQL/导出组件/硬编码密钥
   ├── 依赖扫描：CVE 漏洞检查，高危阻塞
   ├── 权限扫描：声明的权限 vs 代码实际调用 vs 隐私政策
   ├── 签名校验：构建产物签名信息核查
   ├── 配置检查：debug 开关/测试地址/日志级别
   └── 报告生成：合规检查报告归档

门禁设计：

门禁项	判定	动作
高危 CVE	存在	阻塞发布
权限三方不一致	不一致	阻塞发布
明文日志/硬编码密钥	发现	阻塞发布
调试开关未收敛	开启	阻塞发布
安全评分	< 阈值	人工评审放行

3.3 企业级安全建设的实施路径

第一阶段：盘点与基线（1-2 周）

• 梳理全部业务模块的数据流、权限使用、第三方 SDK
• 建立权限清单表、敏感数据清单
• 制定安全基线（加密标准、权限标准、日志标准）

第二阶段：SDK 与门禁建设（2-4 周）

• 封装统一安全 SDK（加密/权限/审计/加固）
• 搭建 CI 自动化流水线（静态扫描/依赖扫描/权限扫描）
• 历史业务迁移到统一 SDK

第三阶段：持续运营（长期）

• 定期安全评审与威胁建模
• 漏洞响应机制（SLA：高危 24 小时内响应）
• 合规检查报告定期归档，支撑监管审查

四、避坑速查

坑	现象	原因	解决
安全能力分散	各业务自造安全轮子	无统一安全SDK	统一封装安全SDK层
合规只做表面	审查时发现政策与实现不符	隐私政策与代码脱节	权限清单/政策/实现三方联动
门禁形同虚设	漏洞带病上线	门禁可绕过	门禁强制 + 自动化
数据销毁缺失	注销后数据仍留	未实现删除流程	注销触发全链路数据删除
审计无证据	合规检查无据可查	未留存审计日志	审计日志留存 + 可导出
安全与体验对立	安全措施影响体验	一刀切策略	分级安全策略（高风险强管控）
文档与实现脱节	审查时发现文档过期	文档更新滞后	文档纳入变更流程管理
忽视供应链安全	第三方库漏洞被利用	未做依赖扫描	CI 依赖扫描 + 版本基线
合规证据不完整	审查质疑	只留了部分记录	全环节证据链建设

五、总结

企业级安全合规架构的建设路径：

1. 四位一体：数据/通信/代码/隐私四维覆盖，不留死角
2. 统一封装：安全能力收敛为安全 SDK，业务零成本接入
3. 自动化门禁：扫描/校验纳入 CI，带病代码无法上线
4. 有据可查：审计日志、合规检查结果全程留痕

落地建议：

• 从"安全工具"升级为"安全架构"，安全能力平台化
• 合规检查自动化，人工抽查兜底
• 定期做安全评审与威胁建模，动态调整策略
• 建立安全事件响应机制，明确 SLA 与责任人
• 安全建设分阶段推进：先基线后 SDK 再运营，避免一次性大工程烂尾

企业级安全不是"上线前的检查项"，而是"持续运行的工程"。四位一体架构 + 统一 SDK + 自动化门禁 + 证据链留存，四者缺一不可。只有把安全从"个人经验"变成"体系能力"，才能支撑企业在合规与安全的双重压力下持续演进。