授权和权限：防止未经授权的访问的最佳实践

大多数人混淆了[身份验证0] 与授权，这种混淆的代价是高昂的。身份验证是证明您是谁、登录名、密码、令牌、生物识别。授权是决定你已经确定的有权做什么。这些是不同的问题，第二个是大多数内部泄密和欺诈发生的地方。

登录完美且授权不严格的系统是很常见的。前门有一个生物识别锁，但一旦进入，任何人都可以打开任何抽屉。如果攻击者在使用常规帐户登录后可以访问他不应该访问的数据，则不需要破坏您的[身份验证1]。

本文汇集了基本步骤和最佳授权实践。目标是实用的：确保每个用户、系统或服务准确地访问其所需的内容，不多也不少。

支撑这一切的原则：最小特权

如果您仅从本文中获得一个想法，请考虑以下内容：为每个用户提供完成其工作所需的最低访问权限，仅此而已。这是最小特权原则，它实际上解决了大多数授权问题。

相反的诱惑是强烈的。给予广泛的访问权限“以免阻止任何人”并稍后处理后果会更容易。但每增加一个许可，就多一扇门。当帐户受到威胁时，损失与该帐户可能造成的后果成正比。拥有太多权力的账户会把一个小事件变成一场灾难。

较小的特权并不是对人们的不信任。它认识到帐户被泄露、错误发生，并且必须通过设计来控制损害。

按用户分配权限无法扩展，并且会在短时间内变得混乱。成熟的实践是按角色来组织访问，该模型称为RBAC（基于角色的访问控制）。

您不是说“John 可以查看财务报告”，而是使用一组权限定义“财务分析师”角色，并将该角色分配给 John。当约翰离开而玛丽加入时，您只需交换扮演该角色的人即可。权限在一处进行描述、可审核且一致。

对于更复杂的场景，可以使用基于属性的控制（ABAC），其中决策考虑上下文、时间、位置、数据敏感性。但从简单开始。做得好的 RBAC 可以解决绝大多数情况，过早的复杂性只会产生错误。

一个常见的架构错误是将权限规则分散在整个代码中，这里是“if”，那里是检查。随着时间的推移，没有人确切知道谁可以做什么，而且系统各部分之间的规则也有所不同。

良好的做法是将授权视为核心责任，并明确制定决策的地点。不管它是一个库、一个服务还是一个模块，重要的是“这个用户可以这样做吗？”的问题。在可以审核和更改的地方得到一致的回答。

这也让证明合规性变得更加容易。当审计员或 [LGPD2? 本身（就个人数据而言））询问谁有权访问什么内容时，您可以通过查看一个地方来回答，而不是搜索整个代码。

这是最危险和最常见的故障之一。前端隐藏了用户不应该看到的按钮，团队认为问题已解决。它不是。隐藏按钮是体验，而不是安全。

每次请求时都需要在后端检查授权。攻击者不使用您的接口，而是直接调用 API。如果唯一的障碍是视觉，那么就没有障碍。规则很简单且不可协商：客户端可以建议，服务器决定。

标识符也是如此。如果系统允许用户仅通过更改 URL 中的数字来访问资源，而不检查该资源是否属于他们，那么您将面临现有最常被利用的漏洞之一，即通过直接引用对对象进行不当访问，多年来已被 OWASP 编目。检查占有，而不仅仅是存在。

授予的访问权限必须能够被快速取消。当有人离开组织、改变角色或帐户被盗时，您需要立即切断访问权限，而不是在下一个冲刺中。

这假设了两件事。首先，知道谁可以访问什么，这可以追溯到集中化和角色建模的点。其次，记录谁访问了什么以及何时访问。访问日志记录并不能防止问题发生，但它可以让您在事件发生后进行调查、响应和学习。没有审计跟踪的系统是一个不知道发生了什么的系统。

有一个问题在没有人注意到的情况下不断增长：权限随着时间的推移而积累。该人改变区域，获得新的访问权限并保留旧的访问权限。多年后，她从曾经担任的三个角色中积累了权限。没有人审阅它，因为审阅是工作并且不会给你奖杯。

这种积累就是一颗定时炸弹。当这些帐户之一受到威胁时，访问权限就会不成比例。防御虽然令人不舒服但却是必要的：定期审查访问权限。时不时地看看并问“这个人还需要这个吗？”对于某些权限，几乎总是答案是否定的。

另一个挑战是文化。限制性授权会产生摩擦，而摩擦又会产生投诉。用户想要广泛的访问权限，经理想要敏捷性，而安全性成为阻止每个人的恶棍。维持最低限度的特权需要领导层的信念，并明确今天的摩擦比明天的泄密要便宜。

做得好的授权在有效时是看不见的，而在失败时则是毁灭性的。它不会出现在产品演示中，也不会在会议上给人留下深刻的印象，但它却是处理敏感数据的任何系统中最重要的决策之一。

步骤很明确：以最小权限为原则，以角色代替宽松的权限，集中决策，服务器端验证，以及可撤销和可审计的访问。它们都不复杂。所有这些都经常被忽视。

如果您的组织处理敏感数据，并且您不确定谁可以访问哪些数据，那么现在是进行审查的好时机。博客上还有其他有关安全性、访问控制和合规性的文本，深入探讨了该主题。