IT 服务运维中的安全管理

ITIL 是一套 ITSM 最佳实践体系，能够提高 IT 部门用户满意度和运行效率。它提供了针对 IT 活动的实践，可以被组织应用于战略、价值交付和能力维持。它允许组织建立一个基线，用于计划、实施和测量，证明合规性和衡量改进。虽然 ITIL 建立了 ITSM 的“游戏规则”，但它只告诉你最好做什么事，具体落地层面的流程实践需要根据不同的组织进行定制化和优化。

本系列 IT 运维服务管理的文章，基于我们过去在不同项目背景下总结出来的实践经验，具有运维服务管理落地指导性质。它为项目稳定运营提供奠项目运维开展计划的基础，为进一步的工程实践和持续优化奠定良好的基础，同时可以帮助运维项目中的人员完善和提升项目运维过程中的服务管理能力。

本系列文章的主题包括运维安全管理、事件管理、变更管理、应急预案、自动化效率化运维。本文为第一篇：运维中的安全管理。

在企业的 IT 服务运维管理中，安全管理是一个非常重要的问题。在产品运维过程中，不仅需要管理、维护和监控 IT 系统的可靠性，同时系统的安全性也是非常重要的。当谈到运维安全管理时，我们最容易想到的是保护敏感信息和数据安全。然而，随着信息技术的进步，敏感信息和数据安全的威胁也变得越来越复杂。

（图片来源：https://s34456.pcdn.co/wp-content/uploads/2023/07/Private-markets-640x360.jpg.webp）

想象一个场景，你所运维的系统中，有一个比较重要的服务因为安全漏洞问题需要被隔离甚至关停，这可能会引发一系列紧急举措和挑战。在现实中，我们曾经就遇到过这样的情况。由于一个重大的系统漏洞，服务器被攻击并受到了破坏。在恢复服务之后，我们又发现了应用程序中的软件包存在漏洞，必须在紧急的时间内进行修复才能重新上线。最终，我们花费了将近两天的时间才让应用程序恢复至可用状态。如果我们定期进行漏洞扫描并及时修复任何漏洞，或许就能够避免这样的情况再次发生。

再想象一个场景，你所运维的一个线上服务昨天还正常提供服务，但是今天突然所有用户都在抱怨不能用了，你查看了监控后发现系统的指标都没有问题，最终才发现居然是应用证书过期了。这样一个看似简单的问题却造成了如此大的影响，不仅仅可能涉及金钱损失，还很可能影响到公司的声誉。如果在日常运维中我们注重证书的安全管理，就不会发生这样低级的错误，从而避免无法挽回的损失。

除了上述提到的软件依赖包的安全管理和证书的安全管理，运维团队还需要考虑权限管理、 CI/CD（Continuous Integration/Continuous Delivery） 流水线（Pipeline）安全检查、个人隐私数据信息管理、Web 应用防火墙管理、威胁建模等方面。这些措施都可以有效地减少恶意攻击和数据泄漏的风险，并保护企业的业务稳定性和可持续性。

当然，在运维阶段中涉及的安全管理问题是多方面的，需要我们根据具体项目情况进行综合考虑和解决。下面我们会基于运维项目上所涉及的安全领域来具体分享运维项目上的一些安全实践。

（图片来源：https://arxall.io/news/wp-content/uploads/2022/02/access-rwr-600x400.jpg）

在运维项目中，很多场景下，我们需要与多个系统进行交互，这给我们的系统和人员带来了许多权限管理的挑战和要求。例如，我们需要确保管理员拥有足够的权限来完成必要的任务，但又不能赋予过多的权限，以避免安全风险。我们还需要确保所有操作都有明确的记录和审计，以便在发生问题时进行追踪和分析。另外，我们还需要使用适当的认证和授权措施，以防止未经授权的访问和操作。

为了满足这些要求，我们需要实施一套完整的运维权限管理方案，包括对管理员帐户、角色、权限、认证和授权、审计和监控等方面的管理。这样，我们才能确保管理员只能访问他们所需的资源，并且他们的操作都能够被准确记录和审计。此外，我们还需要定期审查和更新权限，以确保系统和数据的安全性和完整性得到保障。

在运维项目中，权限管理是保护系统和数据安全的关键环节，它不仅是技术上的问题，更是一个管理流程上的问题，所以需要管理员的合作和配合。只有全面而有效的运维权限管理方案，才能确保系统的稳定性和安全性，为企业的发展提供有力的支持。

权限管理在运维中具有非常重要的作用，它可以确保系统和数据的安全性和完整性，避免未经授权的访问和操作，同时也可以提高运维效率和降低风险。

• 保护系统和数据安全：通过运维权限管理，可以对管理员的操作进行授权和控制，避免未经授权的访问和操作，确保系统和数据的安全性和完整性。

