Themensicherheit

Verwenden Sie die Themensicherheit, um festzulegen, welche Anwendungen in Ihrem Publish/Subscribe-System auf Informationen zu welchen Themen zugreifen können.

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. Sie können auch angeben, welche Principals die persistente Nachrichtenübermittlung anfordern können.

Jeder Principal kann Nachrichten veröffentlichen, subskribieren und die persistente Nachrichtenübermittlung für jedes Thema anfordern, auf das der Zugriff nicht explizit eingeschränkt wurde.

Die Themensicherheit wird von einem Benutzernamensserver verwaltet, der mit Hilfe der von Ihnen erstellten Zugriffssteuerungslisten über die Berechtigungen entscheidet.

Principals und der Benutzernamensserver

In WebSphere Message Broker verwaltet der Benutzernamensserver die Principal-Gruppen, die in Ihrem Netz bereits definiert sind. Er tut dies im Auftrag des Brokers und des Konfigurationsmanagers für die Verwendung in Publish/Subscribe. Unter Windows wird die Liste der Benutzer aus der Domäne verwendet, die im Befehl mqsicreateusernameserver angegeben wurde.

Der Benutzernamensserver wird für den Broker und den Konfigurationsmanager durch die Angabe des Warteschlangenmanagers von Benutzernamensserver in den Befehlen mqsicreatebroker und mqsicreateconfigmgr definiert.

Die Nachrichtenbroker in der Brokerdomäne kommunizieren mit dem Benutzernamensserver, um alle Benutzer und Gruppen abzurufen, aus denen die Zugriffssteuerungslisten (ACL; Access Control List) erstellt sind und mit denen die Publish/Subscribe-Anforderungen verglichen 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

Mit Hilfe von Zugriffssteuerungslisten (Access Control List, ACL) werden für jeden Principal die Berechtigungen zum Veröffentlichen und Subskribieren von Themen oder zur Anforderung der persistenten Nachrichtenübermittlung einer Veröffentlichung zu diesem Thema definiert.

Sie können mit Hilfe von ACLs auch die Ebene des Nachrichtenschutzes definieren, die Sie für jedes Thema anwenden möchten.

Geben Sie diese Definitionen in der Ansicht 'Brokerverwaltung' der Workbench mit Hilfe des Editors für die Themenhierarchie an.

Die Zugriffssteuerung kann für jedes einzelne Thema explizit festgelegt werden. Wenn für ein Thema jedoch keine explizite ACL definiert ist, wird die Zugriffssteuerung von einem vorhergegangenen oder übergeordneten Thema übernommen (gemäß der Definition in der hierarchischen Struktur der Themenbaumstruktur). Wenn in der Hierarchie bis zum Themenstamm keine explizite ACL vorhanden ist, übernimmt das Thema die Zugriffssteuerungsliste des Themenstamms.

Jeder definierte Principal im Benutzernamensserver kann auf diese Weise einem Thema zugeordnet werden.

Konflikte in der Zugriffssteuerungsliste lösen

Wenn in den Principals in Ihrer Brokerdomäne ein oder mehrere Broker in mehreren Gruppen enthalten sind, kann es zu einem Konflikt der expliziten oder übernommenen Werte der Zugriffssteuerungsliste kommen. In den folgenden Regeln wird gezeigt, wie ein Konflikt gelöst werden kann:
  • Die explizite Benutzer-ACL zu einem vom Benutzer gewünschten Thema hat immer Priorität, und der Broker prüft die laufende Operation auf Grundlage dieser ACL.
  • Wenn der Benutzer über keine explizite Benutzer-ACL zu dem von ihm gewünschten Thema verfügt, aber explizite Benutzer-ACLs für ein vorhergehendes Thema in der Themenbaumstruktur vorhanden sind, hat die nächste vorhergehende ACL dieses Benutzers Priorität, und der Broker prüft die laufende Operation auf Grundlage dieser ACL.
  • Wenn es keine expliziten Benutzer-ACLs zu dem vom Benutzer gewünschten Thema oder einem vorhergehenden Thema gibt, versucht der Broker, die laufende Operation auf Grundlage von Gruppen-ACLs zu prüfen:
    • Wenn der Benutzer Mitglied einer Gruppe mit einer expliziten Gruppen-ACL zum gewünschten Thema ist, prüft der Broker die laufende Operation auf Grundlage dieser Gruppen-ACL.
    • Wenn der Benutzer kein Mitglied einer Gruppe mit einer expliziten Gruppen-ACL zum gewünschten Thema ist, aber Mitglied einer Gruppe mit expliziten Gruppen-ACLs für ein vorhergehendes Thema in der Themenbaumstruktur, hat die nächste vorhergehende ACL Priorität, und der Broker prüft die laufende Operation auf Grundlage dieser ACL.
    • Wenn die Benutzer-ID auf einer bestimmten Ebene der Themenbaumstruktur in mehreren Gruppen mit einer expliziten ACL enthalten ist, wird die Berechtigung erteilt, wenn eine der Angaben positiv ist, sonst 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. In dieser impliziten Gruppe werden die Angaben der ACLs in einer Themenbaumstruktur vereinfacht. Diese Gruppe wird vor allem in den Bestimmungen der ACL für den Themenstamm verwendet. 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 in Ihrer vorhandenen Sicherheitsumgebung ein Principal mit der Bezeichnung Public definiert ist, können Sie diesen nicht für die Themensicherheit verwenden. 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.

