Neues Upgrade für Apache RocketMQ ACL 2.0

[Live-Übertragungsvorschau] Werden große Models Programmierer ersetzen? "

Autor: Tu Zhong

Einführung

Als beliebte verteilte Messaging-Middleware wird RocketMQ häufig in verschiedenen großen verteilten Systemen und Mikrodiensten eingesetzt. Es spielt eine wichtige Rolle bei der asynchronen Kommunikation, Systementkopplung, Peak-Shaving und Valley-Filling sowie Nachrichtenbenachrichtigung. Mit der Weiterentwicklung der Technologie und der Ausweitung des Unternehmensumfangs sind sicherheitsbezogene Herausforderungen immer wichtiger geworden, und die Zugriffskontrolle von Messaging-Systemen ist besonders wichtig geworden. Allerdings ist die bestehende ACL 1.0-Version von RocketMQ den zukünftigen Entwicklungen nicht mehr gewachsen. Aus diesem Grund haben wir die aktualisierte Version von RocketMQ ACL 2.0 auf den Markt gebracht, um die Sicherheit von RocketMQ-Daten weiter zu verbessern. In diesem Artikel werden die neuen Funktionen, Arbeitsprinzipien und zugehörigen Konfigurationen und Praktiken von RocketMQ ACL 2.0 vorgestellt.

Verbesserter Hintergrund

ACL 1,0 Schmerzpunkte

Der Authentifizierungs- und Autorisierungsprozess von RocketMQ ACL 1.0 ist in der Abbildung oben dargestellt. Während der Verwendung gibt es die folgenden Schwachstellen:

IP-Whitelisting zur Umgehung der Zugriffskontrolle : In standardmäßigen Sicherheitspraktiken wird IP-Whitelisting häufig verwendet, um Clients daran zu hindern, nur über bestimmte IPs oder IP-Bereiche auf Ressourcen zuzugreifen. In ACL 1.0 wird die IP-Whitelist jedoch ungewöhnlicherweise als Mittel zur Umgehung der Authentifizierungsüberprüfung verwendet, was von der Sicherheitsabsicht der Standardpraxis abweicht. Diese Designabweichung kann zu potenziellen Sicherheitsrisiken führen, insbesondere in öffentlichen Netzwerkszenarien, in denen mehrere Clients dieselbe IP verwenden, was dazu führen kann, dass nicht autorisierte IP-Adressen die normalen Zugriffskontrollprüfungen für den Zugriff auf die Clusterdaten umgehen.

Fehlende detaillierte Steuerung der Verwaltungs-APIs : RocketMQ bietet mehr als 130 Verwaltungs- und Steuerungs-APIs, die die Clusterkonfiguration, die Metadatenverwaltung von Themen und Gruppen sowie Vorgänge wie Nachrichtenabfragen und Site-Reset unterstützen. Diese Vorgänge beinhalten die Verarbeitung sensibler Daten und beeinträchtigen die Stabilität des Systems. Daher ist es von entscheidender Bedeutung, den Umfang der zugänglichen APIs und Daten basierend auf unterschiedlichen Benutzerrollen oder Verantwortlichkeiten genau zu definieren. ACL 1.0 unterstützt jedoch nur 9 APIs, einschließlich Topic, Gruppenmetadaten und Broker-Konfiguration. Die verbleibenden APIs können von Angreifern verwendet werden, um das System anzugreifen und vertrauliche Daten zu stehlen. Darüber hinaus erfordert die Implementierung der Zugriffskontrolle für so viele Verwaltungs-APIs viel Codierungsarbeit mit dem vorhandenen Design und erhöht das Risiko, dass beim Hinzufügen neuer APIs Dinge übersehen werden.

Fehlende Zugriffskontrolle zwischen Clusterkomponenten : Die RocketMQ-Architektur umfasst mehrere Schlüsselkomponenten wie NameServer, Broker-Master-Slave-Knoten und Proxy. Derzeit fehlt der Mechanismus zur Überprüfung der Schlüsselberechtigungen für den gegenseitigen Zugriff zwischen diesen Komponenten. Sobald Sie also einen Broker-Slave-Knoten oder eine Proxy-Komponente außerhalb des Clusters erstellen, können Sie den vorhandenen Sicherheitsmechanismus umgehen und auf sensible Daten im Cluster zugreifen. Dies wird zweifellos große Auswirkungen auf die Datensicherheit des Systems und die Stabilität haben der Cluster-Bedrohungen.

Eigenschaften und Prinzipien

Neue Funktionen von ACL 2.0

RocketMQ ACL 2.0 löst die Probleme in ACL 1.0 und bringt außerdem sechs wichtige neue Funktionen mit:

Feine API-Ressourcenberechtigungsdefinition : ACL 2.0 definiert alle Ressourcen im RocketMQ-System, einschließlich Cluster, Namespaces, Themen und Verbrauchergruppen, um eine unabhängige Zugriffskontrolle für alle Arten von Ressourcen zu erreichen. Darüber hinaus werden alle APIs in den Bereich der Berechtigungskontrolle einbezogen, die verschiedene Vorgänge abdeckt, einschließlich Senden und Empfangen von Nachrichten, Clusterverwaltung, Metadaten usw., wodurch sichergestellt wird, dass bei allen Vorgängen aller Ressourcen eine strenge Berechtigungskontrolle angewendet wird.

Mehrere Matching-Modi für autorisierte Ressourcen : In einer Cluster-Umgebung mit vielen Ressourcen führt die Autorisierung jeder Ressource einzeln zu komplizierten Konfigurationsprozessen und Verwaltungsaufwand. Daher führt ACL 2.0 drei flexible Matching-Modi ein: exakte Übereinstimmung, Präfix-Übereinstimmung und Wildcard-Übereinstimmung. Mit diesen Modi können Benutzer schnell einheitliche Einstellungen basierend auf den Namenskonventionen und Strukturmerkmalen von Ressourcen vornehmen, Berechtigungsverwaltungsvorgänge vereinfachen und die Konfigurationseffizienz verbessern.

Unterstützt die Zugriffskontrolle zwischen Clusterkomponenten : Da alle Ressourcentypen und API-Operationen im Zugriffskontrollsystem enthalten sind, unterliegen Verbindungen und Zugriffe zwischen Komponenten innerhalb des Clusters auch der Berechtigungskontrolle, einschließlich der Wahl des Leaders zwischen Broker-Master und -Slave sowie der Datenreplikation. Prozess sowie Datenzugriff vom Proxy zum Broker usw. Dadurch können potenzielle Datenlecks und Risiken für die Systemstabilität wirksam vermieden und die Sicherheit und Zuverlässigkeit des gesamten Clusters verbessert werden.

Trennung von Benutzerauthentifizierung und Autoritätsüberprüfung : Durch die Entkopplung der beiden Schlüsselmodule Authentifizierung und Autorisierung kann das System flexible Optionen wie „nur Authentifizierung ohne Authentifizierung“ bereitstellen, um sich an die Anforderungen verschiedener Szenarien anzupassen. Darüber hinaus können sich die beiden Komponenten unabhängig voneinander weiterentwickeln und so verschiedene Authentifizierungsmethoden und erweiterte Authentifizierungsmethoden hervorbringen.

Balance zwischen Sicherheit und Leistung : Wenn ACL aktiviert ist, muss jede Anfrage vom Client einen vollständigen Authentifizierungs- und Autorisierungsprozess durchlaufen. Dies gewährleistet die Systemsicherheit, führt aber auch zu Leistungseinbußen. In ACL 2.0 werden zustandslose Authentifizierungs- und Autorisierungsstrategien sowie zustandsbehaftete Authentifizierungs- und Autorisierungsstrategien bereitgestellt, um zwei unterschiedliche Sicherheits- und Leistungsanforderungen zu erfüllen: extreme Sicherheitsanforderungen und kontrollierbare Sicherheit, aber Leistungspriorität.

Flexibler und erweiterbarer Plug-in-Mechanismus : Auf dem aktuellen Markt gibt es mehrere Implementierungen von Authentifizierungsmethoden, und für Autorisierungsmethoden gelten auch Anpassungsanforderungen für verschiedene Szenarien. Daher hat ACL 2.0 ein Plug-in-Framework entwickelt, um Schnittstellen auf verschiedenen Ebenen zu definieren und zu abstrahieren, um zukünftige Erweiterungen der Authentifizierung und Autorisierung zu unterstützen und es Benutzern zu ermöglichen, entsprechende Lösungen entsprechend ihren eigenen Geschäftsanforderungen anzupassen und zu implementieren.

Zugangskontrollmodell

Rollenbasierte Zugriffskontrolle (RBAC) und attributbasierte Zugriffskontrolle (ABAC) sind die beiden Hauptmethoden im Zugriffskontrollsystem. RocketMQ ACL 2.0 integriert diese beiden Methoden, um ein flexibleres und leistungsfähigeres Zugangskontrollsystem zu schaffen.

RBAC ist ein rollenbasiertes Zugriffskontrollmodell, das Berechtigungen über Rollen zuweist. RocketMQ ACL 2.0 unterteilt Benutzerrollen in Superbenutzer (Super) und normale Benutzer (Normalbenutzer). Normalen Benutzern müssen vor dem Zugriff auf Ressourcen entsprechende Berechtigungen erteilt werden, was für den bedarfsgesteuerten Zugriff auf Ressourcen in Geschäftsszenarien geeignet ist.

ABAC ist ein attributbasiertes Zugriffskontrollmodell, das Zugriffskontrollrichtlinien durch mehrdimensionale Attribute wie Benutzer, Ressourcen, Umgebungen, Vorgänge usw. ausdrückt. RocketMQ ACL 2.0 bietet diesen flexiblen Zugriffskontrollmechanismus für normale Benutzer. Helfen Sie Administratoren bei der Implementierung einer verfeinerten Zugriffskontrolle auf Ressourcen basierend auf Geschäftsanforderungen, Benutzerverantwortlichkeiten und anderen Faktoren.

