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 »

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

Mit dem in Oracle 10g eingeführten Scheduler (der in der Datenbank, implementiert mit dem Package dbms_scheduler) ist es leicht möglich, externe Programme (z.B. OS-Scripts) zu starten. Innerhalb der Datenbank konnte aber nicht gesteuert werden, unter welchem Betriebssystembenutzer die Programme laufen. Dies konnte nur über eine Datei pro ORACLE_HOME gesteuert werden (siehe Metalink Note 391820.1) - d.h. alle externen Programme liefen immer unter dem gleichen Account.

Auch wenn es nicht im New Features Dokument steht - über das neue Objekt CREDENTIAL ist es nun in Oracle 11g einfach möglich, jedem Job (bei Bedarf) andere Usernamen/Passwort-Kombinationen zuzuweisen.
Read the rest of this entry »

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