使用RBAC进行SaaS多租户访问控制的实践指南
使用RBAC进行SaaS多租户访问控制的实践指南
本文详细介绍了在SaaS多租户环境中使用RBAC(基于角色的访问控制)进行访问控制的具体实现方法。通过具体的策略示例和授权请求,展示了如何通过多个策略存储实现租户隔离,以及如何在租户内部通过用户角色定义权限。
使用RBAC进行多租户访问控制
在多租户解决方案中,总是代表给定租户提供资源访问权限。也就是说,租户A的用户无法查看租户B的数据,即使这些数据在逻辑上或物理上并置在系统中。以下示例说明了如何使用多个已验证权限策略存储来实现租户隔离,以及如何使用用户角色在租户内定义权限。
使用每租户策略存储设计模式是在使用已验证权限实施访问控制的同时保持租户隔离的最佳实践。在这种情况下,租户A和租户B的用户请求将分别根据不同的策略存储DATAMICROSERVICE_POLICYSTORE_A
和DATAMICROSERVICE_POLICYSTORE_B
进行验证。
策略存储示例
以下策略位于DATAMICROSERVICE_POLICYSTORE_A
策略存储中。它验证主体是否将成为该类型Role
组allAccessRole
的一部分。在这种情况下,将允许委托人对与租户A关联的所有资源执行viewData
和updateData
操作。
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
);
以下策略位于DATAMICROSERVICE_POLICYSTORE_B
策略存储中。第一个策略验证委托人是否属于该类型updateDataRole
Role组。假设是这样,则它允许委托人对与租户B关联的资源执行操作updateData
。
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
);
第二项政策规定,Role
应允许属于该类型viewDataRole
组的委托人对与租户viewData
B关联的资源执行操作。
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
);
授权请求示例
租户A发出的授权请求需要发送到DATAMICROSERVICE_POLICYSTORE_A
策略存储区,并由属于该存储的策略进行验证。在本例中,已通过前面作为本示例一部分讨论的第一个策略对其进行验证。在此授权请求中,类型User
为的委托人Alice
正在请求执行viewData
操作。主体属于allAccessRole
类型组Role
。Alice正在尝试对SampleData
资源执行viewData
操作。由于Alice有这个allAccessRole
角色,所以这个评估会产生一个ALLOW
决策。
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "viewData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
相反,如果您查看租户B发出的请求User Bob
,则会看到类似以下授权请求的内容。该请求之所以被发送到DATAMICROSERVICE_POLICYSTORE_B
策略存储,是因为它来自租户B。在此请求中,委托Bob
人想要updateData
对资源SampleData
执行操作。但是,Bob
不属于有权访问该资源操作updateData
的群组。因此,该请求会导致决DENY
策。
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_B",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Bob"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "updateData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Bob"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "viewDataRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
在第三个示例中,User Alice
尝试对资源执行viewData
操作SampleData
。此请求被定向到DATAMICROSERVICE_POLICYSTORE_A
策略存储,因为委托人Alice
属于租户AAlice
,属于该allAccessRole
类型的组Role
,允许她对资源执行操作viewData
。因此,请求会导致ALLOW
决策。
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "viewData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
本文原文来自AWS官方文档