Dieser Artikel stammt aus der Huawei Cloud Community „ Einführung in die Datendesensibilisierungsprinzipien und Nutzungsmethoden des GaussDB (DWS) Sicherheitsmanagements “ von VV Yixiao.
1. Einleitung
- Anwendbare Versionen: 8.2.0 und höher
Die Produktdaten-Desensibilisierungsfunktion von GaussDB (DWS) ist ein wichtiger technologischer Durchbruch für Datenbankprodukte zur Internalisierung und Konsolidierung von Datensicherheitsfunktionen. Es bietet die Desensibilisierungsfunktion für sensible Daten auf Spaltenebene im Rahmen bestimmter Benutzer und bietet die Vorteile von Flexibilität, Effizienz, Transparenz, Benutzerfreundlichkeit usw. Es verbessert die Datensicherheitsfunktionen des Produkts erheblich und sorgt für einen zuverlässigen Schutz sensibler Daten .
Der Beginn des Big-Data-Zeitalters hat das Betriebsmodell traditioneller Unternehmen untergraben und neues Produktionspotenzial geschaffen. Daten sind zu einem wichtigen Produktionsfaktor und Informationsträger geworden, und im Datenfluss verbergen sich auch höherwertige Informationen. Für Datenverantwortliche und Datenverarbeiter besteht die ursprüngliche Absicht und Bedeutung des Data Mining darin, den Wert des Datenflusses zu maximieren. Allerdings hat die Aufdeckung einer Reihe von Informationslecks dazu geführt, dass der Datensicherheit immer mehr Aufmerksamkeit geschenkt wird. Länder und Regionen erlassen und verbessern schrittweise Gesetze und Vorschriften in Bezug auf Datensicherheit und Datenschutz, um einen rechtlichen Schutz für den Schutz der Privatsphäre der Benutzer zu gewährleisten. Wie man die Datensicherheit und den Schutz der Privatsphäre auf technischer Ebene stärkt und mehr funktionale Anforderungen an das Data-Warehouse-Produkt selbst stellt, ist auch der effektivste Weg, die Datensicherheit aufzubauen.
GaussDB (DWS) Produktversion 8.1.1 veröffentlicht die Daten-Desensibilisierungsfunktion, die die Desensibilisierungsfunktion für sensible Daten auf Spaltenebene innerhalb des angegebenen Benutzerbereichs bietet. Sie bietet die Vorteile von Flexibilität, Effizienz, Transparenz und Benutzerfreundlichkeit und verbessert die Datensicherheitsfunktionen des Produkts.
2. Das Konzept der Datendesensibilisierung
Wie der Name schon sagt, dient die Datenmaskierung dazu, sensible Daten zu schützen. Alle Daten, deren Offenlegung der Gesellschaft oder Einzelpersonen ernsthaften Schaden zufügen könnte, sind allgemein sensible Daten. Persönlich identifizierbare Informationen wie Name, Ausweisnummer, Adresse, Mobiltelefonnummer und E-Mail-Adresse sind für die Offenlegung von Informationen wie Geschäftslizenznummer, Steuerbescheinigung, Mitarbeitergehalt, Geräteinformationen wie IP-Adresse und MAC nicht geeignet Adresse, Bankkartennummer, geschützte Ihre Gesundheitsdaten, geistige Eigentumsrechte usw. sind allesamt vertrauliche Informationen. Diese sensiblen Informationen werden durch Desensibilisierungsregeln deformiert, um einen zuverlässigen Schutz privater Daten zu erreichen. Zu den gängigen Desensibilisierungsregeln in der Branche gehören Ersetzung, Neuanordnung, Verschlüsselung, Kürzung und Maskierung. Benutzer können Desensibilisierungsregeln auch basierend auf dem gewünschten Desensibilisierungsalgorithmus anpassen.
Im Allgemeinen muss eine gute Implementierung der Datendesensibilisierung den folgenden zwei Prinzipien folgen: Erstens, versuchen Sie, aussagekräftige Informationen vor der Desensibilisierung für Anwendungen zu behalten, und zweitens, Hacker so weit wie möglich davon abzuhalten, sie zu knacken.
Die Datendesensibilisierung wird in statische Datendesensibilisierung und dynamische Datendesensibilisierung unterteilt. Bei der statischen Datendesensibilisierung handelt es sich um den „Bewegungs- und Simulationsersatz“ von Daten. Nachdem die Daten extrahiert und desensibilisiert wurden, werden sie zum freien Zugriff, Lesen und Schreiben an nachgeschaltete Verbindungen gesendet. Nach der Desensibilisierung werden die Daten von der Produktionsumgebung isoliert Erfüllen Sie Geschäftsanforderungen und gewährleisten Sie gleichzeitig die Sicherheit der Produktionsdatenbank. Die dynamische Datendesensibilisierung führt eine Desensibilisierungsverarbeitung in Echtzeit durch, während auf sensible Daten zugegriffen wird. Sie kann verschiedene Desensibilisierungsschemata für unterschiedliche Rollen, unterschiedliche Berechtigungen und unterschiedliche Datentypen implementieren und so sicherstellen, dass die zurückgegebenen Daten verfügbar und sicher sind.
2.1 Desensibilisierung dynamischer DWS-Daten
Die Daten-Desensibilisierungsfunktion von GaussDB (DWS) beseitigt die Schwachstellen der hohen Abhängigkeit und der hohen Kosten der Desensibilisierung auf der Ebene der Geschäftsanwendung und integriert die Daten-Desensibilisierung in die Sicherheitsfunktionen des Datenbankprodukts selbst und bietet so eine vollständige, sichere, flexible und transparente Lösung Satz von , einer benutzerfreundlichen Datendesensibilisierungslösung, die zur dynamischen Datendesensibilisierung gehört. Nachdem der Benutzer die sensiblen Felder identifiziert hat, kann er eine Maskierungsrichtlinie erstellen, indem er die integrierte Maskierungsfunktion basierend auf dem Zielfeld bindet. Die Schwärzungsrichtlinie hat eine Viele-zu-Eins-Beziehung zum Tabellenobjekt. Eine Maskierungsstrategie enthält drei Schlüsselelemente: Tabellenobjekt, effektive Bedingung, maskiertes Spalten-Maskierungsfunktionspaar. Es handelt sich um eine Sammlung aller maskierten Spalten im Tabellenobjekt, die je nach Dateneigenschaften unterschiedliche Maskierungsfunktionen verwenden können Abhängig von den effektiven Bedingungen und Desensibilisierungsspalten-Desensibilisierungsfunktionspaaren können auch Strategien in derselben Tabelle festgelegt werden. Nur wenn die effektive Bedingung wahr ist, löst die Abfrageanweisung die Desensibilisierung sensibler Daten aus. Der Desensibilisierungsprozess ist in die SQL-Engine integriert und für Benutzer der Produktionsumgebung transparent und unsichtbar.
Desensibilisierungstool für Agenten eines Drittanbieters im Vergleich zur DWS-Desensibilisierungs-Engine des Data Warehouse
- Das Proxy-Tool eines Drittanbieters ist eine Übertragungsstation zwischen Benutzern und Data-Warehouse-Clustern. Es handelt sich um ein Plug-in-Desensibilisierungstool außerhalb der Basis. Es kann nicht direkt an der Generierungsumgebung teilnehmen, und komplexe Szenarien sind schwierig zu handhaben.
- DWS ist eine Desensibilisierungs-Engine, die auf der direkten Interaktion zwischen der Data Warehouse-Basis und der Speicher-Engine und der SQL-Engine basiert. Sie führt während des Abfrageausführungsprozesses eine Desensibilisierung durch und die Desensibilisierungsergebnisse werden direkt an den Benutzer zurückgegeben.
- Das Agenten-Desensibilisierungstool ist eine statische Desensibilisierung, und die DWS-Desensibilisierungs-Engine ist eine dynamische Desensibilisierung.
Vorteile der dynamischen Desensibilisierungs-Engine von DWS
- Gute Basissynergie. Die Desensibilisierungs-Engine durchläuft viele Aspekte der Data-Warehouse-Basis und ist am Parsen, Umschreiben, Optimieren und Ausführen der SQL-Engine basierend auf voreingestellten Desensibilisierungsstrategien beteiligt. Der Desensibilisierungsprozess ist für den Benutzer unsichtbar.
- Richtlinien sind konfigurierbar. Kunden können sensible Daten anhand ihrer eigenen Geschäftsszenarien identifizieren und Desensibilisierungsstrategien für bestimmte Spalten von Geschäftstabellen flexibel voreinstellen.
- Strategien sind skalierbar. Das Produkt verfügt über eine integrierte Desensibilisierungsfunktion, die die häufigsten Desensibilisierungseffekte abdecken kann und benutzerdefinierte Desensibilisierungsfunktionen unterstützt.
- Datenverfügbarkeit. Die ursprünglichen sensiblen Daten in der Datenbank nehmen an der Operation teil und werden erst zum Zeitpunkt des Verlassens der Datenbank (wenn die Ergebnisse zurückgegeben werden) desensibilisiert.
-
Der Datenzugriff wird kontrolliert. Die ursprünglichen sensiblen Daten sind für Benutzer unter den Bedingungen für das Inkrafttreten der Desensibilisierungsrichtlinie nicht sichtbar.
-
Es werden nicht alle Szenendaten durchgesickert. Durch die Basisinteraktion kann das potenzielle Risiko des Verlusts sensibler Datenübertragungsverbindungen verringert werden.
Es ist sicherer und zuverlässiger, identifiziert verschiedene potenzielle böswillige Phishing-Szenarien vollständig und bietet wirksamen Schutz.
3. Verwendung der Datendesensibilisierung
Bei der dynamischen Datendesensibilisierung handelt es sich um einen Echtzeit-Desensibilisierungsprozess, der darauf basiert, ob die tatsächlichen Bedingungen während der Ausführung der Abfrageanweisung erfüllt sind. Validierungsbedingungen basieren normalerweise auf der Beurteilung der aktuellen Benutzerrolle. Der sichtbare Bereich sensibler Daten ist für verschiedene Benutzer voreingestellt. Der Systemadministrator hat die höchste Autorität und kann jederzeit jedes Feld in jeder Tabelle sehen. Die Identifizierung eingeschränkter Benutzerrollen ist der erste Schritt bei der Erstellung einer Desensibilisierungsstrategie.
Sensible Informationen hängen vom tatsächlichen Geschäftsszenario und den Sicherheitsdimensionen ab. Zu den sensiblen Feldern einzelner Benutzer gehören: Name, ID-Nummer, Mobiltelefonnummer, E-Mail-Adresse usw. im Bankensystem , es kann auch die Bankkartennummer, die Ablaufzeit, das Zahlungspasswort usw. betreffen; im Unternehmenssystem kann es auch das Gehalt, den Bildungshintergrund usw. betreffen; im medizinischen System kann es auch sein Dazu gehören auch Informationen zur medizinischen Behandlung usw. Daher ist die Identifizierung und Aussortierung sensibler Bereiche in bestimmten Geschäftsszenarien der zweite Schritt bei der Erstellung einer Desensibilisierungsstrategie.
Das Produkt verfügt über eine Reihe gängiger Desensibilisierungsfunktionsschnittstellen, mit denen Parameter für verschiedene Datentypen und Dateneigenschaften angegeben werden können, um unterschiedliche Desensibilisierungseffekte zu erzielen. Die Desensibilisierungsfunktion kann die folgenden drei integrierten Schnittstellen nutzen und unterstützt auch benutzerdefinierte Desensibilisierungsfunktionen. Die drei integrierten Desensibilisierungsfunktionen können die Desensibilisierungseffekte in den meisten Szenarien abdecken. Es wird nicht empfohlen, benutzerdefinierte Desensibilisierungsfunktionen zu verwenden.
-
MASK_NONE: Keine Desensibilisierung, nur für interne Tests.
-
MASK_FULL: Vollständige Desensibilisierung auf einen festen Wert.
-
MASK_PARTIAL: Verwenden Sie die angegebenen Maskierungszeichen, um den Inhalt innerhalb des Maskierungsbereichs teilweise zu maskieren.
Verschiedene Desensibilisierungssäulen können unterschiedliche Desensibilisierungsfunktionen verwenden. Beispielsweise werden bei Mobiltelefonnummern in der Regel die letzten vier Ziffern angezeigt und die vorderen Ziffern durch „*“ ersetzt; der Betrag wird einheitlich als fester Wert von 0 usw. angezeigt. Die Bestimmung der Desensibilisierungsfunktion, die an die Desensibilisierungssäule gebunden werden muss, ist der dritte Schritt bei der Erstellung einer Desensibilisierungsstrategie.
Am Beispiel der Mitarbeitertabelle emp eines Unternehmens, des Eigentümers der Tabelle, Benutzer alice, und der Benutzer matu und july stellen wir kurz den Verwendungsprozess der Datendesensibilisierung vor. Darunter enthält die Tabelle emp die Namen, Mobiltelefonnummern, E-Mails, Gehaltskartennummern, Gehälter und andere private Daten der Mitarbeiter. Der Benutzer Alice ist der Personalmanager und die Benutzer Matu und July sind normale Mitarbeiter.
Es wird davon ausgegangen, dass die Tabelle, der Benutzer und die Ansichtsberechtigungen des Benutzers für die Tabelle emp alle vorhanden sind.
1. Erstellen Sie eine Desensibilisierungsrichtlinie mask_emp, die es Alice nur ermöglicht, alle Mitarbeiterinformationen anzuzeigen, Matu und July sind für Gehaltskartennummern und Gehälter nicht sichtbar. Das Feld „card_no“ ist ein numerischer Typ und MASK_FULL wird verwendet, um es vollständig auf einen festen Wert von 0 zu desensibilisieren; das Feld „card_string“ ist ein Zeichentyp und MASK_PARTIAL wird verwendet, um die Originaldaten gemäß dem angegebenen Eingabe- und Ausgabeformat teilweise zu desensibilisieren; Das Feld „Gehalt“ ist ein numerischer Typ und die Zahl 9 wird verwendet, um alle Ziffernwerte vor der vorletzten Ziffer teilweise zu desensibilisieren.
postgres=# REDAKTIONSRICHTLINIE ERSTELLEN mask_emp ON emp WHEN (current_user != 'alice') COLUMN card_no WITH mask_full(card_no) HINZUFÜGEN, ADD COLUMN card_string WITH mask_partial(card_string, 'VVVVFVVVVFVVVVFVVVV','VVVV-VVVV-VVVV-VVVV','#',1,12), ADD SPALTE Gehalt MIT mask_partial(salary, '9', 1, length(salary) - 2);
Wechseln Sie zu Matu und Juli und sehen Sie sich die Mitarbeitertabelle emp an.
postgres=> SET ROLE matu PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; id | Name | Telefonnr. | Kartennummer | Kartenzeichenfolge | E-Mail | Gehalt | Geburtstag ----+------+-------------+---------+-------------- -------+---------------------+------------+------ --------------- 1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999,9990 | 02.10.1999 00:00:00 2 | Bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999,9990 | 12.12.1989 00:00:00 3 | cici | 15512231233 | | | [email protected] | | 06.11.1992 00:00:00 (3 Reihen) postgres=> SET ROLE july PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; id | Name | Telefonnr. | Kartennummer | Kartenzeichenfolge | E-Mail | Gehalt | Geburtstag ----+------+-------------+---------+-------------- -------+---------------------+------------+------ --------------- 1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999,9990 | 02.10.1999 00:00:00 2 | Bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999,9990 | 12.12.1989 00:00:00 3 | cici | 15512231233 | | | [email protected] | | 06.11.1992 00:00:00 (3 Reihen)
2. Aufgrund der Arbeitsanpassung trat Matu in die Personalabteilung ein, um sich an den Rekrutierungsangelegenheiten des Unternehmens zu beteiligen, und alle Mitarbeiterinformationen waren ebenfalls sichtbar, wodurch die wirksamen Bedingungen der Richtlinie geändert wurden.
postgres=> ALTER REDACTION POLICY mask_emp ON emp WHEN(current_user NOT IN ('alice', 'matu'));
Wechseln Sie zu den Benutzern matu und july und sehen Sie sich die Mitarbeitertabelle emp erneut an.
postgres=> SET ROLE matu PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; id | Name | Telefonnr. | Kartennummer | Kartenzeichenfolge | E-Mail | Gehalt | Geburtstag ----+------+-------------+------------------+----- -+----------------------+---------- ---+--------------------- 1 | anny | 13420002340 | 1234123412341234 | 1234-1234-1234-1234 | [email protected] | 10000,0000 | 02.10.1999 00:00:00 2 | Bob | 18299023211 | 3456345634563456 | 3456-3456-3456-3456 | [email protected] | 9999,9900 | 12.12.1989 00:00:00 3 | cici | 15512231233 | | | [email protected] | | 06.11.1992 00:00:00 (3 Reihen) postgres=> SET ROLE july PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; id | Name | Telefonnr. | Kartennummer | Kartenzeichenfolge | E-Mail | Gehalt | Geburtstag ----+------+-------------+---------+-------------- -------+---------------------+------------+------ --------------- 1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999,9990 | 02.10.1999 00:00:00 2 | Bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999,9990 | 12.12.1989 00:00:00 3 | cici | 15512231233 | | | [email protected] | | 06.11.1992 00:00:00 (3 Reihen)
3. Mitarbeiterinformationen wie Telefonnummer, E-Mail und Geburtstag sind ebenfalls private Daten. Aktualisieren Sie die Maskierungsrichtlinie mask_emp und fügen Sie drei Maskierungsspalten hinzu.
postgres=> ALTER REDACTION POLICY mask_emp ON emp ADD COLUMN phone_no WITH mask_partial(phone_no, '*', 4);
postgres=> ALTER REDACTION POLICY mask_emp ON emp ADD COLUMN email WITH mask_partial(email, '*', 1, position('@' in email));
postgres=> ALTER REDACTION POLICY mask_emp ON emp ADD COLUMN birthday WITH mask_full(birthday);
Wechseln Sie zum Benutzer july und sehen Sie sich die Mitarbeitertabelle emp an.
postgres=> SET ROLE july PASSWORD 'Gauss@123'; postgres=> SELECT * FROM emp; id | Name | Telefonnr. | Kartennummer | Kartenzeichenfolge | E-Mail | Gehalt | Geburtstag ----+------+-------------+---------+-------------- -------+---------------------+------------+------ --------------- 1 | anny | 134********* | 0 | ####-####-####-1234 | ********163.com | 99999,9990 | 1970-01-01 00:00:00 2 | Bob | 182********* | 0 | ####-####-####-3456 | ***********qq.com | 9999,9990 | 1970-01-01 00:00:00 3| cici | 155******** | | | **************sina.com | | 1970-01-01 00:00:00 (3 Reihen)
4. Unter Berücksichtigung der Benutzerfreundlichkeit der Benutzerinteraktion bietet GaussDB (DWS) die Systemansichten redaction_policies und redaction_columns, um Benutzern die direkte Anzeige weiterer Desensibilisierungsinformationen zu erleichtern.
postgres=> SELECT * FROM redaction_policies;
Objektschema | Objektbesitzer | Objektname | Richtlinienname | Ausdruck | aktivieren | Richtlinienbeschreibung
---------------+--------------+-------------+----- --------+---------------------+----- ---+--------------------
öffentlich | Alice | emp | mask_emp | ("current_user"() = 'july'::name) | t |
(1 Reihe)
postgres=> SELECT object_name, columns_name, function_info FROM redaction_columns;
Objektname | Spaltenname | function_info
-------------+-------------+---------------------- -------------------------------------------------- -----------------
emp | Kartennummer | mask_full(card_no)
emp | Kartenzeichenfolge | mask_partial(card_string, 'VVVVFVVVVFVVVVFVVVV'::text, 'VVVV-VVVV-VVVV-VVVV'::text, '#'::text, 1, 12)
emp | E-Mail | mask_partial(email, '*'::text, 1, "position"(email, '@'::text))
emp | Gehalt | mask_partial(salary, '9'::text, 1, (length((salary)::text) - 2))
emp | Geburtstag | mask_full(Geburtstag)
emp | Telefonnr. | mask_partial(phone_no, '*'::text, 4)
(6 Reihen)
5. Plötzlich, eines Tages, wenn Mitarbeiterinformationen innerhalb des Unternehmens weitergegeben werden können, löschen Sie einfach die Maskierungsrichtlinie mask_emp der emp-Tabelle.
postgres=> DROP REDACTION POLICY mask_emp ON emp;
Weitere Einzelheiten zur Verwendung finden Sie in der Produktdokumentation zu GaussDB (DWS).
4. Unsichtbare Datendesensibilisierung
Bei Verwendung der Datendesensibilisierungsfunktion kann es vorkommen, dass sensible Daten vor der Ausgabe verarbeitet und berechnet werden. Wenn in diesem Fall die desensibilisierten Daten für datenbankinterne Berechnungen verwendet werden, wirken sich die desensibilisierten Daten selbst unter Bedingungen wie Aggregatfunktionen und Filterbedingungen auf die Abfrageergebnisse aus. Daher werden die desensibilisierten Daten zur Behebung dieses Phänomens verwendet . Min führt die Fähigkeit ein, als unsichtbar zu gelten. Das sogenannte Unsichtbare bedeutet, dass die ursprünglichen sensiblen Daten in der Datenbank zur Teilnahme an Verarbeitungsberechnungen verwendet werden und die sensiblen Daten erst desensibilisiert werden, wenn sie aus der Datenbank versendet werden. Um die berechenbare unsichtbare Funktion verwenden zu können, müssen Sie den Schalter „enable_redactcol_computable=on“ setzen.
Derzeit gibt es folgende Szenarien, die die direkte Beteiligung sensibler Daten an Verarbeitungsberechnungen unterstützen:
-
SELECT nullif(salary, 1) FROM emp; Projektionsspaltenausdruck nullif
-
SELECT email LIKE '%.com' FROM emp; projizierte Spalte LIKE-Ausdruck
-
SELECT to_days(birth) FROM david.emp; Projektionsspaltenfunktion to_days
-
SELECT count(*) FROM emp; Aggregatfunktion
-
SELECT * FROM emp WHERE cardid IS NOT NULL; Filterbedingungen
-
SELECT name, avg(salary) * 12 FROM emp GROUP BY name; Gruppierungsbedingung (name ist ein desensibilisiertes Feld)
-
SELECT (SELECT Gehalt+10 FROM emp ORDER BY id LIMIT 1); Unterabfragepositionsprojektionsspaltenausdruck
-
Die beiden Tabellen verwenden sensible Felder als Zuordnungsbedingungen
-
CTE-Ausdruck projizierte Spalte
Die folgenden Szenarien lösen eine Desensibilisierung der Daten zum Zeitpunkt des Versands aus:
-
Tabellenabfrage
-
Abfrage anzeigen
-
DML RETURNING-Klausel
-
COPYExport
-
GDS-Tabellenexport
-
CURSOR… FETCH
-
Die Definition der gespeicherten Prozedur verwendet die maskierte Tabelle, um die gespeicherte Prozedur abzufragen.
4.1 Vererbung der Desensibilisierungsstrategie
Bei INSERT/UPDATE/MERGE INTO/CREATE TABLE AS-Anweisungen wird die desensibilisierte Vererbung ausgelöst, wenn es sich bei der Unterabfrage um eine Projektionsoperation für ein sensibles Feld handelt, sodass die neue Tabelle mit sensiblen Informationen dieselben Informationen wie die Quelltabelle enthält Die Strategie vermeidet das Problem des Verlusts vertraulicher Daten, indem vertrauliche Daten aus der Quelltabelle in eine neue Tabelle eingefügt und dann die neue Tabelle abgefragt werden. Darüber hinaus gehört die Vererbung der Maskierungsrichtlinie zur Tabellendimensionsaktivität, und die Vererbungsaktivität achtet nicht darauf, ob die Maskierungsrichtlinie unter den aktuellen Sitzungs- oder Rollenbedingungen im Unterabfrageteil wirksam wird.
Der erste Schritt bei der Vererbung der Desensibilisierungsstrategie besteht darin, eine sensible Abstammungsanalyse durchzuführen. Damit jeder Benutzer eine DML-Anweisung ausführt, werden der Unterabfrageteil der Quelltabelle und seine Zielprojektionsspalte durchlaufen Die Zielprojektionsspalte ist ein Desensibilisierungsfeld. Es wird davon ausgegangen, dass bei Verwendung der Quelltabelle zum Einfügen/Aktualisieren von Zieltabellendaten das Risiko besteht, dass vertrauliche Daten der Quelltabelle offengelegt werden.
Wenn Sie eine Maskierungsstrategie erben, generieren Sie zunächst die Maskierungsstrategieinformationen und Maskierungsfeldinformationen, die für die Zieltabelle gelten, aus den vertraulichen Informationen der im Durchlauf markierten Quelltabelle. Anschließend generiert das integrierte System eine Richtlinienerstellungsanweisung und schreibt sie in die Systemtabelle pg_redaction_policy/pg_redaction_column. Die integrierte Desensibilisierungsrichtlinie heißt „inherited_rp“. Setzen Sie abschließend das Markierungsfeld für die Vererbung von Metadaten der Systemtabelle auf „true“.
Beachten Sie, dass, wenn die INSERT-Ausführungssitzung/der Benutzer die Auslösebedingungen erfüllt, das zurückgegebene Ergebnis beim Drucken des Einfügeergebnisses mit der RETURNING-Klausel desensibilisiert wird und die Protokollinformationen „Übergeordnete Redaktionsrichtlinien/Spalten“ die Quelle der Richtlinienvererbung aufzeichnen .
Mit der Einführung des Vererbungsverhaltens bei Desensibilisierungsrichtlinien sind einige Konfliktszenarien bei Desensibilisierungsrichtlinien entstanden. Beispielsweise ist die Zielspalte der SELECT-Anweisungsabfrage nicht das ursprüngliche sensible Feld, sondern ein komplexer Ausdruck des sensiblen Feldes. Der Ausdruck wird zuerst berechnet und dann desensibilisiert. Die beiden Unterzweige der SETOP-Set-Operation verwenden unterschiedliche Desensibilisierungseffekte für dieselbe Zielspalte. Wie wird das Desensibilisierungsergebnis der Zielspalte der äußeren Anweisung zu diesem Zeitpunkt definiert? Bei der sensiblen Abstammungsanalyse mehrerer INSERT/UPDATE-Vorgänge übernehmen die Quelltabellenprojektionsspalten derselben Zielspalte unterschiedliche Desensibilisierungseffekte, und die effektiven Bedingungen der Quelltabellenrichtlinie können auch unterschiedlich sein. Wie sollte die Desensibilisierungsrichtlinie in diesem Fall vererbt werden? ?
Für diese Konfliktszenarien wird auf der Grundlage des Prinzips, dass der Schutz aller sensiblen Daten des Benutzers vor dem Durchsickern Vorrang vor der Desensibilisierungswirkung sensibler Daten hat, die keine Originalmerkmale aufweisen, bei Auftreten eines Desensibilisierungseffektkonflikts ein Upgrade auf das Allgemeine durchgeführt Desensibilisierungseffekt mask_full. mask_full ist eine vollständige Maskierungsfunktion, die jeden Datentyp abdecken kann. Sie konzentriert sich nur auf den Rückgabewerttyp des Ausdrucks, wodurch sichergestellt werden kann, dass die maskierten Daten nicht verloren gehen Originaldaten, wodurch das maskierte Ergebnis weniger lesbar ist. Darüber hinaus legen die Berechnungsergebnisse für Funktionsausdrücke wie Länge und Anzahl keine Originaldatenmerkmale und -informationen offen, sodass die ALTER FUNCTION ... [NOT] MASKED-Syntax bereitgestellt wird, um Benutzer bei der manuellen Konfiguration einer nicht desensibilisierenden Funktion zu unterstützen Whitelist.
4.2 Schutz vor bösartigem Phishing
Bestimmte sensible Informationen sind bekannt und durch mehrere heuristische Übereinstimmungen werden die sichtbaren Benutzerinformationen umgekehrt bestätigt, wodurch die privaten Daten des Benutzers gestohlen werden. Ordnen Sie vertrauliche Informationen heuristisch zu, indem Sie Filterbedingungen oder Projektionsoperationen verwenden, die Ausdrücke in Form von Äquivalenzurteilen unterstützen. Diese Verhaltensweisen beim Extrahieren privater Benutzerdaten durch bekannte konstante Werte und Äquivalenz-/ähnliche Äquivalenzbeurteilungsausdrücke sind böswillige Versuche.
postgres=> SELECT name FROM emp WHERE name in('张三');
INFO: Das Ergebnis der Zielspalte {"name"} ist maskiert.
Name
------
offen*
(1 Reihe)
Wie im obigen Beispiel gezeigt, wurden die Namensinformationen des Benutzers zwar desensibilisiert, da die Abfragebedingung für den Benutzer „Zhang San“ gilt, auch wenn sie auf „Zhang*“ desensibilisiert sind, können wir die Desensibilisierung hier dennoch leicht ermitteln Bei sensiblen Informationen handelt es sich um „Zhang San“, wodurch die Gefahr besteht, dass die Benutzerinformationen von Zhang San verloren gehen.
Als Reaktion auf dieses Problem haben wir ein „Pessimismus“-Modell eingeführt, das das Risiko einer böswilligen Arbitrage birgt und daher verboten werden sollte.
postgres=> SELECT name FROM emp WHERE name in('张三');
FEHLER: Die Schwärzungsspalte „Name“ kann in Äquivalenzbedingungen mit dem Wert „const“ nicht referenziert werden.
TIPP: Bitte verwenden Sie den EXPLAIN-Befehl, um weitere Details anzuzeigen.
Die Szenarien, in denen böswillige Arbitrage unter Verwendung von Konstanten verboten ist, werden wie folgt zusammengefasst:
1. Ausdrücke zur Beurteilung konstanter Äquivalenz, zusammengesetzte Ausdrücke und äquivalente Ausdrücke für desensibilisierte Felder
2. Unter der Annahme, dass das Namensfeld ein desensibilisiertes Feld ist und die aktuelle Sitzung die Richtlinienauslösebedingungen erfüllt, weist die Anweisung die folgenden (aber nicht beschränkt auf) Merkmale auf, es besteht das Risiko einer böswilligen Arbitrage und die Ausführung ist verboten:
• Name = 'Zhang San'
• name = 'Zhang San' ODER name = '李思'
• Name in ('Zhang San', '李思')
• CASE-Name WHEN '张三' THEN true …
• CASE WHEN Name in ('张三', '李思') THEN …
• Erweitertes Paket dbms_output.put_line
3. Beim Ausführen der Anweisung wird ein Fehler gemeldet: FEHLER: Redaktionsspalte „Name“ kann in Äquivalenzbedingungen mit const-Wert nicht referenziert werden.
5. Umsetzungsprinzip der Datendesensibilisierung
Die Datendesensibilisierungsfunktion von GaussDB (DWS) basiert auf dem vorhandenen Implementierungsframework der SQL-Engine und ermöglicht eine Desensibilisierungsverarbeitung in Echtzeit, die für die Außenwelt während der Ausführung von Abfrageanweisungen durch eingeschränkte Benutzer nicht wahrnehmbar ist. Die interne Implementierung ist in der obigen Abbildung dargestellt. Wir betrachten die Schwärzungsrichtlinie als eine an das Tabellenobjekt gebundene Regel. Während der Abfrageumschreibungsphase des Optimierers wird jeder TargetEntry der TargetList im Abfragebaum durchlaufen, wenn eine Schwärzungsspalte der Basistabelle beteiligt ist Wenn die Desensibilisierungsregel wirksam wird (dh die wirksamen Bedingungen der Desensibilisierungsrichtlinie sind erfüllt und die Aktivierung aktiviert), wird daraus geschlossen, dass das zu desensibilisierende Var-Objekt an diesem TargetEntry beteiligt ist. Zu diesem Zeitpunkt ist die Desensibilisierungsspaltensystemtabelle pg_redaction_column wird durchlaufen, um die entsprechende Desensibilisierungsspaltenbindung zu finden. Eine bestimmte Desensibilisierungsfunktion kann durch den entsprechenden FuncExpr ersetzt werden. Nach dem oben beschriebenen Umschreiben des Abfragebaums generiert der Optimierer automatisch einen neuen Ausführungsplan, der Ausführende führt die Ausführung gemäß dem neuen Plan aus und die Abfrageergebnisse werden für vertrauliche Daten desensibilisiert.
Im Vergleich zur ursprünglichen Anweisung führt die Anweisungsausführung mit Datendesensibilisierung zu einer logischen Verarbeitung der Datendesensibilisierung, was zwangsläufig zu einem zusätzlichen Overhead für die Abfrage führt. Diese Kosten werden hauptsächlich von drei Faktoren beeinflusst: der Datengröße der Tabelle, der Anzahl der maskierten Spalten, die an der Abfrage der Zielspalte beteiligt sind, und der in der maskierten Spalte verwendeten Maskierungsfunktion.
Nehmen Sie für eine einfache Abfrageanweisung die tpch-Tabelle customer als Beispiel, um die oben genannten Faktoren zu testen, wie in der folgenden Abbildung dargestellt.
In den Abbildungen (a) und (b) verwendet der Basistabellenkunde je nach Feldtyp und Eigenschaften entweder die Desensibilisierungsfunktion MASK_FULL oder die Desensibilisierungsfunktion MASK_PARTIAL. MASK_FULL desensibilisiert Originaldaten beliebiger Länge und Art nur auf einen festen Wert, sodass sich das Ausgabeergebnis stark von den Originaldaten unterscheidet. Abbildung (a) zeigt die Ausführungszeit einfacher Abfrageanweisungen in desensibilisierten und nicht desensibilisierten Szenarien unter verschiedenen Datenskalen. Ausgefüllte Symbole stehen für Nicht-Desensibilisierungsszenarien und leere Symbole für eingeschränkte Benutzer, also Desensibilisierungsszenarien. Es ist ersichtlich, dass der Unterschied zwischen der Abfragezeit mit Desensibilisierung und der ursprünglichen Aussage umso größer ist, je größer die Datengröße ist. Abbildung (b) zeigt die Auswirkung einer unterschiedlichen Anzahl maskierter Spalten, die an der Abfrage beteiligt sind, auf die Leistung der Anweisungsausführung bei einer 10-fachen Datenskala. Wenn eine maskierte Spalte beteiligt ist, ist die Abfrage mit Maskierung langsamer als die ursprüngliche Anweisung. Es wird darauf zurückgeführt, dass diese Spalte die Teilmaskierungsfunktion MASK_PARTIAL verwendet. Das Abfrageergebnis ändert nur das Format des Ergebnisses und die Länge des Ergebnisinhalts ändert sich nicht. Dies steht im Einklang mit der theoretischen Vermutung, dass „die Ausführung einer Anweisung mit Desensibilisierung zu einer entsprechenden Leistungseinbuße führt“. Als die Anzahl der an der Abfrage beteiligten maskierten Spalten zunahm, entdeckten wir ein seltsames Phänomen. Das desensibilisierte Szenario wurde tatsächlich schneller ausgeführt als die ursprüngliche Anweisung. Bei der weiteren Verfolgung der Maskierungsfunktionen, die mit maskierten Spalten in Mehrspaltenszenarien verbunden sind, haben wir festgestellt, dass gerade aufgrund der maskierten Spalten mithilfe der Maskierungsfunktion MASK_FULL die Ausgabeergebnismenge im Vergleich zu den Originaldaten viel Zeit spart und somit mehrere Daten enthält -Spaltenabfragen effizienter. Einfache Abfragen mit Datenmaskierung sind tatsächlich viel schneller.
Um die obige Spekulation zu untermauern, haben wir die Maskierungsfunktion angepasst. Alle maskierten Spalten verwenden MASK_PARTIAL, um die Originaldaten teilweise zu maskieren, sodass die externe Lesbarkeit der Originaldaten in den Maskierungsergebnissen erhalten bleiben kann. Wie in Abbildung © dargestellt, ist die Anweisung mit Datenmaskierung etwa 10 % schlechter als die ursprüngliche Anweisung, wenn alle maskierten Spalten Teilmaskierungsfunktionen zugeordnet sind. Theoretisch liegt diese Verschlechterung im akzeptablen Bereich. Der obige Test gilt nur für einfache Abfrageanweisungen, wenn die Anweisung komplex genug ist, um Aggregatfunktionen oder komplexe Ausdrucksoperationen einzuschließen, kann dieser Leistungsabfall offensichtlicher sein.
6. Zusammenfassung
Die Desensibilisierungsfunktion für Produktdaten von GaussDB (DWS) ist ein wichtiger technologischer Durchbruch für Datenbankprodukte zur Internalisierung und Konsolidierung von Datensicherheitsfunktionen. Sie deckt hauptsächlich die folgenden drei Aspekte ab:
Eine Reihe einfacher und benutzerfreundlicher Syntax für Strategien zur Desensibilisierung von Daten;
Eine Reihe flexibel konfigurierbarer integrierter Desensibilisierungsfunktionen, die häufige Desensibilisierungseffekte für private Daten abdecken;
Eine vollständige und praktische Anwendungslösung für Desensibilisierungsstrategien ermöglicht eine transparente und effiziente Desensibilisierung von Originalanweisungen in Echtzeit während der Ausführung.
Alles in allem kann diese Daten-Desensibilisierungsfunktion die Daten-Desensibilisierungsanforderungen der Geschäftsszenarien der Kunden vollständig erfüllen, den Desensibilisierungseffekt allgemeiner privater Daten unterstützen und einen zuverlässigen Schutz sensibler Daten erreichen.
[Warme Erinnerung] Wenn Sie während des Gebrauchs Fragen haben, können Sie jederzeit mitteilen und Feedback geben.
High-School-Schüler erstellen ihre eigene Open-Source-Programmiersprache als Coming-of-Age-Zeremonie – scharfe Kommentare von Internetnutzern: Unter Berufung auf die Verteidigung hat Apple den M4-Chip RustDesk veröffentlicht. Inländische Dienste wurden wegen grassierenden Betrugs eingestellt . In Zukunft plant er, ein unabhängiges Spiel auf der Windows-Plattform Taobao (taobao.com) zu produzieren. Webversionsoptimierungsarbeiten neu starten, Ziel für Programmierer, Visual Studio Code 1.89 veröffentlicht Java 17, die am häufigsten verwendete Java LTS-Version, Windows 10 hat eine Marktanteil von 70 %, Windows 11 geht weiter zurück ; Google unterstützt Hongmeng bei der Übernahme von Open-Source-Rabbit-R1;