Themenspezifische Sicherheit

Über die themenspezifischen Sicherheit können Sie festlegen, welche Anwendungen in Ihrem Publish/Subscribe-System Zugriff auf die Informationen zu welchen Themen erhalten.

Sie können für jedes Thema, auf das Sie den Zugriff einschränken möchten, die Principals (Benutzer-IDs und Gruppen von Benutzer-IDs) angeben, die zu diesem Thema veröffentlichen bzw. sich für dieses Thema anmelden können. Darüber hinaus können Sie auch angeben, welche Principals eine persistente Nachrichtenübermittlung anfordern können.

Nachrichten zu Themen, die keiner Beschränkung unterliegen, können von jedem Principal veröffentlicht, subskribiert oder an jeden Principal persistent übermittelt werden.

Die themenspezifische Sicherheit wird über einen Benutzernamensserver verwaltet, der anhand der von Ihnen erstellten ACLs festlegt, welche Berechtigungen gelten.

Principals und der Benutzernamensserver

Der Benutzernamensserver in WebSphere Message Broker verwaltet für die Broker und den Konfigurationsmanager die im Netz definierten Principals für das Publish/Subscribe-System. Unter Windows wird diese Benutzerliste im Befehl mqsicreateusernameserver aus der Domäne abgerufen.

Durch Angabe des Warteschlangenmanagers des Benutzernamensservers in den Befehlen mqsicreatebroker und mqsicreateconfigmgr wird der Benutzernamensserver im Broker und im Konfigurationsmanager registriert.

Nachrichtenbroker in der Brokerdomäne arbeiten mit dem Benutzernamensserver zusammen, so dass alle Benutzer und Gruppen abgerufen werden können, auf deren Basis dann die Zugriffssteuerungslisten (die ACLs) erstellt werden, anhand derer die Publish/Subscribe-Anforderungen überprüft werden. Der Konfigurationsmanager kommuniziert mit dem Benutzernamensserver, um die Benutzer und Benutzergruppen in den ACLs anzuzeigen, die mit Hilfe des Editors für Themenhierarchien in der Ansicht 'Brokerverwaltung' der Workbench erstellt werden.

Zugriffssteuerungslisten (ACLs)

Über Zugriffssteuerungslisten (ACLs; Access Control Lists) wird die Berechtigung eines Principals festgelegt, ein bestimmtes Thema zu veröffentlichen, zu empfangn bzw. eine persistente Übermittlung von Veröffentlichungen zu diesem Thema zu erhalten.

Darüber hinaus können Sie über die ACL auch den Nachrichtenschutz festlegen, der für die einzelnen Themen gelten soll.

Diese Definitionen werden mit Hilfe des Editors für Themenhierarchien in der Ansicht 'Brokerverwaltung' der Workbench vorgenommen.

Die Zugriffssteuerung kann für jedes Thema einzeln festgelegt werden. Wenn für ein Thema keine ACL festgelegt wird, so wird die Zugriffssteuerung des übergeordneten Themas übernommen, die durch die hierarchische Struktur der Themenbaumstruktur vorgegeben ist. Wurde für keines der Themen unterhalb des Themas der höchsten Ebene eine ACL definiert, so wird die ACL des Themas der höchsten Ebene übernommen.

Alle im Benutzernamensserver registrierten Principals können auf diesen Weise einem Thema zugeordnet werden.

ACL-Konflikte auflösen

Wenn unter den Principals in der Brokerdomäne ein oder mehrere Benutzer zu mehr als einer Gruppe gehören, kann es bei den explizit festgelegten oder übernommenen ACLs zu Konflikten kommen. Solche Konflikte können anhand der folgenden Regeln aufgelöst werden:
  • Verfügt der Benutzer über eine explizite ACL für das gewünschte Thema, so hat diese immer Vorrang, und der Broker wird die Zulässigkeit der aktuellen Operation anhand dieser ACL überprüfen.
  • Verfügt der Benutzer über keine direkte ACL für das betreffende Thema, jedoch über explizite ACLs übergeordneter Benutzer in der Themenstruktur, so wird die ACL des nächsten übergeordneten Benutzers in der Themenbaumstruktur übernommen; der Broker wird die Zulässigkeit der aktuellen Operation anhand dieser ACL überprüfen.
  • Verfügt weder der Benutzer selbst noch ihm übergeordnete Benutzer über explizite ACLs für das gewünschte Thema, so versucht der Broker, die Zulässigkeit der aktuellen Operation anhand von Gruppen-ACLs zu überprüfen:
    • Gehört der Benutzer zu einer Gruppe mit einer expliziten Gruppen-ACL für das das betreffende Thema, so überprüft der Broker die Zulässigkeit der aktuellen Operation anhand dieser Gruppen-ACL.
    • Gehört der Benutzer zu keiner Gruppe mit einer expliziten Gruppen-ACL für das betreffende Thema, ist jedoch Mitglied einer Gruppe, die die expliziten ACLs übergeordneter Gruppen in der Themenstruktur übernehmen kann, so wird die ACL der nächsten übergeordneten Gruppe übernommen; der Broker wird die Zulässigkeit der aktuellen Operation anhand dieser ACL überprüfen.
    • Wenn die Benutzer-ID innerhalb einer bestimmten Ebene in der Themenbaumstruktur zu mehreren Gruppen mit einer expliziten ACL gehört, so wird eine Berechtigung erteilt, wenn die ACLs dies gestatten; andernfalls wird die Berechtigung verweigert.

