1. 项目概述：为什么要在Linux服务器上搞“三权分立”？

最近在给一个金融客户的系统做等保三级测评的加固，对方审计老师提了个硬性要求：所有生产服务器的操作系统账号权限必须实现“三权分立”。这词儿听起来挺唬人，其实就是把系统管理员的权力拆开，不让一个人既当“裁判员”又当“运动员”。在Linux世界里，这通常意味着要把传统的、拥有至高无上权力的root用户给“架空”，把它的权限分给三个不同的角色：系统管理员、安全管理员和审计管理员。

你可能觉得，服务器嘛，有个root密码不就行了，搞这么复杂干嘛？我一开始也这么想，但真正深入金融、政务这些对安全要求严苛的领域，你就会发现，单靠一个root账号和复杂的密码策略，根本防不住内部风险。想象一下，如果运维人员A拥有全部权限，他既可以修改业务配置，又能清空操作日志，万一出了事儿，连个追查的痕迹都留不下。等保三级的要求，核心就是“可审计、可追溯、权限最小化”。“三权分立”就是这个理念在操作系统层面的落地，它强制实现了权限的制衡。系统管理员负责日常运维，但不能动审计日志；安全管理员负责策略配置，但不能直接操作业务；审计管理员专门看日志，但没有任何修改权限。三个人互相监督，谁也别想一手遮天。

这次要做的，就是在CentOS 7/Rocky Linux 8这类主流的企业级Linux发行版上，不依赖任何第三方商业软件，纯粹利用系统自带的sudo和visudo工具，搭建一套符合等保三级要求的“三权分立”权限体系。整个过程涉及用户规划、sudoers策略精细编写、日志审计配置等多个环节，任何一个细节没考虑到，都可能被测评机构扣分。下面我就把这次实战配置的全过程、踩过的坑以及核心的sudoers规则写法，毫无保留地分享出来。

2. 核心思路与角色权限设计拆解

在动手敲命令之前，我们必须先把三个角色的权责边界画清楚。照搬等保的条文没用，得把它翻译成Linux系统里具体能执行和不能执行的命令集合。

2.1 三权角色定义与职责映射

我们设计三个系统用户组和对应的用户，用组来管理权限是更清晰的做法：

1. 系统管理员 (sysadmin)：

   • 核心职责：日常系统运维。包括软件安装（yum）、服务启停（systemctl）、进程管理、基础网络配置、磁盘空间管理等。
   • 权限边界：不能查看或修改审计日志文件，不能修改其他用户的密码，不能修改sudoers文件本身。他的目标是“维持系统运行”。
   • 类比：就像大楼的物业工程部，可以维修水电、打扫卫生，但不能调看监控录像，也不能修改门禁规则。

2. 安全管理员 (secadmin)：

   • 核心职责：负责安全基线。包括用户账号的创建、删除、密码策略设置（chage）、防火墙规则配置（firewall-cmd）、sudoers策略的修改（这是关键）、以及关键系统文件（如/etc/passwd,/etc/shadow,/etc/ssh/sshd_config）的权限管理。
   • 权限边界：不能直接重启业务服务，不能安装非授权的软件包，不能清空或修改系统日志。他的目标是“制定并守护安全规则”。
   • 类比：就像公司的安保部和HR的结合体，负责制定门禁规则、审核人员进出，但不负责具体办公设备的维修。

3. 审计管理员 (auditadmin)：

   • 核心职责：专职审计与监督。拥有读取所有系统日志（/var/log/secure,/var/log/messages,/var/log/audit/等）的权限，特别是sudo命令的执行日志。可以使用journalctl、ausearch等工具进行日志分析。
   • 权限边界：只有只读权限。不能执行任何修改系统状态、文件、配置的命令。他的目标是“记录一切，只读不写”。
   • 类比：就像独立的审计员或监控室值班员，可以查看所有区域的监控录像和操作记录，但无权操作任何设备。

2.2 技术实现路径选择：为什么是sudo？

实现权限分离，主要有三种思路：1）用su切换；2）用权限位（setuid）的特殊程序；3）用sudo。前两种在安全性和灵活性上都有明显缺陷。

