简介：这份PDF教程面向CISAW安全运维认证备考者及一线运维人员，系统讲解信息系统安全运维的核心知识体系。内容源自中国信息安全认证中心信息安全保障人员认证培训框架，重点涵盖信息系统运维模型、安全运维与运维安全两类模式的联系与区别、数据、载体、环境与边界的生命周期、资源信息安全保障模型，以及机房标准化巡视、六阶段应急响应等日常实操要点。整个压缩包仅含1个PDF文件，大小约16.47MB，便于直接阅读与离线学习。目前已有754人学习下载，适合正在准备CISAW安全运维考试，或希望完善信息系统安全保障能力的运维工程师。通过教程可快速梳理“运维模型—对象生命周期—资源管理—应急响应”的完整链条，建立规范的安全运维工作方法，减少安全事件发生，提升信息系统运行的稳定性和安全性。

1. CISAW 安全运维：把“安全”从口号变成一套可执行的动作

很多从开发岗转过来、或者刚接手公司安全运维的同学，第一次翻开《cisaw安全运维教程.pdf》时，基本是同一个状态：目录每一项都认识，合上书却说不清第二天上班该先点哪个按钮。我在甲方带过安全团队，后来又在乙方做过交付，这本教程里讲的东西，其实就是把“安全”拆成了一套可以由值班、巡检、变更、应急这些动作组成的流程。它不教你写 exp，也不教你堆设备，而是告诉你当一个漏洞预警推到工单系统时，怎么评估影响面、怎么定优先级、怎么验证修复，最后怎么在复盘里把同类问题挡在下一轮。适合谁？适合要独立对一个业务系统安全水位负责的人，也适合正在准备 CISAW 认证考试的从业者。

2. CISAW 安全运维知识框架：从风险评估到应急响应，闭环怎么搭

2.1 安全运维闭环模型：从资产台账到应急复盘

我拆这份教程的第一件事，是把它的目录和实战里“安全运维”这四个字做了映射。真正的安全运维不是装了一堆安全设备就结束，而是一个闭环：先知道有什么东西要保护，然后设定一个可接受的安全水位，再让这个水位持续被观测，最后在出事时能止损并恢复。CISAW 安全运维教程里的章节排布，基本就是按这条线走的。你看着它好像讲了很多制度、流程、技术点，其实一个都没有超出这四步。

这里有个新手最容易犯的误区：直接跳到漏洞扫描和 WAF 规则，跳过资产梳理。但我在实际项目里见过太多反面案例。一个研发团队申请的测试服务器，因为没人更新资产台账，在公网裸奔了半年没人发现；也有过资产台账写的是 CentOS 7，实际系统早被升级到了其他版本，等保测评核查工具一跑全是报错。资产识别是本，你连要保护什么都不知道，后续的监控、响应全是空中楼阁。

实操上，我建议每个系统上线第一天就登记三件套：系统负责人、业务联系人、部署拓扑。不需要搞很大的 CMDB，一个用 Markdown 维护的清单都行，但必须保证变更后 24 小时内更新。这个习惯看起来土，但它决定了出事后你能在几分钟内拉出可能受影响的业务清单，还是需要挨个打电话去问。

2.2 风险评估与等保定级：把“拍脑袋”变成量化打分

风险评估是 CISAW 教材里绝对绕不开的一章，也是你实际工作中向老板要预算、向上级说明风险时必须掌握的表述方式。项目里的风险不是“感觉很危险”，而是要算出来的。常用计算方式不复杂：风险值 = 资产价值 × 威胁发生可能性 × 脆弱性被利用的难度。三个维度分别打分，资产价值按机密性、完整性、可用性三维加权，威胁可能性参考威胁情报和自己暴露的攻击面，脆弱性程度则依赖漏洞扫描和渗透测试结果。

