Differenzierte Verwaltungssicherheit

In den Releases vor WebSphere Application Server Version 6.1 konnten Benutzer mit mit Verwaltungsrollen alle Ressourcen in der Zelle verwalten. WebSphere Application Server geht jetzt differenzierter vor, denn der Zugriff wird jetzt pro Ressource erteilt und kann jedem Benutzer gewährt werden.

Benutzern kann beispielsweise der Konfigurationszugriff auf eine bestimmte Instanz einer Ressource (einer Anwendung, eines Anwendungsservers oder eines Knotens) gewährt werden. Benutzer können ausschließlich auf die Ressourcen zugreifen, die ihnen zugeordnet sind. Die Verwaltungsrollen gelten jetzt nicht mehr für die gesamte Zelle, sondern werden einzelnen Ressourcen zugeordnet. Aus Gründen der Kompatibilität mit früheren Versionen gibt es jedoch eine Berechtigungsgruppe für die gesamte Zelle. Benutzer mit Verwaltungsrollen, die zu dieser Gruppe gehören, können nach wie vor auf alle Ressourcen innerhalb der Zelle zugreifen.
Anmerkung: Knoten einer Vorversion von WebSphere Application Server 6.1 werden in einer gemischten Zellenumgebung aus der Ressourcenzuordnung herausgefiltert.

Um diese instanzbasierte oder differenzierte Sicherheit zu erreichen, werden Ressourcen, die dieselben Berechtigungen erfordern, zu einer Berechtigungsgruppe zusammengefasst. Benutzer erhalten Zugriff auf die Berechtigungsgruppe, wenn ihnen die erforderliche Verwaltungsrolle zugeordnet wird.

Die differenzierte Verwaltungssicherheit kann auch in Einzelserverumgebungen genutzt werden. Mehrere Anwendungen des Einzelservers können zu unterschiedlichen Berechtigungsgruppen zusammengefasst werden. Für verschiedene Anwendungen gibt es dann unterschiedliche Berechtigungsvorgaben. Der Server selbst kann in einer Einzelserverumgebung nicht zu einer Berechtigungsgruppe gehören.

Über wsadmin-Scripts und die Administrationskonsole können Sie Benutzer und Gruppen der Rolle adminsecuritymanager auf Zellenebene zuordnen. Mit der Rolle "adminsecuritymanager" können Sie Benutzer und Gruppen Rollen für Benutzer mit Verwaltungsaufgaben bzw. Rollen für Gruppen mit Verwaltungsaufgaben zuordnen.

Wenn eine differenziert Verwaltungssicherheit verwendet wird, können Benutzer, die der Rolle "adminsecuritymanager" zugeordnet sind, Berechtigungsgruppen verwalten. Eine ausführliche Beschreibung aller Verwaltungsrollen finden Sie im Artikel Verwaltungsrollen und Berechtigung für den Namensservice.

Ein Administrator kann diesen Rollen (einschließlich der Rolle "adminsecuritymanager") keine Benutzer oder Gruppen zuordnen. Nähere Einzelheiten finden Sie im Artikel Verwaltungsrollen.

Es gibt diverse Befehle für Verwaltungssicherheit, die für die Erstellung von Berechtigungsgruppen, die Zuordnung von Ressourcen zu Berechtigungsgruppen und die Zuordnung von Benutzern zu Verwaltungsrollen innerhalb dieser Gruppen verwendet werden können. Nachfolgend sind einige Beispiele für die Verwendung von wsadmin aufgelistet:
  • Erstellen einer neuen Berechtigungsgruppe:
    $AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1}
  • Löschen einer Berechtigungsgruppe:
    $AdminTask deleteAuthorizationGroup {-authorizationGroupName groupName}
  • Hinzufügen von Ressourcen zu einer Berechtigungsgruppe:
    $AdminTask addResourceToAuthorizationGroup
    {-authorizationGroupName Gruppenname -resourceName Application=app1}
  • Entfernen von Ressourcen aus einer Berechtigungsgruppe:
    $AdminTask removeResourceFromAuthorizationGroup 
    {-authorizationGroupName Gruppenname -resourceName Application=app1}
  • Hinzufügen von Benutzern zu Rollen einer Berechtigungsgruppe:
    $AdminTask mapUsersToAdminRole {-authorizationGroupName groupName
    -roleName administrator -userids user1}
  • Hinzufügen von Gruppen-IDs zu Rollen einer Berechtigungsgruppe:
    $AdminTask mapGroupsToAdminRole {-authorizationGroupName groupName
    -roleName administrator -groupids group1}
  • Entfernen von Benutzern aus Rollen einer Berechtigungsgruppe:
    AdminTask removeUsersFromAdminRole {-authorizationGroupName
    groupName -roleName administrator -userids user1}
  • Entfernen von Gruppen-IDs aus Rollen einer Berechtigungsgruppe:
    $AdminTask removeGroupsFromAdminRole {-authorizationGroupName
    groupName -roleName administrator -groupids group1}

