Last modified by superadmin on 2026/02/20, 07:01
Hide last authors
superadmin 1.1 1 很多组织谈信息安全，第一反应是“合规”。
2
3
4 合规当然重要，但把安全做成合规作业，最终常常会出现一种悖论：流程越来越多，审批越来越慢，大家越来越想绕开；真正出事故时，依然手忙脚乱。 安全在纸面上很强，落地时却很脆。
5
6
7 更现实的问题是，数字产品与数字服务的节奏越来越快。 变更实施频繁、发布节奏更密、供应商依赖更深、数据流动更复杂。 安全如果还停留在“最后一道关卡”，要么拖垮交付速度，要么被一线绕过。 两种结局都不好。
8
9
10 ITIL 第5版把管理对象扩展到数字产品与数字服务，用八个阶段活动覆盖全生命周期，并强调治理、问责与可审计性。 放到信息安全管理实践上，它的方向很清楚：安全不能只靠流程卡口，而要在速度与风险之间建立可执行的边界，把信息安全控制变成交付能力的一部分。 安全做得越好，交付反而越稳；安全做得越前置，速度反而越可持续。
11
12
13 == 一、为什么第5版更强调安全的“可执行边界” ==
14
15
16 ITIL 第5版相对 ITIL 4 的核心升级要点包括：
17
18 • 管理对象从服务扩展到数字产品与数字服务
19
20 • 八个阶段活动贯穿全生命周期：发现、设计、获取、构建、转换、运营、交付、支持
21
22 • 体验被写入价值定义，信任本身就是体验
23
24 • 治理强调授权、问责与可审计性
25
26 • 自动化与人工智能纳入体系，变化更快、依赖更深
27
28 安全的本质就是信任。 体验越强调信任，安全越不能只靠“说我合规”。 同时，自动化越强，越需要清晰授权和可审计性，否则一次误配置就可能引发严重后果。 第5版强调治理边界，就是在给安全落地提供抓手：让组织知道什么能做、什么不能做、什么需要更强控制、什么可以自动化放行。
29
30
31 == 二、安全做不下去的根因：边界不清，责任不清，证据链不清 ==
32
33
34 信息安全经常被抱怨“卡人”，但如果往深处看，最根本的问题通常不是安全要求高，而是三件事不清楚：
35
36 **• 边界不清**
37
38 哪些数据是高敏感，哪些操作是高风险，哪些场景必须强控制，哪些场景可以走标准路径。 边界不清，安全就只能一刀切，一刀切就必然拖慢。
39
40 **• 责任不清**
41
42 谁批准、谁执行、谁承担后果。 责任不清，一线就会绕开，绕开就会失控。
43
44 **• 证据链不清**
45
46 出了问题，无法快速追溯：谁改了什么、依据是什么、当时如何评估风险。 证据链不清，问责就会情绪化，最终形成更大的对抗。
47
48 ITIL 第5版强调授权、问责与可审计性，就是在把这三件事补齐。
49
50
51 == 三、把安全嵌入八个阶段活动：别等到上线前才想起安全 ==
52
53
54 安全如果只在转换阶段出现，结局往往是两难：要么延期，要么冒险。 更成熟的做法，是把信息安全控制嵌入八个阶段活动，让安全在每个阶段都成为“顺路动作”。
55
56
superadmin 4.1 57
58 (% style="text-align:center" %)
59 [[image:24aedefb-807d-4428-a4dd-4896fcd694f9.jpg||height="106" width="455"]]
60
61
superadmin 1.1 62 **发现：明确数据与风险的业务后果**
63
64 • 哪些业务关键数字产品承载关键业务功能
65
66 • 哪些数据一旦泄露或篡改会造成不可承受后果
67
68 • 风险偏好是什么，哪些风险必须提前规避
69
70
71 **设计：把安全当作设计约束，而不是验收时补丁**
72
73 • 身份与权限策略如何设计
74
75 • 日志与审计记录如何设计，保证可追溯
76
77 • 网络与隔离如何设计，减少横向移动风险
78
79 • 关键依赖如何评估，避免单点与供应链风险
80
81
82 **获取：把供应商安全纳入管理**
83
84 • 托管服务提供商、云服务提供商的安全能力与责任边界
85
86 • 合同条款是否明确安全责任、响应时间与通报机制
87
88 • 供应商变更是否纳入组织的变更日程与风险评估
89
90
91 **构建：让安全控制自动化并可验证**
92
93 • 关键配置基线是否自动校验
94
95 • 权限申请与审批是否可追溯
96
97 • 安全测试与漏洞扫描是否成为标准步骤
98
99 • 关键日志是否默认开启并集中管理
100
101
102 **转换：用就绪度检查守住上线边界**
103
104 • 上线前是否完成关键风险评估
105
106 • 关键权限是否经过授权并留痕
107
108 • 审计日志是否可用，监控与告警是否就绪
109
110 • 回滚与降级是否考虑安全影响
111
112
113 **运营、交付与支持：把安全响应与服务管理联动**
114
115 • 事件响应与重大事件机制是否覆盖安全事件
116
117 • 支持团队是否有清晰升级路径与口径
118
119 • 持续改进是否能把安全缺口变成可落地的改进举措
120
121 安全嵌入后，交付速度不会被拖垮，反而会更稳，因为返工和紧急补洞会少很多。
122
123
124 == 四、授权与审批要“分层”：安全的目标是控制风险，不是控制所有人 ==
125
126
127 安全最怕一刀切审批。 审批越多，绕开越多；绕开越多，风险越大。 更成熟的安全治理通常会做分层：
128
129 • 低风险操作走标准路径，尽量自动化
130
131 • 中风险操作需要明确批准人和时限，审批口径要统一
132
133 • 高风险操作需要更强控制、演练与审计，必须有清晰授权与回退方案
134
135 分层的关键不是复杂，而是让边界可执行。 边界可执行，安全才能真正落地，而不是靠喊口号。
136
137
138 == 五、可审计性不是负担，是效率 ==
139
140
141 很多人觉得审计记录麻烦，其实可审计性最大的价值是效率：
142
143 • 出问题时能快速定位责任链，避免扯皮
144
145 • 复盘时有证据链，改进更精准
146
147 • 合规检查更轻松，不需要临时补材料
148
149 • 权限管理更清楚，减少长期隐患
150
151
superadmin 7.1 152 (% style="text-align:center" %)
153 [[image:1b94385d-51e7-4e32-8441-05a6fc7c2f23.jpg||height="221" width="375"]]
superadmin 1.1 154
superadmin 4.1 155
superadmin 1.1 156 可审计性做得好，安全团队反而更容易被信任，因为安全不再靠“要求”，而靠“事实”。
157
158
159 == 六、资产、配置与安全要连成一张网 ==
160
161
162 安全控制离不开资产管理与配置管理。 资产不清楚、配置不可信，安全就是盲人摸象。 成熟的做法是：
163
164 • 关键资产的登记册要可信，责任人要明确
165
166 • 关键配置要有基线，偏差要能被发现
167
168 • 关键权限与访问要可追溯
169
170 • 关键依赖与接口要清楚，避免影子系统
171
172 这些不是为了“管得更严”，而是为了让风险评估有依据，让事故处理更快。
173
174
175 == 七、发布与变更实施：安全不该是“最后一关”，而应是“护栏” ==
176
177
178 安全如果只在发布前做一次检查，很容易漏掉两类风险：
179
180 • 频繁小变更累积带来的隐患
181
182 • 配置漂移导致的长期漏洞
183
184 更稳的做法是把安全控制融入变更实施：
185
186 • 变更请求必须包含风险评估与影响说明
187
188 • 高风险变更要有更强的验收标准与转换就绪度检查
189
190 • 关键配置与权限变更必须可追溯
191
192 • 发布节奏要可预测，避免在高压窗口做高风险动作
193
194
superadmin 7.1 195 (% style="text-align:center" %)
196 [[image:image (1).png||height="123" width="443"]]
superadmin 1.1 197
superadmin 4.1 198
superadmin 1.1 199 安全做成护栏，交付就能跑得快；安全做成卡口，交付就会绕开。
200
201
202 == 八、人工智能与自动化：能加速安全，但更需要治理边界 ==
203
204
205 自动化能减少人为错误，人工智能能提升分析效率，但前提是边界清楚：
206
207 • 自动化可以用于基线校验、权限申请流程、日志收集与异常检测
208
209 • 人工智能可以用于聚类异常模式、辅助风险提示、生成通告草稿
210
211 • 高风险决策仍要有明确授权与责任链条，不能让工具替代问责
212
213 工具越强，越要守住治理底线。 否则一次自动化误操作就可能造成严重事故。
214
215
216 我建议学习ITIL 5的治理思想，先把“边界”做清楚，再把“路径”做顺：
217
218 • 先定义边界：哪些数据与操作是高风险，哪些必须强控制
219
220 • 再做分层授权：低风险走标准路径，中高风险走明确审批
221
222 • 把可审计性做扎实：关键操作留痕、可追溯
223
224 • 把安全控制嵌入转换就绪度与变更实施
225
226 • 用持续改进把安全缺口做成可验证的改进举措
227
228 只要边界清楚、路径顺畅，一线就不需要绕开，安全也不需要“喊得更大声”。
229
230
231 2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。
232
233
234 欢迎加长河老师微信achotsao，深入交流ITIL 第5版最新资讯。
深圳市艾拓先锋企业管理咨询有限公司