直接告诉你结论这篇文讲的是帮一家单位做等保测评时我在主机层面梳理出来的17个检查项以及每个检查项背后那些容易被忽视的坑。至于标题里的“龙虾”纯粹是我同事在输入法里想打“的流程”结果敲出了“的龙虾”念了两遍居然还挺顺口于是我就拿它当代号了。如果你正在准备等保测评或者被安排了配合测评的整改工作这篇内容应该能帮你省掉不少来回沟通的时间也让你在面对测评师提问的时候心里更有底。等保测评这件事说复杂是真复杂因为牵涉到管理体系、物理环境、网络架构、主机安全、应用安全、数据安全好几个大方向每一个方向里又有几十个细小的检查点。但说简单也真简单只要你能按照“身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范”这条主线去逐项核对把每一类里最核心的控制要求落地测评现场就不会出现太多意外。我这篇文不打算把整个等保的标准条文从头到尾给你念一遍那样没意思也算不上经验分享。我更想把我在这次项目里实际检查过的17个具体项、每一项当时是怎么查的、查完发现了哪些问题、最后又是怎么整改的原原本本写出来。这些内容不是从文档里抄出来的是我一台一台服务器跑命令、一个一个配置文件翻出来的你在标准文档里看得到要求但看不到这些现场经验。先说清楚这17个项是怎么来的。当时接的项目是一家做在线业务系统的公司系统规模不算大但涉及对外服务所以按等级保护第三级的要求来做。测评范围里包含两套业务服务器、一套数据库服务器、一套运维管理终端外加相关的网络设备和安全设备。整个测评团队分工之后落到我手上的主机安全部分我按等保2.0里“安全计算环境”这一章的检查要求把和操作系统、数据库、中间件相关的控制点全部列出来最后合并同类项整理成17个明确的核查项。这17项覆盖了账号权限、登录控制、审计日志、入侵防范、资源管控、数据完整性、个人信息保护等几个大块基本就是三级等保主机层面最核心、也是测评师最容易反复追问的部分。1. 等保测评的整体思路以及为什么这17项必须先理清楚1.1 测评不是找茬是帮你把安全底子摸清楚我见过很多人一听到“等保测评”四个字就头大觉得测评师是来找麻烦的到处挑毛病整改意见一条接一条仿佛永远改不完似的。干这行久了我倒觉得测评的本质更像一次全面体检它不是为了让你当场难堪而是想弄清楚你这套系统现在的安全状态到底处于什么水平哪些地方存在可能被利用的风险点然后给你一份相对客观的结论。和体检一样有些小问题当场就能处理有些问题需要后续持续跟踪但前提是你得先知道自己哪里有毛病。这次项目里我负责的主机部分是整个测评里最细碎但也最见功夫的一块。网络层面的问题通常比较明显比如防火墙策略没生效、访问控制列表缺失这些通过配置核对就能快速判断。但主机层面的问题往往藏在很具体的细节里比如某个系统账号的密码策略不符合要求、某个服务的启动用户权限过高、某条登录日志被轮转覆盖这些问题不深入到操作系统内部、不把配置文件逐行看一遍根本发现不了。所以我在现场花了大量时间在命令行和配置文件之间来回切换就是为了把这些隐藏的风险点一个不落地捞出来。1.2 标准那么多如何把检查点收敛成可落地的17项等保2.0的三级标准文本里安全计算环境这一章的控制点大约有十多条但每条下面还有若干项要求直接照搬会显得很零散。实际操作中我会先把和主机直接相关的控制点摘出来再把那些针对网络设备、安全设备或者管理制度的条目放到其他同事的检查清单里这样责任划分清楚现场也不会重复检查导致对方单位的人来回折腾。收敛原则其实就是三条一是看这个检查项是否直接影响主机本身的安全性二是看它是否属于测评师在主机测评时必须出具证据的必查项三是看它是否能够通过现场操作直接验证。满足任意两条的就保留下来只存在于制度文件里、无法在主机上形成对应配置的就归到管理测评那一组。最终整合出来的17项每一项背后都对应的是等保标准里的一条或几条具体控制要求而且每一项都能在系统配置里找到实际依据。这样做的好处是后续生成问题列表和整改建议的时候每一条都能追溯到具体标准不会出现“测评报告写了问题但不知道按什么标准来的”这种尴尬。2. 17个核心检查项逐个拆解每一关都查了什么2.1 身份鉴别与访问控制类最容易出事也最容易被忽视身份鉴别和访问控制听起来好像是信息安全里最基础的东西但恰恰是问题最多的地方。我无法统计在多少个系统上见过所有用户共享同一个账号、密码五花八门且从不修改的情况了。等保三级的要求是应对登录的用户进行身份标识和鉴别身份标识具有唯一性同时要启用登录失败处理功能比如结束会话、限制非法登录次数、设置超时自动退出。听起来不难对吧但真到了现场核查每个点都有讲究。首先看身份标识的唯一性。你得检查系统当前存在的所有账号确认没有同名账号这一点相对容易。真正容易出问题的是有些应用系统会在数据库里创建服务账号这些账号可能和设备管理员账号混在一起一旦梳理不清就会出现两个账号权限边界模糊的问题。其次看登录失败处理。这个功能在不少系统里是默认关闭的或者配置了但参数太宽松比如允许连续尝试十次以上才锁定这样的配置和没开几乎没有区别。我的经验是一般建议设置为连续失败5次锁定账户锁定时长至少30分钟这样既能防止暴力破解又不会因为误输几次密码就把账号锁死影响正常使用。再往下就是访问控制了。等保标准要求依据安全策略控制用户对文件、数据库表等客体的访问粒度要细到单个用户。实际操作中我会重点核查系统内是否还存在权限过大的普通账号比如某个业务账号居然属于root组或者某个运维账号的sudo权限是ALL,这些都是测评时会明确记录的问题。这个环节我还会特别关注默认账号和共享账号比如有的团队为了方便运维几个人共用一套管理员账号这在测评中是被明确视为不符合项的因为一旦出了问题根本没有办法定位到具体责任人。2.2 安全审计类日志配置对了才有真正的“后悔药”安全审计是等保测评里很重的一块。标准要求系统应启用安全审计功能审计覆盖到每个用户对重要用户行为和重要安全事件进行审计并且保证进程无法中断。说起来很抽象落到主机上就是几个看得见摸得着的事情系统日志有没有开、记不记录用户登录和操作行为、日志内容会不会被普通用户删除或篡改、日志留存时间够不够长。以我这次检查的Linux服务器为例首先要确认rsyslog服务在正常运行然后看/etc/rsyslog.conf和/etc/rsyslog.d/下的配置确认authpriv、cron、kern这些和用户行为及系统关键事件相关的日志类型已经被收集。这里有个容易被忽略的坑就是有些系统管理员图省事把日志全丢到/var/log/messages里结果用户登录日志单独没有被记录这样测评时是会被判定为审计覆盖不全的。正确的做法是给认证日志单独分一个文件比如/var/log/secure同时通过rsyslog的远程日志功能把关键日志同步到集中日志服务器防止本地日志被清理后找不到痕迹。还有一点要重点检查就是日志是否设置了正确的权限。如果普通用户都能读取甚至删除系统日志文件那审计功能就形同虚设了。正常情况下/var/log/secure这样的文件应该设置为600权限属主是root这样一般用户碰都碰不到。另外得确认系统时间是否准确同步这个看起来和审计没什么关系但审计日志里记录的时间如果和时间服务器偏差过大等保测评里同样会记录为时间同步机制不完善后面追溯事件的时候根本没法判断真实发生时间。2.3 入侵防范与恶意代码防范类光装杀毒软件远远不够入侵防范这块标准的要求是系统应遵循最小安装原则仅安装需要的组件和应用程序关闭不需要的系统服务、默认共享和高危端口同时应能够检测到对重要节点进行入侵的行为并在发生严重入侵事件时提供报警。我在现场核查的时候第一件事是把服务器上监听的端口全部拉出来看看有没有多余的服务在跑。这个操作看似简单但特别有效。很多开发机或者测试机上会跑着各种临时服务比如调试端口、数据库默认端口、远程管理端口等这些在测评里都会被揪出来。一般来说对外只应该暴露业务必须的端口其余一律通过防火墙策略控制掉。另外还要检查系统里有没有装编译工具、调试工具这类对生产环境完全无用的组件有的话建议直接卸载这本身就是最小安装原则的体现。恶意代码防范方面标准要求应安装防恶意代码软件并及时更新软件版本和恶意代码库。这里需要注意不是说你装了某款杀毒软件就算符合要求你还得证明它的病毒库是持续更新的并且能覆盖到所有重要的服务器。我见过不少单位杀毒软件倒是装了但是病毒库停留在几个月前有些甚至因为授权到期已经停止服务了这种情况测评时一样会被记录为不符合。如果你用的是云平台自带的安全组件也要注意有没有定期扫描和告警记录这些日志同样要保留下来作为测评证据。3. 现场实操记录我如何一台一台跑命令完成核查3.1 身份鉴别相关命令不只是看配置还要验证效果现场核查的第一步通常是收集各种配置信息但光收集还不够你还要确保收集到的内容足够支撑你做出符合与否的判断。以身份鉴别为例我通常会先跑几条命令把系统的用户和认证配置摸一遍然后再具体验证其中比较关键的参数。# 查看系统账号信息核对是否存在共享账号和异常UID awk -F: $30{print $1 是UID为0的账号} /etc/passwd awk -F: {print $1} /etc/passwd | sort | uniq -d第一条命令用来检查是否存在除root之外的UID为0账号因为UID为0代表超级用户权限如果出现了其他账号拥有这个UID那就是权限过大的典型风险。第二条命令看是否有重复的用户名这是为了确认身份标识的唯一性。这两个检查看起来基础但每次都能发现点东西尤其是那些从测试环境直接转到生产的系统经常会有残留的测试账号躺在passwd文件里。然后看密码策略和登录限制# 查看密码策略配置 grep -E PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE /etc/login.defs # 查看密码复杂度和失败锁定策略 cat /etc/pam.d/system-auth这里我要强调一个很多人会忽略的细节密码策略不只改/etc/login.defs就完事因为/etc/login.defs里设置的密码有效期只对新建用户或者执行chage命令后的用户生效存量用户如果之前没有被强制设置过密码还是可以无限期使用。所以正确的做法是改完login.defs之后还要对所有存量账号执行chage命令让他们在下次登录时强制修改密码。PAM配置那块重点看pam_pwquality.so和pam_faillock.so这两个模块是否开启。密码复杂度不光要设置最小长度最好还要强制包含大小写字母、数字和特殊字符中的至少三类这样面对暴力猜解的时候韧性会强很多。还有个点容易被忽略就是账号是否设置了合理的不活动锁定时间。等保标准里没有明确说要多少天但一个长期不用的账号被遗留在线上的风险是显而易见的。我的习惯是检查一下是否存在lastlog时间为空或者很久没登录的账号如果确实是僵尸账号直接禁用或者删除这比设置再多的策略都实在。3.2 访问控制与最小权限找到一个修一个访问控制这块现场核查的时候我的注意力集中在两个地方一是普通用户权限是否过大二是服务进程的运行身份是否合理。先看几个常用命令# 查看wheel组或sudo组里的用户这些组通常有提权能力 getent group wheel getent group sudo # 查看sudo配置确认哪些用户拥有管理员权限 cat /etc/sudoers ls /etc/sudoers.d/检查sudoers配置的时候我建议不要只盯着root账号看还要看那些通过sudo提权的普通账号。很多单位的运维习惯是用自己的账号登录然后sudo切到root执行命令这本身没问题但如果在sudoers配置里给某个账号配置了NOPASSWD权限并且该账号又被多个团队共用那这个账号一旦泄露系统就完全暴露了。更理想的方式是有权限需求的账号都配置为需要密码验证并且限制他们只能执行必要的管理命令实现最小权限。服务进程运行身份这个点很多人想不明白为什么测评师会关心。打个比方如果一个Web服务进程是用root身份启动的那么攻击者如果利用了Web应用的漏洞拿到的是root权限这就等于把整个服务器的大门钥匙直接递给了对方。正确的做法是每个服务单独创建一个专用的系统账号服务进程只以这个账号的身份运行并且这个账号只拥有和服务运行相关的最小权限。比如Nginx就用nginx用户跑Tomcat就用tomcat用户跑不要为了图省事直接以root启动。检查命令也很简单ps aux一下看看进程列里的USER字段一目了然。3.3 安全审计与日志复核把记录变成看得见的证据审计这块的实操重点是怎么证明你的审计功能真的在干活。我见过有的系统日志服务开了但目录权限不对普通用户能看到甚至能清理关键日志这样的审计等于白做。实操的时候我按下面几步走# 确认日志服务运行状态 systemctl status rsyslog # 查看认证日志文件权限 ls -l /var/log/secure # 验证日志中有用户登录和操作记录 tail -n 50 /var/log/secure日志权限这个问题我在不止一个项目里遇到过。默认情况下/var/log/secure的权限是600属主是root这没问题。但我见过有管理员为了排查问题顺手把日志目录权限改成755甚至把日志文件属主改成某个普通账号的这种改动如果不恢复审计功能的安全性就会大打折扣。等保测评的时候测评师看到这种情况通常都会记录因为这意味着操作日志可能被非授权人员修改或删除。然后就是看日志轮转配置。日志如果无限增长会耗尽磁盘空间挤占业务资源如果轮转周期太短、保留份数太少又会导致审计日志留存时间不够。以我这次项目为例系统日志轮转策略是每天轮转一次、保留4份算下来只保留4天这在等保测评里是不够的。《网络安全法》相关要求以及等保标准里的通行的做法是日志留存至少6个月所以我当时直接建议对方把轮转周期调成按大小轮转并且保留足够多的轮转文件或者干脆把关键日志实时转发到专门做日志集中存储的服务器上这样既满足留存要求又不会对业务服务器造成存储压力。3.4 入侵防范核查用端口和进程排查那些不该有的东西入侵防范的现场操作相对其他几类来说更直观一些因为结果直接可见。我一般从端口入手一步步剥开看# 查看当前监听端口及对应进程 netstat -tlnp # 或使用ss命令 ss -tlnp # 查看与外部IP建立的连接 ss -tn state established ( sport ! :22 )第一条命令把服务器上所有监听端口拉出来然后逐个对号入座查清楚这个端口是哪个服务在监听、那个服务是不是业务必需的。有人会觉得我服务器上多跑一个Web服务、多开一个数据库端口有什么关系关系是多一个端口就等于多一个潜在的攻击面。外部扫描工具很容易发现非业务端口的开放状态一旦对应的服务存在漏洞入侵就可能从这里展开。所以我的建议是除了业务必须的HTTP/HTTPS端口、数据库本地监听端口、SSH远程管理端口之外其他端口一律关闭或者通过防火墙策略限制来源IP。再看是否有异常的外联连接。这里面要特别说明一下不包含任何网络链路相关的合规内容仅从主机侧做常规检查。如果业务服务器本不该主动访问外部网络的但出现了大量对外连接这就有可能是恶意程序在向外回传数据。遇到这种情况我会先用ss命令看连接的远端地址和端口再结合云控制台的流量监控或者防火墙日志去判断这些连接是否是正常业务行为。如果不是那就要立刻定位对应的进程一时定位不了就把可疑进程挂起配合应急响应工具深入排查。3.5 数据安全与个人隐私保护这块检查项经常被漏掉等保三级除了传统的主机安全要求之外数据安全和个人信息保护的要求也在逐步增强。落到主机这一层我会重点看几个方面一是重要数据是否在存储时做了完整性保护二是数据备份是否真实可用三是如果涉及个人信息是否做了去标识化或者加密存储。完整性保护这一点可以通过配置相关机制实现比如对关键的系统文件、重要的配置文件做基于哈希的数字签名校验一旦文件被篡改系统能够检测到异常。这个方法挺好用但很多单位根本没搭过。测评的时候如果系统里没有这类检测机制至少要有定期对重要文件做校验并保留基线记录的书面流程。备份方面光看有没有做备份还不行还得看备份数据是否定期做过恢复演练。这个问题在测评访谈环节一定会被问到“你们的备份做过恢复测试吗”如果答案是没有那这条基本就要按部分符合处理因为备份可用性没有证据支撑。个人信息保护这块如果业务系统里存储了用户手机号、身份证号之类的敏感信息数据库里的这些字段最好做加密处理前端展示也要注意脱敏。测评时访谈对象如果能解释清楚当前用的是什么加密算法、密钥怎么管、展示端怎么脱敏印象分会好很多。4. 测评过程里的典型问题每一坑都值得提前避开4.1 账号密码相关问题不是改个密码就完事这次项目里我发现的最典型问题就是有台业务服务器的操作系统用户里存在一个两年没登录过的测试账号还带着sudo权限。测评现场核到这一项的时候对方的运维负责人自己都有点意外说这个账号是很早之前一个测试同事创建的后来那个人走了账号也没清理。这种情况处理起来很快直接删除账号或者至少先锁定账号再确认后续是否还需要。但这个问题背后折射出的管理缺失才是测评师真正关心的账号生命周期管理如果不做类似的僵尸账号只会在系统里越积越多。密码相关的问题也是类似的逻辑。有个数据库服务器的root账号密码复杂度不够只有8位纯字母。运维人员自己也知道但觉得这个库只在内网访问问题不大。但测评的标准不看你是不是内网只看你配置本身是否符合要求。我当时给出的整改意见是把密码改成至少12位、包含大小写字母加数字加特殊字符并且通过密码策略强制生效。改完之后还要确认应用系统里的连接配置同步更新了不然光改数据库密码没改应用侧的连接串业务直接就断了这种事在整改环节里经常发生务必留意。4.2 时间同步问题一个看起来小、实际上很关键的配置时间同步这个点很不起眼但在等保测评里属于主机层面的必查项。标准要求应对系统的时间进行同步确保日志的时间和外部时间源保持一致这对事后追溯安全事件至关重要。很多服务器装了NTP服务但没配置好或者配置了内网时间源但一直同步失败。我在项目里就遇到一台服务器的系统时间比标准北京时间快了十几分钟日志记录的时间全乱了后续排查问题的时候对不上号。解决办法很简单就是用chrony或者NTP服务配置好可用的时间源然后强制同步一次再确认系统时区也是正确的。这里有一个需要注意的细节如果服务器在云上很多云平台默认提供内网时间源你直接配置内网时间源地址就行这样即便业务环境没有外网访问权限时间同步功能依然能正常工作。同时测完时间同步之后记得查看一下同步是否成功有些时候时间源地址是填了但网络策略没放行导致同步一直失败这种隐藏问题最好当场解决掉。4.3 日志留存不够等保整改里最常见的一个不符合项说到整改日志留存类型的问题几乎每次测评都会出现。很多单位没有集中日志平台服务器上的日志都是本地轮转轮转周期又短保留天数只有一周甚至更短。等到测评的时候测评师要求出示6个月前的操作日志根本拿不出来这一项就得记成不符合或者部分符合。我这次项目里主推的解决方案是搭一套简单的集中日志收集服务通过rsyslog把每台服务器的认证日志、系统日志、核心业务日志实时转发到日志服务器上日志服务器那边再做按日存储和压缩归档。这样一个月的原始日志量也不大一块几TB的磁盘就能轻松存上半年以上的日志。如果你单位已经用了商用日志平台那就更简单了确保所有服务器都已经接入并且日志采集状态正常就行。还有一点日志服务器自身的权限控制要做好不能谁都能登录上去改日志不然集中保存也白搭。4.4 Web应用层面的两头堵虽然我主要负责主机安全但等保测评里Web应用安全和主机安全是紧密咬合的。比如某个对外服务的后台登录页面没有做登录失败次数限制也没有验证码机制那不管主机密码策略设得多完美攻击者依然可以对后台登录接口发起无限次的暴力尝试。这类问题通常会被归类到应用安全但整改的时候往往要主机和应用两边配合着改。合规范围内提一个最直接的场景Web服务的启动账号。之前在一台服务器上看到某个Java应用直接以root身份启动对应端口也绑定在8080上对外访问。如果这个Java应用存在反序列化漏洞攻击者一旦得手拿到的是root权限损失就不是一台业务服务器那么简单了。整改方法很简单但很颠覆惯性给应用创建一个专用账号把部署目录属主改成这个账号再用这个账号启动应用。注意这一步涉及应用的日志写权限、临时目录写权限、配置文件读取权限都要跟着调不是说换个账号启动就完事了改完还要完整做一轮业务回归测试确认功能没受影响。5. 测评前后的一些琐碎心得关于整改、复测和沟通5.1 整改优先级怎么排先处理风险最高的再处理最显眼的测评报告出来之后整改的顺序也是有讲究的。我的建议是先把高危风险项处理掉比如系统账号权限过大、对外非必要端口开放这种一旦被利用后果严重的问题第一时间处理接着处理测评里被明确判定不符合、但整改成本比较低的项比如密码策略、登录失败锁定、日志留存策略这些改配置就能解决的项目最后再处理那些涉及管理制度、需要长期运行才能见效的项比如账号管理制度、备份恢复演练制度这些要写进制度文件还要真正落地执行。我当时给这家单位的主机整改建议也是按这个优先级排的。第一优先级是删除僵尸账号和调整sudo权配置这是纯粹的存量风险清理半小时内可以完成但对系统安全性的提升立竿见影。第二优先级是全面调整密码策略和登录失败锁定策略再对所有存量用户强制设置密码有效期。第三优先级才是搭日志集中存储这个需要一点时间但做完就一劳永逸了。按照这个顺序来通常一到两周以内就能把主机层面所有的问题整改完准备复测。5.2 和测评师沟通的几个小技巧不要撒谎但也不要什么都往外说现场沟通的时候有些单位的对接人特别紧张恨不得把自己的家底都翻出来给测评师看这种态度其实没必要。测评师只关心与检查项相关的事实不会因为你业务细节没讲清楚就给你判不符合。反过来也不要为了显得自己安全工作做得好就夸大其词比如明明没有做备份恢复演练却说每周都做等测评师追问上次演练的日期和结果时答不上来反而更被动。我常和配合测评的运维同事说的一句话是知道就是知道不知道就说不知道但要补充一句“这个问题我们后续会核查确认”。测评不是吹牛比赛说得越多漏洞越多稳住心态如实回答有理有据地展示现有配置大部分问题都能沟通解决。还有一点如果某项确实没做到先别急着找借口直接承认现状然后简要给出整改计划比如“这个问题我们注意到了计划下周通过调整XX配置来解决”测评师听到这个通常就不会揪着不放。5.3 最终结果一个“基本符合”背后的意义经过一轮完整的测评和整改复测之后这家单位最终拿到的是“基本符合”的结论这对一个业务系统而言已经是一个比较理想的结果了毕竟三级等保要想拿到“符合”的满分评价确实需要长期稳定运行并保留大量真实可查的运营记录不是临时整改能突击出来的。在这整个流程里最让我有成就感的事情反而不是最后那份报告而是看到对方的运维团队在配合整改的过程中真正理解了一条条安全要求背后的逻辑。等保不是写一堆制度文件装点门面它是要让你在系统出问题的时候真的能够拿出依据、追溯全过程、快速恢复业务这才是这套体系真正的价值所在。