• 降低安全风险：通过限制管理员的权限，可以避免他们误操作或恶意操作系统和数据，从而降低安全风险。

• 提高运维效率：通过权限管理，可以使管理员拥有足够的权限来完成必要的任务，从而提高运维效率。

• 精细化的权限控制：通过将管理员分配到不同的角色中，可以实现权限的精细化控制，使管理员只能访问和操作其所需的资源，从而避免权限过度赋予导致的安全问题。

• 审计和监控：通过对管理员操作的审计和监控，可以及时发现和处理安全问题，从而进一步提高系统和数据的安全性和完整性。

运维权限管理在保障系统和数据安全、降低安全风险、提高运维效率、精细化权限控制以及审计和监控等方面发挥着至关重要的作用。

• 最小权限原则：在运维过程中，应该遵循最小权限原则，即只赋予必要的权限，以最大限度地减少安全漏洞的风险。

• 群组权限：所以的策略都不应该直接分配给用户，应该分配给用户组，再把用户添加到用户组中，降低管理成本。

• 定期修改密码：所有的账户应该有一定的密码复杂度策略和定期修改密码的策略。

• 细粒度的访问控制：细粒度的访问控制可以更好地管理运维权限，例如对特定的服务器、应用程序或服务进行授权。

• 审计和监控：对所有运维操作进行审计和监控，以检测异常行为并及时采取措施。

• 多因子认证 MFA：使用多因子认证可以增加帐户的安全性，避免帐户被非法使用，即使密码被泄露也可以在一定程度上保证账户的安全。

• 定期审查权限：定期审查权限，及时删除无用的帐户和权限，防止因为人员变动导致的权安全问题。

要度量运维项目上权限管理的成熟度，可以考虑以下几个方面：

• 权限分配和授权：

• 权限准确性：衡量权限是否正确地分配给了合适的用户或角色。

• 权限完整性：评估系统中是否存在未分配或遗漏的权限。

• 权限一致性：检查权限授权是否符合组织内部的标准和规范。

• 权限审计和监测：

• 审计合规性：评估权限审计的合规性，包括审计日志的记录、保留和保护。

• 异常权限活动检测：监测和评估系统中的异常权限请求和活动，包括超出正常权限范围的请求和异常的权限使用模式。

• 权限变更管理：

• 变更记录和追踪：确保权限变更的记录和审计跟踪能力，包括变更的原因、执行者和时间戳等信息。

• 变更时效性：衡量权限变更请求的响应时间和处理效率。

• 权限撤销和失效：

• 撤销时效性：评估权限撤销的及时性和有效性，特别是在员工离职或角色变更时。

• 失效权限管理：确保不再需要的权限被及时撤销或失效，避免未经授权的访问风险。

• 权限请求和批准流程：

• 请求时效性：衡量权限请求的响应时间，确保团队成员能够及时获得适当的权限。

• 批准流程效率：评估权限批准流程的效率和准确性，包括审批者的响应时间和批准决策的一致性。

（图片来源：https://www.sectigo.com/uploads/images/Key.png）

密钥是一种在明文转换为密文或将密文转换为明文的算法中输入的参数。具体来说，密钥是一组信息编码，它参与密码的“运算”，并对密码的“运算”起特定的控制作用。

数字证书是一种可以在互联网通讯中唯一地标识身份的一个权威文件。数字证书是由证书认证机构 (以下简称 CA) 对证书申请者真实身份验证之后，用 CA 的根证书对申请人的一些基本信息以及申请人的公钥进行签名（相当于加盖发证书机构的公章）后形成的一个数字文件。可以认为，数字证书就是经过 CA 认证过的公钥，和公钥一样是公开的。

密钥的分类

一般情况下，密钥分为对称密钥与非对称密钥。

• 对称密钥

  对称密钥一般是用对称加密算法，而对称密钥加密又称私钥加密或会话密钥加密算法，即信息的发送方和接收方使用同一个密钥去加密和解密数据。它的最大优势是加/解密速度快，适合于对大数据量进行加密，但密钥的管理与分配困难。

• 非对称密钥

  使用非对称密钥的加密方式又称为公钥加密。它需要使用一对不同的密钥来分别完成加密和解密操作，一个是公开发布的公钥，另一个为用户保存的私钥。信息发送者用公钥去加密，而信息接收者则用私钥去解密。公钥加密机制灵活，但加密和解密速度却比对称密钥加密慢得多。

证书的分类

证书的种类较多，这里列举几种常见的证书分类：TLS/SSL 客户端证书，邮件证书、iOS 和安卓证书，自签名证书等等。

