CentOS集群的运维安全加固，核心难点不在于单机配置，而在于“批量一致性”和“最小权限的可持续维护”。很多团队在几十台甚至上百台节点的集群里，安全策略最终失效，往往是因为登录入口分散、配置漂移、审计缺失。所以加固方案必须围绕“统一入口、集中管控、自动核查”这三个原则来设计，而不是简单地把单机等保条款复制到每一台机器上。

先说最基础的SSH访问层。CentOS 7和CentOS Stream 8/9在ssh配置上差异不大，但集群环境里必须禁用密码登录，全部改用密钥。这里有一个容易被忽略的点：密钥的私钥不能存放在跳板机的默认目录，更不能多人共用一把私钥。建议为每个运维人员生成独立密钥对，并在集群所有节点的authorized_keys里通过from=参数限制来源IP。例如：

from="10.20.1.11",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAB3Nza... ops_zhang@bastion

这样即使私钥泄露，攻击者也无法从其他IP直接登录，同时限制了端口转发和代理转发，防止横向移动。跳板机本身要单独做加固，只开放22端口，并且安装fail2ban或使用firewalld的rich rule对连续失败的IP做临时封禁。

接下来是账户与权限管理。集群环境最怕的是root账户直接登录和sudo权限泛滥。建议在LDAP或FreeIPA未部署的情况下，先用Ansible统一创建普通运维账户，并配置sudoers规则。不要直接编辑/etc/sudoers，而是在/etc/sudoers.d/下放一个统一管理的文件，内容类似：

%opsgroup ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *, /usr/bin/journalctl, /usr/bin/tail -n 100 /var/log/*

这样运维人员只能执行指定的只读命令，需要重启服务或修改配置时，必须走变更流程临时提权。对于需要执行脚本的任务，建议通过Ansible的become机制在受控节点上执行，而不是给个人账户过大的sudo权限。

防火墙策略在集群里不能只靠默认的firewalld zone。生产集群内部节点之间的通信端口要精确到服务，例如Zookeeper的2181、2888、3888，Kafka的9092，Elasticsearch的9200和9300。建议用Ansible模板统一生成每个节点的firewalld规则，并开启rich rule记录被拒绝的连接。一个常见的错误是集群内网完全放开，这会导致单点被攻破后横向移动毫无阻碍。正确做法是：管理网段可以访问所有节点的22端口，数据网段只开放服务端口，存储网段只开放NFS或Ceph相关端口。

系统审计和日志集中是很多CentOS集群的短板。rsyslog默认只记录本地，一旦节点被入侵，本地日志很可能被清除。建议所有节点将auth、authpriv、cron、kern日志通过TCP发送到集中的日志服务器，并使用imfile模块采集应用日志。日志服务器上再部署一套简单的分析脚本或使用ELK做索引。同时必须开启auditd，对/etc/passwd、/etc/shadow、/etc/sudoers、/etc/ssh/sshd_config等关键文件的写操作进行监控。audit规则示例：

-w /etc/passwd -p wa -k identity_change
-w /etc/shadow -p wa -k identity_change
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/ssh/sshd_config -p wa -k sshd_config_change

这些规则要由配置管理工具统一下发，并定期核查auditd服务状态，防止被恶意停止。

内核参数加固在集群环境下需要谨慎。有些安全基线会建议开启ASLR、禁用ICMP重定向、开启SYN cookie等，这些对集群节点通常没有副作用，可以直接应用。但涉及网络栈的参数，比如net.ipv4.tcp_tw_reuse、net.ipv4.ip_local_port_range，如果调整不当会影响高并发服务的连接建立。建议先在测试集群验证，再通过sysctl.d统一推送。对于容器化或大数据场景，vm.max_map_count、fs.file-max等参数需要根据实际负载调整，不能盲目套用通用安全基线。

软件包和漏洞管理方面，CentOS 7已经停止维护，CentOS Stream 8/9的更新节奏和传统RHEL不同。如果集群还在运行CentOS 7，必须尽快迁移，因为安全补丁已经停止。对于无法立即迁移的节点，至少要用yum-plugin-security或dnf updateinfo列出安全更新，并评估影响。建议搭建本地镜像仓库，所有节点只从内网仓库安装和更新软件包，避免外部源被劫持。同时用Ansible定期执行rpm -Va检查关键文件的完整性，重点看/bin、/sbin、/usr/bin、/usr/sbin下是否有文件被替换。

服务加固层面，CentOS集群里常见的Redis、Elasticsearch、MongoDB等组件默认配置非常不安全。Redis必须设置requirepass，并绑定内网IP，禁止protected-mode no。Elasticsearch要开启X-Pack或至少设置网络绑定和防火墙白名单。MongoDB必须开启认证，并禁用HTTP状态接口。这些配置要纳入Ansible的角色模板，确保新加入集群的节点自动应用安全基线，而不是依赖人工手动配置。

还有一个经常被忽略的点是定时任务和启动项。攻击者在获得低权限账户后，往往会通过crontab或systemd timer做持久化。建议用Ansible定期收集所有节点的crontab列表和/etc/cron.d、/etc/cron.daily等目录内容，与基线做比对。对于systemd服务，用systemctl list-unit-files --type=service | grep enabled输出所有开机自启服务，人工审核是否有异常项。同时检查/root/.ssh/authorized_keys和每个普通用户家目录下的.ssh目录，防止攻击者留下后门密钥。

最后是配置漂移的持续检测。安全加固不是一次性工作，集群运行几个月后，总会有手动修改、临时放开防火墙、调试时关闭SELinux等情况。建议部署一套轻量级的合规检查工具，比如用Ansible的check模式定期跑安全基线playbook，或者用Inspec、Lynis等工具生成报告。重点检查项包括：SELinux是否处于enforcing、防火墙服务是否运行、SSH是否禁用密码登录、auditd是否运行、关键文件权限是否正确。检查结果要输出到集中平台，并设置告警，发现漂移后自动触发修复或通知人工介入。

CentOS集群的安全加固，本质上是用工程化手段对抗配置漂移和人为疏忽。单点配置再完美，没有自动化下发和持续核查，最终都会退化。把SSH入口、账户权限、防火墙、审计、内核参数、服务配置、持久化检查全部纳入Ansible等配置管理工具的管控范围，才能让几十台节点的安全状态保持一致，并且在出现问题时快速定位和恢复。