Im Sicherheitssystem spielen Authentifizierung und Autorisierung jeweils unterschiedliche Rollen. RocetMQ ACL 2.0 trennt Authentifizierung und Autorisierung in Module. Dies stellt sicher, dass beide Komponenten ihre Aufgaben erfüllen und reduziert die Komplexität des Systems. Authentifizierungsdienste dienen der Überprüfung der Legitimität von Benutzeridentitäten, während sich Autorisierungsdienste auf die Verwaltung von Benutzerberechtigungen und Zugriffskontrolle konzentrieren. Diese Aufteilung erleichtert nicht nur die Verwaltung, Wartung und Erweiterung des Codes, sondern bietet Benutzern auch Flexibilität bei der Verwendung. Je nach Bedarf können Benutzer Authentifizierungs- oder Autorisierungsdienste separat oder beide gleichzeitig aktivieren. Dadurch kann RocketMQ ACL die schnelle Bereitstellung einfacher Szenarien erfüllen und sich an strenge Sicherheitsanforderungen in komplexen Umgebungen anpassen.

Authentifizierung

Bei der Authentifizierung handelt es sich um einen Sicherheitsmechanismus, mit dem die Authentizität der Person überprüft werden soll, die die Zugriffsanfrage initiiert. Es wird verwendet, um sicherzustellen, dass nur legitime authentifizierte Benutzer oder Entitäten auf geschützte Ressourcen zugreifen oder bestimmte Vorgänge ausführen können. Einfach ausgedrückt ist die Authentifizierung die Antwort auf die Frage „Wer sind Sie?“, bevor auf eine Ressource oder einen Dienst zugegriffen wird.

Die RocketMQ ACL 2.0-Version behält den gleichen Authentifizierungsmechanismus wie ACL 1.0 bei, d. h. eine AK/SK-basierte Authentifizierungsmethode. Diese Methode verwendet hauptsächlich symmetrische Verschlüsselungstechnologie, um die Identität des Clients zu überprüfen und sicherzustellen, dass vertrauliche Authentifizierungsinformationen (z. B. Passwörter) nicht im Klartext im Netzwerk übertragen werden, wodurch die allgemeine Authentifizierungssicherheit verbessert wird.

Agentenmodell

Um die Zugriffskontrolle und Berechtigungsverwaltung des RocketMQ-Systems zu verbessern, hat ACL 2.0 die folgenden Verbesserungen und Erweiterungen am Hauptmodell vorgenommen:

1. Abstraktion eines einheitlichen Subjektmodells: Um die Zugriffskontrolle und Berechtigungsverwaltung verschiedener Entitäten zu realisieren, ist eine einheitliche Subjektschnittstelle so konzipiert, dass mehrere Instanzen im System als Subjekte für den Ressourcenzugriff dienen können. Als eines der Subjekte, die auf Ressourcen zugreifen, implementiert der Benutzer die Schnittstelle des Subjekts gemäß diesem Modell. Dies bietet Erweiterungsmöglichkeiten für die Berechtigungsanpassung an neue Entitätstypen in der Zukunft.

2. Rollenklassifizierung und Berechtigungserteilung:

Superuser : Um den Verwaltungsprozess zu vereinfachen, werden dem Superuser automatisch alle Berechtigungen erteilt, ohne dass eine separate Konfiguration erforderlich ist, wodurch die Systeminitialisierung und die tägliche Betriebs- und Wartungsverwaltung vereinfacht werden.
Normale Benutzer : Die Berechtigungen normaler Benutzer erfordern eine explizite Autorisierung. ACL 2.0 bietet relevante Berechtigungsverwaltungstools, die normalen Benutzern basierend auf den Richtlinien und Sicherheitsanforderungen der Organisation entsprechende Berechtigungen erteilen können.

3. Unterstützung der Benutzerstatusverwaltung: Um mögliche Sicherheitsrisiken wie den Verlust von Benutzerkennwörtern zu bewältigen, bietet ACL 2.0 Funktionen zum Aktivieren und Deaktivieren von Benutzern. Bei einem Sicherheitsvorfall kann der Benutzerstatus deaktiviert werden, um das Bluten schnell zu stoppen und so illegalen Zugriff zu verhindern.

Zertifizierungsprozess

Kundenprozess:

Beim Erstellen einer RPC-Anfrage prüft der Client, ob Benutzername und Passwort festgelegt sind. Wenn nicht konfiguriert, sendet der Client die Anfrage direkt.
Sofern konfiguriert, wird der voreingestellte Verschlüsselungsalgorithmus verwendet, um die Anforderungsparameter zu verschlüsseln und die entsprechende digitale Signatur (Signatur) zu generieren.
Hängen Sie den Benutzernamen und die Signatur an die Anfrage an und senden Sie sie zur Authentifizierung an den Server.

Serverprozess:

Nach Erhalt der Anfrage prüft der Server zunächst, ob die Authentifizierung aktiviert ist. Wenn sie nicht aktiviert ist, wird sie nicht überprüft. Wenn sie aktiviert ist, wird mit dem nächsten Schritt fortgefahren.
Der Server analysiert und stellt die Parameter im Zusammenhang mit der Anforderungsauthentifizierung zusammen und erhält Informationen, einschließlich Benutzername und Signatur.
Fragen Sie benutzerbezogene Informationen in der lokalen Datenbank über den Benutzernamen ab. Wenn der Benutzer nicht vorhanden ist, wird die Verarbeitung als „Keine“ zurückgegeben. Fahren Sie dann mit dem nächsten Schritt fort.
Besorgen Sie sich das Benutzerkennwort, verschlüsseln Sie die Anforderung mit demselben Verschlüsselungsalgorithmus und vergleichen Sie sie mit der vom Client übergebenen Signatur. Wenn beide konsistent sind, ist die Authentifizierung erfolgreich.

Genehmigung

Kernidee

Bei der Autorisierung handelt es sich um einen Sicherheitsmechanismus, mit dem festgestellt werden soll, ob ein Zugriffsanforderer die Berechtigung hat, eine bestimmte Ressource zu bearbeiten. Kurz gesagt geht es bei der Autorisierung um die Beantwortung der Frage „Wer hat welche Vorgänge auf welchen Ressourcen unter welchen Umständen durchgeführt“, bevor auf die Ressourcen zugegriffen wird?

Basierend auf dem „Attribute-based Access Control (ABAC)“-Modell deckt RocketMQ ACL 2.0 die folgende Reihe von Kernkonzepten ab. Bei der Systemimplementierung werden die folgenden Konzepte als Leitfaden verwendet, um den Entwurf und die Implementierung des gesamten Rechteverwaltungs- und Autorisierungsmechanismus abzuschließen.

Berechtigungsmodell

Das Kernkonzept des attributbasierten Zugriffskontrollmodells (ABAC), ACL 2.0, hat das Berechtigungsmodell sorgfältig entworfen. Die wichtigsten Punkte sind wie folgt:

Abwärtskompatible Berechtigungsrichtlinie : Standardmäßig gleicht ACL 2.0 nur benutzerdefinierte Berechtigungen ab und prüft sie. Wenn keine Übereinstimmung gefunden wird, wird davon ausgegangen, dass keine Berechtigung zum Zugriff auf die Ressource vorliegt. Wenn man jedoch bedenkt, dass es in ACL 1.0 eine Standard-Berechtigungseinstellung gibt, die die Standardbestimmung von „kein Berechtigungszugriff“ und „mit Berechtigungszugriff“ für nicht übereinstimmende Ressourcen ermöglicht. Daher haben wir die Kompatibilität mit der Standard-Berechtigungsrichtlinie implementiert, um eine nahtlose Migration von ACL 1.0 auf ACL 2.0 sicherzustellen.

Flexibler Ressourcenabgleichsmodus : In Bezug auf Ressourcentypen unterstützt ACL 2.0 Cluster, Namespace, Thema, Verbrauchergruppe und andere Typen, die zur Steuerung des Zugriffs auf verschiedene Ressourcentypen verwendet werden. In Bezug auf Ressourcennamen werden drei Modi des exakten Abgleichs (LITERAL), des Präfixabgleichs (PREFIXED) und des Platzhalterabgleichs (ANY) eingeführt, um Benutzern das schnelle Festlegen einheitlicher Zugriffsregeln basierend auf den Benennungsspezifikationen und -strukturen von Ressourcen zu erleichtern und Berechtigungen zu vereinfachen . verwalten.

Feine Ressourcenoperationstypen : In Bezug auf Nachrichtensende- und Verbrauchsschnittstellen werden sie als PUB- bzw. SUB-Operationen definiert. In Bezug auf Cluster- und Ressourcenverwaltungsschnittstellen sind fünf Operationen definiert: CREATE, UPDATE, DELETE, LIST und GET. Durch diese Verfeinerung der Operationstypen kann es Benutzern helfen, das Verständnis und die Konfiguration von Operationen zu vereinfachen, ohne sich um spezifische Schnittstellendefinitionen auf der Ebene der Ressourcenoperationen kümmern zu müssen.

Solide Zugriffsumgebungsüberprüfung : In Bezug auf die Umgebung für die Zugriffsanforderung fügt ACL 2.0 eine Überprüfung der IP-Quelle der Clientanforderung hinzu. Diese Überprüfung wird auf der Ebene jeder Ressource gesteuert und kann jede Ressource genau steuern. Die IP-Quelle kann eine bestimmte IP-Adresse oder ein IP-Segment sein, um die IP-Zugriffskontrolle in unterschiedlichen Granularitäten zu erfüllen und eine solide Verteidigungslinie für die Systemsicherheit hinzuzufügen.

Autorisierungsprozess

Kundenprozess:

Wenn der Client eine RPC-Anfrage erstellt, erstellt er die Schnittstelleneingabeparameter für diesen Aufruf, und die Schnittstelle entspricht der Operationsdefinition hinter den Berechtigungen.
Der Client legt die Ressourceninformationen für diesen Besuch in den Schnittstelleneingabeparametern fest und übergibt dann Parameter wie Benutzer und Ressource an den Server.

Serverprozess:

Nach Erhalt der Anfrage prüft der Server zunächst, ob die Autorisierung aktiviert ist. Wenn sie nicht aktiviert ist, geht sie zum nächsten Schritt über.
Der Server analysiert und stellt die autorisierungsbezogenen Parameter in der Anfrage zusammen. Zu diesen Daten gehören Benutzerinformationen, aufgerufene Ressourcen, durchgeführte Vorgänge und die angeforderte Umgebung.
Fragen Sie benutzerbezogene Informationen im lokalen Datenspeicher über den Benutzernamen ab. Wenn der Benutzer nicht vorhanden ist, wird ein Fehler zurückgegeben. Wenn der Benutzer vorhanden ist, fahren Sie mit dem nächsten Schritt fort.
Stellen Sie fest, ob der aktuelle Benutzer ein Superuser ist, wird die Anfrage direkt ohne Autorisierungsprüfung weitergeleitet. Wenn es sich um einen normalen Benutzer handelt, fahren Sie mit dem nächsten Schritt zur detaillierten Autorisierungsprüfung fort.
Rufen Sie die relevante Autorisierungsrichtlinienliste basierend auf dem Benutzernamen ab, ordnen Sie die diesmal angeforderten Ressourcen, Vorgänge und Umgebungen zu und sortieren Sie sie nach Priorität.
Entscheidungen werden auf der Grundlage der Autorisierungsrichtlinie mit der höchsten Priorität getroffen. Wenn die Autorisierungsrichtlinie den Vorgang zulässt, wird der Vorgang abgelehnt.

Analyse von Autorisierungsparametern

In ACL 2.0 wird das Parsen autorisierungsbezogener Parameter (einschließlich Ressourcen, Vorgänge usw.) basierend auf dem Vorgangstyp und der Anforderungshäufigkeit optimiert.

Hartcodierte Analyse

Für Schnittstellen wie Nachrichtenversand und -verbrauch sind die Parameter relativ komplex und die Anforderungshäufigkeit relativ hoch. Unter Berücksichtigung der Komfort- und Leistungsanforderungen beim Parsen wird für das Parsen eine harte Codierung verwendet.

Anmerkungsanalyse

Bei einer großen Anzahl von Verwaltungs- und Steuerungsschnittstellen ist der Arbeitsaufwand für die harte Codierung enorm, die Häufigkeit des Aufrufs dieser Schnittstellen ist gering und die Leistungsanforderungen sind nicht hoch. Daher werden Anmerkungen zur Analyse verwendet, um die Codierungseffizienz zu verbessern.

Priorität der Berechtigungsrichtlinie

In Bezug auf den Berechtigungsrichtlinienabgleich kann dieselbe Ressource mehreren Berechtigungsrichtlinien entsprechen, da der Fuzzy-Ressourcenabgleichsmodus unterstützt wird. Daher ist ein Prioritätsmechanismus erforderlich, um zu bestimmen, welcher Satz von Berechtigungsrichtlinien letztendlich verwendet wird.

Angenommen, die folgende Autorisierungsrichtlinie ist konfiguriert und die Übereinstimmungssituation der oben genannten Prioritätsressourcen ist wie folgt:

Authentifizierungs- und Autorisierungsstrategie

Aufgrund von Sicherheits- und Leistungskompromissen und Überlegungen bietet RocketMQ ACL 2.0 zwei Strategien für die Authentifizierung und Autorisierung: eine zustandslose Authentifizierungs- und Autorisierungsstrategie (Stateless) und eine zustandsbehaftete Authentifizierungs- und Autorisierungsstrategie (Stateful).

Strategie zur zustandslosen Authentifizierung und Autorisierung (Stateless) : Bei dieser Strategie durchläuft jede Anfrage einen unabhängigen Authentifizierungs- und Autorisierungsprozess und ist nicht auf frühere Sitzungs- und Statusinformationen angewiesen. Diese strenge Richtlinie gewährleistet ein höheres Maß an Sicherheit. Änderungen an Berechtigungen können in nachfolgenden Anfragen in Echtzeit und ohne Wartezeit berücksichtigt werden. Diese Strategie kann jedoch in Szenarien mit hohem Durchsatz zu einer erheblichen Leistungsbelastung führen, z. B. durch eine erhöhte System-CPU-Auslastung und zeitaufwändige Anforderungen.

Stateful-Authentifizierungs- und Autorisierungsstrategie (Stateful) : Bei dieser Strategie wird unter derselben Clientverbindung, derselben Ressource und demselben Vorgang die erste Anforderung vollständig authentifiziert und autorisiert, und nachfolgende Anforderungen werden nicht wiederholt authentifiziert und autorisiert. Diese Methode kann die Leistung effektiv reduzieren und die Anforderungszeit verkürzen und eignet sich besonders für Szenarien mit hohem Durchsatz. Allerdings kann diese Strategie Sicherheitsbeeinträchtigungen mit sich bringen und Änderungen an Berechtigungen werden möglicherweise nicht in Echtzeit wirksam.