这套算法在 ISO 27001 和等保标准里都有对应，但我不建议死记公式，关键是理解它怎么指导行动。比如一个内网的低价值资产，暴露面很小，即使存在一个高危漏洞，综合风险值也可能是中低，修复优先级可以拖后；而一个面向公网的支付回调接口，哪怕只是中危漏洞，也要按紧急事件对待，因为它一旦被利用就直接影响资金安全。CISAW 教材把这种判断逻辑讲得很透，这也是它比单纯看漏洞列表更有价值的地方。

落地到具体工作，我一般会把公司系统先按等保级别过一遍。二级系统关注基本的访问控制和日志留存，三级系统则要做更细的权限分离、双因素认证和更严格的审计保留期。很多小公司觉得等保是负担，但其实等保定级最好的产出，是让你把“哪些系统打死不能出事”变成白纸黑字，后续所有安全预算的分配都有据可依。做风险评估时不要追求复杂模型，先把资产清单拉出来，给每个资产打上“如果它被攻破，公司会损失什么”的标签，这一件事就够你忙一整周。

2.3 安全基线与配置核查：用脚本把合规落进系统

基线的概念，说白了就是给每类系统定一条“安全下限”。CISAW 安全运维教材里涉及的密码策略、远程管理限制、默认账户清理、日志保留策略，都属于基线的范畴。为什么它重要？因为漏洞可能修不完，但基线可以保证即使有漏洞，攻击者进来也要多绕过几道墙，整个过程会留下痕迹，让你的检测设备有时间报警。

我一般会为每类主机维护一个基线核查脚本，用最简单的 bash 就能实现。下面是一段我在 Linux 服务器上经常用的核查片段，检查的是最常见也最容易被忽略的几个点：

#!/bin/bash # 基线核查脚本 fragment：SSH、密码策略、登录审计 echo "===== SSH 配置检查 =====" # 检查是否允许 root 直接登录，生产环境建议为 no grep -E "^PermitRootLogin" /etc/ssh/sshd_config || echo "PermitRootLogin 未显式设置，请确认默认值" # 检查 SSH 是否允许密码登录，配合密钥管理应设为 no grep -E "^PasswordAuthentication" /etc/ssh/sshd_config || echo "PasswordAuthentication 未显式设置，注意风险" echo "===== 密码策略检查 =====" # 检查密码最大有效期，通常应 <= 90 天，特殊场景可适度放宽 grep -E "^PASS_MAX_DAYS" /etc/login.defs # 检查密码最小长度，建议至少 8 位，若公司策略更严则按公司策略来 grep -E "^PASS_MIN_LEN" /etc/login.defs echo "===== 登录审计检查 =====" # 检查是否记录了所有本地登录命令历史，定位误操作时靠它 grep -E "^HISTSIZE" /etc/profile || echo "HISTSIZE 未设置，默认可能只保留少量历史"

这段脚本的思路很简单：不是直接改配置，而是先把现状捞出来和基线做比对。我刻意用 grep 而不是 sed，因为你第一遍只该做“事实收集”，不要为了合规模板直接改生产配置，改坏了连回滚都不知道往哪滚。脚本输出的每一行，比对标准应该来自你们公司自己评审过的安全基线文档，不要照抄网上任意一份模板，每个业务对开放端口的诉求不一样。

脚本跑完以后，你会得到一份差距清单。这份清单不是安全团队的负担，反而是运维的后悔药：哪天出了审计问题，你能拿出半个月前的基线快照，证明当时的配置是合规的，问题出在后续某次变更没有走流程。这个证据链，比事后解释十句都管用。

3. 日常安全运维实操：资产梳理、漏洞处置与日志分析

3.1 资产与端口梳理：一个可复用的 Python 探测脚本

在 CISAW 教材里，资产和端口梳理是后续漏洞管理和访问控制的基础。日常运维里，这个活最容易被做成“每年等保之前突击扫一次”，然后就没了下文。我的习惯是把它做成一个定期任务，一个季度至少跑一遍，新业务上线或机房变更后立即加跑一次。

下面这个脚本是我常用来对一段内网 IP 做端口探测的简化版，基于 Python 标准库，不依赖第三方包，在任何装了 Python 3 的机器上都能跑：

