直接在构建服务器上安装Authenticode代码签名证书以创建生产签名构建是否可以接受？我正在寻找网上的一些资源，建议或支持这种做法是合法的，只要您已采取适当的步骤来保护构建服务器以及构建和部署构建的过程。
我所能找到的关于代码签名实践的所有“最佳实践”指南在建议的流程方面都是最重要的。对于签署单个程序集的简单操作，Microsoft的参考文档有多达6个服务器。 http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
我的公司为其员工和直接客户创建简单的富客户端业务应用程序。我们不创建商业软件。我的构建服务器使用我公司严格的安全策略和程序进行物理安全和网络安全。只有组织中非常具体的人才能够在我的环境中开始构建。
我们当前的流程要求我将构建/部署流程分解为多个阶段，并且有很多的手动流程。我们使用物理设备存储Authenticode证书，要求用户输入的PIN才能访问。我们必须将需要代码签名的程序集/清单洗牌到指定的代码签名PC，这些PC也必须是物理安全的。
对我而言，传递物理令牌/设备并保留所有这些手动步骤的安全性较低。没有任何东西可以阻止物理访问令牌/设备的人签署任何他们想要的东西。至少，通过自动化，记录的，受控制的构建服务器环境，您可以知道签名的内容以及由谁签名。
答案 0 :(得分：2)
在构建服务器上安装证书并使其可供构建帐户访问的主要问题是，现在任何开发人员都可以通过临时将其提交给某个合法项目来签署任何恶意代码，并在之后将其还原。建立。
无论记录的操作如何，都很难识别或阻止违规行为。特别是如果开发活跃并且每天都进行多次构建。
我能想到的唯一解决方案是限制一些可以触发“RTM”构建的人。其他构建类型可能使用测试证书或完全避免签名。
事实上，这也是我烦恼的问题。