Oracle Security Reporting Tool – DBSAT

Da ich selbst schon länger nichts mehr hier veröffentlicht habe, reproduziere ich doch einfach mal einen Artikel meines Kollegen Simon Hahn. ;-)

The Cattle Crew Blog

Hallo Community,

aus gegebenen Anlass möchte ich ein paar Worte über Oracle DBSAT – Database Security Assessment Tool verlieren. Ein kleines, kostenloses aber sehr mächtiges Security Reporting Tool für Oracle Datenbanken.

Wir hatten die Möglichkeit das Tool auf der Inspire IT in Frankfurt einigen Kunden vorzustellen.
Sowohl die Verprobung des Tools an sich wie auch die Veranstaltung hat uns sehr viel Spaß bereitet.

Grundsätzlich ist das nichts Neues – Security und Datenschutz sind wichtig und auch teuer, sollten dennoch immer im Unternehmen gelebt werden. Spätestens dann, wenn Firmendaten im Internet für jeden ungewollt einsehbar sind, wurde etwas gänzlich falsch gemacht und nicht selten wird das Unternehmen einen riesigen Imageschaden über Jahre hinweg davontragen.

–> Security und Datenschutz nicht ernst zu nehmen, kann demnach sehr, sehr nachhaltig und gnadenlos sein. Daher lieber vorsorgen. :-)

Im Zuge der neuen EU-weiten Datenschutzverordnungen (GDPR und DSGVO) zum Stichtag 25.5.2018 sollten Datenbanken entsprechend vielleicht doch…

Ursprünglichen Post anzeigen 661 weitere Wörter

Werbeanzeigen

Windows Large Pages

Vor einiger Zeit hatte ich hier über Linux HugePages geschrieben. Die sind ja mittlerweile kein Geheimtipp mehr, und ab Oracle 12.2 lässt sich mit dem DBCA sogar eine Datenbank bei einem RAM > 4GB nur noch mit HugePages anlegen (oder es erscheint die Fehlermeldung „[DBT-11211]“).

(Quelle: Wikimedia Commons)

Etwas anders scheint es nach meinem Eindruck um die Windows Large Pages bestellt zu sein. Da Oracle jedoch ab 4 GB SGA empfiehlt, auch unter Windows die größeren Speicherseiten zu nutzen, möchte ich hier eine kurze Einführung dazu schreiben.

Linux Huge Pages: Schnellstart

If you’re not using HugePages, you’re doing it wrong!  (Mark J. Bobak)

Sie haben eine SGA von mehreren GB Größe, dazu mehrere Hundert Sessions auf der Datenbank? Ihr DB-Server läuft unter Linux, aber ohne Einsatz von HugePages? Dann verschenken Sie RAM und CPU-Leistung, und zwar nicht zu knapp!

Über Linux HugePages wurde schon viel geschrieben (s. Literaturliste unten), jedoch hauptsächlich auf Englisch und meist sehr ausgedehnt. Dieser Artikel soll die wichtigsten Fakten und Maßnahmen in Kürze aufzeigen.

Szenario

Ein Praxisbeispiel vorweg: Eine Data Warehouse-DB mit 20 GB SGA und etwa 300 Sessions läuft auf einem Server mit 32 GB RAM. Gelegentlich gerät der Server unter höhere Last und fängt daraufhin an, massiv zu swappen; die Performance geht in die Knie. Was ist passiert?

SYSDATE in SQL und PL/SQL

Heute fühle ich mich genötigt, ein Thema anzusprechen, das zwar ein Grundlagenthema ist, das aber immer wieder gerne in Vergessenheit gerät. ;-)

Anlass ist ein Fund in einer Produktionsumgebung, in der eine Überlastung der CPU bei sehr hoher Anzahl an SQL-Ausführungen zu beobachten war. Die Umgebung basiert sehr stark auf PL/SQL, wobei häufig verwendete SQL-Abfragen gerne in einer Function gekapselt und dann aus SQL heraus aufgerufen werden.

PL/SQL Injection in Oracle 12c

David Litchfield, der bereits andere Injection-Lücken in Oracle gefunden hatte (s. meine anderen Artikel der Kategorie „Sicherheit“), hat wieder zugeschlagen und eine Injection-Methode unter 12c aufgedeckt:
http://www.davidlitchfield.com/Exploiting_PLSQL_Injection_on_Oracle_12c.pdf

