安全不是上线前补一个审计报告就能解决的事。很多团队把安全放在最后，等到扫描出一堆漏洞再临时修，结果越修越乱。HarmonyOS NEXT 的安全设计从系统层就做了重构，开发者如果还用老思路写代码，会在权限、数据访问、跨设备传输等环节踩坑。
这一篇把安全和隐私变成工程化的流程：从设计、开发、上架到运行，每个阶段该做什么，清单化呈现。
一、星盾安全架构：从权限管理转向数据管理
HarmonyOS NEXT 的星盾安全架构做了几件事：
禁止九类不合理权限：应用再也不能像传统系统那样随意申请读取通讯录、读取已安装应用列表、后台定位等敏感权限。
安全访问机制：用户选哪张照片，应用就拿哪张照片；用户选哪个文件，应用就只能读哪个文件。
一文一密：单设备上的数据通过硬件级加密保护。
文件加密分享：分享出去的文件只有被授权的人才能打开，不依赖应用和渠道。
这对开发者最直接的改变是：很多场景下你不再有「整类数据权限」，必须改用系统提供的安全访问接口。比如读取图片，不再申请相册权限，而是调用系统图片选择器，用户选中的图片以 URI 形式返回，应用按 URI 读取。
// 使用 PhotoAccessHelper 让用户选择单张图片
import { photoAccessHelper } from '@kit.MediaLibraryKit';
async function pickSingleImage(): Promise<string | undefined> {
const photoSelectOptions = new photoAccessHelper.PhotoSelectOptions();
photoSelectOptions.MIMEType = photoAccessHelper.PhotoViewMIMETypes.IMAGE_TYPE;
photoSelectOptions.maxSelectNumber = 1;
const photoPicker = new photoAccessHelper.PhotoViewPicker();
const result = await photoPicker.select(photoSelectOptions);
return result.photoUris[0]; // 应用只拿到用户选中的 URI
}
拿到 URI 后，应用可以读取这张图片，但拿不到整个图库目录。这就是「管数据」而不是「管权限」的区别。
二、权限设计：最小必要 + 运行时验证
HarmonyOS NEXT 的权限模型强调两个原则：最小必要、运行时验证。
最小必要意味着你在 module.json5 里申请的权限，必须能在应用市场上解释清楚为什么要用。运行时验证意味着系统会在调用敏感能力时再次检查，而不是安装时一次性授权。
权限分级如下：
开发时的权限 checklist：
[ ] 是否只申请了业务真正需要的权限
[ ] 是否在用户拒绝授权后给出降级方案
[ ] 是否在 UI 上有明确的权限使用说明
[ ] 是否在权限申请失败时做了兜底处理
// 相机权限检查与申请
import { abilityAccessCtrl, Permissions } from '@kit.AbilityKit';
const CAMERA_PERMISSION: Permissions = 'ohos.permission.CAMERA';
async function checkCameraPermission(): Promise<boolean> {
const atManager = abilityAccessCtrl.createAtManager();
const grantStatus = await atManager.checkAccessToken(CAMERA_PERMISSION);
return grantStatus === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED;
}
三、数据安全：加密、存储、传输三步走
数据生命周期分三段：存储时、传输时、使用时。
存储时：敏感数据不要直接写本地文件或 Preferences。对于密钥、Token、用户凭证，使用 Asset Store Kit 存到系统级安全存储。
import { asset } from '@kit.AssetStoreKit';
async function saveToken(token: string): Promise<void> {
const attr: asset.AssetMap = new Map();
attr.set(asset.Tag.SECRET, new Uint8Array(Buffer.from(token)));
attr.set(asset.Tag.ALIAS, new Uint8Array(Buffer.from('user_token')));
attr.set(asset.Tag.ACCESSIBILITY, asset.Accessibility.DEVICE_FIRST_UNLOCKED);
await asset.add(attr);
}
传输时：与服务端通信走 HTTPS，不要自行实现加密协议。对于特别敏感的业务，可以结合 Device Certificate Kit 做双向 TLS。
使用时：不要把敏感数据随意写日志。很多数据泄露不是因为被攻击，而是因为日志里打印了 Token 或身份证号。
四、安全开发生命周期（SDL）落地
把安全变成工程习惯，比事后补漏有效得多。推荐把 SDL 拆成五个阶段：
对中小团队来说，最省成本的做法是：把安全编码规范写成 checkstyle/规则集，放进代码提交前检查；把敏感 API 调用抽象成统一的工具类，避免每个开发者自己实现。
五、隐私合规：不只是过审
隐私合规的核心是「让用户知道你在用什么、为什么用」。HarmonyOS NEXT 要求应用上架时提交隐私声明，说明收集了哪些数据、用途是什么、保留多久。
工程落地建议：
隐私声明与代码对齐：代码里实际采集的数据，必须和隐私声明里写的一致。
用户可控：提供账号注销、数据导出、撤回同意的入口。
未成年人保护：如果应用可能面向未成年人，接入系统级未成年人模式。
六、实战建议：安全工作从三张表开始
敏感数据清单：列出应用涉及的所有敏感数据，标注存储位置、加密方式、传输协议。
权限使用清单：列出每个权限的业务用途，定期 audit 是否有冗余。
安全事件响应清单：定义数据泄露、恶意攻击、权限滥用的处理流程和责任人。
这三张表不复杂，但能让团队从「出了问题再补」变成「一开始就防」。
小结
HarmonyOS NEXT 的安全架构已经从"应用申请权限"演进到了"系统管理数据"。开发者的安全责任没变，但实现方式变了：更依赖系统能力、更强调最小必要、更注重全生命周期管理。把安全放进需求、设计、开发、测试、上线的每个环节，才是工程化做法。
下篇讲跨平台与多端协同架构，把分布式能力真正落到工程实践中。
参考阅读
HarmonyOS 开发者文档：星盾安全架构
HarmonyOS 开发者文档：安全访问机制
HarmonyOS 开发者文档：Asset Store Kit 开发指南