• su需要知道目标用户的密码，不符合权限最小化和密码保密原则。
• setuid程序编写复杂，容易引入安全漏洞。sudo是当前最成熟、最灵活的方案。它不需要知道root密码，通过/etc/sudoers文件精细控制某个用户能以谁的身份、运行哪些命令、在哪些主机上运行。更重要的是，sudo自带完整的日志功能，所有通过sudo执行的命令都会被记录到/var/log/secure（默认）或专门的审计日志中，天然满足审计要求。

我们的核心工作，就是为上面定义的三个角色，编写三套不同的、高度细化的sudoers规则。这里最大的挑战在于“粒度控制”：既要给够权限让他们能干活，又要严防越权。比如，给系统管理员yum权限时，必须禁止他使用yum erase或yum remove来删除关键的审计或安全组件。

3. 实操准备与环境初始化

理论清晰后，我们进入实战环节。假设我们在一台全新的Rocky Linux 8.6服务器上操作。

3.1 创建用户与用户组

首先，创建三个核心用户组和对应的用户。我习惯用useradd命令的-r参数创建系统用户（不创建家目录，UID在特定范围），但为了管理方便，这里创建普通用户。

# 创建三个核心用户组 sudo groupadd sysadmin sudo groupadd secadmin sudo groupadd auditadmin # 创建系统管理员用户，加入sysadmin组 sudo useradd -m -G sysadmin sysadmin1 sudo passwd sysadmin1 # 设置一个强密码 # 创建安全管理员用户，加入secadmin组 sudo useradd -m -G secadmin secadmin1 sudo passwd secadmin1 # 创建审计管理员用户，加入auditadmin组 sudo useradd -m -G auditadmin auditadmin1 sudo passwd auditadmin1 # 可选：创建一个运维用户组，用于存放其他普通运维人员，他们可以继承sysadmin的部分权限 sudo groupadd ops sudo useradd -m -G ops ops1 sudo passwd ops1

注意：在生产环境中，这些账号的密码必须符合强密码策略（长度、复杂度、定期更换），并且建议与LDAP/AD域账号集成，实现统一认证。这里为了演示使用本地密码。

3.2 备份与visudo安全操作规范

接下来要修改/etc/sudoers文件，这是整个配置中最危险的一步。这个文件语法严格，一旦写错，可能导致所有sudo权限失效，甚至把自己锁在系统外面。务必遵守以下铁律：

1. 永远使用visudo命令编辑：visudo会在保存前检查语法，如果出错会提示，避免直接vim /etc/sudoers导致系统瘫痪。
2. 先备份：sudo cp /etc/sudoers /etc/sudoers.bak.$(date +%Y%m%d)
3. 在测试环境验证：所有规则先在非生产的测试机上验证通过，再应用到生产环境。
4. 保留一个应急的root会话：在修改sudoers时，务必打开另一个已登录的root终端会话。如果新配置导致无法sudo，还可以用这个root会话回滚。

4. 核心sudoers策略编写详解

现在进入最核心的部分：为三个角色编写sudoers策略。我们将策略写在/etc/sudoers.d/目录下的独立文件中，这是推荐的做法，便于管理。每个文件对应一个角色或一个功能模块。

4.1 系统管理员 (sysadmin) 策略

系统管理员需要的是“执行权”，但必须是受控的。我们创建一个文件/etc/sudoers.d/10-sysadmin。

sudo visudo -f /etc/sudoers.d/10-sysadmin

文件内容如下，每一行我都加了详细注释：

