TG咨询虚拟空间里显示的“设备型号”未必对应真实硬件：应用可能运行在 Android 模拟器、应用容器、云端设备或桌面虚拟环境中。因此，企业应用在虚拟化运行空间中的设备完整性校验适配，重点不是识别某个型号，而是确认证明来自哪里、能否由服务端验证，以及校验失败后如何处理。
先分清虚拟化的是应用，还是整台设备
常见情况可分为三类：应用运行在实体手机的工作资料或受管容器中；应用运行在模拟器、云端设备等虚拟设备上；移动应用画面通过远程桌面或应用发布方式呈现，实际执行发生在另一台主机。三者拿到的本地设备信息、硬件密钥能力和管理状态并不相同。
先画出“用户终端—虚拟运行环境—企业服务端”的数据路径，确认哪一端持有设备、谁发起登录，以及敏感操作是否由服务端执行。设备名称、系统版本等可由应用读取的信息只适合辅助判断，不能单独作为完整性证明。
选择能被服务端核验的信号
使用平台提供的完整性证明
Android 应用可评估 Google Play Integrity API 是否适合当前分发方式和运行环境；它返回的完整性判定应由服务端校验，并结合应用身份、请求内容和业务风险解释。Apple 平台可评估 App Attest，部分场景也会用到 DeviceCheck。它们的支持条件和返回信息不同，不能假定每种虚拟环境都会得到相同结果，也不应把“未能证明”直接等同于“设备已被篡改”。
如果企业应用通过受管设备方案部署，可把移动设备管理（MDM）提供的登记状态、合规状态与平台证明分开记录。MDM 状态说明设备是否受组织策略管理，不等于硬件级完整性证明。
避免把客户端自报当成可信结论
应用可采集系统版本、应用版本、调试状态等辅助信号，但攻击者可能修改客户端返回值。服务端应验证平台签名或令牌，并检查应用标识、时间、新鲜度及请求关联关系。挑战随机数（nonce）应由服务端生成并与一次业务请求绑定，以降低旧证明被重放的风险。
一套可执行的适配流程
- 列出目标环境：实体设备容器、模拟器、云端设备或远程应用，并注明操作系统、应用分发渠道和是否受 MDM 管理。
- 按平台接入相应证明能力，在测试环境确认哪些环境能取得有效证明，哪些会返回不支持、风险较高或信息不足的结果。
- 由服务端发起带随机数的校验请求；客户端获取证明后提交，服务端完成验签、时效检查和业务请求绑定，不接受客户端自行给出的“通过”结论。
- 将结果映射为允许、追加验证、限制敏感操作或拒绝等策略。登录、查看普通内容与导出敏感数据可采用不同门槛。
- 覆盖正常设备、受管容器、模拟环境、网络中断、证明过期和平台服务不可用等测试场景；记录失败原因与应用版本，避免只统计通过率。
策略设计：可信判断要有降级路径
企业应用在虚拟化运行空间中的设备完整性校验适配，应区分“明确不可信”和“无法判定”。例如，证明签名无效或请求已过期，可拒绝该次敏感操作；平台暂不可用时，则可要求重新认证、限制高风险功能或稍后重试。具体选择取决于数据敏感度、业务连续性要求和组织安全制度。
不要依赖单一字段硬编码拦截，也不要把设备指纹当作永久身份。应用更新、系统升级、管理策略变化都可能影响信号。建议将规则放在服务端配置，保留规则版本和判定原因，并定期用真实支持范围复核。这样，企业应用在虚拟化运行空间中的设备完整性校验适配才能兼顾安全与可用性。
常见问题
虚拟机一定会被判定为不可信吗？
不一定。结果取决于平台接口、虚拟环境和分发方式；应在目标环境实测，并按返回结果制定策略。
读取设备型号或系统版本够不够？
不够。这些信息可以辅助排查，但容易被伪造，不能替代服务端验证的平台证明。
没有完整性证明时还能运行应用吗？
可以按业务风险提供降级方案，例如允许低风险功能、对敏感操作追加验证，或要求改用受支持的设备环境。
MDM 合规状态能代替设备完整性证明吗？
不能直接替代。前者反映管理登记或策略符合情况，后者用于验证平台提供的应用或设备证明，应分别判断并组合使用。