Passwort Management

Das erweiterte Passwort Management wurde in Oracle 8 eingeführt. Es bedient die immer lauteren Forderungen nach einem besseren Schutz vor internen und externen Attacken.

Im Einzelnen deckt es folgende Themen ab:

• Account Locking (automatisch und manuell)
• Password Expiration
• Password History
• Password Complexity

Das mitgelieferte Skript utlpwdmg wurde erweitert und liefert jetzt zusätzlich die Funktion VERIFY_FUNCTION_11G, in der auch die Anforderungen an die Komplexität des Passwortes stark erhöht wurden. Wir empfehlen allerdings nach wie vor das Erstellen einer eigenen Funktion, die die Anforderungen des jeweiligen Unternehmens individuell erfüllt.

Passwörter können jetzt case-sensitiv erstellt werden. Über den dynamischen Parameter sec_case_sensitive_logon lässt sich diese Funktionalität zu- und abschalten. Hiermit hat Oracle sich jetzt an die unter Unix-Systemen übliche Notation anpasst. Grundsätzlich gilt die Nutzung case-sensitiver Passwörter auch bei entfernten Anmeldungen über SYSDBA. Allerdings kann die Wirkungsweise hier über die Definition des Password Files mit dem Befehl orapwd file=orapwora1 ignorecase=Y verändert werden.

In der View DBA_USERS ist das Passwort jetzt auch nicht mehr in HEX-Darstellung sichtbar. Die hexadezimale Darstellung war immer problematisch, da hierüber unter fremden Benutzerkennungen manipiliert werden konnte.

In welcher Oracle-Version das Passwort erstellt wurde, zeigt die zusätzliche Spalte PASSWORD_VERSIONS in der View DBA_USERS an.

Die neue View DBA_USERS_WITH_DEFPWD zeigt die Benutzer mit Standardpasswörtern an. In allen Security-Projekten, die ORDIX in den letzten Jahren betreute, tauchte die Frage nach dem Auffinden von Standardkennwörtern als eine der ersten auf. Mit der neuen View trägt Oracle dieser Fragestellung Rechnung.

sec_case_sensitive_logon Hier wird gesteuert, ob Passwörter case-sensitiv eingegeben werden können; der Default steht auf TRUE. sec_max_failed_login_attempts Hierüber wird gesteuert, wie viele Versuche ein Anwender zur Anmeldung maximal hat. Im Gegensatz zum failed_login_attempts in der Profile wird hier nicht der account gesperrt, sondern die Verbindung abgebrochen. sec_protocol_error_further_action Definition der Reaktion (Continue/Delay/Drop), wenn korrupte Pakete von einem gefahrbringenden Client kommen. sec_protocol_error_trace_action Definition der Trace-Aktion (None/Trace/Log/Alert), wenn korrupte Pakete von einem gefahrbringenden Client kommen. sec_return_server_release_banner Komplette oder minimale Ausgabe der Software-Infos zum Client. Abb. 1: Standardmäßig gesetzte Security Settings in Oracle 11g.

Abb 2: Schematischer Überblick über die transparente Verschlüsselung (Transparent Data Encryption).

create tablespace encrypt_ts datafile '/oracle11/oradata/kr/encrypt_ts01.dbf' size 50m encryption using 'aes256' default storage (encrypt); Abb. 3: Anlegen eines verschlüsselten Tablespaces.

Security Settings

In Oracle 11g sind einige neue Security-Einstellungen per Default eingestellt (siehe Abbildung 1).

Auditing

Die Aktionen von Anwendern lassen sich über das Auditing protokollieren. Unter Oracle 11g hat sich der Default des Standard-Auditings verändert. Der Parameter AUDIT_TRAIL steht jetzt auf DB statt auf NONE.

Außerdem werden jetzt viele Aktionen zwangsweise per Standard-Auditing in die AUD$ protokolliert. Hierzu zählen Aktionen, die z. B. unter Nutzung eines der folgenden Privilegien gemacht wurden:

• Alter / Drop profile
• Create / Alter / Drop any procedure
• Alter database
• Create public database link
• Create / Alter / Drop any table
• Create / Alter / Drop user

Man muss unbedingt darauf achten, die Tabelle AUD$ zu administrieren (d. h. manuelles Löschen), sonst wird die Tabelle immer größer. Ohne Administration kann es je nach Konfiguration zum Stillstand der Instanz führen. Die Tabelle sollte in ein dediziertes Tablespace gelegt werden und die entstandenen Daten sollten regelmäßig verarbeitet werden.

Verschlüsselung

Die transparente Verschlüsselung wurde in Oracle 10g eingeführt (siehe Abbildung 2). Für jede Spalte kann einzeln definiert werden, ob sie verschlüsselt werden soll oder nicht. Über einen Master Key, der in einem Wallet außerhalb der Datenbank hinterlegt ist, wird dann die Ent- und Verschlüsselung vorgenommen.

Seit Oracle 11g sind folgende zusätzliche Erweiterungen implementiert:

• Support für Log Miner und Logical Data Guard
• Support für Oracle Streams
• Tablespace-Verschlüsselung
• Verschlüsselung von LOBs

Besonders interessant ist die Möglichkeit der kompletten Verschlüsselung von Tablespaces. Das geschieht beim Anlegen des Tablespaces (siehe Abbildung 3) und kann dann im Nachhinein nicht mehr modifiziert werden.

Mögliche Verschlüsselungsalgorithmen sind:

• 3DES168
• AES128 (Default)
• AES192
• AES256

Die Daten aus diesen Tablespaces sind während der gesamten Verarbeitungsschritte verschlüsselt, also auch beim Zwischenlagern im Temporary Tablespace. Über verschlüsselte Tablespaces gibt die neue Spalte ENCRYPTED aus DBA_TABLESPACES ebenso Aufschluss, wie die neue View V$ENCRYPTED_TABLESPACES.

Folgende Einschränkungen sind zu beachten:

• Temporary Tablespaces können nicht verschlüsselt werden.
• UNDO Tablespaces sind nicht verschlüsselbar.
• Verschlüsselte Tablespaces sind nicht über TSPITR auf andere Plattformen migrierbar.
• Der Verschlüsselungsalgorithmus ist nicht änderbar und somit auch nicht abschaltbar.

Fazit

Oracle ist den bereits in den letzten Versionen eingeschlagenen Weg zu mehr Sicherheit konsequent weitergegangen. Die neuen Funktionalitäten in 11g belegen, dass Security in Oracle Datenbanken eine wachsende Rolle spielt. In einer der kommenden Ausgaben setzen wir unsere Oracle 11g Reihe mit dem Thema "Result Cache in Oracle 11g" fort.