Ressourcen, die zu einer Berechtigungsgruppe hinzugefügt werden können

Zu einer Berechtigungsgruppe können Sie nur Ressourcen der folgenden Typen hinzufügen:
  • Zelle
  • Knoten
  • Server-Cluster
  • Server
  • Anwendung
  • Knotengruppe

Falls eine Ressource nicht einem der aufgelisteten Typen zugeordnet werden kann, wird die übergeordnete Ressource verwendet.

Eine Ressource kann nur zu einer Berechtigungsgruppe gehören. Zwischen den Ressourcen besteht jedoch eine Einschlussbeziehung. Wenn eine übergeordnete Ressource zu einer anderen Berechtigungsgruppe als ihre untergeordnete Ressource gehört, gehört die untergeordnete Ressource implizit zu mehreren Berechtigungsgruppen. Sie können eine Ressource jedoch nicht zu mehreren Berechtigungsgruppen hinzufügen.

Die folgende Übersicht zeigt die Einschlussbeziehung zwischen Ressourcen:

Diagramm der Einschlussbeziehungen

Welche Berechtigungen für Aktionen erforderlich sind, die für bestimmte Ressourcen ausgeführt werden, ist von zwei Faktoren abhängig:
  • Von der Berechtigungsgruppe der Verwaltungsressource. Wenn einem Benutzer der Zugriff auf eine Berechtigungsgruppe gewährt wird, sind alle Ressourcen dieser Gruppe eingeschlossen.
  • Von der Einschlussbeziehung der Ressource. Wenn einem Benutzer der Zugriff auf eine übergeordnete Ressource gewährt wird, sind alle untergeordneten Ressourcen eingeschlossen.

Für die Keystore-Verwaltung muss ein Benutzer Verwaltungsberechtigungen auf Zellenebene haben, da die Keystores auf Zellenebene erstellt und verwaltet werden. Ein differenzierter Sicherheitszugriff auf eine bestimmte Ressource lässt die Verwaltung der zugeordneten Keystores nicht zu.

Tabelle 1. Erforderliche Berechtigungen für den Zugriff auf verschiedene Verwaltungsressourcen. Die für den Zugriff auf verschiedene Verwaltungsressourcen benötigten Berechtigungen sind in der folgenden Tabelle angegeben:
Ressource Aktion Erforderliche Rolle
Server Starten, Stoppen, Laufzeitoperationen Operator (Server, Knoten, Zelle)
Server Neu, Löschen Configurator (Knoten, Zelle)
Server Konfiguration bearbeiten Configurator (Server, Knoten, Zelle)
Server Konfiguration anzeigen, Laufzeitstatus Monitor (Server, Knoten, Zelle)
Knoten Neustart, Stoppen, Synchronisieren Operator (Knoten, Zelle)
Knoten Hinzufügen, Löschen Configurator (Zelle)
Knoten Konfiguration bearbeiten Configurator (Knoten, Zelle)
Knoten Konfiguration anzeigen, Laufzeitstatus Monitor (Knoten, Zelle)
Cluster Starten, Stoppen, Laufzeitoperationen Operator (Cluster, Zelle)
Cluster Neu, Löschen Configurator (Zelle)
Cluster Konfiguration bearbeiten Configurator (Cluster, Zelle)
Cluster Konfiguration anzeigen, Laufzeitstatus Monitor (Cluster, Zelle)
Cluster-Member Starten, Stoppen, Laufzeitoperationen Operator (Server, Cluster, Knoten, Zelle)
Cluster-Member Neu, Löschen Configurator (Knoten, Zelle)
Cluster-Member Konfiguration bearbeiten Configurator (Server, Cluster, Knoten, Zelle)
Cluster-Member Konfiguration anzeigen, Laufzeitstatus Monitor (Server, Cluster, Knoten, Zelle)
Anwendung Alle Operationen Weitere Informationen finden Sie im Abschnitt zur Rolle "Deployer" im Artikel Verwaltungsrollen.
Knoten, Cluster Hinzufügen, Löschen Configurator (Zelle)

