Support- und Fachanwender müssen manchmal Datensätze sehen, ohne alle personenbezogenen Werte zu benötigen. Oracle Data Redaction maskiert bestimmte Spalten bei der Abfrageausführung, bevor das Ergebnis an Client oder Anwendung zurückgegeben wird. Die Daten auf der Festplatte bleiben unverändert. Für nicht-produktive Kopien ist das kein Ersatz für dauerhaftes Maskieren, kann aber eine zusätzliche Laufzeitkontrolle für gezielte Lesewege sein.
Policy für eine Spalte definieren
Eine Redaction Policy wird mit DBMS_REDACT an ein Tabellen-, View- oder Materialized-View-Objekt gebunden. Das Beispiel blendet die Gehaltsspalte vollständig aus, sofern die Session nicht von der Policy ausgenommen ist:
BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema => 'HR',
object_name => 'EMPLOYEES',
column_name => 'SALARY',
policy_name => 'REDACT_EMP_SALARY',
function_type => DBMS_REDACT.FULL,
expression => '1=1'
);
END;
/Je nach Datentyp erscheint ein passender Ersatzwert. Für Supportabläufe kann partielle Redaction praktischer sein, wenn beispielsweise nur die letzten Ziffern sichtbar bleiben sollen. Testen Sie die konkrete Darstellung mit den Datentypen, Formaten und Masken Ihrer Anwendung.
In APEX und Reports prüfen
APEX führt SQL unter der Datenbankidentität des Parsing Schemas aus. Eine Policy sieht also nicht automatisch den APEX-Anmeldenamen als Datenbank-SESSION_USER. Wenn unterschiedliche APEX-Benutzer verschieden viel sehen dürfen, muss die Anwendung ihren vertrauenswürdigen Kontext sicher an die Datenbank übergeben und die Policy darauf abgestimmt werden. Ein frei änderbares Page Item oder URL-Parameter ist dafür kein verlässlicher Identitätsnachweis.
Prüfen Sie Interactive Reports, Exporte, LOVs, REST-Endpunkte und Hintergrundprozesse separat. Jede Abfrage sollte unter den tatsächlichen Laufzeitbedingungen getestet werden. Redaction wirkt auf ausgewählte Werte in Ergebnissen; sie filtert keine Zeilen und ersetzt keine Zugriffsrechte, Verschlüsselung oder Auditierung.
Ausnahmen und Sicherheitsgrenzen
Konten mit dem Systemprivileg EXEMPT REDACTION POLICY umgehen Data Redaction; administrative Konten können daher unmaskierte Werte sehen. Prüfen Sie solche Privilegien explizit und betreiben Sie die Anwendung mit möglichst geringen Rechten. Oracle erlaubt nur eine Data Redaction Policy pro Objekt; die Policy kann jedoch mehrere Spalten kontrollieren. Expressions haben außerdem eine eingeschränkte Syntax und dürfen keine benutzerdefinierten Funktionen aufrufen.
- Sensible Spalten und notwendige Anzeigezwecke festlegen.
- Policy für jede App- und Datenbankidentität testen.
- APEX-Seiten, Exporte und REST-Zugriffe in den Testumfang aufnehmen.
EXEMPT REDACTION POLICYund privilegierte Konten prüfen.- Redaction als eine Schicht neben Grants, VPD/RLS, Audit und TDE betreiben.
Data Redaction eignet sich, wenn derselbe Datenbestand je nach berechtigtem Zugriff unterschiedlich dargestellt werden soll. Eine saubere Policy beginnt mit dem Identitätsmodell der Anwendung und endet mit Tests aller Ausgabewege – nicht nur der sichtbaren Formularseite.
Weiterführend: Oracles Dokumentation zu Data Redaction Policies, die Sicherheitsbetrachtungen und die Referenz zu DBMS_REDACT.