# 系统管理员策略 - 允许执行日常运维命令，禁止接触审计和安全配置 # 规则生效于sysadmin组的成员 %sysadmin ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *, /usr/bin/systemctl start *, /usr/bin/systemctl stop *, /usr/bin/systemctl restart *, /usr/bin/systemctl reload * # 说明：允许管理所有服务的状态、启动、停止、重启、重载。但注意，这里没有包含 `enable`/`disable`（开机自启），因为那属于系统配置变更，更应由安全管理员控制。 %sysadmin ALL=(ALL) NOPASSWD: /usr/bin/yum install *, /usr/bin/yum update *, /usr/bin/yum check-update # 说明：允许安装、更新软件包，检查更新。明确禁止了 `yum remove` 和 `yum erase`，防止误删关键组件。 %sysadmin ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat -tulnp, /bin/ps aux, /usr/bin/top, /usr/bin/htop # 说明：允许使用网络和进程查看工具，用于故障排查。这些都是只读命令。 %sysadmin ALL=(ALL) NOPASSWD: /bin/df -h, /usr/bin/du -sh *, /bin/lsblk, /usr/sbin/fdisk -l # 说明：允许查看磁盘和文件系统使用情况，同样是只读。 %sysadmin ALL=(ALL) NOPASSWD: /bin/cat /var/log/messages, /bin/cat /var/log/cron # 说明：允许查看部分系统日志，用于判断系统状态。但明确禁止查看 `/var/log/secure` 和 `/var/log/audit/`（审计日志）。 %sysadmin ALL=(ALL) NOPASSWD: /usr/bin/tail -f /var/log/messages, /usr/bin/tail -f /var/log/myapp/*.log # 说明：允许实时追踪应用日志，方便排障。 # 关键禁止项：通过 ! 来显式拒绝某些命令，防止通过路径或其他方式绕过 %sysadmin ALL=(ALL) !/usr/bin/passwd, !/usr/sbin/visudo, !/bin/vi /etc/sudoers*, !/bin/cat /var/log/secure*, !/bin/cat /var/log/audit/*, !/usr/sbin/ausearch, !/usr/sbin/aureport # 说明：禁止修改密码、编辑sudoers、查看审计日志。这是实现“权责分离”的关键。

实操心得：sudoers中命令的路径必须使用绝对路径，防止通过设置PATH环境变量来执行恶意程序。可以使用which command来查找命令的绝对路径。另外，通配符*要谨慎使用，比如systemctl *就太危险了，必须明确列出允许的操作。

4.2 安全管理员 (secadmin) 策略

安全管理员权限更大，但更聚焦。创建文件/etc/sudoers.d/20-secadmin。

sudo visudo -f /etc/sudoers.d/20-secadmin

# 安全管理员策略 - 负责用户、权限和核心安全配置 %secadmin ALL=(ALL) NOPASSWD: /usr/sbin/visudo, /usr/bin/vi /etc/sudoers*, /usr/bin/cat /etc/sudoers* # 说明：核心权限！允许修改和查看sudoers文件本身，这是安全管理员的核心职责。 %secadmin ALL=(ALL) NOPASSWD: /usr/sbin/useradd, /usr/sbin/userdel, /usr/sbin/usermod, /usr/bin/passwd, /usr/bin/chage # 说明：允许管理用户账号、密码和密码策略（chage）。 %secadmin ALL=(ALL) NOPASSWD: /usr/sbin/groupadd, /usr/sbin/groupdel, /usr/sbin/groupmod # 说明：允许管理用户组。 %secadmin ALL=(ALL) NOPASSWD: /bin/chown, /bin/chmod # 说明：允许修改文件所有者和权限，用于修复错误权限或设置安全基线。 %secadmin ALL=(ALL) NOPASSWD: /usr/bin/systemctl enable *, /usr/bin/systemctl disable * # 说明：允许设置服务开机自启或禁用，这是系统安全配置的一部分（比如禁用不必要的服务）。 %secadmin ALL=(ALL) NOPASSWD: /usr/bin/firewall-cmd * # 说明：允许管理firewalld防火墙的所有规则。这是网络安全的关键。 %secadmin ALL=(ALL) NOPASSWD: /usr/sbin/semanage, /usr/sbin/restorecon, /usr/bin/chcon # 说明：允许管理SELinux策略（如果启用），这是等保三级的高阶要求。 # 关键禁止项：安全管理员不应直接操作业务和审计日志 %secadmin ALL=(ALL) !/usr/bin/systemctl start *, !/usr/bin/systemctl stop *, !/usr/bin/systemctl restart *, !/usr/bin/yum install *, !/bin/cat /var/log/audit/*, !/usr/sbin/ausearch # 说明：禁止启停服务、安装软件、查看原始审计日志。他只能配置策略，不能直接“动手”。

注意事项：给secadmin开放visudo权限是风险最高的操作。必须确保secadmin账号的密码强度极高，并且操作行为本身会被sudo日志和auditd（审计守护进程）记录。在实际中，甚至可以要求secadmin执行visudo时，需要另一个管理员（如sysadmin）进行二次验证（这需要更复杂的PAM或双人授权系统支持）。

