SSL/TLS协议是保护应用程序、设备和通过互联网访问的机器之间连接的业务需求。这些协议需要证书通过加密和认证来保护数据的安全，以减少潜在的篡改和恶意利用。最安全的证书是由受信任的证书颁发机构(CAs)颁发和验证的，确保了认证的关键信任链。
在这篇博客中，我们将探讨自签名证书的风险，以及为什么不应该使用它们来保护你的DevOps管道。
什么是自签名证书?
- Publicly-trusted证书, 用于面向公众的web服务器和应用程序，必须由外部可信的第三方CA颁发，以安全验证域所有者。有些组织运行自己的内部PKI，并为内部网络颁发自己的私有可信SSL/TLS证书，以对设备和用户进行身份验证。
- 自签名证书没有经过公共或私有证书颁发机构的签名，因为自签名证书中的信息没有经过可信证书颁发机构的验证和身份验证，因此它们可以触发安全警报。当web浏览器和操作系统标记了未经公开可信CA签名的证书时，就会出现一个严重的问题，因为这会给用户带来安全风险。如果不通过CA进行认证，用户就无法确定证书是可信的还是由恶意行为者生成的。
为什么自签名证书对开发人员很有吸引力?
自签名证书被开发人员用于低风险的内部网络以及软件开发和测试阶段。
- 自签名证书在开发周期的所有阶段都提供了便捷性和灵活性
- 生成自签名证书可以消除验证和签名过程的长时间等待，这些过程会造成时间损失、挫折和中断
- 自签名证书不受有效期限制。相比之下，公开可信的SSL/TLS证书的有效期目前被限制在13个月
如果开发人员使用自签名证书，那么应该制定强有力的保护和访问安全策略。建立一个负责证书管理的团队，使用高效的监控工具对跟踪所有证书及其真实性至关重要。不幸的是，涉及的安全问题并不总是人们最关心的。就像影子证书会导致复杂性和不必要的风险一样，自签名证书也会导致显著的风险因素。
为什么开发者应该抵制使用自签名证书
反对自签名证书最重要的论点就是它们不可信。在内部网络之外，SSL/TLS证书需要由可信的CA签名，以获得用户信任的重要级别。通过可信的公共CA进行验证对于消除不可追踪的伪造证书、欺骗和恶意代码的危险至关重要。
使用自签名证书的风险因素
- 没有吊销过程——没有吊销过期或被篡改证书的报告机构，这为恶意利用和破坏留下了潜在的网关。
- 缺乏可见性、库存知识和控制——对于安全团队来说，很难知道有多少证书、安装位置、所有权和私钥存储细节，或者证书何时被泄露。
- 缺乏技术支持——内部生成的证书缺乏公共证书颁发机构提供的专业知识的广度、管理工具和吊销机制。
- 与安全标准的依从性和一致性差——对于满足依从性标准的法规和最佳实践的应用通常缺乏知识。
为什么在DevOps中托管PKI是一个安全且有利的选择
公钥基础设施(Public Key Infrastructure，简称PKI)是一个由策略、过程、硬件和软件组成的技术生态系统，它支持数字证书的颁发、管理、存储和撤销过程。PKI允许创建数字证书，通过数据加密、数字签名和通过可信的证书颁发机构颁发的证书来验证设备、用户和服务的身份。
对于开发人员来说，pki即服务(PKIaaS)在易用性、可扩展性、效率和信任方面是自签名证书的一个很好的替代品。
DevOps使用托管PKI的好处
托管PKIaaS提供了许多优势，包括:
- 全面的可见性，管理控制，和知识的每一个证书
- 消除了来自不可信、不可追踪的伪造证书和证书欺骗的漏洞风险
- 更快的证书签发速度
- 实现更安全的DevSecOps自动化
- 降低SSL/TLS所有权的成本
- 自动部署证书
- 包含所有操作系统和浏览器上的公开可信根目录
- 提供内部证书管理的自由
- 节省管理软件、维护、员工培训、监控和健康检查的时间和成本
GlobalSign的DevOps PKI服务可以帮助解决证书问题
GlobalSign可以通过托管、可靠和可信的CA服务克服DevOps证书的挑战。与GlobalSign合作意味着开发人员有一个单一的来源来满足所有的证书需求，让他们可以自由地专注于核心竞争力。我们的PKI专业知识确保最佳实践和审计需求得到满足，同时提供世界级的支持和服务水平协议(SLA)。
GlobalSign的PKI证书服务以具有成本效益的DevOps速度提供，同时确保证书和PKI组件符合最佳实践和法规。
GlobalSign托管了PKI功能
- 托管RFC 5280兼容的撤销服务(CRL或OCSP)，安全的离线密钥存储，托管和管理专用或共享、公共或私有客户根证书
- 通过GlobalSign的API或ACME集成提供
- 直接集成与Venafi作为一个服务和HashiCorp金库可用
- Kubernetes Certmanager通过Atlas插入
- 使用HVClient进行证书签发、续签和吊销的CLI工具
- 涵盖整个应用程序栈的证书需求