• TLS/SSL 客户端证书

  TLS/SSL 客户端证书是一种数字证书，基于公钥加密体系，用于在 TLS/SSL 协议中对客户端进行身份验证。它是由受信任的证书颁发机构 CA 签发的，并包含了客户端的公钥、相关身份信息以及由 CA 签名的数字签名。TLS/SSL 客户端证书用于验证客户端的身份。服务器可以通过验证客户端证书的有效性、签名和证书链，确认客户端的真实性和完整性，从而确保只有合法的客户端能够建立安全的连接。TLS/SSL 客户端证书在保障通信安全和进行双向身份验证方面发挥着重要的作用。

• 邮件证书

  S/MIME（Secure/Multipurpose Internet Mail Extensions）是一种安全电子邮件标准，它使用邮件证书来实现电子邮件的加密和身份验证。S/MIME 通过在电子邮件中添加数字签名和加密功能，提供了保护邮件机密性和完整性的安全层。通过使用 S/MIME 邮件证书，电子邮件的发件人和收件人可以实现电子邮件的身份验证、机密性和完整性验证。S/MIME 提供了一种可靠的方法，使电子邮件在传输过程中免受窃听和篡改，增强了电子邮件通信的安全性和隐私保护。

• iOS 证书

  iOS 开发者证书是一种代码签名证书，是一种将个人、个人数字身份和应用程序关联起来的数字签名。开发者可以从苹果的官方网站申请苹果开发者账号，方便 iOS 证书的申请与使用。iOS 证书主要包括：开发者证书、分发证书、推送证书。开发者证书用于验证 iOS 应用程序的开发者身份，分发证书用于验证 iOS 应用程序的发布者身份，推送证书用于实现 iOS 设备上的远程通知功能。

• 自签名证书

  自签名证书是一种发行者通过自己私钥签署的数字证书，一般由一些公司或软件开发商创建、颁发和签名。但由于证书未经过证书颁发机构签名，因此这种自签名证书通常不会被广泛信任，使用时可能会遇到电脑软件的安全警告。自签名证书特别适用于内部环境或仅用于测试目的，对于公共网络和与外部系统交互的场景，建议使用由受信任的第三方证书颁发机构 CA 签发的证书，以确保可信度和安全性。

在运维的过程中，如果我们对密钥管理不当，密钥的泄露会导致密码系统失效，信息出现泄漏，系统出现安全问题。如果没能及时检查证书的过期时间，导致证书过期，不仅使得用户的通信得不到保护，泄漏用户的安全和隐私，也会使得用户在使用服务时，出现网页无法打开等情况。这些情况在运维中都会是非常严重的生产安全事故。

在运维的过程中，密钥和证书的管理包含生成、更新、存储与备份、有效期及销毁。具体内容如下：

• 密钥生成和存储：使用安全的方法生成密钥对，并确保私钥的保密性。私钥应存储在受控的、加密的环境中，只有授权人员可以访问。

• 证书申请和签发：对于需要使用由受信任的第三方证书颁发机构 CA 签发的证书，按照 CA 的要求生成证书签名请求 CSR，并提交给 CA 进行签发。确保证书的签发过程符合安全最佳实践。

• 建立清单并监控：建立一个密钥和证书清单，记录所有系统中使用的密钥和证书的详细信息，包括类型、用途、到期日期等，并在证书到期前自动发送提醒。

• 定期轮换：定期进行密钥更新，删除和销毁过期密钥。

• 密钥和证书保护：采取适当的措施保护密钥和证书的机密性和完整性。使用加密算法保护密钥的传输和存储，并使用访问控制和权限管理措施限制对密钥和证书的访问。

针对运维团队所运维的服务，服务的证书可能是由专门的团队管理，也可能是直接托管在云服务上。针对不同的情况，有如下内容：

• 如果证书不在云上托管，而是公司有专门的团队负责：

• 建议运维初期在我们服务侧配置专门的报警，例如提前一个月发邮件通知即将到期的证书。

• 在收到通知后过期前两周联系该团队生成新的证书，并计划证书替换事项。

• 记录替换的步骤，以便在团队内部进行知识沉淀和传递。

• 如果证书是云服务自动生成和托管，例如 AWS ACM，建议开启云服务端自动更新。这样运维人员不需要有额外的工作量。

要度量运维项目上密钥和证书管理做得好不好，一般通过查看因证书密钥导致的安全事故数量作为度量准则，可以考虑以下几个方面：

• 证书的统一管理文档是否更新的及时，内容更新是否准确。

• 在定期针对事故查看与分析时，统计因证书密钥导致的事故数量，是否因证书和密钥导致了较多的事故。如果统计的数量较高，则代表团队针对证书和密钥的管理方式需要改进。

（图片来源：https://d2h1bfu6zrdxog.cloudfront.net/wp-content/uploads/2022/03/OpenSource-Security-Blog-image.png）