#!/usr/bin/env python3 # 简易端口存活探测脚本：检测指定网段内主机的常见服务端口 import socket from concurrent.futures import ThreadPoolExecutor # 要探测的端口列表，按业务重要性排序 PORTS = [22, 80, 443, 3306, 6379, 8080, 9090] # 网段范围，实际使用时改成自己的网段 NETWORK = "192.168.10.0/24" def check_port(host_port): host, port = host_port sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(1) # 单端口超时 1 秒，避免扫到黑洞地址时卡死 result = sock.connect_ex((host, port)) sock.close() return host, port, result == 0 def main(): # 简化为只扫最后一段地址，完整版需引入 ipaddress 模块展开整个网段 tasks = [] for last in range(1, 255): host = f"{NETWORK.rsplit('.', 1)[0]}.{last}" for port in PORTS: tasks.append((host, port)) with ThreadPoolExecutor(max_workers=50) as executor: # 50 线程并发，实测在百兆内网里能稳定跑完一个 C 类网段 for host, port, is_open in executor.map(check_port, tasks): if is_open: print(f"[OPEN] {host}:{port}") if __name__ == "__main__": main()

脚本逻辑不复杂：把网段里每个 IP 和端口列表组合成任务，用线程池并发探测，最后把开放的端口打出来。两个参数值得展开说。超时时间设成 1 秒，如果机房有跨地域的网络延迟，可以放宽到 2 秒，不然容易漏报；线程数 50 是内网探测的常见值，开太大会让交换机或目标服务器先扛不住，开太小速度又上不来。

这个脚本的价值不在“发现新机器”，而在让你定期对比台账。跑完以后，把开放端口列表和 CMDB 里登记的端口清单做一次 diff，多出来的端口就是排查对象。是业务新增了服务忘了更新台账，还是有人私自开了高危端口，这是真实环境里每天都在发生的对抗。我见过一个案例，某公司的数据库端口被运维私下改到高位端口用来绕过检查，结果这个“隐形端口”被脚本抓到，追查之后发现这位运维在跑私单。你不需要把工具做成商业扫描器那么全，但保持高频比对这件事，比一次性扫描有效得多。

3.2 漏洞管理闭环：扫描、验证、定级、修复、复查

漏洞管理是 CISAW 教程里占用篇幅较大的部分，也是安全团队和运维团队冲突最多的环节。研发说“这个漏洞影响不大”，安全说“必须立刻修”，互相拉扯的根源，是双方没有一个共同的定级标尺。

我建议把漏洞处置流程固定为五步：扫描、验证、定级、修复、复查。漏洞扫描报告只是第一步，报告里的内容还要有人在预发布环境验证一次，确认不是扫描器的误报。验证通过后，按照 CVSS 分数和资产暴露面联合定级，这才是决定修复顺序的依据。这里给一个我项目里常用的参考表：

这张表的关键不是 CVSS 数字本身，而是“暴露面”参与了定级。一个 CVSS 8.8 的漏洞，跑在内网且无敏感数据，和跑在公网供用户直接访问，处置时限差出一大截。CISAW 教材反复强调资产的三个属性，机密性、完整性、可用性，就是为了在这里发挥作用。

修复完成不等于漏洞关闭。你还要做复查：重新扫一次目标资产，确认漏洞确实消失，同时检查修复动作有没有引入新的开放端口或配置变更。复查记录要保存，后期做安全月报和等保测评时，这些记录是硬通货。嘴上说“漏洞全修完了”没有用，把时间线贴出来，谁也不会再问第二句。

3.3 日志分析三板斧：grep、awk、关联已经够用

很多刚做安全运维的同学会被“大数据分析”“AI 检测”这些词带偏，以为日志分析非要上 ELK 或者大数据平台。实际上，百分之七八十的日常告警排查，用 Linux 原生的 grep 和 awk 就能完成。CISAW 教材里对日志讲得最多的是访问日志和认证日志，这两类恰恰是命令行的主战场。