4.3 审计管理员 (auditadmin) 策略

审计管理员的策略最简单，也最严格：只读。创建文件/etc/sudoers.d/30-auditadmin。

sudo visudo -f /etc/sudoers.d/30-auditadmin

# 审计管理员策略 - 只读权限，专注于日志审计 %auditadmin ALL=(ALL) NOPASSWD: /usr/bin/cat /var/log/secure*, /usr/bin/cat /var/log/audit/*, /usr/bin/tail -f /var/log/audit/audit.log # 说明：允许查看所有安全及审计日志文件。 %auditadmin ALL=(ALL) NOPASSWD: /usr/sbin/ausearch, /usr/sbin/aureport # 说明：允许使用SELinux审计工具 ausearch 和 aureport 进行高级日志查询和分析。 %auditadmin ALL=(ALL) NOPASSWD: /usr/bin/journalctl * # 说明：允许使用journalctl查看所有系统日志。注意，journalctl可能包含敏感信息，但审计员需要这些信息。 %auditadmin ALL=(ALL) NOPASSWD: /bin/cat /var/log/messages*, /bin/cat /var/log/cron*, /bin/ls -la /var/log/ # 说明：允许查看其他系统日志和日志目录列表。 # 关键限制：审计员只能以root身份运行这些命令，且只能读。不需要显式写禁止项，因为没允许的就是禁止的。 # 但为了绝对安全，可以强制命令在只读模式下运行（如果命令支持的话）。 Defaults:%auditadmin !syslog, !log_input, !log_output # 说明：Defaults关键字用于设置默认选项。这里禁止审计员通过sudo执行命令时记录输入输出到syslog，避免审计日志本身被污染。

重要技巧：对于审计员，我们甚至可以使用sudo的NOEXEC功能（如果支持），或者通过rbash（受限bash）来限制其shell能力，确保他无法在系统中执行任何 shell 操作，只能通过sudo运行我们明确允许的那几个只读命令。这需要额外的配置，但安全性更高。

5. 加固sudo日志与系统审计配置

权限分好了，但如果日志本身不完整、能被篡改，那一切就白费了。等保三级对审计日志的要求是“完整性、保密性和可用性”。我们需要对sudo日志和系统审计进行加固。

5.1 配置独立的、受保护的sudo日志

默认sudo日志写在/var/log/secure里，和其他日志混在一起。我们可以配置独立的、权限严格的日志文件。

首先，修改/etc/sudoers（或/etc/sudoers.d/99-logging）文件，在顶部或单独文件中添加：

# 全局sudo日志配置 Defaults logfile=/var/log/sudo.log Defaults log_host, log_year, log_input, log_output Defaults iolog_dir=/var/log/sudo-io/%{user} Defaults !syslog

• logfile：指定独立日志文件路径。
• log_input, log_output：极其重要！记录用户通过sudo执行命令时所有的输入和输出。这对于事后复盘操作过程至关重要，但会显著增加日志量。
• iolog_dir：将输入输出日志按用户分开存放。
• !syslog：不发送到系统syslog，避免重复。

然后，创建日志文件并设置严格的权限，确保只有root和auditadmin（通过sudo）能读：

sudo touch /var/log/sudo.log /var/log/sudo-io sudo chown root:root /var/log/sudo.log /var/log/sudo-io sudo chmod 600 /var/log/sudo.log # 只有root可读写 sudo chmod 700 /var/log/sudo-io # 只有root可进入 # 设置日志轮转 sudo tee /etc/logrotate.d/sudo << 'EOF' /var/log/sudo.log { weekly rotate 12 compress delaycompress missingok notifempty create 0600 root root } EOF

5.2 启用并配置auditd审计守护进程

sudo日志只记录sudo相关操作。系统层面的全量审计需要靠auditd。等保三级明确要求对重要用户行为、重要安全事件进行审计。

1. 安装与启动：

   sudo yum install audit audit-libs sudo systemctl enable --now auditd

