Aus technischen und organisatorischen Gründen ist es oft notwendig, mehreren Personen Zugang zu einer Benutzerkennung zu verschaffen. Üblicherweise musste dazu allen zugangsberechtigten Personen das Kennwort und die Abrechnungsnummer mitgeteilt werden. Dieses Vorgehen hat den Nachteil, dass die Verantwortung für ein Kennwort nicht mehr auf eine Person begrenzt ist. Außerdem kann die Urheberschaft von Aktionen anhand der SAT-Einträge nur noch einem Personenkreis, nicht aber einer bestimmten Person zugeordnet werden.
Der Operand DIALOG-ACCESS des Kommandos /MODIFY-LOGON-PROTECTION wurde erweitert. Damit können für eine Benutzerkennung andere Benutzerkennungen als zusätzlich zugangsberechtigt festgelegt werden. Es wird eine personenspezifische Identifizierung/Authentisierung während der Dialogzugangsprüfung veranlasst. Die Benutzerkennung, die mit der personenbezogenen Identifizierung angegeben wurde, wird in die SAT-Einträge übernommen. Somit ist es möglich, Personen als Urheber einzelner Aktionen auch nachträglich zu ermitteln.
Für die persönliche Identifizierung steht das Kommando /SET-PERSONAL-ATTRIBUTES zur Verfügung. Es ermöglicht unmittelbar im Anschluss an das Kommando /SET-LOGON-PARAMETERS die Eingabe einer persönlichen Benutzerkennung mit deren Kennwort. Die Aufforderung zur persönlichen Identifikation wird durch Angabe PERSONAL-LOGON= *YES im Kommando /MODIFY-LOGON-PROTECTION bewirkt.
Die persönliche Benutzerkennung ist eine normale Benutzerkennung, die auch selbst als Logon-Benutzerkennung dienen kann.
Ausschlaggebend für die Rechte des Anwenders, der Zugang mittels persönlicher Identifizierung erlangt hat, bleiben allein die Rechte, die für die Logon-Kennung definiert sind. Die Rechte der persönlichen Kennung werden nur bei der Zugangsprüfung (s.u.) ausgewertet.
Im Benutzerkatalog wird prinzipiell nicht zwischen Logon- und persönlichen Benutzerkennungen unterschieden. Daher kann als persönliche Benutzerkennung jede beliebige Benutzerkennung angegeben werden, jedoch nicht die Logon-Benutzerkennung selbst (dies wird abgewiesen mit Fehler SRM3206).
Folgende Maßnahmen sind erforderlich, um einen Zugangsschutz mit der persönlichen Identifizierung zu realisieren:
Einrichten von persönlichen Benutzerkennungen. Wird die Kennung nur zum Zwecke der persönlichen Identifizierung benötigt, genügt die Angabe von Name, Kennwort, Abrechnungsnummer.
Angabe PERSONAL-LOGON=*YES
Einrichten eines Guards, in dem Zugriffsbedingungen und persönliche Benutzerkennungen oder Gruppenamen als zugriffsberechtigte Subjekte festgelegt werden.
Schutz des Dialogzugangs der Benutzerkennung, für die die persönliche Identifizierung eingeschaltet ist, mit diesem Guard.
Zusammenwirken der Operanden PERSONAL-LOGON, PASSWORD-CHECK und GUARD-NAME
Die Werte der Operanden PERSONAL-LOGON, PASSWORD-CHECK und GUARD-
NAME (siehe Kommandos /SET- bzw. /MODIFY-LOGON-PROTECTION) können beliebig kombiniert werden. Allgemein gilt:
Der Operand PASSWORD-CHECK (= *YES/*NO) regelt, ob das Kennwort der Logon-Kennung anzugeben ist oder nicht.
Der Operand PERSONAL-LOGON (= *YES/*NO) regelt, ob bei Zugang zu dieser Kennung (LOGON) eine persönliche Identifizierung aufgefordert wird oder nicht.
Folgende Möglichkeiten ergeben sich:
Standard-Einstellung
(PASSWORD-CHECK=*YES,GUARD-NAME=*NONE, PERSONAL-LOGON=*NO):Nur Dialog-Logon mit dem Kennwort der Logon-Kennung ist zugelassen. Der Operand PASSWORD-CHECK regelt, ob das Kennwort der Logon-Kennung anzugeben ist oder nicht.
Dialogzugangsregelung mittels GUARD ohne persönliche Identifizierung (GUARD-NAME = <name>, PERSONAL-LOGON = * NO):
Über das Guard lassen sich zeitliche Bedingungen für den Dialogzugang einstellen. Das im Guard angegebene Subjekt muss Zugriff durch die Logon-Kennung erlauben (Name der Kennung, Gruppenangabe, *OTHERS-Zweig).
Persönliche Identifikation ist erforderlich
(PERSONAL-LOGON=*YES):Die Eingabe der persönlichen Kennung und ihres Kennwortes ist erforderlich (Kommando /SET-PERSONAL-ATTRIBUTES). Über ein Guard kann die Menge der für eine persönliche Identifizierung zulässigen Kennungen eingeschränkt werden. Diese Kennungen sind in dem Guard explizit oder über Gruppennamen als Subjekt anzugeben. Ist kein Guard spezifiziert (GUARD-NAME=*NONE), sind alle Kennungen zugelassen.
Die Kennwortprüfung ist abhängig vom Operanden PASSWORD-CHECK:
Bei PASSWORD-CHECK=*YES werden sowohl das Kennwort der Logon-Kennung als auch das der persönlichen Kennung überprüft.
Im Falle von PASSWORD-CHECK=*NO ist die Kennwortprüfung ganz auf die Prüfung des Kennwortes der persönlichen Kennung verlagert.
Falls die Logon-Kennung ein Kennwort besitzt und dieses beim Logon angegeben wird, wird auf die Anforderung einer zusätzlichen persönlichen Identifikation verzichtet. Die Logon-Kennung wird implizit zur persönlichen Identifizierung herangezogen.
Diese Vorgehensweise ermöglicht es insbesondere, dass Anwendungen, die den Zugang zum System über $DIALOG realisieren (wie z.B. RFA), ohne Anpassung Zugang zu Kennungen haben können, für die eine persönliche Identifizierung vereinbart ist.
Relevante Attribute bei der Zugangskontrolle
Zu beachten ist, dass mit dem Zulassen von Kennungen für eine persönliche Identifizierung Zugangsattribute dieser Kennungen wirksam werden. Die folgende Tabelle zeigt, welche Attribute in der Zugangskontrolle geprüft und damit relevant für den Zugang zur Logon-Kennung werden:
Kennung | Logon- | persönlich |
Kennung gesperrt | ja | nein |
Kennung abgelaufen | ja | ja |
Dialog-Zugriff gesperrt | ja | nein |
ACCOUNTNUMBER | ja | nein |
Kennwort | ja | ja |
PASSWORD-CHECK | ja | nein |
GUARD | ja | nein |
TERMINALS | nein | ja |
TERMINAL-SETS | nein | ja |
Von der persönlichen Benutzerkennung werden also jene Attribute herangezogen, die für die persönliche Authentisierung des Aufrufers benötigt werden, unabhängig davon, ob die Kennung gesperrt ist oder nicht. Ferner wird angenommen, dass der Zugang zur Logon-Kennung nur über die Sichtstationen der persönlichen Kennung erfolgen darf.
Beispiele zur persönlichen Identifizierung
Beispiel 1
Für den Dialogzugang zur Benutzerkennung USER0001 wird das persönliche Logon vereinbart. Jede persönliche Benutzerkennung soll zulässig sein. Die Kenntnis des Logon-Kennwortes von USER0001 soll nicht erforderlich sein.
|
Bei der Einleitung eines Auftrags sind nun zwei Fälle zu unterscheiden:
Der Benutzer gibt beim Logon kein Kennwort an
/set-logon-parameters user0001,useracc1% SRM3205 PLEASE ENTER '/SET-PERSONAL-ATTRIBUTES' OR '?'/set-personal-attributes user0002,'userpas2'% JMS0066 JOB '(NONE)' ACCEPTED ON 2018-03-02 AT 14:57, TSN = 8NI9Der Benutzer muss sich durch Angabe seiner eigenen Benutzerkennung und seines Logon-Kennwortes identifizieren und authentisieren.
Der Benutzer gibt beim Logon das Kennwort der Kennung USER01 an
/set-logon-parameters user0001,useracc1,'userpas1'% JMS0066 JOB '(NONE)' ACCEPTED ON 2018-03-02 AT 14:58, TSN = 8NJ2Das Logon wird implizit als persönliche Identifizierung gewertet. Damit hat sich der Benutzer als USER0001 authentisiert. Eine weitere Prüfung findet nicht statt.
Beispiel 2
Für den Dialogzugang zur Benutzerkennung USER0001 wird eine persönliche Identifizierung vereinbart. Nur die Benutzerkennungen USER0002 und USER0003 sollen zum Zugang berechtigt sein. Sie werden im Guard GUARD003 definiert. Die Kenntnis des Logon-Kennwortes von USER0001 ist erforderlich.
Zu diesem Zweck wird das Guard GUARD003 für systemweiten Zugriff eingerichtet. Die berechtigten Benutzerkennungen USER0002 und USER0003 werden als Subjekte eingetragen.
|
Anschließend wird für die Benutzerkennung USER0001 vereinbart, dass eine persönliche Identifizierung verlangt wird und der Zugang über das Guard GUARD003 geschützt wird.
/modify-logon-protection user-id=user0001, -/ password=*p(logon-password='userpas1'), -
/ dialog-access=*yes(guard-name=guard003,personal-logon=*yes)
Das Logon muss unter Angabe des Logon-Kennwortes erfolgen. Zusätzlich muss sich der Benutzer persönlich identifizieren und authentisieren.
|