Wir haben das Patchset 10.2.0.4 auf einer Database Vault Datenbank getestet.

Obwohl in der Liste der Bugfixes kein Database Vault Bug erscheint, wurden zwei meiner kritischsten Bugs behoben
Einer ist noch offen - aber dieser ist wesentlich schwieriger (und nur als SYS) auszunutzen.

Da die OS Authentication für SYSDBAs wieder gesperrt ist, kann ich nun den Einsatz von Database Vault mit dem Patchset 10.2.0.4 empfehlen.

Trotzdem braucht es viel Datenbank- und Security-Wissen, um eine sichere Installation zu gewährleisten...

Folgende Oracle-Aussage stimmt definitiv nicht mehr:

Patch sets provide bug fixes only; they do not include new functionality and they do not require certification on the target system.

Wie in diesem Blogeintrag zu sehen ist, gibt es weitere neue Funktionen, worüber sich die "Performance Junkies" freuen werden

Entgegen meinem ersten Artikel (und dem Kommentar meines Kollegen Chris zu diesem Artikel ) ist Real Application Testing doch in 10.2.0.4 verfügbar:

Ein paar Bemerkungen aber dazu:

• Der SQL Performance Analyzer fehlt (jedenfalls das Package DBMS_SQLPA, welches die Funktionalität zur Verfügung stellt)
• Database Replay ist vorhanden, aber nur der Capture-Teil (ok, das haben wir auch so erwartet - und damit kann ich doch das Update von 10.2.0.4 auf 11.x testen)
• Es muss der (neue) Parameter PRE_11G_ENABLE_CAPTURE auf TRUE gesetzt werden, ansonsten kommt folgende Fehlermeldung beim Start des Capture-Prozesses:

  ORA-15591: cannot start capture because parameter "PRE_11G_ENABLE_CAPTURE" is not enabled

• Der Capture-Prozess kann mit Database Control 10.2.0.4 gestartet und verwaltet werden, Preprozess und Replay sind im Menu zwar verfügbar, aber nicht anklickbar:
  
  

Und das Wichtigste: Die gesammelten Daten können problemlos auf einer 11g-Datenbank abgespielt werden !
Also - erfolgreiche Tests!

Der Download (immerhin 1GB!!) läuft im Moment. Im README steht nichts aussergewöhnliches, ausser dass auch Bugs in Database Vault behoben wurden...

Über die Gerüchte, dass "Real Application Testing" nun auch mit 10g gehen soll, habe ich noch nichts gefunden

Nachdem im CPU Januar 2008 unsere gemeldeten Bugs nicht behoben wurden, habe ich heute von Oracle eine neue Antwort bekommen:

Die Bugs sind gefixt in 10.2.0.4 und 11.1.0.7 - und vielleicht auch in einen späteren CPU für ältere Versionen.
Also - warten wir weiter ab...

Wir sind gerade am intensivem Testen des CPUs. Einige Punkte dazu:

• Beim Einspielen des CPU in eine Oracle 10g Datenbank, wird automatisch ohne Abfrage der Oracle Configuration Manager (OCM) installiert:

  OPatch will now install the Oracle Configuration Manager in the Oracle Home.

  Wer dieses Feature nicht kennt: Damit können automatisch Informationen über die Datenbank, Umgebung, Fehler, ... an Oracle Support übermittelt werden...
  Zum Glück passiert dies jetzt nicht automatisch für alle Datenbanken - OCM muss dafür zuerst konfiguriert werden - und dies wird schon noch abgefragt:

  Do you wish to configure OCM at this time? (y/n)

• Für einen bekannten View-Bug müssen alle Views neu kompiliert werden (abhängig von der Oracle Version).
  Da dies einige Zeit braucht, gibt Oracle eine Reihe von Emfehlungen, wann es nicht notwendig ist. Z.B. ist es für Oracle 9.2.0.8 nicht notwendig, wenn (Zitat:) "Databases created with Release 11.1.0.6 or later" ...???...