举个真实场景。你接到一个告警，说某台服务器出现大量 SSH 认证失败，第一步要做的不是上平台，而是在服务器上直接捞：

# 查看最近一小时内 SSH 认证失败的来源 IP 和次数 # 适用系统：CentOS 7 / Ubuntu 18.04 及以上（journald 收集 auth 日志） journalctl --since "1 hour ago" | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

这段命令的构成很简单：journalctl 取时间窗口，grep 过滤出认证失败记录，awk 抓取来源 IP，sshd 日志里倒数第四列就是来源地址，然后用 uniq -c 做次数统计。几个参数值得说清楚：--since 的时间窗口看告警触发的节奏来定，如果是连续爆破，一小时够用；如果攻击者做了慢速攻击，就要把窗口拉到 24 小时。head -20 只取前 20 个 IP 是避免一次看太多，先找最激进的那个。

拿到 IP 之后，下一步不是封禁了事，而是看它有没有登录成功过。如果只有失败记录，大概率是扫描器随机爆破；如果其中夹杂着登录成功的记录，这就是安全事件了。这时候再去翻登录成功后的操作痕迹，比如命令历史、文件变更，定位攻击者进来之后做了什么。

日志分析这个活，核心能力不是会用多高级的工具，而是知道“看哪段时间、看哪类事件、怎么串起来”。把这三件事练好，再上 SOC 才有意义，否则你只是在用一个更贵的界面做同样的事。

4. 安全监控与应急响应：从海量告警里捞出真威胁

4.1 告警分级与值班响应：给告警定一个 SLO

监控体系一旦搭起来，下一个问题就是告警太多。很多团队第一天接入监控，值班手机一晚上能响几十次，根本分不清哪个是要命的。CISAW 教程里的做法，是把告警按业务影响和可利用性分级，每个级别绑定不同的响应时效，也就是给告警定义一个明确的 SLO。

我在项目里的习惯是分四级：P0 是核心业务不可用或疑似入侵，必须 10 分钟内有人响应；P1 是重要系统异常但业务还能撑，30 分钟内响应；P2 是常规告警，当天处理；P3 只是提示，不强制排期。关键点是，每个级别必须对应一个负责人和一套动作，否则分级就成了一条没有执行的标语。

为什么这么强调 SLO？因为我见过太多团队把告警级别定得很细，结果一晚上接到 20 个 P0，值班人员干脆把手机调成静音。这个现象说明分级没有和资源挂钩，P0 只是一个标签。真正有效的做法是控制 P0 的数量，每个月统计各级别告警数量。如果 P0 占了大头，问题出在监控策略太敏感或系统本身太脆弱，而不是值班的人不努力。

4.2 应急响应时间线：一小时止损、四小时定位、一天复盘

应急响应是 CISAW 安全运维教程里含金量最高的模块，也是你所有日常积累集中兑现的时刻。很多第一次经历安全事件的同学会犯同一个错误：打开终端和攻击者比手速，结果越操作越乱，最后连自己改了哪些配置都说不清。

我的做法是把应急响应拆成四个时间节点，每个节点有明确产出，不求一步到位：

这张表的核心在于：第 60 分钟前，你的敌人不是攻击者，而是自己的慌乱。很多新手一上来就拔网线、改密码，结果攻击者留下的后门还在，你恢复服务等于二次放行。正确的顺序是先保留证据，再动系统。哪怕只是把内存镜像导出来、把进程树打出来，也比什么都不留强。

应急过程里，最容易被忽略的是记录。我要求团队成员在事件响应时开一个共享文档，每十分钟记一次当前状态和操作动作。不是为了写报告，而是为了让自己回头看时知道“刚才这个状态是我改的还是攻击者改的”。后面复盘的时候，这份记录比任何分析工具都重要。

4.3 常见攻击链识别：横向移动的典型信号

