Sven’s Technik-Blog

"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...

Tanel Poder beschreibt in seinem Blog-Eintrag "Your read only accounts aren’t that read only", dass Benutzer mit ausschliesslich Select-Rechten Tabellen locken können. Damit besteht die Gefahr, dass diese Benutzer Applikationen komplett lahmlegen können. Tanel liefert auch einen (mühsamen) Workaround.

Durch diesen Bericht bin ich wieder einmal auf die Idee gekommen, zu testen, ob sich im "Readonly-Verhalten" von Oracle etwas geändert hat.
Read the rest of this entry »

Hat ein Benutzer EXECUTE-Rechte auf eines der folgenden Packages, kann er (bis Oracle 10g) Informationen an beliebige Hosts schicken:

• UTL_TCP
• UTL_SMTP
• UTL_MAIL
• UTL_HTTP
• UTL_INADDR

Mit Oracle 11g ist dies nicht mehr der Fall. Per Default hat kein Benutzer (ausser SYS) die Möglichkeit, mit diesen Packages externe Rechner zu erreichen.
Mit dem neuen Package DBMS_NETWORK_ACL_ADMIN können nun Access Control Listen erzeugt werden, mit denen definiert wird, wer an welchen Host Callouts durchführen kann.

Dies hat aber einige Auswirkungen...
Read the rest of this entry »

Mein Kollege Martin hat einen Rolling Upgrade mit dem aktuellen CPU getestet. Das Einspielen des CPU ging ohne Probleme (wenn der bekannte Bug mit Linux 64bit umgangen wird).

Damit aber die Datenbank die gesamte Zeit online zur Verfügung steht, müssen ein paar Sachen beachtet werden. Siehe dazu seinen interessanten Blog-Eintrag.

Ein kurzes Update zu unserem Security Alert:

Oracle informierte uns, dass drei unserer kritischsten Security Holes im Main Code behoben sind. Die Fixes sollen im nächsten CPU (Januar 2008) enthalten sein.
Wir bemühen uns, einen Vorab-Patch zu bekommen für die Kunden, die Database Vault schon produktiv im Einsatz haben.

Andere Probleme sind noch "Under investigation".

Transparent Data Encryption wurde mit Oracle 10.2 eingeführt, hatte dort aber einige Einschränkungen:

• Es konnten nur einzelne Spalten verschlüsselt werden
• Nicht alle Datentypen konnten verschlüsselt werden (Long, LOB)
• Während Operationen waren die Daten nicht verschlüsselt, so dass eventuell unverschlüsselte und vertrauliche Daten im TEMP-Tablespace oder im REDO sichtbar waren
• Ausschliesslich B*Tree Indizes werden unterstützt (keine FBI)
• Index Range Scans werden nur bei Abfragen auf Gleichheit unterstützt
• Fremdschlüssel können nicht auf verschlüsselten Spalten definiert werden

Alle diese Einschränkungen wurden mit Oracle 11g aufgehoben
Read the rest of this entry »

Am 23.10. halte ich zum DOAG-Regionaltreffen in Köln einen Vortrag zum Thema Oracle Audit Vault.

Geplant war eigentlich Database Vault, aber aus bekannten Gründen habe ich diesen Vortrag zurückgezogen.

Wer sich gerade in der Nähe aufhält, ist recht herzlich eingeladen. Die Veranstaltung ist wie immer kostenlos (aber nicht umsonst), anmelden solltet ihr euch hier.

Es ist langsam wieder so weit, am 16. Oktober erscheint das nächste CPU. Das Pre-Release Announcement gibt schon mal einige interessante Informationen:

• 51 Security-Fixes für hunderte Oracle Produkte - wow
• Oracle ändert seine Risiko-Bewertung auf CVSS 2.0 Scoring
• Bereich Datenbank:
  • Der höchste CVSS-Wert ist 6.5 (4.2 für das alte CVSS 1.0 scoring) - entspricht also einem recht hohem Risiko
  • 27 Security-Löcher wurden behoben, davon sind 5 remote ohne Authentisierung ausnutzbar!
• Für OAS ist der höchste CVSS-Wert 6.8 (7.0 für das alte CVSS 1.0 scoring), also ein sehr hoher Wert
• Database Vault ist erwähnt, schauen wir mal, ob unsere gemeldeten Löcher geschlossen wurden...
• Oracle Database 11g hat noch keine Fixes

Wir werden dieses CPU wieder testen und berichten...

Nachdem ich in den Blogs von Markus und Alex zitiert und korrigiert werde, noch eine genauere Darstellung zu dieser Aussage:

"Es sind zu viele Security Lücken vorhanden, die das Lesen und Ändern von vertraulichen Daten als Datenbank- oder Betriebssystemadministrator zulassen"

Natürlich ist mir klar, dass Database Vault allein kaum Schutz vor einem OS-Administrator bietet - und das verkauft Oracle auch nicht so.
Aber Database Vault soll dabei unterstützen. Z.B. ist per Default keine Anmeldung als SYSDBA und (je nach Version und Patchlevel ) keine OS authentication (also ein "connect / as sysdba") mehr möglich, also auch root/oracle müssen sich mit Usernamen und Passwort anmelden.

Dies darf aber nicht als alleiniger Schutz benutzt werden, da der Software-Owner Database Vault ausschalten kann (auch hier gibt es ein paar Security-Holes). Ausserdem kann er die Anmeldung als SYSDBA wieder zulassen. Beides kann aber wiederum auf OS-Ebene überwacht werden.

Auch aus meiner Sicht ist sehr viel Wissen notwendig, um dieses Produkt sicher einzuführen.

In den letzten beiden Wochen haben wir sehr intensiv Oracle Database Vault getestet.

Fazit:
Das Konzept ist gut durchdacht. und es sind einige sehr interessante Ideen implementiert.

Trotzdem müssen wir Stand heute vom Einsatz abraten. Es sind zu viele Security Lücken vorhanden, die das Lesen und Ändern von vertraulichen Daten als Datenbank- oder Betriebssystemadministrator zulassen - genau das aber verspricht dieses Produkt zu unterbinden.

So gelingt es z.B. per dynamischen SQL sehr einfach - in 3 unterschiedlichen Varianten - Zugriff auf per Realm geschützte Daten zu erlangen.

Diverse Servicerequests sind offen, secalert ist ebenfalls informiert, wir sind hier in sehr engem Kontakt mit Oracle.
Wir werden wieder berichten, sobald Database Vault aus unsere Sicht Produktionsreife erlangt hat.