Sicherheit des Job-Managers

In einer Umgebung für flexibles Management muss eine Benutzer-ID die richtige Berechtigung haben, um den Verwaltungsagenten zu verwenden und mit registrierten Knoten zu arbeiten.

Erforderliche Sicherheitsrollen

Sie benötigen die folgenden Rollen, um den Job-Manager zu verwenden:

Tabelle 1. Erforderliche Sicherheitsrollen für Tasks des Job-Managers. Die Rollen sind: Verwaltung (Administrator), Bedienung (Operator), Konfiguration (Configurator) und Überwachung (Monitor).
Verwaltungstasks Erforderliche Sicherheitsrollen
Registrierung beim Job-Manager durchführen bzw. zurücknehmen Administration
Job übergeben Bedienung
Job-Manager-Konfiguration ändern Konfiguration
Job-Manager-Konfiguration oder Jobprotokoll lesen Überwachung

Wenn eigenständige Anwendungsserverknoten (Basisknoten), die vom Verwaltungsagenten verwaltet werden, beim Job-Manager registriert werden, benötigen Sie die folgenden Rollen, um den Verwaltungsagenten zu verwenden und seine Knoten zu verwalten:

Tabelle 2. Erforderliche Sicherheitsrollen für Tasks des Verwaltungsagenten. Die Rollen sind folgende: "Administration" und die für die Operation oder den Knoten erforderlichen Rollen.
Verwaltungstasks Erforderliche Sicherheitsrollen
Registrierung eines Basisknotens (eines eigenständigen Knotens) beim Verwaltungsagenten durchführen bzw. zurücknehmen Administration
Mit dem Verwaltungsagenten arbeiten: Verwaltungsrollen, die für die auszuführende Operation erforderlich sind
Mit dem Verwaltungssubsystem (z. B. den registrierten Knoten) arbeiten Verwaltungsrollen, die für den registrierten Basisknoten erforderlich sind

Wenn ein Job auf einem Ziel ausgeführt wird, muss der Benutzer Berechtigungen haben, die die erforderliche Rolle für den Job einschließen. Beispielsweise ist für den Job zum Erstellen eines Anwendungsservers mindestens die Rolle "Konfiguration" auf dem Basisknoten oder in der WebSphere Application Server Network Deployment-Zelle erforderlich.

Sicherheit für Installation-Manager- oder Libertyjobs auf fernen Hosts

Wenn für den Zugriff auf einen fernen Host wie Installation Manager oder Liberty ein Benutzername und ein Kennwort erforderlich sind, müssen Sie einen gültigen Betriebssystembenutzernamen und ein gültiges Betriebssystemkennwort angeben, da sonst kein Job auf dem fernen Host ausgeführt werden kann. Sie können die folgenden Arten der Autorisierung bereitstellen:

Betriebssystembenutzername und -kennwort
Der Benutzername und das Kennwort sind die Anmeldewerte für den Host. Wenn für den Host kein Kennwort erforderlich ist, muss bei der Übergabe eines Jobs kein Kennwort angegeben werden.
Sudo
Wenn Befehle auf dem Host von einem Vertreter ausgeführt werden sollen, können Sie "sudo" verwenden, um vor Ausführung eines Jobs die Benutzer zu wechseln. Anschließend müssen Sie den Benutzernamen und das Kennwort für den Vertreter angeben. sudo steht für "substitute user do". Wenn für den Host kein Kennwort erforderlich ist, muss bei der Übergabe eines Jobs kein Kennwort angegeben werden.
Authentifizierung mit öffentlichem und privatem Schlüssel
Sie können die Authentifizierung mit öffentlichem und privatem Schlüssel verwenden. Wenn Sie einen Job übergeben, geben Sie den vollständigen Pfad zum Keystore und, sofern für den Keystore erforderlich, die Kennphrase an. Ein privater SSH-Schlüssel (Secure Shell) ermöglicht es einem Administrator, einen Job unter einem bestimmten Benutzernamen auf dem fernen Host auszuführen. Der Schlüssel ist mit einem Kennwort verschlüsselt, um zu verhindern, dass er von einem anderen Benutzer verwendet wird.

Für Liberty-Server ist der Autorisierungstyp, den Sie verwenden, abhängig von den Benutzernamen, die für jeden Host konfiguriert sind:

Einzelner Benutzername
Wenn jeder Host nur einen Benutzernamen verwendet, müssen Sie lediglich sicherstellen, dass der Benutzer Schreibzugriff auf die Verzeichnisse für die Installation der Liberty-Ressourcen hat. Damit die Jobübergabe auf verschiedenen Hosts unterstützt wird, müssen Sie sicherstellen, dass auf jedem Host derselbe Benutzername konfiguriert ist, oder Sie müssen einen SSH-Schlüssel verwenden, um die verschiedenen Benutzernamen für jeden Host zu authentifizieren.
Wechsel zu einzelnem Benutzernamen
Wenn die Hosts mehrere Benutzernamen unterstützen, können Sie Jobs unter verschiedenen Benutzernamen übergeben, Sie können jedoch "sudo" verwenden, um zu einem einzelnen einheitlichen Benutzernamen zu wechseln. Nur der einheitliche Benutzername kann zur Verwaltung der Liberty-Ressourcen verwendet werden. Dieser Benutzername ist häufig so konfiguriert, dass er die Anmeldung inaktiviert.
Verschiedene Benutzernamen
In einigen Konfigurationen können Sie jede Liberty-Ressource unter einem anderen Betriebssystembenutzernamen installieren. Beispielsweise können gemeinsam genutzte Ressourcen unter einem oder mehreren Benutzernamen installiert sein und global oder für eine bestimmte Betriebssystemgruppe im Lesezugriff verfügbar gemacht werden. Ressourcen, die nicht gemeinsam genutzt werden, können exklusiv für verschiedene Benutzernamen erstellt werden.

Indem Sie die Dateiberechtigungen des Stammverzeichnisses für jede Ressource festlegen, können Sie steuern, welche Benutzer Liberty-Ressourcen installieren dürfen. Wenn Sie die Berechtigung für das Verzeichnis so festlegen, dass nur ein Benutzer Schreibzugriff dafür hat, dann kann auch nur dieser Benutzer in das betreffende Verzeichnis installieren. Wenn Sie die Berechtigung für das Verzeichnis so festlegen, dass eine Gruppe von Benutzern Schreibzugriff dafür hat, dann können die Benutzer, die zu der betreffenden Gruppe gehören, Ressourcen unter dem Stammverzeichnis installieren. Wenn Sie für das Verzeichnis globalen Schreibzugriff festlegen, kann jeder Benutzer in das betreffende Verzeichnis installieren.

Während der Installation können Sie Dateiberechtigungen festlegen, die verhindern, dass andere Benutzer die Ressourcen modifizieren. Beispielsweise können Sie vorab ${WLP_WORKING_DIR}/project1 mit Dateiberechtigungen erstellen, die festlegen, dass nur ein bestimmter Benutzer oder eine bestimmte Gruppe Schreibzugriff dafür hat. Nachdem der Benutzer einen neuen Liberty installiert hat, z. B. "server1", können Sie ${WLP_WORKING_DIR}/project1/server1 so konfigurieren, dass kein anderer Benutzer Änderungen vornehmen darf.

Wenn mehrere Benutzer Zugriff auf Ressourcen haben, müssen Sie Variablen oder Jobparameter festlegen, die es einem Inventarjob ermöglichen, alle verfügbaren Ressourcen zu finden:

  • Sie müssen die Variable WLP_ADDITIONAL_DIRS definieren, damit alle relevanten Pfade nach Ressourcen durchsucht werden, oder
  • Sie müssen sicherstellen, dass der Benutzername, der zum Ausführen des Inventarjobs verwendet wird, Lesezugriff auf alle Ressourcen hat. Dazu müssen die Ressourcen mit globalem Lesezugriff erstellt werden, die Ressourcen müssen von der Betriebssystemgruppe lesbar sein, zu der der Benutzername gehört, oder der Rootbenutzername muss zum Ausführen des Inventarjobs verwendet werden.

Grundlegende Sicherheitskonfiguration