攻击者很少只打一台机器。公网入口得手后，下一步就是内网横向移动。CISAW 教材在安全监测章节里反复提到的异常登录、异常进程、异常外联，追根究底就是在找横向移动的痕迹。

横向移动最常见的信号有三个，值班时优先盯这几类日志。一是域内用户从非习惯终端登录，比如一个从来没有登录过服务器 A 的账户，突然在凌晨 3 点登录了；二是脚本宿主进程异常启动，比如 powershell.exe 从文档目录启动，这是典型的白名单绕过尝试；三是服务器主动向外发起大量内网端口连接，比如一台只跑 web 的服务突然去连数据库端口，这大概率是失陷后在探测数据库。

检测这类行为的命令本身不复杂，但需要提前打开审计开关。比如 Windows 上需要开启登录审计和进程创建审计，然后定期查询安全日志里的事件 ID 4624登录和 4688进程创建：

# 查询最近 24 小时内登录成功的非本地账户，按来源 IP 聚合 # 适用系统：已开启安全审计策略的 Windows Server 2016+ $since = (Get-Date).AddHours(-24) Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=$since} | Where-Object { $_.Properties[8].Value -ne '0.0.0.0' } | Group-Object { $_.Properties[18].Value } | Sort-Object Count -Descending | Select-Object Count, Name -First 15

这段 PowerShell 的逻辑不复杂：把安全日志里 4624 事件捞出来，过滤掉回环源地址，按来源 IP 分组，看哪个 IP 登录最频繁。这里有一个坑：不是源 IP 次数多就是攻击，有些合法的跳板机本身就是集中登录源，你需要先把堡垒机 IP 加进白名单，再对剩下的 IP 做人工分析。我一直强调基线先行，就是这个原因——你没有“正常行为”的参考，就无法判断“异常行为”。

5. 安全运维避坑指南：五个高频翻车点的排查记录

5.1 漏洞扫描把生产业务扫挂了

现象：在非业务高峰期跑了一次全端口扫描，扫描结束后，网络设备 CPU 负载飙升，部分前端页面响应超时，有个服务直接重启。

原因：扫描器发出的并发包太多了。默认配置下，很多商业扫描器对单个主机的并发检测会同时跑几十个插件，遇到老旧的网络设备或中间件，半开连接会直接把会话表打满。很多第一次做扫描的团队，装上扫描器直接就用默认策略，这是最危险的用法。

解决：扫描前先做两件事。第一，在扫描器里把单主机并发数调到 5 以下；第二，先用 5 个 IP 做小范围试点，观察目标机器的 CPU 和网络连接数曲线，没有异常再放开到全量。扫描窗口选在凌晨业务最低谷，并且提前通知运维和网络团队，让他们看到异常流量时不至于误判成攻击。

5.2 基线加固改坏了业务端口

现象：按基线模板在 Linux 服务器上执行加固脚本后，客户端连接不上应用端口，业务中断了半小时。

原因：基线模板里的防火墙规则没有放行业务端口。网上很多开源的加固脚本为了省事，默认只放行 22、80、443 三个端口，但你们的业务用的可能是 8080、8443 或自定义的高位端口。加固流程里如果包含“禁止所有未明确放行的端口”，这一条就把业务端口全杀了。

解决：把基线加固拆成两步。第一步先导出当前防火墙规则，和业务端口清单做交集，把业务端口在加固脚本里显式加入放行列表；第二步在预发布环境跑通脚本，用同样的客户端连接测试，确认端口全通后才允许推生产。我在每次加固前都会重复一句：基线给资产分类，不是一把尺子量所有人的。

5.3 日志权限配置不当导致采集断流

现象：配置了集中日志采集后，发现部分服务器的日志在采集端断流，每天固定时间之后就没有新记录了，但磁盘上的日志文件还在增长。

原因：日志轮转和新目录权限冲突。运维通常把日志目录设为 644 权限，但采集器 agent 以独立账户运行，没有读取某些日志目录的权限。一旦日志轮转把旧文件切走、新文件生成时权限不对，agent 就会静默失败，不再上报。

