麒麟服务器等保三级配置实战：从SSH双因子到kysec策略落地

1. 这不是“打补丁”，而是给服务器穿防弹衣：麒麟等保配置的真实定位

很多人第一次接触“国产麒麟服务器等保配置”，第一反应是：“不就是改几个密码、关几个端口、装个杀毒软件？”——这种理解，轻则导致测评反复失败，重则让整套系统在正式检查中被一票否决。我亲身参与过7个政务云平台的等保三级落地，其中3次返工都源于对“麒麟等保配置”本质的误判：它根本不是一套可零散拼凑的操作清单，而是一套覆盖身份鉴别、访问控制、安全审计、入侵防范、可信验证、数据完整性与保密性六大能力域的闭环防御体系。你面对的不是一台Linux服务器，而是一个被纳入国家网络安全等级保护2.0框架下的“受监管实体”。麒麟V10（SP1/SP2）、Kylin V4等主流版本，其内核深度集成了国密SM2/SM3/SM4算法支持、强制访问控制（MAC）模块、统一身份认证中间件和可信启动链，这些不是“可选功能”，而是等保三级要求中明确写入《GB/T 22239-2019》的“应”级条款。换句话说，如果你没启用麒麟自带的kysec策略引擎，没配置基于SM2证书的SSH双向认证，没打开auditd的细粒度规则并对接到日志审计平台，那你的配置再“干净”，也只是一具没有骨骼的躯壳。这篇文章不讲教科书定义，只讲我在某省大数据中心现场踩过的坑、调过的参数、被测评老师当场指出的5类高频失分点，以及如何用一套可验证、可回溯、可批量部署的脚本体系，把“等保要求”真正变成服务器上跑得起来的进程、看得见的日志、拦得住的攻击。

2. 等保三级在麒麟服务器上的硬性落点：从条款到命令行的一一映射

等保三级不是抽象概念，它被拆解为81项具体测评指标，其中直接作用于操作系统层的有32项。麒麟服务器作为国产化底座，其配置必须与这些指标形成可审计、可验证的映射关系。下面这张表，是我根据《等保2.0基本要求》操作系统部分（附录A）和麒麟V10 SP2官方安全加固指南交叉比对后整理的核心映射清单，每一项都对应一条可执行、可验证的命令或配置路径：

这张表的价值在于：它把“等保要求”翻译成了运维工程师每天打交道的命令行世界。比如条款“c) 安全审计”，很多团队只是简单运行systemctl start auditd就以为完成了，但测评老师会直接SSH进来，敲出ausearch -m execve -ts 10min，如果返回空，说明你的规则根本没生效——因为auditctl -a always,exit -F arch=b64 -S execve这条规则，必须写进/etc/audit/rules.d/10-os.rules并执行augenrules --load才能持久化。再比如“e) 可信验证”，你以为装了TPM2.0模块就万事大吉？麒麟V10 SP2默认不启用TPM2.0驱动，你得先确认lsmod | grep tpm_tis有输出，再执行kysecctl add-policy --type trusted-boot --file /boot/vmlinuz-$(uname -r)，最后用kysecctl verify-policy验证签名是否有效。这些细节，文档里不会逐条告诉你，但测评现场，错一个就扣分。

3. 从“能连上”到“连得稳”：麒麟SSH双因子认证的实操陷阱与填坑指南

SSH是麒麟服务器最核心的远程管理通道，等保三级明确要求“应对登录用户进行身份鉴别，且鉴别信息具有唯一性、机密性”。在麒麟生态下，“唯一性+机密性”的标准解法是SM2数字证书+口令双因子认证，而非简单的口令或密钥登录。但这个看似标准的流程，在实操中布满了极易被忽略的“地雷”。

3.1 SM2证书生成与部署的三道坎

第一道坎：证书签发机构（CA）的选择。很多团队图省事，用OpenSSL自建RSA CA，这直接违反等保“应使用国家密码管理局认可的密码算法”的要求。正确做法是使用麒麟官方提供的kyca工具（集成在kysec-tools包中），它内置SM2根证书和签发流程。执行kyca init会生成符合GM/T 0015-2012标准的SM2根证书，所有终端证书必须由该CA签发。

第二道坎：证书格式与路径的强耦合。麒麟SSH服务（openssh-server）对SM2证书有严格路径要求：/etc/ssh/kysec_ca.crt（CA证书）、/etc/ssh/kysec_user.crt（用户证书）、/etc/ssh/kysec_user.key（用户私钥）。私钥必须用SM4加密（openssl sm4 -in user.key -out user.key.sm4 -k "passphrase"），且/etc/ssh/sshd_config中必须指定KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256（启用ECDH密钥交换）和HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa（兼容RSA回退）。漏掉任何一个路径或算法，SSH服务将无法启动。

