从安全角度上,产品正在逐步完善数据权限控制,避免出现数据安全性问题。
1、在系统运维(运维设置) /系统选项/ 高级设置 增加了下面的设置项:
序号 | 选项 | 内容 | |
---|---|---|---|
1 | RAW_SQL_APPLY_MASKING_RULE | 如果在源表设置了脱敏规则,通过原生SQL数据集、SQL查询等方式取数,如果开启了该项,能正常继承到对应的脱敏规则,从而对数据进行脱敏处理。 系统系统默认false,即不开启(不生效);设置成true,则是开启。 | |
2 | RAW_SQL_APPLY_ROW_PERMISSIONS | 如果在源表设置了行权限,通过原生SQL数据集、SQL查询等方式取数,并且开启了该设置项,能正常继承到源表的行权限,从而控住数据的泄露; 系统系统默认false,即不开启(不生效);设置成true,则是开启。 | |
3 | RAW_SQL_APPLY_ROW_PERMISSIONS_CHECK_TABLE | 如果在源表设置了资源权限(表或列权限),通过原生SQL数据集、SQL查询等方式取数,如果开启了该项,能正常继承到对应的资源权限,从而对数据进行控制; 原生SQL数据集资源权限;系统系统默认false,即不开启(不生效);设置成true,则是开启。 | |
| |||
4 | RAW_SQL_APPLY_REFS_REQUIRE_READ_PURVIEW | 为了引起不必要的解释,建议不要开,不要开! 如果用户对表或者字段有 引用 权限,但是没有 查看 权限,如果需要控制不能查看数据,可以开启: 开启之后,”执行时“会抛出异常,但是能正常保存。 原因:是由于产品本身有 引用 权限就能查看数据,该控制项仅仅只是控制数据安全性,用户无法在 SQL查询 中随意输入表、字段 查找没有 查看 权限的数据。 |
2、以下是关于功能是否控住的说明:
功能项 | 是否控住 | |||
序号 | 类型 | 数据行权限 | 表和列资源权限 | 脱敏规则 |
3 | 原生SQL数据集 | |||
4 | SQL数据集 | |||
5 | 数据模型的SQL查询 | |||
6 | 参数的备选值、默认值(SQL查询) (公共设置的参数+模型参数+模型查询参数+电子表格的参数管理) | |||
7 | 用户属性的 SQL【表达式】 | |||
8 | 转换规则 的SQL【表达式】 | |||
9 | ETL 中 【关系数据源】、ETL 中【数据查询】 | |||
10 | ETL 中的【Spark SQL脚本】、【SQL查询】 | X | X | X |
11 | ETL的【Python脚本】 | X | X | X |
12 | 计划任务 | X | X | X |
13 | 业务主题的业务属性、计算字段 | X | X | X |
14 | 即席、透视分析的计算字段 | X | X | X |
15 | 自助数据集的计算字段 | X | X | X |
16 | (旧)数据集的告警 | X | X | X |
基于原生SQL查询、SQL数据集等创建的报表也会继承权限限制,在报表层会有相应的提示。
可查看:SQL查询控制数据示例。
1、Select a.* 使用通配符进行查询时,解析器可以从当前 Smartbi 的基础表信息中获取,但是当使用到没有添加到 Smartbi 中的表时,会无法进行判断导致出现问题;并且由于数据库返回的顺序未必与 Smartbi 中记录的顺序必定一致,所以也可能存在错乱的问题 2、多条 SQL 语句: 由于在 SQL 中是可以使用临时表等方式,在多条 SQL 语句下的逻辑会变得非常复杂,目前还没考虑这种场景。 3、复杂 SQL 语句 :只能保证基本语法检测,但是对于部分数据库而言可以拼接字符串后再执行,这种用法也是无法处理的。 |