大数据 2023 年 3 月 13 日

数据安全与Apache Ranger

讨论了数据安全与Apache Ranger的调研结果、插件原理等。

数据安全

功能需求

数据脱敏/加密

针对隐私信息和机密信息，比如姓名、帐号、IMEI、手机号、客户号、QQ号、银行帐号、位置信息等，制定了去隐私化处理策略，明确不同的隐私信息数据对应采用不同的脱敏策略。由于去隐私化处理必须是无损的、可逆的，本次策划还包含还原管理：针对需求，把系统中的部分隐私信息还原，并输出给内、外部系统。

脱敏/加密策略

DataX-Masking
  • Hiding算法
  • Floor算法
  • Enumerate算法
  • Prefix Preserve算法
  • MD5算法
  • EDP算法
  • AES算法
  • FPE算法
  • RSA算法

数据查询流程

数据查询时序图
数据查询时序图
  1. 用户提出数据查询请求，由后台验证用户权限
    • 无权限查询数据，则提示用户，结束流程
    • 用户有权限，则进入下一步骤
  2. 用户为脱敏权限，则对查询结果进行脱敏处理，返回脱敏后的数据信息，流程结束
  3. 用户为不脱敏权限，则前台展示不脱敏的数据原始信息，流程结束

后端处理流程

后端处理时序图
后端处理时序图
  1. 应用系统调用api向数据服务请求数据查询
  2. 数据服务调用数据安全api，请求用户的权限信息
  3. 数据安全查询出该用户对应的权限信息，返回给数据服务
  4. 数据服务根据返回的权限信息，先判断用户是否有权限
    • 没有查询权限，返回无权限的信息
    • 用户有权限，则进入下一步骤
  5. 数据服务根据api查询到对应的数据，根据权限信息，调用包含脱敏算法的jar包中的方法，对数据进行脱敏处理
  6. 将数据返回给应用系统

  7. 数据库中的是明文，在数据服务查询数据之后，对查询结果根据用户的权限，进行脱敏

  8. 对于可逆加密，密钥如何存储？

权限管理

用户：由User或Group来表达，User代表访问资源的用户，Group代表用户所属的用户组。 资源：由Resource来表达，主要是资产的资源 权限：由(AllowACL, DenyACL)来表达，类似白名单和黑名单机制，AllowACL用来描述允许访问的情况，DenyACL用来描述拒绝访问的情况。
策略组成：

Service = List policy Policy = List source + AllowACL + DenyACL AllowACL = List allow + List allowException DenyACL = List deny + List denyException AccessItem = List user + List accessType

一条Policy有(allow, allowException, deny, denyException)这么四组AccessItem
总体来说，这四组AccessItem的作用优先级由高到低依次是：
denyException > deny > allowException > allow
权限校验流程图
权限校验流程图

Apache Ranger调研

结构图

Apache Ranger架构图
Apache Ranger架构图
Ranger主要由以下三个组件构成：
RangerAdmin: 以RESTFUL形式提供策略的增删改查接口，同时内置一个Web管理页面。
AgentPlugin: 嵌入到各系统执行流程中，定期从RangerAdmin拉取策略，根据策略执行访问决策树，并且记录访问审计。插件的实现原理将在后文详细介绍。
UserSync: 定期从LDAP/Unix/File中加载用户，上报给RangerAdmin。

RangerAdmin与认证引擎

