简介这份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 # 基线核查脚本 fragmentSSH、密码策略、登录审计 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_workers50) 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 分数典型处置时限是否需上报安全负责人紧急9.0 以上4 小时内是高危7.0-8.924 小时内是中危4.0-6.97 个自然日内否低危0.1-3.930 个自然日内或下个版本周期否这张表的关键不是 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 抓取来源 IPsshd 日志里倒数第四列就是来源地址然后用 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 安全运维教程里含金量最高的模块也是你所有日常积累集中兑现的时刻。很多第一次经历安全事件的同学会犯同一个错误打开终端和攻击者比手速结果越操作越乱最后连自己改了哪些配置都说不清。我的做法是把应急响应拆成四个时间节点每个节点有明确产出不求一步到位时间节点目标动作产出物第 0-10 分钟确认告警真实性判断是否影响核心业务一句话事件描述和初步影响范围第 10-60 分钟隔离受影响系统保留现场证据网络侧阻断记录、内存和磁盘镜像第 60-240 分钟分析攻击路径定位入口和失陷范围攻击链时间线第 240 分钟起清除后门、恢复服务、启动复盘复盘报告和后续加固项这张表的核心在于第 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 {LogNameSecurity; Id4624; 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 教材对应章节逐个补齐。这套方法不一定适合所有人但至少帮团队把“看书”和“干活”之间的距离缩短了一大截希望帮到你。本文还有配套的精品资源点击获取