Verbundsicherheit

Sie können die Prinzipien der Verbundsicherheit im Liberty-Profil für in Übertragung befindliche Daten und ruhende Daten verwenden.

Zwei Hauptbereiche der Verbundsicherheit:
  • Konfiguration der Verwaltungsdomänensicherheit

    Bezieht sich auf die Datenübertragung, die Authentifizierung und die Berechtigung.

  • Sicherheit der Daten im Verbundrepository

    Bezieht sich auf ruhende Daten, Authentifizierung und Berechtigung.

Konfiguration der Verwaltungsdomänensicherheit
Die Konfiguration der Verwaltungsdomänensicherheit für Verbünde umfasst zwei Bereiche:
  • Benutzerdomäne

    Diese Domäne verwendet die rollenbasierte Java™-Sicherheit, die die Administratorrolle definiert. Sie kann den Benutzern in der konfigurierten Benutzerregistry zugeordnet werden.

  • Serverdomäne

    Diese Domäne verwendet die auf SSL-Zertifikaten basierende Authentifizierung.

Damit Benutzer auf die MBeans des Verbundcontrollers zugreifen können, müssen sie die Administratorrolle haben. Alle Verwaltungsaktionen, die über den Verbund ausgeführt werden, setzen voraus, dass dem Benutzer die Administratorrolle zugewiesen ist. Ausführliche Informationen hierzu finden Sie unter Sichere JMX-Verbindung zum Liberty-Profil konfigurieren.

Die Kommunikation zwischen Servern fällt in die Serverdomäne, und daher werden für die Kommunikation zwischen den Membern eines Verbundes keine Benutzeridentitäten oder Kennwörter verwendet. Jedes Member des Verbunds verfügt über eine eindeutige Identität, die den Hostnamen, das Benutzerverzeichnis und den Servernamen umfasst. Jedes Member im Verbund definiert seine Serverdomänenkonfiguration, die aus den Dateien serverIdentity.jks und collectiveTrust.jks besteht. Diese Dateien enthalten die SSL-Zertifikate, die erforderlich sind, um innerhalb des Verbunds eine sichere Kommunikation aufzubauen. Die HTTPS-Schlüsselkonfiguration muss spezifische Vertrauenseinstellungen (Trust) enthalten, die standardmäßig definiert werden.

Die SSL-Konfiguration der Serverdomäne kann angepasst werden, indem dem Keystore collectiveTrust.jks weitere Einträge für anerkannte Zertifikate hinzugefügt werden. Alle Vertrauenseinstellungen (Trust) werden kopiert, wenn ein Controller repliziert wird. Daher sollte die Anpassung von SSL auf den ursprünglichen Controller angewendet werden. Das Hinzufügen von Vertrauenseinstellungen (Trust) zum Keystore collectiveTrust.jks ist nur dann erforderlich, wenn nicht die HTTPS-Standardzertifikate verwendet werden. Wird die HTTPS-SSL-Konfiguration modifiziert, gelten folgende Zertifikatsregeln:
  • HTTPS-Vertrauenseinstellungen (Trust) müssen für alle Controller und Member im Verbund festgelegt werden. Wenn die HTTPS-SSL-Zertifikate modifiziert werden, müssen die folgenden Stammunterzeichner aus dem Verbundcontroller zum HTTPS-SSL-Truststore hinzugefügt werden.
    • Der Unterzeichner controllerRoot aus dem Keystore rootKeys.jks muss dem HTTPS-SSL-Truststore aller Verbundmember hinzugefügt werden.
    • Die Unterzeichner controllerRoot und memberRoot aus dem Keystore rootKeys.jks müssen dem HTTPS-SSL-Truststore aller Verbundcontroller hinzugefügt werden.
  • Jedes Member kann eine abgehende Verbindung zu einem Verbundcontroller herstellen. Der Keystore collectiveTrust.jks des Verbundcontrollers muss eine Zertifikatskette enthalten, in der das HTTPS-SSL-Zertifikat für jedes Member akzeptiert wird. Es wird dringend empfohlen, dass alle HTTPS-Zertifikate von einem Stammunterzeichner signiert werden, der anschließend in den Keystore collectiveTrust.jks aufgenommen werden kann. Werden einzelne SSL-Zertifikate verwendet, die keinen einheitlichen Stammunterzeichner haben, reicht dies zwar aus, damit eine Vertrauensbeziehung hergestellt wird, aber sie können nicht skaliert werden.
  • Jeder Controller kann eine abgehende Verbindung zu einem Verbundmember herstellen. Der Keystore collectiveTrust.jks des Verbundmembers muss eine Zertifikatskette enthalten, in der das HTTPS-SSL-Zertifikat für jeden Controller akzeptiert wird. Es wird dringend empfohlen, dass alle HTTPS-Zertifikate von einem Stammunterzeichner signiert werden, der anschließend in den Keystore collectiveTrust.jks aufgenommen werden kann. Werden einzelne SSL-Zertifikate verwendet, die keinen einheitlichen Stammunterzeichner haben, reicht dies zwar aus, damit eine Vertrauensbeziehung hergestellt wird, aber sie können nicht skaliert werden.
