動態資料遮罩 - Amazon Redshift

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

動態資料遮罩

概觀

使用 Amazon Redshift 中的動態資料遮罩 (DDM),您可以保護資料倉儲中的敏感資料。您可以操控 Amazon Redshift 在查詢時向使用者顯示敏感資料的方式,而無需在資料庫中進行轉換。您可以透過將自訂混淆規則套用至指定使用者或角色的遮罩政策,來控制資料的存取。如此一來,您就可以回應不斷變更的隱私權需求,而不必修改基礎資料或編輯 SQL 查詢。

動態資料遮罩原則會隱藏、混淆或虛擬化符合指定格式的資料。當附加至資料表時,遮罩運算式會套用至其一或多個資料欄。您可以進一步修改遮罩政策,只將政策套用至特定使用者,或套用至可以使用 角色型存取控制 (RBAC) 建立的使用者定義角色。此外,您可以在建立遮罩政策時使用條件資料欄,在儲存格層級上套用 DDM。如需條件式遮罩的詳細資訊,請參閱 條件式動態資料遮罩

您可以將不同混淆層級的多個遮罩政策套用至資料表中的相同資料欄,並將期指派給不同的角色。當您有不同角色且搭配套用至一個資料欄的不同政策時,為避免發生衝突,您可以為每個應用程式設定優先順序。如此一來,您就可以控制指定使用者或角色可以存取的資料。DDM 政策可以部分或完全修訂資料,或使用以 SQL、Python 或 AWS Lambda撰寫的使用者定義函數來雜湊資料。透過使用雜湊來遮罩資料,您可以在不存取潛在敏感資訊的情況下對此資料套用聯結。

電子nd-to-end 示例

下列 end-to-end 範例顯示如何建立遮罩原則並將其附加至資料欄。這些政策可讓使用者存取資料欄並查看不同的值,視附加至其角色的政策中的混淆程度而定。您必須是超級使用者或具有 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 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 支援以下例外情況:

    • 輸入類型為 INTN 的遮罩政策可以附加至大小為 INTM 的政策,只要 M < N 即可。例如,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 會傳回查詢的錯誤訊息。