Der Verwaltungsagent und der Job-Manager unterstützen zwei verschiedene grundlegende Sicherheitskonfigurationen:

  • Eine gemeinsame Sicherheitsdomäne

    In dieser Konfiguration nutzen alle Zellen in der Topologie dieselbe Benutzerregistry und folglich dieselbe Sicherheitsdomäne. Dasselbe gilt für den Verwaltungsagenten und die zugehörigen registrierten Basisknoten sowie alle Job-Manager oder WebSphere Application Server Network Deployment-Zellen in der Topologie.

  • Verschiedene Sicherheitsdomäne

    In dieser Konfiguration sind alle Zellen mit unterschiedlichen Benutzerregistrys und folglich unterschiedlichen Sicherheitsdomänen konfiguriert.

Für die Verwaltungsagententopologie wird, wenn ein Benutzer sich am JMX-Connector-Port eines Verwaltungssubsystems anmeldet oder den registrierten Knoten aus der Verwaltungskonsole auswählt, die Berechtigungstabelle für den Basisknoten verwendet.

Beispielsweise hat Benutzer User1 die Administratorberechtigung für den ersten Basisknoten, nicht jedoch für den zweiten Knoten. Benutzer User2 hat die Berechtigung, den zweiten Knoten zu konfigurieren, ist jedoch nicht für den ersten Knoten berechtigt. Die folgende Abbildung einer Konfiguration mit einer einzigen Benutzerregistry veranschaulicht dieses Beispiel:

Konfiguration mit einer gemeinsamen Sicherheitsdomäne

Nehmen Sie weiter an, das User1 sich mit Benutzernamen und Kennwort als Benutzer mit Bedienungsberechtigung bei einem Job-Manager anmelden kann. Außerdem kann User1 sich als Benutzer mit Überwachungsberechtigung mit Benutzername und Kennwort anmelden. Die folgende Abbildung einer Konfiguration mit unterschiedlichen Benutzerregistrys veranschaulicht dieses Beispiel:

Konfiguration mit unterschiedlichen Sicherheitsdomänen

User1 hat zwar denselben Benutzernamen für den Job-Manager und den Deployment Manager, kann aber auch unterschiedliche Benutzernamen und Kennwörter verwenden.

Übertragung von Sicherheitsinformationen