对于软件的代码依赖包，我们都不陌生。为了避免重复编写某个公用代码，我们都倾向于去在代码里引用软件依赖包来提高交付效率。将外部软件作为依赖包意味着我们需要信赖这个依赖包，但是这些依赖包中可能存在安全漏洞，它们还可能过时，可能存在影响应用程序性能和风险状况的错误或安全问题，从而导致我们的应用质量下降，安全性无法得到保障。因此在享用依赖包所带来的便利性的同时，我们需要去定期扫描和升级依赖包，做好安全管理，以防止任何安全漏洞趁虚而入。

关于依赖包的安全漏洞，我们往往需要特别关注和及时升级涉及 Critical 极危级别漏洞和 High 高危级别漏洞的依赖包

• Critical 极危级别漏洞意味着我们的服务或者网站随时有被黑客入侵的风险。需要将立即修复这些漏洞作为最高优先级。

• High 高危级别漏洞意味着我们的服务或网站可能被黑客入侵，并可能导致黑客找到其他影响更大的漏洞。因此也需要即修复这些类型的漏洞。

• 保证软件系统的安全性：依赖包中可能存在的安全漏洞和问题可能会被黑客利用，导致软件系统被攻击或被破坏。运维的项目中，其中有一大部分是遗留的服务，因为这些系统不需要开发新功能了，维护者往往不想在上面投入过多精力的，只想让他能工作就行，因此大家会常常忽视这些系统的网络安全问题，比如过期不维护的有安全漏洞的依赖包。只要我们不主动识别并消除来自这些的潜在威胁，就始终存在安全漏洞的可能性。如果我们能正确管理好依赖包，可以发现这些安全漏洞和问题，并及时采取措施加以修复。

• 遵循合规要求：一些行业或法规要求必须对软件代码进行安全审计和检查，以确保其符合安全标准。在运维阶段，依然做好依赖包安全管理可以帮助我们的组织遵循这些合规要求，并确保软件系统的安全性。

• 保护品牌声誉：一旦软件系统被攻击或破坏，会给我们的公司带来财务和声誉损失。运维阶段持续做好依赖包安全管理，可以发现潜在的安全风险，避免因安全问题导致的损失。

因此，在运维项目上，我们不应该忽视对软件代码依赖的管理，定期去扫描和更新依赖包，确保依赖包没有安全漏洞，直到这个服务的生命周期结束，我们都应该对这些进行负责。

• 选择合适的依赖扫描工具： 

如果当前的运维项目上没有集成，我们可以考虑根据项目所使用的编程语言和依赖库，选择适合的依赖扫描工具。依赖扫描工具的主要目的是检测和识别项目中的依赖项，以便在需要更新时通知开发人员。扫描工具可以帮助开发人员确定项目中使用的依赖项版本是否过时或具有安全漏洞，从而确保项目的安全性和稳定性。常见的依赖扫描工具包括：

* Snyk：是一个用于检测和修复开源软件中的漏洞的云扫描工具。它支持多种编程语言，包括 Java、JavaScript、Python、Ruby 等。

* OWASP Dependency Check：是一个开源的工具，可用于检测 Java、.NET、Node.js 和 Python 应用程序中的漏洞和漏洞。

* Dependency Track：是一个开源的软件组件分析平台，可以检测并跟踪应用程序中的组件漏洞和依赖关系。

* Mend：是一个用于管理开源组件和依赖关系的云扫描工具。它支持多种编程语言，包括 Java、.NET、Node.js、Python 等。

* Nexus IQ：是一个用于检测和管理应用程序依赖关系和组件漏洞的工具。它提供了一个集中式的平台，可以帮助用户分析和管理所有组件的安全和许可证问题。

• 集成依赖扫描工具： 

可以将依赖扫描工具集成到 CI/CD 工作流程中，以便在每次构建和部署时都自动运行依赖扫描工具。这可以帮助确保每个版本都经过安全审查。

• 代码仓库集成依赖升级工具并自动更新依赖包： 

依赖升级工具可以帮助开发人员和团队更轻松地管理其项目的依赖项。这些工具可以定期扫描项目的依赖项，并自动提供更新版本的建议，甚至可以自动提交更新请求和合并请求。如果在开发阶段在代码仓库没有集成依赖扫描工具，那么在运维阶段，我们应尽可能地集成这样的工具。 这里我们推荐两种和 Github 集成的工具：Dependabot 和 Renovate。它们可以轻松自动更新依赖项，提高项目的安全性和可维护性。这两个工具都能很好的跟 Github 集成，不管是有成百上千的代码仓库的大型企业还是个人的代码仓库，都可以使用这两个工具去进行定期代码依赖包扫描，并自动创建拉取请求。 对于大型项目公司，也可以创建自建的 Dependabot 和 Renovate 实例去进行依赖包的安全扫描，并且定制公司项目内部的规则。

