Apple 系统防护 · 工程预览
XSafe: X 系统级防护
真实的 HostOnlyPreview 控制台,覆盖本地规则校验、防护模块状态、诊断与 FullLive 就绪度。在满足平台前置条件之前,Network Extension、Endpoint Security、MDM 等受限能力始终明确保持禁用。

关键成果
HostOnlyPreview iOS 控制台已在 iPhone 模拟器完成构建与验证
五条可信规则完成本地 Schema、SHA256 与受保护合并校验
如实呈现十二项未满足的 FullLive 前置条件,不把预览状态包装成已启用防护
概览
XSafe 的当前产品形态是一套 owner 控制的 Apple 系统防护工程控制台。它先把规则、模块、诊断、报告和平台前置条件讲清楚,再决定何时进入 FullLive,而不是在授权未完成时制造已经具备实时防护的错觉。
- 所有者掌控:只有设备所有者能确认配置、导入规则和推进受限能力。
- 本地优先:规则校验、就绪判断、诊断与报告优先留在设备本地。
- 如实呈现能力:未启用的 Network Extension、MDM 和 Endpoint Security 始终显示为未启用。
- 跨平台就绪:在同一模型中区分 iOS、macOS 与受监督设备的不同前置条件。
问题
Apple 平台的系统级防护能力不是普通 App API:Network Extension、Endpoint Security、System Extension、MDM 和 Screen Time 都受到 entitlement、签名、用户批准或设备管理状态约束。最大的产品挑战不是画出一个安全面板,而是把真实能力与未来能力严格分开。
- 受限能力必须经过 Apple entitlement、签名和用户批准,不能用私有 API 绕过。
- iOS 与 macOS 的能力范围不同,Endpoint Security 不会在 iOS 上被伪装成可用。
- 预览模式仍需提供可验证价值,同时不能暗示实时拦截已经生效。
- 规则导入、诊断和报告本身也要遵守最小数据与本地处理边界。
解决方案
XSafe 先交付 ConfigB_HostOnlyPreview:一个可运行的本地控制台,用真实状态组织可信规则、防护模块、FullLive 前置条件、本地诊断、安全边界和报告导出。它把“准备好什么、缺少什么、谁必须批准”变成产品界面。
- 状态控制台:用 42/100 就绪分数和逐项状态呈现当前能力,而不是营销式安全评分。
- 可信规则中心:内置规则可本地校验,外部 JSON 先预览 SHA256、Schema 与合并边界。
- 就绪条件清单:将 iOS、macOS、MDM、权限授权与所有者批准等前置条件逐项列出。
- 安全边界:明确禁止私有 API、隐蔽监控、越权持久化和敏感数据外传。
架构
安全架构
预览架构将如实呈现状态的产品控制台与受控的平台集成分离。XSafeCore 负责确定性的本地策略与就绪逻辑;由 Apple 管理的能力保留在适配器之后,只有满足真实前置条件才可报告为已启用。
面向 iPhone 的模式、模块、可信规则、就绪度、诊断、安全边界与本地报告界面。
共享本地模型、风险评分、健康探针、隐私感知日志、加密存储与确定性规则评估。
内置与手动选择的 JSON 规则,支持 SHA256 预览、Schema 校验、受保护合并策略与私有容器存储。
将平台前置条件分类为已就绪、缺失、禁用、所有者确认或等待 Apple 批准。
在取得真实 entitlement 与批准前,Network Extension、Family Controls、MDM、System Extension 与 Endpoint Security 集成保持未启用。
在设备端生成健康摘要与可导出的就绪报告,避免读取无关应用或用户隐私数据。
本地处理模型
HostOnlyPreview 的可用价值全部建立在本地处理上:可信规则、就绪状态、诊断与报告无需依赖远端画像。手动导入只在用户选择文件后发生,且在写入前先完成内存预览与校验。
- 不静默导入:只有设备所有者主动选择 JSON 后才读取文件,文件上限为 2 MB。
- 不采集浏览记录:规则分类只显示数量,不展示或记录完整浏览地址。
- 重视隐私的存储:规则和报告留在应用私有容器,并使用可审计的本地处理链路。
- 不虚假启用:本地规则可用不等于系统过滤已启用,界面始终保留这一区分。
工作流
防护就绪工作流
每次启动都从已知配置开始,并生成本地、可解释的就绪状态。受限集成不能悄然从预览切换到实时;所有者操作与平台批准始终是显式门槛。
防护就绪工作流
- 步骤 01
加载 HostOnlyPreview
以 ConfigB_HostOnlyPreview 启动控制台,并将实时防护状态初始化为未启用。
- 步骤 02
校验本地规则
加载五条内置可信规则,并在本地检查版本、Schema、SHA256 和受保护合并边界。
- 步骤 03
评估前置条件
按 iOS、macOS 和设备管理范围逐项判断 entitlement、profile、受监督状态与 owner approval。
- 步骤 04
复查与导出
在本地诊断、安全边界和报告中复查结果;只有满足真实前置条件后才考虑 FullLive。
能力门控
受限的 Apple 能力始终位于明确的平台与所有者控制门槛之后。预览数据可以解释就绪状态,但不能把模块标记为已启用防护。
- 每个受保护的系统入口都必须具备正确的 entitlement 与描述文件。
- 在验证完成前,Network Extension、Endpoint Security、MDM 与 Screen Time 状态明确保持禁用。
- 在 Apple 要求的场景中,必须取得所有者确认与系统用户批准。
- 从本地状态生成就绪报告,不把诊断成功等同于实时防护已激活。
技术栈
技术栈
实现采用原生 Apple 框架与共享 Swift 核心;受限系统能力仅在其支持的平台与 entitlement 边界内编译和呈现。
产品控制台
安全核心
受控集成
时间线
交付路径记录了产品如何从概念验证逐步演进为具备生产形态的系统。
梳理 Apple 批准的防护入口
将受支持的 API 与受管设备能力,同私有 API、绕过技术和不安全监控模式明确分离。
交付 ConfigB_HostOnlyPreview
完成原生控制台、可信规则校验、就绪度评估、本地诊断、安全边界与报告界面。
满足 FullLive 前置条件
在宣称实时防护前,取得所需 Apple 批准、签名描述文件、用户同意、MDM 基础设施与设备级激活条件。
产品画面
这些图片直接来自经过验证的 HostOnlyPreview iPhone 模拟器构建,禁用与缺失状态被有意保留。



复盘
XSafe 当前最重要的工程成果不是“防护已开启”,而是建立了一套不会越权、不会误报能力、也不会把安全工具变成新隐私风险的产品骨架。对系统安全产品来说,准确表达不可用状态与准确实现可用能力同样重要。
- 能力真实可信:任何未满足权限授权、签名、用户批准或 MDM 条件的模块都保持未启用。
- 安全边界:不使用私有 API、越狱、隐蔽持久化、键盘记录、隐藏监控或安全机制绕过。
- 本地信任:通过可解释规则、最小数据和本地报告建立可审计信任。
- 下一里程碑:FullLive 是需要真实授权与设备条件的后续工程阶段,不是前端开关。