Die Rolle "Operator (Server)" ist die Rolle der Berechtigungsgruppe, zu der die Serverinstanz gehört, und die Rolle "Operator (Knoten)" ist die Rolle der Berechtigungsgruppe, zu der die Knoteninstanz gehört.

Damit die differenzierte Verwaltungssicherheit in der Administrationskonsole verwendet werden kann, sollte ein Benutzer mindestens der Rolle "Monitor" auf Zellenebene zugeordnet werden. Für die Anmeldung bei wsadmin muss ein Benutzer nur der Rolle "Monitor" für eine Berechtigungsgruppe zugeordnet sein.

Beispiel: Differenzierte Sicherheit verwenden

Die folgenden Szenarien beschreiben die Verwendung einer differenzierten Verwaltungssicherheit, insbesondere für die neue Implementierungsrolle.

Szenario 1 für Rolle "Implementierung"

Im folgenden Szenario sind vier Anwendungen auf Server1 konfiguriert. Vergleichen Sie dazu die folgende Tabelle. Jede Anwendung muss isoliert werden, damit der Administrator einer Anwendung keine andere Anwendung ändern kann. Beispiel: Nur Benutzer1 kann die Anwendung A1 verwalten, Benutzer2 kann die Anwendungen A2 und A3 verwalten, und nur Benutzer3 kann die Anwendung A4 verwalten.

Anmerkung: Es wird nicht empfohlen, eine Anwendung in einer Gruppe und den Zielserver in einer anderen Gruppe zu haben. Dies ist jedoch nicht immer möglich. Es ist üblich, viele Anwendung auf einem Server auszuführen. Manchmal ist es trotzdem erforderlich, die Verwaltung von Anwendungen zu trennen, die auf demselben Server ausgeführt werden.

Ein Beispiel hierfür ist ein Application Service Provider (ASP), bei dem in einem einzelnen Anwendungsserver mehrere Anwendungen mehrerer Anbieter ausgeführt werden können. In diesem Fall ist der Serveradministrator für die Installation der Anwendungen verantwortlich. Nachdem die Anwendungen installiert sind, kann jeder Anbieter seine eigene Anwendung verwalten, ohne die Anwendungen anderer Anbieter zu beeinträchtigen.

Tabelle 2. Anwendungen in Szenario 1 für die Rolle "Implementierung".

In dieser Tabelle sind die Anwendungen für das Szenario 1 für Implementierungsrollen aufgelistet.

Anwendung Server Knoten
A1 S1 N1
A2 S1 N1
A3 S1 N1
A4 S1 N1

Sie können Berechtigungsgruppen wie in dem nachfolgenden Diagramm gezeigt konfigurieren:

Im Diagramm gehört die Anwendung A1 zur Berechtigungsgruppe G1, die Anwendungen A2 und A3 gehören zur Berechtigungsgruppe G2, und die Anwendung A4 gehört zur Berechtigungsgruppe G3. Eine Rolle Deployer wird von der Berechtigungsgruppe G1 user1 zugeordnet, von der Berechtigungsgruppe G2 user2 und von der Berechtigungsgruppe G3 user3 zugeordnet.

In dem Diagramm ist Anwendung A1 in der Berechtigungsgruppe G1, die Anwendungen A2 und A3 sind in der Berechtigungsgruppe G2 und die Anwendung A4 ist in der Berechtigungsgruppe G3.

Eine Rolle "Deployer" wird von der Berechtigungsgruppe G1 user1 zugeordnet, von der Berechtigungsgruppe G2 user2 und von der Berechtigungsgruppe G3 user3 zugeordnet.