ACLs können keinen Themen zugeordnet werden, die Platzhalterzeichen enthalten. Der Zugriff Ihrer Clientanwendung wird jedoch bei der Subskriptionsanmeldung korrekt aufgelöst, auch wenn im Thema der Anwendung ein Platzhalterzeichen enthalten ist.

PublicGroup-Berechtigungen

Zusätzlich zu den von Ihnen definierten Gruppen wird in WebSphere Message Broker implizit eine öffentliche Gruppe, PublicGroup bereitgestellt, der alle Benutzer automatisch angehören. Diese implizite Gruppe erleichtert die Definition von ACLs in einer Themenbaumstruktur. Diese Gruppe wird insbesondere für die Definition der ACL für Themen der höchsten Ebene herangezogen. Die Standardeinstellung der höchsten Themenebene gestattet der PublicGroup die Ausführung von Publish- und Subscribe-Operationen. Sie können die ACL über die Workbench anzeigen und ändern, aber nicht löschen. Diese ACL legt die Standardberechtigungen für die gesamte Themenbaumstruktur fest. Sie können für die PublicGroup überall dort in der Themenstruktur ACLs angeben, wo Berechtigungen für alle Benutzer definiert werden sollen.

Wenn Sie in der bestehenden Sicherheitsumgebung einen Principal namens Public definiert haben, sollte dieser nicht für die themenspezifische Sicherheit verwendet werden. Bei Angabe dieses Principals in einer ACL wird dieser der öffentlichen Gruppe (PublicGroup) gleichgesetzt und ermöglicht dadurch immer einen globalen Zugriff.

mqbrkrs-Berechtigungen

WebSphere Message Broker erteilt Mitgliedern der Gruppe mqbrkrs und der globalen Gruppe Domain mqbrkrs, falls notwendig, besondere Publish/Subscribe-Zugriffsberechtigungen.

Broker benötigen für die Ausführung interner Publish- und Subscribe-Operationen in Netzen mit Zugriffssteuerung spezielle Berechtigungen. Wird ein Broker in einem solchen Netz erstellt, müssen Sie eine Benutzer-ID angeben, die als Servicebenutzer-ID für den Broker zur Gruppe mqbrkrs gehört. Die Gruppe mqbrkrs verfügt über implizite Rechte, so dass ihre Mitglieder Nachrichten veröffentlichen und sich für Nachrichten anmelden und außerdem die persistente Übermittlung von Nachrichten auf der höchsten Themenebene ("") anfordern können. Alle anderen Themen übernehmen diese Berechtigungen. Sollten Sie mit Hilfe der Workbench eine ACL für die Gruppe mqbrkrs erstellen, wird diese ACL von WebSphere Message Broker ignoriert.

ACLs und systemspezifische Themen

Nachrichten für interne Publish- und Subscribe-Operationen werden innerhalb der gesamten Brokerdomäne für systemspezifische Themen verwendet, die mit der Zeichenfolge "$SYS" oder "$ISYS" beginnen.

Diese Themen dürfen nur von Mitgliedern der Gruppe 'mqbrkrs' veröffentlicht bzw. subskribiert werden, mit den folgenden beiden Ausnahmeszenarios:
  1. Wenn Sie Themen aus WebSphere MQ Publish/Subscribe migrieren, können ACLs für Themen konfiguriert werden, die mit "$SYS/STREAM" beginnen.
  2. Clients können Subskriptionen für Themen anmelden, die mit "$SYS" beginnen; das heißt also, dass Anwendungen, die eine Managementfunktion zur Verfügung stellen, sich beim Broker für verwaltungsspezifische Ereignisse anmelden können.

