Ein Datenbankkonto, das nur die Statements seiner Anwendung ausführen soll, ist ein guter Kandidat für eine Allow-List. Oracle SQL Firewall unterstützt diesen Ansatz in Oracle AI Database 26ai: Für ein Konto werden erwartete SQL-Statements und vertrauenswürdige Verbindungskontexte erfasst. Unerwartete SQL- oder Verbindungsdaten können anschließend protokolliert oder blockiert werden.
1. Den richtigen Benutzer auswählen
Starten Sie mit einem klar abgegrenzten Anwendungskonto statt mit einem Sammelbenutzer. Je eindeutiger der Benutzer einer Anwendung oder Schnittstelle zugeordnet ist, desto belastbarer wird die Baseline. Beziehen Sie auch geplante Jobs, Reporting-Zugriffe und Wartungsfenster ein, wenn diese denselben Account verwenden.
SQL Firewall arbeitet auf Ebene des Datenbankkontos. Als zusätzlicher Kontext können unter anderem IP-Adresse, Betriebssystembenutzer und Programmname dienen. So lässt sich neben dem „Was“ auch das „Von wo“ kontrollieren.
2. Normalen Workload aufnehmen
Ein DBA aktiviert SQL Firewall, startet für den Benutzer eine Capture-Phase und lässt die Anwendung unter realistischen Bedingungen laufen. Dazu gehören typische Geschäftsprozesse, Fehlerpfade, Batchläufe und Deployments. Die Capture-Logs sollten anschließend auf Vollständigkeit und unerwartete Zugriffe geprüft werden.
SELECT sql_text
FROM dba_sql_firewall_capture_logs
WHERE username = 'APP';Die Aufnahme ist kein automatischer Freifahrtschein. Ein Statement, das während der Capture-Phase durch ein kompromittiertes Konto ausgeführt wurde, würde sonst wie normales Verhalten aussehen. Deshalb gehören Zeitraum, Testfälle und verantwortliche Freigabe zur Baseline.
3. Allow-List erzeugen und zunächst beobachten
Nach der Prüfung wird aus den Capture-Logs eine Allow-List erzeugt. In einer ersten Betriebsphase empfiehlt sich ein beobachtender Modus: Verstöße werden protokolliert, aber noch zugelassen. So erkennen Sie vergessene Statements, neue Release-Schritte oder zusätzliche vertrauenswürdige Verbindungswege, ohne die Anwendung sofort zu unterbrechen.
BEGIN
DBMS_SQL_FIREWALL.GENERATE_ALLOW_LIST('APP');
END;
/Kontrollieren Sie anschließend die erlaubten SQL-Statements und Kontexte über die SQL-Firewall-Data-Dictionary-Views. Ergänzungen sollten gezielt erfolgen, nicht durch pauschales Übernehmen sämtlicher Violation-Logs.
4. Enforcement in den Betrieb überführen
Erst wenn die Beobachtungsphase stabil ist, wird die Policy durchgesetzt. SQL Firewall kann SQL-Statements, Session-Kontexte oder beides prüfen. Für die erste Aktivierung ist ein abgestimmtes Wartungsfenster sinnvoll. Überwachen Sie danach die Violation-Logs und halten Sie einen Rückweg bereit, falls ein legitimer Prozess noch nicht erfasst wurde.
BEGIN
DBMS_SQL_FIREWALL.ENABLE_ALLOW_LIST(
username => 'APP',
enforce => DBMS_SQL_FIREWALL.ENFORCE_SQL,
block => TRUE
);
END;
/5. Betrieb, Releases und Data Guard
Eine Anwendungspatch kann neue SQL-Statements einführen. Planen Sie deshalb Capture- und Review-Schritte in den Release-Prozess ein. Allow-Lists lassen sich exportieren und importieren; das ist für kontrollierte Umgebungsübergänge hilfreich. In Data-Guard-, RAC- und Multitenant-Umgebungen müssen Sie zusätzlich klären, wo Policy und Logs verwaltet und geprüft werden.
Fazit
SQL Firewall ergänzt klassische Datenbankkontrollen um eine präzise Erwartung an SQL und Verbindungsweg. Der Wert entsteht durch eine gute Baseline, eine echte Beobachtungsphase und einen bewusst geplanten Enforcement-Schritt. So wird aus einer pauschalen Berechtigung ein überprüfbarer, anwendungsnaher Schutz gegen unerwartete Statements und missbrauchte Zugangsdaten.
Weiterführend: Oracle SQL Firewall Überblick und die Getting-Started-Anleitung.