Audit- und Paßwort-Funktionen im GTDS

Audit- und Paßwort-Funktionen im GTDS
Audit-Funktionen im GTDS
Im Prinzip geht es dabei um Protokollierung verschiedener, insbesondere für die Sicherheit
relevanter Aktionen. Intern verfügt GTDS bereits über solche Protokolle, die über
Benutzer, Rechte … verfügbar sind :
Das Masken – Log protokolliert im klassischen GTDS Maskenzugriffe im Kontext der Patienten, so
dass Zugriffe auf einzelne Patienten nachvollziehbar sind. Die Details und die Konfiguration sind
in der Hilfe beschrieben (http://www.med.uni-giessen.de/akkk/gtds/grafisch/doku/gtds_log.htm).
Diese Funktion ist seit dem Jahr 2001 verfügbar und seit 2011 auch für WebGTDS wirksam sofern
der GTDS – Parameter GLOBAL.GTDSLOG den Wert Ja hat.
Die Knopf „Web-GTDS“ ermöglicht die Sicht auf Anmeldeinformation, Länge der Sitzungen und
den letzten Sitzungskontext im WebGTDS
In manchen Fällen ist es möglich, daß diese Protokolle nach einer gewissen Zeit gelöscht werden
müssen. Dazu stehen auf Anfrage spezielle SQL-Pakete zur automatisierten, fristgerechten
Löschung zur Verfügung.
Audit-Funktionen der Datenbank verwenden
Manche Aktionen werden von den GTDS – Protokollen bisher nicht erfaßt, z.B. Login und Logout
in Bezug auf die Datenbank. Hier ist es am einfachsten, die Audit-Funktionen von Oracle zu
verwenden. Dafür sind folgende Schritte erforderlich :
Datenbank für Audit-Funktionen konfigurieren
Im Auslieferungszustand ist diese Funktionalität normalerweise deaktiviert. Sie muß nur einmalig
eingeschaltet werden. Dazu ist ein Neustart der Datenbank erforderlich.Die Aktion zur Aktivierung
von Audit hängt von der Version ab (bei Detailfragen im konkreten Falle beraten wir gern) :
•
bei Oracle 9 oder früher muß in der Datei INITGTDS.ORA o.ä. im Verzeichnis
%ORACLE_HOME%/DBS bzw. %ORACLE_HOME%/Database die Zeile
audit_trail=DB
angefügt bzw. unkommentiert werden.
•
bei den meist jetzt mit GTDS verwendeten Versionen 10 oder 11 von Oracle ist ein SQLStatement auszuführen (geht evtl. auch als OPS$TUMSYS), wie es in der Datei
Audit_Trail.sql abgelegt ist :
alter System Set Audit_Trail = DB scope = SPFILE ;
In beiden Fällen ist die Änderung zunächst nicht wirksam. Erst wenn die Datenbank
heruntergefahren und neu gestartet wird, ist anschließend Audit eingeschaltet.
Zunächst sind danach jedoch keinerlei Audit-Funktionen aktiv. Lediglich ist die Datenbank bereit,
solche Funktionen tatsächlich auszuführen. Anderenfalls würden AUDIT … - Statements zwar ohne
Fehler angenommen, es geschieht jedoch nichts.
Den Status des Datenbank-Parameters Audit_Trail können Sie in SQLPLUS als
OPS$TUMSYS anzeigen mit
SHOW PARAMETERS
AUDIT
Einzelne Audit-Funktionen beauftragen
Nach dieser einmaligen Vorbereitung können einzelne Audit-Funktionen mit SQL aktiviert bzw.
deaktiviert werden. Die ganzen Details enthält die originale Dokumentation von Oracle, die u.a.
auch im Internet verfügbar ist ( Configuring and Administering Auditing
http://docs.oracle.com/cd/B19306_01/network.102/b14266/cfgaudit.htm ) . Für GTDS reicht als
erster Schritt aus, Audit für Login und Logoff zur Datenbank zu aktivieren. Um dies für einen
bestimmten Benutzer zu tun, genügt das SQL-Statement (wie in Audit.sql )
Audit CONNECT By
BenutzerName ;
Statt BenutzerName wird natürlich ein Benutzer aus GTDS eingesetzt.
Soll dies für alle GTDS – Benutzer geschehen kann ein Skript wie Start_Audit.sql
eingesetzt werden, welches als OPS$TUMSYS ausgeführt ein neues Skript namens
Audit_Benutzer.sql generiert, welches wiederum diese Funktion für alle gewünschten
Benutzer einschaltet.
Audit – Protokolle anschauen
Oracle speichert diese Protokolle in internen Tabellen, deren Inhalte über Views mit SQL abgerufen
werden können. Für GTDS steht ein fertiges SQLPLUS – Skript zur Verfügung mit dem Namen
Sel_Aud.sql . Es wird gestartet in der Form
SQL> @Sel_Aud
Benutzer
AnzahlTage
Sollen also alle Datenbank – Verbindungen des Benutzers PC03 in den letzten 30 Tagen aufgelistet
werden, ginge das so :
SQL> @Sel_Aud
PC03 30
Der Kern dieses Skriptes ist das folgende SQL :
select OS_USERNAME,
USERNAME,
TO_CHAR(TIMESTAMP,'DD.MM.YY HH24:MI:SS') Login_Timestamp,
TO_CHAR(LogOff_Time,'DD.MM.YY HH24:MI:SS') LogOff,
Action_Name,
TERMINAL||' '||USERHOST WO,
Client_ID
from DBA_AUDIT_TRAIL
where Username LIKE '&BENUTZER'
AND ( SysDate - Timestamp ) <= &TAGE
order by Timestamp ;
Datenschutz-konforme Anforderungen an Paßwörter u.a. im GTDS
Um dem Mißbrauch von Benutzernamen und Paßwörtern vorzubeugen, werden häufig eine Reihe
von Forderungen gestellt wie :
1. Begrenzte Lebensdauer von Paßwörtern, anschließend soll ein Wechsel innerhalb einer Frist
erzwungen werden
2. Paßwort muß beim ersten eigenständigen Login geändert werden
3. Mindestlänge , z.B. 8 Zeichen
4. frühere Paßwörter dürfen (evtl. für eine gewisse Zeit) nicht wieder verwendet werden
5. nicht triviale Paßwörter. Bestimmte einfache Varianten und bekannte Wörter sollen nicht
verwendet werden. Paßwörter sollen nicht nur Buchstaben, sondern auch Zahlen und
Satzzeichen enthalten.
6. Verbindung soll nach einer gewissen Zeit der Inaktivität getrennt werden
7. Maximale Verbindungszeit ohne Unterbrechung soll auf einen Arbeitstag begrenzt sein.
8. Login wird nach einer gewissen, geringen Anzahl von Fehlversuchen gesperrt.
Als kommerzielle Datenbank bietet Oracle in Gestalt der Benutzerprofile schon lange solche
Möglichkeiten. Da GTDS sein Login über Oracle durchführt, konnten sie auch schon immer mit
GTDS verwendet werden. Manche Funktionen wurden allerdings nicht über die Masken unterstützt,
so dass beispielsweise bei fehlgeschlagenen Logins generische Werkzeuge von ORACLE genutzt
werden mussten, um Probleme zu beheben.
Mit dem neuesten Versionsstand unterstützt GTDS geeignete Benutzerprofile direkt in der
Benutzerverwaltung. Informations- und Fehlermeldungen zum Paßwortablauf und -wechsel werden
explizit gehandhabt. Aus Gründen der Kompatibilität zur bisherigen Arbeitsweise (Schulung der
Anwender vor Aktivierung erforderlich) werden diese Funktionen jedoch nicht bei der Installation
des Updates automatisch aktiviert. Nach der Installation des aktuellen Patches ist GTDS stehen also
die neuen Paßwort-Funktionen zur Verfügung, müssen aber explizit aktiviert werden.
Als Beispiel wird in der Datei Beispiel_Profil.sql ein einfaches Profil namens
BSP_PROFIL zur Verfügung gestellt. In der Benutzerverwaltung im GTDS könnte dieses Profil
dann neuen Benutzern zugewiesen werden. Das nachfolgend dargestellte Profil muss den lokalen
Erfordernissen angepasst werden. Die im folgenden verwendete Bezeichnung BSP_PROFIL dient
lediglich der Illustration und sollte durch einen passenden Namen ersetzt werden.
Beispiel_Profil.sql
erzeugt das neue Profil BSP_PROFIL mit folgenden
Einstellungen :
CPU_PER_SESSION 360000
eine Stunde CPU (Einheit 1/100 Sec.)
IDLE_TIME 30
30 Minuten nichts tun. Gilt nicht für langlaufende
Abfragen und Berichte
CONNECT_TIME 800
800 Minuten Verbindungszeit. Am nächsten Tag auf
jeden Fall neues Login erforderlich
FAILED_LOGIN_ATTEMPTS 8
Fehlerhafte Login- Versuche. ACHTUNG : Das initiale
Login ins klassische GTDS wird u.U. doppelt gezählt.
PASSWORD_LIFE_TIME 50
Maximale Lebensdauer des Paßwortes in Tagen
PASSWORD_REUSE_TIME 100
Paßwort kann erst nach dieser Zahl Tagen wieder
verwendet werden, nur wenn seitdem mindestens
PASSWORD_REUSE_MAX Paßwortwechsel erfolgt sind.
PASSWORD_REUSE_MAX 8
Paßwort kann ggf. nach dieser Zahl Wechsel wieder
benutzt werden
PASSWORD_VERIFY_FUNCTION Pwck
-- s.u.
PASSWORD_LOCK_TIME UNLIMITED
Ein gesperrter Account (z.B. wegen zuvieler Login mit
falschem Paßwort) muß vom GTDS - Administrator
entsperrt werden.
PASSWORD_GRACE_TIME 30
Nach Ablauf des Paßwortes (PASSWORD_LIFE_TIME) ist
noch diese Anzahl von Tagen zum Ändern verfügbar.
Beim Login ins GTDS erfolgt ein entsprechender Hinweis.
Zur Überprüfung von Länge und Inhalt der Paßwörter dient die PL/SQL - Funktion PWCK , wie
im Profil unter PASSWORD_VERIFY_FUNCTION angegeben :
Passwort.sql
muß als SYS (!) ausgeführt werden. Erzeugt die
Hilfsfunktion Pwck zur Paßwort- Überprüfung.
Die Anforderungen an Paßworte des jeweiligen Profiles,
dem diese Funktion zugeordnet ist, werden in dieser
Funktion festgelegt. Gegenwärtig realisiert :
- altes und neues Paßwort verschieden, minimaler
Unterschied derzeit ein Zeichen
- Paßwort mindestens 8 Zeichen lang
- Paßwort muß mindestens je ein Zeichen enthalten von
* Buchstaben
* Ziffern
* Satzzeichen
Einmalige Vorbereitung der Datenbank
Damit ein entsprechendes Profil GTDS – Benutzern zugewiesen werden kann, sind zwei Schritte
notwendig :
1. Hilfsfunktion PWCK zur Paßwort-Überprüfung unter SYS erzeugen. Das geht am
einfachsten aus einem administrativen Account auf dem Datenbank-Server (unter Windows
muß er der Gruppe ORA_DBA angehören, unter Linux der Gruppe dba, wie meist der
oracle) :
sqlplus
…
/NOLOG
SQL> CONNECT / AS SYSDBA
….
SQL> @Passwort
….
SQL> EXIT
evtl. muß zu Passwort.sql der volle Pfadname angegeben werden.
2. Profil BSP_Profil erzeugen. Das kann als OPS$TUMSYS geschehen, wenn der (wie meist)
DBA-Rechte hat :
SQL> SHO USER
User is OPS$TUMSYS
SQL> @Beispiel_Profil
Auch hier könnte wieder der volle Pfadname zu Beispiel_Profil.sql nötig sein.
Danach kann das Profil für GTDS – Benutzer verwendet werden.
ACHTUNG :
Es ist unter Umständen sinnvoll, für unterschiedliche Arten von Benutzern unterschiedliche Profile
zu erstellen und den Benutzern zuzuweisen. Das vorgestellte Beispiel-Profil sollte beispielsweise
nicht unverändert dem OPS$TUMSYS zugewiesen werden, da ohne spezielle
Vorsichtsmaßnahmen unter Umständen ein Login nicht mehr möglich ist und zur Behebung auf
übergeordnete Nutzer zurückgegriffen werden müsste. Ähnliches gilt auch für Spezialbenutzern wie
GTDSHL7 oder GTDSEXP oder GTDSSESSIONINITIATE für Schnittstellen, Datenbankexport
und Vermittlung von WebGTDS-Aufrufen, die nicht für interaktive Sitzungen gedacht sind und
auch nur begrenzte Berechtigungen haben. Werden für diese Fälle Vorschläge für Profile benötigt,
sollte derzeit noch Rücksprache mit den Entwicklern erfolgen.
Des weiteren sollte bedacht werden, dass bei der Einrichtung insbesondere sehr strenger Profile
auch eine Logistik vorhanden sein muss, die quasi zwangsläufig häufiger auftretenden Probleme
(gesperrte Accounts, abgelaufene oder nicht erinnerbare Passwörter, …) kurzfristig zu beheben,
damit zeitkritische Nutzungen wie Anmeldung von Patienten zu Tumorkonferenzen jederzeit zur
Verfügung stehen.
Neue GTDS – Parameter
- PASSWORT.AENDERN
wenn Ja für einen Benutzer gesetzt, wird dieser nach dem
Logon unmittelbar aufgefordert, sein Paßwort zu ändern, und
in die Maske SETPASS geführt. Bricht er dort ab, erwarten
ihn derzeit noch keine Restriktionen
- PASSWORT.PROFIL
Name jenes Profiles, das für den Datenschutz neuen GTDS Benutzern zugewiesen werden soll. Wenn Sie unser Beispiel_Profil.sql
verwenden ist der Wert einfach BSP_PROFIL
- GLOBAL.PASSWORT_MIT_REPLACE
muß auf Ja gesetzt werden, sonst funktioniert die PaßwortÄnderung nicht.
Änderungen von Masken im GTDS
In der Benutzerverwaltung kann jetzt einzelnen Benutzern ein Profil zugewiesen werden (in diesem
Fall heißt das Profil DATENSCHUTZ 1). Die Maske zum ändern des Paßwortes kann direkt
aufgerufen werden (2). Ist ein Benutzer gesperrt (z.B. Arzt hat das Paßwort vergessen und zu oft
probiert), kann mit dem Knopf Unlock die Sperre unmittelbar aufgehoben werden (3).
Erweitert wurde auch die Maske zur Paßwort-Änderung :
Die Grundfunktionalität bleibt die gleiche. Jedoch wird jetzt das Ablaufdatum des
Benutzerpaßwortes angezeigt, wenn vorhanden, und ein evtl. Sperrdatum. Ist der Account gesperrt,
kann er direkt in dieser Maske entsperrt werden.
Nach Drücken von Passwort ändern wird das neue Paßwort gesetzt, jedoch nur wenn es die
Bedingungen des für den zu ändernden Benutzer gesetzten Profiles (s.o.) erfüllt. Ist das nicht der
Fall kommt eine Fehlermeldung wie diese :
Hier entspricht das
Paßwort nicht den
Anforderungen, da es
keine Ziffer enthält. Die
volle Meldung, daß das
Paßwort Buchstaben,
Ziffern und Satzzeichen
enthalten muß, wird leider
noch abgeschnitten.
Verfügbarkeit der SQL-Skripte
Die erwähnten SQL-Skripte sind im aktuellen GTDS – Patch bzw. - Update enthalten, werden
jedoch nicht automatisch ausgeführt. Sie sind im Unterverzeichnis SQL\passwort_skripte
abgelegt. Beispiel_Profil.sql heißt in einigen frühen Distributionen
Datenschutz_Profil.sql.