2、最小权限原则：概念解析、权限模型设计、用户与进程权限最小化实践

2.1 概念解析

最小权限原则（Principle of Least Privilege, PoLP）是网络安全与系统设计的核心基石。该原则要求任何用户、程序或进程仅应被授予完成其合法任务所必需的最小权限集合，且权限的有效期应尽可能短。

📌 核心思想： 权限不是越多越好，而是“刚刚好”。多一份权限，就多一分被滥用的风险。

图1：最小权限原则核心对比——权限应精确匹配任务需求

2.2 权限模型设计

设计权限模型时，通常采用分层、分域的思想，将权限抽象为三个核心维度：

维度	说明	示例
用户角色	基于岗位职责定义角色，角色绑定权限集	审计员、运维工程师、开发人员
资源域	按系统、模块、数据级别划分资源范围	生产库、测试库、配置文件、API端点
操作类型	定义对资源的具体操作（CRUD + 执行）	读取、写入、删除、执行、管理

图2：RBAC权限模型——用户→角色→权限→资源的映射关系

2.3 用户与进程权限最小化实践

🔹 用户权限最小化

按角色分配： 使用 RBAC 模型，避免直接给个人授权。例如：审计员仅授予 SELECT 权限。
临时提权： 使用 sudo 或 PAM 机制，操作完成后自动降权。
定期审计： 每季度审查用户权限列表，撤销长期未使用的权限。
默认拒绝： 新用户默认无权限，按需申请、审批后开通。

🔹 进程权限最小化

专用运行账号： 每个服务使用独立的系统账号（如 nginx、mysql），禁止使用 root 运行。
文件系统权限： 进程仅对其工作目录拥有读写权限，其他目录只读或不可见。
能力（Capabilities）裁剪： 使用 capsh 或 Docker --cap-drop 移除不需要的 Linux Capabilities。
Seccomp / AppArmor： 限制进程可调用的系统调用，防止内核漏洞利用。

图3：进程权限最小化四步实施流程

🔹 实践代码示例（Linux 环境）

# 1. 创建专用系统账号（无登录权限）
sudo useradd -r -s /sbin/nologin myapp

# 2. 设置文件所有权和最小权限
sudo chown myapp:myapp /opt/myapp
sudo chmod 750 /opt/myapp          # 仅 owner 和 group 可读写执行
sudo chmod 640 /opt/myapp/config   # 配置文件仅 owner 可写

# 3. 使用 systemd 限制进程能力（Capabilities）
[Service]
User=myapp
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=yes

# 4. 使用 Docker 运行时的最小权限
docker run -d \
  --name myapp \
  --user 1001:1001 \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt seccomp=default.json \
  --read-only \
  myapp:latest

📋 最小权限检查清单

检查项	是否满足	备注
所有服务使用非 root 账号运行	✅	使用 useradd -r 创建
文件权限遵循 750/640 原则	✅	定期用 find 检查
Linux Capabilities 已裁剪	⚠️ 部分满足	需进一步移除 NET_RAW
Seccomp 或 AppArmor 已启用	❌	待实施默认拒绝策略

🎯 核心要点回顾： 最小权限原则不是一次性配置，而是一个持续审计、持续收敛的过程。每次系统变更后，都应重新评估权限是否仍然“最小”。

📚 课程目录