说明权限模型与分配
学习目标
说明权限管理与分配
权限模型
要在 SAP BTP 上执行任务,平台用户和业务用户需要获得相应的权限。SAP BTP 中有许多预定义权限,可直接分配给用户。通常至少会有提供完全访问权限的角色,以及提供只读访问权限的角色(例如供审计人员使用)。
除少数例外情况外,您还可以定制权限:可以将预定义权限分组到更高层级的角色中。这有助于以简单且一致的方式为众多用户授权,同时兼顾职责分离。
在某些情况下,还有一个额外的定制层级:您甚至可以将功能性权限限制到数据的特定子集。例如,某个用户可以查看全球所有客户的订单,但只能管理某个特定市场/区域的订单。此类限制也称为“基于实例的权限”。
平台用户的权限模型
账户成员(全局账户、目录、子账户)
您将用户分配到预定义角色集合和自定义角色集合,以授予其权限。角色集合将来自同一账户上下文中可用的一项或多项服务的角色分组在一起。所有权限以及用户分配都特定于单个账户上下文,例如特定的子账户。它们在其他上下文中不可用,例如对应的全局账户或其他子账户。角色由应用程序/服务提供者预定义,是管理员可以使用的最细粒度。管理员可以将角色分组到自定义角色集合中。对于账户成员,只有功能性权限,没有实例限制选项。此模型基于 SAP BTP 的授权和信任管理服务,该服务也用于业务用户。
Cloud Foundry 组织和空间的成员
对于 Cloud Foundry 的成员,此方法有所不同:您将用户分配到预定义角色。有些角色适用于组织,另一些适用于空间。既没有选项也没有必要定制预定义权限。角色分配特定于单个用户以及组织或空间。
Kyma 系统的成员:
对于 Kyma 环境的成员,您将用户分配到预定义角色和自定义角色。您可以对角色中的各个权限进行细粒度控制。它们要么适用于整个系统,要么适用于单个命名空间。
ABAP 环境的成员
ABAP 环境中平台用户与业务用户之间没有区分。在 SAP BTP ABAP 环境中,您将使用 ABAP 自身身份访问管理中的业务用户和业务角色,其与 SAP S/4HANA Cloud Public Edition 中的身份访问管理有很多共同之处。
业务用户的权限模型
应用程序的权限只有在应用程序已订阅(SaaS 应用程序)或已部署(自定义应用程序)到子账户之后才可用。相应地,可重用服务的权限只有在子账户中至少创建了一个服务实例之后才可用。我们可以区分两种不同的业务用户权限模型:
传统模型:授权和信任管理服务
大多数现有应用程序和服务都采用传统模型,使用授权和信任管理服务向用户授予权限。这与账户成员使用的模型相同。应用程序和服务包含预定义角色,通常还包含预定义角色集合。某些应用程序支持针对特定条件(例如市场)的基于实例的权限。它们提供角色模板,用于定义可能的限制。您可以基于角色模板创建自定义角色,并根据需要指定限制。您可以将子账户中所有应用程序和服务的角色分组到自定义角色集合中。
新模型:SAP Cloud Identity services – 授权管理(AMS)
未来的新战略模型是使用授权管理服务。它原生集成到 SAP Cloud Identity services 中,并具有强大得多的基于实例的授权能力。一些首批 SaaS 应用程序已经在使用它,例如 SAP Ariba Buying 和 SAP Green Ledger。您也可以将其用于在 SAP BTP 上运行的自定义应用程序。这些应用程序包含预定义授权策略,可立即用于用户分配。某些应用程序支持针对特定条件的基于实例的授权。它们提供基础策略,用于定义可能的限制。您可以基于基础策略创建自定义策略(“管理策略”),并根据需要指定限制。
Note
目前,您直接在 SAP Cloud Identity services 的身份目录中向用户分配策略并设计自定义策略,而不是使用 SAP BTP 专用工具(如 SAP BTP 主控室)。向用户分配策略要求用户配置文件存在于 SAP Cloud Identity services 的身份目录中。您仍然可以将用户身份验证委托给企业身份提供者。未来,SAP 产品组合中越来越多的场景将依赖身份目录作为用户配置文件的中央存储,以及作为向用户分配各种权限的位置。
权限分配
在 SAP BTP 中向用户分配权限时,我们区分三种不同的方法:
手动分配
刚开始使用 SAP BTP 时,您只需手动创建用户配置文件并直接为其分配权限。通常使用 UI 来完成,例如为账户成员、Cloud Foundry 成员和大多数业务用户使用 SAP BTP 主控室。Kyma 和 ABAP 环境除 SAP BTP 主控室外还提供专门的管理 UI。
但是,当您将 SAP BTP 推广到更广泛的用户群体时,出于多种原因,您往往希望改变这种做法:
总拥有成本(TCO):手动管理各个用户分配需要大量精力
安全与合规:严格移除不再合理的分配非常困难,而且很可能出现遗漏。移除本应保留的分配,“只不过”是阻止用户工作的问题。而错误地保留它们可能会带来更大的麻烦。
通用数据保护条例(GDPR):除非人员需要使用,否则您不得将用户配置文件作为个人数据存储。尤其是在有人离开公司时,除了潜在的安全与合规问题之外,保留此类个人数据还违反 GDPR 法规。
因此,SAP 提供了更多管理用户配置文件和权限分配的方法,这些方法也考虑了上述部分甚至全部方面。它们各有优缺点,因此适合不同的客户。
SAP BTP 有多种工具,您可以使用它们自动化用户管理,从而在一定程度上降低 TCO。对于较小的单一任务,您可以使用 SAP Joule 与 SAP BTP 主控室的集成。要使用脚本方法自动化用户管理之类的重复流程,您可以使用一组命令行界面(CLI),具体而言:账户成员使用 btp CLI,组织和空间的成员使用 Cloud Foundry CLI,Kyma 成员则使用 kubectl。最后,还有适用于 SAP BTP 和 Cloud Foundry 的 Terraform 提供程序,可用于基础设施即代码方法。
所有这些选项都有助于在 SAP BTP 环境中实现自动化。但是,它们要求您从头实现完整的身份和权限生命周期。它们不覆盖您完整的 SAP 系统架构,也不与公司范围的 IAM 解决方案集成。因此,它们更适合由开发团队分散管理的非生产 SAP BTP 账户和环境。至少对于生产账户和环境而言,通常需要更集中的控制,因而需要集成到中央 IAM 解决方案中。
联合方法:基于用户组和其他用户属性的分配
解决 TCO 方面问题的另一种选择,也是迈向集中 IAM 管理的第一步,是根据 SAP Cloud Identity services 或企业身份提供者中已有的用户信息来授予权限。由于结合了来自身份提供者的数据(用户信息)和 SAP BTP 的数据(授予权限的规则),这被称为“联合”方法。
最典型的用例是在身份提供者中将用户分配到用户组,例如反映其归属于某个特定部门,并在 SAP BTP 中为该组授予特定权限。除了用户组之外,您还可以根据任何其他用户属性授予权限,例如用户类型或用户所在位置。
Note
由于用于权限分配的合理用户数据(例如组成员资格和组织数据)在 SAP ID service 中不可用,因此联合方法只能用于 SAP Cloud Identity services 的自定义租户。
尽管具有显而易见的简洁性优势,但此方法有以下限制:
它仅在某些场景中可用,并非覆盖整个 SAP BTP。具体而言,您可以将其用于账户层级所有级别上的账户成员(在目录级别,目前无法通过 SAP BTP 主控室进行配置),以及用于 Kyma 环境。对于平台用户,它在 Cloud Foundry 和 ABAP 环境中不可用。对于业务用户,授权和信任管理服务(XSUAA)支持此方法,但无法通过这种方式授予 AMS 策略。
在支持联合方法的地方,通常意味着基本用户配置文件会在首次访问时自动创建(“影子用户”)。但是,无法再次自动删除它们。这使您承担长期义务:审查这些数据,并在不再有正当理由存储时立即删除它们。
预置方法:通过 SAP Cloud Identity services 进行生命周期感知的复制
最先进的用户管理方法解决了上述选项的不足,是企业级场景的推荐做法。它并非 SAP BTP 专有,而是将 SAP BTP 用户和权限与客户系统架构中其他 SAP 和非 SAP 解决方案的用户和权限一起管理。其原理是:
您有一个或多个“主导”系统,它们充当用户/身份的来源,并控制其生命周期直至最终删除。任何更改都会自动预置到所有相关的“目标”系统,通常使用行业标准协议“跨域身份管理系统”(SCIM)。您还可以在系统架构的中央位置管理用户权限分配。这方面与联合方法类似,但当用户不再在相关系统工作时,不会再将其个人数据分散在系统架构的多个位置。
对于您系统架构中的 SAP 解决方案(包括 SAP BTP),SAP 建议使用您的 SAP Cloud Identity services 自定义租户作为枢纽,来管理 SAP 系统架构中的用户和权限。Identity Provisioning 组件为许多 SAP 解决方案以及本学习路径涵盖的大多数 SAP BTP 领域提供了连接器。唯一的例外是 Kyma 环境中的平台用户,对于这类用户,您可以放心地使用联合方法。Kyma 不会永久存储用户配置文件数据,因此上述 GDPR 问题在此情况下并不适用。
如果您使用公司范围的 IAM 解决方案,可以将 SAP Cloud Identity services 连接到它。更多详细信息请参见 SAP Discovery Center 中的参考架构。
本课其余配图

