Hinweise zur dynamischen Datenmaskierung - Amazon Redshift

Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im Blog-Posting.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Hinweise zur dynamischen Datenmaskierung

Bei Verwendung der dynamischen Datenmaskierung ist Folgendes zu beachten:

  • Beim Abfragen von Objekten, die aus Tabellen erstellt wurden, wie z. B. Ansichten, werden den Benutzern Ergebnisse auf der Grundlage ihrer eigenen Maskierungsrichtlinien angezeigt, nicht basierend auf den Richtlinien des Benutzers, der die Objekte erstellt hat. Einem Benutzer mit der Analystenrolle, der eine von einem Benutzer mit der Rolle „secadmin“ erstellte Ansicht abfragt, würden beispielsweise Ergebnisse mit Maskierungsrichtlinien angezeigt, die der Analystenrolle angefügt sind.

  • Damit bei Verwendung des Befehls EXPLAIN keine sensiblen Maskierungsrichtlinienfilter offengelegt werden, können nur Benutzer mit der Berechtigung SYS_EXPLAIN_DDM Maskierungsrichtlinien sehen, die in EXPLAIN-Ausgaben angewendet wurden. Standardmäßig verfügen Benutzer nicht über die Berechtigung SYS_EXPLAIN_DDM.

    Nachfolgend sehen Sie die Syntax zum Gewähren der Berechtigung für einen Benutzer oder eine Rolle.

    GRANT EXPLAIN MASKING TO ROLE rolename

    Weitere Informationen zum Befehl EXPLAIN finden Sie unter EXPLAIN.

  • Benutzer mit unterschiedlichen Rollen können je nach verwendeten Filter- oder Join-Bedingungen unterschiedliche Ergebnisse sehen. So schlägt beispielsweise die Ausführung eines Befehls SELECT für eine Tabelle mit einem bestimmten Spaltenwert fehl, wenn für den Benutzer, der den Befehl ausführt, eine Maskierungsrichtlinie angewendet wurde, die diese Spalte verschleiert.

  • DDM-Richtlinien müssen vor allen Prädikatoperationen oder Projektionen angewendet werden. Die Maskierungsrichtlinien können Folgendes beinhalten:

    • Kostengünstige konstante Operationen wie die Umwandlung eines Werts in Null

    • Operationen zu moderaten Kosten wie HMAC-Hashing

    • Kostenintensive Operationen wie Aufrufe externer benutzerdefinierter Lambda-Funktionen

    Daher empfehlen wir, wenn möglich einfache Maskierungsausdrücke zu verwenden.

  • Sie können DDM-Richtlinien für Rollen mit Sicherheitsrichtlinien auf Zeilenebene verwenden. Beachten Sie jedoch, dass RLS-Richtlinien vor DDM angewendet werden. Ein Ausdruck für die dynamische Datenmaskierung ist nicht in der Lage, eine Zeile zu lesen, die durch RLS geschützt wurde. Weitere Informationen zu RLS finden Sie unter Sicherheit auf Zeilenebene.

  • Wenn Sie den Befehl COPY zum Kopieren aus Parquet in geschützte Zieltabellen verwenden, sollten Sie in der COPY-Anweisung explizit Spalten angeben. Weitere Informationen zur Zuordnung von Spalten mit COPY finden Sie unter Optionen für das Mapping von Spalten.

  • DDM-Richtlinien können nicht an die folgenden Relationen angefügt werden:

    • Systemtabellen und Kataloge

    • Externe Tabellen

    • Datasharing-Tabellen

    • Datenbankübergreifende Relationen

    • Temporäre Tabellen

    • Korrelierte Abfragen

  • DDM-Richtlinien können Suchtabellen enthalten. Suchtabellen können in der USING-Klausel enthalten sein. Die folgenden Relationstypen können nicht als Suchtabellen verwendet werden:

    • Systemtabellen und Kataloge

    • Externe Tabellen

    • Datasharing-Tabellen

    • Ansichten, materialisierte Ansichten und Late-Binding-Ansichten.

    • Datenbankübergreifende Relationen

    • Temporäre Tabellen

    • Korrelierte Abfragen

    Im Folgenden finden Sie ein Beispiel für das Anfügen einer Maskierungsrichtlinie an eine Suchtabelle.

    --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;
  • Sie können keine Maskierungsrichtlinie anfügen, die zu einer mit dem Typ und der Größe der Zielspalte nicht kompatiblen Ausgabe führen würde. So können Sie beispielsweise keine Maskierungsrichtlinie anfügen, die eine 12-stellige Zeichenfolge an eine VARCHAR (10)-Spalte ausgibt. Amazon Redshift unterstützt die folgenden Ausnahmen:

    • Eine Maskierungsrichtlinie mit dem Eingabetyp INTN kann einer Richtlinie mit der Größe INTM angefügt werden, solange M < N ist. Beispielsweise kann eine BIGINT (INT8)-Richtlinie an eine Smallint (INT4)-Spalte angefügt werden.

    • Eine Maskierungsrichtlinie mit dem Eingabetyp NUMERIC oder DECIMAL kann immer an eine FLOAT-Spalte angefügt werden.

  • DDM-Richtlinien können nicht für die Freigabe von Daten verwendet werden. Wenn der Produzent der Datashare-Daten eine DDM-Richtlinie an eine Tabelle im Datashare anfügt, können Benutzer des Datenkonsumenten, die versuchen, die Tabelle abzufragen, nicht mehr auf die Tabelle zugreifen. Der Versuch, die Beziehung zu einem Datashare hinzuzufügen, schlägt auf dem produzentenseitigen Cluster oder Namespace mit dem folgenden Fehler fehl:

    <ddm_protected_relation> or a relation dependent on it is protected by a masking policy and cannot be added to a datashare

    Wenn Sie eine Maskierungsrichtlinie an eine Beziehung auf Produzentenseite anhängen und die Beziehung bereits in einem Datashare enthalten ist, schlägt der Versuch, die Beziehung auf der Verbraucherseite abzufragen, mit dem folgenden Fehler fehl:

    cross-cluster query of the masked relation <ddm_protected_relation> is not supported.

    Sie können DDM für Datashares deaktivieren, indem Sie den Befehl ALTER TABLE mit dem Parameter MASKING OFF FOR DATASHARES verwenden. Weitere Informationen finden Sie unter ALTER TABLE.

  • Sie können keine Beziehungen abfragen, für über angefügte DDM-Richtlinien verfügen, wenn Ihre Werte für eine der folgenden Konfigurationsoptionen nicht dem Standardwert der Sitzung entsprechen:

    • enable_case_sensitive_super_attribute

    • enable_case_sensitive_identifier

    • downcase_delimited_identifier

    Erwägen Sie, die Konfigurationsoptionen Ihrer Sitzung zurückzusetzen, wenn Sie versuchen, eine Beziehung mit einer angefügten DDM-Richtlinie abzufragen und die Meldung „Die DDM-geschützte Beziehung unterstützt keine Konfiguration auf Sitzungsebene, da die Berücksichtigung von Groß- und Kleinschreibung vom Standardwert abweicht“ angezeigt wird.

  • Wenn Ihr bereitgestellter Cluster oder Serverless-Namespace über Richtlinien zur dynamischen Datenmaskierung verfügt, werden die folgenden Befehle für normale Benutzer blockiert:

    ALTER <current_user> SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier

    Wenn Sie DDM-Richtlinien erstellen, empfehlen wir, die Einstellungen der Standardkonfigurationsoptionen für normale Benutzer so zu ändern, dass sie den Einstellungen der Sitzungskonfigurationsoptionen zum Zeitpunkt der Erstellung der Richtlinie entsprechen. Superuser und Benutzer mit der Berechtigung ALTER USER können dies mithilfe von Parametergruppeneinstellungen oder dem Befehl ALTER USER erreichen. Informationen zu Parametergruppen finden Sie unter Amazon-Redshift-Parametergruppen im Amazon-Redshift-Verwaltungshandbuch. Informationen zum Befehl ALTER USER finden Sie unter ALTER USER.

  • Ansichten und Late-Binding-Ansichten mit DDM-Richtlinien auf Zeilenebene können nicht von normalen Benutzern mit dem Befehl CREATE VIEW ersetzt werden. Um Ansichten oder LBVs durch RLS-Richtlinien zu ersetzen, trennen Sie zunächst alle mit diesen verknüpften DDM-Richtlinien, ersetzen Sie die Ansichten oder LBVs und fügen Sie die Richtlinien erneut an. Superuser und Benutzer mit der sys:secadmin-Berechtigung können CREATE VIEW für Ansichten oder LBVs mit DDM-Richtlinien verwenden, ohne die Richtlinien zu trennen.

  • Ansichten mit angefügten DDM-Richtlinien können nicht auf Systemtabellen und Ansichten verweisen. Late-Binding-Ansichten können auf Systemtabellen und Ansichten verweisen.

  • Late-Binding-Ansichten mit angefügten DDM-Richtlinien können nicht auf verschachtelte Daten in Data Lakes verweisen, wie z. B. JSON-Dokumente.

  • Late-Binding-Ansichten können keine DDM-Richtlinien angefügt werden, wenn die Late-Binding-Ansicht von einer Ansicht referenziert wird.

  • DDM-Richtlinien, die an Late-Binding-Ansichten angefügt sind, werden anhand des Spaltennamens angefügt. Bei der Abfrage überprüft Amazon Redshift, ob alle Maskierungsrichtlinien, die an die Late-Binding-Ansicht angefügt sind, erfolgreich angewendet wurden und ob der Ausgabespaltentyp der Late-Binding-Ansicht mit den Typen in den angefügten Maskierungsrichtlinien übereinstimmt. Wenn die Überprüfung fehlschlägt, gibt Amazon Redshift einen Fehler für die Abfrage zurück.

  • Sie können benutzerdefinierte Sitzungskontextvariablen verwenden, wenn Sie DDM-Richtlinien erstellen. Im folgenden Beispiel werden Sitzungskontextvariablen für eine DDM-Richtlinie festgelegt.

    -- Set a customized context variable. SELECT set_config('app.city', 'XXXX', FALSE); -- Create a MASKING policy using current_setting() to get the value of a customized context variable. CREATE MASKING POLICY city_mask WITH (city VARCHAR(30)) USING (current_setting('app.city')::VARCHAR(30)); -- Attach the policy on the target table to one or more roles. ATTACH MASKING POLICY city_mask ON tickit_users_redshift(city) TO ROLE analyst, ROLE dbadmin;

    Einzelheiten zum Festlegen und Abrufen angepasster Sitzungskontextvariablen finden Sie unter SET, SET_CONFIG, ZEIGEN, CURRENT_SETTING und RESET. Weitere Informationen zum Ändern der Serverkonfiguration im Allgemeinen finden Sie unter Modifizieren der Serverkonfiguration.

    Wichtig

    Bei der Verwendung von Sitzungskontextvariablen innerhalb von DDM-Richtlinien ist die Sicherheitsrichtlinie von dem Benutzer oder der Rolle abhängig, der/die die Richtlinie aufruft. Achten Sie darauf, Schwachstellen zu vermeiden, wenn Sie Sitzungskontextvariablen in DDM-Richtlinien verwenden.