权限设计不是技术细节，而是产品安全与业务边界的底层保障。一旦“乱给权限”，不仅埋下隐患，更可能引发信任危机。本文将带你系统梳理权限的核心逻辑、常见误区与产品经理不可忽视的职责边界，帮助你从源头守住产品底线。
有没有遇到过这种尴尬？
新来的同事，对着系统干瞪眼，啥功能也找不着。
你只是想给销售部开个新功能，结果却不得不拉着IT同事，在几十号人的权限列表里一个个勾选……
出现这些问题，可能是因为没搞懂『权限』和『角色』那点事儿，这次就跟大家聊聊什么权限和角色，以及如何应用。
我们先来回忆下用户人机交互的场景，用户在某个应用内使用某些功能，我们来概括下就是【谁能对什么做什么】，这里【做什么】指的就是我们的权限。
我们通常会把权限划分成，功能权限和数据权限。
功能权限，狭义上大家都会认为是某个功能，例如某个按钮功能。实际上功能权限可以划分不同层级来看，例如应用权限/模块权限/页面（菜单）权限/按钮权限等。
例如：运营同学鸣人，有电商管理后台权限，有商品管理模块权限，能够查看商品主档信息页面，能够去创建产品。财务同学佐助，有财务系统后台权限，有资产管理模块权限，能够查看资产登记页面，能够创建资产。
数据权限，实际上就是能够查看或编辑某些数据，这里有个概念要清楚，我们常说的数据权限，基本都是业务数据，也就是用户产生的数据。所以数据权限也就是指的，能查看或编辑哪些人的数据。
例如：运营同学鸣人和小李，只能查看和编辑各自的数据，互相看不到彼此的数据。
虽然上面举了一些，跟管理后台相关的场景，但权限这部分是互联网应用全场景都通用的，包含C端产品，用户能使用哪些功能等。
说完了权限，接着聊一下与权限捆绑在一起的【角色】。
角色实际上就是一个权限的集合。一般使用场景是用户关联角色，角色关联权限：
可能有的同学会说，为什么不直接用户关联权限呢，其实是可以的，但这样操作起来很繁琐，而且很不利于管理。
试想如果企业有10个人，每个人配置权限；如果有100个人，1000个人呢。
所以引用【角色】这个概念，是为了解决以下几点：
我们了解了权限和角色，那我们接下来举一些使用场景。
鸣人在saas平台注册了账号，登录账号后，使用saas上的功能
用户注册账号，被关联平台设置的默认角色（管理员/普通角色等），角色中一般包含了系统权限，所以账号可使用对应的功能。
鸣人在平台上，想要卖商品，付费开通了商品管理功能，鸣人进入商品模块开始维护商品
用户付费后，平台会分配账号应用权限组，这个组里包含了应用内不同的功能权限（或资源）。所以账号可以使用对应的功能。这样的做法是，可以根据不同的业务，打包不同的应用组，根据业务灵活配置。
鸣人运营不过来，在平台上添加小队成员佐助和小樱。鸣人希望佐助能拥有更多的权限，小樱只能使用商品管理功能。所以鸣人分配了佐助和小樱不同的角色。
平台管理员拥有开通账号和分配角色的权限，不同用户分配不同角色和权限后，用户就可以使用不同的功能。
随着业务越来越壮大，鸣人把忍者村的大家拉了进来做业务，由于人数太多不好管理，所有鸣人把大家分成了不同的部门。然后给不同的部门关联不同的角色权限。这样不同部门就可以专注不同的功能。
通过组织管理，创建不同的部门，把用户分配在不同的部门中。相当于给用户，分配了用户组，在给部门关联角色，实际就是把用户组中的用户，批量关联了角色权限。
业务发展的越来越好，也涉及到了平台数据敏感的问题。鸣人把不同的部门，通过忍者等级，做了数据的分权，不同的部门中，上忍能够看中忍和下忍数据，中忍能下忍数据，下忍只能看自己的数据。火影能看到所有部门的所有数据。
上面就是数据分权的场景，上面场景已经维护好了部门层级。角色中设置数据权限，关联部门，再通过部门上下级关系来做管理。
例“销售经理”角色，可查看销售订单页面，数据权限规则为“可查看当前部门以及其下属部门”
不愧是鸣人，现在开始做海外业务，和砂影村建立了合作关系。但由于不是同一个村沟通起来很费劲。所以鸣人和我爱罗达成协议，在平台上做了授权，两个村子的人可以在平台上共同使用某些功能。这样大大节省了协同成本，提高效率
如果涉及到集团或供应链业务时，不同企业需要在平台上共同使用某些应用，传递某些数据。这个时候就需要平台上，不同主体来建立关系，授权某些功能。一般由链主企业，发起邀请，授权某些功能或权限。这样就可以达成不同企业共享某些功能或者数据。
以上是一些可能涉及到的权限相关场景，提到的处理方式也并非绝对的，还是要看公司的业务场景。但归根结底，底层的逻辑不变的。权限是管理用户到底能做什么能看什么，角色是把人按一定规则组来做类别，使你的系统更加灵活，更加安全，更加有拓展性，才能更好的应对各种业务拓展。
本文由 @Robbie 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。