2. 添加关键审计规则：编辑/etc/audit/rules.d/audit.rules，在文件末尾添加：

   # 审计所有sudoers文件的修改（-w 监视文件路径，-p wa 监视写和属性更改，-k 给事件打标签） -w /etc/sudoers -p wa -k sudoers -w /etc/sudoers.d/ -p wa -k sudoers # 审计所有特权命令的执行（-a 添加规则，exit,always 表示总是记录退出事件，-S execve 表示记录execve系统调用，-F path 过滤路径） -a always,exit -F arch=b64 -S execve -F path=/usr/bin/su -k privileged -a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -k privileged -a always,exit -F arch=b64 -S execve -F path=/usr/sbin/visudo -k privileged # 审计用户和管理员组的变更 -w /etc/passwd -p wa -k identity -w /etc/group -p wa -k identity -w /etc/shadow -p wa -k identity # 审计审计日志文件本身的访问（防篡改） -w /var/log/audit/ -p wa -k auditlog -w /var/log/sudo.log -p wa -k sudolog

   保存后，重启auditd服务使规则生效：sudo systemctl restart auditd

3. 查询审计日志：审计管理员auditadmin1可以通过sudo执行以下命令查看：

   # 查看所有打上 sudoers 标签的事件 sudo ausearch -k sudoers -ts today # 查看所有特权命令执行 sudo ausearch -k privileged # 生成日报表 sudo aureport --summary

踩坑记录：auditd规则配置不当可能导致内核日志(dmesg)报错“audit backlog limit exceeded”，这是因为事件太多，队列满了。需要调整/etc/audit/auditd.conf中的max_log_file（日志文件大小）和num_logs（保留数量），以及内核参数audit_backlog_limit。对于高负载生产环境，需要精心设计规则，只审计最关键的事件，避免性能影响。

6. 验证、测试与常见问题排查

配置完成后，绝不能直接上生产。必须进行严格的验证测试。

6.1 分角色功能测试

使用三个不同的终端，分别用三个用户登录进行测试。

• 测试系统管理员 (sysadmin1)：

  # 应能成功 sudo systemctl status sshd sudo yum check-update sudo tail -f /var/log/messages # 应被拒绝 sudo visudo sudo cat /var/log/secure sudo passwd root

• 测试安全管理员 (secadmin1)：

  # 应能成功 sudo visudo # 可以打开编辑，但不要乱保存 sudo useradd testuser sudo passwd testuser sudo firewall-cmd --list-all # 应被拒绝 sudo systemctl restart network sudo yum install nginx sudo ausearch -k sudoers

• 测试审计管理员 (auditadmin1)：

  # 应能成功 sudo cat /var/log/secure | head -20 sudo ausearch -m USER_CMD -ts recent sudo journalctl -xe # 任何修改操作都应被拒绝 sudo touch /tmp/test.txt # 会失败，因为没授权任何写命令

6.2 关键问题排查清单

在测试和后续运维中，你肯定会遇到问题。下面这个表格整理了常见症状和解决方法：

6.3 上线后的持续维护要点

“三权分立”不是配置完就一劳永逸的，需要持续维护。

1. 定期审计日志：审计管理员应定期（如每天）审查sudo.log和audit.log，关注异常权限使用、失败尝试等。
2. 权限定期复审：业务变化后，sudoers规则可能需要调整。任何修改都必须经过申请、审批、测试、记录的流程，并由安全管理员操作。
3. 账号生命周期管理：员工离职或转岗，必须立即禁用或删除其对应账号。这需要与公司HR流程联动。
4. 备份与恢复演练：定期备份/etc/sudoers.d/目录和/etc/audit/目录下的配置。并演练在sudoers文件损坏后，如何用备份的root会话快速恢复。
5. 结合堡垒机：对于大规模服务器集群，强烈建议将“三权分立”与堡垒机（跳板机）结合。所有运维操作必须通过堡垒机进行，堡垒机自身实现三权分立，并对所有会话进行录像，提供更强大的审计能力。

这套基于原生sudo的“三权分立”方案，虽然配置起来有些繁琐，但它不引入任何外部依赖，稳定性高，能够很好地满足等保三级在身份鉴别、访问控制和安全审计方面的要求。其核心思想——权限最小化、职责分离和完整审计——适用于任何对安全有要求的生产环境。刚开始实施可能会觉得束手束脚，但习惯了这种制衡的流程后，你会发现整个运维体系反而更清晰、更安全了。