最小权限管理是贯穿账户创建、资源分配、服务运行和持续审计的实践体系，核心是“谁在什么场景下只能做刚好够用的事”，需禁用root登录与密码认证、按需切分文件权限、服务降权运行，并定期验证收敛权限。
服务器最小权限管理不是一步到位的配置动作，而是一套贯穿账户创建、资源分配、服务运行和持续审计的实践体系。核心就一条：谁在什么场景下，只能做刚好够用的事。
用户账户与登录入口必须收窄
默认的 root 登录和密码认证是最大风险点。生产环境应禁止直接 root 登录，禁用密码登录，只保留密钥认证方式。具体操作包括：
- 修改 /etc/ssh/sshd_config.d/99-hardening.conf，设置 PermitRootLogin no 和 PasswordAuthentication no
- 为每个运维或应用人员创建独立系统账户，不共用账号
- 用 AllowUsers 明确限定可登录的用户名和来源 IP（如 ops@192.168.10.*）
- 所有账户强制使用强密码策略，并启用 MaxAuthTries 3 防暴力尝试
文件与目录权限要按需切分
Linux 文件权限（chmod/chown）是第一道隔离线。不能图省事给整个 /var/www 或 /opt/app 加上 777。正确做法是：
- 按功能模块划分目录，例如 /var/www/api、/opt/db/data、/var/log/app
- Web 服务进程只拥有 读+执行 权限访问代码目录，无写入权；日志目录则仅允许服务用户写入，禁止读取
- 数据库目录由 dbuser 所有，web 用户组不可访问；敏感配置文件（如 .env）设为 600，仅属主可读写
- 统一采用“服务名-版本-环境”命名，比如 payment-v2.1-prod，便于权限批量管理和审计追溯
服务与进程运行身份必须降权
服务以 root 身份运行等于把钥匙交给陌生人。无论是传统服务还是容器化应用，都应主动切换到低权限用户：
- Systemd 服务中通过 User=appuser 和 Group=appuser 指定运行身份
- Dockerfile 中显式创建非 root 用户并用 USER appuser 切换，配合 COPY --chown=appuser:appuser 确保文件归属一致
- Kubernetes Pod 中启用 securityContext.runAsNonRoot: true，并丢弃全部 capabilities，仅按需添加（如 NET_BIND_SERVICE）
- 禁用 privileged: true、避免挂载 /proc 或 /sys 等敏感路径
权限策略要可验证、可收敛
最小权限不是设完就结束，而是需要定期回检和闭环优化：
- 每季度跑一次 find / -perm -4000 -o -perm -2000 -type f 2>/dev/null，检查是否有意外的 SUID/SGID 文件
- 用 auditctl 监控关键目录（如 /etc/passwd、/var/log/auth.log）的修改行为
- 对所有用户组权限做矩阵梳理：哪些组能访问哪些路径？哪些服务属于哪个组？是否存在冗余授权？
- 新上线服务必须填写《权限申请单》，明确用途、最小所需权限、有效期，由安全团队联合审批
