Audit- und Paßwort-Funktionen im GTDS

Transkript

1 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 ( 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

2 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 SQL- Statement 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

3 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 ). 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 Benutzer AnzahlTage Sollen also alle Datenbank Verbindungen des Benutzers PC03 in den letzten 30 Tagen aufgelistet werden, ginge das so : 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

4 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 eine Stunde CPU (Einheit 1/100 Sec.) IDLE_TIME Minuten nichts tun. Gilt nicht für langlaufende Abfragen und Berichte CONNECT_TIME 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

5 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

6 SQL> CONNECT / AS SYSDBA. 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 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

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

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

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