动态数据掩蔽 - Amazon Redshift
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

动态数据掩蔽

概述

使用 Amazon Redshift 中的动态数据掩蔽 (DDM),您可以保护数据仓库中的敏感数据。您可以操纵 Amazon Redshift 在查询时如何向用户显示敏感数据,而无需在数据库中对其进行转换。您可以通过将自定义模糊处理规则应用于给定用户或角色的屏蔽策略来控制对数据的访问。这样,您无需更改底层数据或编辑 SQL 查询即可响应不断变化的隐私要求。

动态数据掩蔽策略会隐藏、模糊处理或假名化与给定格式匹配的数据。附加到表时,对表的一个或多个列应用屏蔽表达式。您可以进一步修改屏蔽策略,使其仅应用于某些用户,或者应用于您可以使用 基于角色的访问控制 (RBAC) 创建的用户定义角色。此外,在创建屏蔽策略时,您可以使用条件列在单元格级别应用 DDM。有关条件屏蔽的更多信息,请参阅条件动态数据掩蔽

您可以将具有不同模糊处理级别的多个屏蔽策略应用于表中的同一列,并将它们分配给不同的角色。为避免在不同角色对一列应用不同策略时发生冲突,可以为每个应用程序设置优先级。通过这种方式,您可以控制给定用户或角色可以访问哪些数据。DDM 策略可以部分或完全编辑数据,也可以使用以 SQL、Python 或 Amazon Lambda 编写的用户定义函数对其进行哈希处理。通过使用哈希屏蔽数据,您可以对这些数据应用联接,而无需访问潜在的敏感信息。

端到端示例

下面是一个端到端的示例,显示了如何创建屏蔽策略并将其附加到列。这些策略让用户可以访问列并查看不同的值,具体取决于与其角色相关的策略的混淆程度。您必须是超级用户或具有 sys:secadmin 角色才能运行此示例。

创建屏蔽策略

首先,创建一个表并填入信用卡值。

--create the table CREATE TABLE credit_cards ( customer_id INT, credit_card TEXT ); --populate the table with sample values INSERT INTO credit_cards VALUES (100, '4532993817514842'), (100, '4716002041425888'), (102, '5243112427642649'), (102, '6011720771834675'), (102, '6011378662059710'), (103, '373611968625635') ; --run GRANT to grant permission to use the SELECT statement on the table GRANT SELECT ON credit_cards TO PUBLIC; --create two users CREATE USER regular_user WITH PASSWORD '1234Test!'; CREATE USER analytics_user WITH PASSWORD '1234Test!'; --create the analytics_role role and grant it to analytics_user --regular_user does not have a role CREATE ROLE analytics_role; GRANT ROLE analytics_role TO analytics_user;

接下来,创建应用于分析角色的屏蔽策略。

--create a masking policy that fully masks the credit card number CREATE MASKING POLICY mask_credit_card_full WITH (credit_card VARCHAR(256)) USING ('000000XXXX0000'::TEXT); --create a user-defined function that partially obfuscates credit card data CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT) RETURNS TEXT IMMUTABLE AS $$ import re regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})") match = regexp.search(credit_card) if match != None: first = match.group(1) last = match.group(2) else: first = "000000" last = "0000" return "{}XXXXX{}".format(first, last) $$ LANGUAGE plpythonu; --create a masking policy that applies the REDACT_CREDIT_CARD function CREATE MASKING POLICY mask_credit_card_partial WITH (credit_card VARCHAR(256)) USING (REDACT_CREDIT_CARD(credit_card)); --confirm the masking policies using the associated system views SELECT * FROM svv_masking_policy; SELECT * FROM svv_attached_masking_policy;

附加屏蔽政策

将屏蔽政策附加到信用卡表中。

--attach mask_credit_card_full to the credit card table as the default policy --all users will see this masking policy unless a higher priority masking policy is attached to them or their role ATTACH MASKING POLICY mask_credit_card_full ON credit_cards(credit_card) TO PUBLIC; --attach mask_credit_card_partial to the analytics role --users with the analytics role can see partial credit card information ATTACH MASKING POLICY mask_credit_card_partial ON credit_cards(credit_card) TO ROLE analytics_role PRIORITY 10; --confirm the masking policies are applied to the table and role in the associated system view SELECT * FROM svv_attached_masking_policy; --confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user SET SESSION AUTHORIZATION regular_user; SELECT * FROM credit_cards; --confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user SET SESSION AUTHORIZATION analytics_user; SELECT * FROM credit_cards;

修改掩蔽政策

以下部分介绍了如何修改动态数据掩蔽政策。

--reset session authorization to the default RESET SESSION AUTHORIZATION; --alter the mask_credit_card_full policy ALTER MASKING POLICY mask_credit_card_full USING ('00000000000000'::TEXT); --confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000' SELECT * FROM credit_cards;

分离和删除屏蔽策略

以下部分显示如何通过从表中删除所有动态数据掩蔽策略来分离和删除屏蔽策略。

--reset session authorization to the default RESET SESSION AUTHORIZATION; --detach both masking policies from the credit_cards table DETACH MASKING POLICY mask_credit_card_full ON credit_cards(credit_card) FROM PUBLIC; DETACH MASKING POLICY mask_credit_card_partial ON credit_cards(credit_card) FROM ROLE analytics_role; --drop both masking policies DROP MASKING POLICY mask_credit_card_full; DROP MASKING POLICY mask_credit_card_partial;

使用动态数据掩蔽时的注意事项

