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.
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.
- 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
- 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:
- 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.
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.
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.
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:

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.
Anwendung | Server | Knoten |
---|---|---|
A1 | S1 | N1 |
A2 | S1 | N1 |
A3 | S2 | N2 |
A4 | S3 | N3 |

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.

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.

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.

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, 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:

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