直接告诉你结论：这篇文讲的是帮一家单位做等保测评时，我在主机层面梳理出来的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: '$3==0{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 最终结果：一个“基本符合”背后的意义
经过一轮完整的测评和整改复测之后，这家单位最终拿到的是“基本符合”的结论，这对一个业务系统而言已经是一个比较理想的结果了，毕竟三级等保要想拿到“符合”的满分评价，确实需要长期稳定运行并保留大量真实可查的运营记录，不是临时整改能突击出来的。在这整个流程里，最让我有成就感的事情，反而不是最后那份报告，而是看到对方的运维团队在配合整改的过程中真正理解了一条条安全要求背后的逻辑。等保不是写一堆制度文件装点门面，它是要让你在系统出问题的时候，真的能够拿出依据、追溯全过程、快速恢复业务，这才是这套体系真正的价值所在。