• 了解依赖包的来源和信誉：我们运维中，难免要涉及到改代码，如果我们要引入新的开源依赖包时，应该了解其来源和信誉，并确保它们不会带来安全风险或法律问题。例如：可以查看其 Github 页面或其他社区网站来评估其质量和活跃度。

• 实行最小依赖原则：为了减少安全风险和复杂性，可以使用最小依赖原则，只引入必要的依赖包。在运维过程中，我们每次的代码改动，要小心引入不必要的依赖包，除此之外，我们也可以定期 Review 依赖包列表，及时移出不必要的依赖。这样可以尽量减少依赖包中可能存在的安全问题，同时也可以减少软件系统的复杂性。

• 限制依赖包的版本范围：限制依赖包的版本范围可以减少依赖包中可能存在的安全问题。可以使用 SemVer 规范来定义版本，并确保所有依赖包的版本都是兼容的。

• 开启安全漏洞的告警通知：这样在运维阶段可以第一时间发现项目依赖包里的 Critical 或者 High 级别的安全漏洞。

• 制定策略和流程：根据当前运维阶段的项目需要，制定适合的策略和流程，以确保依赖库的安全性得到持续的管理和审查。例如，制定规则和标准（比如大家要坚持最小依赖原则），以确保在开发新功能或更新依赖关系时遵循最佳安全实践。

要度量运维项目上软件代码依赖包的安全管理做得好不好，可以考虑以下几个方面：

• 依赖扫描覆盖率：度量依赖扫描工具扫描项目依赖的覆盖率。较高的覆盖率表示扫描工具可以发现更多的漏洞和安全问题，这有助于提高项目的安全性。

• 安全漏洞修复时间：度量漏洞修复时间，即从扫描发现漏洞到修复漏洞所需的时间。较短的漏洞修复时间意味着团队更加重视安全，并且能够快速响应漏洞。

• 安全漏洞数量：度量扫描出的安全漏洞的数量，较少的漏洞数量通常意味着项目的安全性较好。

• 依赖升级的频率和成功率：度量依赖升级的频率和成功率。较高的依赖升级频率和成功率意味着团队能够及时升级依赖以解决漏洞和安全问题。

• 安全策略的执行情况：度量团队在实践安全策略方面的执行情况，如是否定期审查代码、定期进行安全测试等。较好的安全策略执行情况可以帮助确保项目的安全性。

这些度量指标可以帮助我们了解运维项目上软件代码依赖包的安全管理做得好不好，以评估我们运维项目的安全实践和改进方向。

（图片来源：https://www.preemptive.com/wp-content/uploads/2022/06/PreEmptive-icons-10.png）

在软件行业中，CI/CD 流水线是加速软件开发和集成、快速上线产品的关键工具。然而，在 CI/CD 流水线的自动化过程中，安全问题往往容易被忽视，CI/CD 流水线的安全对于确保整个软件系统的安全和可靠性至关重要。CI/CD 流水线安全管理涉及到的方面众多，包括但不限于：

• 对 CI/CD 系统本身的安全检查

• 对 CI/CD 流水线操作权限的检查

• 对 CI/CD 流水线的执行日志安全检查

• 对生成产物（Artifacts）的安全检查

• 对程序代码的检查

• 对第三方依赖的检查

• 对容器镜像的检查

• 对部署环境的检查等

在运维项目中，CI/CD 流水线安全管理至关重要。由于它涉及到公司业务的正常运行以及用户数据的安全，因此对 CI/CD 流水线进行安全管理可以确保整个 CI/CD 过程的可靠性和安全，并为维护软件系统的稳定性和企业的口碑提供保障。具体来说，CI/CD 流水线安全管理在运维中能发挥以下作用：

• 帮助防止潜在的安全漏洞：CI/CD 流水线安全检查可以帮助开发团队发现可能存在的安全漏洞，并及时修复，从而减少黑客攻击和数据泄露等安全问题的风险。

• 帮助确保整个 CI/CD 过程的安全：CI/CD 流水线安全检查可以确保 CI/CD 系统本身的安全，包括对流水线操作权限的检查、对程序代码的检查、对第三方依赖的检查、对容器镜像的检查、对部署环境的检查等，从而确保整个 CI/CD 过程的安全。

• 提高安全意识：CI/CD 流水线安全检查可以帮助开发团队了解软件安全的重要性，并提高安全意识，从而有助于改善整个组织的安全文化。

• CI/CD 系统的安全除第三方所提供的 CI/CD 系统外，对于自建的 CI/CD 系统和它所真正执行任务的 Agent/Runner（构建、部署任务执行程序）我们都需要确保它自身的安全。在允许的前提下，确保使用的 CI/CD 及其 Agent 所在的操作系统是最新版本，且已安装最新的安全补丁，以防止已知的漏洞被利用。在大型公司中对于操作系统的安全性一般有安全团队专门负责。

  对于 CI/CD 服务器系统本身我们需要做到的有：