Daher kann user1 alle Operationen auf Anwendung A1, user2 auf den Anwendungen A2 und A3 und user3 auf der Anwendung A4 durchführen. Da alle Anwendungen denselben Server verwenden, kann dieser nicht in allen Berechtigungsgruppen enthalten sein. Nur ein Administrator auf Zellenebene kann eine Anwendung installieren. Nachdem die Installation einer Anwendung abgeschlossen ist, kann der Implementierer jeder Anwendung die eigenen Anwendungen ändern. Zum Starten und Stoppen des Servers ist Administratorberechtigung erforderlich. Dieses Szenario ist in einer ASP-Umgebung hilfreich.

Szenario 2 für die Rolle "Implementierung"

Im folgenden Szenario erfordert eine Gruppe von Anwendungen dieselbe Verwaltungsrolle für einen Server. In diesem Beispiel gehören die Anwendungen A1 und A2 zusammen und können von einer Administratorgruppe verwaltet werden. Sie werden auf demselben Server (S1) ausgeführt. Für die Anwendungen A3 und A4 ist eine andere Administratorgruppe erforderlich. Sie werden auf den Servern S2 bzw. S3 ausgeführt.

Tabelle 3. Anwendungen in Szenario 2 für die Rolle "Implementierung".

In dieser Tabelle sind die Anwendungen für das Szenario 2 für Implementierungsrollen aufgelistet.

Anwendung Server Knoten
A1 S1 N1
A2 S1 N1
A3 S2 N2
A4 S3 N3
Im folgenden Szenario erfordert eine Gruppe von Anwendungen dieselben Verwaltungsrollen für einen Server. In diesem Beispiel gehören die Anwendungen A1 und A2 zusammen und können von einer einzigen Gruppe von Administratoren verwaltet werden. Sie werden auf demselben Server (S1) ausgeführt. Die Anwendungen A3 und A4 erfordern eine andere Gruppe von Administratoren und werden auf den Servern S2 bzw. S3 ausgeführt.
Szenarien, die direkt in Umgebungen des Kunden angewendet werden können.

Jeder Entwickler muss die Konfiguration seiner Server ändern und seine Anwendungen auf diesem Server installieren können. Sie müssen Server und Anwendungen auf dem Server starten und stoppen können.

Entwickler müssen Server konfigurieren können, um möglicherweise auftretende Fehler beheben zu können. Sie müssen die Fähigkeit besitzen, die zu entwickelnde Anwendung aktualisieren und ändern zu können. Die Verwaltungsberechtigungsgruppe für diesen Entwickler beinhaltet mindestens einen Server und alle Anwendungen, die der Entwickler auf diesem Server installiert.

Die Verwaltungsberechtigungsgruppe für diesen Entwickler beinhaltet mindestens einen Server und alle Anwendungen, die der Entwickler auf diesem Server installiert.

Im folgenden Beispiel steht den Entwicklern der Berechtigungsgruppe G1 eine neue Anwendung (A11) zur Verfügung. Sie können diese neue Anwendung nur auf Servern der Berechtigungsgruppe G1 installieren und verwenden. Sie können diese neue Anwendung auch in ihre Berechtigungsgruppe (G1) aufnehmen.

Im folgenden Beispiel haben Entwickler der Berechtigungsgruppe G1 eine neue Anwendung (A11). Sie können diese neue Anwendung nur in den Servern der Berechtigungsgruppe G1 installieren. Außerdem können Sie die neue Anwendung in ihre Berechtigungsgruppe (G1) übernehmen.
Szenario für ASP-Umgebung

In diesem Szenario ist der Kunde ein Application Service Provider (ASP). Dieser hat seine eigenen Kunden, für die er Anwendungen bereitstellt. Die Kunden sollen in der Lage sein, ihre Anwendungen zu verwalten und zu überwachen, sie sollen jedoch nicht die Anwendungen anderer Kunden sehen und verwalten können. In diesem Beispiel hat der ASP jedoch interne Administratoren, deren Aufgabe es ist, die Server zu verwalten.

Dieser interne ASP-Administrator muss möglicherweise eine Anwendung von einem Server auf einen anderen Server verschieben, um sicherzustellen, dass eine Anwendung verfügbar bleibt. Er sollte Server starten und stoppen und ihre Konfiguration ändern können.