Bei der Wahl zwischen diesen beiden Strategien müssen die Sicherheitsanforderungen und Leistungsanforderungen des Systems abgewogen werden. Wenn das System hohe Sicherheitsanforderungen hat und einen gewissen Leistungsverlust tolerieren kann, ist die zustandslose Authentifizierungs- und Autorisierungsstrategie möglicherweise die bessere Wahl. Im Gegenteil: Wenn das System eine große Anzahl gleichzeitiger Anfragen verarbeiten muss und die Sicherheitsanforderungen bis zu einem gewissen Grad gelockert werden können, ist eine zustandsbehaftete Authentifizierungs- und Autorisierungsstrategie möglicherweise besser geeignet. Bei der tatsächlichen Bereitstellung sollten Entscheidungen auch auf der Grundlage spezifischer Geschäftsszenarien und Sicherheitsanforderungen getroffen werden.

Steckmechanismus

Um sich an die kontinuierliche Weiterentwicklung der Authentifizierungsmethoden in der Zukunft anzupassen und die individuellen Anforderungen der Benutzer für bestimmte Szenarien zu erfüllen, bietet RocketMQ ACL 2.0 Flexibilität und Skalierbarkeit in mehrfacher Hinsicht.

Erweiterung der Authentifizierungs- und Autorisierungsrichtlinien : Standardmäßig bietet RocketMQ ACL 2.0 zustandslose Authentifizierungs- und Autorisierungsrichtlinien (Stateless) und zustandsbehaftete Authentifizierungs- und Autorisierungsrichtlinien (Stateful), um den Sicherheits- und Leistungsanforderungen der meisten Benutzer gerecht zu werden. Allerdings können in Zukunft noch bessere Strategien erforscht werden, um ein Gleichgewicht zwischen Sicherheit und Leistung zu finden.

Erweiterung der Authentifizierungs- und Autorisierungsmethoden : Im Hinblick auf die Authentifizierung gibt es derzeit viele ausgereifte Implementierungen auf dem Markt. Derzeit ist nur eine davon durch Plug-In-Funktionen reserviert, und in Zukunft können weitere problemlos eingeführt werden. Authentifizierungsmechanismus. In Bezug auf die Autorisierung implementiert RocketMQ eine Reihe gängiger Autorisierungsmethoden basierend auf dem ABAC-Modell, um sich an eine Vielzahl von Benutzeranforderungen anzupassen. Es bietet aber auch Plug-in-Funktionen, um die Anpassung weiterer Lösungen an zukünftige Entwicklungen zu erleichtern.

Orchestrierung von Authentifizierungs- und Autorisierungsprozessen : Basierend auf dem Designmuster der Verantwortungskette orchestriert RocketMQ ACL 2.0 seine Standardauthentifizierungs- und Autorisierungsprozesse flexibel. Benutzer können diese Verantwortungskettenknoten erweitern oder neu schreiben, um die Authentifizierungs- und Autorisierungslogik für ihre spezifischen Geschäftsszenarien anzupassen.

Erweiterung der Benutzer- und Berechtigungsspeicherung : RocketMQ verwendet standardmäßig RocksDB, um Benutzer- und Berechtigungsdaten lokal auf dem Broker-Knoten zu speichern. Durch die Implementierung vordefinierter Schnittstellen können Benutzer diese Daten jedoch problemlos auf jeden Dienst oder jedes Speichersystem eines Drittanbieters migrieren und so ihr Architekturdesign und ihre betriebliche Effizienz optimieren.

Audit-Log

Audit-Protokolle werden verwendet, um alle Zugriffskontrollvorgänge im Zusammenhang mit Authentifizierung und Autorisierung aufzuzeichnen und zu überwachen. Mithilfe des Upgrade-Protokolls können wir jede Zugriffsanfrage verfolgen, um die Zuverlässigkeit und Sicherheit des Systems zu gewährleisten. Gleichzeitig hilft es dabei, Probleme zu beheben, sichere Upgrades durchzuführen und Compliance-Anforderungen zu erfüllen.

RocketMQ ACL 2.0 unterstützt Audit-Protokolle im Zusammenhang mit Authentifizierung und Autorisierung. Das Format ist wie folgt:

Authentifizierungsprotokoll

# 认证成功日志
[AUTHENTICATION] User:rocketmq is authenticated success with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+gg=.

# 认证失败日志
[AUTHENTICATION] User:rocketmq is authenticated failed with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+xx=.

Autorisierungsprotokoll

# 授权成功日志
[AUTHORIZATION] Subject = User:rocketmq is Allow Action = Pub from sourceIp = 192.168.0.2 on resource = Topic:TP-TEST for request = 10.

