Ein Passwortschutz besteht auf Datenbankebene. Sofern der Zugriff auf das System auf Betriebssystemebene durch Eingabe von Benutzerkennung und Passwort geschützt werden kann, besteht zusätzlich ein Passwortschutz auf Betriebssystemebene (z.B. Windows NT, UNIX, Novell). Grundsätzlich sind Betriebssystemkennung und Benutzername zwei unterschiedliche Dinge. Dementsprechend können oder sollen sogar die Paßwörter unterschiedlich sein.
Unter bestimmten Voraussetzungen kann die Datenbank so parametrisiert werden, daß die Datenbank ein Betriebssystem-Login als Berechtigung anerkennt, ohne daß eine zweite Paßworteingabe erfolgt. Näheres ist der Dokumentation der ORACLE-Version zu entnehmen. In diesem Zusammenhang muß darauf verwiesen werden, daß die maximale Länge einer GTDS-Kennung 10 Zeichen ist. Es kann daher vorkommen, daß Betriebssystem- und GTDS/ORACLE-Kennung nicht zusammenpassen.
Die Daten sind dem Benutzer OPS$TUMSYS, auf Server-Ebene der Benutzer 'tumsys' zugeordnet. Er erteilt anderen Benutzern Zugriffsrechte (Leserechte und, im Fall von Bewegungsdaten, Schreibrechte) auf seine Tabellen und Sichten (Views). Zusätzlich sind für alle Tabellen (und andere Objekte wie Views und Prozeduren), auf die andere zugreifen sollen, PUBLIC SYNONYMe eingerichtet. Ohne diese müßte Benutzer MAIER zum Beispiel auf die Tabelle TUMOR von OPS$TUMSYS mit vorangestelltem Benutzernamen, also OPS$TUMSYS.TUMOR zugreifen, was die Programmierung der Masken etc. erheblich komplizierter gemacht hätte. Mit dem PUBLIC SYNONYM TUMOR für OPS$TUMSYS.TUMOR kann er dann einfach mit TUMOR zugreifen.
Im alphanumerischen GTDS wurden diese Zugriffsrechte zunächst über individuelle GRANT-Befehle direkt an die berechtigten Benutzer vergeben. Immer, wenn neue Tabellen oder andere Objekte im GTDS hinzugefügt wurden oder neue Benutzerkennungen angelegt wurden, mußte über Skripte eine entsprechende Rechtevergabe durchgeführt werden. Mit ORACLE 7 standen dann sogenannte Rollen zur Verfügung. Diese erlauben, typische Benutzerprofile einzurichten. Neue Benutzer bekommen dann nur noch die Rollen zugeteilt, für die sie berechtigt sind. Die Rechte für neue Objekte im GTDS werden dann nur noch an die Benutzerrollen erteilt. Hierdurch vereinfacht sich die Verwaltung insgesamt.
Im graphischen GTDS bestehen komfortable Verwaltungsmöglichkeiten für Benutzerrollen und Rechte. Weiterführende Informationen:
Die alten, individuell erteilten Rechte bleiben erhalten und ergänzen die über Benutzerrollen erteilten Rechte. Die Übersicht über die erteilten Benutzerrollen vermittelt also kein exaktes Bild über die tatsächlich vorhandenen Rechte. Dies trifft natürlich nur für die "alten" Benutzer zu und kann in der Regel auch keinen Schaden verursachen, da zusätzliche Mechanismen (Zugang über Masken) den Zugriff auf bestimmte Objekte erschweren. Solange weiterhin die GRANT-Skripte genutzt werden, ist kein Umstieg auf die Rollen erforderlich. Allerdings werden die GRANT-Skripte vom graphischen GTDS-Client nicht unterstützt.
Auf einige Tabellen, insbesondere die AUSWERTUNG%tabellen, bei denen eine Weiterverarbeitung von Daten außerhalb des GTDS vorgesehen ist, können andere Benutzer als der OPS$TUMSYS nur über Views (z.B. AUSWERTUNG_ALLE für die Tabelle AUSWERTUNG) zugreifen und bekommen nur Datensätze von Patienten, die in Abteilungen betreut werden (Tabelle ABTEILUNG_PATIENT, Maske abt_pat), auf die sie Zugriff haben. Das entsprechende PUBLIC SYNONYM zeigt dann auf diesen View, statt auf die Tabelle (also PUBLIC SYNONYM AUSWERTUNG zeigt auf OPS$TUMSYS.AUSWERTUNG_ALLE). Damit können die Auswertungsmasken "sicher" auch Nicht-Leitstellen-Benutzern zur Verfügung gestellt werden, zeigen aber natürlich ggf. nicht alle Patienten an. Dies gilt auch für alle "Leitstellen-Benutzer", die nicht Zugriff auf alle Abteilungen haben.
Weitere Sicherungsmöglichkeiten bestehen auf Anwendungsebene:
Es besteht die Möglichkeit, optional eine sogenannte Leitstellen einzurichten. Eine Leitstelle ist eine besondere Abteilung innerhalb des GTDS. Alle Benutzer, die der Leitstelle angehören, werden Leitstellenbenutzer genannt. Sie dürfen alle Dokumente, unabhängig davon, ob sie der Leitstelle zugeordnet sind, verändern. Arbeiten die Leitstellenbenutzer mit der Leitstelle im Kontext, so können sie auch alle Patienten auswählen, ohne daß diese in den betreuenden Abteilungen der Leitstelle zugeordnet sind oder werden.
