数据隔离、访问授权，用好大数据为什么这么难？

如今，企业大数据资产在企业辅助决策、用户画像、推荐系统等诸多业务流程中扮演着越来越重要的作用，如何保证企业大数据在满足各业务部门数据访问需求的同时又能精细化保障数据访问安全、避免数据泄露是每个企业大数据资产管理者必须关注的话题。

笔者结合在华为云数据湖探索服务中的技术沉淀与丰富的企业数据安全管理经验，从以下几点来探讨如何精细化保障企业大数据安全。

1、企业大数据的安全挑战

2、数据资产权限管理的通用做法

3、以华为云DLI为例，对数据资产管理的实践&案例分析

4、未来展望

数据隔离、分层访问、授权，难题多多

企业大数据的日积月累，自然面临着大数据安全的挑战：数据来源广泛，来源于不同的业务单元，又要服务于各种业务单元，还需要对不同层级的员工设置不一样的权限。如何防范企业数据不被未经授权的用户访问，管理数据在不同业务单元的共享，隔离企业敏感数据……企业可能面临着以下的挑战：

1.1 数据隔离

不同的项目业务数据需要隔离，如游戏运营数据，企业在设计大数据分析平台时可能期望A游戏产生的业务数据用来支撑A游戏运营分析，B游戏产生的业务数据是支撑B游戏运营分析，那么需要对业务数据按项目进行隔离，A游戏运营部门员工只可访问A游戏运营数据，B游戏运营部门员工只可访问B游戏运营数据

1.2 数据分层访问

不同层级业务部门对数据具备不同的访问权限，高层级部门可以访问底层级部门的数据，而低层级部门不可访问高层级部门的数据。如省级部门可以访问地市级数据，而地市级部门只可访问本地市数据，不可访问跨区数据，也不可访问省级部门数据。这就要求对数据的权限管理需要具备分层管理能力，能够分层级授予不同的权限。

1.3 列级数据授权

不同业务部门对同一份数据的访问权限要求不同，所以要求能够对数据进行精细化授权。如银行系统中，用户表中的身份证号信息是敏感信息，柜台系统可以查询用户的身份证号，但推荐系统就不需要身份证信息，只需要用户ID就可以了。这种场景下需要对用户表能够分列授权，对不同的业务单元不同的权限。

1.4 批量授权

随着企业规模的增大，企业员工可能非常庞大，分部门授权，批量授权也是很常见的业务场景。例如销售部门下面员工很多，如果单个单个的给销售人员授权，会非常麻烦，人员流动时取消授权也很复杂，这时就需要能够批量授权或者基本角色的授权模型，来实现一次授权，部门内员工均可使用的目的。

四种权限模型，孰优孰劣？

目前比较流行的大数据分析平台的有Hadoop，Hive，Spark等，它们使用的权限模型有POSIX模型、ACL模型、SQL Standard模型和RBAC模型。其中Hadoop大数据平台使用了POSIX和ACL权限模型来管理数据，HIVE和Spark使用了ACL和RBAC权限模型来管理数据。

POSIX权限模型是基于文件的权限模型，与Linux系统的文件系统权限类似。即一个文件有相应的OWNER和GROUP，只能支持设置OWNER,、GROUP和其他用户的权限，可授权限也只有读写执行权限。

这种模型不适用于企业用户，有一个明显的缺点就是它只有一个GROUP，不能实现不同的GROUP有不同的权限，也无法实现精细化的权限管理，只能在文件级授权，所授权限也只有读写与执行权限。

ACL即Access Control List，ACL权限模型可以弥补POSIX权限模型的不足，可以实现比较精细化的权限管理。通过设置访问控制列表，我们可以授予某一个用户多个权限，也可以授予不同用户不同的权限。但ACL也有明显的缺点，当用户数较大时，ACL列表会变得庞大而难以维护，这在大企业中问题尤其明显。

RBAC（Role-Based Access Control）模型也是业界常用的一种权限模型。是基于用户角色的权限管理模型，其首先将一个或多个权限授权某一个角色，再把角色与用户绑定，也实现了对用户的授权。一个用户可以绑定一个或多个角色，用户具备的权限为所绑定角色权限的并集。RBAC可以实现批量授权，可以灵活维护用户的权限，是当前比较流行的权限管理模型。

SQL Standard模型是Hive/Spark使用权限模型之一，本质是使用SQL方式的授权语法来管理权限。Hive中的权限模型也是基于ACL和RBAC模型，即可以给单独的用户直接授权，也可能通过角色进行授权。

数据湖探索怎么做数据资产管理？

华为云DLI结合了ACL和RBAC两种权限模型来管理用户权限。DLI中涉及到的概念有：

DLI用户：DLI用户为IAM账号及其下的子用户，下面访问权限说明的用户均指IAM账号及其下的子用户。

DLI资源：DLI的资源分为数据库(Database)、表（table）、视图（View）、作业（Job）和队列(Queue)。资源是按项目隔离的，不同项目的资源不可互相访问。表和视图是数据库(Database)下的子资源。

DLI权限：DLI权限为执行DLI相关操作所需要的权限。DLI中的权限比较细，每项操作对应的权限都不一样，如创建表对应CREATE_TABLE权限，删除表对应DROP_TABLE权限, 查询对应SELECT权限等等。

DLI使用统一身份认证（IAM）的策略和DLI的访问控制列表（ACL）来管理资源的访问权限。其中统一身份认证（IAM）的策略控制项目级资源的隔离，和定义用户为项目的管理员还是普通用户。访问控制列表（ACL）控制队列，数据库，表，视图，列的访问权限和授权管理。

DLI使用统一身份认证来完成用户认证和用户角色管理。DLI在IAM中预定义了几个角色：Tenant Administrator（租户管理员），DLI Service Admin（DLI管理员），DLI Service User（DLI普通用户）。其中具备租户管理员或DLI管理员角色的用户在DLI内是管理员，可以操作该项目的所有资源，包括创建数据库，创建队列，操作项目下的数据库，表，视图，队列，作业。普通用户不可创建数据库，不可创建队列，依赖管理员的授权，可以执行创建表，查询表等操作。

DLI使用ACL和RBAC两种模型来管理用户权限。管理员或资源的所有者可以授予另外一个用户单个或多个权限，也可能创建角色，授予权限给创建好的角色，然后绑定角色和用户。

DLI提供了API和SQL语句两种方式来实现以上权限管理，方便用户灵活授权。具体使用方式可以参考DLI的权限管理。

案例分析

拿银行的大数据实践来分析下如何利用DLI来管理数据的权限。众所周知，银行积累了大量的用户数据，包括用户信息，交易信息，账户信息等等数以亿计的数据。而银行业务也是非常的复杂，涉及到柜员系统，监管部门，运营部门，营销部门等等各个业务线，各业务线对数据的要求不同，访问的权限不同。我们拿反洗钱业务与画像业务来简单介绍下如何利用DLI平台实现大数分析和数据资产权限管理。