Für Themen, die mit "$ISYS" beginnen, dürfen keine ACLs eingerichtet werden. Sie können diese ACLs zwar erstellen, sie werden jedoch ignoriert.

Zugriffssteuerung für Themen setzen

Alle Benutzer mit einer ACL, die auf Sicherheit auf Objektebene beruht und dem Objekt 'Thema der höchsten Ebene' die vollständige Steuerungsberechtigung erteilt, können die ACLs definieren und bearbeiten, in denen festgelegt wird, welche Principals zu welchen Themen Nachrichten veröffentlichen bzw. subskribieren können. Durch ACLs kann auch die Übermittlung von persistenten Nachrichten eingeschränkt und die Ebene für den Nachrichtenschutz definiert werden.

Alle definierten Principals können einem beliebigen Thema zugeordnet werden; die Berechtigungen können wie in der folgenden Tabelle gesetzt werden:
Option Beschreibung:
Publish Über diese Option wird festgelegt, ob der Principal Nachrichten zu dem betreffenden Thema veröffentlichen kann.
Subscribe Über diese Option wird festgelegt, ob sich der Principal für Nachrichten zu dem betreffenden Thema anmelden kann.
Persistent Gibt an, ob der Principal Nachrichten persistent empfangen kann. Ist der Principal nicht dazu berechtigt, werden alle Nachrichten nicht-persistent gesendet. In jeder Subskription ist angegeben, ob der Subskribent eine persistente Übermittlung anfordert.
QoP Level Gibt die geltende Nachrichtenschutzstufe an. Zulässige Werte:
  • None (Keinen)
  • Channel Integrity (Kanalintegrität)
  • Message Integrity (Nachrichtenintegrität)
  • Encryptet (Verschlüsselt)
Standardwert ist 'None'.
Die Zugriffssteuerung für die persistente Nachrichtenübermittlung ist nicht identisch mit der Steuerung von Publish- und Subscribe-Operationen:
  • Clients ohne Publish-Berechtigung können keine Nachrichten veröffentlichen.
  • Clients ohne Subscribe-Berechtigung können keine Veröffentlichung empfangen.
  • Über die Zugriffssteuerung für persistente Übermittlung wird den Subskribenten nicht der Empfang der Nachricht, sondern der persistente Empfang von Nachrichten verweigert; die Subskribenten, denen eine persistente Übermittlung verweigert wird, empfangen zwar entsprechend der für sie definierten ACLs Nachrichten, allerdings werden diese Nachrichten nicht-persistent übertragen, unabhängig vom Persistenzstatus der ursprünglichen Nachricht.

Vererbung von Sicherheitsrichtlinien

In der Regel sind Themen in einer hierarchischen Baumstruktur angeordnet. Die ACL eines übergeordneten Themas kann von einigen oder allen ihm untergeordneten Themen übernommen werden, die über keine eigene ACL verfügen. Daher muss nicht unbedingt für jedes Thema eine eigene ACL definiert werden. Jedes Thema verfügt über eine ACL-Richtlinie, bei der es sich um die Richtlinie des übergeordneten Themas handelt. Verfügt keines der übergeordneten Themen in der Baumstruktur über eine eigene ACL, wird die ACL des Themas der höchsten Ebene übernommen.

In der Themenstruktur unten beispielsweise ist die höchste Themenebene nicht dargestellt; es wird aber davon ausgegangen, dass diese höchste Ebene über eine ACL für die öffentliche Gruppe (PublicGroup) verfügt, deren Mitglieder Nachrichten veröffentlichen und subskribieren sowie persistente Veröffentlichungen erhalten können. (Das Symbol "¬" steht für "nicht".)

Vererbung von ACLs in einer Themenbaumstruktur

Die Abbildung zeigt die folgende Themenbaumstruktur: Die höchste Ebene ist A, mit den Knoten B, K und P in der nächsten Ebene. Unterhalb von K gibt es weitere Ebenen mit den Knoten M und N.  Für einige Knoten in der Baumstruktur werden ACLs angezeigt. Knoten A verfügt über eine Publish-ACL, die 'joe' enthält; eine Subscribe-ACL, die 'PublicGroup' enthält, sowie eine ACL für persistente Nachrichtenübermittlung, die den Eintrag '¬PublicGroup' enthält. Knoten B verfügt über eine Publish-ACL mit dem Eintrag 'allen' sowie eine Subscribe-ACL mit den Einträgen 'HR' und '¬PublicGroup'. Eine ACL für die persistente Nachrichtenübermittlung ist für diesen Knoten nicht vorhanden. Knoten P verfügt über eine Publish-ACL mit dem Eintrag 'joe' sowie eine ACL für die persistente Nachrichtenübermittlung mit dem Eintrag 'joe'; es ist keine explizit definierte Subscribe-ACL vorhanden. Knoten N verfügt über eine Publish-ACL mit den Einträgen 'mary' und 'joe', eine Subscribe-ACL mit dem Eintrag 'nat' und einer ACL für persistente Nachrichtenübermittlung mit den Einträgen 'PublicGroup' und '¬nat'. Für die Knoten K und M sind keine expliziten ACLs definiert.
In der folgenden Tabelle sind die ACLs aufgeführt (einige davon 'geerbt'), die sich aus der angezeigten Themenbaumstruktur ergeben:
Thema Publisher Subskribenten Persistent
A nur joe jeder keiner
A/P nur joe jeder nur joe
A/K nur joe jeder keiner
A/K/M nur joe jeder keiner
A/K/M/N nur mary, joe jeder jeder außer nat
A/B allen, joe HR keiner

