返回项目03

Apple 系统防护 · 工程实践

把安全能力边界，变成可理解的决策依据。

用真实的 HostOnlyPreview 控制台呈现规则校验、模块状态、诊断与 FullLive 就绪度；在平台条件未满足前，受限能力始终保持明确禁用。

方案支柱 01能力如实呈现
方案支柱 02本地可信规则
方案支柱 03下一阶段就绪证据
HostOnlyPreview 安全控制台
00

交付证据

证据 01

HostOnlyPreview iOS 控制台完成构建与运行验证

证据 02

五条可信规则通过本地 Schema、SHA256 与受保护合并校验

证据 03

十二项 FullLive 前置条件如实呈现，预览状态不会被包装成已启用防护

01

目标与机会

本方案先把规则、模块、诊断、报告与平台前置条件讲清楚，再判断何时进入 FullLive；核心目标是建立可信决策基础，而不是在授权未完成时制造实时防护错觉。

  • 01所有者掌控：只有设备所有者能确认配置、导入规则和推进受限能力。
  • 02本地优先：规则校验、就绪判断、诊断与报告优先留在设备本地。
  • 03如实呈现能力：未启用的 Network Extension、MDM 和 Endpoint Security 始终显示为未启用。
  • 04跨平台就绪：在同一模型中区分 iOS、macOS 与受监督设备的不同前置条件。
02

关键挑战

Apple 平台的系统级防护能力不是普通 App API：Network Extension、Endpoint Security、System Extension、MDM 和 Screen Time 都受到 entitlement、签名、用户批准或设备管理状态约束。最大的产品挑战不是画出一个安全面板，而是把真实能力与未来能力严格分开。

  • 01受限能力必须经过 Apple entitlement、签名和用户批准，不能用私有 API 绕过。
  • 02iOS 与 macOS 的能力范围不同，Endpoint Security 不会在 iOS 上被伪装成可用。
  • 03预览模式仍需提供可验证价值，同时不能暗示实时拦截已经生效。
  • 04规则导入、诊断和报告本身也要遵守最小数据与本地处理边界。
03

方案主张

方案先交付 ConfigB_HostOnlyPreview：用可运行的本地控制台把“已经具备什么、仍缺少什么、何时可以推进”变成清晰界面与可导出证据。

  • 01状态控制台：用 42/100 就绪分数和逐项状态呈现当前能力，而不是营销式安全评分。
  • 02可信规则中心：内置规则可本地校验，外部 JSON 先预览 SHA256、Schema 与合并边界。
  • 03就绪条件清单：将 iOS、macOS、MDM、权限授权与所有者批准等前置条件逐项列出。
  • 04安全边界：明确禁止私有 API、隐蔽监控、越权持久化和敏感数据外传。
04

系统蓝图

预览架构将如实呈现状态的产品控制台与受控的平台集成分离。XSafeCore 负责确定性的本地策略与就绪逻辑；由 Apple 管理的能力保留在适配器之后，只有满足真实前置条件才可报告为已启用。

01
层级XSafe SwiftUI 控制台

面向 iPhone 的模式、模块、可信规则、就绪度、诊断、安全边界与本地报告界面。

02
层级XSafeCore

共享本地模型、风险评分、健康探针、隐私感知日志、加密存储与确定性规则评估。

03
层级可信规则存储

内置与手动选择的 JSON 规则，支持 SHA256 预览、Schema 校验、受保护合并策略与私有容器存储。

04
层级就绪度评估器

将平台前置条件分类为已就绪、缺失、禁用、所有者确认或等待 Apple 批准。

05
层级受控平台适配器

在取得真实 entitlement 与批准前，Network Extension、Family Controls、MDM、System Extension 与 Endpoint Security 集成保持未启用。

06
层级本地诊断与报告

在设备端生成健康摘要与可导出的就绪报告，避免读取无关应用或用户隐私数据。

本地信任模型

