IT 服务运维中的安全管理

发布时间：2025-11-05 09:02:49 来源：技术快报 作者：人工智能

作者 | 赵佩

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

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

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

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

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

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

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

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

一、权限管理

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

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

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

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

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

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

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

(1) 权限分配和授权：

(2) 权限审计和监测：

(3) 权限变更管理：

(4) 权限撤销和失效：

(5) 权限请求和批准流程：

二、密钥和证书管理

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

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

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

(1) 密钥的分类

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

(2) 证书的分类

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

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

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

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

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

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

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

三、代码依赖安全管理

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

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

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

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

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

(1) 选择合适的依赖扫描工具： 

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

(2) 集成依赖扫描工具： 

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

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

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

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

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

四、CI/CD（Continuous Integration/Continuous Delivery） 流水线（Pipeline）的安全管理

（图片来源：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 过程的可靠性和安全，并为维护软件系统的稳定性和企业的口碑提供保障。具体来说，CI/CD 流水线安全管理在运维中能发挥以下作用：

(1) CI/CD 系统的安全

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

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

对 CI/CD 系统及其数据定期进行备份，做好灾难恢复计划。对于 Agent（构建、部署任务执行程序）我们需要做到的有：

(2) CI/CD 流水线访问控制

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

(3) 编写安全的 CI/CD 流水线代码

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

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

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

五、个人隐私数据管理

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

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

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

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

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

根据公司所在国家的法律和公司本身的业务，定义出 PII 的列表。

在运维的初始阶段，需要依据 PII 列表识别项目中的 PII 并进行隐藏。 因为日志中的 PII 的数据有时候对排查问题时非常重要，所以在隐藏 PII 的时候，可以采取部分隐藏的策略，既可以达到隐藏 PII 的目的，又可以使用部分 PII 数据对问题进行调查。

在开发产品功能时，避免暴露或者输出任何 PII 。在运维过程中，如果发现 PII，也需要及时的隐藏。

在日常运维开发中，设立项目中的 PII 检查规则，并且及时和团队进行同步：

(1) 代码中的 PII 

不能使用真实用户的 PII 数据作为测试数据提交到代码仓库，因为一般情况下，代码的读取权限是被很多人拥有的，这样很容易泄漏 PII。

(2) 数据库中的 PII1

(3) 日志中的 PII

在代码中隐藏日志输出的 PII，日志系统是我们定位问题使用最多的工具，支持团队或者开发人员大多都有查看日志的权限，因此隐藏日志中的 PII 十分重要。我们可以在 Pipeline 中配置检查 PII 日志的插件，并配置告警，便于我们及时发现。

在运维过程中如果有新需求进行产品功能开发时，避免暴露 PII：

发现 PII 相关的泄露问题及时通知公司的安全部门，采取相应的措施。

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

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

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

六、威胁建模

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

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

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

(1) 确定运维项目威胁建模的时间

(2) 准备最新的、准确的架构图和数据流图

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

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

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

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

(3) 根据 STRIDE 识别图中每一个元素的威胁

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

(4) 根据 DREAD 对威胁进行风险评估

对第二步识别出来的风险从以下几个纬度进行打分，确定风险等级。

(5) 设置应对措施

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

威胁

措施

SQL 注入威胁（高风险）

更改相关 SQL，并且让 DBA 团队进行评审

用户权限提升为管理员权限（中风险）

由运维人员收回用户的管理员权限

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

七、Web 应用防火墙

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

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

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

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

(1) 准备工作

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

(2) 实现

(3) 产品选择

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

(4) 策略配置

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

(5) 性能测试

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

(6) 日志监控

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

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

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

八、总结

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

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

相关文章