Sven’s Technik-Blog

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

Nach der Migration einer 10g-Datenbank nach 11g wurden bei mir auf einmal (ohne Parameteränderung) die Archivelogs gespiegelt.
log_archive_dest_n ist nicht gesetzt, damit wird (richtig) in db_recovery_file_dest (also in die Flash Recovery Area - FRA) archiviert - aber zusätzlich auch noch in $ORACLE_HOME/dbs!!

Im alert.log steht's:

Using LOG_ARCHIVE_DEST_1 parameter default value as /u00/app/oracle/product/11.1.0/dbs/arch
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST

Ist das nun Absicht? In der Dokumentation haben wir jedenfalls nichts darüber gefunden.

Zwei Tipps kamen von meinen Kollegen:

• Entweder Destination1 wirklich auf FRA setzen:

  ALTER SYSTEM SET log_archive_dest_1 = 'location=USE_DB_RECOVERY_FILE_DEST';
   

• Oder aber Destination1 ausschalten, indem ein Whitspace eingetragen wird (in der Doku wird dies ein Null-String genannt):

  ALTER SYSTEM SET log_archive_dest_1=' ';
   

Sollte man unbedingt beachten, damit nicht sehr schnell das ORACLE_HOME voll läuft...