📚 课程目录第3章安全设计原则

3、安全设计原则：最小权限、默认安全、纵深防御

聊安全设计，我一直觉得原则比具体技术更重要。技术会换代，但原则能陪你走很远。SDK开发里这三个原则——最小权限、默认安全、纵深防御——几乎能覆盖我见过的90%安全问题。每个都值得反复琢磨。

3.1 最小权限：不多给一寸疆土

最小权限，说白了就是“够用就好”。你的SDK只需要读文件，那就不要申请写权限；只需要访问网络，那就别碰联系人列表。我早年做支付SDK时踩过一个坑：为了方便传递用户信息，直接申请了读取设备标识和位置权限。结果审计时被客户怼回来——人家银行SDK一个多余权限都不申请。改完后不仅通过审计，连接入方的信任度都高了不少。

  核心要点：
  每个API只暴露必要功能，不把底层能力全部抛出去
进程/线程只赋予完成当前任务所需的最小特权
文件、网络、设备等资源按需申请，用完即释放

怎么做？我推荐三步走：

穷举所有功能路径——把SDK每个接口、每个回调、每个后台线程列出来
标出每条路径的真实资源需求——比如某接口只需读配置，那就别给它读写数据库的权限
裁剪冗余权限——比如android里用<uses-permission>只声明真正需要的，别图省事写一堆

举个例子，一个日志SDK的接口设计：

// 错误的设计：直接暴露文件读写路径
public void logToFile(String path, String message) { ... }

// 正确的设计：只允许写入指定的日志目录
public void log(String tag, String msg);
// SDK内部管理日志文件的存储位置，调用方无需关心

调用方只需要给日志内容，不需要知道文件存在哪。这就是“接口最小化”。

个人经验： 我在设计SDK的配置结构时，习惯把所有可选参数放到一个Builder里，默认全为null或false。调用方只设置他们关心的。这样既灵活，又不会因为传错了参数导致权限放大。

3.2 默认安全：不信任任何人的疏忽

默认安全是什么意思？就是你的SDK装上去，什么都不配，也得是安全的。别指望接入方会主动打开HTTPS、校验签名、设置过期时间。我曾经见过一个SDK，默认关闭了证书验证，文档里写着“建议在生产环境开启”。结果大量开发者在测试环境直接复制代码到生产——完蛋。

嗯，从那以后我定了个规矩：所有安全开关默认都要最严格的那一档。

安全项	不安全默认	安全默认
TLS证书验证	关闭（方便测试）	开启，且锁定根证书
日志输出级别	DEBUG（打印全部信息）	WARN（仅打印警告和错误）
存储	明文	加密存储 + Keychain
文件权限	所有人可读	仅当前进程可读

你想想看，如果SDK默认打开了所有调试日志，一旦发布到用户手机，敏感信息可能就从logcat泄漏出去了。我曾经排查过一个事故：某款游戏SDK默认打印了玩家设备ID、IP和登录，结果被竞争对手抓到了。

避坑指南： 默认安全不等于“功能不可用”。比如你默认禁止网络请求，那SDK就没法联网。正确的做法是：默认开启安全机制（如证书校验），但提供高级配置接口让有经验的接入方按需调整，且必须明确警告风险。

3.3 纵深防御：让攻击者步步维艰

纵深防御，说白了就是“别把鸡蛋放在一个篮子里”。即使第一道防线破了，后面还有第二道、第三道。我不指望我能永远不出漏洞，但我要让攻击者付出足够的代价。

我参与过一个金融类SDK的架构设计，当时就画了这样一张图：

从图里你能看到，每一层都是独立的防护，而且每层出错都会留下痕迹。我记得有一次我们在SDK里加了反调试检测，结果某个破解软件试图Hook我们的加密函数，被第二层的完整性校验发现了，然后第三层的日志模块直接把异常信息上传到我们的监控后台。虽然最终破解者还是绕过了，但我们用了不到一天就发布了热修复补丁。

  实践建议：
  多重校验：不要只依赖单一校验点，比如签名校验在加载时做一次，运行时再做一次
安全日志要分层：普通错误可以本地记录，敏感异常要加密上报
密钥不要硬编码：用KeyStore或安全芯片存放，并结合动态生效机制

3.4 三者协同：一张安

这三个原则不是孤立的。最小权限减少了攻击面，默认安全减少了人为失误，纵深防御提供了容错能力。我合作过的一家头部IoT厂商，他们的SDK要求所有API的权限声明必须在文档中逐条解释，同时默认屏蔽所有高风险接口（如文件读写、网络插拔监听），只有显式调用一个授权方法才能打开——这就是三原则结合的例子。

场景	最小权限	默认安全	纵深防御
文件读取API	只读，不能写	默认仅限应用私有目录	每次读取前校验路径合法性 + 记录访问日志
网络请求API	仅支持HTTPS，不暴露底层Socket	默认开启证书校验	连接后检测中间人 + 超时重试机制 + 上报异常
用户身份信息API	只提供脱敏后的ID（如哈希值）	默认不收集任何信息	收集前需用户授权+数据加密+定期清理

我真切建议： 在SDK设计文档里专门开一节“安全设计原则”，把你每个接口如何应用这三个原则写清楚。这不仅是为了给自己看，更是为了给安全评审团队看。评审一次性过，能省很多来回扯皮的时间。

注意： 别以为加了纵深防御就能放松最小权限。我见过有人觉得“反正后面还有校验”，结果前端随意暴露了文件操作接口。记住：每一层都该承担它那层的责任，不要互相推卸。

最后留个思考：你的SDK里，有没有哪个接口同时违反了这三条？如果有，趁还来得及赶紧改。我相信你做完这件事后，下次用户评估安全时会对你的SDK更有信心。