安全工程演进：Office 2016 for Mac

安全是微软所有产品的核心组成部分。我们强调从工作伊始就注重强安全性，包括在设计过程中进行威胁建模，并考虑苹果自身对其平台上产品的安全建议。作为这一方法的示例，我想分享一些我们为保护Mac Office 2016所做的工作。

对于Mac Office 2016和Office 365订阅系统，我们保持工具系统“常青”。通过Mac Office 2016，我们每月发布更新，并在Xcode及其内部工具发布时测试并采用最新版本。我们通过广泛的自动化测试来缓解编译器变更的风险。我们拥有一个由数百台Mac Mini组成的农场，每天运行数万次基于场景的测试，并调查自动化系统报告的每一个失败或意外行为变更。

我们尽可能通过代码静态分析来增强自动化场景测试，并包括使用故意损坏的文件和数据进行的输入模糊测试，以识别代码中的不当预期。在整个Office中，我们投资于更智能的模糊测试工具，并持续运行它们。这推动了更好的数据验证，尤其是在旧代码中，并使应用程序更稳定和安全。

通过使用最新的工具链，我们从编译器改进中获得安全益处。这些更新不断带来新的代码警告；我们默认启用所有警告，并将警告视为错误。这随着每个新编译器发布提高了我们的代码质量。并非所有编译器警告都意味着安全问题，但那些确实触发错误的问题我们会立即修复。我们还在每个版本中寻找新的可选编译器安全功能（如-fstack-protector和-D_FORTIFY_SOURCE=2）并启用它们。工具链更新带来了新的macOS和iOS SDK，其中包含新API以及操作系统中被弃用或不安全API的注解。我们认真对待这些注解，并更新代码以移除后者的使用。

Xcode 7引入了一个名为地址消毒器（ASan）的新工具。该工具可以帮助识别具有潜在安全影响的错误，但它比非ASan构建需要更多内存，并且对于大型32位应用程序不实用。Mac Office 2016现在是64位的，我们每天生成一个内部ASan检测构建，并通过与常规产品相同的自动化测试运行它。自动化系统发现的任何ASan问题都会成为待调查和解决的错误报告。

我们还进行了超出新工具链或64位转换强制代码变更的安全改进。我们重新设计了Office套件，仅在必要时使用受限可执行内存页，并维护一个被认为 inherently不安全或允许不安全编码实践的API黑名单。我们定期审计代码库以确保不使用这些API。我们还启用了位置无关执行来构建应用程序。通过该标志、我们最低支持的OS 10.10，以及所有Mac Office应用程序现在都是64位的事实，macOS可以将地址空间布局随机化（ASLR）应用于我们的应用程序，作为另一层防御。

尽管对于macOS应用程序是可选的，我们也为我们的应用程序启用了macOS沙箱。选择加入沙箱为几乎我们评估的每一个威胁增加了又一个障碍，使利用更加困难。我们认为这是Mac应用程序的最佳实践。沙箱改变了应用程序与操作系统的交互方式，要求我们重新审视几个现有的Office功能，使它们符合沙箱要求，同时仍能利用完整Office套件的能力。

这些安全改进适用于我们应用程序的最新版本。我们的自动更新工具本身受益于上述几乎所有改进。每个更新包都由微软签名，并且每次下载包时都会验证该签名。我们不断改进用户体验，以减少安装更新的工作量，并使其成为自动完成的无形操作。这鼓励我们的用户始终安装最安全的应用程序版本。

将所有这些变更结合在一起，使Office 2016 for Mac成为我们迄今为止最安全的版本。我们在编译时启用更严格的编译器安全功能，构建和链接时预期ASLR在启动时将我们随机放置在内存中，审计不安全API并将其禁止在代码库之外，模糊输入以验证数据解析，禁止堆执行，选择加入macOS沙箱，在运行时使用地址消毒器寻找可能的安全漏洞，并使用户更可能拥有最新的安全更新。所有这些在可能恶意的代码面前设置了非常高的障碍，有助于保护您的应用程序、您的数据和您的Mac。

Erik Schwiebert，Mac Office首席软件工程师