• 定期更新系统所使用的插件和组件，例如：Jenkins 中的各类第三方插件。

• 对于报出的安全漏洞需要及时做出响应和修复，例如 2023 年初发生的 CircleCI secrets 泄漏事件。

• 确保其使用了 TLS 加密，避免中间人攻击窃取访问权限。

• 对 CI/CD 系统及其数据定期进行备份，做好灾难恢复计划。

  对于 Agent（构建、部署任务执行程序）我们需要做到的有：

• 及时更新 Agent 的系统镜像和依赖，以确保安全和可靠性。

• 对 Agent 所能访问的网络进行限制，以防止未经授权的访问和数据泄露。

• 坚持最小权限原则，尽量不使用 root 用户运行 Agent。

• 给各个项目使用专属的 Agent，避免来自其他项目的未授权操作。

• CI/CD 流水线访问控制

  流水线中未授权的部署操作会影响线上系统的稳定性，攻击者也可以通过流水线的部署操作将线上版本替换为老版本而制造漏洞。部分流水线可能可以直接下载项目所构建的中间产物或是项目编译后的二进制文件，被未授权的人员获取可能会有安全风险。由此可见，对流水线访问权限的检查尤为重要。我们需要确保项目的流水线只能由团队成员所访问，并要求团队成员启用多因子验证 MFA 提高安全性。对于存储在 CI/CD 系统中的密钥，我们需要及时的了解是否已对其进行了加密，这样有利于避免其他人获取敏感信息。

• 编写安全的 CI/CD 流水线代码

  虽然很多场景下我们运维团队所维护的都是一些老的服务或系统，但我们在运维过程中可能会对现有的 CI/CD 流水线进行一些修改加固。在编写流水线代码时，我们应该注意的点有：

• 不使用未经授权的库和组件。

• 不使用硬编码的密码和敏感信息。

• 不将敏感信息输出在流水线日志中。

• 不将生产数据作为流水线的测试输入。

在常见的 CI/CD 流水线中也应该包含以下步骤：

* 对源代码进行扫描：源代码可能存在 SQL 注入、跨站攻击、内存溢出等常见安全漏洞，因此可以使用 SonarQube 等工具进行扫描，以控制源代码的质量。

* 对依赖版本进行扫描：依赖库的版本可能存在安全漏洞，因此需要扫描依赖库的版本，并及时升级版本以获得最新的安全修复。

* 对基础容器镜像的扫描：容器镜像中可能存在弱密码访问权限、不安全的软件包或内嵌远程控制程序等问题，因此扫描基础容器镜像也很重要，以此避免此类供应链攻击。

要度量运维项目上 CI/CD 流水线是否安全，可以考虑以下几个方面：

• 漏洞发现和修复速度：好的流水线应该能够及时发现漏洞和及时更新和修复系统级别的漏洞，以最小化安全漏洞带来的风险。

• 访问控制的完整性：好的流水线应该遵守最小权限原则，能够避免未经授权的访问和数据泄露，提高整个系统的安全性。

• 代码质量的合规性：好的流水线应该能及时通过自动化工具发现硬编码的密码和敏感信息，确保高质量的代码，符合安全标准和最佳实践。

（图片来源：https://www.cyberark.com/wp-content/uploads/2020/04/Laptop-with-Fingerprint-Icon-scaled.jpg）

个人身份信息（Personal Identifiable Information，后文简称 PII）是指单独使用或与其他相关数据一起使用时可以识别个人身份的信息。

PII 按照识别类型可以分为：

• 唯一识别一个人的直接标识符（例如，护照号码，身份证号码，社会安全号码等）。

• 与其他准标识符组合以成功识别一个人的准标识符（例如，姓名，出生日期，种族，宗教信仰等）。

PII 按照敏感类型可以分为：

• 敏感的标识符（身份证号码，社会安全号码 SSN、驾照号码、财务信息和医疗记录等）。

• 非敏感的标识符（邮政编码、种族、性别和出生日期等）。

在运维的过程中，工程师和支持团队经常需要排查线上的问题，不可避免的需要查看系统日志，服务日志，数据库数据等信息。而这些信息中经常会出现 PII，这使得 PII 很容易泄漏，而 PII 的泄露可能会违反当地的法律，也可能被黑客利用，给用户带来潜在的威胁。

要度量运维项目个人隐私数据的管理做得好不好，可以考虑以下几个方面：

• 根据公司或项目上记录的 PII 泄露事故数量作为我们度量运维团队是否做好了 PII 保护的一个指标。