Dynamisch erstellte Themen

Themen, die nicht explizit durch den Systemadministrator erstellt werden, sondern beim Veröffentlichen oder Subskribieren von Nachrichten durch einen Client dynamisch erstellt werden, werden auf die gleiche Weise bearbeitet wie Themen, die durch den Systemadministrator erstellt wurden; es sind jedoch keine explizit definierten ACLs vorhanden. Das bedeutet, dass die ACLs für dynamisch erstellte Themen von dem nächsten vorhergehenden Thema in der Themenbaumstruktur übernommen werden, das über eine explizite Richtlinie verfügt. Falls keine expliziten ACLs vorhanden sind, ist es deshalb nicht erforderlich, in der Baumstruktur untergeordnete Themen zu definieren.

ACLs und Platzhalterthemen

In WebSphere Message Broker ist es nicht möglich, eine explizite Sicherheitsrichtlinie einem Platzhalterthema zuzuordnen. Beispielsweise können Sie eine ACL nicht dem Thema "A/+" zuordnen, das eine Hierarchie auf zwei Ebenen darstellt und "A/B", "A/K" sowie "A/P" enthält.

WebSphere Message Broker garantiert jedoch die korrekte Zugriffsvermittlung, wenn die Subskription einer Clientanwendung zu einem Platzhalterthema erfolgt.

Das Thema "A/+" kann beispielsweise keine Sicherheitsrichtlinie enthalten, die dem Thema explizit zugeordnet ist. Deshalb übernimmt "A/+" die Richtlinie von "A". Jeder Benutzer kann sich für "A/+" anmelden, da in der Subscribe-ACL alle Benutzer zugelassen sind.

Wenn eine Nachricht auf "A/P" oder "A/K" veröffentlicht wird, sendet der Broker die Nachricht an den Benutzer, der "A/+" subskribiert hat. Wenn eine Nachricht jedoch auf "A/B" veröffentlicht wird, wird diese Nachricht nur an die Subskribenten der Gruppe HR gesendet.

Wenn der Systemadministrator die Subscribe-ACL eines Themas ändert, das unter "A/+" fällt, so übernimmt der Broker bei der Nachrichtenzustellung die korrekte ACL. Bei der Subskription von Platzhalterthemen ist die Semantik zur Übermittlung von Nachrichten zu allen Themen enthalten, die mit dem Platzhalter übereinstimmen und für die der Subskribent über die Berechtigung zum Empfangen dieser Nachricht verfügt.

ACLs und Subskriptionslösungen

Der Broker setzt die Zugriffssteuerung durch das Thema der Nachricht um, die übermittelt werden soll. Nachrichten werden nur an Clients übermittelt, denen der Zugriff zum Subskribieren dieses Themas nicht explizit oder durch die Übernahme verweigert wurde. Da eine Subskription Platzhalter enthalten kann, kann beim Empfang der Subskription kein Vergleich hinsichtlich des Themen-Namespace und damit der Themen-ACLs erfolgen. Die Entscheidung zur Übermittlung einer Nachricht an einen Subskribenten erfolgt nur, wenn eine bestimmte Nachricht mit einem Thema vom Nachrichtenbroker verarbeitet wird.

Aktualisierung von Themen der ACL aktivieren

Die Aktualisierungen von Themen einer ACL sind erst aktiv, wenn sie in der gesamten Brokerdomäne von der WebSphere Message Broker-Workbench implementiert und aktiviert werden.

Sie müssen über eine ACL verfügen, die auf Sicherheit auf Objektebene beruht und die dem Objekt 'Thema der höchsten Ebene' die vollständige Steuerungsberechtigung erteilt.

Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
aq01203_