Deployment 直接在生成服务器上安装Authenticode代码签名证书以创建生产签名的生成是否可以接受？

直接在生成服务器上安装Authenticode代码签名证书以创建生产签名的生成是否可以接受？我正在网上寻找一些资源，这些资源建议或支持这种做法是合法的，前提是您已经采取适当的步骤来保护构建服务器以及创建和部署构建的过程

我所能找到的关于代码签名实践的所有“最佳实践”指南在建议的流程方面都远远超出了顶部。Microsoft的参考文档中有多达6台服务器，用于签署单个程序集的简单操作

一些背景： 我的公司为其员工和直接客户创建简单的富客户端业务线应用程序。我们不创造商业软件。我的构建服务器使用我的公司严格的安全策略和程序进行物理安全和网络安全保护。组织中只有非常特定的人员才有能力在我的环境中开始构建

我们当前的流程要求我将构建/部署流程分解为多个阶段，并准备大量的手动流程。我们使用物理设备存储Authenticode证书，需要用户输入PIN才能访问。我们必须将需要代码签名的程序集/清单重新排列到指定的代码签名PC，这些PC也必须进行物理保护

---

对我来说，传递物理令牌/设备并保留所有这些手动步骤是不安全的。没有任何东西可以阻止具有令牌/设备物理访问权限的人签署他们想要的任何东西。至少，在一个自动、记录、控制的生成服务器环境中，您知道什么是由谁签署的。

在生成服务器上安装证书并使其可供生成帐户访问的主要问题是，现在任何开发人员都可以通过将恶意代码临时提交给某个合法项目来签署它，并在生成后将其还原回来

无论记录了哪些操作，都很难识别或防止违规行为。尤其是当开发处于活动状态并且每天都要完成几个构建时

我能想到的唯一解决方案是限制能够触发“RTM”构建的人数。其他生成类型可能使用测试证书或根本避免签名

---

事实上，这也是我头疼的问题。

Adobe的代码签名证书来自一个被破坏的构建服务器引起了更多的怀疑。事实上，他们自己的问题明确地说，他们的构建服务器没有访问私钥信息的权限。声明：“受损的构建服务器除了能够向代码签名服务发出代码签名请求外，没有任何公钥基础设施（PKI）功能的权限。”我不确定这是否会对我的查询产生任何疑问。这完全是一场风险与回报的空壳游戏。谢天谢地，我认为自己是一个低价值的目标。是的，证书没有被盗。但故事表明，当构建服务器以无人值守模式提供相同的服务时，不需要费心去窃取它。而且比任何HSM都不安全。