第三道坎：PAM模块的加载顺序。双因子认证依赖PAM链式调用：先验证SM2证书（pam_kysec.so），再验证口令（pam_pwquality.so）。/etc/pam.d/sshd文件中，这两行必须按此顺序且不可注释：

auth [success=done default=ignore] pam_kysec.so debug auth [default=bad success=ok] pam_pwquality.so retry=3 minlen=12 difok=3

如果顺序颠倒，系统会先要求输密码，再提示“证书验证失败”，用户体验极差；如果pam_kysec.so行缺少debug参数，故障时无日志，排查如同盲人摸象。

3.2 实测中的“连接成功但认证失败”怪现象

有一次，我们为某市公积金中心部署完双因子，测试人员能SSH连上，但输入正确口令后仍被拒绝。journalctl -u sshd -f日志显示pam_kysec(sshd:auth): failed to load certificate from /etc/ssh/kysec_user.crt。排查发现，证书文件权限是644，而pam_kysec.so模块要求私钥文件权限必须为600，证书文件为644，且属主必须是root:root。一个chmod 600 /etc/ssh/kysec_user.key就解决了问题。更隐蔽的是SELinux上下文：/etc/ssh/kysec_*文件的SELinux类型必须是ssh_key_t，否则pam_kysec会被拒绝读取。执行restorecon -Rv /etc/ssh/才是终极解决方案。

3.3 双因子的“降级开关”与应急方案

生产环境不能没有应急通道。我们设计了一个“降级开关”：在/etc/ssh/sshd_config中保留PasswordAuthentication yes，但通过Match User admin块将其限制为仅对特定管理员账号开放，并配合fail2ban的[sshd-dual]jail，对该账号的失败登录进行IP封禁。同时，编写一个emergency-disable-2fa.sh脚本，一键停用pam_kysec模块（备份原/etc/pam.d/sshd，替换为仅含口令认证的版本），并重启SSHD。脚本执行前会自动发送告警邮件至运维组，并记录操作日志到/var/log/kysec/emergency.log。这个设计既满足等保“应提供应急处理机制”的要求，又避免了证书丢失导致的“锁死”风险。

4. kysec策略引擎：麒麟服务器的“免疫系统”配置全解析

如果说SSH双因子是“门禁”，那么kysec策略引擎就是麒麟服务器的“免疫系统”——它负责实时监控、拦截、响应一切偏离基线的行为。等保三级中“入侵防范”、“可信验证”、“安全审计”三大能力域，超过70%的得分点都依赖kysec的正确配置。但官方文档对此着墨甚少，很多团队把它当成“高级功能”束之高阁，结果在测评中因“未启用主机入侵检测”、“未实施可信验证”等条款大面积失分。

4.1 kysec的四大核心模块与启动逻辑

kysec不是一个单一服务，而是由四个协同工作的守护进程组成：

• kysecd：主守护进程，负责策略加载、状态管理、与其他模块通信。必须开机自启（systemctl enable kysecd）。
• kysec-realtime：实时防护模块，监控进程创建、文件写入、网络连接等事件。需手动启用（kysecctl enable realtime）。
• kysec-audit：审计增强模块，将kysec事件写入/var/log/kysec/audit.log，并与系统auditd日志关联。需配置/etc/kysec/audit.conf指定日志路径和级别。
• kysec-trusted：可信验证模块，负责度量启动过程、内核模块、关键配置文件哈希值。依赖TPM2.0芯片，需先执行tpm2_clear初始化芯片。

这四个模块的启动有严格依赖顺序：必须先启动kysecd，再启用kysec-realtime和kysec-trusted，最后配置kysec-audit。任何一步顺序错误，都会导致模块无法正常工作。例如，若先执行kysecctl enable trusted而kysecd未运行，命令会静默失败，kysecctl status显示trusted: disabled，但无任何错误提示。

4.2 从零开始构建一条可落地的kysec策略链

以“禁止非授权进程访问数据库端口”为例，这是等保“访问控制”条款的典型场景。我们不直接写iptables规则，而是用kysec构建策略链：

1. 定义目标进程：kysecctl add-process --name mysqld --path /usr/bin/mysqld --hash sha256:abc123...
2. 定义网络规则：kysecctl add-network --name mysql-access --proto tcp --dport 3306 --action allow --process mysqld
3. 定义拒绝规则（兜底）：kysecctl add-network --name block-all --proto tcp --dport 3306 --action deny --process "*"
4. 激活策略：kysecctl enable policy --name mysql-access; kysecctl enable policy --name block-all

执行后，kysecctl list-policy会显示两条策略，kysecctl status中realtime状态变为active。此时，任何非mysqld进程尝试连接3306端口，都会被kysec-realtime拦截，并在/var/log/kysec/audit.log中记录DENY network connect to 3306 by /bin/bash。这个过程比iptables更精准（基于进程名而非PID），且策略可导出为JSON文件（kysecctl export-policy > mysql-policy.json），便于在多台服务器批量部署。