• 当发现 PII 泄露之后，团队的应对和处理措施更能反映出大家的信息安全的意识，因此这一点也是一个重要的度量指标。

（图片来源：https://www.guidepointsecurity.com/wp-content/uploads/2020/09/service-icon-threat-model.svg）

威胁建模是一种结构化的分析和解决安全问题的方法，用来识别、量化威胁，并且有助于思考如何应对威胁。在公司的安全部门一般会每年定期开展威胁建模活动，除此之外，威胁建模还会发生在项目前期，以及每当业务或者技术有较大变更的时候开展。

在运维的过程中，威胁建模可以为运维团队提供清晰的安全视野，最大限度的预防生产的安全事故。尤其是在运维团队刚入场接手项目时，威胁建模有助于团队梳理清楚所有安全方面的威胁，及时去发现和修复已有的安全威胁。比如说通过威胁建模明确人员的权限，最大防止数据库、服务器被不应该接触权限的人误删除或者恶意删除等。

• 确定运维项目威胁建模的时间

• 运维团队从其他团队（交付团队或者此前的运维团队）开始接收项目的运维工作时。

• 在运维过程中发生重大变更时，比如项目架构的调整，引入新的组件等。

• 运维过程中有新的发现时。（交付时上一个团队没有告知到的或者因为某些原因交接团队也不是很清楚，交接时间短暂，没有能在交接时，对项目有完整的、彻底的认知）。

• 团队可以也可以定期去开展威胁建模。

• 准备最新的、准确的架构图和数据流图

  运维项目即意味着项目主要功能已经完成并且已经在线上运行，那么也就意味着在这个时刻，项目的架构、数据流都已经固定下来。但是每个项目实际产出的各有差异，将有三种情况：

  第一种情况，那么运维团队只需要简单验证架构图和数据流图的准确性即可。

  第二种情况，则需要结合代码、现存文档以及过期的架构图重新完成最新的、准确的架构图和数据流图的绘制。出现第二种情况的原因有很多，比较常见的是在某个时刻退役了某些功能但是并没有删除代码，或者是第三方服务发生了改变，但并没有及时更新架构图等。

  第三种情况，在文档严重缺失的情况下，只能通过阅读代码的方式来重新绘制。

• 项目有最新的、准确的架构图和数据流图。

• 项目的架构图和数据流图过期，不一定准确。

• 由于某些原因没有架构图和数据流图。

• 根据 STRIDE 识别图中每一个元素的威胁：团队成员分别扮演不同的角色，包括从用户、开发人员、运维人员、竞争者以及黑客组织。从他们的行为习惯或者目的出发，以 STRIDE 为攻击的角度去思考如果你是这类用户，你会怎么做威胁系统安全的事情。

• Spoofing 欺骗

• Tampering 篡改

• Repudiation 否认、抵赖

• Information disclosure 信息泄露

• Deny of service 拒绝服务

• Elevation of privilege 特权提升

• 根据 DREAD 对威胁进行风险评估：对第二步识别出来的风险从以下几个纬度进行打分，确定风险等级。

• Damage potential 潜在损失

• Reproducibility 重现性

• Exploitability 利用难度

• Affected users 受影响用户数量

• Discoverability 是否容易被发现

• 设置应对措施：风险评估完成后，团队便会获取到一个按照优先级排序的风险列表 。那么这一步就需要按照优先级制定相关的措施 。例如在做完某次威胁建模后发现有SQL 注入威胁和发现有用户权限提升为管理员权限。那么此时根据这两种威胁带来的影响排出优先级，并且制定相对应的措施（如下表）：

要度量运维项目上威胁建模做得好不好，可以考虑以下几个方面：

• 团队是否有基于运维项目时间（新的交接，重大变更，新的发现）进行威胁建模。

• 每一次进行威胁建模后生成的措施是否都完成。

• 团队是否及时对数据流图进行了更新，并根据新的数据流图更新来完成威胁建模。

（图片来源：https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcTEe9BAIoNTetWZ7EJgxbd99eXdXOoLza26MqwnTiwoZ8fOi-52）

Web 应用程序防火墙（后文简称 WAF），通过过滤和监控 Web 应用程序与互联网之间的 HTTP 流量来帮助保护 Web 应用程序。它是一种反向代理，引导客户端通过 WAF 到达服务器，从而防止暴露服务器。WAF 可以快速简便地修改规则，因而可以更迅速地响应不同的攻击手段。例如，当发生拒绝服务攻击（DDoS） 攻击时，可通过修改 WAF 规则快速实施速率限制。

WAF 和普通防火墙的区别