Für Broker sind spezielle Berechtigungen zur Ausführung interner Publish/Subscribe-Operationen in Netzen mit Zugriffssteuerung erforderlich. 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. Diese Berechtigungen werden von allen anderen Themen übernommen. Sollten Sie mit Hilfe der Workbench eine ACL für die Gruppe mqbrkrs erstellen, wird diese ACL von WebSphere Message Broker ignoriert.

ACLs und Systemthemen

Nachrichten für interne Publish/Subscribe-Operationen werden in der gesamten Brokerdomäne mit Hilfe von Systemthemen veröffentlicht, die mit den Zeichenfolgen "$SYS" und "$ISYS" beginnen. Diese Themen dürfen nur von Mitgliedern der Gruppe mqbrkrs veröffentlicht bzw. subskribiert werden, mit den folgenden beiden Ausnahmen:
  1. Wenn Sie Themen aus dem WebSphere MQ Publish/Subscribe migrieren, können Sie ACLs zu Themen konfigurieren, die mit der Zeichenfolge "$SYS/STREAM" beginnen.
  2. Clients können Themen subskribieren, die mit der Zeichenfolge "$SYS" beginnen; d. h., dass Anwendungen mit einer Managementfunktion beim Broker für Verwaltungsereignisse subskribiert werden können.

Konfigurieren Sie keine ACLs für Themen, die mit der Zeichenfolge "$ISYS" beginnen. Sie können diese ACLs zwar erstellen, sie werden jedoch ignoriert.

Zugriffssteuerung für Themen festlegen

Alle Mitglieder der Gruppe mqbrtpic bzw. Benutzer/Mitglieder einer Gruppe mit einer ACL, die auf Sicherheit auf Objektebene beruht und mindestens die Implementierungsberechtigung für das Objekt 'Thema der höchsten Ebene' erteilt, können 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. Definierte Principals können jedem Thema zugeordnet werden. Die Berechtigungen, die dafür festgelegt werden können, werden in der folgenden Tabelle gezeigt:
Option Beschreibung
Veröffentlichen Ermöglicht oder verweigert dem Principal das Veröffentlichen von Nachrichten zu diesem Thema.
Subskription einrichten Ermöglicht oder verweigert dem Principal das Subskribieren von Nachrichten zu diesem Thema.
Persistent Gibt an, ob der Principal persistent Nachrichten erhalten kann. Wenn der Principal nicht über die entsprechende Berechtigung verfügt, werden die Nachrichten nicht persistent gesendet. In jeder einzelnen Subskription wird angezeigt, ob für den Subskribenten persistente Nachrichten erforderlich sind.
Zugriffsschutzstufe Gibt die zwingend vorgeschriebene Ebene des Nachrichtenschutzes an. Sie können einen der folgenden vier Werte auswählen:
  • Keine
  • Kanalintegrität
  • Nachrichtenintegrität
  • Verschlüsselt
Der Standardwert ist 'Keine'.
Das Verhalten der persistenten Zugriffssteuerung stimmt nicht mit der Publish/Subscribe-Steuerung überein:
  • Clients, denen der Zugriff 'Veröffentlichen' verweigert wurde, können keine Nachrichten veröffentlichen.
  • Clients, denen der Zugriff 'Subskription einreichen' verweigert wurde, können keine Veröffentlichungen empfangen.
  • Durch die persistente Zugriffssteuerung wird nicht die Übermittlung von Nachrichten an Subskribenten, sondern die persistente Übermittlung verweigert. Deshalb erhalten Subskribenten immer Nachrichten gemäß der Zugriffssteuerung für die Subskription, wobei die Nachrichten aber nicht persistent gesendet werden, unabhängig davon, ob die ursprüngliche Nachricht persistent war.

Übernahme von Sicherheitsrichtlinien

Normalerweise werden Themen in hierarchischen Baumstrukturen angeordnet. Die ACL eines übergeordneten Themas kann von einigen oder von allen untergeordneten Themen übernommen werden, die über keine explizite ACL verfügen. Es ist deshalb nicht erforderlich, dass jedem Thema eine explizite ACL zugeordnet ist. Jedes Thema verfügt über die ACL-Richtlinie des übergeordneten Themas. Wenn keines der übergeordneten Themen bis hinauf zum Thema der höchsten Ebene über eine explizite ACL verfügt, übernimmt dieses Thema die ACL des Themas der höchsten Ebene.

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 "¬" bedeutet "nicht".)

ACLs in einer Themenbaumstruktur übernehmen


In der Abbildung wird eine Themenbaumstruktur mit der folgenden Struktur gezeigt. A ist die Ausgangsebene, und B, K und P befinden sich auf 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 eine 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 werden die in einigen Fällen übernommenen ACLs gezeigt, die sich aus der in der Abbildung gezeigten 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. Um ACLs implementieren zu können, müssen Sie zur Gruppe 'mqbrops' gehören oder Benutzer bzw. Mitglied einer Gruppe mit einer ACL sein, die auf Sicherheit auf Objektebene beruht und mindestens die Berechtigung zur Implementierung für das Objekt 'Thema der höchsten Ebene' erteilt.

Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2005 Letzte Aktualisierung: Nov 17, 2005
aq01203_