4.3 kysec策略的“灰度上线”与回滚机制

生产环境不敢直接全量启用新策略。我们的做法是：先用kysecctl set-mode --mode test将kysec设为测试模式，此时所有DENY动作只记录日志，不实际拦截。持续观察/var/log/kysec/audit.log24小时，统计被拦截的合法行为（如监控脚本、备份工具），然后在策略中为其添加白名单。确认无误后，再执行kysecctl set-mode --mode enforce切为强制模式。每次策略变更，都用kysecctl backup-policy --name pre-v1.2做快照。若上线后出现业务异常，kysecctl restore-policy --name pre-v1.2可在30秒内回滚到上一版本。这个机制，让我们在某省级医保平台上线时，将策略误配导致的业务中断时间从数小时压缩到3分钟以内。

5. 日志审计的“最后一公里”：从auditd到等保报告的完整证据链

等保测评中，“安全审计”条款的失分率常年居高不下，原因不是不会配置auditd，而是日志无法形成可追溯、可验证、可呈现的证据链。测评老师要的不是“日志存在”，而是“你能证明在X年X月X日X时X分，用户A执行了sudo rm -rf /，该行为被完整记录，且日志未被篡改”。麒麟服务器的auditd配置，必须围绕这个终极目标展开。

5.1 auditd的“黄金八条”持久化规则

很多团队只加了-w /etc/passwd -p wa -k passwd_change这一条，远远不够。我们总结出必须写入/etc/audit/rules.d/10-os.rules的八条核心规则（已通过麒麟V10 SP2实测）：

# 1. 监控关键系统调用 -a always,exit -F arch=b64 -S execve -k execve # 2. 监控特权进程 -a always,exit -F path=/usr/bin/sudo -F perm=x -k sudo_exec # 3. 监控用户账户变更 -w /etc/passwd -p wa -k user_mod -w /etc/shadow -p wa -k shadow_mod # 4. 监控SSH配置变更 -w /etc/ssh/sshd_config -p wa -k sshd_config_mod # 5. 监控防火墙规则变更 -w /sbin/iptables -p x -k iptables_mod -w /sbin/ip6tables -p x -k ip6tables_mod # 6. 监控关键目录（递归） -w /var/log/audit/ -p wa -k audit_log # 7. 监控kysec策略变更 -w /etc/kysec/ -p wa -k kysec_policy # 8. 监控系统时间修改 -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change

每条规则后的-k标签至关重要，它是ausearch命令的检索关键字。例如，ausearch -k sudo_exec能精准筛选出所有sudo执行记录，而ausearch -m execve会混入大量无关的shell命令。规则写完，必须执行augenrules --load，否则重启后失效。

5.2 日志的“防篡改”与“防丢失”双保险

等保要求“审计记录应受到保护，避免受到未预期的删除、修改或覆盖”。单靠logrotate不够，我们采用双保险：

• 防篡改：启用auditd的disk_full_action = halt（磁盘满时停止系统，而非覆盖日志），并在/etc/audit/rules.d/99-disk-full.rules中添加-w /var/log/audit/ -p wa -k audit_disk，监控日志目录自身。
• 防丢失：配置rsyslog将audit日志实时转发到独立的日志审计服务器。/etc/rsyslog.d/50-audit.conf内容如下：

  $ModLoad imfile $InputFileName /var/log/audit/audit.log $InputFileTag audit: $InputFileStateFile audit-state $InputRunFileMonitor *.* @@log-audit-server:514

  关键是@@（TCP协议）而非@（UDP），确保日志不丢包；$InputFileStateFile保证rsyslog崩溃重启后能从断点续传。

5.3 生成测评老师要的“证据截图”

测评时，老师会要求提供“近3个月的登录失败记录”、“关键配置文件修改记录”等。我们用aureport命令自动生成标准化报告：

# 生成近30天登录失败报告（CSV格式，可直接导入Excel） aureport -au -ts $(date -d '30 days ago' +%m/%d/%Y) --csv > /tmp/login-fail-30d.csv # 生成/etc/shadow被修改的详细记录（含执行用户、命令、时间） aureport -f -i -ts $(date -d '90 days ago' +%m/%d/%Y) | grep "shadow_mod" > /tmp/shadow-mod-90d.txt # 生成所有sudo执行记录（去重，按时间排序） aureport -m -i --key sudo_exec | sort -k1,1 | uniq > /tmp/sudo-exec-all.txt

