📚 课程目录第4章最小权限原则

4. 最小权限原则：权限的细粒度控制、JIT、JEA 与 PAM

聊零信任，绕不开一个核心原则——最小权限。说白了，就是给每个用户、每个服务、每个进程，只分配完成工作所必需的最小权限集合。多一分不要，少一分不行。

我在很多项目里见过反面教材：一个普通开发人员，账号居然挂着域管理员权限。问他为什么，他说“方便”。嗯，方便是方便了，一旦这个账号被攻破，整个内网就像脱了衣服站在黑客面前。所以，最小权限不是理论，是生存法则。

4.1 权限的细粒度控制

传统权限模型太粗了。要么是“管理员”，要么是“普通用户”，中间没有过渡。你想想看，一个只需要读取日志的人，你给他一个“系统管理员”角色，这合理吗？

细粒度控制，就是把权限拆到原子级别。比如：

能读 A 数据库，不能写 B 数据库
能重启 Web 服务，不能修改防火墙规则
能查看用户列表，不能导出密码哈希

我习惯用 RBAC（基于角色的访问控制）做第一层，再用 ABAC（基于属性的访问控制）做第二层过滤。举个例子：

# 伪代码示例：细粒度权限检查
def can_access(user, resource, action, context):
    # RBAC 检查：用户是否有角色
    if not user.has_role('ops'):
        return False
    
    # ABAC 检查：时间、地点、设备状态
    if context.time not in ['09:00-18:00']:
        return False
    if context.device_trust_score < 0.7:
        return False
    
    # 资源级权限
    if action == 'DELETE' and resource.type == 'production_db':
        return False  # 禁止删除生产库
    
    return True

核心思路：权限不是“有或没有”，而是“在什么条件下，对什么资源，能做什么操作”。

4.2 Just-In-Time（JIT）权限

JIT 的理念很简单：权限不是常驻的，而是按需临时授予的。用完即收回。

我曾经在一个金融客户那里看到，他们的 DBA 账号 24 小时都有超级权限。我说，万一晚上被入侵了呢？他们沉默了。后来我们上了 JIT 方案：DBA 只有在发起工单、审批通过后，才能获得 30 分钟的数据库管理员权限。30 分钟后自动回收。

JIT 的典型流程：

请求：用户发起权限申请，说明原因、时长、资源
审批：自动或人工审批，检查是否合理
授予：临时提升权限，设置 TTL（生存时间）
使用：用户在限定时间内操作
回收：TTL 到期或操作完成，自动撤销权限

我的建议：JIT 一定要和审批流打通。别让用户自己申请自己批，那就形同虚设了。

4.3 Just-Enough-Access（JEA）

JEA 和 JIT 是兄弟，但侧重点不同。JIT 管的是“时间”，JEA 管的是“范围”。

JEA 的核心是：只给刚刚好的权限，不多给一丁点。比如一个运维人员需要重启 IIS 服务，你给他一个完整的管理员账号？太危险了。JEA 的做法是：创建一个受限的 PowerShell 会话，里面只暴露 Restart-Service IIS 这一个命令。

我举个例子，用 JEA 配置一个只允许重启服务的角色：

# JEA 角色能力文件示例
@{
    VisibleCmdlets = @(
        'Restart-Service',
        'Get-Service'
    )
    VisibleFunctions = @()
    VisibleExternalCommands = @()
    VisibleProviders = @()
    ScriptsToProcess = @()
    RoleCapabilities = @()
}

这样，用户登录后只能执行这两个命令。想干别的？没门。

维度	JIT	JEA
控制对象	权限的时效性	权限的范围
典型场景	临时管理员权限	受限运维操作
实现方式	临时提权 + TTL	受限会话 + 命令白名单
风险降低	减少权限暴露窗口	减少权限滥用面

4.4 特权账号管理（PAM）

PAM 是前面三者的落地载体。它不是一个单一产品，而是一套体系：发现所有特权账号、管理它们的密码、控制它们的使用、审计它们的操作。

我在一个大型国企做过 PAM 项目。他们之前有 2000 多个 root 密码，写在 Excel 里，存在共享文件夹。你敢信？后来我们上了 PAM 系统，做了几件事：

账号发现：扫描全网，找出所有特权账号
密码托管：密码自动轮换，没人知道明文
会话录制：所有特权操作录屏，可回放
命令拦截：危险命令（如 rm -rf /）直接拦截

避坑指南：我曾经见过一个团队，PAM 上线后忘了配置密码轮换策略。结果半年后，所有密码还是初始密码。PAM 不是买来就完事的，要持续运营。

4.5 知识体系总览

下面这张图，把最小权限原则的四个核心模块串起来了。你可以看到，细粒度控制是基础，JIT 和 JEA 是两种策略，PAM 是落地平台。

4.6 落地建议

说了这么多，怎么落地？我总结几个实操点：

先盘点，再治理：不知道有多少特权账号，就别谈最小权限。先扫一遍。
从高风险的账号开始：比如 root、admin、sa。这些账号风险最高，优先纳入 PAM。
分阶段推行：别想一步到位。先做 JIT，再做 JEA，最后上 PAM 平台。
持续审计：权限不是设完就完的。定期 review，看看有没有权限膨胀。

我的经验：最小权限原则推行最大的阻力，往往来自“习惯”。开发人员习惯了有 root 权限，运维人员习惯了随便执行命令。要改变习惯，光靠技术不行，还得有制度和培训。

嗯，这一章的内容就到这里。最小权限不是限制生产力，而是保护生产力。你想想看，一个没有权限失控的系统，是不是比一个谁都能乱搞的系统更让人放心？