Im Gegensatz dazu sollte der Administrator des ASP-Kunden keine Server starten und stoppen können. Der Administrator des ASP-Kunden muss jedoch seine Anwendungen, die auf diesen Servern ausgeführt werden, aktualisieren können. Die Verwaltungsberechtigungsgruppe für den internen ASP-Administrator kann eine ganze Zelle oder eine Untergruppe von Servern, Knoten, Clustern und Anwendungen umfassen. Die Verwaltungsberechtigungsgruppe für den Administrator des Kunden umfasst lediglich die Anwendungen, für deren Bereitstellung der Kunde diesen ASP bezahlt.

Wenn Sie das Konfigurationsrepository aktualisieren, führen Sie die Verwaltungsscripts über den Deployment Manager aus, damit die differenzierten Sicherheitsregeln wirksam werden, wenn die Verwaltungsscripts von der Seite des Deployment Manager aus ausgeführt werden.

Das folgende Diagramm zeigt ein Szenario mit zwei verschiedenen Kunden und jeweils zwei verschiedene Arten von Anwendungen, die sie selbst verwalten können. Die Server und Knoten, auf denen die Anwendungen ausgeführt werden, sind jedoch von den Kunden isoliert. Diese Server und Knoten können nur von den internen Administratoren verwaltet werden. Außerdem können die Kunden ihre Anwendungen nicht auf einen anderen Server ausrichten. Dies kann nur von einem internen Administrator oder internen Implementierern durchgeführt werden.

Das folgende Diagramm zeigt ein Szenario, in dem zwei verschiedene Kunden zwei verschiedene Typen von Anwendungen haben und ihre eigenen Anwendungen verwalten können. Die Server und Knoten, auf denen die Anwendungen ausgeführt werden, sind jedoch von ihren Kunden isoliert. Die Server und Knoten können nur von den internen Administratoren verwaltet werden. Außerdem können die Kunden ihre Anwendungen nicht in einem anderen Server installieren. Dies kann nur vom internen Administrator oder von internen Implementierern durchgeführt werden.
Szenario für regional ausgerichtete Unternehmen

In diesem Szenario ist der Kunde ein großes weltweites Unternehmen. Die Knoten und Server des Unternehmens sind so organisiert, dass eine Anwendungsbereitstellung für verschiedene Regionen (oder alternativ verschiedene Geschäftszweige) möglich ist. Administratoren in den verschiedenen regionalen Bereichen sollen in der Lage sein, die Knoten und Server, die einer bestimmten Region zugeordnet sind, zu überwachen und zu verwalten. Es ist jedoch nicht erwünscht, dass der regionale Administrator auf Knoten oder Server einer anderen Region zugreifen kann.

Die Verwaltungsberechtigungsgruppe für jeden regionalen Administrator umfasst Knoten, Server, Cluster und Anwendungen, die der entsprechenden Region zugeordnet sind.

Ein Beispiel für dieses Szenario könnte ein Unternehmen sein, dass mehrere Services bereitstellt, z. B. ein Geldinstitut, das Services wie Kreditkartenkonten, Depot-Konten, Bankkonten und Konten für Reisekosten anbietet. Jeders dieser Services kann über unterschiedliche Anwendungen ausgeführt werden, und für jede dieser Anwendungen muss ein anderer Administrator zuständig sein. Die folgende Abbildung zeigt eine Möglichkeit, ein solches System zu konfigurieren:

Die folgende Abbildung zeigt eine Möglichkeit, ein solches System zu konfigurieren:

Die folgende Abbildung zeigt, wie die Ressourcen in einem solchen System gruppiert werden, um die Administratoren voneinander zu isolieren.

Die folgende Abbildung zeigt, wie die Ressourcen in einem solchen System gruppiert werden, um die Administratoren voneinander zu isolieren.

Beachten Sie, dass die Knoten zu keiner Berechtigungsgruppe gehören. Daher kann der Administrator einer Handelsanwendung keinen Server auf Knoten stoppen, und somit auch keine Handelsanwendung stoppen.

Dasselbe System kann auch wie nachfolgend abgebildet konfiguriert werden:

Dasselbe System kann auch wie nachfolgend abgebildet konfiguriert werden:

Die folgende Abbildung zeigt, wie die Ressourcen in einem solchen System gruppiert werden, um die Administratoren voneinander zu isolieren.

Die folgende Abbildung zeigt, wie die Ressourcen in einem solchen System gruppiert werden, um die Administratoren voneinander zu isolieren.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_fineg_admsec
Dateiname:csec_fineg_admsec.html