RBAC/Single Sign-On
Herkömmliche, benutzer-basierte Zugriffskontrollmodelle können aufwändig sein, denn Benutzerwechsel sind relativ häufig.
In einem gutdurchdachten modernen Geschäftsprozess werden daher Zugriffsrechte eher einer Rolle zugewiesen als einer Person.
Eine Rolle wird dabei definiert aufgrund der Tätigkeiten, die zu einer Job-Funktion gehören sowie durch die damit in Zusammenhang
stehende Autorität und Verantwortung. Einer Person können eine oder mehrere Rollen zugewiesen werden. Gemäss dieser Zuweisung
erhält die Person Zugriff auf bestimmte Bereiche eines Systems, z.B. zum Ausführen von Operationsbefehlen oder zum Ändern
von Daten.
Rolf Stalder, Manager PCS Systems Hardware & Software Engineering, beantwortet zehn Fragen zu PMCS RBAC/SSO:
Das neue PMCS Modul
Aktuelle PMCS Releases können mit dem neuen RBAC/SSO Modul konfiguriert werden. Dieses Modul erweitert die Zugriffskontroll-Features
des PMCS Systems erheblich. Zusätzlich wird die Anwenderfreundlichkeit durch das neue Single Sign-On verbessert. Rolf Stalder, Manager PCS Systems Hardware & Software Engineering, beantwortet zehn Fragen zu PMCS RBAC/SSO:
Rolf Stalder
Die bisherigen PMCS Releases waren mit einer Level-Autorisierung (konfigurierbare Autorisierungsebenen) ausgestattet. Wo liegen
die Schwachstellen dieses Modells?
In der herkömmlichen Level-Autorisierung gibt es keine strikte Trennung zwischen Authentifizierungs- und Autorisierungsprüfung. Die Autorisierungsebenen in den Applikationen sind zum Teil fix codiert oder können nur pro GUI-Instanz vorkonfiguriert werden. Zudem unterliegen viele Applikationen keiner Prüfung. Es hätte durchaus die Möglichkeit bestanden, die bestehende Level-Autorisierung zu überarbeiten. Wir zogen es jedoch aus verschiedenen Gründen vor, stattdessen einen Rechte-Wrapper zu entwickeln: Um das Ausführen von PMCS-Programmen verhindern zu können, hätten alle PMCS-Programme in die heutige Level-Autorisierung eingebunden werden müssen. Für eine flexible Rechtevergabe wäre zudem ein Verwaltungsmechansimus vonnöten. Dies wäre viel zu aufwändig!
Bei vielen PMCS-Programmen kann die UNIX-Berechtigung mit der einzig sinnvoll nutzbaren Berechtigung gleichgesetzt werden. Um die für den technischen Betrieb notwendigen Berechtigungen im SSO-Modus beibehalten zu können, ist der Einsatz eines Rechte-Wrappers zwingend, denn das PMCS System kennt keine Trennung zwischen Client- und Server-Programmen. Der Rechte-Wrapper von Solaris basiert auf dem RBAC-Modell und kann relativ einfach in Applikationen eingebunden werden (API).
Applikationsspezifische Berechtigungen könnten längerfristig mit Hilfe des RBAC-Mechanismus flexibel verwaltet werden (als Ersatz für die heutige Level-Prüfung).
Die PMCS Level-Prüfung ist rückwärtskompatibel. Der RBAC-Modus bietet zur Zeit eine zusätzliche Möglichkeit zur Vergabe von Berechtigungen und ist (noch) kein Ersatz für die Level-Autorisierungsprüfung des PMCS.
Was sind die wesentlichen Vorteile des RBAC-Modells gegenüber dem Benutzer/Gruppen Modell, wie es in UNIX Systemen üblich ist?
Eine Rolle leitet sich aus der Geschäftslogik ab und steht für eine Geschäftsfunktion. Rollen ändern daher selten, ganz im Gegensatz zu Benutzern. Ein- und Austritte von Mitarbeitern, Beförderungen, Einführung neuer Applikationen und damit verbunden Ablösung bestehender Applikationen, all dies sind relativ häufig auftretende Ereignisse in einem Betrieb. Rollen eignen sich daher ideal als Bindeglied. Eine Geschäftsfunktion wird von allen Beteiligten verstanden, applikationsspezifische Berechtigungen in der Regel nicht. Auch ohne technische Rollenunterstützung ist diese "Gedankenstütze" bei der Herleitung von technischen Berechtigungen hilfreich.
Woraus besteht das neue PMCS Modul, und welche Technologien kommen zum Einsatz?
Beim Single Sign-On verwenden wir den MIT Kerberos Server und die zugehörigen Bibliotheken. Für den GUI Teil kommt GTK/GLIB sowie Glade/Libglade zum Einsatz. Auf unserer Seite wurde eine Bibliothek für SSO-Funktionalität entwickelt, und natürlich mussten einige PMCS Programme angepasst werden. Ausserdem haben wir ein grafisches sowie ein Kommandozeilen-Programm zum Ein- und Ausloggen entwickelt.
Zur Realisierung des RBAC-Teils haben wir basierend auf der Solaris RBAC-Bibliothek eine RBAC-Wrapper-Applikation für PMCS Programme entwickelt.
Entstehen zusätzliche Kosten für den Kunden bei der Implementierung von RBAC/SSO für PMCS Applikationen?
Ja, falls zusätzliche Supportleistungen seitens PCS notwendig werden zur Definition und Ausarbeitung von Rollen. Softwareseitig entstehen keine zusätzlichen Kosten.
Wie erfolgt die Rechteverwaltung bei komplexen Systemen mit mehreren Prozessrechnern?
Solaris RBAC kann mit einem Verzeichnisdienst (NIS oder LDAP) betrieben werden. Dies erlaubt die zentrale Konfiguration und Pflege der Berechtigungen.
Gemäss 21 CFR 11 (11.300) besteht die Anforderung, dass die Einmaligkeit einer elektronischen Unterschrift eindeutig einer Person und deren Funktionen zugeordnet sein muss. Wird diese Anforderung auch mit PMCS Single Sign-On erfüllt?
Ja, der ausführende Benutzer wird wie bis anhin an den "Level-Prüfstellen" aufgezeichnet.
Entstehen durch den Einsatz von RBAC/SSO prozessbezogene Risiken?
In der SSO-Betriebsart wird, genau gleich wie in der herkömmlichen Betriebsart, vorausgesetzt, dass der Benutzer die Berechtigungsprüfung nicht mutwillig umgehen will (Ausloggen unterlassen bzw. Weitergabe des Passwortes). Im Falle von SSO kann auch durch ein Versehen ein Risiko entstehen. Auf der anderen Seite ist in der herkömmlichen Betriebsart die häufige Passworteingabe problematisch, weil dadurch die Wahrscheinlichkeit grösser wird, dass ein "Mitgucker" das Passwort erfährt.
Was ist unter Single Sign-on im PMCS Kontext zu verstehen?
Eine sessionbasierte Fahrweise des PMCS mit personalisierten Accounts. Pro Benutzer wird eine Programminstanz gestartet, d.h. es gibt kein Sharing von Programmen. Programme werden mit der persönlichen UNIX ID des Benutzers gestartet. Der Benutzer loggt sich bei der ersten Level-Prüfung, oder explizit mit dem SSO-Client, in die PMCS Applikation ein. Anschliessend behält er die entsprechende Level-Berechtigung für die konfigurierte Ticket-Laufzeit und wird nicht mehr nach dem Passwort gefragt. Der Benutzer kann aber jederzeit seine Credentials löschen (ausloggen) und forciert dadurch bei der nächsten Level-Prüfung eine erneute Passwortabfrage. Das System-Passwort des Benutzers entspricht dem PMCS Passwort. Da der Benutzername aus der UNIX-Umgebung bekannt ist, kann dieser in den Passwort-Dialogen nicht eingegeben oder modifiziert werden.
Also kann z.B. ein Benutzer, der als "supervisor1" an UNIX angemeldet ist, die PMCS Applikation nicht als "operator1" bedienen?
Richtig, wenn RBAC und SSO verwendet werden, wird dies absichtlich verhindert. Mit RBAC ohne SSO ist dies unterstützt, allerdings nur mittels der PMCS-Passwortdatenbank.
Für welche PMCS Versionen ist das RBAC/SSO Modul verfügbar? Können bestehende PMCS Systeme aufgerüstet werden?
Das RBAC Modul ist für PMCS R7 und R8 sowie für die aktuelle PMCS Version verfügbar. Das SSO Modul nur für das aktuelle PMCS ab Iteration 1.0.0.
Bei den Betriebssystemen werden für RBAC Solaris 10 (Intel und SPARC) sowie Solaris 8 SPARC unterstützt. Für SSO Solaris 10 (Intel und SPARC) und Solaris 8 SPARC, letzteres jedoch ohne SSO Client.
Die Aufrüstung bestehender Systeme ist gemäss diesen Einschränkungen möglich. Für Solaris 8 Systeme empfehlen wir jedoch ein Upgrade auf Solaris 10.
Weitere Informationen
In der herkömmlichen Level-Autorisierung gibt es keine strikte Trennung zwischen Authentifizierungs- und Autorisierungsprüfung. Die Autorisierungsebenen in den Applikationen sind zum Teil fix codiert oder können nur pro GUI-Instanz vorkonfiguriert werden. Zudem unterliegen viele Applikationen keiner Prüfung. Es hätte durchaus die Möglichkeit bestanden, die bestehende Level-Autorisierung zu überarbeiten. Wir zogen es jedoch aus verschiedenen Gründen vor, stattdessen einen Rechte-Wrapper zu entwickeln: Um das Ausführen von PMCS-Programmen verhindern zu können, hätten alle PMCS-Programme in die heutige Level-Autorisierung eingebunden werden müssen. Für eine flexible Rechtevergabe wäre zudem ein Verwaltungsmechansimus vonnöten. Dies wäre viel zu aufwändig!
Bei vielen PMCS-Programmen kann die UNIX-Berechtigung mit der einzig sinnvoll nutzbaren Berechtigung gleichgesetzt werden. Um die für den technischen Betrieb notwendigen Berechtigungen im SSO-Modus beibehalten zu können, ist der Einsatz eines Rechte-Wrappers zwingend, denn das PMCS System kennt keine Trennung zwischen Client- und Server-Programmen. Der Rechte-Wrapper von Solaris basiert auf dem RBAC-Modell und kann relativ einfach in Applikationen eingebunden werden (API).
Applikationsspezifische Berechtigungen könnten längerfristig mit Hilfe des RBAC-Mechanismus flexibel verwaltet werden (als Ersatz für die heutige Level-Prüfung).
Die PMCS Level-Prüfung ist rückwärtskompatibel. Der RBAC-Modus bietet zur Zeit eine zusätzliche Möglichkeit zur Vergabe von Berechtigungen und ist (noch) kein Ersatz für die Level-Autorisierungsprüfung des PMCS.
Was sind die wesentlichen Vorteile des RBAC-Modells gegenüber dem Benutzer/Gruppen Modell, wie es in UNIX Systemen üblich ist?
Eine Rolle leitet sich aus der Geschäftslogik ab und steht für eine Geschäftsfunktion. Rollen ändern daher selten, ganz im Gegensatz zu Benutzern. Ein- und Austritte von Mitarbeitern, Beförderungen, Einführung neuer Applikationen und damit verbunden Ablösung bestehender Applikationen, all dies sind relativ häufig auftretende Ereignisse in einem Betrieb. Rollen eignen sich daher ideal als Bindeglied. Eine Geschäftsfunktion wird von allen Beteiligten verstanden, applikationsspezifische Berechtigungen in der Regel nicht. Auch ohne technische Rollenunterstützung ist diese "Gedankenstütze" bei der Herleitung von technischen Berechtigungen hilfreich.
Woraus besteht das neue PMCS Modul, und welche Technologien kommen zum Einsatz?
Beim Single Sign-On verwenden wir den MIT Kerberos Server und die zugehörigen Bibliotheken. Für den GUI Teil kommt GTK/GLIB sowie Glade/Libglade zum Einsatz. Auf unserer Seite wurde eine Bibliothek für SSO-Funktionalität entwickelt, und natürlich mussten einige PMCS Programme angepasst werden. Ausserdem haben wir ein grafisches sowie ein Kommandozeilen-Programm zum Ein- und Ausloggen entwickelt.
Zur Realisierung des RBAC-Teils haben wir basierend auf der Solaris RBAC-Bibliothek eine RBAC-Wrapper-Applikation für PMCS Programme entwickelt.
Entstehen zusätzliche Kosten für den Kunden bei der Implementierung von RBAC/SSO für PMCS Applikationen?
Ja, falls zusätzliche Supportleistungen seitens PCS notwendig werden zur Definition und Ausarbeitung von Rollen. Softwareseitig entstehen keine zusätzlichen Kosten.
Wie erfolgt die Rechteverwaltung bei komplexen Systemen mit mehreren Prozessrechnern?
Solaris RBAC kann mit einem Verzeichnisdienst (NIS oder LDAP) betrieben werden. Dies erlaubt die zentrale Konfiguration und Pflege der Berechtigungen.
Gemäss 21 CFR 11 (11.300) besteht die Anforderung, dass die Einmaligkeit einer elektronischen Unterschrift eindeutig einer Person und deren Funktionen zugeordnet sein muss. Wird diese Anforderung auch mit PMCS Single Sign-On erfüllt?
Ja, der ausführende Benutzer wird wie bis anhin an den "Level-Prüfstellen" aufgezeichnet.
Entstehen durch den Einsatz von RBAC/SSO prozessbezogene Risiken?
In der SSO-Betriebsart wird, genau gleich wie in der herkömmlichen Betriebsart, vorausgesetzt, dass der Benutzer die Berechtigungsprüfung nicht mutwillig umgehen will (Ausloggen unterlassen bzw. Weitergabe des Passwortes). Im Falle von SSO kann auch durch ein Versehen ein Risiko entstehen. Auf der anderen Seite ist in der herkömmlichen Betriebsart die häufige Passworteingabe problematisch, weil dadurch die Wahrscheinlichkeit grösser wird, dass ein "Mitgucker" das Passwort erfährt.
Was ist unter Single Sign-on im PMCS Kontext zu verstehen?
Eine sessionbasierte Fahrweise des PMCS mit personalisierten Accounts. Pro Benutzer wird eine Programminstanz gestartet, d.h. es gibt kein Sharing von Programmen. Programme werden mit der persönlichen UNIX ID des Benutzers gestartet. Der Benutzer loggt sich bei der ersten Level-Prüfung, oder explizit mit dem SSO-Client, in die PMCS Applikation ein. Anschliessend behält er die entsprechende Level-Berechtigung für die konfigurierte Ticket-Laufzeit und wird nicht mehr nach dem Passwort gefragt. Der Benutzer kann aber jederzeit seine Credentials löschen (ausloggen) und forciert dadurch bei der nächsten Level-Prüfung eine erneute Passwortabfrage. Das System-Passwort des Benutzers entspricht dem PMCS Passwort. Da der Benutzername aus der UNIX-Umgebung bekannt ist, kann dieser in den Passwort-Dialogen nicht eingegeben oder modifiziert werden.
Also kann z.B. ein Benutzer, der als "supervisor1" an UNIX angemeldet ist, die PMCS Applikation nicht als "operator1" bedienen?
Richtig, wenn RBAC und SSO verwendet werden, wird dies absichtlich verhindert. Mit RBAC ohne SSO ist dies unterstützt, allerdings nur mittels der PMCS-Passwortdatenbank.
Für welche PMCS Versionen ist das RBAC/SSO Modul verfügbar? Können bestehende PMCS Systeme aufgerüstet werden?
Das RBAC Modul ist für PMCS R7 und R8 sowie für die aktuelle PMCS Version verfügbar. Das SSO Modul nur für das aktuelle PMCS ab Iteration 1.0.0.
Bei den Betriebssystemen werden für RBAC Solaris 10 (Intel und SPARC) sowie Solaris 8 SPARC unterstützt. Für SSO Solaris 10 (Intel und SPARC) und Solaris 8 SPARC, letzteres jedoch ohne SSO Client.
Die Aufrüstung bestehender Systeme ist gemäss diesen Einschränkungen möglich. Für Solaris 8 Systeme empfehlen wir jedoch ein Upgrade auf Solaris 10.
Weitere Informationen
Auf weitere Fragen zu RBAC/SSO gibt Ihnen gerne unsere Systems Hardware & Software Abteilung Auskunft.