# 授权失败日志
[AUTHORIZATION] Subject = User:rocketmq is Deny Action = Sub from sourceIp = 192.168.0.2 on resource = Topic:GID-TEST for request = 10.

Konfiguration und Verwendung

Bereitstellungsarchitektur

In Bezug auf die Bereitstellungsarchitektur bietet RocketMQ zwei Bereitstellungsformen, nämlich die integrierte Speicher- und Computerarchitektur und die getrennte Speicher- und Computerarchitektur.

Integrierte Speicher- und Computerarchitektur

In der integrierten Speicher- und Computerarchitektur von RocketMQ übernimmt die Broker-Komponente sowohl Rechen- als auch Speicheraufgaben, stellt externe Dienste bereit und empfängt Zugriffsanfragen von allen Clients. Daher spielt die Broker-Komponente eine wichtige Rolle bei der Authentifizierung und Autorisierung. Darüber hinaus ist die Broker-Komponente auch für die Pflege und Speicherung von Metadaten im Zusammenhang mit Authentifizierung und Autorisierung verantwortlich.

Speicher- und Berechnungstrennungsarchitektur

In der Speicher- und Berechnungstrennungsarchitektur von RocketMQ wird die Speicherung von der Broker-Komponente und die Berechnung von der Proxy-Komponente verwaltet. Alle externen Anforderungen werden vom Proxy bedient. Daher erfolgt die Authentifizierung und Autorisierung von Anfragen durch die Proxy-Komponente. Der Broker ist für die Metadatenspeicherung verantwortlich und stellt die erforderlichen Abfrage- und Verwaltungsdienste für Authentifizierungs- und Autorisierungsmetadaten für die Proxy-Komponente bereit.

Clusterkonfiguration

Authentifizierungskonfiguration

Parameterliste

Wenn Sie die Authentifizierungsfunktion serverseitig aktivieren möchten, umfassen die relevanten Parameter und Anwendungsfälle hauptsächlich Folgendes:

Broker-Konfiguration

authenticationEnabled = true
authenticationProvider = org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider
initAuthenticationUser = {"username":"rocketmq","password":"12345678"}
innerClientAuthenticationCredentials = {"accessKey":"rocketmq","secretKey":"12345678"}
authenticationMetadataProvider = org.apache.rocketmq.auth.authentication.provider.LocalAuthenticationMetadataProvider

Proxy-Konfiguration

{
  "authenticationEnabled": true,
  "authenticationProvider": "org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider",
  "authenticationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthenticationMetadataProvider",
  "innerClientAuthenticationCredentials": "{\"accessKey\":\"rocketmq\", \"secretKey\":\"12345678\"}"
}

Autorisierungskonfiguration

Parameterliste

Wenn Sie die Autorisierungsfunktion serverseitig aktivieren möchten, umfassen die relevanten Parameter und Anwendungsfälle hauptsächlich Folgendes:

Broker-Konfiguration

authorizationEnabled = true
authorizationProvider = org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider
authorizationMetadataProvider = org.apache.rocketmq.auth.authorization.provider.LocalAuthorizationMetadataProvider

Proxy-Konfiguration

{
  "authorizationEnabled": true,
  "authorizationProvider": "org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider",
  "authorizationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthorizationMetadataProvider"
}

wie benutzt man

Verwendung der Befehlszeile

Benutzerverwaltung

Bezüglich der Verwaltung von ACL-Benutzern lauten die relevanten Schnittstellendefinitionen und Anwendungsfälle wie folgt.

Schnittstellendefinition

Anwendungsfälle

# 创建用户
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq
# 创建用户，指定用户类型
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq -t Super
# 更新用户
sh mqadmin updateUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p 12345678
# 删除用户
sh mqadmin deleteUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户详情
sh mqadmin getUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户列表
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster
# 查询用户列表，带过滤条件
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster -f mq

ACL-Verwaltung

Bezüglich der Verwaltung der ACL-Autorisierung lauten die relevanten Schnittstellendefinitionen und Anwendungsfälle wie folgt.

Schnittstellendefinition

Anwendungsfälle

# 创建授权
sh mqadmin createAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Allow
# 更新授权
sh mqadmin updateAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Deny
# 删除授权
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq
# 删除授权，指定资源
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权列表
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster
# 查询授权列表，带过滤条件
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权详情
sh mqadmin getAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq

Kundennutzung

Bezüglich der Verwendung von ACL werden ACL 2.0 und ACL 1.0 ohne Unterschied auf die gleiche Weise verwendet. Einzelheiten entnehmen Sie bitte dem offiziellen Fall.

Nachrichtenversand

ClientServiceProvider provider = ClientServiceProvider.loadService();
StaticSessionCredentialsProvider sessionCredentialsProvider = 
  new StaticSessionCredentialsProvider(ACCESS_KEY, SECRET_KEY);
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
Producer producer = provider.newProducerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setTopics(TOPICS)
    .build();

Nachrichtenverbrauch

