Konzept Sicherheit

In der Regel erfolgt die Authentifizierung von Anwendern über eine zentrale Komponente der Systemlandschaft, in welche das IT-System eingebettet ist. Die Authentifizierung darf auch lokal, d.h. vom IT-System selbst, durchgeführt werden, falls es beispielsweise nicht in eine Systemlandschaft eingebettet ist.

Für die zentrale Authentifizierung wird üblicherweise ein IAM-System verwendet.

Das IAM-System verwaltet Anwender und ihre Rollen.

Die Authentifizierung und grobgranulare Autorisierung erfolgt, gemäß der siehe Prinzipien der Sicherheitsarchitektur, an den Außenschnittstellen der Systemlandschaft. Hierbei wird eine Session aufgebaut und das IAM-System ermittelt nach erfolgreicher Authentifizierung die Rollen des Anwenders. Die Rollen allein sind jedoch noch nicht ausreichend, um Anwender vollständig zu autorisieren.

Die Autorisierung geschieht in jedem Fall im jeweiligen IT-System. Nach der erfolgreichen Authentifizierung eines Anwenders leitet das IAM-System die Anfrage an das IT-System weiter. Hier wird die Anfrage – je nach Schutzbedarf und Funktionalität – autorisiert. Dazu weist das IT-System einem Anwender anhand seiner Rollen Rechte zu und prüft diese gegen die für die Anfrage benötigten Rechte. Wie genau Rollen und Rechte spezifiziert werden, beschreibt das Kapitel Rollen und Rechte.

Aus den Prinzipien der Sicherheitsarchitektur leiten sich die folgenden Randbedingungen für die Umsetzung der Berechtigungsprüfung innerhalb eines IT-Systems ab:

Die folgende Abbildung zeigt den logischen Aufbau für die Authentifizierung und für die Bereitstellung von Berechtigungsinformationen an die Komponenten eines IT-Systems.

Im Folgenden werden die Aufgaben und grobe Funktionsweise der Komponenten für die Autorisierung von Anfragen in einer Geschäftsanwendung erläutert.

Die Komponente AufrufKontextVerwalter stellt für eine laufende Anfrage Kontextinformationen zur Anfrage bereit, die in einem AufrufKontext hinterlegt werden. Das sind insbesondere die mit der Anfrage über die Außenschnittstelle eingehenden Informationen zum Anwender und dessen Rollen, die Korrelations-ID und anwendungsspezifisch ggf. weitere Informationen. Die Komponente bringt Hilfsmittel zur transparenten Nutzung des AufrufKontextVerwalter mit. So wird der AufrufKontext bei Serviceaufrufen transparent über Interceptoren via Spring AOP gesetzt. Weiterhin wird der Aufrufkontext im Rahmen der Authentifizierung automatisch befüllt. Nach Initialisierung des AufrufKontextVerwalter für eine laufende Anfrage kann das IT-System fortan transparent mit den im AufrufKontextVerwalter hinterlegten Anwenderinformationen arbeiten (ohne deren Herkunft zu kennen) und damit auch weitere Nachbarsysteme aufrufen.

Der Baustein Sicherheit bietet folgende Funktionen:

Die Authentifizierung und Autorisierung von Web-Zugriffen wird über Spring Security durchgeführt. Die Integration von Spring Security und des Bausteins Sicherheit wird im Detailkonzept Komponente WebGUI beschrieben.

Im Folgenden wird die Schnittstelle des Bausteins Sicherheit beschrieben.

Die zentrale Schnittstelle für den Zugriff auf Rollen und Rechte eines Anwenders ist Berechtigungsmanager. Instanzen des Berechtigungsmanagers zur Autorisierung einer Anfrage werden über die Schnittstelle Sicherheit erzeugt.

Der Berechtigungsmanager verwendet die Schnittstellen Rolle und Recht. Rollen werden über die Benutzeradministration Anwendern zugewiesen. Rechte sind anwendungsspezifisch und an Rollen gebunden.

