DE102020113257A1 - Policy management system zur bereitstellung von autorisierungsinformationen über den distributed data store - Google Patents

Policy management system zur bereitstellung von autorisierungsinformationen über den distributed data store Download PDF

Info

Publication number
DE102020113257A1
DE102020113257A1 DE102020113257.3A DE102020113257A DE102020113257A1 DE 102020113257 A1 DE102020113257 A1 DE 102020113257A1 DE 102020113257 A DE102020113257 A DE 102020113257A DE 102020113257 A1 DE102020113257 A1 DE 102020113257A1
Authority
DE
Germany
Prior art keywords
network
nodes
information
node
distributed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020113257.3A
Other languages
English (en)
Inventor
Antoni MILTON
Pattabhi Attaluri
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102020113257A1 publication Critical patent/DE102020113257A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Ein PM-System (Distributed Policy Management) (z. B. ein System für Authentifizierungs-, Autorisierungs- und Abrechnungsaktivitäten (AAA) in einem Netzwerk) wird bereitgestellt. Knoten des PM-Systems können Informationen des PM-Systems unter Verwendung eines verteilten Datenspeichers (z. B. eines Multi-Master-Cache) gemeinsam nutzen. Jeder Knoten des verteilten PM-Systems kann ferner Informationen aus dem verteilten Datenspeicher mit anderen Knoten eines Unternehmensinfrastrukturnetzwerks teilen, indem Informationen in einer RADIUS-Protokollnachricht (Remote Authentication Dial-In User Service) erweitert werden. Knoten, die an der Richtlinienverwaltung beteiligt sind (z. B. Netzwerkauthentifizierungsserver (NAS) oder Firewall), ohne Zugriff auf den verteilten Datenspeicher, erhalten möglicherweise Informationen über erweiterte RADIUS-Nachrichten. Auf diese Weise können Geräte mit dem verteilten PM-System verbunden werden, ohne Zugriff auf den verteilten Datenspeicher zu haben. Hochverfügbarkeits- und Lastausgleichsimplementierungen können bereitgestellt werden, indem der verteilte Datenspeicher über Knoten des PM-Systems genutzt wird.