• In diesem CPU wurde keiner der von uns gemeldeten Database Vault-Bugs behoben
  Unsere Empfehlung bleiben also leider bestehen

Es ist wieder so weit: Die Vorbereitungen für das CPU können starten.

Die ersten Informationen von Oracle sind hier verfügbar.

Ein paar Details dazu:

• Dies ist das erste CPU, welches auch Fixes für Oracle 11g beinhaltet
• Für Oracle 10g Database Vault finde ich keine Informationen, also scheinen unsere Security-Findings nicht behoben zu sein
• Für die Oracle Datenbank gibt es 8 neue Security Fixes, von denen keiner remote ohne Authentication ausnutzbar ist
  Mit einem CVSS-Score von 6.5 ist das Risiko aber sehr hoch
• Für den Application Server gibt es 6 neue Security Fixes.
  Mit einem CVSS-Score von 9.3 für Clients und 6.8 für Server ist das Risiko hier sehr hoch

Probleme können Anwender von Oracle-Versionen bekommen, die nicht das aktuelle Patchset einsetzen. So wird z.B. für Oracle Database 10.2.0.2 für Windows und Solaris kein Patch erscheinen oder dieser speziell angefordert werden müssen.
Siehe dazu das Kapitel "Planned Patches for Next CPU Release" im README des Oktober-CPUs.

Wie immer - wir werden das CPU testen und darüber berichten.

Ausser angepassten Passwort-Profilen (siehe diesen Artikel) gehören noch weitere Änderungen am Default-Verhalten zu Oracles Initiative "Secure by Default".

So ist jetzt standardmässig Auditing eingeschaltet für folgende Operationen (Auszug aus der Oracle-Dokumentation):

Auch diese Massnahme ist aus Security-Sicht gut.

Aber für viele Firmen ist Auditing in der Datenbank etwas neues - etwas mit dem sie sich deshalb nicht beschäftigen wollen.
Read the rest of this entry »

Neben der Vorstellung der zwei Komponenten "Database Replay" und "SQL Performance Analyzer" in meinem Blog habe ich dazu auch noch einen etwas ausführlicheren Artikel geschrieben.

Download: www.trivadis.com -> Know-how-Center -> Publikationen
Oder direkt hier.

"Secure by Default" nennt Oracle eine neue Initiative, durch die Oracle Database 11g out-of-the-box sicherer ist als eine vergleichbare 10g-Installation.

Dazu gehört u.a. auch "Fine-Grained Access für Netzwerk-Callouts", worüber ich hier schon berichtete.

Ausserdem wird beim Anlegen der Datenbank mit dem DBCA abgefragt, ob die "Enhanced default security settings" eingeschaltet werden sollen:

Wird diese Frage mit "Keep" beantwortet, wird das Default-Profile angepasst und der Wert PASSWORD_LIFE_TIME auf 180 (Tage) gesetzt. Das bedeutet, dass alle Benutzer nach 180 Tagen ihr Passwort ändern müssen.
Aus Security-Sicht ist das sicherlich gut (der Wert sollte eventuell sogar kleiner sein). Aber was machen dann alle Batchprogramme, Scripts, Programme mit fest kodierten Passwörtern (Application Server), ...? Abstürzen
Ich jedenfalls habe noch kein Programm gesehen, was in der Lage war, die Aufforderung zu erkennen und das Passwort selbständig zu ändern.

Deswegen - daran denken:
Vor dem Ablauf der 180 Tage ein spezielles Profile anlegen, im diesem PASSWORD_LIFE_TIME auf UNLIMITED setzen und (nur) den Benutzern zuteilen, die ihr Passwort nicht ändern können/sollen.

Übrigens, auch wenn Sie Ihre DB mit eigenen Scripts angelegen, gilt dieses Verhalten. Durch catproc.sql wird nämlich neu das Script secconf.sql ausgeführt...