So wie ein IT-System bei einem Aufruf erwartet, einen gültigen, vollständigen Aufrufkontext vorzufinden, erwartet dies auch ein Nachbarsystem, welches vom eigenen IT-System aufgerufen wird. Das aufrufende System muss daher einen Aufrufkontext mitliefern. Im Regelfall soll dabei der Aufrufkontext der originären Anfrage verwendet und unverändert weitergeleitet werden.

Zum Aufruf von Nachbarsystemen sollen, falls vorhanden, dedizierte Client-Bibliotheken verwendet werden. Diese enthalten bereits die Logik zur Weiterleitung des Aufrufkontextes.

Gibt es diese nicht, muss das Nachbarsystem direkt aufgerufen werden. Hierbei muss das aufrufende IT-System stets ein entsprechendes Transportobjekt befüllen und mit dem Aufruf an das Nachbarsystem übergeben. Für die Technologie Spring HTTP Invoker stellt die IsyFact passende Transportobjekte in der Bibliothek isy-serviceapi-sst bereit.

Rollen werden bereits auf fachlicher Ebene als Teil der Systemspezifikation einer Geschäftsanwendung spezifiziert. Dazu werden zunächst in geeigneter Granularität Rechte definiert, die zur Benutzung bestimmter Funktionalität der Geschäftsanwendung berechtigen. Diese Rechte werden fachlichen Rollen zugeordnet, die dann wiederum den Anwendern der Anwendung zugeordnet werden können. Die fachlichen Rollen ermöglichen in der Regel pauschal den Zugriff auf die Geschäftsanwendung oder, im Sinne der Rolle eines fachlichen Sachbearbeiters, die Nutzung ausgewählter Anwendungsfälle.

Alle Rollen besitzen die folgende Struktur:

Name: Interner Name der Rolle, wie er für die Autorisierung und innerhalb von Anwendungen zur Überprüfung bereitgestellt wird.

Label: Name der Rolle, wie sie in der Oberfläche der Benutzeradministration angezeigt wird. In der Regel ist dieser Name identisch mit dem technischen Namen der Rolle. Eine Abweichung ist nur dann sinnvoll, wenn die Vergabe der Rollen durch den Administrator dadurch intuitiver wird.

Beschreibung: Eine kurze Beschreibung der Rolle in einer fachlichen Sprache, die für die Benutzeradministration verständlich ist.

Typ: Eine Rolle kann fachlich oder technisch sein. Nur fachliche Rollen können über die Benutzeradministration verwaltet werden. Technische Rollen können fachlichen Rollen allerdings untergeordnet werden (siehe weiter unten: Untergeordnete Rollen).

Enthaltene Rechte: Die Ausstattung einer fachlichen Rolle mit Rechten beschreibt den Funktionsumfang, den diese Rolle bei Nutzung der Geschäftsanwendung ermöglicht.

Untergeordnete Rollen: Optional können fachliche Rollen untergeordnete technische Rollen besitzen. Dies ist z.B. immer dann notwendig, wenn ein Anwendungsfall die Services eines Nachbarsystems verwendet. Somit muss im Rahmen des Anwendungsfalls die Service-Schnittstelle des Nachbarsystems aufgerufen werden. Die dazu benötigte, technische Rolle muss der fachlichen Rolle untergeordnet werden, damit dies funktioniert.

Sichtbarkeit der Rolle: Die Sichtbarkeit der Rollen bei der Zuordnung an Anwender, externe Systeme und interne Systeme kann eingeschränkt werden, um die Administration zu vereinfachen.

Die meisten Rollen sind fachlicher Natur. Technische Rollen treten oft im Rahmen von Service-Schnittstellen auf. Bietet eine Geschäftsanwendung Funktionalität über Service-Schnittstellen an, so ist die Nutzung jeder Service-Schnittstelle zumindest durch eine technische Rolle abzusichern. Diese Rollen werden nicht direkt an Anwender vergeben, sondern fachlichen Rollen anderer Geschäftsanwendungen untergeordnet.