ClientServiceProvider provider = ClientServiceProvider.loadService();
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
FilterExpression filterExpression = new FilterExpression(TAG, FilterExpressionType.TAG);
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setConsumerGroup(CONSUMER_GROUP)
    .setSubscriptionExpressions(Collections.singletonMap(TOPIC, filterExpression))
    .setMessageListener(messageView -> {
        return ConsumeResult.SUCCESS;
    })
    .build();

Expansion und Migration

Erweiterung

Wenn Sie einen Broker erweitern möchten, während der Cluster läuft, müssen Sie alle Metadaten mit dem neuen Broker synchronisieren. ACL 2.0 bietet entsprechende Kopierbenutzer- und Kopierautorisierungsschnittstellen, um diesen Vorgang zu unterstützen.

Schnittstellendefinition

Anwendungsfälle

# 拷贝用户
sh mqadmin copyUser -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911
# 拷贝授权
sh mqadmin copyAcl -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911

Wandern

Wenn Sie bereits ACL 1.0 verwenden und nahtlos auf ACL 2.0 migrieren möchten, stehen Ihnen entsprechende Lösungen zur Verfügung. Sie müssen lediglich die folgenden Konfigurationen vornehmen.

Konfigurationsdefinition

Aktivieren Sie die folgende Konfiguration in der Konfigurationsdatei des Brokers:

migrateAuthFromV1Enabled = true

Spezielle Notiz

Nach der Aktivierung der obigen Konfiguration wird die Ausführung beim Broker-Start automatisch ausgelöst. Diese Migrationsfunktion schreibt die Benutzerberechtigungsinformationen in ACL 1.0 in die entsprechende Speicherstruktur von ACL 2.0.

Benutzer und Berechtigungen, die in ACL 2.0 noch nicht vorhanden sind, werden vom System automatisch hinzugefügt. Die Migrationsfunktion überschreibt keine vorhandenen Benutzer und Berechtigungen, um zu vermeiden, dass in ACL 2.0 vorgenommene Änderungen überschrieben werden.

Die IP-Whitelist in ACL 1.0 wird zur Umgehung von Zugriffskontrollprüfungen verwendet und entspricht nicht dem Verhalten von ACL 2.0, sodass sie nicht auf ACL 2.0 migriert wird. Wenn Sie die entsprechenden Funktionen bereits genutzt haben, schließen Sie bitte die Transformation vor der Migration ab.

Planung und Zusammenfassung

Planung

Die zukünftige Planung von RocketMQ ACL kann sich in den folgenden zwei Aspekten widerspiegeln:

Umfangreiche Authentifizierungs- und Autorisierungserweiterungen : Es gibt umfangreiche Authentifizierungs- und Autorisierungslösungen auf dem Markt, und auch andere Speicher- oder Computerprodukte verwenden verschiedene Implementierungsmethoden. Um mit den Entwicklungstrends der Branche Schritt zu halten, wird RocketMQ ACL auch in Zukunft nach Innovationen streben, um breitere und sich ändernde Kundenbedürfnisse zu erfüllen. Gleichzeitig werden wir die Forschung weiter vertiefen und bessere Authentifizierungs- und Autorisierungsstrategien entwickeln, um das ideale Gleichgewicht zwischen Sicherheit und Leistung zu erreichen.
Visuelle Benutzerberechtigungsoperationen : Derzeit können Benutzer und Berechtigungen in ACL nur über Befehlszeilentools konfiguriert werden, was nicht benutzerfreundlich genug ist. Wir hoffen, in Zukunft eine klare und benutzerfreundliche visuelle Verwaltungsoberfläche im RocketMQ Dashboard bereitzustellen, um so den Konfigurationsprozess zu vereinfachen und die technischen Hürden für die Verwaltung zu senken. Andererseits ist im bestehenden Dashboard noch nicht das ACL-Zugriffskontrollsystem integriert, das in Zukunft ebenfalls integriert werden soll, um Benutzern Zugriffsrechte für die Bedienung verschiedener Ressourcen auf dem Dashboard zu geben.

Zusammenfassen

RocketMQ ACL 2.0 wurde in Bezug auf Modelldesign, Skalierbarkeit, Sicherheit und Leistung völlig neuen Upgrades unterzogen. Es wurde entwickelt, um Benutzern eine verfeinerte Zugriffskontrolle zu bieten und gleichzeitig den Berechtigungskonfigurationsprozess zu vereinfachen. Jeder ist herzlich willkommen, die neue Version auszuprobieren und in der Produktionsumgebung anzuwenden. Wir freuen uns auf das Feedback, die Diskussion und die Teilnahme aller in der Community, um gemeinsam das Wachstum und den technologischen Fortschritt der RocketMQ-Community voranzutreiben. Willkommen bei der Apache RocketMQ China Developers DingTalk Group. (Gruppennummer: 21982288)

Verwandte Links:

[1] RocketMQ-Website zum Chinesischlernen ttps://rocketmq-learning.com

[2] Cloud-Nachrichtenwarteschlange RocketMQ https://www.aliyun.com/product/rocketmq