HostOnlyPreview 的可用价值全部建立在本地处理上：可信规则、就绪状态、诊断与报告无需依赖远端画像。手动导入只在用户选择文件后发生，且在写入前先完成内存预览与校验。

  • 01不静默导入：只有设备所有者主动选择 JSON 后才读取文件，文件上限为 2 MB。
  • 02不采集浏览记录：规则分类只显示数量，不展示或记录完整浏览地址。
  • 03重视隐私的存储：规则和报告留在应用私有容器，并使用可审计的本地处理链路。
  • 04不虚假启用：本地规则可用不等于系统过滤已启用，界面始终保留这一区分。
05

关键路径

每次启动都从已知配置开始，并生成本地、可解释的就绪状态。受限集成不能悄然从预览切换到实时；所有者操作与平台批准始终是显式门槛。

就绪决策路径

  1. 步骤 01

    加载 HostOnlyPreview

    以 ConfigB_HostOnlyPreview 启动控制台，并将实时防护状态初始化为未启用。

  2. 步骤 02

    校验本地规则

    加载五条内置可信规则，并在本地检查版本、Schema、SHA256 和受保护合并边界。

  3. 步骤 03

    评估前置条件

    按 iOS、macOS 和设备管理范围逐项判断 entitlement、profile、受监督状态与 owner approval。

  4. 步骤 04

    复查与导出

    在本地诊断、安全边界和报告中复查结果；只有满足真实前置条件后才考虑 FullLive。

推进门槛与责任边界

受限的 Apple 能力始终位于明确的平台与控制门槛之后。预览数据可以解释就绪状态，但不能把模块标记为已启用防护。

  • 01每个受保护的系统入口都必须具备正确的 entitlement 与描述文件。
  • 02在验证完成前，Network Extension、Endpoint Security、MDM 与 Screen Time 状态明确保持禁用。
  • 03在 Apple 要求的场景中，必须取得所有者确认与系统用户批准。
  • 04从本地状态生成就绪报告，不把诊断成功等同于实时防护已激活。
06

落地基础

实现采用原生 Apple 框架与共享 Swift 核心；受限系统能力仅在其支持的平台与 entitlement 边界内编译和呈现。

产品控制台

SwiftUIUIKitUniformTypeIdentifiers

安全核心

XSafeCoreCryptoKit规则引擎健康探针

受控集成

Network ExtensionFamily ControlsMDMSystem ExtensionsEndpoint Security
07

推进路径

以阶段性目标、验证标准与交付物推进方案，让每一步都能为下一阶段决策提供依据。

边界研究

梳理 Apple 批准的防护入口

将受支持的 API 与受管设备能力，同私有 API、绕过技术和不安全监控模式明确分离。

工程预览

交付 ConfigB_HostOnlyPreview

完成原生控制台、可信规则校验、就绪度评估、本地诊断、安全边界与报告界面。

下一阶段

满足 FullLive 前置条件

在宣称实时防护前，取得所需 Apple 批准、签名描述文件、用户同意、MDM 基础设施与设备级激活条件。

08

交付实证

这些界面证据直接来自经过验证的 HostOnlyPreview iPhone 模拟器构建，禁用与缺失状态被有意保留。

防护模块
界面截图防护模块真实模块状态界面，将本地指导与规则预览同尚未启用的 Network Extension、MDM 和 Endpoint Security 能力明确区分。
可信规则中心
界面截图可信规则中心在运行中的模拟器版本里呈现本地规则包状态、Schema 校验、SHA256 预览、受控 JSON 导入与受保护合并边界。
FullLive 就绪状态
作品展示FullLive 就绪状态如实列出 iOS 与 macOS 能力中已就绪、缺失、禁用，或仍需所有者与 Apple 批准的前置条件。
09

决策复盘

最重要的交付结果不是“防护已开启”，而是一套不会越权、不会误报、也不会制造新隐私风险的可信产品骨架。对系统安全产品来说，准确表达不可用状态与准确实现可用能力同样重要。

  • 01能力真实可信：任何未满足权限授权、签名、用户批准或 MDM 条件的模块都保持未启用。
  • 02安全边界：不使用私有 API、越狱、隐蔽持久化、键盘记录、隐藏监控或安全机制绕过。
  • 03本地信任：通过可解释规则、最小数据和本地报告建立可审计信任。
  • 04下一里程碑：FullLive 是需要真实授权与设备条件的后续工程阶段，不是前端开关。