Wenn die Anwendung fachliche oder technische Batches enthält, dann müssen für diese Batches in der Spezifikation entsprechende „interne Systeme“ definiert werden. Die Systemnamen sollten dem folgenden Schema entsprechen: <Anwendungskürzel>_BAT_<Batchname>. Für jedes dieser internen System müssen eigene fachliche Rollen definiert werden.

Zum Schnitt von fachlichen und technischen Rollen gibt es Erfahrungswerte, welche das restliche Kapitel detailliert. Wichtig ist vor allem die Beziehung zwischen fachlichen und technischen Rollen. Des weiteren sollte die Menge der Rollen so klein wie möglich gehalten werden.

Die Abbildung Abbildung 3 verdeutlicht den Inhalt der folgenden Abschnitte grafisch.

Die Benennung von Rollen muss fachlich getrieben sein. Das bedeutet vor allem, dass Rollen für eine fachliche Operation, d.h. den Akteur, angelegt werden. Grundsätzlich gilt, dass die Namen der Rollen ausgeschrieben werden, sofern sie nicht zu lang werden. Ist dies der Fall, sollte der Namen abgekürzt und ein sprechendes Label für die Administration der Rollen vergeben werden.

Wird ein neues IT-System entwickelt, sind die oben genannten Richtlinien zum Schnitt und zur Benennung der Rollen stärkstens empfohlen. Hierfür ist eine enge Abstimmung mit der Benutzeradministration und den jeweiligen fachlichen Ansprechpartnern erforderlich. Alle Parteien verfügen über unterschiedliches, sich ergänzendes Fachwissen, das essenziell für die Erstellung von Rollen ist.

Prinzipiell sollten so wenig Rollen wie möglich und so viele wie nötig vergeben werden. Der folgende Prozess bietet eine grobe Richtlinie:

Die Rollen und Rechte sollten bereits während der Erstellung des Systementwurfs entworfen werden, soweit dies möglich ist. Sobald die angebotenen Schnittstellen bekannt sind, können die entsprechenden Rollen nach obigen Richtlinien erstellt werden. Die zugehörigen untergeordneten Rollen lassen sich durch die aufgerufenen Nachbarsystemschnittstellen ermitteln.

Eine wesentliche Einschränkung der bisherigen Modellierung findet sich bei Tests und Inbetriebnahmen. Es gestaltet sich bislang schwer, dass vor der eigentlichen Inbetriebnahme nur eine kleine Menge von Anwendern auf eine neue Geschäftsanwendung zugreifen kann. So werden oft, auch bei der Ablösung einer Geschäftsanwendung durch eine neue Umsetzung, komplett neue Rollen für die neue Geschäftsanwendung vergeben, um die Absicherung beider Geschäftsanwendungen zu gewährleisten. Dies führt oft zu aufwendigen Migrationen und zu einer stark ansteigenden Menge von Rollen.

Um dies zu vermeiden, kann eine neue fachliche Rolle für eine Art Testmodus eingeführt:

Geschäftsanwendungen, die bestehende Geschäftsanwendungen ablösen oder vor der offiziellen Inbetriebnahme einer kleinen Menge von Anwendern zur Verfügung stehen, müssen in ihrer betrieblichen Konfiguration einen Schalter besitzen, der einen Testmodus aktiviert. Ist der Schalter (und damit der Testmodus) aktiv, wird zusätzlich zur üblichen Autorisierung auf die zusätzliche, fachliche Rolle geprüft. Somit ist sichergestellt, dass beim Ablösen von alten Geschäftsanwendungen auch die neue Geschäftsanwendung mit denselben Rollen abgesichert und (falls nötig) parallel betrieben werden kann. Genauso funktioniert auch das Freischalten einer neuen Geschäftsanwendung für einen zunächst kleinen Kreis von Anwendern. In beiden Fällen muss zur eigentlichen Inbetriebnahme, anstatt einer aufwändigen Migration, nur ein Schalter in der betrieblichen Konfiguration umgelegt werden.