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.
Da es keinen Automatismus für das Löschen der Audit-Tablelle (aud$) gibt, wird dies dann aber schnell zum Problem, denn die Tabelle wächst und wächst…
Also – wichtiger Punkt 1:
Auditing-Informationen auswerten, eventuell sichern – und erst danach Tabelle leeren.
Ausserdem empfiehlt sich, die eingeschalteten Optionen an den eigenen Verwendungszweck anzupassen.
Nicht immer sind alle sinnvoll – und sicherlich fehlen manchmal welche.
Z.B. wird “create session” protokolliert, auch “whenever successful”. Vom Prinzip her sicherlich richtig (um nachzuweisen, wer wann angemeldet war). Ich kenne aber (Web-) Applikationen, wo jeder Seitenaufbau einen Connect zur Datenbank macht (ich will jetzt nicht über die Art der Programmierung diskutieren…). Dadurch würde die Auditing-Tabelle schnell riesengross – und damit potentiell auch noch zum Performance-Problem.
Also – wichtiger Punkt 2:
Audit-Optionen kontrollieren und an die eigenen Bedürfnisse (Regularien??) anpassen.
Dann sollte dem Auditing nichts mehr im Wege stehen 