解决：排查时不要只盯 agent 配置。先确认采集账户对日志目录有读取权限，再检查轮转后的新文件权限是否保持一致，最后看 agent 自己的日志里有没有权限拒绝的记录。最好的办法是在上线清单里加一条“采集器权限自检”，部署完马上跑一遍，别等第二天告警响了再去查。

5.4 告警风暴：半夜被刷屏，值班手机一周后静音

现象：某夜值班手机连响 20 多次，第二天一看全是同一台测试服务器的同一类告警。值班人员从那以后对所有告警通知都麻木了，真正的事件被淹没在噪音里。

原因：监控规则没有做聚合和抑制，也没有设置告警冷却时间。一台服务器的某个指标持续异常，采集周期是 30 秒，一个小时就能产生 120 条告警。如果不做聚合，P0 和噪音没有本质区别，分级形同虚设。

解决：所有告警规则必须配置聚合窗口和恢复通知。我的习惯是：同一对象同一指标在 15 分钟内只产生一条告警，恢复后自动清除并触发恢复通知。同时开启抑制规则，比如“主机 down”告警触发后，其上的所有服务告警都自动静默，避免一条故障触发几十条连带告警。

5.5 应急响应时线上操作没有留痕

现象：一次安全事件结束后复盘，发现参与处置的三个人对“当时是谁禁用了那个账号”“防火墙规则是哪条被改的”各执一词，没有任何记录能证明操作顺序。

原因：应急响应时没有同步记录操作日志。几个人各自在自己终端上操作，心理上都觉得“我操作了、别人看得到”，实际上没有任何人看到全貌。事件结束后，留下的只是一堆最终状态的截图和聊天记录。

解决：应急响应启动时，第一件事不是查攻击源，而是开一个共享文档，并在操作机上启用终端会话记录。我给团队定的规矩是：谁执行了什么命令，必须在共享文档里同步一条，哪怕只是“在 10.1.1.5 上改了 SSH 配置”。复盘时把终端记录和文档对照，整个事件的时间线才能还原出来。

6. 把 CISAW 安全运维知识固化成能力：两周自测清单

教材看完了、步骤也照做了，怎么确定自己真的掌握？我的做法是别急着收藏，先给自己出一道综合题，把二十几页笔记浓缩成一张两周自测清单，每天花十五分钟过一遍，比把书放在书架上落灰有用得多。

先出题。找你们公司一个真实的、不是 PDF 里虚构的案例，比如“某天凌晨收到告警说核心数据库服务器 CPU 异常，登录后发现一个陌生进程在持续外联”，然后试着把处置过程写成文档。写不出来没关系，对照教材的应急响应章节做一轮填空。这一步的意义，是把“我看过了”变成“我做过一遍”。

再对照。把教材目录里的核心章节列出来，对着你当前负责的系统逐条打分：资产台账有没有人维护、基线配置有没有脚本化、日志能不能从采集到分析全链路跑通、告警分级有没有 SLO、应急响应有没有复盘记录。每个低分项就是下一周的工作排期。分数不高的章节，下一周的排期就放在那里，别给自己找借口。

纸上谈兵的部分通了，实验还是要做一次。我建议搭一个最小靶机环境：一台装了默认配置服务的虚拟机，开启审计日志，跑一遍漏洞扫描、日志分析、应急响应的完整流程。不需要装重型设备，一台虚拟机加一个端口扫描工具就够。跑完你自然会发现，书上写“先保存证据再隔离”只用一行，实际操作时你的第一反应永远是先杀进程。这中间的差距，就是这份教程最大的价值所在。

从那以后，我每次带新人接触安全运维，都会先让他们做一遍这个自测，再把暴露出的短板和 CISAW 教材对应章节逐个补齐。这套方法不一定适合所有人，但至少帮团队把“看书”和“干活”之间的距离缩短了一大截，希望帮到你。

本文还有配套的精品资源，点击获取