Für eine Kommunikation zwischen Servern muss die SSL-Authentifizierung unterstützt werden. Wird die HTTPS-SSL-Konfiguration angepasst, muss die SSL-Konfiguration die Festlegung clientAuthenticationSupported="true" enthalten. Es wird empfohlen, clientAuthenticationRequired="true" nicht zu verwenden, weil dies die Authentifizierung mit Benutzernamen und Kennwörter verhindert. Beispiel:
<!-- clientAuthenticationSupported festgelegt, um bidirektionale Anerkennung festzulegen -->
    <ssl id="defaultSSLConfig"
         keyStoreRef="defaultKeyStore"
         trustStoreRef="defaultTrustStore"
         clientAuthenticationSupported="true" />

Mit der MBean CollectiveRegistration können Member daran gehindert werden, Informationen im Verbundcontroller zu veröffentlichen. Die Methoden "disavow" und "avow" verhindern die Authentifizierung bzw. ermöglichen die Authentifizierung.

Sicherheit der Daten im Verbundrepository

Die Sicherheitsrichtlinie für Daten im Verbundrepository umfasst die Richtlinie für ruhende Daten, speziell die Richtlinie für den Zugriff auf den Inhalt des Verbundrepositorys.

Die aktuelle Sicherheitsrichtlinie für Verbunddaten stellt sich wie folgt dar:
  • Das System reserviert drei Knotennamen: sys.host.auth.info, sys.jmx.auth.info und sys.nologin. Diese Knoten befinden sich unter dem Repository-Namensbereich eines Hosts oder Servers. Für Knoten, die von Benutzern erstellt wurden, sollte nicht das Präfix sys. verwendet werden.
  • Auf die Knoten sys.host.auth.info und sys.jmx.auth.info ist kein Zugriff über die MBean möglich, um zu verhindern, dass die Berechtigungsnachweise des Systems offengelegt werden. Beim Zugriff auf die in diesen Knoten gespeicherten Daten wird eine Nullantwort zurückgegeben.
  • Ein Verbundmember darf nur seine eigenen Informationen im Repository ändern. Authentifizierte Benutzer mit Verwaltungsaufgaben haben unbeschränkten Zugriff auf die Informationen im Repository, mit Ausnahme der oben genannten Einschränkung. Authentifizierte Benutzer mit Verwaltungsaufgaben sind alle Benutzer, denen die Verwaltungsrolle zugewiesen wurde.

Weil sich das Verbundrepository letztlich auf der Platte befindet, müssen die Berechtigungseinstellungen für das Dateisystem für die verwendete Umgebung sicher sein. Es wird empfohlen, dass die Konfiguration des Verbundcontrollers für die Allgemeinheit nicht zugänglich ist, sondern dass nur der Benutzer Schreib-/Leseberechtigung und nur die Gruppe Leseberechtigung dafür hat, mit anderen Worten chmod 0640. Befolgen Sie alle bestehenden Sicherheitsrichtlinien Ihrer Organisation.


Symbol das den Typ des Artikels anzeigt. Konzeptartikel

Nutzungsbedingungen für Information Center | Feedback


Symbol für Zeitmarke Letzte Aktualisierung: 25.08.2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=cwlp_collective_sec
Dateiname: cwlp_collective_sec.html