Sehr kurze Zusammenfassung des Dokuments:

• Ein User mit Execute-Recht auf DBMS_SQL und DBMS_JAVA_TEST kann damit SQL Injections durchführen.
• Der Entzug von Execute auf DBMS_JAVA_TEST und DBMS_JAVA wirkt dem entgegen.
• Wenn Java in der DB nicht benötigt wird, sollten diese Packages gleich ganz deinstalliert werden, um die Angriffsfläche zu verringern.

Oracle 12c / Java7: setEndToEndMetrics() deprecated

Dies ist eine kurze Aktualisierung zu meinem früheren Artikel „DBMS_SESSION: Anwender und Sessions mehrschichtiger Anwendungen in der DB identifizieren„, der sich auf Oracle 11.2 nebst der damals unterstützten JDBC-Version bezog.

Die Oracle 12c JDBC-Treiber unterstützen JDBC 4.1 über das JDK 7 und damit auch die JDBC DMS Metrics, wenn entsprechende Treiber-Packages (z.B. ojdbc7dms.jar) verwendet werden. Die in meinem damaligen Beispiel verwendete Methode setEndToEndMetrics schließt allerdings die wechselseitige Verwendung mit DMS-Methoden aus. Daher empfiehlt es sich auf die neue Methode setClientInfo umzustellen. Ein Codefragment mit der neuen Methode kann dann so aussehen:

...
Connection conn = DriverManager.getConnection(myUrl, myUsername, myPassword);
conn.setClientInfo("E2E_CONTEXT.DBOP", "MeinTag");
Statement stmt = conn.createStatement();
// DBOP-Tag wird mit dem naechsten DB-Aufruf gesetzt:
stmt.execute("select 1 from dual");
...

Dem Nachteil, dass schon wieder eine andere Methode als bisher verwendet werden soll, steht der Vorteil gegenüber, dass man sich mit DMS Metrics in einem standardisierten Umfeld bewegt und auch nicht mehr zwingend eine OracleConnection verwenden muss; eine einfache Connection reicht aus.

Neues vom Clustering Factor

Richard Foote (der „Index-Guru“) hat auf seinem Blog in mittlerweile drei Artikeln Neues zur Berechnung des Clustering Factors (CF) verkündet:

1. Erster Artikel: Ein Patch für Oracle 11.2 führt eine neue Option „TABLE_CACHED_BLOCKS“ für die Berechnung mit DBMS_STATS ein. Dieser kann von 0-255 oder auf AUTO gesetzt werden und sorgt für eine Berücksichtigung von Caching-Effekten, die bislang nicht in die Berechnung des Clustering Factors eingegangen sind. Dadurch können unberechtigt zu hohe CFs deutlich reduziert werden, wenn die indizierten Rows innerhalb der nächsten n Blöcke der Zieltabelle liegen. n wird bei AUTO auf 1% der Tabellengröße in Blöcken gesetzt.
2. Im zweiten Artikel geht Richard Foote auf Bedenken aus den Kommentaren zu Teil 1 ein, speziell die Bedenken, daß der CF nunmehr zu niedrig werden könnte. Ein ausführlicher Testfall mit einer großen Tabelle zeigt, daß hier selbst das Maximum von TABLE_CACHED_BLOCKS=255 keine gravierende Änderung zur Folge hat.
3. Im dritten Artikel wird als Gegenbeispiel die maximale Einstellung auf eine kleine Tabelle angewendet und dargestellt, dass in solchen Fällen ein hoher Wert für TABLE_CACHED_BLOCKS, der nahe an der Anzahl an Datenblöcken der Tabelle liegt, kontraproduktiv sein kann.

Eine „Best Practice“ wird sich wohl erst noch herauskristallisieren müssen. Meine persönliche Vermutung anhand der bislang diskutierten Testfälle geht dahin:

• TABLE_CACHED_BLOCKS = AUTO als DB-weite Einstellung
• Wo es dann immer noch Probleme mit einem zu hohen CF gibt, Objekt-spezifische Einstellung dieser Option.