WAF 和普通网络防火墙之间的关键技术区别在于 WAF 保护 OSI 模型第 7 层应用层的攻击。而网络防火墙在 OSI 模型第 3 层网络层和第 4 层传输层运行，保护数据传输和网络流量。WAF 位于外部用户和 Web 应用程序之间，用于分析所有 HTTP 通信。然后，它会在恶意请求到达用户或 Web 应用程序之前检测并阻止它们。网络防火墙主要目标是将安全区域与不太安全的区域分开，并控制两者之间的通信。

WAF 保护着网站的应用程序，在网站的安全维护上扮演着重要角色。从实际运维经验中，我们发现许多网站在搭建完成后就由不同人管理，这样会造成网站上存着不同程序员的管理风格，一旦疏于管理或是在缺失上下文的情况下依循不同逻辑扩增网站的架构，在新旧架构并存、语法混乱的状态下，网站其实很容易就会出现安全漏洞，但团队往往不自知而让黑客有机可趁，因此就会需要 WAF 为网站筑起防护墙，保障网站安全。

• 准备工作

  首先对需接入 WAF 进行防护的网站的业务情况进行全面梳理，帮助我们了解当前业务状况和具体数据，为后续配置 WAF 的防护策略提供依据。主要梳理的内容包括：

• 网站/应用业务每天的流量峰值情况，包括 Mbps、QPS。

• 业务的主要用户群体（例如，访问用户的主要来源地区）。

• 明确架构，是否有 App 端、Windows 端、Linux 端、代码回调或其他环境的客户端。

• 源站服务器的网络配置和业务端口。

• 源站服务器的请求处理性能，判断需要的 DDoS 防护规格。

• 实现

• 硬件 WAF 串行或旁路部署在网络上，通过网页界面进行管理和规则配置，价格较高，但部署方便，运维管理比较省心。

• 软件 WAF 以 ModSecurity、Naxsi、Wazuh 等免费开源软件为代表，部署在每一台 Web 服务器上，需要网络安全人员熟悉其配置规则，但服务器数量多了之后，这种模式安装的软件，维护管理很快就会变得不太方便，因为不同的服务器可能使用不同的规则。

• 以各类云加速 + CDN 类产品为代表，如国外的 CloudFlare、国内的各种云加速等，对用户隐藏真实服务器地址，云 WAF 作为反向代理执行安全控制，是用户浏览器和真实服务器之间的中间人。但要注意对于涉及商业秘密等场景，要谨慎选择。

• 对于自研发的方式，目前 Nginx 配合 Lua 搭建简易的黑名单式 WAF 较为常见。

• 产品选择：

  目前 WAF 的产品形态主要有硬件 WAF、软件 WAF、云 WAF 服务和自研发方式，我们可以项目的实际情况，去选择一款合适的进行部署：

• 策略配置

  根据应用程序的需求，配置 WAF 策略，包括白名单、黑名单、访问控制规则、SQL 注入防御、跨站点脚本 XSS 防御等。

• 性能测试

  在部署完 WAF 之后，比较容易忽视一点的是，我们需要对其进行性能测试。与服务的性能测试相同，旨在确保 WAF 的加入不会影响服务正常的性能指标。

• 日志监控

  有了 WAF 之后，最重要的一点是要进行数据的采集，监控和智能拦截。将 WAF 的日志和性能指标与现有日志监控系统集成，便于时刻监控 WAF 状态，定期检查 WAF 的日志，监控应用程序的安全状况，发现异常行为需要告警并采取必要的措施，以及及时升级和修复 WAF。

要度量运维项目上 WAF 的效果，可以先进行威胁建模，根据可能会受到的攻击，制定 WAF 的测试方案。主要可能包含以下方面：

• 模拟黑客攻击看是否阻断生效。

• 模拟灾难发生（WAF 宕机或网络波动等）看是否切换备用 WAF 正常工作。

• 若无备用 WAF，服务是否能正常访问到源服务器。

• 模拟大流量并发看是否 WAF 能抗压正常工作。

• WAF 是否支持调整策略。

这些度量指标可以帮助我们了解 WAF 功能是否正常，帮助我们运维项目的安全实践和改进方向。

当谈到运维中安全管理时，我们不仅仅在维护和管理IT系统，更是在守护企业的核心利益。无论是保护敏感信息免受黑客威胁，还是确保系统的连续可用性，安全管理都不容忽视。通过对权限控制，密钥和证书的妥善管理，代码依赖的安全管理，CICD 流水线的安全检查，敏感信息的保护，以及建立有效的 Web 应用防火墙和及时进行威胁建模，我们可以建立起一道坚固的安全屏障，以抵御各种内外部风险。

然而，安全管理不仅仅是一项任务，更是一种文化。它需要贯穿于运维的始终，贯彻于每个细节。通过在运维阶段进行全面的安全管理，能够确保业务的可持续性，维护客户的信任，以帮助我们在竞争激烈的市场中脱颖而出。因此，我们应始终牢记，在运维中，安全是不可或缺的基石。