十大 CI/CD 安全风险（四）
在上一篇文章，我们着重介绍 PPE 风险，并提供缓解相关风险的安全建议与实践。在本篇文章中，我们将会了解凭据使用环境管理不善与不安全的系统配置，并给出相应的风险缓解建议。
凭据使用管理不善
由于与凭据周围的访问控制、不安全的秘密管理和过于宽松的凭据有关的缺陷，凭据环境管理不善会给攻击者提供获取和使用散布在整个流水线中的各种秘密和令牌的能力的机会。
风险描述
CI/CD 环境由多个相互通信和身份验证的系统构建而成，由于凭据可能存在的多种上下文，因此在保护凭据方面有不小的挑战。应用程序在运行时使用应用程序凭据，流水线使用生产系统的凭据将基础架构、工件和应用程序部署到生产环境，开发人员将凭据用作其测试环境的一部分以及代码和工件中的一部分。
这种不同的上下文，以及用于存储和使用它们的大量方法和技术，为凭据的不安全使用创造了机会。影响凭据环境安全的一些主要风险在于：
-
包含凭据的代码被推送到 SCM 存储库的其中一个分支：由于没能发现代码中包含的敏感信息，或未能了解相关风险，将包含凭据的代码推送到 SCM 存储库的分支。凭据会暴露给对存储库具有读取权限的任何人，即使从推送到的分支中删除，信息也会继续出现在提交历史记录中，任何具有存储库访问权限的人都可以查看。
-
在构建和部署过程中不安全地使用凭据：这些凭据用于访问代码存储库、读取和写入工件存储库，以及将资源和工件部署到生产环境。鉴于开发人员需要访问大量的流水线和目标系统，必须明确以下几个问题：
-
在哪种情况下，使用哪种方法，使用了什么凭据？
-
每个流水线能否仅访问所需的凭据？
-
流经流水线的未经审查的代码可以访问凭据吗？
-
这些凭据如何被调用并注入到构建中？这些凭据是否只能在运行时访问，并且只能从需要它们的上下文中访问？
-
容器镜像层中的凭据：仅用于构建镜像的凭据仍然存在于其中一个镜像层中，任何能够下载镜像的人都可以使用。
-
传输到控制台输出的凭据：流水线中使用的凭据通常有意或无意地打印到控制台输出。这可能会使凭据以明文形式在日志中公开，任何有权访问构建结果的人都可以查看。这些日志可能会流入日志管理系统，从而扩大其暴露面。
-
未轮换凭据：由于凭据遍布整个工程生态系统，因此这些凭据暴露给大量员工和承包商。未能轮换凭据会导致拥有有效凭据的人员和工件数量不断增加。对于流水线使用的凭据，如果企业秉持“未损坏就不修复”的理念进行管理，那么未轮换的凭据则会长期有效，安全风险也会随着拥有有效凭据人员的数量增加而增加。
影响
凭据是攻击者最常利用的工具，攻击者试图将凭据用于访问高价值资源或部署恶意代码和工件。而在凭据管理不善的开发环境中，攻击者获得了多种获取凭据的途径。最大的风险还是人为因素，由于缺乏安全管理凭据相关知识以及对凭据轮换可能影响流程的担忧，使得凭据暴露于风险中，让许多企业的高价值资源面临因凭据暴露而受到损害的风险。
建议
-
从代码到部署，建议建立程序来持续映射软件开发生态系统中不同系统中发现的凭据。确保每组凭据都遵循最小权限原则，确保所需权限被精准授予到相关服务的使用。
-
避免在多个上下文中共享同一组凭据。这增加了实现最小特权原则的复杂性，并对问责制产生负面影响。
-
建议使用临时凭据，减少使用静态凭据。如果需要使用静态凭据，建议建立定期轮换所有静态凭据并检测陈旧的凭据的相关程序。
-
将凭据的使用配置为仅限于预定条件（例如限定特定源 IP 或身份），以确保即使在受到破坏的情况下，泄露的凭据也不能在您的环境之外使用。
-
检测推送到代码存储库并存储在其中的密钥。使用诸如 IDE 插件之类的控件来识别本地更改中使用的密钥、每次代码推送时的自动扫描以及对存储库及其过去提交的定期扫描。
-
确保 CI/CD 系统中使用的机密以允许每个流水线和步骤仅访问其需要的机密的方式限定范围。
-
使用内置的供应商选项或第三方工具来防止机密被传送到未来构建的控制台输出。确保所有现有输出不包含机密。
-
验证是否从任何类型的工件（例如容器镜像、二进制文件或 Helm Chart的层）中删除了机密。
不安全的系统配置
不安全的系统配置风险源于流水线中不同系统（例如 SCM、CI、Artifact 存储库）的安全设置、配置和加固方面的缺陷，这类风险往往扩大了企业的攻击面，给攻击者可趁之机。
风险描述
CI/CD 环境由多个供应商提供的多种系统组成。为了优化 CI/CD 安全性，企业及其开发团队需要高度重视流经流水线的代码和工件，以及每个单独系统的状态和弹性。与存储和处理数据的其他系统类似，CI/CD 系统涉及所有级别的各种安全设置和配置——应用程序、网络和基础设施，这些设置对 CI/CD 环境的安全状况和潜在危害的敏感性有重大影响。攻击者总是在寻找潜在的 CI/CD 漏洞和错误配置，这些漏洞和错误配置可以用来为他们谋取利益，比如：
-
使用过时版本或缺少重要安全补丁的自我管理系统和/或组件。
-
具有过于宽松的网络访问控制的系统。
-
对底层操作系统具有管理权限的自托管系统。
-
具有不安全系统配置的系统。配置通常确定与授权、访问控制、日志记录等有关的关键安全功能。在许多情况下，默认配置集并不安全，需要优化。
-
凭据环境管理不当的系统——例如未禁用的默认凭据、过于宽松的编程令牌等等。
-
虽然使用 SaaS CI/CD 解决方案消除了与系统强化和网络内横向移动相关的一些潜在风险，但组织仍需要高度关注并安全配置其 SaaS CI/CD 解决方案。每个解决方案都有自己的一套独特的安全配置和最佳实践，这对于保持最佳安全状态至关重要。
影响
攻击者可能会利用其中一个 CI/CD 系统中的安全漏洞来获得对系统的未经授权的访问，甚至破坏系统并访问底层操作系统。攻击者可能会滥用这些漏洞来操纵合法的 CI/CD 流程、获取机密令牌并可能访问生产环境。在某些情况下，这些缺陷可能会让攻击者有机会在开发环境内和 CI/CD 系统的上下文之外横向移动。
建议
-
维护正在使用的系统和版本的清单，包括每个系统的指定所有者对应的映射图。持续检查这些组件中的已知漏洞。如果有可用的安全补丁，请更新易受攻击的组件。如果没有，应当考虑移除组件/系统，或通过限制对系统的访问或系统执行敏感操作的能力来减少利用漏洞的潜在影响。
-
确保对系统的网络访问符合最小访问原则。
-
建立安全检查流程，来定期检查所有系统配置中可能影响系统安全状况的任何设置，并确保所有设置都是最佳的。
-
确保按照最小权限原则授予流水线执行节点的权限。在这种情况下，一个常见的错误配置是向开发人员授予执行节点上的调试权限。虽然在许多组织中这是一种常见做法，但必须考虑到任何能够在调试模式下访问执行节点的用户，都可能在将所有机密加载到内存并使用节点身份时暴露所有敏感信息。因此请谨慎为拥有此类权限的开发人员升级权限。
下一篇文章为本系列文章的最后一篇，我们将了解第三方服务的监管不足，工件完整性验证及日志可见性不足这三个 CI/CD 安全风险及缓解相应风险的建议与措施。
