前言

最近在真实的HANA Cloud某POC实现过程中，遇到一个比较棘手的涉及Multitenant的权限问题。Cloud与非Cloud的HANA Platform在解决问题的要求方面还是有很大的不同的。

不能通过停止DB服务的情况下做相关变更，那样会极大影响整个Cloud服务的质量。

基本情况是这样，在HANA Cloud的前一个版本中，SAC （专用于分析的服务), 针对新加的Tenant，用户权限是完全足够的。新用户默认就能访问:  _SYS_BI这个schema下边的对象的SELECT权限。

但是在后来的版本中，逐渐将这些权限收回去了。尤其是SAC的访问过程中：需要访问：_SYS_BI.BIMC_VARIABLE_ASSIGNMENT。查看具体的trace文件，发现有下边的错误信息：

Error message like below:

[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946814 i TraceContext     TraceContext.cpp(01411) : UserName="6D4*********4F_C1HNC3**********4LO_RT" ApplicationUserName="vcap" ApplicationName="sap.bc.ina.service.v2" StatementExecutionID=844433520231183
[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946814 e mds_sql          Connection.cpp(00870) : Error: 71000258
[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946828 e mds_sql          Connection.cpp(00871) : insufficient privilege: Detailed info for this error can be found with guid '64215F14***************' at Authorization/insuffPriv/impl/InsufficientPrivilegeThrow.cpp:343
[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946837 e mds_sql          Connection.cpp(00872) : line 4294967295, col 4294967295, pos 4294967295, src file Authorization/insuffPriv/impl/InsufficientPrivilegeThrow.cpp, src line343
[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946845 e mds_sql          Connection.cpp(00877) : SELECT VARIABLE_NAME,MODEL_ELEMENT_NAME,MODEL_ELEMENT_TYPE,PLACEHOLDER_NAME FROM _SYS_BI.BIMC_VARIABLE_ASSIGNMENT WHERE SCHEMA_NAME = ? AND CATALOG_NAME=? AND CUBE_NAME=? ORDER BY VARIABLE_NAME ASC WITH HINT (OPTIMIZATION_LEVEL(RULE_BASED))
[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946847 e mds_sql          Connection.cpp(00886) : Parameter 0: 6D436A932BAE4307BD99C794B584604F
[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946848 e mds_sql          Connection.cpp(00886) : Parameter 1: 6D436A932BAE4307BD99C794B584604F
[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946850 e mds_sql          Connection.cpp(00886) : Parameter 2: CV_SMP_STATISTICS
[5043]{207318}[2317/-1] 2023-06-05 07:30:47.946882 e mds              Message.cpp(00752) : Exception in /data/jenkins/workspace/3300_build_hana/s/mds/sql/Connection.cpp, line 902, error 42017, msg: Not authorized : Detailed info for this error can be found with guid '64215F14***************'
[2917]{207317}[2863/-1] 2023-06-05 07:30:47.947551 e mds              Message.cpp(00533) : /data/jenkins/workspace/3300_build_hana/s/mds/mdq/processor/Engine.cpp(1984) [42208] Can't read the view :

分析

HANA Cloud对Multitenant，无论是加密处理，还是非加密处理，处理的都非常完善。Tenant之间的数据隔离更是作到滴水不漏。甚至dbadmin用户默认情况下都访问不了创建出来的各个tenant对应的schema的数据。这也让最后的tenant(客户）对他们自己的业务数据比较放心。

这个tenant对应的schema，是由HDI container创建的过程中生成的。伴随着这个schema, 有一个DI用户和一个RT用户，前者负责部署，后者负责访问该schema。而现在问题就出在这个创建出来的RT用户，已经没有权限去访问_SYS_BI下边的系统视图了。

如果单从HDI Container的deploy脚度出发，尝试去动态授权role，动作将比较繁琐。因为用户名提前是未知的。

可能得需要提前在整个Database级别，创建如下的role:

CREATE ROLE FOO_ROLE;
GRANT SELECT ON SCHEMA _SYS_BI TO FOO_ROLE;
...

最后要在hdi deploy的相关hdi脚本中，添加.hdbroles的相关grant动作。比较繁琐。

那么有没有办法从顶层，直接通过相关授权达到目的呢？

直接找到HANA开发的同事，得到的答复也是模棱两可，只是提示要从内部相关的一些role里头去找。我们进入Hana Cloud的控制台，从系统的Role列表里头，发现有一个非常重要的role:  XSA_APP_USER_ROLE，每一个新建的tenant RT用户，都自动拥有这个role。用户是动态的，但是这个Role名字是固定的。

接着我们再看下其中的一个用户的role的情况：

这个role，所在的schema现在变成了：BROKER_USER。以前老版本的HANA，用的schema是：SYS_XS_HANA_BROKER。

基于此，思路一下子就简化了很多，我们可以单独建一个补充的Role, 给这个Role一些_SYS_BI的权限，当然也需要补上SAC需要的其它的一些重要权限。然后把这个role补到XSA_APP_USER_ROLE中去就能达到目的了。

CREATE ROLE FOO_REQUIRED_ROLE;
GRANT EXECUTE ON "SYS"."EXECUTE_MDS" TO FOO_REQUIRED_ROLE;
GRANT SELECT ON "SYS"."CS_FREESTYLE_COLUMNS" TO FOO_REQUIRED_ROLE;    
GRANT SELECT ON "SYS"."CS_KEY_FIGURES"    TO FOO_REQUIRED_ROLE;   
........
GRANT SELECT ON "SYS"."VIEW_COLUMNS" TO FOO_REQUIRED_ROLE;
GRANT SELECT ON "SYS"."DUMMY"    TO FOO_REQUIRED_ROLE;
GRANT SELECT ON "SYS"."OBJECT_DEPENDENCIES"    TO FOO_REQUIRED_ROLE;
GRANT SELECT ON "SYS"."SYNONYMS" TO FOO_REQUIRED_ROLE;
GRANT SELECT ON SCHEMA _SYS_BI TO FOO_REQUIRED_ROLE;
GRANT FOO_REQUIRED_ROLE TO BROKER_USER.XSA_APP_USER_ROLE;

最后一句：GRANT FOO_REQUIRED_ROLE TO BROKER_USER.XSA_APP_USER_ROLE;很重要，它把这些缺失的权限都被给XSA_APP_USER_ROLE了，于是新建的user自动具备这个role的相关权限了，问题也就解决了。只需要dbadmin在整个Database级别执行一次就可以了。

至此问题得以解决。如果仔细探索一下另一个role:  RT_DEFAULTS，目测如果对它进行相应的权限修改，似乎也是可以解决的。只是它的语义和XSA_APP_USER_ROLE的语义是不同的。这里不再过多的描述。

附加说明：

说到dbadmin用户，当它尝试去访问tenant对应的schema中的对象时，都会遇到权限问题, 隔离性做的非常强大。

SET SCHEMA 75955B****559143AE0;
SELECT * FROM APPS a ;
SQL Error [258] [HY000]: SAP DBTech JDBC: [258]: insufficient privilege: Detailed info for this error can be found with guid '920B69BB3391A14D92A07C3FD777250A'

有人会说，那我直接grant select那个schema给自己，不行吗？还真不行。HANA Cloud在更底层做了限制。

CREATE ROLE SEAN_NEEDED;
GRANT SELECT ON SCHEMA "75955B****559143AE0" TO SEAN_NEEDED;

GRANT SEAN_NEEDED TO dbadmin;

这个在第2行就会报错。

SQL Error [258] [HY000]: SAP DBTech JDBC: [258]: insufficient privilege: Detailed info for this error can be found with guid '7ACCA550B79D764C957F86928BEC8E96'

由于中间涉及到#DI admin,  Group Admin等多个比较复杂的权限设置，想让dbadmin直接访问tenant schema中的数据，还是比较麻烦的。

小结：

HANA Cloud在支持Multitenant方面，权限层面和数据隔离方面，都在底层提供了支持。用户只需要按照它的使用方式进行使用就好，目前就是通过HDI-shared的那种一实例一个schema，对应一个Tenant(租户), 而且客户可以自行控制是否对这个schema中的所有数据进行加密(RSA方式)，非常灵活，安全方面几乎能做到极致。

PostgreSQL如果要实现相同的功能，或者接近相同的功能，还是挺难做到的。手动动作非常多。但也正为手动动作多，更需要了解一些稍底层的功能。使用pgcrypto插件，并灵活动作触发器，在一定程度上也能做到数据库的加密。通过预定义role，并且对新的tenant创建，定义一套user/schema的规则，也能模拟出来schema之间完全隔离的效果。只是需要自己精心设计。这方面，HANA Cloud是完全自动的。用户只需要定义好它的表以及其它相关对象的HDI定义，然后部署上去就可以独立使用了。