Description

  • STAND DER TECHNIK
  • Authentifizierung, Autorisierung und Buchhaltung (AAA) sind Funktionen, die von Netzwerksicherheitsprotokollen bereitgestellt werden, um den Zugriff auf Dienste und Ressourcen in einem Netzwerkcluster oder einem verteilten Netzwerk von Diensten einzuschränken, zu aktivieren und zu überwachen. Die Authentifizierung ist die Funktion, mit der Sicherheitsanbieter sicherstellen, dass die Identität von Benutzern oder Geräten, die versuchen, auf Netzwerkressourcen zuzugreifen, erkannt und als echt verifiziert wurde. Diese Zusicherung kann über die Vorlage von Identifikationsdaten erfolgen und über die EAP (Extensible Authentication Protocol) über LAN (EAPoL). EAPoL ist ein Netzwerkport-Authentifizierungsprotokoll, das im Port Based Network Access Control-Standard des Institute of Electrical and Electronics Engineers (z. B. IEEE 802.1X-Standards) verwendet wird. Autorisierungsfunktion, die im Allgemeinen verwendet wird, um den Umfang oder die Rolle des zulässigen Zugriffs eines Benutzers mit einer authentifizierten Identität auf eine bestimmte Netzwerkressource zu bestimmen (z. B. Authentifizierung bei einem Netzwerk über einen Netzwerkauthentifizierungsserver (NAS)). Nachdem eine Entität für bestimmte Ressource (n) authentifiziert und autorisiert wurde, kann eine Sitzung für diesen Benutzer und dieses Gerät eingerichtet werden. Buchhaltungsfunktionen stellen ein Mittel dar, um Aktivitäten von Benutzern in festgelegten Sitzungen zu verfolgen. Etablierte Sitzungen können ferner das Sammeln statistischer Daten für verschiedene Zwecke ermöglichen (z. B. Netzwerküberwachung, Nutzungsverfolgung, Analyse und andere Gründe). Der RADIUS (Remote Authentication Dial-In User Service) ist ein Netzwerkprotokoll, das alle drei AAA-Funktionen über eine Standardschnittstelle bereitstellt. RADIUS wird von vielen verschiedenen Hardware- und Softwareanbietern unterstützt und auf der Grundlage der IETF-Standards (Internet Engineering Task Force) gesteuert.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Offenbarung kann anhand der folgenden detaillierten Beschreibung besser verstanden werden, wenn sie zusammen mit den begleitenden Figuren gelesen wird. Es wird darauf hingewiesen, dass in Übereinstimmung mit der branchenüblichen Praxis verschiedene Merkmale nicht maßstabsgetreu gezeichnet werden. Tatsächlich können die Dimensionen oder Positionen von Funktionsattributen basierend auf Design, Sicherheit, Leistung oder anderen auf dem Gebiet der Computersysteme bekannten Faktoren verschoben oder kombiniert werden. Ferner kann die Reihenfolge der Verarbeitung für einige Funktionen sowohl intern als auch in Bezug aufeinander geändert werden. Das heißt, dass einige Funktionen möglicherweise nicht durch serielle Verarbeitung implementiert werden und daher in einer anderen Reihenfolge als gezeigt oder möglicherweise parallel zueinander ausgeführt werden. Für eine detaillierte Beschreibung verschiedener Beispiele wird nun auf die beigefügten Zeichnungen verwiesen, in denen:
  • 1 zeigt ein funktionales Zeitplandiagramm mit Beispielkomponenten (und Aktionen dieser Komponenten) für ein System, das unter Verwendung des RADIUS-Netzwerkprotokolls und anderer Protokolle erstellt wurde, um Informationen von einem Richtlinienmanager (PM) mit anderen Geräten in einem Netzwerk gemäß einem oder mehreren zu teilen offenbarte Implementierungen;
  • 2 ist ein Blockdiagramm, das eine mögliche Beziehung zwischen mehreren interagierenden Ressourcen innerhalb eines Clusters darstellt, die AAA-Funktionen für verteilte Instanzen einer beispielhaften PM-Implementierung gemäß einer oder mehreren offenbarten Implementierungen bereitstellen;
  • 3 ist ein Flussdiagramm, das einen möglichen Prozessablauf für ein Handshake-Verfahren einer Zugriffsanforderungsfunktion darstellt und das Aktualisieren der Ergebnisse einer entsprechenden Zugriffsakzeptanzantwort gemäß einer oder mehreren offenbarten Implementierungen umfasst;
  • 4 ist ein Flussdiagramm, das einen möglichen Prozessablauf für ein zweites Handshake-Verfahren darstellt, das eine Buchhaltungsanforderungsfunktion darstellt, und das Aktualisieren der Ergebnisse einer entsprechenden Buchhaltungsantwort zurück an das anfordernde Netzwerkgerät gemäß einer oder mehreren offenbarten Implementierungen umfasst;
  • 5 zeigt einen beispielhaften Prozessor und ein computerlesbares Medium, um das beispielhafte Verfahren von 5 zu implementieren. 3 gemäß einer oder mehreren offenbarten Implementierungen;
  • FIG. zeigt einen beispielhaften Prozessor und ein computerlesbares Medium, um das beispielhafte Verfahren von 6 zu implementieren. 4 gemäß einer oder mehreren offenbarten Implementierungen;
  • 7 zeigt eine beispielhafte Computernetzwerkinfrastruktur, die verwendet werden kann, um alle oder einen Teil der offenbarten Techniken zum Aktualisieren von AAA-Informationen über RADIUS auf einen externen Server von einem PM gemäß einer oder mehreren offenbarten Ausführungsformen zu implementieren; und
  • 8 ein Computer-Verarbeitungsgerät zeigt, das verwendet werden kann, um die Funktionen, Module, Verarbeitungsplattformen, Ausführungsplattformen, Kommunikationsgeräte und andere Verfahren und Prozesse dieser Offenbarung umzusetzen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Veranschaulichende Beispiele des nachstehend beanspruchten Gegenstands werden nun offenbart. Aus Gründen der Übersichtlichkeit werden in dieser Spezifikation nicht für jede Beispielimplementierung alle Merkmale einer tatsächlichen Implementierung beschrieben. Es versteht sich, dass bei der Entwicklung eines solchen tatsächlichen Beispiels zahlreiche implementierungsspezifische Entscheidungen getroffen werden können, um die spezifischen Ziele des Entwicklers zu erreichen, wie beispielsweise die Einhaltung systembezogener und geschäftsbezogener Einschränkungen, die von Implementierung zu Implementierung unterschiedlich sind. Darüber hinaus versteht es sich, dass ein solcher Entwicklungsaufwand, selbst wenn er komplex und zeitaufwendig ist, ein Routinevorhaben für den Durchschnittsfachmann wäre, der von dieser Offenbarung profitiert.
  • Systeme, die entwickelt wurden, um AAA für Benutzer zu handhaben, wie z. B. diejenigen, die das RADIUS-Protokoll implementieren, können zuverlässige Speichermechanismen verwenden, um Informationen über bekannte Benutzer (z. B. authentifizierte Benutzer) und ihre zugewiesenen Rollen zu verwalten und auszutauschen. Ein solches System, das AAA verarbeitet, ist ein LDAP-Server (Lightweight Directory Access Protocol). AAA-Systeme speichern im Allgemeinen Informationen zu Benutzersitzungen und erkannten Benutzerrollen zur Laufzeit. AAA-Systeme können auch die Abrechnung von Benutzersitzungen ermöglichen (z. B. unter Verwendung einer Authentifizierungsdatenbank). In einigen Implementierungen können Proxyserver als Brücke zwischen isolierten Netzwerkkomponenten (z. B. verschiedenen Subnetzen eines größeren Unternehmensnetzwerks) fungieren, um die zentralisierte Verwaltung und Weitergabe von Informationen an andere Instanzen der Geräte zu unterstützen, die dasselbe Netzwerkprotokoll wie RADIUS verstehen . Die Verwendung eines Standardprotokolls wie RADIUS ermöglicht ferner ein heterogenes Netzwerk von Geräten, die von mehreren Anbietern gleichzeitig bereitgestellt werden. Beispielsweise kann das Weiterleiten oder Umschreiben von Paketen des Standardprotokolls unter Verwendung derselben genau definierten Schnittstellen, die in diesem Protokoll beschrieben sind, es verschiedenen Herstellern ermöglichen, gemeinsam zu arbeiten.
  • AAA-Systeme wie RADIUS können auch hoch verfügbar gemacht werden (z. B. für Redundanz konfiguriert), um einen zuverlässigen Zugriff auf die von ihnen bereitgestellten Dienste und Ressourcen im Falle eines Ausfalls eines einzelnen Geräts zu gewährleisten. Hochverfügbarkeit (HA) ist ein Merkmal, das in einer zusammengesetzten Ansicht versucht, sicherzustellen, dass ein System, ein Dienst oder eine Ressource funktionsfähig und zugänglich bleibt, mit maximaler Verfügbarkeit und einer geringeren Wahrscheinlichkeit von Ausfallzeiten bei einzelnen Ausfallstellen des Einzelnen Komponenten des Systems. Ein weiterer Aspekt, der zusammen mit HA bereitgestellt werden kann, ist eine verteilte Ressourceneigenschaft, die es dem System, dem Dienst oder der Ressource ermöglicht, in einem bestimmten Unternehmen allgemein zugänglich zu sein. Diese Ziele von HA und verteiltem Zugriff können durch Verteilung von wirkenden Komponenten und / oder Verteilung von Statusinformationen sowohl für den Zugriff als auch für die Änderung erreicht werden. Durch die Verteilung des Status sowohl für den Zugriff als auch für die Änderung können aktuelle Informationen rechtzeitig im verteilten System wiedergegeben werden (z. B. Austausch von Clusterinformationen, verteilte Datenbank usw.). Die für die unterstützende Infrastruktur eines Netzwerksicherheitsprotokolls getroffenen Entscheidungen, die AAA-Funktionen wie RADIUS bereitstellen, können für verschiedene Implementierungen angepasst werden und basieren auf Komponenten mehrerer Anbieter.
  • Implementierungen von Netzwerksicherheitsprotokollen wie RADIUS bieten ihre Funktionen zur Authentifizierung, Autorisierung und Abrechnung (AAA) normalerweise über vom Protokoll definierte Standardschnittstellen. RADIUS und andere Netzwerkprotokolle bieten möglicherweise definierte Schnittstellen, um das Handshake zwischen externen Akteuren (z. B. anderen Systemen eines Unternehmensnetzwerks) und den Systemen zur Bereitstellung von AAA-Funktionen zu ermöglichen. Zusätzlich zu vordefinierten Schnittstellen (z. B. Handshakes von Gerätekonsumenten) für das System, das AAA-Funktionalität bereitstellt, bietet diese Offenbarung ein Mittel zum Abrufen und Ändern der resultierenden Statusinformationen. Somit kann eine Verbesserung gegenüber herkömmlichen Computernetzwerken bereitgestellt werden, um eine Schnittstelle zwischen vernetzten Systemen, die für den Verbrauch bestimmt sind, und Peripheriesystemen herzustellen, die diese gemeinsam genutzten Informationen innerhalb des größeren Unternehmens weiter verarbeiten können. Insbesondere können Beispielimplementierungen den Austausch von Informationen von einem PM-System und anderen Systemen (z. B. Firewalls) ermöglichen, die von zusätzlichen Informationen in Bezug auf Unternehmensnetzwerkrichtlinien (z. B. vom PM-System bereitgestellte Richtlinien) profitieren können.
  • Offenbarte Implementierungen zum Abrufen von Änderungen an Informationen, die durch AAA-Funktionen verwaltet werden, die von einem PM-Server ausgeführt werden, umfassen die Verwendung eines gemeinsam genutzten Speichercaches, der hier als „Multi-Master-Cache“ (MMC) bezeichnet wird. Die MMC kann auf verschiedene Computergeräte übertragen werden, um gemeinsam ein umfassendes Richtlinienmanagement für eine Organisation bereitzustellen. Wie oben erwähnt, umfassen die Richtlinienverwaltungsfunktionen das Steuern der Zugriffsfunktionen (z. B. Sicherheit) für Netzwerkdienste innerhalb des Unternehmensnetzwerks des Unternehmens.
  • Im Allgemeinen kann es Geräte im Unternehmensnetzwerk geben, die Geräte verbrauchen (z. B. Benutzergeräte oder abonnierende Geräte). Benutzergeräte können Laptops, Tablets, Desktops usw. darstellen. Abonnierende Geräte können Anwendungsserver darstellen oder Ressourcen berechnen, die allgemeine Funktionen (z. B. Computeranwendungen) zur Unterstützung des Unternehmensbetriebs über die Geräte bereitstellen, die kommunikativ mit dem Unternehmensnetzwerk verbunden sind. Jedes dieser verbrauchenden Geräte kann unter Verwendung eines Netzwerkprotokolls wie RADIUS miteinander und mit der Bereitstellung von Geräten (z. B. Teilnehmern, die die PM-Funktionalität bereitstellen) interagieren. Jeder Teilnehmer, der die PM-Funktionalität bereitstellt, kann Informationen über RADIUS (oder ein anderes Netzwerkprotokoll) und mithilfe der MMC austauschen. Durch die Verwendung einer verteilten MMC kann die Verteilung der PM-Funktionalität über einen Cluster für das Unternehmensnetzwerk hoch verfügbar werden. Implementierungen sind nicht auf einen Cluster für HA beschränkt, sondern ein Cluster ist nur eine Möglichkeit, Redundanz bereitzustellen.
  • In den Beispielimplementierungen dieser Offenbarung wird ein Cluster verwendet, jedoch sind andere Techniken für HA möglich und werden vom Fachmann angesichts des Vorteils dieser Offenbarung verstanden. Insbesondere eine herkömmliche Primär- und Sicherungsrolle für zwei Server mit PM-Funktionalität ist ein weiteres Beispiel für die Implementierung von HA. In jedem Fall können mehrere Server, die gemeinsam an der Bereitstellung einer HA-Lösung arbeiten, dies tun, indem sie die offenbarte MMC verwenden, um Informationen auszutauschen und mehreren Geräten den Zugriff auf einen aktuellen Satz von Informationen zu ermöglichen (z. B. werden Änderungen an dynamischen Informationen automatisch weitergegeben), um ihre Informationen auszuführen Beabsichtigte Funktion.
  • In einer Cluster-Implementierung kann die MMC als Repository für Knoten eines PM-Clusters fungieren, um dynamische Informationen zu speichern, die dann automatisch (basierend auf Änderungen) über jeden der Knoten des Clusters weitergegeben werden können, so dass jeder der Knoten erhalten bleibt Strom und Redundanz des Datenzugriffs sorgen für hohe Verfügbarkeit. Ferner kann jedes der Geräte, die die aktuellen Informationen teilen (z. B. über die MMC), den Zugriff auf Informationen durch Verbrauchergeräte unter Verwendung von Backend-Kanälen ermöglichen, die nicht notwendigerweise durch einen bestimmten Protokollstandard (z. B. RADIUS) definiert sind. Kurz gesagt, es können Erweiterungen des Standards bereitgestellt werden, die die Erweiterung verfügbarer Daten ermöglichen, ohne standardkonforme Schnittstellen zu „beschädigen“.
  • In offenbarten Implementierungen kann die Fähigkeit zur Bereitstellung von PM-Funktionalität etablierte Netzwerksicherheitsprotokolle wie RADIUS zum Einrichten und Teilen von AAA-Informationen verwenden. Ein Verfahren zum Einrichten und Teilen von AAA-Informationen kann die Handshake-Schnittstellen umfassen, die in dieser Offenbarung diskutiert werden. Die gemeinsame Nutzung kann zwischen den bereitstellenden Geräten erfolgen (z. B. mithilfe von RADIUS- oder MMC-Zugriff) und kann auch Ressourcen (z. B. verbrauchenden Geräten) bereitgestellt werden, die die AAA-Informationen verwenden. Beispiele für das Konsumieren von Geräten sind unter anderem Anwendungsdienste, Rechenressourcen und Firewalls. Verbrauchende Geräte haben möglicherweise keinen direkten Zugriff auf MMC, können jedoch möglicherweise indirekt über die MMC auf aktuelle Daten zugreifen. Das heißt, sie können (z. B. über Handshake oder eine andere Schnittstelle) mit einer verteilten Komponente interagieren, die die PM-Funktionalität bereitstellt, die direkten Zugriff auf die MMC hat. Ein Vorteil dieser Art der Implementierung besteht darin, eine lose Kopplung mit einem beliebigen Protokoll bereitzustellen und ferner einen proprietären Zugriff (z. B. Zugriff, der nicht auf einem Industriestandard basiert) auf diese Informationen zu ermöglichen, ohne auf Funktionen beschränkt zu sein oder diese zu beeinträchtigen, die auf einem Industriestandard basieren . Dementsprechend kann der Zugriff auf AAA-Informationen unter Verwendung von Techniken, die sonst nicht verfügbar wären (z. B. von keinem Standard bereitgestellt), optimiert, verbessert und verfügbar gemacht werden.
  • Die Verwendung einer MMC kann das Aktualisieren der AAA-Informationen auf mindestens zwei Arten ermöglichen. Beispielsweise können AAA-Informationen in einer MMC verwaltet werden und Aktualisierungen können Nicht-MMC-Geräten (z. B. Firewall) unter Verwendung eines Protokolls wie RADIUS bereitgestellt werden. Zusätzlich können AAA-Informationsaktualisierungen für MMC-Geräte über einen verteilten gemeinsam genutzten Datenspeicher bereitgestellt werden. Natürlich kann es auch möglich sein, MMC-Geräte auf andere Weise als mithilfe der MMC-Funktion zu aktualisieren. Im Allgemeinen können Aktualisierungen des gemeinsam genutzten Datenspeichers (MMC) als integrierte Funktion der erfolgreichen Bestätigung einer versuchten Handshake-Schnittstelle vorgenommen werden. In einem Beispiel können MMC-Aktualisierungen auftreten, bevor Erfolg / Misserfolg des Handshakes an einen Initiator dieses versuchten Handshakes zurückgemeldet werden. Nach der Aktualisierung in einem lokalen Datenspeicher, der dem Komponentengerät zugeordnet ist, das den Handshake ausführt, können Änderungen an Daten automatisch an die anderen Komponentengeräte weitergegeben (z. B. gemeinsam genutzt oder verteilt) werden, die nicht direkt an dieser Instanz eines Handshakes teilgenommen haben. Somit kann der Datenspeicher auf den verbleibenden Knoten des Clusters, der ihre lokale Version der MMC darstellt, mit aktuellen Informationen verwaltet werden.
  • Im Allgemeinen kann die Weitergabe von Informationen für jede Handshake-Operation gelten, die zum Hinzufügen, Ändern oder Löschen der resultierenden Statusinformationen in Bezug auf die PM-Funktionalität geführt hat. In diesem Zusammenhang beziehen sich Statusinformationen auf den Authentifizierungsstatus in Bezug auf Benutzer oder Endbenutzergeräte, die auf Interaktionen mit einem Unternehmensinfrastrukturnetzwerk basieren. Interaktionen können Anforderungen zur Authentifizierung beim Unternehmensnetzwerk oder zum Zugriff auf Anwendungsdienste enthalten, die als Teil der gesamten sicheren Unternehmensinfrastruktur bereitgestellt werden. In einem Beispiel für die Implementierung unter Verwendung von RADIUS können Identitäts- und Rolleninformationen eines bestimmten Benutzers und der zugewiesenen Sitzung, die aus einem erfolgreichen Zugriffsanforderungsaufruf resultieren, vor dem Antworten mit einer Zugriffsantwort auf die MMC aktualisiert werden. Darüber hinaus werden möglicherweise keine Accounting-Stop-Antworten gesendet, bevor die zugehörigen AAA-Statusinformationen gelöscht wurden. Dementsprechend können Änderungen unabhängig über die MMC weitergegeben werden, um Mitgliedern eines Clusters oder anderen Rechenressourcen zur Verfügung zu stehen, die PM-Funktionen unter Verwendung der MMC implementieren (z. B. der gemeinsam genutzte und weitergegebene Datenspeicher).
  • Im Allgemeinen können offenbarte Implementierungen mehrere unterschiedliche Funktionsabläufe (z. B. Handshakes) verwenden, um Informationen auszutauschen. Ein erster Informationsfluss kann zwischen zwei PM-Knoten einer verteilten PM-Implementierung erfolgen. In diesem ersten Fluss kann ein erster PM-Knoten (nach der Authentifizierung an einem möglicherweise anderen Knoten) Autorisierungsattribute (z. B. für den neu authentifizierten Benutzer) aus einer Datenbank von Regeln (z. B. Richtlinien) ableiten (z. B. abrufen oder über eine Abfrage abrufen) Regeln). Dann kann der erste PM-Knoten (beispielsweise in die MMC) einen Datensatz aktualisieren / einfügen, der die abgeleiteten Berechtigungsattribute widerspiegelt. In einem bestimmten Beispiel kann die Datenbank bei der Authentifizierung von Benutzer-BOB BOB als „Schüler“ identifizieren. Dann kann eine Zuordnung von BOB zur Studentenrolle in die MMC eingefügt werden.
  • Ein zweiter Informationsfluss kann zwischen einem NAS und einem PM-Knoten erfolgen und eine Abrechnungsanforderung widerspiegeln. In diesem zweiten Ablauf kann eine Abrechnungsanforderung von der NAS gestellt werden, um eine Stationsidentifikation und eine Rahmen-IP-Adresse für ein Gerät zu erhalten, das dem Benutzer BOB zugeordnet ist. Ein dritter Funktionsfluss kann zwischen Knoten einer verteilten PM-Implementierung liegen (z. B. wie der erste oben diskutierte Funktionsfluss). Dieser dritte Funktionsfluss kann möglicherweise nach der Abrechnungsanforderung des zweiten Flusses stattfinden und einen Knoten darstellen, der eine Abfrage an die MMC für den Benutzer BOB ausführt. Dann kann eine Aktualisierung der Kontoinformationen für den Benutzer BOB basierend auf den im zweiten Fluss erhaltenen Informationen vorgenommen werden. Die aktualisierten Kontoinformationen können dann unter Verwendung einer Aktualisierung der MMC auf allen Knoten der verteilten PM geteilt werden. Schließlich kann ein vierter Beispielfluss zwischen einem Knoten einer verteilten PM-Implementierung und einer Firewall bestehen. In diesem Ablauf kann ein Knoten des verteilten PM eine RADIUS-basierte Nachricht verwenden, um der Firewall Informationen (z. B. Informationen, die von der MMC erhalten wurden) bereitzustellen. Andere Flüsse sind möglich. Mit diesen Beispielen soll erklärt werden, dass Informationen zwischen verteilten Knoten einer PM-Implementierung über die MMC ausgetauscht werden können. Mithilfe der Freigabefunktion können verschiedene Knoten mit anderen Netzwerkgeräten (z. B. Firewall, PM-Datenbankinstanz) interagieren, um Funktionen auszuführen, die möglicherweise (z. B. in einer nicht verteilten PM-Implementierung) auf ein einzelnes Gerät beschränkt waren. Somit kann eine weitere Verteilung der PM-Funktionalität (dh Lastausgleich) und HA (z. B. verteilte Redundanz) durch offenbarte Implementierungen bereitgestellt werden, die eine verteilte MMC verwenden, wie hierin offenbart.
  • Mit einem Verständnis der obigen Übersicht erklärt diese Offenbarung nun eine mögliche nicht einschränkende Beispielimplementierung (mögliche optionale Varianten können gegebenenfalls auch enthalten sein). Diese beispielhafte Implementierung wird unter Bezugnahme auf die Figuren erläutert und stellt nur eine Möglichkeit dar, die auf offenbarten Techniken basiert. In 1 zeigt ein Funktionsblockdiagramm relevante wirkende Komponenten eines Systems, das auf dem RADIUS-Netzwerkprotokoll aufgebaut ist, das innerhalb der Parameter des Standardprotokolls arbeitet, während es ferner eine verteilte In-Memory-Cache-Technik enthält, um die Funktionalität zu erweitern, ohne den Standard zu verletzen. 2 zeigt dann ein Funktionsblockdiagramm, um mögliche Beziehungen zwischen Verbindungsgeräten zu zeigen, die von einem PM-System verwaltet werden können (z. B. einem ClearPass Policy Manager, wie er von Hewlett Packard Enterprises erhältlich ist). In einem Beispiel kann ein PM erweiterte Informationen über RADIUS-Interaktionen gemeinsam nutzen und die Parallelität in einem Unternehmensnetzwerk (z. B. Cluster-Implementierung eines PM) mithilfe eines verteilten Multi-Master-Cache (MMC) aufrechterhalten. Somit können mehrere Netzwerkkomponenten gleichzeitig die Beziehung anderer Netzwerkkomponenten kennen, indem sie ihre Statusinformationen von der MMC empfangen. 3 zeigt dann ein Flussdiagramm für ein beispielhaftes Verfahren eines Handshakes (z. B. gesteuerte Geräteinteraktion wie z. B. Challenge-Response) für eine Access-Request-Funktion. Die Zugriffsanforderungsfunktion kann eine Interaktion zwischen einem Netzwerkgerät (z. B. einem Clientgerät) oder einer Clusterkomponente basierend auf dem RADIUS-Netzwerkprotokoll darstellen. Jedes andere Gerät, das an diesem Handshake teilnimmt, verfügt möglicherweise über Parallelität und Verfügbarkeit von Daten, die zum Implementieren der Richtlinien des PM über die verteilte MMC erforderlich sind. 4 zeigt dann ein Flussdiagramm für ein beispielhaftes zweites Handshake-Verfahren (das dem ersten Handshake folgen kann), um eine Abrechnungsanforderungsfunktion zwischen einem Netzwerkgerät (z. B. dem Clientgerät) oder einer Clusterkomponente basierend auf dem RADIUS-Netzwerkprotokoll bereitzustellen. Wiederum kann jedes unterschiedliche Gerät, das an diesem Handshake teilnimmt, Parallelität und Verfügbarkeit von Daten aufweisen, die erforderlich sind, um Richtlinien des PM über die verteilte MMC zu implementieren. 5-6 veranschaulichen nicht vorübergehende computerlesbare Medien und eine entsprechende Rechenressource zum Implementieren offenbarter Verfahren. Schließlich zeigen die 7-8 veranschaulichen eine mögliche Unternehmensnetzwerkinfrastruktur bzw. ein Verarbeitungsgerät für Komponenten der Unternehmensnetzwerkinfrastruktur. 7-8 veranschaulichen eine Umgebung, in der Aspekte der aktuellen Offenbarung implementiert werden können, um eine Verbesserung der Verwaltung, Wartung, Sicherheit, Verfügbarkeit und Gesamtleistung / Zuverlässigkeit der Richtlinienverwaltung für vernetzte Geräte bereitzustellen.
  • Unter Bezugnahme auf 1 ist eine funktionale Zeitleiste 100 dargestellt. Die Zeitleiste 100 enthält beispielhaft wirkende Komponenten (z. B. Clientgerät 105, Netzwerkauthentifizierungsserver (NAS) 110, PM 115, Firewall 1 (120) und Firewall 2 (125)). Zusammen können diese wirkenden Komponenten ein Beispiel für ein System darstellen, das unter Verwendung des RADIUS-Netzwerkprotokolls und anderer Protokolle zur Implementierung der PM-Funktionalität zur Bereitstellung von Autorisierungs- und Abrechnungsinformationen für einen externen Server gemäß einer oder mehreren offenbarten Implementierungen erstellt wurde. Obwohl PM 115 in 1 als eine einzelne Box dargestellt ist. In 1 kann eine verteilte Implementierung die Funktionalität von PM 115 bereitstellen. Ereignisse der Zeitleiste 100 werden von oben nach unten dargestellt, und Interaktionen werden als Pfeile von links nach rechts und von rechts nach links dargestellt.
  • Die Zeitleiste 100 beginnt oben links, wo das Clientgerät 105 zuerst eine Verbindung zum NAS 110 unter Verwendung des Extensible Authentication Protocol über LAN (EAPoL) herstellt, wie durch den bidirektionalen Pfeil 130 angegeben. Wie oben erwähnt, ist EAPoL im IEEE-Standard (Institute for Electrical and Electronics Engineers) für portbasierte Netzwerkzugriffskontrolle (PNAC) definiert und in der Branche allgemein durch das Akronym und die Aufzählung IEEE 802.1X gekennzeichnet. Der NAS 110 kann eine ordnungsgemäße Antwort auf die EAPoL-Anforderung über den Pfeil 130 bestimmen, indem zuerst (oder gleichzeitig) eine Zugriffsanforderung gesendet wird, wie durch den Pfeil 135 an PM 115 angegeben. In diesem Beispiel stellt die dem Pfeil 135 zugeordnete Zugriffsanforderung eine Authentifizierungsanforderung dar. Wenn PM 115 in der Lage ist, die Identität des Clientgeräts 105 zu überprüfen, kann eine Aktualisierung (wie durch die Schleife 140 angezeigt) an der MMC vorgenommen werden (z. B. kann der Knoten, der die mit Pfeil 135 verknüpfte Zugriffsanforderung bedient, eine lokale Instanz von aktualisieren MMC) mit entsprechenden Werten für die Autorisierung des Zugriffs. Die geeigneten Werte können eine Rolle eines Benutzers umfassen, der derzeit dem Clientgerät 105 zugeordnet ist, oder andere Berechtigungen, die über einen Authentifizierungs- / Autorisierungsprozess gemäß NAS 110 und PM 115 überprüft / identifiziert werden können. In diesem Beispiel können Attribute zur Kontoanforderung in der MMC hinzugefügt werden (angegeben durch Anmerkung 145). Ein Beispielattribut (wie in Anmerkung 150 angegeben) ist die Rolle eines „STUDENTEN“. In einigen Implementierungen kann die durch die Schleife 140 angegebene Aktualisierung in Bezug auf Attribute erfolgen, die einer MMC hinzugefügt wurden, bevor irgendwelche Antworten an das Clientgerät 105 gegeben werden. In Reaktion auf eine erfolgreiche Aktualisierung der MMC durch PM 115 kann eine durch den Pfeil 155 angegebene Zugriffsantwort an den NAS 110 zurückgegeben werden. Der NAS 110 kann dann die Antwort (der Einfachheit halber nicht gezeigt) an das Clientgerät 105 zurücksenden. Die Antwort an den Client kann Informationen bezüglich der Sitzung enthalten, die dem jetzt authentifizierten Clientgerät 105 und einem zugeordneten Benutzer zugewiesen ist.
  • In dieser Phase der Zeitachse 100 wird in einem Beispiel das Clientgerät 105 jetzt authentifiziert und das Clientgerät 105 kann Funktionen in einem Unternehmensnetzwerk basierend auf instanziierten Sitzungsinformationen ausführen. Zusätzlich kann der NAS 110 eine Buchhaltungsanforderung, wie durch den Pfeil 160 angegeben, an die PM 115 übermitteln. Abrechnungsanforderungen können mit dem Verfolgen oder Zulassen von Benutzerinteraktionen (z. B. Authentifizierungs- oder Zugriffsanforderungen) eines Clientgeräts (z. B. Clientgerät 105) und eines zugeordneten Benutzers verbunden sein. Anfänglich kann eine Abrechnungsanforderung mit EAPoL 130 als Teil (oder als Antwort auf) eine anfängliche Netzwerkauthentifizierungsaktivität verknüpft sein. Nach der Authentifizierung können Abrechnungsanforderungen mit einem Versuch des Clientgeräts 105 verbunden sein, auf einen bestimmten Dienst oder eine bestimmte Ressource im Unternehmensnetzwerk zuzugreifen.
  • In diesem Beispiel wird das Unternehmensnetzwerk von PM 115 gesichert und verwaltet. In Reaktion auf eine Zugriffsanforderung kann PM 115 die Abfrage 165 initiieren, um Informationen von der MMC zu erhalten (z. B. eine Abfrage basierend auf einer MAC-Adresse des Clientgeräts 105 oder eine Abfrage basierend auf der Benutzeridentifikation, eine Abfrage basierend auf der Benutzer- / Geräterolle, oder eine Abfrage basierend auf einer Kombination davon). Die Abfrage 165 kann verwendet werden, um zu bestimmen, ob das Clientgerät 105 (und möglicherweise ein zugeordneter Benutzer) Zugriff auf den Zieldienst oder die Zielressource hat. PM 115 kann dann eine Abrechnungsanforderung, wie durch den Pfeil 175 angegeben, an ein anderes Computergerät weiterleiten. Es ist wichtig zu beachten, dass in einer verteilten PM-Implementierung von PM 115 ein erster Knoten funktional mit der mit Pfeil 160 verknüpften Abrechnungsanforderung arbeiten kann, während ein zweiter anderer Knoten die mit Pfeilen 175 verknüpften Abrechnungsanforderungen initiieren kann (Anmerkung 1 zu Firewall 1) (120) und eine andere zu Firewall 2 (125)). Ferner können verschiedene Knoten eines einzelnen verteilten PM 115 gleichzeitig mit Firewall 1 (120) und Firewall 2 (125) interagieren. Somit können mindestens drei Knoten einer verteilten Implementierung PM 115 eine Shard-MMC verwenden, um gemeinsam die in der Zeitachse 100 dargestellten Aktivitäten auszuführen. Natürlich sind auch weniger als drei Knoten möglich und alle Aktivitäten der Zeitachse 100 können von einem einzelnen Knoten oder einer beliebigen Anzahl von Knoten ausgeführt werden. Jeder der beteiligten Knoten kann Zugriff auf die gemeinsam genutzte MMC haben, um eine konsistente verteilte Kopie der PM-Informationen zu verwalten.
  • Wenn Sie mit der Zeitachse 100 fortfahren, können Buchhaltungsantworten, wie durch die Pfeile 185 angegeben, von Firewall 1 (120) und Firewall 2 (125) an PM 115 gesendet werden. Wie in Anmerkung 170 angegeben, ist es möglich, dass PM 115 nicht auf eine Antwort von jeder der einer oder mehreren Firewalls wartet. Stattdessen kann PM 115 eine Übertragung (z. B. Senden) einer Buchhaltungsantwortnachricht initiieren, wie durch Pfeil 180 angezeigt. Es ist zu beachten, dass die durch Pfeil 180 angegebene Abrechnungsantwortnachricht unter Verwendung von Informationen abgeleitet werden kann, die PM 115 zuvor von der MMC erhalten hat (z. B. Abfrageantwort) (z. B. wie durch Schleife 165 angegeben). Die durch den Pfeil 180 angegebene Abrechnungsantwortnachricht kann von PM 115 zurück zum NAS 110 gesendet werden, der dann (nicht in der Zeitachse 100 dargestellt) die Antwort (oder Informationen über die Antwort) an das Clientgerät 105 zurücksenden kann. Auf diese Weise kann die Verarbeitung parallelisiert werden, indem in der MMC verfügbare Informationen verwendet werden.
  • Zum Abschluss der Erörterung der Zeitachse 100 kann eine HTTP-GET-Anforderung (wie durch Pfeil 190 angegeben) für eine bestimmte Website Universal Resource Locator (URL) vom Clientgerät 105 aus erfolgen. Das Ergebnis ist eine Ablehnung in diesem Beispiel, da Firewall 2 (125) keinen Zugriff auf diese URL gewährt. Die Ablehnung kann durch einen Mangel an ordnungsgemäßer Authentifizierung verursacht werden oder weil die dem Benutzer und / oder Clientgerät 105 zugeordnete Rolle (wie durch Firewall 2 (125) bekannt) nicht zur Interaktion mit dieser URL berechtigt ist. In beiden Fällen führt die Zurückweisung dazu, dass eine HTTP: Error Forbidden-Antwortnachricht, wie durch Pfeil 195 angezeigt, an das Clientgerät 105 zurückgesendet wird.
  • Unter Bezugnahme auf 2 wird ein beispielhaftes vernetztes System 200 beschrieben, indem ausgewählte Beziehungen zwischen Komponenten einer beispielhaften Implementierung eines PM-Systems und anderen Computersystemen gezeigt werden, die typischerweise in einer Unternehmensnetzwerkinfrastruktur gemäß einer oder mehreren offenbarten Implementierungen zu finden sind. Insbesondere beschreibt das vernetzte System 200 ein PM-System (z. B. PM-Knoten 1-5 (210-1 bis 210-5)), das als Cluster implementiert ist, wobei jeder PM-Knoten (210-1 bis 120-5) des verteilten PM-Systems aufweist Zugriff auf einen verteilten Datenspeicher 220 (z. B. eine MMC wie oben beschrieben). In diesem Beispiel kann jeder PM-Knoten (210-1 bis 120-5) des verteilten PM-Systems mit anderen Netzwerkgeräten (z. B. Firewall 230 und Anwendungscluster 235) unter Verwendung einer RADIUS-Protokollschnittstelle interagieren, um Informationen aus dem verteilten Datenspeicher bereitzustellen 220.
  • Wie in dem Netzwerksystem 200 dargestellt, sind mehrere Clientgeräte 205 als Schnittstelle zu ausgewählten Instanzen von PM-Knoten (210-1 bis 210-5) dargestellt. Es ist zu beachten, dass der Klarheit halber die zuvor beschriebenen NAS-Instanzen im Netzwerksystem 200 nicht vollständig dargestellt sind. Ein Beispiel NAS 206 ist für den PM-Knoten 3 (210-3) dargestellt, und andere Instanzen von PM-Knoten können ähnlich konfiguriert sein. Wie oben erläutert, kann der NAS 206 als zwischengeschaltetes Netzwerkgerät zwischen den Clientgeräten 205-3 und dem PM-Knoten 3 (210-3) fungieren, und ähnliche zwischengeschaltete Geräte können vorhanden sein, um andere PM-Knoten wie gewünscht zu unterstützen. In dem vernetzten System 200 können Client-Geräte 205-1 eine Schnittstelle mit dem PM-Knoten 1 (210-1) und dem PM-Knoten 1 (210-1) über eine bidirektionale Verbindung 215-1 mit dem verteilten Datenspeicher 220 verbinden. In ähnlicher Weise können Client-Geräte 205-2 eine Schnittstelle mit dem PM-Knoten 2 (210-2) und dem PM-Knoten 2 (210-2) über eine bidirektionale Verbindung 215-2 mit dem verteilten Datenspeicher 220 verbinden. Jedes der Client-Geräte 205-4 und Client-Geräte 205-4 ist jeweils mit dem PM-Knoten 4 (210-4) und dem PM-Knoten 5 (210-5) verbunden, die wiederum bidirektionale Verbindungen 215-4 und 215-5 verwenden (jeweils wieder), um auf den verteilten Datenspeicher 220 zuzugreifen. Wie hierin erläutert, ist es möglich, dass ein bestimmtes Clientgerät zu verschiedenen Zeitpunkten für eine einzelne authentifizierte Sitzung mit mehreren verschiedenen Instanzen eines PM-Knotens interagieren kann. Das heißt, eine Instanz eines Clientgeräts kann eine erste Handshake-Interaktion mit einer ersten Instanz eines PM-Knotens ausführen und (innerhalb derselben authentifizierten Sitzung) eine zweite Handshake-Interaktion mit einer zweiten, anderen Instanz eines PM-Knotens durchführen. Somit kann ein Lastausgleich für PM-Funktionen erreicht werden, die mehrere Clientgeräte innerhalb eines Unternehmensinfrastrukturnetzwerks unterstützen. Ferner verbessert der verteilte Datenspeicher 220 die Fähigkeit, die PM-Funktionalität auszugleichen, teilweise, weil jede Instanz eines PM-Knotens (210-1 bis 210-5) eine konsistente Kopie von Informationen innerhalb des verteilten Datenspeichers 220 verwaltet (z. B. durch unter Verwendung einer Implementierung einer MMC wie hierin beschrieben).
  • 2 zeigt auch eine Beziehung zwischen jeder Instanz eines PM-Knotens (210-1 bis 210-5) und dem verteilten Datenspeicher 220, auf den jeder der PM-Knoten 201-1 bis 210-5 zugreifen kann. Es ist auch zu beachten, dass das gestrichelte Kästchen des PM-Knotens N 226 im Netzwerksystem 200 zweimal erscheint und verwendet wird, um eine indirekte Beziehung (z. B. Links 225-1 und 225-2) zu Daten aus dem verteilten Datenspeicher 220 aus dem Anwendungscluster 235 und der Firewall zu veranschaulichen 230 jeweils. Diese indirekte Beziehung wurde oben beschrieben und stellt dar, dass, obwohl der Anwendungscluster 235 und die Firewall 230 keinen direkten Zugriff auf den verteilten Datenspeicher 220 haben, Informationen vom verteilten Datenspeicher 220 über RADIUS-Protokollnachrichten von einem geeigneten PM-Knoten an einen anderen bereitgestellt werden können Knoten des vernetzten Systems 200. Insbesondere können Datensätze innerhalb des verteilten Datenspeichers 220 mit Informationen ergänzt werden, die von einem PM-System verwaltet und den anderen Knoten des Netzwerksystems 200 bereitgestellt werden, die zum Verstehen von RADIUS-Protokollnachrichten ausgestattet sind. Auf diese Weise können Informationen von einem verteilten PM-System, wie es in dem vernetzten System 200 dargestellt ist, mit Knoten geteilt werden, die keinen direkten Zugriff auf den verteilten Datenspeicher 220 haben (z. B. eine MMC wie oben beschrieben).
  • Im Allgemeinen können Instanzen jedes PM-Knotens 210-1 bis 210-5 den verteilten Datenspeicher 220 als ihren Backend-Datenspeicher behandeln und eine interne Integrationsschicht verwenden, um Informationen im gesamten Cluster zu verbreiten. Außerdem kann jede Instanz eines PM-Knotens 210-1 bis 210-5 ein RADIUS-Protokoll verwenden, um eine Weitergabe durch Proxy an alle anderen Knoten des Netzwerksystems 200 bereitzustellen. Jede Instanz eines PM-Knotens 210-1 bis 210-5 kann Aktualisierungen von anderen RADIUS-Implementierungen über einen Proxy empfangen und ihre eigenen Aktualisierungen unter Verwendung von RADIUS-Implementierungen über einen Proxy an andere Computersysteme weitergeben. Wenn jedoch eine Instanz eines PM-Knotens (z. B. PM-Knoten 2 (210-2)) eine Aktualisierung für eine andere Instanz eines PM-Knotens (z. B. PM-Knoten 4 (210-4)) bereitstellen möchte, kann dies eine Aktualisierung sein bereitgestellt durch Weitergabe von Daten innerhalb des verteilten Datenspeichers 220 (z. B. einer MMC), der einen effizienteren Mechanismus zum Teilen von Daten darstellen kann als die Verwendung von RADIUS-Nachrichten. Es ist auch zu beachten, dass, obwohl der verteilte Datenspeicher 220 als eine zentrale eigenständige Einheit in 1 dargestellt ist. In 2 dient dies nur zur Veranschaulichung (dh es handelt sich um eine logische Darstellung). In einer tatsächlichen Implementierung des Netzwerksystems 200 gibt es möglicherweise kein zentrales Repository, da jede Instanz eines PM-Knotens 210-1 bis 210-5 eine lokal synchronisierte Kopie von Daten in einem internen (oder lokal zugänglichen) Speicher für die Leistung oder andere verwalten kann Gründe dafür.
  • Unter Bezugnahme auf 3 ist ein Flussdiagramm dargestellt, um ein beispielhaftes Verfahren 300 zu skizzieren, das es einem Client-Gerät ermöglicht, eine Authentifizierungsanforderung zu stellen (z. B. eine Handshake-Interaktion durchzuführen, wie hierin diskutiert), gemäß einer oder mehreren offenbarten Implementierungen. Aktionen des beispielhaften Verfahrens 300 können in einer anderen Reihenfolge als den in 1 dargestellten durchgeführt werden. 3 und einige Aktionen können möglicherweise parallel ausgeführt werden. Das beispielhafte Verfahren 300 kann eine Implementierung von RADIUS verwenden, die mit einer verteilten PM-Funktionalität zusammenarbeitet, um die Fähigkeiten zu erweitern, die typischerweise in einer Standardimplementierung unter Verwendung des RADIUS-Protokolls verfügbar sind. Das beispielhafte Verfahren 300 beginnt bei Block 305, wo ein Client-Gerät (z. B. das Client-Gerät 105 von 1) eine EAPoL-Anforderung an einen NAS (z. B. NAS 110 von 1) zur Authentifizierung senden kann. Block 310 zeigt an, dass der NAS ferner einen von RADIUS oder einem anderen Netzwerkprotokoll definierten Zugriffsanforderungsaufruf an eine Instanz der beispielhaften verteilten PM-Implementierung (beispielsweise als PM 115 von 1 dargestellt) initiieren kann, die innerhalb eines Clusters oder eines anderen arbeitet Computergeräte eines Unternehmensnetzwerks. Die verteilte PM-Implementierung bietet Sicherheit und überwacht die Aktivitäten von Geräten und Benutzern in einem Unternehmensnetzwerk (oder anderen Netzwerktypen). Die Entscheidung 315 zeigt an, dass eine Antwort auf die Zugriffsanforderung analysiert werden kann, um verschiedene mögliche Flusspfade zu bestimmen, beispielsweise das Verfahren 300.
  • Wenn die Entscheidung 315 bestimmt, dass die Antwort des PM-Knotens ein Access-Challenge-Typ ist, fährt der Fluss mit Block 320 fort. Block 320 zeigt an, dass die Access-Challenge-Antwort an den NAS zurückgegeben und dann an das entsprechende Clientgerät zurückgesendet werden kann, das zu Block 305 zurückkehrt. Bei einer Rückkehr von Block 320 kann ein Clientgerät die Antwort verarbeiten, um die Authentifizierungsanforderung basierend auf der Herausforderung abzuschließen. Beispielsweise kann ein Clientgerät Informationen basierend auf der Herausforderung ändern und eine andere Anforderung versuchen.
  • Wenn alternativ die Entscheidung 315 die Antwort des PM-Knotens bestimmt, ein Access-Reject-Typ ist, fährt der Fluss mit Block 325 fort. In Block 325 kann die Access-Reject-Antwort an den NAS zurückgegeben und letztendlich dem Client-Gerät bereitgestellt werden. In einer typischen Implementierung gibt eine Access-Reject-Antwort eine Fehlerbedingung an das Clientgerät zurück und beendet eine Iteration der Beispielmethode 300 in einem Fehlerzustand.
  • Als dritte mögliche Bestimmung aus Entscheidung 315, wenn die Antwort des PM-Knotens eine Antwort vom Typ Access-Accept darstellt, fährt der Fluss mit Block 330 fort. Wie in Block 330 angegeben, werden Benutzer- und Sitzungsinformationen, wie z. B. Rolle und andere Attribute, für verwendet Die Autorisierung kann im gemeinsam genutzten Distributions-Repository (z. B. der MMC) aktualisiert werden. Der Fluss aus Block 330 weist zwei mögliche Pfade auf, die abhängig von einer Art der Implementierung eines PM-Knotens entweder seriell oder parallel ausgeführt werden können. Block 335 zeigt an, dass die Benutzer- und Sitzungsinformationen dann über Datenausbreitungstechniken, die die Synchronisation des gruppierten In-Memory-Cache beinhalten, an andere PM-Knoten des Clusters weitergegeben werden können. Seriell oder gleichzeitig mit der Verarbeitung von Block 335 zeigt Block 340 an, dass die Access-Accept-Antwort an den NAS und letztendlich an das Client-Gerät zurückgegeben werden kann. Der NAS kann einfach eine Access-Accept-Antwort weiterleiten oder die Access-Accept-Antwort verarbeiten und Informationen senden, die angeben, dass die Authentifizierungsanforderung gewährt wurde. Das Empfangen einer Bedingung für die Gewährung eines Zugriffs kann es dem Client-Gerät ermöglichen, mit einer angeforderten Operation fortzufahren (z. B. Zugriff auf Es kann ein Dienst gewährt, der Zugriff auf eine URL gewährt und Informationen für diese URL zurückgegeben werden.
  • Unter Bezugnahme auf 4 ist ein Flussdiagramm dargestellt, um ein Beispielverfahren 400 zu erläutern, bei dem einem authentifizierten Clientgerät eine oder mehrere Abrechnungsanforderungen zugeordnet sein können, die von der Beispielimplementierung eines verteilten PM-Systems verarbeitet werden. Diese eine oder mehreren Abrechnungsanforderungen können zumindest teilweise unter Verwendung eines RADIUS-Protokolls verarbeitet werden, damit ein PM-System mit anderen Computergeräten interagieren kann, die in einem Unternehmensnetzwerk verfügbar sind. Aktionen des beispielhaften Verfahrens 400 können in einer anderen Reihenfolge als den in 1 dargestellten durchgeführt werden. 4 und einige Aktionen können parallel ausgeführt werden.
  • In dem beispielhaften Verfahren 400 kann ein PM-System implementiert werden, um Informationen zu nutzen, die über das verteilte PM-System verbreitet werden (z. B. in einem CCM verfügbar), um über über das RADIUS-Protokoll definierte Funktionen mit anderen Computersystemen (z. B. Firewalls) weiter zu interagieren.. Das beispielhafte Verfahren 400 beginnt bei Block 405, wo ein NAS periodisch (oder bei Bedarf) Informationen an ein verteiltes PM-System liefern kann (z. B. im Namen eines zugeordneten Clientgeräts, das bereits bei einem Netzwerk authentifiziert ist). Diese Aktualisierungen können fortgesetzt werden, bis ein Client die Verbindung zum NAS trennt. Im Allgemeinen kann ein Clientgerät nach der Authentifizierung Aktionen ausführen, die zu einer Abrechnungsanforderung führen, die möglicherweise einem Standard-RADIUS-Protokoll entspricht. In regelmäßigen Abständen (oder bei Bedarf) kann ein NAS Buchhaltungsaktualisierungen an einen PM-Knoten eines verteilten PM-Systems senden. Der Fluss fährt mit dem Block 410 fort, der angibt, dass ein PM-Knoten (z. B. eines verteilten PM-Systems) eine lokale Instanz eines verteilten Datenspeichers abfragen kann, die eine Implementierung eines Multi-Master-Caches wie der oben beschriebenen MMC sein kann. Die Abfrage kann Sitzungsinformationen eines Benutzers abrufen, der sich über den NAS bei einem Netzwerk auf einem bestimmten Endbenutzergerät authentifiziert hat. Block 415 gibt an, dass der Typ der Buchhaltungsanforderung entweder darin bestehen kann, Informationen über eine Benutzersitzung zu aktualisieren oder eine Benutzersitzung zu beenden.
  • Wenn die Anforderung in Entscheidung 415 als Aktualisierung bestimmt wird, fährt der Fluss mit Block 420 fort, in dem ein PM-Knoten (der ein anderer Knoten sein kann als der, der zuvor für diese bestimmte Benutzerauthentifizierungssitzung mit diesem Client interagiert hat) Autorisierungswerte hinzufügen kann (z , AAA-Informationen wie oben beschrieben) für den Benutzer. Die Berechtigungswerte können einem konfigurierten Radiusattribut hinzugefügt werden, das in einer MMC gespeichert ist. Bei Block 420 gibt es zwei mögliche Austrittspfade, die parallel oder seriell ausgeführt werden können. Block 430 zeigt an, dass Aktualisierungen einer MMC über alle Instanzen einer MMC (oder eines anderen verteilten Datenspeichers) innerhalb des Clusters oder der verteilten PM-Implementierung weitergegeben werden können. Block 435 zeigt an, dass ein PM-Knoten dieselben Aktualisierungen (oder einen Teil davon im gleichen oder einem anderen Format) über ein Netzwerkkommunikationsprotokoll (z. B. RADIUS) auch an andere verbundene Geräte weitergeben und eine oder mehrere Autorisierungsanforderungen über weiterleiten kann Proxy. Auf diese Weise können Informationen an externe Server weitergegeben werden, die nicht unbedingt Zugriff auf eine MMC haben. Block 445 zeigt an, dass der PM-Knoten nicht auf die Antworten auf diese Proxy-Anforderungen warten muss, da sie möglicherweise asynchron zu anderen Aktionen verarbeitet werden. Natürlich ist es möglich, dass der PM-Knoten in einigen Implementierungen auf eine Bestätigung wartet. Flow verlässt dann Block 445, um zu Block 450 zu gelangen, wo der PM-Knoten (oder ein anderer Knoten im PM-Cluster) Informationen über die Abrechnungsantwort an das anfänglich anfordernde Clientgerät zurückgeben kann. Diese Rückgabe von Informationen an das Clientgerät kann optional direkt an den Client oder in einigen Fällen über den NAS gesendet werden.
  • Zurück zur Entscheidung 415: Wenn festgestellt wird, dass die an den PM-Knoten gesendete Anforderung eine Stoppanweisung ist (z. B. Beendigung der Aktivität oder Sitzung), fährt der Fluss mit Block 425 fort. Block 425 hat zwei verschiedene mögliche Austrittspfade (ähnlich wie Block 420, wie oben diskutiert), die parallel oder nacheinander ausgeführt werden können. Wie oben erwähnt, gibt Block 430 an, dass Aktualisierungen einer MMC über alle Instanzen einer MMC (oder eines anderen verteilten Datenspeichers) innerhalb des Clusters oder der verteilten PM-Implementierung weitergegeben werden können. Block 440 zeigt an, dass ein PM-Knoten dieselben Aktualisierungen zum Herunterfahren der Sitzung (oder einen Teil davon im gleichen oder einem anderen Format) über ein Netzwerkkommunikationsprotokoll (z. B. RADIUS) auch an andere verbundene Geräte weitergeben kann. Aktualisierungen beim Herunterfahren können auf das Löschen von Informationen zu einer abgebrochenen Aktivität oder Sitzung hinweisen. Zusätzlich kann eine Anweisung zum Löschen von Sitzungsinformationen auch über einen Proxy weitergeleitet werden. Auf diese Weise können Informationen an externe Server weitergegeben werden, die nicht unbedingt Zugriff auf eine MMC haben. Block 445 und Block 450 schließen den Prozess der Sitzungsaktualisierung auf ähnliche Weise wie oben bereits beschrieben ab.
  • 5 ist eine beispielhafte Rechenvorrichtung 500 mit einem Hardwareprozessor 501 und zugänglichen maschinenlesbaren Anweisungen, die auf einem maschinenlesbaren Medium 502 zum Implementieren der Verwaltung eines verteilten PM-Systems gemäß einer oder mehreren offenbarten Beispielimplementierungen gespeichert sind. 5 zeigt als Beispiel das Computergerät 500, das dafür konfiguriert ist, den Ablauf des Verfahrens 300 durchzuführen. Das Computergerät 500 kann jedoch auch dafür konfiguriert werden, den in dieser Offenbarung beschriebenen Ablauf anderer Methoden, Techniken, Funktionen oder Prozesse durchzuführen. In diesem Beispiel von 3 umfasst das maschinenlesbare Speichermedium 502 Anweisungen, um den Hardware-Prozessor 501 zu veranlassen, die oben unter Bezugnahme auf 3 besprochenen Blöcke 305-340 auszuführen.
  • 6 ist eine beispielhafte Rechenvorrichtung 600 mit einem Hardwareprozessor 601 und zugänglichen maschinenlesbaren Anweisungen, die auf einem maschinenlesbaren Medium 602 gespeichert sind, um alternative Techniken und Verfahren zu implementieren, die dem oben beschriebenen verteilten PM-System gemäß einem oder mehreren offenbarten Beispielen zugeordnet sind Implementierungen. 6 zeigt als Beispiel das Computergerät 600, das dafür konfiguriert ist, den Ablauf des Verfahrens 400 durchzuführen. Das Computergerät 600 kann jedoch auch dafür konfiguriert werden, den in dieser Offenbarung beschriebenen Ablauf anderer Methoden, Techniken, Funktionen oder Prozesse durchzuführen. In diesem Beispiel von 4 umfasst das maschinenlesbare Speichermedium 602 Anweisungen, um den Hardware-Prozessor 601 zu veranlassen, die oben unter Bezugnahme auf 4 besprochenen Blöcke 405-450 auszuführen.
  • Ein maschinenlesbares Speichermedium, wie z. B. 502 in 602, kann sowohl flüchtige als auch nicht-flüchtige, austauschbare und nicht austauschbare Medien umfassen und kann jedes elektronische, magnetische, optische oder andere physische Speichergerät sein, das ausführbare Anweisungen, Datenstrukturen, Programmodul oder andere Daten enthält oder speichert, auf die ein Prozessor zugreifen kann, z. B. Firmware, löschbarer programmierbarer Festwertspeicher (EPROM), Direktzugriffsspeicher (RAM), nicht-flüchtiger Direktzugriffsspeicher (NVRAM), optische Platte, Festkörperlaufwerk (SSD), Flash-Speicherchips und ähnliches. Bei dem maschinenlesbaren Speichermedium kann es sich um ein nicht-flüchtiges Speichermedium handeln, wobei der Begriff „nichtflüchtig“ keine flüchtigen Ausbreitungssignale umfasst.
  • 7 stellt eine Computernetzwerkinfrastruktur 700 dar, die verwendet werden kann, um die offenbarte Technik zur Verteilung von Benutzersitzungsinformationen, die von AAA-Funktionen (z. B. einem verteilten PM-System, wie oben diskutiert) bereitgestellt werden, ganz oder teilweise zu implementieren, die in einem Netzwerksicherheitsprotokoll definiert sind, wie z RADIUS über einen hochverteilten verteilten In-Memory-Cache (z. B. ein CCM) oder Bereitstellung eines Informationsflusses zwischen einem System, das die offenbarten Techniken ausführt, und anderen Computernetzwerken gemäß einer oder mehreren offenbarten Implementierungen. Die Netzwerkinfrastruktur 700 umfasst eine Reihe von Netzwerken, in denen Ausführungsformen der vorliegenden Offenbarung arbeiten können. Die Netzwerkinfrastruktur 700 umfasst ein Kundennetzwerk 702, Netzwerk 708, Mobilfunknetz 703 und ein Cloud-Service-Provider-Netzwerk 710. In einer Ausführungsform kann das Kundennetzwerk 702 ein lokales privates Netzwerk sein, wie z. B. ein Local Area Network (LAN), das verschiedene Netzwerkgeräte wie z. B. Switches, Server und Router umfasst, aber nicht auf diese beschränkt ist.
  • Jedes dieser Netzwerke kann drahtgebundene oder drahtlose programmierbare Geräte enthalten und mit einer beliebigen Anzahl von Netzwerkprotokollen (z. B. TCP/IP) und Verbindungstechnologien (z. B. WiFi®-Netzwerke oder Bluetooth®) arbeiten. In einer anderen Ausführungsform stellt das Kundennetzwerk 702 ein Unternehmensnetzwerk dar, das ein oder mehrere lokale Netzwerke (LANs), virtuelle Netzwerke, Datenzentren und/oder andere entfernte Netzwerke (z. B. 708, 710) umfassen oder mit diesen kommunikativ gekoppelt sein könnte. Im Zusammenhang mit der vorliegenden Offenbarung kann das Kundennetzwerk 702 eine Netzwerkvorrichtung enthalten, die einen verteilten CCM-Datenspeicher wie den oben beschriebenen unterstützt.
  • Wie in 7 dargestellt, kann das Kundennetzwerk 702 mit einem oder mehreren Client-Geräten 704A-E verbunden werden und es den Client-Geräten 704A-E ermöglichen, über das Netzwerk 708 (z. B. Internet) miteinander und/oder mit dem Netzwerk 710 des Cloud-Service-Providers zu kommunizieren. Bei den Client-Geräten 704A-E kann es sich um Computersysteme wie Desktop-Computer 704B, Tablet-Computer 704C, Mobiltelefon 704D, Laptop-Computer (als drahtlos gezeigt) 704E und/oder andere Arten von Computersystemen handeln, die generisch als Client-Gerät 704A dargestellt werden. Client-Geräte 704A-E können einen oder mehrere zugeordnete Benutzer (nicht gezeigt) haben, die bei einem Netzwerk authentifiziert werden können, und auf Dienste zugreifen, die von einem PM-System wie dem oben beschriebenen verwaltet werden.
  • Die Netzwerkinfrastruktur 700 kann auch andere Arten von Geräten umfassen, die allgemein als Internet der Dinge (loT) bezeichnet werden (z. B. Edge-IOT-Gerät 705), die dafür konfiguriert werden können, Informationen über ein Netzwerk zu senden und zu empfangen, um auf Cloud-Computing-Dienste zuzugreifen oder mit einer Remote-Web-Browser-Anwendung zu interagieren (z. B. um Konfigurationsinformationen zu empfangen).
  • 7 zeigt auch, dass das Kundennetzwerk 702 lokale Computing-Ressourcen 706A-C umfasst, die einen Server, Zugangspunkt, Router oder ein anderes Gerät umfassen können, das dafür konfiguriert ist, lokale Computing-Ressourcen bereitzustellen und/oder die Kommunikation zwischen Netzwerken und Geräten zu erleichtern. Beispielsweise kann es sich bei den lokalen Computing-Ressourcen 706A-C um ein oder mehrere physische lokale Hardware-Geräte handeln, wie z. B. die oben beschriebenen HA-Switches. Lokale Computing-Ressourcen 706A-C können auch die Kommunikation zwischen anderen externen Anwendungen, Datenquellen (z. B. 707A und 707B) und Diensten sowie dem Kundennetzwerk 702 erleichtern. Die Rechenressourcen 706A-C können als ein Satz von Clusterknoten konfiguriert sein, um gemeinsam eine Anwendungsfunktion auszuführen.
  • Die Netzwerkinfrastruktur 700 umfasst auch das Mobilfunknetz 703 zur Verwendung mit mobilen Kommunikationsgeräten. Mobilfunknetze unterstützen Mobiltelefone und viele andere Arten von mobilen Geräten wie Laptops usw. Mobile Geräte in der Netzinfrastruktur 700 werden als Mobiltelefon 704D, Laptop 704E und Tablet-Computer 704C dargestellt. Ein mobiles Gerät, wie z. B. das Mobiltelefon 704D, kann mit einem oder mehreren Netzen von Mobilfunkanbietern interagieren, wenn sich das mobile Gerät bewegt. Üblicherweise interagiert es mit einer Vielzahl von Mobilfunknetztürmen 720, 730 und 740 zur Verbindung mit dem Mobilfunknetz 703.
  • 7 zeigt, dass das Kundennetzwerk 702 mit einem Netzwerk 708 gekoppelt ist. Das Netzwerk 708 kann ein oder mehrere heute verfügbare Computernetzwerke umfassen, wie z. B. andere LANs, Wide Area Networks (WAN), das Internet und/oder andere Remote-Netzwerke, um Daten zwischen den Client-Geräten 704A-D und dem Netzwerk 710 des Cloud-Service-Providers zu übertragen. Jedes der Computernetzwerke im Netzwerk 708 kann drahtgebundene und/oder drahtlose programmierbare Geräte enthalten, die im elektrischen und/oder optischen Bereich arbeiten.
  • In 7 wird das Cloud-Service-Provider-Netzwerk 710 als ein Remote-Netzwerk (z. B. ein Cloud-Netzwerk) dargestellt, das in der Lage ist, über das Kundennetzwerk 702 und das Netzwerk 708 mit den Client-Geräten 704A-E zu kommunizieren. Das Cloud-Service-Provider-Netzwerk 710 fungiert als Plattform, die zusätzliche Computing-Ressourcen für die Client-Geräte 704A-E und/oder das Kundennetzwerk 702 bereitstellt. In einer Ausführungsform umfasst das Cloud-Service-Provider-Netzwerk 710 ein oder mehrere Rechenzentren 712 mit einer oder mehreren Server-Instanzen 714. Das Cloud-Service-Provider-Netzwerk 710 kann auch einen oder mehrere Frames oder Cluster (und Cluster-Gruppen) umfassen, die eine skalierbare Computing-Ressource darstellen, die von den Techniken dieser Offenbarung profitieren kann.
  • 8 zeigt ein Computergerät 800, das zur Implementierung oder zusammen mit den Funktionen, Modulen, Verarbeitungsplattformen, Ausführungsplattformen, Kommunikationsgeräten und anderen Verfahren und Prozessen dieser Offenbarung verwendet werden kann. Zum Beispiel könnte das in 8 dargestellte Computergerät 800 ein Client-Gerät oder ein physisches Server-Gerät darstellen und je nach Abstraktionsgrad des Computergeräts entweder Hardware oder virtuelle(n) Prozessor(en) enthalten. In einigen Fällen (ohne Abstraktion) beziehen sich das Computergerät 800 und seine Elemente, wie in 8 gezeigt, jeweils auf physische Hardware. Alternativ könnten in einigen Fällen ein, mehrere oder alle Elemente unter Verwendung von Emulatoren oder virtuellen Maschinen als Abstraktionsebenen implementiert werden. Unabhängig davon, wie viele Abstraktionsebenen von der physischen Hardware entfernt sind, kann in jedem Fall das Computergerät 800 auf seiner untersten Ebene auf physischer Hardware implementiert werden.
  • Wie auch in 8 dargestellt, kann das Computergerät 800 ein oder mehrere Eingabegeräte 830, wie z. B. Tastatur, Maus, Touchpad oder Sensoranzeige (z. B. biometrischer Scanner) und ein oder mehrere Ausgabegeräte 815, wie z. B. Displays, Lautsprecher für Audio oder Drucker, umfassen. Einige Geräte können auch als Ein-/Ausgabegeräte konfiguriert sein (z. B. eine Netzwerkschnittstelle oder ein Touchscreen-Display).
  • Das Computergerät 800 kann auch Kommunikationsschnittstellen 825 umfassen, wie z. B. eine Netzwerkkommunikationseinheit, die eine verdrahtete Kommunikationskomponente und/oder eine drahtlose Kommunikationskomponente enthalten kann, die kommunikativ mit dem Prozessor 805 gekoppelt sein kann. Die Netzwerkkommunikationseinheit kann verschiedene proprietäre oder standardisierte Netzwerkprotokolle wie Ethernet, TCP/IP, um nur einige von vielen Protokollen zu nennen, für die Kommunikation zwischen Geräten verwenden. Netzwerkkommunikationseinheiten können auch einen oder mehrere Transceiver umfassen, die Ethernet, Power Line Communication (PLC), WiFi, Mobilfunk- und/oder andere Kommunikationsverfahren verwenden.
  • Wie in 8 gezeigt, umfasst das Computergerät 800 ein Verarbeitungselement wie den Prozessor 805, der einen oder mehrere Hardware-Prozessoren enthält, wobei jeder Hardware-Prozessor einen einzelnen oder mehrere Prozessorkerne haben kann. In einer Ausführungsform kann der Prozessor 805 mindestens einen gemeinsam genutzten Cache enthalten, der Daten (z. B. Rechenanweisungen) speichert, die von einer oder mehreren anderen Komponenten des Prozessors 805 verwendet werden. Beispielsweise kann der gemeinsam genutzte Cache ein lokal gecachter Datenspeicher sein, der in einem Speicher für einen schnelleren Zugriff von Komponenten der Verarbeitungselemente, aus denen der Prozessor 805 besteht, gespeichert ist. In einer oder mehreren Ausführungsformen kann der gemeinsam genutzte Cache einen oder mehrere Mid-Level-Caches enthalten, wie z. B. Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Level, einen Last-Level-Cache (LLC) oder Kombinationen davon. Beispiele für Prozessoren sind unter anderem eine zentrale Verarbeitungseinheit (CPU) und ein Mikroprozessor. Obwohl in nicht dargestellt, können die Verarbeitungselemente, aus denen der Prozessor 805 besteht, auch eine oder mehrere andere Arten von Hardware-Verarbeitungskomponenten enthalten, wie z. B. Grafikverarbeitungseinheiten (GPU), anwendungsspezifische integrierte Schaltungen (ASICs), feldprogrammierbare Gate-Arrays (FPGAs) und/oder digitale Signalprozessoren (DSPs).
  • 8 zeigt, dass der Speicher 810 operativ und kommunikativ mit dem Prozessor 805 gekoppelt werden kann. Der Speicher 810 kann ein nicht-flüchtiges Medium sein, das für die Speicherung verschiedener Datentypen konfiguriert ist. Zum Beispiel kann der Speicher 810 ein oder mehrere Speichergeräte 820 beinhalten, die ein nicht-flüchtiges Speichergerät und/oder einen flüchtigen Speicher umfassen. Ein flüchtiger Speicher, wie z. B. ein Direktzugriffsspeicher (RAM), kann jedes geeignete nicht-permanente Speichergerät sein. Zu den nicht-flüchtigen Speichergeräten 820 können ein oder mehrere Plattenlaufwerke, optische Laufwerke, Solid-State-Laufwerke (SSDs), Tap-Drives, Flash-Speicher, Nur-Lese-Speicher (ROM) und/oder jeder andere Speichertyp gehören, der dafür ausgelegt ist, Daten für eine bestimmte Zeit nach einem Stromausfall oder Abschaltvorgang zu erhalten. In bestimmten Fällen können die nicht-flüchtigen Speichergeräte 820 zur Speicherung von Überlaufdaten verwendet werden, wenn der zugewiesene RAM-Speicher nicht groß genug ist, um alle Arbeitsdaten aufzunehmen. Die nicht-flüchtigen Speichergeräte 820 können auch zum Speichern von Programmen verwendet werden, die in den RAM-Speicher geladen werden, wenn solche Programme zur Ausführung ausgewählt werden.
  • Fachleuten ist bekannt, dass Softwareprogramme in verschiedenen Computersprachen für verschiedene Softwareplattformen und/oder Betriebssysteme entwickelt, kodiert und kompiliert und anschließend vom Prozessor 805 geladen und ausgeführt werden können. In einer Ausführungsform kann der Kompilierungsprozess des Softwareprogramms den in einer Programmiersprache geschriebenen Programmcode in eine andere Computersprache umwandeln, sodass der Prozessor 805 in der Lage ist, den Programmcode auszuführen. Beispielsweise kann der Kompilierungsprozess des Softwareprogramms ein ausführbares Programm erzeugen, das kodierte Anweisungen (z. B. Maschinencode-Anweisungen) für den Prozessor 805 bereitstellt, um spezifische, nicht generische, bestimmte Rechenfunktionen zu erfüllen.
  • Nach dem Kompilierungsprozess können die kodierten Anweisungen dann als computerausführbare Anweisungen oder Prozessschritte vom Speichergerät 820, vom Speicher 810 und/oder eingebettet im Prozessor 805 (z. B. über einen Cache oder ein integriertes ROM) in den Prozessor 805 geladen werden. Der Prozessor 805 kann so konfiguriert werden, dass er die gespeicherten Anweisungen oder Prozessschritte ausführt, um Anweisungen oder Prozessschritte auszuführen, die das Computergerät in eine nicht generische, insbesondere speziell programmierte Maschine oder Vorrichtung umwandeln. Auf gespeicherte Daten, z. B. Daten, die auf einem Speichergerät 820 gespeichert sind, kann der Prozessor 805 während der Ausführung von computerausführbaren Anweisungen oder Prozessschritten zugreifen, um eine oder mehrere Komponenten innerhalb des Computergeräts 800 anzuweisen.
  • Eine Benutzerschnittstelle (z. B. Ausgabegeräte 815 und Eingabegeräte 830) kann ein Display, ein positionelles Eingabegerät (wie eine Maus, ein Touchpad, einen Touchscreen oder ähnliches), eine Tastatur oder andere Formen von Benutzereingabe- und Ausgabegeräten umfassen. Die Benutzerschnittstellenkomponenten können kommunikativ mit dem Prozessor 805 gekoppelt sein. Wenn das Ausgabegerät ein Display ist oder ein Display enthält, kann das Display auf verschiedene Weise implementiert werden, einschließlich durch eine Flüssigkristallanzeige (LCD) oder eine Kathodenstrahlröhre (CRT) oder eine Leuchtdiodenanzeige (LED), wie z. B. eine organische Leuchtdiodenanzeige (OLED). Fachleuten ist bekannt, dass das Computergerät 800 auch andere in der Technik bekannte Komponenten enthalten kann, wie z. B. Sensoren, Stromquellen und/oder Analog-Digital-Wandler, die nicht explizit in 8 dargestellt sind.
  • In dieser Beschreibung wurden bestimmte Begriffe verwendet, die sich auf bestimmte Systemkomponenten beziehen sollen. Wie ein Fachmann weiß, können verschiedene Parteien eine Komponente mit unterschiedlichen Namen bezeichnen. In diesem Dokument wird nicht zwischen Komponenten unterschieden, die sich im Namen unterscheiden, aber nicht funktionieren. In dieser Offenlegung und in den Ansprüchen werden die Begriffe „einschließlich“ und „umfassend“ in einer unbegrenzten Weise verwendet und sollten daher so ausgelegt werden, dass sie „einschließlich, aber nicht beschränkt auf...“ bedeuten. Auch der Begriff „Paar“ oder „Paare“ soll entweder eine indirekte oder direkte drahtgebundene oder drahtlose Verbindung bedeuten. Wenn also ein erstes Gerät mit einem zweiten Gerät koppelt, kann diese Verbindung durch eine direkte Verbindung oder durch eine indirekte Verbindung über andere Geräte und Verbindungen erfolgen. Mit der Formulierung „basierend auf ist” zumindest teilweise basierend auf gemeint. Wenn also X auf Y basiert, kann X eine Funktion von Y und einer beliebigen Anzahl anderer Faktoren sein.
  • Die obige Erörterung soll die Prinzipien und verschiedenen Implementierungen der vorliegenden Offenbarung veranschaulichen. Zahlreiche Variationen und Modifikationen werden für den Fachmann offensichtlich, sobald die obige Offenbarung vollständig erkannt ist. Es ist beabsichtigt, die folgenden Ansprüche so auszulegen, dass sie alle derartigen Variationen und Modifikationen umfassen.

Claims (20)

  1. Verfahren, Folgendes umfassend: Empfangen einer Zugriffsanforderungsnachricht, die einem Clientgerät und einem Benutzer des Clientgeräts zugeordnet ist, wobei die Zugriffsanforderungsnachricht den angeforderten Zugriff auf eine Netzwerkressource betrifft, die teilweise von einem mit einer Netzwerkinfrastruktur verbundenen PM-System (Policy Management) verwaltet wird ; Erhalten eines Attributs, das eine erste Richtlinienregel darstellt, die auf Ressourcenanforderungen vom Benutzer angewendet werden soll, wobei die erste Richtlinienregel eine Durchsetzungsrichtlinie des PM-Systems darstellt; Erweitern eines Datensatzes in einem verteilten Datenspeicher, auf den jeder von mehreren PM-Knoten zugreifen kann, der gemeinsam die Funktionalität des PM-Systems bereitstellt, wobei der Datensatz jede der mehreren PM-Knoteninformationen über das Attribut und die erste Richtlinienregel bereitstellt; und Weitergabe des Datensatzes über mehrere PM-Knoten des PM-Systems.
  2. Verfahren nach Anspruch 1, wobei der verteilte Datenspeicher einen Multi-Master-Cache mit einem lokal zugänglichen Datenspeicher für jeden der mehreren PM-Knoten des PM-Systems darstellt, um gemeinsame Informationen über Zustände von Clientgeräten und mehrere Richtlinienregeln aufrechtzuerhalten einschließlich der ersten Richtlinienregel, jeder der mehreren Richtlinienregeln, die vom PM-System durchgesetzt werden.
  3. Verfahren nach einem der Ansprüche 1 oder 2, wobei die Zugriffsanforderungsnachricht an einem ersten PM-Knoten der Vielzahl von PM-Knoten empfangen wird und das Attribut aus einer Datenbank außerhalb des ersten PM-Knotens erhalten wird, wobei die Datenbank enthält Informationen über eine Vielzahl von Richtlinienregeln, einschließlich der ersten Richtlinienregel.
  4. Verfahren nach einem der Ansprüche 1 bis 3, ferner umfassend: Teilen mindestens eines Teils der Informationen über das Attribut und die Richtlinienregel mit einem Infrastrukturgerät der Netzwerkinfrastruktur über eine RADIUS-Protokollnachricht (Remote Authentication Dial-In User Service).
  5. Verfahren nach Anspruch 4, wobei das Teilen mindestens des Teils der Information das Einbetten des Teils der Information in ein Segment der RADIUS-Protokollnachricht in Übereinstimmung mit einem Industriestandard für ein RADIUS-Protokoll umfasst.
  6. Verfahren nach einem der Ansprüche 4 oder 5, wobei das Infrastrukturgerät der Netzwerkinfrastruktur die Einhaltung der ersten Richtlinienregel basierend auf der RADIUS-Protokollnachricht bestimmt.
  7. Verfahren nach einem der Ansprüche 1 bis 6, wobei die Zugriffsanforderungsnachricht an einem ersten PM-Knoten der mehreren PM-Knoten empfangen wird und ferner umfasst: Empfangen einer Abrechnungsanforderungsnachricht an einem zweiten PM-Knoten der mehreren PM-Knoten; Aktualisieren des Datensatzes im verteilten Datenspeicher, um die Abrechnungsanforderungsnachricht widerzuspiegeln und einen aktualisierten Datensatz im verteilten Datenspeicher zu erstellen; und Weitergabe des aktualisierten Datensatzes über mehrere PM-Knoten des PM-Systems.
  8. Verfahren nach Anspruch 7, ferner umfassend: Teilen mindestens eines Teils der Informationen aus dem aktualisierten Datensatz mit einem Infrastrukturgerät der Netzwerkinfrastruktur über eine RADIUS-Protokollnachricht (Remote Authentication Dial-In User Service).
  9. Verfahren nach Anspruch 8, wobei das Infrastrukturgerät der Netzwerkinfrastruktur eine Firewall oder ein Netzwerkauthentifizierungsserver (NAS) ist.
  10. Verfahren nach Anspruch 9, wobei das Teilen des mindestens einen Teils der Informationen aus dem aktualisierten Datensatz von einem dritten PM-Knoten der Vielzahl von PM-Knoten durchgeführt wird, basierend auf Informationen, die von dem zweiten PM-Knoten weitergegeben werden.
  11. Verfahren nach einem der Ansprüche 8 bis 10, wobei die Leistung des dritten PM-Knotens der mehreren PM-Knoten durch eine Lastausgleichsfähigkeit des PM-Systems angezeigt wird.
  12. Verfahren nach einem der Ansprüche 1 bis 11, wobei jeder der mehreren PM-Knoten des PM-Systems Knoten einer Clusterkonfiguration sind, die implementiert sind, um gemeinsam die Funktionalität des PM-Systems als Hochverfügbarkeits- (HA-) PM-System bereitzustellen.
  13. Ein zu verwaltendes Netzwerkinfrastrukturgerät Authentifizierung, Autorisierung und Buchhaltung (AAA) Aktivitäten in einem ersten Netzwerk, wobei das Netzwerkinfrastrukturgerät Folgendes umfasst: eine Netzwerkschnittstelle, die kommunikativ mit dem ersten Netzwerk verbunden ist; eine Verarbeitungsvorrichtung, die kommunikativ mit der Netzwerkschnittstelle verbunden ist; und ein nicht vorübergehendes Speichermedium, das von der Verarbeitungsvorrichtung gelesen werden kann, und Speicheranweisungen, die bei Ausführung durch die Verarbeitungsvorrichtung bewirken, dass die Netzwerkinfrastrukturvorrichtung die Funktionalität eines ersten PM-Knotens einer Vielzahl von PM-Knoten bereitstellt, und: Empfangen einer Zugriffsanforderungsnachricht, die einem Clientgerät und einem Benutzer des Clientgeräts zugeordnet ist, wobei die Zugriffsanforderungsnachricht den angeforderten Zugriff auf eine Netzwerkressource des ersten Netzwerks betrifft und teilweise von einem Richtlinienverwaltungssystem (PM) verwaltet wird verbunden mit dem ersten Netzwerk; Erhalten eines Attributs, das eine erste Richtlinienregel darstellt, die auf Ressourcenanforderungen vom Benutzer angewendet werden soll, wobei die erste Richtlinienregel eine Durchsetzungsrichtlinie des PM-Systems darstellt; Erweitern eines Datensatzes in einem verteilten Datenspeicher, auf den jeder der mehreren PM-Knoten zugreifen kann, der gemeinsam die Funktionalität des PM-Systems bereitstellt, des Datensatzes, um jedem der mehreren PM-Knoten Informationen über das Attribut und die erste Richtlinienregel bereitzustellen; und Verteilen Sie den Datensatz über mehrere PM-Knoten des PM-Systems.
  14. Netzwerkinfrastrukturgerät nach Anspruch 13, wobei der verteilte Datenspeicher einen Multi-Master-Cache mit einem lokal zugänglichen Datenspeicher für jeden der mehreren PM-Knoten des PM-Systems darstellt, um gemeinsam genutzte Informationen über Zustände von Clientgeräten und mehrere Richtlinienregeln einschließlich der ersten Richtlinienregel zu verwalten; jede der mehreren Richtlinienregeln, die vom PM-System durchgesetzt werden.
  15. Netzwerkinfrastrukturvorrichtung nach einem der Ansprüche 13 oder 14, wobei die Anweisungen ferner Anweisungen umfassen, um die Netzwerkinfrastrukturvorrichtung zu veranlassen: Teilen Sie mindestens einen Teil der Informationen über das Attribut und die Richtlinienregel über eine RADIUS-Protokollnachricht (Remote Authentication Dial-In User Service) mit einem anderen Infrastrukturgerät der Netzwerkinfrastruktur.
  16. Netzwerkinfrastrukturvorrichtung nach einem der Ansprüche 13 bis 15, wobei die Anweisungen ferner Anweisungen umfassen, um zu bewirken, dass die Netzwerkinfrastrukturvorrichtung: Empfangen von Daten bezüglich einer Abrechnungsanforderungsnachricht, die an einem zweiten PM-Knoten der Vielzahl von PM-Knoten verarbeitet wird, über die Weitergabe von Datenspeichern; und Aktualisieren einer lokalen Instanz des verteilten Datenspeichers, um die Abrechnungsanforderungsnachricht wiederzugeben, und Erstellen eines aktualisierten Datensatzes im verteilten Datenspeicher; und leiten die Daten bezüglich der Abrechnungsanforderung an einen dritten PM-Knoten der mehreren PM-Knoten weiter.
  17. Netzwerkinfrastrukturvorrichtung nach Anspruch 16, wobei die Anweisungen ferner Anweisungen umfassen, um die Netzwerkinfrastrukturvorrichtung zu veranlassen: Teilen Sie mindestens einen Teil der Informationen aus dem aktualisierten Datensatz mit einem anderen Infrastrukturgerät der Netzwerkinfrastruktur über eine RADIUS-Protokollnachricht (Remote Authentication Dial-In User Service).
  18. Netzwerkinfrastrukturgerät nach Anspruch 17, wobei das unterschiedliche Infrastrukturgerät der Netzwerkinfrastruktur eine Firewall oder ein Netzwerkauthentifizierungsserver (NAS) ist.
  19. Ein nicht vorübergehendes computerlesbares Medium, das darauf gespeicherte Anweisungen enthält, die, wenn sie von einem Prozessor eines ersten Netzwerkinfrastrukturgeräts ausgeführt werden, bewirken, dass das erste Netzwerkinfrastrukturgerät: Empfangen einer Zugriffsanforderungsnachricht, die einem Clientgerät und einem Benutzer des Clientgeräts zugeordnet ist, wobei die Zugriffsanforderungsnachricht den angeforderten Zugriff auf eine Netzwerkressource eines ersten Netzwerks betrifft und teilweise von einem Richtlinienverwaltungssystem (PM) verwaltet wird verbunden mit dem ersten Netzwerk; Erhalten eines Attributs, das eine erste Richtlinienregel darstellt, die auf Ressourcenanforderungen vom Benutzer angewendet werden soll, wobei die erste Richtlinienregel eine Durchsetzungsrichtlinie eines verteilten PM-Systems darstellt; Erweitern eines Datensatzes in einem verteilten Datenspeicher, auf den jeder von mehreren PM-Knoten zugreifen kann, der gemeinsam die Funktionalität des verteilten PM-Systems bereitstellt, des Datensatzes, um jede der mehreren PM-Knoteninformationen über das Attribut und die erste Richtlinienregel bereitzustellen; den Datensatz über die Vielzahl von PM-Knoten des verteilten PM-Systems verbreiten; und Teilen Sie mindestens einen Teil der Informationen über das Attribut und die erste Richtlinienregel mit einem zweiten Infrastrukturgerät des ersten Netzwerks über eine RADIUS-Protokollnachricht (Remote Authentication Dial-In User Service).
  20. Nicht-vorübergehendes computerlesbares Medium nach Anspruch 19, wobei die Zugriffsanforderungsnachricht an einem ersten PM-Knoten der Vielzahl von PM-Knoten empfangen wird und ferner Anweisungen umfasst, um das Netzwerkinfrastrukturgerät zu veranlassen: Empfangen von Daten bezüglich einer Abrechnungsanforderungsnachricht, die an einem zweiten PM-Knoten der Vielzahl von PM-Knoten verarbeitet wird, über die Weitergabe von Datenspeichern; und Aktualisieren einer lokalen Instanz des verteilten Datenspeichers, um die Abrechnungsanforderungsnachricht wiederzugeben, und Erstellen eines aktualisierten Datensatzes im verteilten Datenspeicher; Weiterleiten der Daten bezüglich der Abrechnungsanforderung an einen dritten PM-Knoten der Vielzahl von PM-Knoten; und Teilen Sie mindestens einen Teil der Informationen aus dem aktualisierten Datensatz mit einem anderen Infrastrukturgerät der Netzwerkinfrastruktur über eine RADIUS-Protokollnachricht (Remote Authentication Dial-In User Service), wobei das unterschiedliche Infrastrukturgerät keinen direkten Zugriff auf den verteilten Datenspeicher hat.
DE102020113257.3A 2019-05-22 2020-05-15 Policy management system zur bereitstellung von autorisierungsinformationen über den distributed data store Pending DE102020113257A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/419,138 US11463477B2 (en) 2019-05-22 2019-05-22 Policy management system to provide authorization information via distributed data store
US16/419,138 2019-05-22

Publications (1)

Publication Number Publication Date
DE102020113257A1 true DE102020113257A1 (de) 2020-11-26

Family

ID=73052666

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020113257.3A Pending DE102020113257A1 (de) 2019-05-22 2020-05-15 Policy management system zur bereitstellung von autorisierungsinformationen über den distributed data store

Country Status (3)

Country Link
US (2) US11463477B2 (de)
CN (1) CN111988269A (de)
DE (1) DE102020113257A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113946624A (zh) * 2021-10-11 2022-01-18 北京达佳互联信息技术有限公司 分布式集群、信息处理方法、装置、电子设备及存储介质

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050138380A1 (en) * 2003-12-22 2005-06-23 Fedronic Dominique L.J. Entry control system
US7483438B2 (en) * 2005-04-14 2009-01-27 Alcatel Lucent Systems and methods for managing network services between private networks
CN101496387B (zh) * 2006-03-06 2012-09-05 思科技术公司 用于移动无线网络中的接入认证的系统和方法
EP2115568A4 (de) 2006-12-13 2012-11-28 Identity Engines Inc Verteilte authentifizierung, autorisierung und buchführung
WO2009032711A1 (en) * 2007-08-29 2009-03-12 Nirvanix, Inc. Policy-based file management for a storage delivery network
US8839386B2 (en) * 2007-12-03 2014-09-16 At&T Intellectual Property I, L.P. Method and apparatus for providing authentication
US9129071B2 (en) * 2012-10-24 2015-09-08 Texas Instruments Incorporated Coherence controller slot architecture allowing zero latency write commit
WO2015040280A1 (en) 2013-09-20 2015-03-26 Notava Oy Access control to wireless networks involving a policy proxy server
US10193878B2 (en) * 2013-10-31 2019-01-29 Hewlett Packard Enterprise Development Lp Using application level authentication for network login
US9438506B2 (en) * 2013-12-11 2016-09-06 Amazon Technologies, Inc. Identity and access management-based access control in virtual networks
US10462210B2 (en) * 2014-02-13 2019-10-29 Oracle International Corporation Techniques for automated installation, packing, and configuration of cloud storage services
US9571452B2 (en) * 2014-07-01 2017-02-14 Sophos Limited Deploying a security policy based on domain names
US9473504B2 (en) * 2014-10-15 2016-10-18 Ayla Networks, Inc. Role based access control for connected consumer devices
US9979733B2 (en) * 2015-09-24 2018-05-22 International Business Machines Corporation Automatically provisioning new accounts on managed targets by pattern recognition of existing account attributes
US9894067B1 (en) * 2015-12-03 2018-02-13 Amazon Technologies, Inc. Cross-region roles
US10454940B2 (en) * 2016-05-11 2019-10-22 Oracle International Corporation Identity cloud service authorization model
US20190238550A1 (en) * 2016-12-26 2019-08-01 Cloudminds (Shenzhen) Robotics Systems Co., Ltd. Permission control method, apparatus and system for block chain, and node device
US10547614B2 (en) * 2017-03-30 2020-01-28 Juniper Networks, Inc. Bulk delivery of change of authorization data via AAA protocols
US10931673B2 (en) * 2017-09-19 2021-02-23 Amazon Technologies, Inc. Policy activation for client applications
US11057366B2 (en) * 2018-08-21 2021-07-06 HYPR Corp. Federated identity management with decentralized computing platforms

Also Published As

Publication number Publication date
US20220417288A1 (en) 2022-12-29
CN111988269A (zh) 2020-11-24
US11968238B2 (en) 2024-04-23
US20200374315A1 (en) 2020-11-26
US11463477B2 (en) 2022-10-04

Similar Documents

Publication Publication Date Title
DE602005000025T2 (de) Verfahren und Anordnung für den Betrieb eines offenen Netzwerks mit einem Proxy
DE60103027T2 (de) Netzwerkbetriebsmittel-zugriffssystem
DE112020005786T5 (de) Systeme und verfahren zum ermöglichen eines hochverfügbaren verwalteten ausfallsicherungsdienstes
DE60205289T2 (de) System und Verfahren zur gesicherte Funkübertragung von Konfigurationsdaten
DE60133648T2 (de) System und verfahren zum führen von laufzeitdaten in einem server-netzwerk
DE112010003464B4 (de) Modifikation von Zugangskontrolllisten
DE202020005700U1 (de) Aufrufen externer Funktionen aus einem Datenlager
DE69921455T2 (de) System und verfahren zur zugriffssteuerung auf gespeicherte dokumente
DE102006032108B4 (de) System und Verfahren für eine Mehr-Ort-Testausführung
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
DE102019131123A1 (de) Technologien zur transparenten function-as-a-service-arbitrierung für edge-systeme
DE112015004267T5 (de) Speicherung und Übertragung von Anwendungsdaten zwischen Vorrichtungen
DE102016103733A1 (de) Kanaleigentum in einem Veröffentlichungs-/Abonnier-System
DE102021127243A1 (de) Auswahl von Profilen für virtuelle private Netze
DE112015004699B4 (de) Über mehrere Sites verteiltes Sicherheitssystem
DE202020005715U1 (de) Dynamische Maskierung geteilter Datenobjekte
DE112017007393T5 (de) System und verfahren für netzwerkvorrichtungssicherheits- und vertrauenswertbestimmung
DE112021002487T5 (de) Teilen einer geografisch konzentrierten arbeitslast zwischen benachbarten mec-hosts mehrerer netzbetreiber
DE112022000280T5 (de) Identitätsautorität
DE112020004353T5 (de) Globale tabellenverwaltungsoperationen für replizierte tabellen mit mehreren regionen
DE202023100535U1 (de) Systeme für Multi-Blockchain- und Multi-Token-Interoperabilität durch gemeinsame Blockchain-Integration
DE112018004385B4 (de) Steuern des betriebs von datenverarbeitungseinheiten
DE102020113257A1 (de) Policy management system zur bereitstellung von autorisierungsinformationen über den distributed data store
DE102021109509A1 (de) System und verfahren zur rekonfiguration eines netzwerks unter verwendung von netzvverkverkehrsvergleichen
DE202021004328U1 (de) Mit Daten-Cloud verbundene Anwendungen

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: HL KEMPNER PATENTANWAELTE, SOLICITORS (ENGLAND, DE

Representative=s name: HL KEMPNER PATENTANWALT, RECHTSANWALT, SOLICIT, DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000

R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, WEST HOUSTON, TX, US

R012 Request for examination validly filed