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