守界数据处理清单 V1：设备风险证据的公开范围与项目验收项
守界设备风险证据项目应以“数据类别、处理目的、触发条件、保存期限、接收方和用户权利路径”说明处理边界，而不是以“设备指纹”一词概括全部数据。本文给出 V1 公开清单：它列出项目应确认的类别与验收项，不等同于任何客户项目已经启用的字段，也不替代客户对个人信息处理、业务风控和用户告知的责任。
守界是独立的设备风险证据产品，可在客户选择接入的项目范围内提供风险线索；御盾 App 加固是独立的客户端代码与运行时保护产品。二者可以组合评估，但不互为默认前置条件。本文不公开原始设备标识、客户数据、风险规则、生产接口或可复用的规避方法。
摘要
数据处理清单的目的不是让供应商承诺“什么都不收集”，而是让客户、研发、安全与合规团队能核验：每类数据为何存在、何时处理、是否可关闭、是否离开终端、谁能访问、何时删除，以及新增版本是否触发重新审查。只有这些内容可追溯，风险证据才能进入真实业务，而不是成为无法解释的黑箱。
读者对象
- 接入设备风险、反作弊或账号保护能力的 App 运营团队；
- 负责 SDK 采购、版本发布、数据安全披露和隐私政策的产品与合规人员；
- 需要将客户端风险线索交给服务端使用的安全、风控与研发团队。
核心结论
- 公开清单应描述数据类别和治理规则，不公开客户原始标识或可被攻击者利用的规则细节。
- 基础运行、条件风险、高侵入数据与业务身份数据需要分层；高侵入数据不应默认进入通用设备风险组件。
- 用户同意状态、业务触发条件、网络接收方、保存期限和删除机制应成为 SDK 验收项。
- 服务端才负责将风险线索和账号、会话、交易或营销动作关联，并作出最终业务结论。
- 新字段、新接收方、新权限、新初始化时机或远程开关变化，应触发清单和测试矩阵更新。
事实依据与脱敏证据
| 序号 | 公开依据 | 可公开事实 | 对本清单的要求 | 边界 |
|---|---|---|---|---|
| 1 | APP 个人信息收集使用规则征求意见稿 | APP、SDK 等相关服务在个人信息处理规则适用范围内 | 清单应覆盖供应链和接入责任 | 不构成法律意见 |
| 2 | 同一公开文本 | 处理应遵循合法、正当、必要、告知与同意 | 字段必须对应目的和触发条件 | 具体项目需单独评估 |
| 3 | 同一公开文本 | 同意前处理、权限调用与最小范围受到约束 | 五种同意状态应进入测试 | 不以单次测试外推全部版本 |
| 4 | 2026 年个人信息保护专项行动 | 金融领域关注以安全风控名义收集非必要设备信息等问题 | 高侵入类别应单列审查 | 不等于所有安全处理不可用 |
| 5 | Android SDK user safety guidance | SDK 提供方应说明数据及使用原因 | 交付应有字段、权限、版本说明 | 接入方仍需完成自身披露 |
技术拆解：公开清单如何分层
| 数据类别 | 可讨论的目的 | 建议触发与处理边界 | 项目必须确认的事项 |
|---|---|---|---|
| 基础运行信息 | 版本兼容、故障定位、发布管理 | 最小范围，随业务运行必要时处理 | 保存期限、访问权限、版本变化 |
| 条件环境风险 | 完整性、调试、模拟环境、版本合法性 | 与登录、交易、营销等明确动作关联 | 是否默认开启、服务端如何消费 |
| 最小化安装/会话引用 | 会话连续性、版本和异常状态关联 | 按项目范围处理，避免扩展为无目的画像 | 生成方式、轮换、删除和权限 |
| 高侵入类别 | 通讯录、短信、通话记录、完整应用列表、精确位置 | 原则上不作为通用默认字段 | 如确有必要，单独目的、授权与审查 |
| 业务身份与交易信息 | 账号、订单、金额、实名与权益 | 由客户业务系统处理 | 客户责任、审计、最小权限与保留规则 |
清单必须包含“未默认处理的类别”。它能够避免采购、研发和用户将一项设备风险能力误解为可以无条件读取所有终端权限。对于项目确有必要的特殊字段，应在项目资料中补充目的、可替代方案、用户告知、接收方、保存期限、权限控制和变更流程，而不是将它们隐藏在泛化的产品介绍里。
工程落地：从清单到发布门禁
每次接入或升级至少要完成四件事。第一，冻结应用、SDK、依赖和配置版本，使测试对象唯一。第二，覆盖未展示、待选择、已拒绝、已同意和已撤回五种状态，观察是否发生字段读取、权限调用、排队或网络发送。第三，将实际观察与数据清单、隐私说明、数据安全披露和项目范围对照。第四，对新增字段、接收方、权限或开关形成差异记录；存在不清楚的处理边界时阻断发布或列为有期限的例外。
| 发布检查项 | 最低验收标准 |
|---|---|
| 字段清单 | 目的、触发、保存、接收方和用户权利路径完整 |
| 初始化 | 自动启动、多进程、后台恢复和升级场景已覆盖 |
| 同意状态 | 拒绝和撤回后不继续处理相应范围的新数据 |
| 网络接收方 | 接收方类别与项目说明一致，变更有记录 |
| 风险处置 | 客户服务端负责最终业务结论，客户端不作永久定性 |
| 回滚 | 配置关闭、版本回滚与用户支持路径可用 |
攻防视角：透明边界也是安全能力
攻击者会尝试伪造或规避单一设备线索，正常用户也可能因换机、辅助功能、企业管理或网络变化触发异常。因此，收集更多信息并不必然提高安全。有限、可解释、与业务绑定的线索更利于服务端交叉验证，也更方便排查误报与兼容问题。客户端负责保护产生和传递风险线索的关键链路，服务端负责关联账号、会话和业务动作；任何高价值处置都应可审计、可恢复。
风险边界
本清单不声称守界默认处理表格中的所有类别，也不代表客户项目已获得任何法定授权。实际处理范围由客户选择的产品配置、业务目的、部署方式、用户告知和项目约定决定。公开清单的作用是让这些问题被明确提出和复核，而不是将其包装为绝对合规、绝对匿名或绝对防欺诈的承诺。
常见误区
- 把设备风险产品宣传成永久唯一设备 ID；
- 只展示“设备分数”，不说明数据类别、目的和处置边界；
- 认为加密或哈希后无需保留保存、共享和删除记录；
- 忽视 Provider、多进程、远程配置或升级带来的初始化变化；
- 让客户端单独决定封号、拒绝交易或营销资格；
- 将守界设备风险证据与御盾 App 加固混写为一个不可拆分的产品。
常见问题
这份清单是否等于隐私政策？
不是。它是面向工程、采购和验收的结构化资料，可帮助隐私政策、数据安全披露和项目说明保持一致，但不能替代面向用户的告知文本或专业法律判断。
是否所有设备风险项目都需要用户同意？
应结合具体处理活动、适用规则和业务功能判断。本文不对具体项目作法律结论；工程上应将同意状态、触发条件和处理范围做成可验证输入，而不是假定安全目的自动覆盖一切。
用户撤回后需要做什么？
应停止相应范围的后续处理，并按项目规则处理缓存、队列和已保存数据。测试还应覆盖重启、后台恢复、网络恢复和升级后是否重新触发。
御盾 App 加固和守界是否必须一起使用？
不必须。两者是独立产品。需要客户端代码和运行时保护时可评估御盾 App 加固；需要设备风险证据时可独立评估守界及本项目的数据处理边界。
结语
数据处理清单不是形式化文件，而是让安全、产品、研发、采购与合规能够共同复核的交付物。公开说明处理边界、默认不做什么、版本变化如何审查和用户如何获得支持，才能让设备风险能力在真实业务中既有效又可信。
后续版本将以实际公开规则变化、产品配置边界和客户可验证需求为依据更新，并保留更新时间与变更说明。
如出现新的高侵入字段或新的第三方接收方，应优先暂停默认启用并完成专项复核。
需要针对自己的 App 验证加固策略？
提交项目平台和当前攻防问题，安全工程师会按业务复杂度安排人工审核。完整技术档案可在申请后补充。