In vielen Unternehmen arbeiten die DBAs – und nicht nur die – mit dem User „SYSTEM„. Ist das falsch? Nicht unbedingt, es sei denn, Sie wollen überprüfen können, wer welche Änderungen gemacht hat. Auditing ist hier das Argument. Und die DSGVO trägt sicherlich auch dazu bei, sich einmal zu überlegen, ob es hilfreich ist, Build-In User oder andere Security-relevante Build-In Objekte zu verwenden.
Was darf der User SYSTEM?
Mit dieser Frage fängt es schon an: Sie verwenden einen Account, von dem Sie gar nicht genau wissen, was der eigentlich darf?! Schauen wir uns das in einem Tool wie Toad ein, dann sieht das doch ganz einfach aus: SYSTEM hat die Rollen DBA und AQ_ADMINISTRATOR_ROLE.
Aber wenn man sich das dann einmal detailliert ansieht, stellt man fest, dass die Rolle DBA 393 (Oracle 19c) Systemprivilegien hat, viele davon mehrfach durch weitere Rollen. Ich glaube nicht, dass noch jemand nachvollziehen kann, ob die alle okay sind.
Daher ist die erste Bitte: verwenden Sie keine Build-In User sondern benutzen Sie ihre eigenen. Und sperren Sie am Besten den SYSTEM Account. Es gibt keinen Grund, ihn zu verwenden. In der Oracle Dokumentation heißt es dazu: „For production systems, Oracle recommends creating individual database administrator accounts and not using the generic SYSTEM account for database administration operations.“ (Quelle: Database 2 Day + Security Guide Version 11.1).
Standardrollen DBA, RESOURCE, CONNECT
Damit sind wir schon beim zweiten Thema: Die Rollen DBA, RESOURCE, CONNECT sind Relikte aus grauer (Oracle 6) Vorzeit. In der Oracle Dokumentation heißt es dazu: „The first three roles in Table 11-1 namely, CONNECT, RESOURCE, and DBA, are provided to maintain compatibility with previous versions of Oracle and may not be created automatically in future versions of Oracle. Oracle recommends that you design your own roles for database security, rather than relying on these roles.Y“ (das Zitat stammt aus dem Oracle Security Guide Version 10.2!).
Daher ist die zweite Bitte: verwenden Sie nicht die RollenDBA, RESOURCE, CONNECT. Vielleicht haben Sie ja schon bei Oracle 12.1 die Erfahrung gemacht, dass das Privileg UNLIMITED TABLESPACE nicht mehr in der Resoure Rolle enthalten war. Ähnlich könnte es Ihnen in Zukunft mit der DBA Rolle gehen.
Default Profile
Kommen wir zum dritten Teil der Geschichte: Jeder User hat ein Profil(e). Und ähnlich wie bei Usern und Rollen gibt es auch hier Build-In Objekte und dabei vor allem das Profile DEFAULT. Und genau so wie bei Usern und Rollen ist das ein Beispiel, dass Sie gerne nutzen können, um ihre eigenen Profiles zu erstellen – mehr aber nicht. Auch hier gibt es ein schönes Beispiel aus der jüngeren Vergangenheit. Mit Version 12.1 wurde das LIMIT für den Parameter PROFILE_LIFE_TIME von UNLIMITED auf 180 Tage geändert.
Ich habe einige Anrufe von Anwendern bzw. DBAs bekommen, dass die Anwendung nicht mehr funktioniert weil die User sich nicht mehr anmelden können. Auf die Nachfrage, wann sie den Upgrade auf 12.1 gemacht hätten, war die Antwort stets „vor ca. 6 Monaten“ ….
Daher die dritte Bitte: Verwenden Sie ausschließlich eigene Profiles!
Password Complexity Check
Und jetzt der letzte Punkt – und hier bin ich selbst ziemlich auf die Nase gefallen. Oracle bietet seit einigen Versionen PL/SQL Prozeduren und Funktionen für die Einhaltung von Password-Richtlinien an, die man dann in den Profiles als Limit PASSWORD_VERIFY_FUNCTION einbauen kann.
Bitte machen Sie das nicht für das DEFAULT Profile, weil es ansonsten Probleme geben kann, wenn Sie Datenbank Optionen, z.B. Spatial nachträglich installieren wollen. Es kommt schon einmal vor, dass das Passwort vordefiniert ist und damit die Installation mit einer zu komplexen Passwort Richtlinie fehlschlägt.
Jetzt zum Problem: Mit dem Skript <ORACLE_HOME>/rdbms/catpvf.sql erhalten Sie die Möglichkeit, Vorgaben für die Passwort-Komplexitätsprüfung zu machen. Die Prozeduren sind gut beschrieben und können einfach in die Profiles eingebaut werden.
Hier ein Beispiel:
CREATE OR REPLACE FUNCTION carajan_pwd_verify
(username varchar2,
password varchar2,
old_password varchar2)
RETURN boolean IS
differ integer;
pw_lower varchar2(256);
db_name varchar2(40);
i integer;
simple_password varchar2(10);
reverse_user varchar2(32);
BEGIN
IF NOT ora_complexity_check(
password, chars => 10, letter => 1, upper => 1,
lower => 1, digit => 1) THEN
RETURN(FALSE);
END IF;
...
Damit wird unter anderem geprüft, ob das Passwort mindestens 10 Zeichen lang ist, sowie einen Groß-, einen Kleinbuchstaben und eine Zahl enthält. Soweit so gut.
Leider hat Oracle in der Version 18 die Prozedur ora_complexity_check, die hierfür die Grundlage bildet, geändert. Die Parameter upper und lower wurden aus unerfindlichen Gründen durch uppercase und lowercase ersetzt.
Das führt natürlich dazu, dass die Funktion carajan_pwd_verify „invalid“ wird und die Benutzer ihre Passworte nicht mehr ändern können. Das ist ziemlich ärgerlich und bedeutet, dass man jedes Mal prüfen muss, welches Release man gerade einsetzt um dann die „richtige“ Funktionswerte zu übergeben.
Daher hier die vierte und letzte Bitte: schreiben Sie ihre eigene Complexitycheck Prozedur. Nehmen Sie die von Oracle gelieferte und bauen daraus ihre eigene. Das ist sicherer und hat den Vorteil, dass diese auch nach einem Upgrade auf Oracle 21 oder später noch funktioniert.
Übrigens: In diesem Fall habe ich keine Dokumentation von Oracle gefunden, die besagt, dass das Skript catpvf.sql nur ein Beispiel ist und nicht benutzt werden sollte. Noch gab es einen Hinweis in der Dokumentation, dass die Funktionen sich geändert hätten.