精通Testany平台权限和用户状态控制系统:指南
为了确保安全和高效的操作,我们开发了一个全面的权限控制系统,遵循最小特权原则。这种方法确保用户仅获得执行其功能所需的最低访问权限或权限。下面,我们解释了如何应用这一原则以及用户状态如何融入整体框架。
用户状态:访问的基础
我们将用户与平台的互动分为四种不同的状态:
已邀请
:收到加入平台邀请的用户。活跃
:完全注册并与平台资源互动的用户。暂停
:访问暂时受限的用户。禁用
:访问被永久撤销且无法与平台互动的用户。
理解“暂停”和“禁用”状态
(用户)暂停:一种可逆状态,保持用户数据完整性但限制平台互动。
无法登录或执行操作。
不会收到通知,但保留资源所有权。
全局管理员可以解除此状态,完全恢复用户的访问权限。
(用户)禁用:一种不可逆状态,表示完全脱离平台。
用户被移除所有操作角色,无法登录或接收通知。
除非在特殊情况下全局管理员介入,否则此状态是最终的。
最小特权原则的应用
我们的权限控制系统基于最小特权原则。这意味着:
用户仅被提供执行其角色所需的访问权限,降低意外或恶意泄露的风险。
权限根据角色和用户状态仔细分配,以确保安全性和功能性。
权限一览
权限因角色而异,并由我们的权限矩阵清晰定义:
列表 (list)
:查看资源集合。创建(create)
:添加新资源。读取(read)
:访问资源的详细信息。编辑(edit/update)
:修改现有资源。删除(delete)
:移除资源。特殊权限
:特定角色的操作,如授予和撤销访问权限。
每个角色对每个操作都有特定权限,绿色(允许)和红色(拒绝)指示器提供一目了然的理解。
用户和管理员的最佳实践
管理员:定期进行权限审计,以确保遵循最小特权原则。
用户:了解您当前的状态和权限,并理解它们如何影响您的平台互动。
结论
通过实施最小特权原则和详细的用户状态,我们创建了一个安全、高效且以用户为中心的权限控制系统。该系统使用户能够有效地履行其角色,同时保护平台的完整性。
Appendix: Testany平台权限矩阵 V2.6
对象 (资源) | 行为 | 对象 (资源) 的 | 全局管理员 | 工作区管理员 | 工作区用户 | 无工作区角色的用户 |
---|---|---|---|---|---|---|
Case | list | |||||
create | ||||||
read | ||||||
edit (update) |
| |||||
delete |
| |||||
workspace | list | |||||
create | ||||||
read | ||||||
edit (update) | ||||||
grant_access | ||||||
revoke_access | ||||||
assign_owner | ||||||
Pipeline | list | |||||
create | ||||||
read | ||||||
edit (update) | ||||||
manual_trigger_execution | ||||||
delete | ||||||
Plan | list | |||||
create | ||||||
read | ||||||
edit (update) | ||||||
delete | ||||||
Gatekeeper | list | |||||
create | ||||||
read | ||||||
edit (update) | ||||||
delete | ||||||
User | list | |||||
list_all_status | ||||||
add | ||||||
read | ||||||
edit | ||||||
suspend | ||||||
disable | ||||||
assign_global_admin | ||||||
assign_workspace_admin | ||||||
grant_workspace_access | ||||||
revoke_workspace_access | ||||||
Notification Receiver | list | |||||
create | ||||||
read | ||||||
edit (update) | ||||||
delete | ||||||
activate | ||||||
Tenant | access | |||||
create | ||||||
read | ||||||
edit (update) | ||||||
delete |
请注意,此矩阵仅供参考;实际权限以应用程序中的结果为准。