Wenn das Produkt einen Job vom Job-Manager zum Verwaltungsagenten, Deployment Manager oder Hostcomputer überträgt, überträgt es auch Sicherheitsdaten über denjenigen, der den Job übergibt. Durch diese Übertragung wird der Benutzer bei der Jobausführung authentifiziert und berechtigt, während er den Job ausführt. Die folgenden Daten zur Benutzersicherheit können mit einem übertragenen Job weitergegeben werden:

  • Benutzername und Kennwort

    Bei der Jobübergabe gibt der Benutzer möglicherweise einen Benutzernamen und ein Kennwort an. Wenn der Job das Verwaltungssubsystem oder den Deployment Manager erreicht, erfolgt die Anmeldung über den Benutzernamen und das Kennwort.

    Beispiel: Wenn der Benutzer John eine Konfiguration mit einer einzigen Benutzerregistry verwendet und einen Job für den ersten Basisknoten übergibt, kann er seinen Benutzernamen und sein Kennwort als Teil des Jobs angeben. Normalerweise werden der Benutzername und das Kennwort für die Anmeldung am ersten Verwaltungssubsystem verwendet, und der Job wird ausgeführt. Wenn John nun einen Job für die Deployment-Manager-Zelle oder den zweiten Basisknoten übergibt, schlägt der Job fehl, weil John nicht berechtigt ist.

    Bei einer Konfiguration mit unterschiedlichen Benutzerregistrys kann John einen Job für die Deployment-Manager-Zelle übergeben und den Benutzernamen und das Kennwort für die Deployment-Manager-Zelle angeben. Wenn der Job den Deployment Manager erreicht, gelingt die Anmeldung, und der Job wird ausgeführt. Wenn John nun einen Job für die Basisknoten übergibt, wird der Zugriff verweigert, und der Job schlägt fehl.

  • Sicherheitstoken

    Wenn bei einem Job keinen Benutzernamen und kein Kennwort angibt, wird der Berechtigungsnachweis des Benutzers automatisch als Sicherheitstoken in der Jobdatenbank persistent gespeichert. Das Token enthält die Attribute zur Benutzersicherheit, einschließlich der Gruppen. Wird ein Job abgerufen, wird das Token verwendet, um die Authentifizierung und Berechtigung beim Verwaltungssubsystem oder beim Deployment Manager durchzuführen.

    Im Falle der Konfiguration mit einer einzigen Benutzerregistry kann John einen Job für den ersten Basisknoten übergeben, ohne den Benutzernamen und das Kennwort anzugeben. Der Job wird ausgeführt, weil Johns Berechtigungsnachweis automatisch als Sicherheitstoken an das Verwaltungssubsystem weitergeleitet und verwendet wird, um ihn für den Job zu authentifizieren und zu berechtigen. Wenn John nun einen Job für die Deployment-Manager-Zelle oder den zweiten Basisknoten übergibt, schlägt der Job fehl, weil sein Sicherheitstoken in diesen zwei Umgebungen nicht berechtigt ist.

    Bei der Konfiguration mit unterschiedlichen Benutzerregistrys lässt das Sicherheitstoken eines Benutzers nicht automatisch zu, dass der übergebene Job für das Verwaltungssubsystem oder den Deployment Manager ausgeführt wird. Um ein Benutzertoken für einen anderen Realm zu aktivieren, müssen Sie das Feature für mehrere Sicherheitsdomänen verwenden. Zuerst müssen Sie den Realm des Job-Managers als anerkannten Realm für die registrierten Basisknoten und die Deployment-Manager-Zelle einrichten. Außerdem müssen Sie die Zugriffs-ID des Benutzers aus dem Job-Manager in die lokale Berechtigungstabelle importieren und der Zugriffs-ID eine Rolle zuweisen. Dann kann der Benutzer einen Job übergeben, ohne den Benutzernamen und das Kennwort angeben zu müssen.

    Nehmen Sie an, John hat die Rolle "Bedienung" im Job-Manager, seine Zugriffs-ID wird jedoch mit der Berechtigung "Administration" in die Berechtigungstabelle für Verwaltungstasks des ersten Basisknotens importiert. Obwohl John in der Benutzerregistry des Basisknotens nicht aufgelistet ist, wird er durch die Übergabe des Sicherheitstokens und der Definition der Berechtigungstabelle für Verwaltungstasks als Administrator für den Basisknoten berechtigt. John kann einen Job für den ersten Basisknoten übergeben, ohne Benutzernamen oder Kennwort angeben zu müssen.

    Wenn John einen Job für den Deployment Manager übergibt, wird der Zugriff verweigert. Johns Sicherheitstoken stammt aus dem Realm des Job-Managers, und seine Zugriffs-ID wurde nicht für den Deployment Manager berechtigt. In diesem Fall kann der Administrator Johns Zugriffs-ID aus dem Job-Manager exportieren und in den Deployment Manager importieren. Oder John kann einen Job mit der Kombination aus Benutzernamen und Kennwort, die er für den Deployment Manager verwendet hat, übergeben, was ihm die Berechtigung gibt, Jobs mit der Rolle "Überwachung" auszuführen.

    Dasselbe Verfahren kommt zur Anwendung, wenn das differenzierte Sicherheitsfeature im Gebrauch ist. Sie müssen in der Berechtigungstabelle für eine neue Berechtigungsgruppe berechtigt sein. Die Berechtigungstabelle kann auch eine externe Zugriffs-ID enthalten.

Konfiguration mit heterogenen Registrys

In einer komplexeren Topologie, in der einige Zellen eine gemeinsame Benutzerregistry nutzen, andere aber nicht, gelten die folgenden Regeln:

  • Sie können bei der Jobübertragung immer einen Benutzernamen und ein Kennwort angeben, falls der Zielknoten oder der Deployment Manager Ihren Benutzernamen und Ihr Kennwort erkennt.
  • Wenn der Job-Manager und der Zielknoten oder der Deployment Manager dieselbe Benutzerregistry haben, erfordert die Jobübertragung keinen Benutzernamen und kein Kennwort. Sie müssen jedoch für den Zielknoten oder den Deployment Manager berechtigt sein.
  • Wenn der Job-Manager und der Zielknoten oder der Deployment Manager verschiedene Benutzerregistrys haben, anerkannte Realms eingerichtet werden und die Zugriffs-ID des Benutzers, der den Job übergibt, in die Berechtigungstabelle für Verwaltungstasks des Zielknotens oder des Deployment Manager importiert wird, muss bei der Jobübertragung kein Benutzernamen und kein Kennwort angegeben werden.

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=cagt_jobmgr_security
Dateiname:cagt_jobmgr_security.html