使用动态数据掩蔽时,请考虑以下事项:

  • 在查询通过表创建的对象(例如视图)时,用户将看到基于他们自己的屏蔽策略的结果,而不是创建对象的用户的策略。例如,具有分析师角色的用户查询 secadmin 创建的视图时,他将看到附加到分析师角色的屏蔽策略的结果。

  • 为防止 EXPLAIN 命令可能暴露敏感的屏蔽策略筛选条件,只有拥有 SYS_EXPLAIN_DDM 权限的用户才能看到在 EXPLAIN 输出中应用的屏蔽策略。默认情况下,用户没有 SYS_EXPLAIN_DDM 权限。

    以下是向用户或角色授予权限的语法。

    GRANT EXPLAIN MASKING TO { username | ROLE rolename }

    有关 EXPLAIN 命令的更多信息,请参阅 EXPLAIN

  • 根据所使用的筛选条件或联接条件,具有不同角色的用户会看到不同的结果。例如,如果运行命令的用户应用了会模糊处理特定列的屏蔽策略,则在使用该列值的表上运行 SELECT 命令将失败。

  • 必须在任何谓词操作或预测之前应用 DDM 策略。掩蔽策略可以包括:

    • 低成本常量操作,例如将值转换为 null

    • 中等成本操作,例如 HMAC 哈希

    • 高成本操作,例如调用外部 Lambda 用户定义函数

    因此,如果可能,我们建议您使用简单屏蔽表达式。

  • 您可以对具有行级安全策略的角色使用 DDM 策略,但请注意,RLS 策略在 DDM 之前应用。动态数据掩蔽表达式将无法读取受 RLS 保护的行。有关 RLS 的更多信息,请参阅 行级别安全性

  • 使用 COPY 命令从 parquet 复制到受保护的目标表时,您应在 COPY 语句中明确指定列。有关使用 COPY 映射列的更多信息,请参阅列映射选项

  • DDM 策略不能附加到以下关系:

    • 系统表和目录

    • 外部表

    • 数据共享表

    • 实体化视图

    • 跨数据库关系

    • 临时表

    • 关联的查询

  • DDM 策略可以包括查找表。查找表可以存在于 USING 子句中。以下关系类型不能用作查找表:

    • 系统表和目录

    • 外部表

    • 数据共享表

    • 视图、实体化视图和后期绑定视图

    • 跨数据库关系

    • 临时表

    • 关联的查询

    以下是将掩蔽政策附加到查找表的示例。

    --Create a masking policy referencing a lookup table CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING ( CASE WHEN credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup) THEN '000000XXXX0000' ELSE REDACT_CREDIT_CARD(credit_card) END ); --Provides access to the lookup table via a policy attached to a role GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;
  • 您不能附加所产生的输出与目标列的类型和大小不兼容的屏蔽策略。例如,您不能附加将 12 个字符长的字符串输出到 VARCHAR(10) 列的屏蔽策略。Amazon Redshift 支持以下例外情况:

    • 只要 M < N,输入类型为 INTN 的屏蔽策略就可以附加到大小为 INTM 的策略上。例如,BIGINT (INT8) 输入策略可以附加到 smallint (INT4) 列。

    • 输入类型为 NUMERIC 或 DECIMAL 的屏蔽策略始终可以附加到 FLOAT 列。

  • DDM 策略不能用于数据共享。如果数据共享的数据创建者将 DDM 策略附加到数据共享中的表,则尝试查询该表的数据使用者用户将无法访问该表。无法将附加 DDM 策略的表添加到数据共享中。

  • 如果以下任一配置选项的值与会话的默认值不匹配,则无法查询附加了 DDM 策略的关系:

    • enable_case_sensitive_super_attribute

    • enable_case_sensitive_identifier

    • downcase_delimited_identifier

    如果您试图查询附加了 DDM 策略的关系,并看到消息“DDM 保护的关系不支持会话级别配置,因为区分大小写不同于其默认值”,请考虑重置会话的配置选项。

  • 当您的预调配集群或无服务器命名空间具有任何动态数据掩蔽策略时,普通用户将无法使用以下命令:

    ALTER <current_user> SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier

    创建 DDM 策略时,我们建议您更改普通用户的默认配置选项设置,使其与创建策略时会话的配置选项设置相匹配。超级用户和具有 ALTER USER 权限的用户可以使用参数组设置或 ALTER USER 命令来执行此操作。有关参数组的信息,请参阅《Amazon Redshift 管理指南》中的 Amazon Redshift 参数组。有关 ALTER USER 命令的信息,请参阅 ALTER USER

  • 普通用户无法使用 CREATE VIEW 命令替换已附加 DDM 策略的视图和后期绑定视图。要替换具有 DDM 策略的视图或 LBV,请先分离附加到这些视图的所有 DDM 策略,替换视图或 LBV,然后重新附加策略。具有 sys:secadmin 权限的超级用户和用户可以在具有 DDM 策略的视图或 LBV 上使用 CREATE VIEW,而无需分离策略。

  • 附加了 DDM 策略的视图无法引用系统表和视图。后期绑定视图可以引用系统表和视图。

  • 附加了 DDM 策略的后期绑定视图无法引用数据湖中的嵌套数据,例如 JSON 文档。

  • 如果任何视图引用了后期绑定视图,则后期绑定视图不能附加 DDM 策略。

  • 附加到后期绑定视图的 DDM 策略按列名附加。在查询时,Amazon Redshift 会验证是否已成功应用附加到后期绑定视图的所有掩蔽策略,以及后期绑定视图的输出列类型是否与附加掩蔽策略中的类型相匹配。如果验证失败,Amazon Redshift 将返回查询错误。