数据库设计
数据库E-R图
数据库E-R图
类设计
类图
类图
示例：
{
    "id": 4,
    "guid": "d6218120-1b66-43e6-9fef-9c917a8e9e25",
    "name": "cl1_hive-2-20151222041952",
    "description": "Default Policy for Service: cl1_hive",
    "isAuditEnabled": true,
    "isEnabled": true,
    "service": "cl1_hive",
    "resourceSignature": "c834ed2b8c7462d2aa8bbffdb05226c8",
    "resources": {
        "database": {
            "isExcludes": false,
            "isRecursive": false,
            "values": [
                "*"
            ]
        },
        "udf": {
            "isExcludes": false,
            "isRecursive": false,
            "values": [
                "*"
            ]
        }
    },
    "policyItems": [
        {
            "accesses": [
                {
                    "isAllowed": true,
                    "type": "select"
                },
                {
                    "isAllowed": true,
                    "type": "update"
                },
                {
                    "isAllowed": true,
                    "type": "create"
                },
                {
                    "isAllowed": true,
                    "type": "drop"
                },
                {
                    "isAllowed": true,
                    "type": "alter"
                },
                {
                    "isAllowed": true,
                    "type": "index"
                },
                {
                    "isAllowed": true,
                    "type": "lock"
                },
                {
                    "isAllowed": true,
                    "type": "all"
                }
            ],
            "conditions": [],
            "delegateAdmin": true,
            "groups": [],
            "users": [
                "ambari-qa"
            ]
        }
    ],
    "allowExceptions": [],
    "denyPolicyItems": [],
    "denyExceptions": [],
    "createTime": 1450757992000,
    "createdBy": "amb_ranger_admin",
    "updateTime": 1450757995000,
    "updatedBy": "amb_ranger_admin",
    "version": 2
}
验证流程
  1. 根据policyType判断验证引擎，如果是RangerPolicy.POLICY_TYPE_ACCESS，则使用Acl Summary验证，否则使用PolicyItemEvaluator进行验证
  2. Acl Summary验证
    1. 将RangerPolicy中的policyItems、denyPolicyItems、allowExceptions、denyExceptions策略，对策略组中的每个RangerPolicyItemAccess组成key为accessType，value为AccessResult的Map，再将用户、用户组、角色作为key，value为Map存为AccessInfo
    2. 根据AccessInfo中的权限信息，先获取该用户的权限信息中accessType对应的accessResult，如果为null，再根据用户所属的用户组去获取，最后再通过角色去获取
    3. 根据获取到的accessResult，判断值是否为通过
  3. PolicyItemEvaluator验证
    1. 根据RangerPolicy中的policyItems、denyPolicyItems、allowExceptions、denyExceptions策略组生成对应每个组的校验执行器组RangerDefaultPolicyItemEvaluator
    2. 先根据denyPolicyItems策略组对应的执行器进行校验，分别验证用户、用户组、角色是否符合，如果符合，返回该执行器RangerDefaultPolicyItemEvaluator
    3. 再根据denyExceptions策略组对应的执行器进行校验，如果符合，返回null
    4. 如果2、3步返回的为null，再验证policyItems、allowExceptions，同2、3步
    5. 最后判断返回的执行器不为null并且为通过类型的执行器，则验证通过

参考资料：

大数据安全管理框架 Ranger 原理介绍

插件原理（以Hive为例）

  1. 插件加载

    类加载：plugin-shim中通过ranger-plugin-classloader模块加载对应插件中的类，该模块实现了一个自定义的类加载器，会根据模块名称去指定目录加载class文件

    初始化：plugin-shim中通过加载对应的启动类，进行初始化操作

  2. 权限同步

    插件初始化时，RangerBasePlugin的init()方法会初始化权限同步线程PolicyRefresher，并调用startRefresher()方法启动线程

    1. 初始化时会根据配置的类名进行反射，创建客户端类RangerAdminRESTClient，该类初始化时会与Ranger Server创建HTTP连接
    2. 启动同步线程，从阻塞队列policyDownloadQueue 中取出一个元素，执行一次loadRoles() 和 loadPolicy()
    3. 启动一个Timer，定期（默认 30 秒）向阻塞队列policyDownloadQueue 添加一个元素
    4. loadPolicy()负责更新策略
      1. 调用客户端接口，获取最新的策略信息
      2. 如果返回为空，则代表没有更新，再去缓存(目前是一个缓存的文件)中获取
      3. 将获取到的策略更新到插件RangerBasePlugin中，更新状态信息

  3. 插件验证流程

    1. 获取用户信息、访问的资源信息RangerHiveResource、访问的操作类型HiveAccessType，组装成访问请求RangerHiveAccessRequest
    2. 插件RangerHivePlugin通过继承的RangerBasePlugin的isAccessAllowed获取验证结果
    3. 具体验证引擎由统一的RangerPolicyEngineImpl进行实现，插件可通过RangerChainedPlugin进行额外的拓展
    4. 结果为验证失败时，抛出异常HiveAccessControlException

参考资料：

Ranger Hive plugin 源代码分析 Ranger 对 HDFS 权限管理探索与实践

版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）

作者： OnlyWaitY 发表日期：2023 年 3 月 13 日