FileVault 采用硬件加速的 XTS-AES 128 加密，符合 FIPS、GDPR、HIPAA 等多项合规要求，其安全性依赖密钥派生、Secure Enclave 存储及完整加密覆盖，而非单纯密钥长度。
macOS FileVault 是系统级全盘加密机制，不是可选插件，而是内建于 macOS 的基础安全能力。它采用 XTS-AES 128 位加密标准，该算法由 Apple 硬件（T2 芯片或 Apple Silicon 的 Secure Enclave）加速实现，不支持切换为 AES-256 或其他自定义算法——这是 Apple 统一设计的安全边界，也是企业合规中被广泛接受的基准。
FileVault 加密标准的技术定位
XTS-AES 128 是 NIST 认可的块加密模式，专为磁盘加密优化：它防止重放与篡改，且每个数据扇区使用独立密钥流，避免传统 ECB 模式下的模式泄露风险。Apple 明确声明该标准“足以满足企业安全要求”，并已在金融、医疗、政府等高合规行业长期落地验证。其安全性不取决于密钥长度数字本身，而在于密钥派生方式（PBKDF2 + 用户密码 + 硬件绑定盐值）、密钥存储位置（Secure Enclave 物理隔离）以及解锁链路（登录密码 → 密钥解封 → 自动挂载）。
与主流数据加密标准的对照关系
- FIPS 140-2/3 Level 2：FileVault 本身未单独认证，但其所依赖的硬件模块（如 Secure Enclave、T2）已通过 FIPS 140-2 Level 3 认证；整套加解密路径符合 Level 2 对密钥管理、抗物理攻击和角色分离的要求。
- GDPR / HIPAA / CCPA：启用 FileVault 被视为满足“适当技术措施”（appropriate technical measures）的关键证据，尤其在设备丢失场景下可有效规避“数据泄露通知义务”。
- NIST SP 800-111：完全匹配该指南对“基于主机的全盘加密”的全部推荐项：实时加解密、用户身份绑定、恢复密钥分离、无明文密钥驻留内存。
- ISO/IEC 27001 Annex A.8.2.3：直接支撑“移动设备和可移动存储介质的数据保护”控制项，是 ISMS 审计中最常引用的 macOS 原生控制措施。
实际部署中需关注的合规落点
标准再强，落地偏差会削弱效力。真正影响合规判定的，不是“是否开了 FileVault”，而是以下三项是否闭环：
- 恢复密钥必须托管或离线存档：仅本地保存密钥纸条不算合规；Intune、Jamf 或自建密钥服务器托管才算完成密钥生命周期管理。
-
启动卷真实锁定状态需可验证：不能只看系统设置里打了勾，要用
diskutil info / | grep "Locked"确认输出为 YES，且Passphrase Required: YES。 -
非启动卷不可遗漏：FileVault 默认只加密启动宗卷；外置 SSD、Time Machine 备份盘、加密 DMG 等含敏感数据的载体，须用
diskutil apfs encryptVolume单独处理，并纳入审计范围。
性能与安全的现实平衡点
XTS-AES 128 在现代 Mac 上几乎零感知：M 系列芯片的 Secure Enclave 吞吐超 10 GB/s，远高于 NVMe SSD 实际带宽；Intel Mac（2018 后）依赖 T2 芯片，也无明显延迟。所谓“性能损耗”多源于后台首次加密过程（Converting: Yes），而非运行时加解密——这属于一次性开销，不是持续负担。安全团队无需妥协性能来换取防护，正确做法是把验证重点放在密钥管理、卷锁定状态和覆盖完整性上。