这些命令被封装进/usr/local/bin/kysec-audit-report.sh，运维人员只需执行sudo kysec-audit-report.sh 30，即可生成包含时间戳、签名、页眉页脚的PDF报告（调用wkhtmltopdf转换）。报告首页注明“本报告由麒麟V10 SP2服务器自动生成，日志哈希值：sha256sum /var/log/audit/audit.log”，完美回应“日志真实性”质疑。

6. 等保配置的“交付物”清单：一份能让测评老师点头的验收包

等保测评不是技术演示，而是一场严谨的合规性审查。你提交的“配置成果”，必须是一份结构清晰、证据确凿、可快速验证的交付物包。我们为每个项目准备的标准交付包，包含以下六个核心文件，缺一不可：

6.1 《麒麟服务器等保配置基线说明书》（PDF）

这不是配置文档，而是面向测评老师的“合规说明书”。它用表格形式，逐条列出等保三级操作系统部分的32项要求，每项包含：

• 条款原文（摘自GB/T 22239-2019）
• 麒麟实现方式（如“启用kysec-realtime模块，策略ID：mysql-access”）
• 验证方法（如“执行kysecctl list-policy \| grep mysql-access，返回策略详情”）
• 验证截图（带时间戳、服务器主机名、命令行输出的截图）
• 责任人与日期（配置人、审核人、生效日期）

这份说明书让测评老师无需登录服务器，就能在10分钟内完成80%的条款初审。

6.2 《配置脚本与执行日志》（ZIP包）

包含所有自动化脚本及其执行记录：

• install-kysec.sh：安装kysec工具链、初始化TPM2.0、加载默认策略
• config-ssh-2fa.sh：生成SM2 CA、签发用户证书、配置PAM和sshd
• setup-audit.sh：写入“黄金八条”规则、配置rsyslog转发、设置磁盘保护
• verify-all.sh：一键执行所有验证命令（sestatus,kysecctl status,ausearch -k ...等），输出HTML格式报告
• install-kysec.log,config-ssh-2fa.log等：每个脚本执行时的完整stdout/stderr日志，带时间戳

提示：所有脚本开头必须有#!/bin/bash -e，确保任一命令失败即退出，避免“半成品”配置。日志文件必须用script命令捕获，而非简单重定向，以保留颜色和交互信息。

6.3 《关键日志样本》（TXT文件）

提供真实、脱敏的日志片段，证明审计功能有效：

• /var/log/audit/audit.log的100行样本（含execve、sudo、passwd_mod事件）
• /var/log/kysec/audit.log的50行样本（含kysec-realtime拦截记录）
• /var/log/secure的30行样本（含SSH登录成功/失败、PAM认证日志）
• 所有样本均用sed脱敏IP、用户名、主机名，但保留时间戳、进程ID、事件类型等关键字段。

6.4 《应急响应预案》（DOCX）

明确告知测评老师：“如果配置出问题，我们怎么救？” 包含：

• 双因子失效：emergency-disable-2fa.sh脚本位置、执行步骤、预计恢复时间（<2分钟）
• kysec误拦截：kysecctl set-mode --mode test切换步骤、日志分析方法（ausearch -m avc）
• auditd磁盘满：auditctl -s查看状态、auditctl -e 0临时禁用、augenrules --load恢复
• 所有预案均经过实测，并附上测试录像链接（内部NAS地址）。

6.5 《第三方工具合规声明》（PDF）

等保要求“使用的安全产品应通过国家相关认证”。我们为所有引入的工具提供声明：

• kysec-tools：麒麟官方发布，符合《信息安全技术 操作系统安全技术要求》（GB/T 20272）
• clamd（国密版）：通过国家密码管理局商用密码检测中心检测，证书号：GM/T 00XX-202X
• rsyslog：开源社区版，但配置符合《等保2.0安全计算环境测评要求》中关于日志传输的条款

6.6 《配置差异报告》（HTML）

用diff对比两台同型号麒麟服务器的配置，证明“一致性”：

• diff -r /etc/ssh /etc/kysec /etc/audit /etc/pam.d /etc/rsyslog.d server1 server2 > config-diff.html
• 报告高亮显示所有差异，并标注“允许差异”（如主机名、IP地址）和“禁止差异”（如/etc/kysec/policy.json内容）
• 证明你的配置不是“手工调出来的”，而是“可复制、可推广”的标准化成果。

这份交付包，是我们过去7个项目全部一次通过等保三级测评的核心武器。它把技术配置，转化成了测评老师能看懂、能验证、能签字的合规证据。当你把这份包交到测评老师手上时，他翻看几页，就会说：“嗯，这个团队是真干过活的。”

我在某省政务云项目收尾时，测评组长指着《配置基线说明书》对我说：“你们这份文档，比我们自己写的测评指南还清楚。”那一刻我明白，等保配置的终点，从来不是敲完最后一行命令，而是让所有证据，安静、清晰、无可辩驳地躺在那里，等待被看见。