自从身份验证和授权成为访问计算机系统的常规操作，最小权限原则（POLP）就是实际上的安全底线。其核心思想在于仅为用户分配供其完成任务所需访问公司数据及系统的最小权限——不多也不少，恰恰够完成工作。理论上，遵守POLP似乎是最佳身份与访问管理策略，但实现最小权限往往说得容易做起来难。

为什么最小权限原则一直难以实现？

原因很多。首先，要实现最小权限就得对每位用户及其角色所需的恰当权限有着清晰的理解。其次，要有某种工具来实施所定义的权限等级。再次，授权的定义与实施一定不能干扰到用户的正常工作。最小权限原则能保护所有类型的用户访问，尤其是管理员权限访问。

有些系统角色定义良好，对与这些角色相关联的权限也有着细粒度的划分，在这些系统上实现POLP就比较容易。但有些系统就没那么配合了，因为它们缺乏定义和实现各级权限划分的原生工具。对于后者，公司企业往往只能靠自己粗浅简陋的权限定义设备和有限的工具来实现POLP。造成的结果就是，很多公司企业非常想要施行最小权限，但实际上却只在非常有限的范围内真正实现了POLP。

从管理员权限的角度看，很多公司图省事直接给所有可能需要该权限的用户都分发了管理员(或者说“超级用户”)凭证，让太多的员工掌握了对数据及系统的过多权限，根本就是完全背离了POLP。

管理员权限应用最小权限原则的经典案例是Unix和Linux系统上的开源工具“sudo”(“ superuser do ”的缩写)。该工具允许公司在“sudoer”文件中定义具有“全权”root凭证部分权限的角色。管理员登录后得在命令前加“su”前缀才可以尝试执行特权命令，且该命令若不被sudoer策略允许，执行尝试还会被拒绝。

sudo在很多情况下运行良好。但当Unix/Linux系统环境达到一定的规模，每台Unix/Linux服务器上独立运行sudo就让最小权限的施行变得难以控制，容易出错，适得其反了。于是，各种特权访问管理(PAM)解决方案应运而生，要么用覆盖整个环境的解决方案贯彻统一的策略和实现规则集并辅以键盘记录，要么以覆盖所有实例的集中式策略增强sudo（相对于分散在各实例上的多个sudoer文件）。

但是，Unix/Linux通常只是PAM整体视图中的一部分。还有其他系统会留有未经审查的管理员权限访问。比如说，大多数公司企业都会设置微软活动目录(AD)和Azure活动目录(AAD)作为终端用户的主要访问入口。这就让AD/AAD管理员成为了任何PAM项目的重要内容，POLP也应扩展到这些管理员身上。

然而，现实往往没那么简单，除了Unix/Linux和AD/AAD平台，现代异构企业中非常难以贯彻一致的POLP。有些应用内置了供POLP实现的功能，而有些应用压根儿就没考虑过POLP。

前路艰险，为了尽可能展开PAM项目，帮助企业从POLP中收获最多益处，可以参考下列建议：

• 控制好你能控制的：

在Unix/Linux系统中寻找机会增强原生sudo，清除最小权限实现过程中的漏洞并提升操作效率。用商业解决方案增强或替换sudo能带来巨大的安全收益。同样地，寻求第三方辅助，去除默认非此即彼的管理员权限设置，是当下AD/AAD应用POLP的良好方式。

• 使用特权口令管理器：

如果最小权限无法实现，可以尝试用特权口令管理器来共享管理员口令。随着日常Unix/Linux和AD/AAD管理员访问以最小权限模式委托出去，我们很有必要在其他特权口令的核发、批准和管理上实现安全和自动化。这么做可以去除掉未核准管理员访问的匿名性，对整个过程加以管控。特权口令管理器还可提供向单个用户发放被委托管理员账户整套权限的另一种途径。委托出日常行为权限并为紧急事件赋予超级用户访问权限。

• 审计行为：

如果不能监视管理员用他们手中的特权都干了些什么，PAM项目就称不上完整。运用会话审计和键盘记录来增强管理员权限委托，可以让你知道这些权限都被用来了干了什么。

• 实现分析：

PAM拼图的最后一块就是实现分析功能。特权行为分析有助于检测异常及危险行为，身份分析则可评估特权口令管理器和最小权限模式中与管理员权限相关的那些权利。对同类管理员进行权利与权限分析，可以帮助公司发现其最小权限模式中的弱点。

POLP是有效PAM项目中的关键组成部分，但并非唯一的原则。全面的PAM项目还应辅以口令管理、会话审计和分析，才能真正交付项目设计之初的安全目标。