DE112021001413T5 - Verwaltung eines privilegierten zugriffs mit geringer vertrauenswürdigkeit - Google Patents

Verwaltung eines privilegierten zugriffs mit geringer vertrauenswürdigkeit Download PDF

Info

Publication number
DE112021001413T5
DE112021001413T5 DE112021001413.7T DE112021001413T DE112021001413T5 DE 112021001413 T5 DE112021001413 T5 DE 112021001413T5 DE 112021001413 T DE112021001413 T DE 112021001413T DE 112021001413 T5 DE112021001413 T5 DE 112021001413T5
Authority
DE
Germany
Prior art keywords
access
request
blockchain
action
information system
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
DE112021001413.7T
Other languages
English (en)
Inventor
Fabio Benedetti
Alessandro Donatelli
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112021001413T5 publication Critical patent/DE112021001413T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • 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/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Software Systems (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Automation & Control Theory (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Preparation Of Compounds By Using Micro-Organisms (AREA)

Abstract

Ein Verfahren zum Orchestrieren eines Zugriffsverwaltungsprozesses, ein Governance-Orchestrator für die Zugriffsverwaltung und ein Computerprogrammprodukt. Eine Ausführungsform kann Empfangen einer Anforderung zum Zugreifen auf eine verwaltete Ressource eines Informationssystems, Abfragen einer Berechtigung zum Zugreifen auf die Ressource von einem Zugriffsmanager und als Reaktion auf das Abfragen der Berechtigung Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie aufweisen, um den Zugriff auf die verwaltete Ressource zu gewähren. Das Empfangen der Anforderung, das Abfragen der Berechtigung und das Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie können Erzeugen eines Transaktionsdatensatzes und Hinzufügen des Transaktionsdatensatzes zu einem Distributed Ledger aufweisen, wobei das Distributed Ledger den Transaktionsdatensatz gleichzeitig an mehreren Knoten in einem Netzwerk verwaltet.

Description

  • HINTERGRUND
  • Die vorliegende Offenbarung bezieht sich auf Computersicherheit und insbesondere auf Orchestrieren des Zugriffs auf privilegierte und administrative Funktionen in kritischen IT-Systemen, die sensible Daten speichern/verarbeiten.
  • Die Entwicklung des EDVAC-Computersystems (EDVAC = Electronic Discrete Variable Automatic Computer) von 1948 wird oft als der Beginn des Computerzeitalters bezeichnet. Seit dieser Zeit haben sich Computersysteme zu äußerst komplizierten Einheiten entwickelt. Die heutigen Computersysteme enthalten in der Regel eine Kombination aus hoch entwickelten Hardware- und Software-Komponenten, Anwendungsprogramme, Betriebssysteme, Prozessoren, Busse, Speicher, Eingabe-/Ausgabeeinheiten usw. Da Fortschritte in der Halbleiterverarbeitung und bei der Computerarchitektur die Leistungsfähigkeit des Computers immer weiter steigern, ist eine noch ausgereiftere Computer-Software entstanden, die die höhere Leistungsfähigkeit der Hardware vorteilhaft nutzt, sodass es heute Computersysteme gibt, die weitaus leistungsstärker sind als noch vor ein paar Jahren.
  • Die heutigen Computersysteme sind für den technischen Fortschritt unverzichtbar und zu einem wichtigen Bestandteil des täglichen Lebens geworden. Die technische Frage der Sicherheit dieser Datenverarbeitungssysteme hat daher an Bedeutung gewonnen. Ein wichtiger Aspekt der Computersicherheit ist die Verwaltung des Berechtigungszugriffs und die Verwaltung privilegierter Konten. Bei einem privilegierten Benutzer handelt es sich um einen Benutzer, dem eine höhere Zugriffsebene (z.B. ein Administrator oder ein „Stamm“-Superbenutzer eines Systems) und/oder eine besondere Zugriffsebene (z.B. die Fähigkeit, Daten mit geheimen Informationen zu lesen und zu schreiben) in einem Datenverarbeitungssystem zur Verfügung steht. Die Verwaltung des Berechtigungszugriffs und die Verwaltung privilegierter Konten umfassen ihrerseits allgemein ein Verwalten und Prüfen der Konten, die diesen privilegierten Benutzern einen System- und Datenzugriff bereitstellen.
  • KURZDARSTELLUNG
  • Gemäß Ausführungsformen der vorliegenden Offenbarung ein Verfahren zum Orchestrieren eines Zugriffsverwaltungsprozesses. Eine Ausführungsform kann Empfangen einer Anforderung zum Zugreifen auf eine verwaltete Ressource eines Informationssystems, Abfragen einer Berechtigung zum Zugreifen auf die Ressource von einem Zugriffsmanager und als Reaktion auf das Abfragen der Berechtigung Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie aufweisen, um den Zugriff auf die verwaltete Ressource zu gewähren. Das Empfangen der Anforderung, das Abfragen der Berechtigung und das Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie können Erzeugen eines Transaktionsdatensatzes und Hinzufügen des Transaktionsdatensatzes zu einem Distributed Ledger (verteiltes Kontenbuch) aufweisen, wobei das Distributed Ledger den Transaktionsdatensatz gleichzeitig an mehreren Knoten in einem Netzwerk verwaltet.
  • Gemäß Ausführungsformen der vorliegenden Offenbarung ein Governance-Orchestrator für die Zugriffsverwaltung, der einen Peer-Knoten aufweist, der einem Blockchain-Netzwerk zugehörig ist, wobei das Blockchain-Netzwerk eine Mehrzahl von Knoten aufweist, die einer Asset-Eignerfunktion, einer Administratorfunktion und/oder einer Prüffunktion zugehörig sind. Der Peer-Knoten kann so ausgelegt sein, dass er einen „Zugriff anfordern“-Datensatz von einem Benutzer eines Informationssystems in einem Distributed Ledger aufzeichnet, einen Eignergenehmigungsdatensatz von der Asset-Eignerfunktion aufzeichnet, wobei der Eignergenehmigungsdatensatz auf den „Zugriff anfordern“-Datensatz im Distributed Ledger reagiert, einen Smart Contract (intelligenter Vertrag) als Reaktion auf den „Zugriff anfordern“-Datensatz und den Eignergenehmigungsdatensatz ausführt, der den Zugriff auf das Informationssystem gewährt, wobei der Smart Contract eine Berechtigungsrichtlinie ändert, um den Zugriff des Benutzers auf das Informationssystem zu ermöglichen, und einen Ausführungsdatensatz des Smart Contract im Distributed Ledger aufzeichnet.
  • Gemäß Ausführungsformen der vorliegenden Offenbarung ein Computerprogrammprodukt, das ein nichtflüchtiges, durch einen Computer lesbares Speichermedium mit einer Mehrzahl von darauf gespeicherten Anweisungen aufweist. Wenn die Anweisungen von einem Prozessor ausgeführt werden, können sie den Prozessor veranlassen, eine Anforderung zum Zugreifen auf eine verwaltete Ressource eines Informationssystems zu empfangen, eine Berechtigung zum Zugreifen auf die Ressource von einem Zugriffsmanager abzufragen und als Reaktion auf das Abfragen der Berechtigung eine Aktualisierung der Zugriffssteuerungsrichtlinie anzufordern, um den Zugriff auf die verwaltete Ressource zu gewähren. Das Empfangen der Anforderung, das Abfragen der Berechtigung und das Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie können Erzeugen eines Transaktionsdatensatzes und Hinzufügen des Transaktionsdatensatzes zu einem Distributed Ledger aufweisen.
  • Die vorstehende Kurzdarstellung ist nicht dazu gedacht, jede veranschaulichte Ausführungsform oder jede Implementierung der vorliegenden Offenbarung zu beschreiben.
  • Figurenliste
  • Die in der vorliegenden Anmeldung dargestellten Zeichnungen sind in der Beschreibung enthalten und bilden einen Teil davon. Sie veranschaulichen Ausführungsformen der vorliegenden Offenbarung und dienen zusammen mit der Beschreibung dazu, die Grundgedanken der Offenbarung zu erläutern. Die Zeichnungen veranschaulichen lediglich bestimmte Ausführungsformen und beschränken die Offenbarung nicht.
    • 1 stellt eine Cloud-Computing-Umgebung gemäß einigen Ausführungsformen dar.
    • 2 stellt Abstraktionsmodellschichten gemäß einigen Ausführungsformen dar.
    • 3 stellt ein Datenverarbeitungssystem gemäß einigen Ausführungsformen dar.
    • 4 ist eine schematische Darstellung eines Berechtigungsorchestrators gemäß einigen Ausführungsformen.
    • 5A stellt eine beispielhafte Konfiguration einer Blockchain-Architektur gemäß einigen Ausführungsformen dar.
    • 5B veranschaulicht einen Blockchain-Transaktionsablauf gemäß einigen Ausführungsformen.
    • 6A veranschaulicht einen Ablaufplan gemäß einigen Ausführungsformen.
    • 6B veranschaulicht einen weiteren Ablaufplan gemäß einigen Ausführungsformen.
    • 6C veranschaulicht gemäß einigen Ausführungsformen ein beispielhaftes System, das so konfiguriert ist, dass es eine oder mehrere hier beschriebene Operationen durchführt.
    • 6D veranschaulicht gemäß einigen Ausführungsformen ein weiteres beispielhaftes System, das so konfiguriert ist, dass es eine oder mehrere hier beschriebene Operationen durchführt.
    • 6E veranschaulicht gemäß einigen Ausführungsformen ein weiteres beispielhaftes System, das so konfiguriert ist, dass es einen Smart Contract verwendet.
    • 6F veranschaulicht gemäß einigen Ausführungsformen ein System, das eine Blockchain umfasst.
    • 7A veranschaulicht gemäß beispielhaften Ausführungsformen einen Prozess, bei dem ein neuer Block zu einem Distributed Ledger hinzugefügt wird.
    • 7B veranschaulicht gemäß beispielhaften Ausführungsformen den Inhalt eines neuen Datenblocks.
    • 7C veranschaulicht gemäß beispielhaften Ausführungsformen eine Blockchain für digitalen Inhalt.
    • 7D veranschaulicht gemäß beispielhaften Ausführungsformen einen Block, der die Struktur von Blöcken in der Blockchain darstellen kann.
  • Verschiedene Änderungen und andere Formen sind für die Erfindung möglich, die Besonderheiten der Erfindung sind jedoch beispielhaft in den Zeichnungen dargestellt und werden ausführlich beschrieben. Es wird jedoch darauf hingewiesen, dass die Erfindung nicht auf die beschriebenen besonderen Ausführungsformen beschränkt werden soll. Alle Änderungen, Äquivalente und Alternativen, die Gedanken und Anwendungsbereich der Erfindung widerspiegeln, sollen vielmehr mitaufgenommen werden.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Aspekte der vorliegenden Offenbarung beziehen sich auf Computersicherheit; besondere Aspekte beziehen sich auf Orchestrieren des Zugriffs auf privilegierte und administrative Funktionen in kritischen IT-Systemen, die sensible Daten speichern/verarbeiten. Die vorliegende Offenbarung ist zwar nicht zwingend auf diese Anwendungen beschränkt, verschiedene Aspekte der Offenbarung können jedoch durch eine Beschreibung verschiedener Beispiele in diesem Zusammenhang verstanden werden.
  • Ein wichtiger Aspekt der IT-Sicherheit ist die Verwaltung des Zugriffs von privilegierten Benutzern, z.B. solcher Benutzer, die Verwaltungsmaßnahmen bei kritischen IT-Systemen durchführen können, die sensible Daten speichern/verarbeiten. Der Zugriff eines privilegierten Benutzers auf ein IT-System kann durch ein Zugriffssteuerungssystem auf der Grundlage von Authentifizierungs- und Berechtigungsrichtlinien erlaubt oder abgelehnt werden. Diese Richtlinien werden in der Regel von der höchsten Ebene der Administratoren des IT-Systems festgelegt.
  • Wirksame Zugriffssteuerungssysteme können versuchen, Änderungen an Sicherheitsrichtlinien zu steuern, um sicherzustellen, dass nur genehmigte Änderungen vorgenommen werden (z.B. wenn ein neuer Mitarbeiter eingestellt wird und somit Zugriff auf das IT-System benötigt, um seine Arbeit auszuführen). Diese Änderungen an den Sicherheitsrichtlinien können wiederum von einem Governance-Prozess für die Zugriffsverwaltung über einen Governance-Orchestrator für die Zugriffsverwaltung verwaltet werden.
  • Einige Governance-Prozesse für die Zugriffsverwaltung zum Verwalten des Zugriffs auf ein IT-System können ihrerseits wieder aus einer oder mehreren der folgenden Maßnahmen bestehen: (i) Anfordern des Zugriffs; (ii) Genehmigen des Zugriffs; (iii) Gewähren des Zugriffs; (iv) Prüfen des Zugriffs; (v) Zurücknehmen des Zugriffs und (vi) Autorisieren des Zugriffs. An einigen Governance-Prozessen für die Zugriffsverwaltung können eine oder mehrere der folgenden Entitäten beteiligt sein: (i) Eigner des IT-Systems; (ii) privilegierter Benutzer, der Zugriff auf das IT-System benötigt; (iii) Sicherheitsadministrator des IT-Systems, der die Zugriffsrichtlinien für das IT-System steuert, die den Zugriff für privilegierte Benutzer autorisieren oder ablehnen; (iv) externe Prüfungsstelle und (v) Orchestrator des Zugriffsverwaltungsprozesses. In einigen Ausführungsformen kann dieser Prozess den folgenden Arbeitsablauf umfassen:
    1. 1. Ein Benutzer, der eine Berechtigung für ein verwaltetes Asset in einem IT-System haben möchte, sendet eine Zugriffsanforderung, wobei er dem Orchestrator des Zugriffsverwaltungsprozesses in der Regel eine Begründung bereitstellt;
    2. 2. Der Prozessorchestrator ermittelt, wer der Eigner des verwalteten Assets und/oder des IT-Systems ist und leitet die Anforderung an diesen weiter;
    3. 3. Der Eigner des Assets und/oder IT-Systems empfängt die Zugriffsanforderung, prüft die Begründung, entscheidet über die Genehmigung oder Ablehnung der Anforderung und sendet die genehmigte/abgelehnte Anforderung an den Prozessorchestrator zurück;
    4. 4. Wenn die Anforderung genehmigt wird, sendet der Prozessorchestrator eine Anforderung zum Gewähren des Zugriffs an den Administrator und/oder das lokale Steuerungssystem, das dem verwalteten Asset und/oder IT-System zugehörig ist;
    5. 5. Der Administrator und/oder das lokale Steuerungssystem empfangen die Anforderung und gewähren dem anfordernden Benutzer Zugriff, indem er/es Änderungen an den Berechtigungsrichtlinien des Systems vornimmt, um dem privilegierten Benutzer die Anmeldung und den Zugriff auf das System zu ermöglichen;
    6. 6. Die Maßnahmen zum Anfordern, Genehmigen/Ablehnen, Gewähren des Zugriffs werden vom Prozessorchestrator in einem Prüfprotokoll protokolliert; und
    7. 7. Eine externe Prüfungsstelle fordert vom Prozessorchestrator das Prüfprotokoll an, um zu prüfen, ob der Zugriff gemäß den Vorschriften (Unternehmen, Regierung, Industrie usw.) gewährt wurde und ob alle Richtlinien korrekt angewendet wurden.
  • Wenn der privilegierte Benutzer seine Arbeit beendet hat und den Zugriff nicht mehr benötigt, kann der Prozessorchestrator „Zugriff zurücknehmen“ an den Administrator und/oder das lokale Steuerungssystem senden, der/das den Zugriff aufhebt, indem Änderungen an der Sicherheit des Systems vorgenommen werden. Der Prozessorchestrator kann die Zurücknahme-Anforderung auslösen, wenn er eine Anforderung des privilegierten Benutzers empfängt, den Zugriff aufzuheben, wenn die für die Zugriff zugewiesene Höchstdauer abläuft, nach einer regelmäßigen Überprüfung, die der Eigner des IT-Systems bei den privilegierten Benutzern durchführt, die aktuell Zugriff auf das IT-System haben, um festzustellen, ob sie noch eine gültige Begründung für den weiteren Zugriff haben, nach einer Überprüfung einer externen Prüfungsstelle (die möglicherweise einen Verstoß gegen die Sicherheitsrichtlinien festgestellt hat und einen Sicherheitsvorfall auslöst, bei dem eine Zurücknahme des Zugriffs gefordert wird) usw.
  • In einigen Ausführungsformen kann es sich bei dem Governance-Orchestrator für die Zugriffsverwaltung um ein System handeln, das diese Anforderungen empfängt und verarbeitet. In diesen Ausführungsformen leitet der Governance-Orchestrator für die Zugriffsverwaltung die Anforderungen an die entsprechenden Eigner, Administratoren usw. weiter. Die Person oder Organisation, die die Zielsysteme verwaltet, kann eine andere sein als die Person oder Organisation, die Eigner des Zielsystems ist: z.B. eine Bank, die Eignerin von Datenbanksystemen ist und eine externe Sicherheitsorganisation nutzt, um den Prozess zu verwalten. Bei dem Administrator des IT-Systems kann es sich auch um ein automatisiertes System handeln, das die von der Prozess-Orchestratororganisation weitergeleiteten Anforderungen zum Gewähren des Zugriffs ohne Beurteilung oder weitere Prüfung ausführt.
  • In einigen Ausführungsformen kann der Governance-Orchestrator für die Zugriffsverwaltung vorteilhafterweise ein Distributed Ledger (z.B. Blockchain) enthalten, das die Berechtigung verteilt und vollständige Transparenz der Operationen von allen beteiligten Parteien sicherstellt, indem es gleichzeitig Transaktionsdatensätze an mehreren Punkten in einem Netzwerk verwaltet. Einige Ausführungsformen können insbesondere einen Governance-Prozess für die Zugriffsverwaltung bereitstellen, um zu orchestrieren, wie Änderungen an den Berechtigungsrichtlinien angefordert, genehmigt, gewährt, zurückgenommen, validiert usw. werden, einschließlich Schnittstellen des Governance-Orchestrators für die Zugriffsverwaltung zu jedem der Zugriffssteuerungssysteme des lokalen IT-Systems, um Änderungen an den Berechtigungsrichtlinien anzufordern. Auf diese Weise können einige Ausführungsformen eine Alternative zur vollständigen Vertrauenswürdigkeit zwischen den Teilnehmern bereitstellen, da jeder weiß, dass keine andere Partei den Zugriffsverwaltungsprozess umgehen oder einen Mitarbeiter dazu zwingen/täuschen kann, um den Zugriff zu gewähren/zurückzunehmen, auch wenn keine Genehmigung vom Dateneigner erteilt wurde, usw.
  • Ein Vorteil einiger Ausführungsformen des Governance-Orchestrators für die Zugriffsverwaltung mit Blockchains besteht darin, dass sie die Anfälligkeit für Angriffe von innen auf die Zugriffsverwaltungssysteme verringern können (z.B. Fehlverhalten von Mitarbeitern). Ohne dieses Merkmal könnten beispielsweise Mitarbeiter der Organisation und/oder Mitarbeiter einer externen Organisation, die ihre IT-Assets verwaltet, über ausreichende Befugnisse verfügen, um die Prozesse zu manipulieren und gegen die Sicherheitsrichtlinien zu verstoßen. Ein betrügerischer Mitarbeiter könnte unter diesen Umständen eine „Zugriff gewähren“-Anforderung an das IT-System senden (d.h. ohne die Genehmigung des Systemeigners) und die Prüfprotokolle manipulieren, um diese Zugriffsgenehmigung zu verbergen oder zu ändern. Sogar die Protokollsignierung und andere Techniken zum Schutz vor Manipulationen können theoretisch von einem betrügerischen Mitarbeiter mit ausreichenden Rechten umgangen werden, z.B. durch Hacken des zentralisierten Systemcodes/der zentralisierten Systemkonfiguration, dessen/deren vollständiger Eigner er ist, durch Unterbinden der Zurücknahme des Zugriffs für betrügerische Benutzer, durch Bereitstellen manipulierter Prüfprotokolle für den externen Prüfer, die keine Verstöße gegen die Sicherheitsrichtlinien anzeigen usw. Governance-Orchestratoren für die Zugriffsverwaltung, die Blockchains verwenden, können dagegen dem Eigner eines IT-Systems, Administratoren dieser IT-Systeme und/oder Datenverwaltern die Sicherheit bereitstellen, dass der Zugriff auf das System und/oder die Daten nicht gewährt werden kann, ohne dass der Eigner diesen Zugriff ausdrücklich und transparent genehmigt hat. Ausführungsformen, die Blockchains verwenden, können ferner dazu beitragen, dass Prüfer und Regulierungsbehörden sicher sein können, dass dokumentierte Prozesse nicht umgangen werden können. Diese Merkmale und Vorteile können insbesondere in Szenarien von Nutzen sein, in denen es um sensible personenbezogene Informationen, Daten, die Vorschriften unterliegen, vertrauliche Informationen, Geschäftsgeheimnisse usw. geht.
  • Einige Ausführungsformen können darüber hinaus sicherstellen, dass niemand Transaktionen wie „AccessApproved“ (Zugriff genehmigt) und „GrantAccess“ (Zugriff gewähren) fälschen und dem Blockchain-Ledger hinzufügen kann. Wenn jemand einen Knoten hackt, um die Transaktionen zu fälschen und sie in das Ledger zu stellen, kann es sein, dass diese Ausführungsformen keinen Konsens erreichen, um die Transaktionen zuzulassen. Dies wiederum kann wünschenswert sein, da der „Zugriffsmanager“ in einigen Ausführungsformen keine privilegierte Rolle mehr oder sogar nicht mehr vertrauenswürdig sein muss. Die IT-Eigner können sich somit darauf verlassen, dass die im Distributed Ledger zugelassenen Transaktionen von mehreren Knoten validiert wurden, die von verschiedenen Parteien kontrolliert werden, und daher keine der Genehmigungen gefälscht ist. Um einen noch besseren Schutz vor dem Hacken von Code zu gewährleisten, das eine gefälschte Transaktion darstellen könnte, können einige Ausführungsformen es den Eignern und dem IT-Administrator ermöglichen, ihre eigenen privaten Knoten zu implementieren (d.h. mit vollständiger Kontrolle über die Code-Implementierung und -Konfiguration) und diese zum Blockchain-Netzwerk hinzuzufügen. Auf diese Weise können einige Ausführungsformen eine verbesserte Vertrauenswürdigkeit zwischen den Teilnehmern bereitstellen, da jeder weiß, dass keine Person oder keine Entität den Zugriffsverwaltungsprozess umgehen oder jemanden dazu zwingen/täuschen kann, um den Zugriff zu gewähren/zurückzunehmen, auch wenn keine Genehmigung vom Dateneigner erteilt wurde.
  • Einige Ausführungsformen ermöglichen es IT-Administratoren, Transaktionen wie die „GrantAccess“-Transaktionen und die zugehörigen „AccessApproved“-Transaktionen durch den Eigner des Zielsystems validieren zu lassen. Wenn die Transaktionen nicht mit den dem IT-Administrator vorliegenden Informationen übereinstimmen, kann der IT-Administrator die Gewährung sperren. Auf diese Weise können IT-Administratoren bei Verdacht auf Hackeraktivitäten, die die Konsistenz des Ledger zu zerstören versuchen, die betreffende Quelle einfach vom Netzwerk trennen oder das Netzwerk auffordern, den zugehörigen Zugriffsmanager zu sperren (und wenn das Blockchain-Netzwerk einen Konsens erzielt, kann der Zugriffsmanager sogar aus dem Blockchain-Netzwerk entfernt werden).
  • Einige Ausführungsformen können auch eine bessere Prüfbarkeit bereitstellen, da das Prüfen der Transaktionssequenz durch ein Blockchain-System kryptografisch gewährleistet werden kann. In diesen Ausführungsformen kann das Distributed Ledger unveränderlich sein, sodass zugelassene Transaktionen nicht geändert, gehackt usw. werden können. Darüber hinaus kann gewährleistet werden, dass Transaktionen im Distributed Ledger nur dann zugelassen werden, wenn das Netzwerk einen Konsens darüber erzielt hat, dass sie gültig sind. Ein Angreifer, der versucht, falsche Transaktionen in das Ledger zu hacken, müsste selbst mit Codeänderungen, Protokoll-Spoofing/Fälschung usw. eine ausreichende Anzahl von Knoten des Netzwerks hacken, um einen Konsens über gefälschte Transaktionen zu erzwingen. Die Erfolgswahrscheinlichkeit dieser Möglichkeit ist sehr gering und kann sich noch weiter verringern, wenn sichergestellt wird, dass mehrere (unabhängige) Prüfer an dem Netzwerk beteiligt sind und kein Konsens erzielt wird, ohne dass eine Mehrheit von ihnen zustimmt. In diesen Ausführungsformen können Prüforganisationen, die dem Netzwerk beitreten, um Transaktionen zu validieren, zum weiteren Schutz vor dem Hacken von Code, durch das ihnen gefälschte Transaktionen vorgelegt werden könnten, auch ihre privaten Knoten (mit vollständiger Kontrolle über die Code-Implementierung und -Konfiguration) implementieren und diese zum Blockchain-Netzwerk hinzufügen.
  • Einige Ausführungsformen können darüber hinaus eine hohe Verfügbarkeit des verteilten Systems bereitstellen, das den Sicherheitsprozess überwacht. In diesen Ausführungsformen beeinträchtigt der Ausfall einer oder mehrerer Knoten nicht die Verfügbarkeit der globalen Blockchain, und die Clients können sich mit anderen Knoten verbinden.
  • Cloud Computing
  • 1 veranschaulicht eine Cloud-Computing-Umgebung gemäß einigen Ausführungsformen. Die vorliegende Offenbarung enthält zwar eine ausführliche Beschreibung von Cloud-Computing, es versteht sich jedoch, dass die Umsetzung der hier dargelegten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit beliebigen Arten von jetzt bekannter oder später entwickelter Datenverarbeitungsumgebung umgesetzt werden.
  • Cloud-Computing ist ein Modell zum Liefern eines Dienstes, der einen problemlosen, bedarfsorientierten Netzwerkzugriff auf einen gemeinsamen Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Speicher, Anwendungen, virtuelle Maschinen und Dienste) ermöglicht, die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle enthalten.
  • Bei den Eigenschaften handelt es sich um die Folgenden:
    • • On-Demand Self-Service (bedarfsorientierte Selbstbedienung): Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher bereitstellen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
    • • Broad Network Access (breiter Netzzugriff): Über ein Netzwerk sind Funktionen verfügbar, auf die durch Standardmechanismen zugegriffen wird, die die Verwendung durch heterogene schlanke oder leistungsintensive Client-Plattformen unterstützen (z.B. Mobiltelefone, Laptops und PDAs).
    • • Ressource Pooling (Ressourcen-Bündelung): Die Datenverarbeitungsressourcen des Anbieters werden gebündelt, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
    • • Rapid Elasticity (schnelle Anpassungsfähigkeit): Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
    • • Measured Service (messbarer Dienst): Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Kundenkonten). Die Inanspruchnahme von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz bereitgestellt wird.
  • Es gibt folgende Dienstmodelle:
    • • Software as a Service (Saas) (Software als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine schlanke Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende eMail) von verschiedenen Client-Einheiten aus zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten kundenspezifischen Einstellungen der Anwendungskonfiguration.
    • • Platform as a Service (Paas) (Plattform als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Werkzeugen erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen der Hosting-Umgebung der Anwendung.
    • • Infrastructure as a Service (laas) (Infrastruktur als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
  • Es gibt folgende Einsatzmodelle:
    • • Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
    • • Community Cloud (Benutzergemeinschafts-Cloud): Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Anliegen hat (z.B. Aufgabe, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder fremden Räumen befinden.
    • • Public Cloud (öffentliche Cloud): Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Branchengruppe zur Verfügung gestellt und gehört einer Organisation, die Cloud-Dienste verkauft.
    • • Hybrid Cloud (hybride Cloud): Die Cloud-Infrastruktur besteht aus zwei oder mehr Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Entitäten bleiben, aber durch eine standardisierte oder herstellereigene Technologie miteinander verbunden sind, die eine Übertragbarkeit von Daten und Anwendungen ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
  • Eine Cloud-Computing-Umgebung ist dienstorientiert und schwerpunktmäßig auf Statusunabhängigkeit, geringe Kopplung, Modularität und semantische Interoperabilität ausgerichtet. Der Kern der Cloud-Computing ist eine Infrastruktur, die ein Netzwerk aus miteinander verbundenen Knoten enthält.
  • Mit Bezug nunmehr auf 1 ist eine veranschaulichende Cloud-Computing-Umgebung 50 dargestellt. Wie gezeigt, enthält die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie der persönliche digitale Assistent (PDA) oder das Mobiltelefon 54A, der Desktop-Computer 54B, der Laptop-Computer 54C und/oder das Kraftfahrzeug-Computersystem 54N Daten austauschen können. Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in einem oder mehreren Netzwerken wie private, benutzergemeinschaftliche, öffentliche oder hybride Clouds wie oben beschrieben oder in einer Kombination davon in Gruppen angeordnet sein (nicht dargestellt). Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastruktur, Plattformen und/oder Software als Dienste anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es ist ersichtlich, dass die Arten von Datenverarbeitungseinheiten 54A bis N, die in 1 dargestellt sind, nur veranschaulichend sein sollen und die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 mit jeder Art von computergestützter Einheit über jede Art von Netzwerk und/oder netzwerkadressierbarer Verbindung Daten austauschen kann (z.B. über einen Web-Browser).
  • Mit Bezug nunmehr auf 2 wird ein Satz funktionaler Abstraktionsschichten gezeigt, die von der Cloud-Computing-Umgebung 50 (1) bereitgestellt werden. Es versteht sich im Voraus, dass die in 2 dargestellten Komponenten, Schichten und Funktionen nur veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
  • Die Hardware- und Software-Schicht 60 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: die Großrechner 61; die Server 62 auf Grundlage der RISC-Architektur (RISC = Reduced Instruction Set Computer, Computer mit reduziertem Befehlssatz), die Server 63; die Blade-Server 64; die Speichereinheiten 65; sowie die Netzwerke und Netzwerkkomponenten 66. In einigen Ausführungsformen enthalten die Software-Komponenten die Netzwerkanwendungs-Serversoftware 67 und die Datenbank-Software 68.
  • Die Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Entitäten bereitgestellt werden können: virtuelle Server 71; virtuelle Speicher 72; virtuelle Netzwerke 73; darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
  • In einem Beispiel kann die Verwaltungsschicht 80 die nachfolgend beschriebenen Funktionen bereitstellen. Die Ressourcenbereitstellung 81 ermöglicht eine dynamische Bereitstellung von Datenverarbeitungsressourcen und anderen Ressourcen, die verwendet werden, um Aufgaben in der Cloud-Computing-Umgebung durchzuführen. Messen und Preisfindung 82 stellen Kostenverfolgung beim Verwenden von Ressourcen in der Cloud-Computing-Umgebung sowie Abrechnung oder Rechnungsstellung für die Inanspruchnahme dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungssoftware umfassen. Die Sicherheitsfunktion stellt eine Identitätsprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt Nutzern und Systemadministratoren den Zugang zur Cloud-Computing-Umgebung bereit. Die Verwaltung der Dienstgüte 84 stellt Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, sodass die erforderliche Dienstgüte erreicht wird. Die Planung und Erfüllung der Dienstgütevereinbarung (Service Level Agreement, SLA) 85 stellt eine Vorabeinteilung und eine Beschaffung von Cloud-Computing-Ressourcen bereit, deren künftiger Bedarf auf der Grundlage einer Dienstgütevereinbarung vorausgesehen wird.
  • Die Arbeitslastschicht 90 stellt Beispiele für Funktionalitäten bereit, für die die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalyseverarbeitung 94; Transaktionsverarbeitung 95; und ein Governance-Orchestrator für die Zugriffsverwaltung 96.
  • Datenverarbeitungssystem
  • 3 veranschaulicht eine Ausführungsform eines Datenverarbeitungssystems (DVS) 300, das sich gemäß einigen Ausführungsformen zur Verwendung als Cloud-Computing-Knoten 10 in einer Cloud-Computing-Umgebung 50 eignet. In einigen Ausführungsformen ist das DVS 300 als Personal Computer; Server-Computer; tragbarer Computer wie ein Laptop- oder Notebook-Computer, PDA (persönlicher digitaler Assistent), Tablet-Computer oder Smartphone; Prozessoren, die in größere Einheiten wie ein Auto, ein Flugzeug, ein Telefonkonferenzsystem, ein Gerät integriert sind; intelligente Einheiten oder jede andere geeignete Art von elektronischer Einheit implementiert. Darüber hinaus können auch andere oder zusätzliche als die in 3 gezeigten Komponenten vorhanden sein, und die Anzahl, Art und Konfiguration dieser Komponenten kann variieren. In 3 sind ferner nur die repräsentativen Hauptkomponenten des DVS 300 dargestellt, und einzelne Komponenten können komplexer sein als in 3 gezeigt.
  • Das Datenverarbeitungssystem 300 in 3 weist eine Mehrzahl von Zentraleinheiten 310 a bis 310 d auf (hier allgemein als Prozessor 310 oder CPU 310 bezeichnet), die über einen Systembus 322 mit einem Speicher 312, einer Massenspeicher-Schnittstelle 314, einer Terminal-/Anzeigeschnittstelle 316, einer Netzwerkschnittstelle 318 und einer Eingabe-/Ausgabeschnittstelle („E/A“-Schnittstelle) 320 verbunden sind. Die Massenspeicher-Schnittstelle 314 verbindet in dieser Ausführungsform den Systembus 322 mit einer oder mehreren Massenspeichereinheiten wie einer Direktzugriffsspeichereinheit 340, einem Universal-Serial-Bus-Speichereinheit („USB“) 341 oder einem lesbaren/beschreibbaren optischen Laufwerk 342. Die Netzwerkschnittstellen 318 ermöglichen es dem DVS 300, über das Datenübertragungsmedium 306 mit anderen DVS 300 Daten auszutauschen. Der Speicher 312 enthält ferner ein Betriebssystem 324, eine Mehrzahl von Anwendungsprogrammen 326 und Programmdaten 328.
  • Bei der Ausführungsform des Datenverarbeitungssystems 300 in 3 handelt es sich um eine universelle Datenverarbeitungseinheit. Bei den Prozessoren 310 kann es sich daher um jede beliebige Einheit handeln, die in der Lage ist, im Speicher 312 gespeicherte Programmanweisungen auszuführen, wobei die Prozessoren selbst aus einem oder mehreren Mikroprozessoren und/oder integrierten Schaltungen bestehen können. In dieser Ausführungsform enthält das DVS 300 mehrere Prozessoren und/oder Verarbeitungskerne, wie es bei größeren, leistungsstärkeren Computersystemen üblich ist; in anderen Ausführungsformen können die Datenverarbeitungssysteme 300 jedoch ein einzelnes Prozessorsystem und/oder einen einzelnen Prozessor aufweisen, der so ausgestaltet ist, dass er ein Mehrprozessorsystem emuliert. Die Prozessoren 310 können des Weiteren mit einer Reihe von heterogenen Datenverarbeitungssystemen 300 implementiert werden, bei denen ein Hauptprozessor mit sekundären Prozessoren auf einem einzelnen Chip vorhanden ist. In einem weiteren veranschaulichenden Beispiel kann es sich bei dem Prozessor 310 um ein symmetrisches Mehrprozessorsystem mit mehreren Prozessoren desselben Typs handeln.
  • Beim Starten des Datenverarbeitungssystems 300 führen der oder die zugehörige(n) Prozessor(en) 310 zunächst die Programmanweisungen aus, aus denen das Betriebssystem 324 besteht, das die physischen und logischen Ressourcen des DVS 300 verwaltet. Zu diesen Ressourcen gehören der Speicher 312, die Massenspeicher-Schnittstelle 314, die Terminal-/Anzeigeschnittstelle 316, die Netzwerkschnittstelle 318 und der Systembus 322. Wie bei dem/den Prozessor(en) 310 können einige Ausführungsformen des DVS 300 mehrere Systemschnittstellen 314, 316, 318, 320 und Busse 322 verwenden, die ihrerseits jeweils ihre eigenen separaten, vollständig programmierten Mikroprozessoren enthalten können.
  • Anweisungen für das Betriebssystem, Anwendungen und/oder Programme (allgemein als „Programmcode“, „durch einen Computer verwendbarer Programmcode“ oder „durch einen Computer lesbarer Programmcode“ bezeichnet) können sich zunächst in den Massenspeichereinheiten 340, 341, 342 befinden, die über den Systembus 322 Daten mit den Prozessoren 310 austauschen. Der Programmcode in den verschiedenen Ausführungsformen kann auf verschiedenen physischen, durch einen Computer lesbaren Medien wie dem Systemspeicher 312 oder den Massenspeichereinheiten 340, 341, 342 ausgeführt sein. In dem veranschaulichenden Beispiel in 3 werden die Anweisungen in einer funktionalen Form eines dauerhaften Speichers in der Direktzugriffsspeichereinheit 340 gespeichert. Diese Anweisungen werden anschließend zum Ausführen durch den Prozessor 310 in den Speicher 312 geladen. Der Programmcode kann sich jedoch auch in einer funktionalen Form auf dem durch einen Computer lesbaren Medium 342 befinden, das selektiv entfernt werden und zum Ausführen durch den Prozessor 310 in das DVS 300 geladen oder dorthin übertragen werden kann.
  • Bei dem Systembus 322 kann es sich um eine beliebige Einheit handeln, die die Datenübertragung zwischen den Prozessoren 310, dem Speicher 312 und den Schnittstellen 314, 316, 318, 320 ermöglicht. Bei dem Systembus 322 handelt es sich in dieser Ausführungsform darüber hinaus zwar um eine relativ einfache, einzelne Busstruktur, die einen direkten Datenübertragungspfad bei dem Systembus 322 bereitstellt, andere Busstrukturen sind jedoch mit der vorliegenden Offenbarung vereinbar, darunter Punkt-zu-Punkt-Verbindungen in hierarchischen, sternförmigen oder Netzkonfigurationen, mehrere hierarchische Busse, parallele und redundante Pfade usw., ohne auf diese beschränkt zu sein.
  • Der Speicher 312 und die Massenspeichereinheiten 340, 341, 342 arbeiten zusammen, um das Betriebssystem 324, die Anwendungsprogramme 326 und die Programmdaten 328 zu speichern. In dieser Ausführungsform handelt es sich bei dem Speicher 312 um ein Halbleiterbauelement mit wahlfreiem Zugriff, das Daten und Programme speichern kann. 3 zeigt dieses Bauelement zwar konzeptionell als einzelne monolithische Entität, der Speicher 312 kann in einigen Ausführungsformen jedoch eine komplexere Anordnung wie eine Hierarchie von Caches und anderen Speichereinheiten aufweisen. Der Speicher 312 kann beispielsweise aus mehreren Ebenen von Caches bestehen, und diese Caches können weiter nach Funktionen unterteilt sein, sodass ein Cache Anweisungen enthält, während ein anderer Cache Nichtanweisungsdaten enthält, die von dem Prozessor oder den Prozessoren verwendet werden. Der Speicher 312 kann ferner verteilt und verschiedenen Prozessoren 310 oder Sätzen von Prozessoren 310 zugehörig sein, wie es von verschiedenen sogenannten NUMA-Computerarchitekturen (NUMA = Non-Uniform Memory Access) bekannt ist. Einige Ausführungsformen können darüber hinaus bekannte virtuelle Adressierungsmechanismen verwenden, die es dem DVS 300 ermöglichen, sich so zu verhalten, als hätte es Zugriff auf eine große, einzelne Speicherentität anstatt auf mehrere, kleinere Speichereinheiten wie den Speicher 312 und die Massenspeichereinheit 340, 341, 342.
  • Das Betriebssystem 324, die Anwendungsprogramme 326 und die Programmdaten 328 werden zwar als im Speicher 312 enthalten dargestellt, einige oder alle können sich jedoch physisch in verschiedenen Computersystemen befinden, und in einigen Ausführungsformen kann aus der Ferne auf sie zugegriffen werden, z.B. über das Datenübertragungsmedium 306. Während das Betriebssystem 324, die Anwendungsprogramme 326 und die Programmdaten 328 als im Speicher 312 enthalten dargestellt sind, sind diese Elemente nicht notwendigerweise alle gleichzeitig vollständig in derselben physischen Einheit enthalten und können sich sogar im virtuellen Speicher anderer DVS 300 befinden.
  • Die Systemschnittstellen 314, 316, 318, 320 unterstützen die Datenübertragung mit einer Vielfalt von Speicher- und E/A-Einheiten. Die Massenspeicher-Schnittstelle 314 unterstützt den Anschluss einer oder mehrerer Massenspeichereinheiten 340, 341, 342, bei denen es sich in der Regel um rotierende Magnetplattenspeichereinheiten, eine Halbleiterspeichereinheit (SSD), die Baugruppen für integrierte Schaltungen als Speicher verwendet, um Daten dauerhaft in der Regel unter Verwendung eines Flash-Speichers zu speichern, oder eine Kombination aus beiden handelt. Die Massenspeichereinheiten 340, 341, 342 können jedoch auch andere Einheiten aufweisen, darunter Anordnungen von Festplattenlaufwerken, die so konfiguriert sind, dass sie für einen Host als einzige große Speichereinheit erscheinen (allgemein als RAID-Anordnungen bezeichnet) und/oder Archivierungsspeichermedien wie Festplattenlaufwerke, Bänder (z.B. Mini-DV), beschreibbare Compact Disks (z.B. CD-R und CD-RW), Digital Versatile Disks (z.B. DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), Holografie-Speichersysteme, Blue Laser Disks, IBM Millipede-Einheiten usw.
  • Die Terminal-/Anzeigeschnittstelle 316 wird verwendet, um eine oder mehrere Anzeigeeinheiten wie den Monitor 380 mit dem Datenverarbeitungssystem 300 zu verbinden. Bei diesen Anzeigeeinheiten 380 kann es sich um nichtintelligente Terminals wie einen LED-Monitor oder um vollständig programmierbare Workstations handeln, die verwendet werden, um es IT-Administratoren und Kunden zu ermöglichen, mit dem DVS 300 Daten auszutauschen. Es ist jedoch zu beachten: obwohl die Anzeigenschnittstelle 316 bereitgestellt wird, um die Datenübertragung mit einer oder mehreren Anzeigen 380 zu unterstützen, benötigen die Computersysteme 300 nicht unbedingt eine Anzeige 380, da alle erforderlichen Interaktionen mit Kunden und anderen Prozessen über die Netzwerkschnittstelle 318 erfolgen können.
  • Bei dem Datenübertragungsmedium 306 kann es sich um ein beliebiges geeignetes Netzwerk oder eine Kombination von Netzwerken handeln, das/die jedes geeignete Protokoll unterstützt, das für die Übertragung von Daten und/oder Code zu/von mehreren DVS 300 geeignet ist. Bei der Netzwerkschnittstelle 318 kann es sich demzufolge um eine beliebige Einheit handeln, die diese Datenübertragung ermöglicht, unabhängig davon, ob die Netzwerkverbindung mit heutigen analogen und/oder digitalen Techniken oder über einen Netzwerkmechanismus der Zukunft hergestellt wird. Zu geeigneten Datenübertragungsmedien 306 gehören Netzwerke, die mit einer oder mehreren der Spezifikationen „InfiniBand“ oder IEEE (Institute of Electrical and Electronics Engineers) „Ethernet“ 802.3x implementiert sind; Mobilfunk-Übertragungsnetzwerke; drahtlose Netzwerke, die mit einer der Spezifikationen IEEE 802.11x, IEEE 802.16, General Packet Radio Service („GPRS“), FRS (Family Radio Service) oder Bluetooth implementiert sind; Ultrabreitband-Technologie („UWB“), wie sie in FCC 02-48 beschrieben ist, usw., ohne auf diese beschränkt zu sein. Für Fachleute ist offensichtlich, dass viele verschiedene Netzwerk- und Übertragungsprotokolle verwendet werden können, um das Datenübertragungsmedium 306 zu implementieren. Die Suite Transmission Control Protocol/Internet Protocol („TCP/IP“) enthält geeignete Netzwerk- und Übertragungsprotokolle.
  • Governance-Orchestrator für die Zugriffsverwaltung
  • 4 ist eine schematische Darstellung eines Governance-Orchestrators für die Zugriffsverwaltung 400 gemäß einigen Ausführungsformen. Diese Ausführungsform eines Governance-Orchestrators für die Zugriffsverwaltung 400 wird unter Bezugnahme auf eine Systemeignerfunktion 450, eine Prüffunktion 455, eine Benutzerfunktion zum Anfordern von Systemberechtigungen 460 und eine Systemadministratorfunktion 465 beschrieben, die über eine Blockchain 470 Daten austauschen. Bei einer veranschaulichenden Transaktion fordert der Benutzer beim Governance-Orchestrator für die Zugriffsverwaltung 400 eine zusätzliche Berechtigung 405 an, und die Eignerfunktion 450 kann diese Anforderung 415 genehmigen oder ablehnen. Nachdem die Eignerfunktion 450 die Anforderung genehmigt hat, kann die Systemadministratorfunktion 465 den entsprechenden Zugriff 425, 430 auf das/die physische(n) IT-System(e) gewähren. Der Prüfer 455 kann bestätigen (410), dass der Eigner diese neuen Berechtigungen genehmigt hat. In einigen Ausführungsformen können die Systemeignerfunktion 450, die Prüffunktion 455, die Benutzerfunktion zum Anfordern von Systemberechtigungen 460 und die Systemadministratorfunktion 465 alle Teil verschiedener juristischer Personen sein und daher verschiedene interne technische Systeme zum Verwalten des Zugriffs verwenden. In diesen Anwendungsfällen können die verschiedenen Funktionen über standardisierte Anwendungsprogrammierschnittstellen (API) oder Ähnliches mit dem Governance-Orchestrator für die Zugriffsverwaltung 400 verbunden sein.
  • Bei der Blockchain 470 kann es sich in dieser Ausführungsform um ein Netzwerk von Knoten 471A, 471B, 471C, 471D (zusammen die Knoten 471) handeln, die sich an verschiedenen logischen und physischen Entitätsorten (geografisch, Organisationen, Hosting usw.) befinden. Die Knoten 471 können über verschlüsselte Netzwerk-Datenübertragungskanäle 472 miteinander verbunden sein. In einigen Ausführungsformen können die Knoten 471 dieser Blockchain 470 nur hinzugefügt werden, wenn dies von den anderen bereits vorhandenen Knoten 471 in der Blockchain 470 gemäß einem Konsensprotokoll genehmigt wurde.
  • Jeder Knoten 471 kann in dieser Ausführungsform eine Kopie eines Distributed Ledger 473 (in 4 ist aus Gründen der Übersichtlichkeit nur eine Kopie dargestellt) enthalten, das alle zugelassenen Transaktionen aufführt, die an die Blockchain 470 gesendet wurden. Eine Transaktion kann in dieser Ausführungsform nur dann zugelassen werden, wenn zwischen den Knoten 471 in der Blockchain 470 gemäß dem Konsensprotokoll Einigung besteht. Eine Transaktion kann in dieser Ausführungsform nur zum Distributed Ledger 473 hinzufügt werden, wenn alle früheren Transaktionen im Distributed Ledger 473 unveränderlich sind und nicht geändert werden können. Das Distributed Ledger 473 kann darüber hinaus kryptografisch signiert werden, um sicherzustellen, dass eine Manipulation der Datensätze praktisch unmöglich ist.
  • In einigen Ausführungsformen können die Knoten 471 Smart Contracts ausführen (d.h., von Clients gesendete Computerprogramme, die Transaktionen im Ledger 473 verarbeiten, z.B. um die Durchführung der Transaktion digital zu ermöglichen, zu überprüfen oder umzusetzen). Zu ihren Aufgaben können gehören, ohne auf diese beschränkt zu sein: (i) Validieren von Transaktionen, d.h. Teilnahme am Konsensprotokoll, das neue Transaktionen im Ledger zulässt; (ii) Vorschlagen neuer Transaktionen für das Ledger, die zugelassen werden können und (iii) Durchführen von Maßnahmen mit externen Clients, um eine oder mehrere Transaktionen zu verarbeiten. Ein Smart Contract kann parallel auf allen Knoten 471 der Blockchain 470 ausgeführt werden, und das Ergebnis des Smart Contract kann nur von der Blockchain 470 zugelassen werden, wenn zwischen den Knoten 471 im Netzwerk Einigung gemäß einem Konsensprotokoll besteht.
  • In einigen Ausführungsformen kann es sich bei der Blockchain 470 um eine genehmigungspflichtige Blockchain handeln. In diesen Ausführungsformen können Clients (z.B. Benutzer, Software-Anwendungen) nur über die Knoten 471A, 471B, 471C, 471D mit der Blockchain 470 verbunden werden, die sie authentifiziert und denen sie Berechtigung erteilt. Clients können in diesen Ausführungsformen eine Blockchain-Netzwerk-API aufrufen, um Transaktionen zu senden, Transaktionszustände und Attribute abzufragen usw. Zu diesen Transaktionen können gehören, ohne auf diese beschränkt zu sein: (i) Clients, die neue Transaktionen vorschlagen, die zum Ledger hinzugefügt werden sollen und die dann das Konsensprotokoll durchlaufen, damit sie vom Distributed Ledger zugelassen werden; (ii) Clients, die prüfen, ob neue Transaktionen vom Distributed Ledger zugelassen wurden, zu deren Verarbeitung sie berechtigt sind, und (iii) Clients, die Smart Contracts an die Blockchain 470 senden.
  • In einigen Ausführungsformen kann das Zugriffsverwaltungssystem durch Verwenden der Blockchain 470 implementiert werden, um den Entitäten Identitäten zuordnen zu können, die Zugriffsrechte auf die von der Blockchain 470 bereitgestellten Verbindungs-/Aufrufdienste gewährt haben. Diese Entitäten können das Recht haben, sich mit einem bestehenden Knoten 471A, 471B, 471C, 471D zu verbinden oder einen zusätzlichen Knoten (nicht dargestellt) hinzuzufügen, mit dem sie sich verbinden können. Diese Entitäten können auch das Recht haben, Smart Contracts von dem Knoten 471A, 471B, 471C, 471D, mit denen sie verbunden sind, zu senden und mit ihnen zu interagieren. Diese Entitäten und die von ihnen gesendeten Smart Contracts können das Recht haben, Transaktionen zu erhalten/zu senden, deren Attribute mit den Kriterien der Zugriffsrichtlinie übereinstimmen.
  • Blockchain-Netzwerk-API
  • Einige Ausführungsformen können die folgenden Arten von Transaktionen zusammen mit den folgenden Attributen unterstützen:
    • RequestAccess (UID, ITSystemID, Berechtigungen, Grund)
    • AccessApproved (UID, ITSystemID, Berechtigungen, UIDOwner, Beschreibung der Genehmigung, RequestTID)
    • AccessDenied (UID, ITSystemID, Berechtigungen, UIDOwner, Beschreibung der Ablehnung, RequestTID)
    • GrantAccess (UID, ITSystemID, Berechtigungen, UlDAdmin, Grund, Beschreibung der Genehmigung, ApprovalTID)
    • AccessGranted (UID, ITSystemID, Berechtigungen, UlDAdmin, Grund, Beschreibung der Genehmigung, ApprovalTID)
    • RevokeAccess (UID, ITSystemID, UIDAM/UIDAuditor, Grund)
    • AccessRevoked (UID, ITSystemID, UIDAM/UIDAuditor, Grund)
    • RequestValidationP ()
      1. 1. Für neue Transaktion RequestAccess (UID, ITSystemID, Berechtigungen, Grund)
      2. 2. UIDOwner der ITSystemlD des Systems finden
      3. 3. Transaktion RequestApproveAccess (UID, ITSystemID, Berechtigungen, UIDOwner, Grund, RequestTID) senden
    • OwnerApprovalP (ITSystemID)
      1. 1. Für neue Transaktion RequestAccess (UID, ITSystemID, Berechtigungen, UIDOwner) mit ITSystemlD == ITSystemlD
      2. 2. Überprüfen, ob der von der UID bereitgestellte Grund zum Anfordern des Zugriffs auf die ITSystemlD mit Berechtigungen gültig ist
      3. 3. Wenn er gültig ist
        1. 1. Transaktion ApprovalTID = AccessApproved (UID, ITSystemID, Berechtigungen, UIDOwner, Beschreibung der Genehmigung, RequestTID) senden
        2. 2. Transaktion GrantAccess (UID, ITSystemID, Berechtigungen, UIDOwner, Beschreibung der Genehmigung, ApprovalTID) senden
      4. 4. Andernfalls Transaktion AccessDenied (UID, ITSystemID, Berechtigungen, UIDOwner, Beschreibung der Ablehnung, RequestTID) senden
    • GrantAccessP (ITSystemID)
      1. 1. Für neue Transaktion AccessGranted (UID, ITSystemID, Berechtigungen, UIDOwner, Beschreibung der Genehmigung, RequestTID) mit ITSystemlD == ITSystemID
      2. 2. Nochmals prüfen, ob UIDOwner der Eigner der ITSystemlD ist, anschließend Nachricht an ITSystemlD des Zugriffssteuerungssystems (Berechtigung) senden, um Maßnahme durchzuführen: Mit Parametern UID, ITSystemID, Berechtigungen, UIDOwner, Beschreibung der Genehmigung, RequestTID gewähren. Die Maßnahme „Gewähren“ ändert die Berechtigungsrichtlinie, um den Zugriff der Benutzer-UID auf die ITSystemlD der Systeme zu erlauben.
    • LogAccess( ITSystem ID)
      1. 1. Auf Anforderung von Bob warten, um die Maßnahme „Gewähren“ oder „Zurücknehmen“ unter Weitergabe der Parameter durchzuführen: UID, ITSystemID, UIDAdmin, Beschreibung, RequestTID
      2. 2. Wenn Maßnahme = Gewähren, dann den Zugriff für UID aktualisieren und Transaktion AccessGranted (UID, ITSystemID, Berechtigungen, UlDAdmin, Beschreibung, ApprovalTID) senden
      3. 3. Andernfalls Maßnahme = Zurücknehmen, dann Zugriff für UID zurücknehmen und Transaktion AccessRevoked (UID, ITSystemID, UIDOwner, Beschreibung, ApprovalTID) senden
    • RevokeAccessP (ITSystemID)
      1. 1. Für neue Transaktion RevokeAccess (UID, ITSystemID, UIDOwner, Grund, RequestTID) mit ITSystemlD == ITSystemlD
      2. 2. Nochmals prüfen, ob UIDOwner gültig ist, anschließend Nachricht an die ITSystemlD des Zugriffssteuerungssystems (Berechtigung) senden, um Maßnahme „Zurücknehmen“ mit Parametern UID, ITSystemID, UIDOwner, Beschreibung der Zurücknahme, RequestTID) senden. Die Maßnahme „Zurücknehmen“ ändert die Berechtigungsrichtlinie, um den Zugriff der Benutzer-UID auf die ITSystemlD der Systeme abzulehnen.
    • AuditActionsP (Liste der ITSystemIDs)
      1. 1. Für neue Transaktionen mit ITSystemlD in Liste der ITSystemIDs
      2. 2. Die Transaktionen validieren und sicherstellen, dass die Sicherheitsrichtlinien eingehalten werden. Zum Beispiel:
        • • RequestApproved: RequestTID ist RequestAccess für UID, UIDOwner ist der Eigner der ITSystemID, Grund ist gültig
        • • GrantAccess: ApprovalTID ist eine AccessApproved-Transaktion für UID/SystemlD, UIDOwner ist der Eigner der ITSystemID, Genehmigungsgrund ist gültig
        • • AccessGranted: ApprovalTID ist eine AccessApproved-Transaktion für UID/SystemlD, UIDOwner ist der Eigner der ITSystemID, UIDAdmin ist der Administrator der SystemID, Genehmigungsgrund ist gültig
        • • Wenn die Richtlinien nicht eingehalten werden, Sicherheitsvorfall einleiten
  • Veranschaulichendes Beispiel
  • Wenn in einem veranschaulichenden Beispiel die folgenden Entitäten mit den folgenden spezifizierten Identitäten in einem bestimmten System zum Orchestrieren von Berechtigungen vorhanden sind:
    • Eve: Eignerorganisation von ITSystemID1 der Systeme,
    • Eve: Eignerorganisation von ITSystemlD2 der Systeme
    • Bob (reale Person oder Automatisierung): Administrator von ITSystemID1, ITSystemlD2 der Systeme
    • Prüfer: Prüforganisation von ITSystemID1, ITSystemlD2
    • Alice: Privilegierte Benutzerin
    und die folgenden Zugriffsrichtlinien festgelegt sind:
    • Eve: liest RequestAccess-Transaktionen mit Attributen ITSystemlD = ITSystemID1, ITSystemID2
    • Eve: sendet AccessApproved-, AccessDenied-, GrantAccess-, RevokeAccess-Transaktionen mit Attributen ITSystemlD = ITSystemID1, ITSystemlD2
    • Bob: liest GrantAccess-, RevokeAccess-, Request-Transaktionen mit Attributen ITSystemlD = ITSystemID1, ITSystemlD2
    • Bob: ITSystemID1, ITSystemlD2: AccessGranted-, AccessRevoked-Transaktionen mit Attributen ITSystemlD = ITSystemID1, ITSystemlD2 senden
    • Prüfer: liest alle Arten von Transaktionen mit beliebigen Attributen
    und folgende Knoten zur Blockchain 470 hinzugefügt wurden:
    • Knoten1: Gehostet von der Zugriffsverwaltungsorganisation
    • Knoten2: Gehostet von der Eignerorganisation von ITSystemID1 der Systeme,
    • ITSystemlD2 der Systeme
    • Knoten3: Gehostet vom Administrator von ITSystemID1, ITSystemID2 der Systeme
    • Knoten4: Gehostet von der Prüforganisation von ITSystemID1, ITSystemlD2
  • In diesem veranschaulichenden Beispiel kann anschließend die folgende Verarbeitung von den Clients durchgeführt werden, die die Blockchain-Netzwerk-API im Betrieb aufrufen:
    • Alice verbindet sich mit Knoten1, um eine Zugriffsanforderung für ITSystemID1 zu senden
    • Eve verbindet sich mit Knoten2 und führt das Programm OwnerApprovalP (ITSystemID1) aus
    • Eve verbindet sich mit Knoten2 und führt das Programm Owner ApprovalSP (ITSystemID2) aus
    • Bob verbindet sich mit Knoten3 und führt das Programm GrantAccessP (ITSystemID1) aus
    • Bob verbindet sich mit Knoten3 und führt das Programm GrantAccessP (ITSystemID2) aus
    • Bob verbindet sich mit Knoten3 und führt das Programm RevokeAccessP (ITSystemID1) aus
    • Bob verbindet sich mit Knoten3 und führt das Programm RevokeAccessP (ITSystemID2) aus
    • ITSystemID1 und ITSystemlD2 verbinden sich mit Knoten3 und führen das Programm LogAccessP() aus
    • Der Prüfer verbindet sich mit Knoten4 und führt AuditActionsP (ITSystemID1, ITSystem1D2) zur Ausführung aus
  • Blockchain-Architektur
  • 5A veranschaulicht eine Konfiguration 500 einer Blockchain-Architektur gemäß einigen Ausführungsformen. Die Blockchain-Architektur 500 kann in diesen Ausführungsformen bestimmte Blockchain-Elemente enthalten, so beispielsweise eine Gruppe von Blockchain-Knoten 502. Die Gruppe von Blockchain-Knoten 502 kann ihrerseits einen oder mehrere Mitgliedsknoten 504 bis 510 umfassen (diese vier Knoten sind nur beispielhaft dargestellt). Diese Mitgliedsknoten 504 bis 510 können an einer Reihe von Aktivitäten beteiligt sein, z.B. am Hinzufügen von Blockchain-Transaktionen und am Validierungsprozess (Konsens). Ein oder mehrere der Mitgliedsknoten 504 bis 510 können Transaktionen auf der Grundlage einer Endorsement Policy (Bestätigungsrichtlinie) bestätigen und einen Sortierdienst für alle Blockchain-Knoten in der Architektur 500 bereitstellen. Ein Mitgliedsknoten 504 bis 510 kann eine Blockchain-Authentifizierung initiieren und versuchen, in ein unveränderliches Blockchain-Ledger zu schreiben, das in der Blockchain-Schicht 516 gespeichert ist, von der eine Kopie auch in der zugrunde liegenden physischen Infrastruktur 514 gespeichert sein kann.
  • In einigen Ausführungsformen kann die Blockchain-Architektur 500 eine oder mehrere Anwendungen 524 umfassen, die mit Anwendungsprogrammierschnittstellen (APIs) 522 verbunden sind, um auf gespeicherten Programm-/Anwendungscode 520 (z.B. Chaincode, Smart Contracts usw.) zuzugreifen und ihn auszuführen. Der gespeicherte Programm-/Anwendungscode 520 kann seinerseits nach einer von den Teilnehmern gewünschten individuellen Konfiguration erzeugt werden und seinen eigenen Zustand beibehalten, seine eigenen Assets steuern und externe Informationen empfangen. Der gespeicherte Programm-/Anwendungscode 520 kann als Transaktion implementiert und durch Anhängen an das Distributed Ledger auf allen Blockchain-Knoten 504 bis 510 implementiert werden.
  • Eine Blockchain-Basis oder -Plattform 512 kann verschiedene Schichten von Blockchain-Daten, Dienste (z.B. kryptografische Vertrauensdienste, virtuelle Ausführungsumgebung usw.) und die zugrunde liegende physische Computerinfrastruktur umfassen, die dazu verwendet werden kann, neue Transaktionen zu empfangen und zu speichern und Prüfern, die auf Dateneinträge zugreifen wollen, den Zugriff bereitzustellen. Eine Blockchain-Schicht 516 kann eine Schnittstelle zur Verfügung stellen, die den Zugriff auf die virtuelle Ausführungsumgebung bereitstellt, die erforderlich ist, um den Programmcode zu verarbeiten und eine physische Infrastruktur 514 zu nutzen. Die kryptografischen Vertrauensdienste 518 können verwendet werden, um Transaktionen wie den Austausch von Assets zu überprüfen und Informationen vertraulich zu halten.
  • Die Konfiguration der Blockchain-Architektur von 5A kann den Programm-/Anwendungscode 520 über eine oder mehrere von der Blockchain-Plattform 512 zur Verfügung gestellte Schnittstellen und bereitgestellte Dienste verarbeiten und ausführen. Der Programm-/Anwendungscode 520 kann Blockchain-Assets kontrollieren. Der Code 520 kann beispielsweise Daten speichern und übertragen und von den Mitgliedsknoten 504 bis 510 in Form eines Smart Contract und eines zugehörigen Chaincodes mit Bedingungen oder anderen Codeelementen ausgeführt werden, die seiner Ausführung unterliegen. In einem nichteinschränkenden Beispiel können Smart Contracts erzeugt werden, um Erinnerungen, Aktualisierungen und/oder Mitteilungen aufgrund von Änderungen, Aktualisierungen usw. auszuführen. Die Smart Contracts können ihrerseits dazu verwendet werden, Regeln zu identifizieren, die den Autorisierungs- und Zugriffsanforderungen und der Nutzung des Ledger zugehörig sind. Beispielsweise können Dokumentattributinformationen 526 von einer oder mehreren Verarbeitungsentitäten (z.B. virtuelle Maschinen) verarbeitet werden, die in der Blockchain-Schicht 516 enthalten sind. Ein Ergebnis 528 kann eine Mehrzahl von verknüpften, gemeinsam genutzten Dokumenten enthalten. Die physische Infrastruktur 514 kann zum Abrufen der hier beschriebenen Daten oder Informationen verwendet werden.
  • In einigen Ausführungsformen kann der Smart Contract über eine hoch entwickelte Anwendung und Programmiersprache erzeugt und dann in einen Block in der Blockchain geschrieben werden. Der Smart Contract kann einen ausführbaren Code enthalten, der in einer Blockchain (z.B. einem verteilten Netzwerk von Blockchain-Peers) registriert, gespeichert und/oder repliziert wird. Eine Transaktion ist eine Ausführung des Codes des Smart Contract, die als Reaktion auf Bedingungen, die dem Smart Contract zugehörig sind und erfüllt werden, durchgeführt werden kann. Das Ausführen des Smart Contract kann (eine) vertrauenswürdige Änderung(en) eines Zustands eines digitalen Blockchain-Ledger auslösen. Die durch das Ausführen des Smart Contract verursachte(n) Änderung(en) des Blockchain-Ledger kann (können) in einigen Ausführungsformen automatisch im gesamten verteilten Netzwerk von Blockchain-Peers durch ein oder mehrere Konsensprotokolle repliziert werden.
  • Der Smart Contract kann Daten im Format von Schlüssel-Wert-Paaren in die Blockchain schreiben. Darüber hinaus kann der Code des Smart Contract in einigen Ausführungsformen die in einer Blockchain gespeicherten Werte lesen und in Operationen der Anwendung verwenden. Der Code des Smart Contract kann in diesen Ausführungsformen die Ausgabe verschiedener logischer Operationen anschließend in die Blockchain schreiben. Der Code des Smart Contract kann in einigen Ausführungsformen dazu verwendet werden, eine temporäre Datenstruktur in einer virtuellen Maschine oder einer anderen Datenverarbeitungsplattform zu erzeugen. Daten, die in diesen Ausführungsformen in die Blockchain geschriebenen werden, können öffentlich oder verschlüsselt sein und als vertraulich behandelt werden. Die temporären Daten, die vom Smart Contract verwendet/erzeugt werden, können von der bereitgestellten Ausführungsumgebung im Speicher gespeichert und dann gelöscht werden, sobald die für die Blockchain benötigten Daten identifiziert sind.
  • Der Chaincode kann in einigen Ausführungsformen die Code-Interpretation eines Smart Contract umfassen und zusätzliche Funktionen enthalten. In einigen Ausführungsformen kann der Chaincode als Programmcode in einem Datenverarbeitungsnetzwerk implementiert werden, wo er von den Chain-Validierern im Rahmen eines Konsensverfahrens ausgeführt und validiert wird. Der Chaincode kann einen Hash empfangen und aus der Blockchain einen Hash abrufen, der der Datenvorlage zugehörig ist, die durch die Verwendung eines zuvor gespeicherten Merkmalsextraktors erzeugt wurde. Stimmen die Hashes der Hash-Kennung und der aus den gespeicherten Kennungsvorlagedaten erzeugte Hash überein, kann der Chaincode einen Autorisierungsschlüssel an den angeforderten Dienst senden. Der Chaincode kann Daten in die Blockchain schreiben, die den kryptografischen Einzelheiten zugehörig sind.
  • 5B veranschaulicht ein Beispiel für einen Blockchain-Transaktionsablauf 550 zwischen Knoten der Blockchain gemäß einigen Ausführungsformen. In diesen Ausführungsformen kann der Transaktionsablauf einen Transaktionsvorschlag 591 umfassen, der von einem Anwendungs-Client-Knoten 560 an einen bestätigenden Peer-Knoten 581 gesendet wird. Der bestätigende Peer 581 kann die Client-Signatur prüfen und eine Chaincode-Funktion ausführen, um die Transaktion zu initiieren. Die Ausgabe kann die Chaincode-Ergebnisse, einen Satz von Schlüssel/Wert-Versionen, die im Chaincode gelesen wurden (Lesesatz), und den Satz von Schlüsseln/Werten, die in den Chaincode geschrieben wurden (Schreibsatz), umfassen. Die Antwort 592 auf den Vorschlag kann anschließend zusammen mit einer Bestätigungssignatur (falls genehmigt) an den Client 560 zurückgesendet werden.
  • Als Reaktion darauf kann der Client 560 die Bestätigungen in den Transaktionsnutzdaten 593 zusammenstellen und diese an einen Sortierdienstknoten 584 übertragen. Der Sortierdienstknoten 584 kann dann sortierte Transaktionen als Blöcke an alle Peers 581 bis 583 in einem Kanal ausgeben. Vor dem Festschreiben in der Blockchain kann jeder Peer 581 bis 583 die Transaktion validieren. So können die Peers in einigen Ausführungsformen beispielsweise die Endorsement Policy überprüfen, um sicherzustellen, dass die richtige Anzahl der angegebenen Peers die Ergebnisse signiert und die Signaturen anhand der Transaktionsnutzdaten 593 authentifiziert hat.
  • Weiterhin mit Bezug auf 5B kann der Client-Knoten 560 in einigen Ausführungsformen die Transaktion 591 initiieren, indem er eine Anforderung an den Peer-Knoten 581 erzeugt und sendet, der als Endorser (Berechtiger) fungieren kann. Der Client 560 kann eine Anwendung umfassen, die ein unterstütztes Software-Entwicklungskit (software development kit - SDK) nutzt, das eine verfügbare API verwenden kann, um einen Transaktionsvorschlag zu erzeugen. Bei dem Transaktionsvorschlag wiederum kann es sich um eine Anforderung handeln, eine Chaincode-Funktion aufzurufen, damit Daten gelesen und/oder in das Distributed Ledger geschrieben werden können (d.h., neue Schlüssel-Wert-Paare für die Assets schreiben). Das SDK kann als Shim dienen, um den Transaktionsvorschlag in ein geeignetes Architekturformat zu packen (z.B. Protokoll puffer über einen Fernprozeduraufruf (remote procedure call - RPC)) und die kryptografischen Berechtigungsnachweise des Clients zu verwenden, um eine eindeutige Signatur für den Transaktionsvorschlag zu erzeugen.
  • Als Reaktion darauf kann der bestätigende Peer-Knoten 281 prüfen: ob (a) der Transaktionsvorschlag korrekt formatiert ist; (b) die Transaktion nicht bereits in der Vergangenheit gesendet wurde (Schutz vor Wiederholungsangriffen); (c) die Signatur gültig ist und (d) der Sender (in dieser beispielhaften Ausführungsform der Client 560) ordnungsgemäß berechtigt ist, die vorgeschlagene Operation auf diesem Kanal durchzuführen. Der bestätigende Peer-Knoten 581 kann die Eingaben des Transaktionsvorschlags als Argumente für die aufgerufene Chaincode-Funktion verwenden. Der Chaincode kann dann auf der Grundlage einer Datenbank mit dem aktuellen Zustand ausgeführt werden, um Transaktionsergebnisse zu erzeugen, darunter ein Antwortwert, ein Lesesatz und ein Schreibsatz. In einigen Ausführungsformen wird das Ledger zu diesem Zeitpunkt nicht aktualisiert. Stattdessen können der Satz von Werten zusammen mit der Signatur des bestätigenden Peer-Knotens 581 als Antwort 592 auf den Vorschlag an das SDK des Clients 560 zurückgesendet werden, der die Nutzdaten für die Anwendung zur Nutzung parst.
  • Als Reaktion darauf kann die Anwendung des Clients 560 die Signaturen der bestätigenden Peers überprüfen/verifizieren und die Vorschlagsantworten vergleichen, um zu ermitteln, ob die Vorschlagsantwort dieselbe ist. Würde der Chaincode nur das Ledger abfragen, könnte die Anwendung die Antwort auf die Abfrage überprüfen und würde die Transaktion in der Regel nicht an den Sortierdienstknoten 584 senden. Beabsichtigt die Client-Anwendung, die Transaktion zum Aktualisieren des Ledger an den Sortierknotendienst 584 zu senden, kann die Anwendung vor dem Senden ermitteln, ob die angegebene Endorsement Policy erfüllt ist (d.h., haben alle für die Transaktion erforderlichen Peer-Knoten die Transaktion bestätigt). In diesem Fall kann der Client nur eine von mehreren an der Transaktion beteiligten Parteien aufnehmen. In diesem Fall kann jeder Client seinen eigenen bestätigenden Knoten haben, und jeder bestätigende Knoten muss die Transaktion bestätigen. Die Architektur ist so angelegt, dass die Endorsement Policy auch dann von den Peers bestätigt und in der Phase des Festschreibens und Validierens aufrechterhalten wird, wenn eine Anwendung sich dafür entscheidet, Antworten nicht zu überprüfen oder ansonsten eine nichtbestätigte Transaktion weiterzuleiten.
  • Nach erfolgreichem Überprüfen kann der Client 560 in der Operation 593 Bestätigungen zu einer Transaktion zusammenstellen und den Transaktionsvorschlag und die Antwort in einer Transaktionsnachricht an den Sortierknoten 584 senden. Die Transaktion kann die Lese-/Schreibsätze, die Signaturen der bestätigenden Peers und eine Kanal-ID enthalten. Der Sortierknoten 584 muss nicht den gesamten Inhalt einer Transaktion überprüfen, um seine Operation durchzuführen; stattdessen kann der Sortierknoten 584 einfach Transaktionen von allen Kanälen im Netzwerk empfangen, sie chronologisch nach Kanal sortieren und Blöcke von Transaktionen pro Kanal erzeugen.
  • Die Blöcke der Transaktion können vom Sortierknoten 584 an alle Peer-Knoten 581 bis 583 im Kanal übermittelt werden. Die Transaktionen 594 im Block können validiert werden, um sicherzustellen, dass die Endorsement Policy erfüllt ist und dass keine Änderungen am Zustand des Ledger für die Variablen des Lesesatzes vorgenommen wurden, seit der Lesesatz durch das Ausführen der Transaktion erzeugt wurde. Transaktionen im Block können als gültig oder ungültig gekennzeichnet werden. Darüber hinaus kann jeder Peer-Knoten 581 bis 583 in der Operation 595 den Block an die Chain des Kanals anfügen, und für jede gültige Transaktion werden die Schreibsätze in der aktuellen Zustandsdatenbank festgeschrieben. Ein Ereignis kann ausgelöst werden, um die Client-Anwendung darüber zu informieren, dass die Transaktion (der Aufruf) unveränderlich an die Chain angehängt wurde, und um mitzuteilen, ob die Transaktion für gültig oder ungültig erklärt wurde.
  • Genehmigungspflichte Blockchains
  • 6A veranschaulicht gemäß einigen Ausführungsformen ein Beispiel für ein genehmigungspflichtiges Blockchain-Netzwerk, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. In diesem Beispiel kann ein Blockchain-Benutzer 602 eine Transaktion in der genehmigungspflichtigen Blockchain 604 beginnen. In diesem Beispiel kann es sich bei der Transaktion um Implementieren, Aufrufen oder Abfragen handeln, und sie kann über eine clientseitige Anwendung, die ein SDK nutzt, direkt über eine API usw. ausgegeben werden. Netzwerke können den Zugriff auf einen Regulierer 606, z.B. einen Prüfer, bereitstellen. Ein Blockchain-Netzwerkbetreiber 608 verwaltet die Genehmigungen der Mitglieder, z.B. Anmelden des Regulierers 606 als „Prüfer“ und des Blockchain-Benutzers 602 als „Client“. Ein Prüfer kann darauf beschränkt sein, nur das Ledger abzufragen, während ein Client berechtigt sein kann, bestimmte Arten von Chaincode zu implementieren, aufzurufen und abzufragen.
  • Ein Blockchain-Entwickler 610 kann in einigen Ausführungsformen Chaincode und clientseitige Anwendungen schreiben. Der Blockchain-Entwickler 610 kann in diesen Ausführungsformen Chaincode über eine Schnittstelle direkt in dem Netzwerk implementieren. Um Berechtigungsnachweise aus einer herkömmlichen Datenquelle 612 in Chaincode zu integrieren, kann der Entwickler 610 eine Out-of-Band-Verbindung verwenden, um auf die Daten zuzugreifen. In diesem Beispiel kann sich der Blockchain-Benutzer 602 über einen Peer-Knoten 614 mit der genehmigungspflichtigen Blockchain 604 verbinden. Bevor der Peer-Knoten 614 mit den Transaktionen fortfährt, kann er die Anmelde- und Transaktionszertifikate des Benutzers von einer Zertifizierungsstelle 616 abrufen, die Benutzerrollen und -genehmigungen verwaltet. In einigen Ausführungsformen müssen die Benutzer der Blockchain diese digitalen Zertifikate besitzen, um in der genehmigungspflichtigen Blockchain 604 Transaktionen durchführen zu können. In anderen Ausführungsformen können die Benutzer der Blockchain mit anderen Techniken, z.B. über verteilte Vertrauensketten, authentifiziert werden. In der Zwischenzeit muss ein Benutzer, der Chaincode verwenden möchte, unter Umständen seine Berechtigungsnachweise in der herkömmlichen Datenquelle 612 überprüfen. Um die Berechtigung des Benutzers zu bestätigen, kann der Chaincode eine Out-of-Band-Verbindung zu diesen Daten über eine herkömmliche Verarbeitungsplattform 618 nutzen.
  • 6B veranschaulicht gemäß einigen Ausführungsformen ein weiteres Beispiel für ein genehmigungspflichtiges Blockchain-Netzwerk, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. In diesem Beispiel kann ein Blockchain-Benutzer 622 eine Transaktion an die genehmigungspflichtige Blockchain 624 senden. In diesem Beispiel kann es sich bei der Transaktion um Implementieren, Aufrufen oder Abfragen handeln, und sie kann über eine clientseitige Anwendung, die ein SDK nutzt, direkt über eine API usw. ausgegeben werden. Netzwerke können den Zugriff auf einen Regulierer 626, z.B. einen Prüfer, bereitstellen. Ein Blockchain-Netzwerkbetreiber 628 verwaltet die Genehmigungen der Mitglieder, z.B. Anmelden des Regulierers 626 als „Prüfer“ und des Blockchain-Benutzers 622 als „Client“. Ein Prüfer könnte darauf beschränkt sein, nur das Ledger abzufragen, während ein Client berechtigt sein könnte, bestimmte Arten von Chaincode zu implementieren, aufzurufen und abzufragen.
  • Ein Blockchain-Entwickler 631 kann in diesen Ausführungsformen Chaincode und clientseitige Anwendungen schreiben. Der Blockchain-Entwickler 631 kann Chaincode über eine Schnittstelle direkt in dem Netzwerk implementieren. Um Berechtigungsnachweise aus einer herkömmlichen Datenquelle 632 in Chaincode zu integrieren, kann der Entwickler 631 eine Out-of-Band-Verbindung verwenden, um auf die Daten zuzugreifen. In diesem Beispiel verbindet sich der Blockchain-Benutzer 622 über einen Peer-Knoten 634 mit dem Netzwerk. Bevor der Peer-Knoten 634 mit den Transaktionen fortfährt, ruft er die Anmelde- und Transaktionszertifikate des Benutzers von der Zertifizierungsstelle 636 ab. In einigen Ausführungsformen müssen die Benutzer der Blockchain diese digitalen Zertifikate besitzen, um in der genehmigungspflichtigen Blockchain 624 Transaktionen durchführen zu können. In anderen Ausführungsformen können die Benutzer der Blockchain mit anderen Techniken, z.B. über verteilte Vertrauensketten, authentifiziert werden. In der Zwischenzeit muss ein Benutzer, der Chaincode verwenden möchte, unter Umständen seine Berechtigungsnachweise in der herkömmlichen Datenquelle 632 überprüfen. Um die Berechtigung des Benutzers zu bestätigen, kann der Chaincode eine Out-of-Band-Verbindung zu diesen Daten über eine herkömmliche Verarbeitungsplattform 638 nutzen.
  • 6C veranschaulicht gemäß beispielhaften Ausführungsformen ein beispielhaftes System, das eine physische Infrastruktur 611 umfasst, die so konfiguriert ist, dass sie verschiedene Operationen durchführt. Mit Bezug auf 6C umfasst die physische Infrastruktur 611 ein Modul 688 und ein Modul 689. Das Modul 619 umfasst eine Blockchain 620 und einen Smart Contract 630 (der sich in der Blockchain 620 befinden kann), der jeden der in einer der beispielhaften Ausführungsformen enthaltenen operativen Schritte 678 (in Modul 612) ausführen kann. Die Schritte/Operationen 678 können eine oder mehrere der beschriebenen oder dargestellten Ausführungsformen umfassen und können ausgegebene oder geschriebene Informationen darstellen, die in einen oder mehrere Smart Contracts 630 und/oder Blockchains 620 geschrieben oder daraus gelesen werden. Die physische Infrastruktur 611, das Modul 688 und das Modul 689 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Datenübertragungseinheiten umfassen. Weiterhin können das Modul 688 und das Modul 689 ein und dasselbe Modul sein.
  • 6D veranschaulicht gemäß einigen Ausführungsformen ein weiteres beispielhaftes System, das so konfiguriert ist, dass es verschiedene Operationen durchführt. Mit Bezug auf 6D umfasst das System ein Modul 612 und ein Modul 614. Das Modul 614 umfasst eine Blockchain 620 und einen Smart Contract 630 (der sich in der Blockchain 620 befinden kann), der jeden der in einer der beispielhaften Ausführungsformen enthaltenen operativen Schritte 678 (in Modul 612) ausführen kann. Die Schritte/Operationen 678 können eine oder mehrere der beschriebenen oder dargestellten Ausführungsformen umfassen und können ausgegebene oder geschriebene Informationen darstellen, die in einen oder mehrere Smart Contracts 630 und/oder Blockchains 620 geschrieben oder daraus gelesen werden. Das physische Modul 612 und das Modul 614 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Datenübertragungseinheiten umfassen. Weiterhin können das Modul 612 und das Modul 614 ein und dasselbe Modul sein.
  • 6E veranschaulicht gemäß beispielhaften Ausführungsformen ein beispielhaftes System, das so konfiguriert ist, dass es eine Konfiguration eines Smart Contract zwischen Vertragsparteien und einem vermittelnden Server verwendet, der so konfiguriert ist, dass er die Bedingungen des Smart Contract in der Blockchain 620 umsetzt. Mit Bezug auf 6E kann die Konfiguration eine Datenübertragungssitzung, eine Asset-Übertragungssitzung oder einen Prozess oder eine Prozedur darstellen, die durch einen Smart Contract 630 gesteuert wird, der ausdrücklich eine oder mehrere Benutzereinheiten 652 und/oder 656 identifiziert. Die Ausführung, die Operationen und die Ergebnisse der Ausführung des Smart Contract können von einem Server 654 verwaltet werden. Der Inhalt des Smart Contract 630 kann digitale Signaturen von einer oder mehreren der Entitäten 652 und 656 erfordern, die an der Transaktion des Smart Contract beteiligt sind. Die Ergebnisse der Ausführung des Smart Contract können als Blockchain-Transaktion in eine Blockchain 620 geschrieben werden. Der Smart Contract 630 befindet sich in der Blockchain 620, die sich in einem oder mehreren Computern, Servern, Prozessoren, Speichern und/oder drahtlosen Datenübertragungseinheiten befinden kann.
  • 6F veranschaulicht gemäß einigen Ausführungsformen ein System 660, das eine Blockchain umfasst. Mit Bezug auf das Beispiel von 6D stellt ein Anwendungsprogrammierschnittstellen(API)-Gateway 662 eine gemeinsame Schnittstelle für den Zugriff auf eine Blockchain-Logik (z.B. Smart Contract 630 oder anderer Chaincode) und Daten (z.B. Distributed Ledger usw.) bereit. In diesem Beispiel ist das API-Gateway 662 eine gemeinsame Schnittstelle zum Durchführen von Transaktionen (Aufrufe, Abfragen usw.) in der Blockchain, indem eine oder mehrere Entitäten 652 und 656 mit einem Blockchain-Peer (d.h. einem Server 654) verbunden werden. In diesem Fall ist der Server 654 eine Peer-Komponente des Blockchain-Netzwerks, die eine Kopie des World State (allgemeiner Zustand) und ein Distributed Ledger enthält, das es den Clients 652 und 656 ermöglicht, Daten über den World State abzufragen und Transaktionen an das Blockchain-Netzwerk zu senden, wo die bestätigenden Peers die Smart Contracts 630 je nach Smart Contract 630 und Endorsement Policy ausführen werden.
  • Blockverarbeitung
  • 7A veranschaulicht gemäß beispielhaften Ausführungsformen einen Prozess 700, bei dem ein neuer Block zu einem Distributed Ledger 720 hinzugefügt wird, und 7B veranschaulicht gemäß beispielhaften Ausführungsformen den Inhalt einer neuen Datenblockstruktur 730 für eine Blockchain. Der neue Datenblock 730 kann Dokumentverknüpfungsdaten enthalten.
  • Mit Bezug auf 7A können Clients (nicht dargestellt) Transaktionen an die Blockchain-Knoten 711, 712 und/oder 713 senden. Clients können Anweisungen sein, die von einer beliebigen Quelle empfangen werden, um eine Aktivität in der Blockchain 722 auszuführen. Bei den Clients kann es sich beispielsweise um Anwendungen handeln, die im Namen eines Anforderers, z.B. einer Einheit, einer Person oder einer Entität, handeln, um Transaktionen für die Blockchain vorzuschlagen. Die Mehrzahl von Blockchain-Peers (z.B. die Blockchain-Knoten 711, 712 und 713) können einen Zustand des Blockchain-Netzwerks und eine Kopie des Distributed Ledger 720 speichern. Im Blockchain-Netzwerk können verschiedene Arten von Blockchain-Knoten/Peers vorhanden sein, z.B. bestätigende Peers, die von Clients vorgeschlagene Transaktionen simulieren und bestätigen, und festschreibende Peers, die Bestätigungen überprüfen, Transaktionen validieren und diese im Distributed Leder 720 festschreiben. In einigen Ausführungsformen können die Blockchain-Knoten 711, 712 und 713 die Rolle eines Endorser-Knotens, eines festschreibenden Knotens oder beider durchführen.
  • Das Distributed Ledger 720 kann eine Blockchain umfassen, die unveränderliche, sequenzierte Datensätze in Blöcken speichert, und eine Zustandsdatenbank 724 (aktueller World State), in der ein aktueller Zustand der Blockchain 722 gespeichert ist. Pro Kanal kann ein Distributed Ledger 720 vorhanden sein, und jeder Peer unterhält seine eigene Kopie des Distributed Ledger 720 für jeden Kanal, dessen Mitglied er ist. Die Blockchain 722 kann ein Transaktionsprotokoll sein, das in Form von Hash-verknüpften Blöcken aufgebaut ist, wobei jeder Block eine Folge von N Transaktionen enthält. Blöcke können verschiedene Komponenten umfassen, wie z.B. in 7B dargestellt. Die Verknüpfung der Blöcke (in 7A durch Pfeile dargestellt) kann durch Hinzufügen eines Hash des Kopfes eines früheren Blocks in einen Blockkopf eines aktuellen Blocks erzeugt werden. Auf diese Weise können alle Transaktionen in der Blockchain 722 sequenziert und kryptografisch miteinander verknüpft werden, um eine Manipulation der Blockchain-Daten zu verhindern, ohne die Hash-Verknüpfungen zu unterbrechen. Aufgrund der Verknüpfungen stellt der letzte Block in der Blockchain 722 außerdem jede Transaktion, die vor ihm stattgefunden hat, dar. Die Blockchain 722 kann in einem Peer-Dateisystem (lokaler oder angeschlossener Speicher) gespeichert werden, das eine Append-only-Blockchain-Arbeitslast unterstützt.
  • Der aktuelle Zustand der Blockchain 722 und des Distributed Ledger 720 kann in der Zustandsdatenbank 724 gespeichert werden. In diesem Fall stellen die Daten des aktuellen Zustands die neuesten Werte für alle jemals im Chain-Transaktionsprotokoll der Blockchain 722 enthaltenen Schlüssel dar. Chaincode-Aufrufe führen Transaktionen auf der Grundlage des aktuellen Zustands in der Zustandsdatenbank 724 aus. Damit diese Chaincode-Interaktionen höchst effizient sind, können die aktuellen Werte aller Schlüssel in der Zustandsdatenbank 724 gespeichert werden. Die Zustandsdatenbank 724 kann eine indizierte Ansicht des Transaktionsprotokolls der Blockchain 722 enthalten und kann daher jederzeit aus der Chain neu erzeugt werden. Die Zustandsdatenbank 724 kann automatisch wiederhergestellt (oder bei Bedarf erzeugt) werden, wenn der Peer-Knoten gestartet wird und bevor Transaktionen angenommen werden.
  • Bestätigende Knoten empfangen Transaktionen von Clients und bestätigen die Transaktion auf der Grundlage simulierter Ergebnisse. Bestätigende Knoten enthalten Smart Contracts, die die Transaktionsvorschläge simulieren. Wenn ein bestätigender Knoten eine Transaktion bestätigt, erzeugt der bestätigende Knoten eine Transaktionsbestätigung, bei der es sich um eine signierte Antwort des bestätigenden Knotens an die Client-Anwendung handelt, die die Bestätigung der simulierten Transaktion anzeigt. Das Verfahren zum Bestätigen einer Transaktion hängt von einer Endorsement Policy ab, die im Chaincode festgelegt werden kann. Ein Beispiel für eine Endorsement Policy ist „die Mehrheit der bestätigenden Peers muss die Transaktion bestätigen“. Verschiedene Kanäle können unterschiedliche Endorsement Policies aufweisen. Bestätigte Transaktionen werden von der Client-Anwendung an den Sortierdienst 710 weitergeleitet.
  • Der Sortierdienst 710 lässt bestätigte Transaktionen zu, ordnet sie in einem Block an und übermittelt die Blöcke an die festschreibenden Peers. Beispielsweise kann der Sortierdienst 710 einen neuen Block initiieren, wenn ein Schwellenwert an Transaktionen erreicht wurde, ein Zeitgeber abgelaufen ist oder eine andere Bedingung vorliegt. In dem Beispiel von 7A handelt es sich bei dem Blockchain-Knoten 712 um einen festschreibenden Peer, der einen neuen Datenblock 730 zum Speichern in der Blockchain 722 empfangen hat. Der erste Block in der Blockchain kann als Genesis-Block bezeichnet werden, der Informationen über die Blockchain, ihre Mitglieder, die darin gespeicherten Daten usw. enthält.
  • Der Sortierdienst 710 kann aus einer Gruppe von Sortierern zusammengesetzt sein. Der Sortierdienst 710 kann in einigen Ausführungsformen keine Transaktionen und Smart Contracts verarbeiten und führt auch nicht das gemeinsam genutzte Ledger. Vielmehr kann der Sortierdienst 710 in diesen Ausführungsformen die bestätigten Transaktionen zulassen und die Reihenfolge festlegen, in der diese Transaktionen im Distributed Ledger 720 festgeschrieben werden. Die Architektur des Blockchain-Netzwerks kann so ausgelegt werden, dass die spezifische Implementierung des „Sortierens“ (z.B. Solo, Kafka, BFT usw.) zu einer integrierbaren Komponente wird.
  • Transaktionen können in einigen Ausführungsformen in einer konsistenten Reihenfolge in das Distributed Ledger 720 geschrieben werden. Die Reihenfolge der Transaktionen kann in diesen Ausführungsformen festgelegt werden, um sicherzustellen, dass die Aktualisierungen der Zustandsdatenbank 724 gültig sind, wenn sie im Netzwerk festgeschrieben werden. Im Gegensatz zu einem Blockchain-System für Kryptowährungen (z.B. Bitcoin usw.), bei dem das Sortieren durch das Lösen eines kryptografischen Rätsels oder durch Mining erfolgt, können die Parteien des Distributed Ledger 720 in diesem Beispiel den Sortiermechanismus wählen, der am besten zu diesem Netzwerk passt.
  • Wenn der Sortierdienst 710 in einigen Ausführungsformen einen neuen Datenblock 730 initialisiert, kann der neue Datenblock 730 an die festschreibenden Peers (z.B. die Blockchain-Knoten 711, 712 und 713) übertragen werden. Daraufhin kann jeder festschreibende Peer die Transaktion im neuen Datenblock 730 validieren, indem er sicherstellt, dass der Lese- und der Schreibsatz immer noch mit dem aktuellen World State in der Zustandsdatenbank 724 übereinstimmen. Konkret heißt dies, dass der festschreibende Peer ermitteln kann, ob die gelesenen Daten, die vorhanden waren, als die Endorser die Transaktion simulierten, mit dem aktuellen World State in der Zustandsdatenbank 724 identisch sind. Wenn der festschreibende Peer die Transaktion validiert, kann die Transaktion in die Blockchain 722 im Distributed Ledger 720 geschrieben werden, und die Zustandsdatenbank 724 kann mit den Schreibdaten aus dem Lese-/Schreibsatz aktualisiert werden. Wenn eine Transaktion in einigen Ausführungsformen nicht erfolgreich ist (z.B. wenn der festschreibende Peer feststellt, dass der Lese-/Schreibsatz nicht mit dem aktuellen World State in der Zustandsdatenbank 724 übereinstimmt), kann die in einem Block zusammengefasste Transaktion zwar immer noch in diesem Block enthalten sein, aber sie ist als ungültig gekennzeichnet, und die Zustandsdatenbank 724 wird nicht aktualisiert.
  • Mit Bezug auf 7B kann in einigen Ausführungsformen ein neuer Datenblock 730 (auch als Datenblock bezeichnet), der in der Blockchain 722 des Distributed Ledger 720 gespeichert wird, mehrere Datensegmente enthalten, z.B. einen Blockkopf 740, Blockdaten 750 und Block-Metadaten 760. Es sei darauf hingewiesen, dass die verschiedenen dargestellten Blöcke und ihr Inhalt, z.B. der neue Datenblock 730 und sein Inhalt, die in 7B gezeigt werden, lediglich Beispiele sind und den Anwendungsbereich der beispielhaften Ausführungsformen nicht einschränken sollen. Der neue Datenblock 730 kann Transaktionsinformationen von N Transaktionen (z.B. 1, 10, 100, 200, 1000, 2000, 3000 usw.) in den Blockdaten 750 speichern. Der neue Datenblock 730 kann auch eine Verknüpfung zu einem früheren Block (z.B. in der Blockchain 722 in 7A) im Blockkopf 740 enthalten. Der Blockkopf 740 kann insbesondere einen Hash des Kopfes eines früheren Blocks enthalten. Der Blockkopf 740 kann auch eine eindeutige Blocknummer, einen Hash der Blockdaten 750 des neuen Datenblocks 730 und Ähnliches umfassen. Die Blocknummer des neuen Datenblocks 730 kann eindeutig sein und in verschiedenen Reihenfolgen zugewiesen werden, z.B. in einer inkrementellen/sequenziellen Reihenfolge, die bei null beginnt.
  • In den Blockdaten 750 können Transaktionsinformationen jeder Transaktion gespeichert werden, die im neuen Datenblock 730 aufgezeichnet werden. Die Transaktionsdaten können zum Beispiel: eine Art der Transaktion, eine Version, einen Zeitstempel, eine Kanal-ID des Distributed Ledger 720, eine Transaktions-ID, eine Epoche, die Sichtbarkeit von Nutzdaten, einen Chaincode-Pfad (deploy tx), einen Chaincode-Namen, eine Chaincode-Version, eine Eingabe (Chaincode und Funktionen), eine Client-ID (Erzeuger-ID) wie einen öffentlichen Schlüssel und ein Zertifikat, eine Signatur des Clients, die Identitäten von Endorsers, Endorser-Signaturen, einen Vorschlags-Hash, Chaincode-Ereignisse, einen Antwortstatus, einen Namensbereich, einen Lesesatz (Liste der von der Transaktion gelesenen Schlüssel und Versionen usw.), einen Schreibsatz (Liste der Schlüssel und Werte usw.), einen Anfangsschlüssel, einen Endschlüssel, eine Schlüsselliste, eine Zusammenfassung der Merkel-Baum-Abfrage und/oder Ähnliches enthalten. Die Transaktionsdaten können für jede der N Transaktionen gespeichert werden.
  • In einigen Ausführungsformen können in den Blockdaten 750 auch neue Daten 762 gespeichert werden, wodurch der hash-verknüpften Kette von Blöcken in der Blockchain 722 zusätzliche Informationen hinzugefügt werden. Die zusätzlichen Informationen können einen oder mehrere der hier beschriebenen oder dargestellten Schritte, Merkmale, Prozesse und/oder Maßnahmen umfassen. Entsprechend können die neuen Daten 762 in einem unveränderlichen Protokoll von Blöcken im Distributed Ledger 720 gespeichert werden. Einige der Vorteile des Speicherns dieser neuen Daten 762 werden in den verschiedenen hier offenbarten und dargestellten Ausführungsformen deutlich. In 7B sind die neuen Daten 762 zwar in den Blockdaten 750 dargestellt, sie könnten sich in einigen Ausführungsformen aber auch im Blockkopf 740 oder in den Block-Metadaten 760 befinden. Die neuen Daten 762 können auch einen Dokumentverbundschlüssel enthalten, der für ein Verknüpfen der Dokumente in einer Organisation verwendet wird.
  • In den Block-Metadaten 760 können mehrere Felder mit Metadaten gespeichert werden (z.B. als Byte-Anordnung usw.). Die Metadatenfelder können eine Signatur beim Erzeugen eines Blocks, einen Verweis auf einen letzten Konfigurationsblock, ein Transaktionsfilter, das gültige und ungültige Transaktionen im Block identifiziert, den letzten verbliebenen Offset eines Sortierdienstes, der den Block sortiert hat, und Ähnliches umfassen. Die Signatur, der letzte Konfigurationsblock und die Metadaten des Sortierers können vom Sortierdienst 710 hinzugefügt werden. In der Zwischenzeit kann ein Festschreibender (Committer) des Blocks (z.B. der Blockchain-Knoten 712) auf der Grundlage einer Endorsement Policy, der Überprüfung von Lese-/Schreibsätzen usw. Angaben zur Gültigkeit/Ungültigkeit hinzufügen. Das Transaktionsfilter kann eine Byte-Anordnung mit einer Größe umfassen, die der Anzahl von Transaktionen in den Blockdaten 750 entspricht, sowie einen Validierungscode, der kennzeichnet, ob eine Transaktion gültig oder ungültig war.
  • 7C veranschaulicht gemäß einigen Ausführungsformen eine Ausführungsform einer Blockchain 770 für digitalen Inhalt. Der digitale Inhalt kann eine oder mehrere Dateien und zugehörige Informationen enthalten. Die Dateien können Transaktionsdaten, Medien, Bilder, Video, Audio, Text, Links, Grafiken, Animationen, Webseiten, Dokumente oder andere Formen mit digitalem Inhalt umfassen. Die unveränderlichen Append-only-Aspekte einiger Ausführungsformen der Blockchain können wünschenswert sein, um als Schutz für die Integrität, Gültigkeit und Echtheit des digitalen Inhalts zu dienen, sodass sie sich für Gerichtsverfahren eignen, in denen Zulässigkeitsregeln angewandt werden, oder für andere Situationen, in denen Beweise in Betracht gezogen werden oder in denen die Darstellung und Verwendung digitaler Informationen anderweitig von Interesse sind. In diesem Fall kann der digitale Inhalt als digitaler Nachweis bezeichnet werden.
  • Die Blockchain kann in diesen Ausführungsformen auf verschiedene Weise gebildet werden. In einer Ausführungsform kann der digitale Inhalt in der Blockchain enthalten sein, und die Blockchain selbst kann darauf zugreifen. Beispielsweise kann jeder Block der Blockchain einen Hash-Wert von Verweisinformationen (z.B. Kopf, Wert usw.) zusammen mit dem zugehörigen digitalen Inhalt speichern. Der Hash-Wert und der zugehörige digitale Inhalt können dann gemeinsam verschlüsselt werden. Auf den digitalen Inhalt jedes Blocks kann somit zugegriffen werden, indem jeder Block in der Blockchain entschlüsselt wird, und der Hash-Wert jedes Blocks kann als Grundlage für einen Verweis auf einen vorherigen Block verwendet werden. Dies lässt sich wie folgt darstellen:
    Block 1 Block 2.. ............. Block N
    Hash-Wert 1 Hash-Wert 2 Hash-Wert N
    Digitaler Inhalt 1 Digitaler Inhalt 2 Digitaler Inhalt N
  • In einer Ausführungsform kann der digitale Inhalt nicht in der Blockchain enthalten sein. So kann die Blockchain beispielsweise die verschlüsselten Hashes des Inhalts jedes Blocks ohne den digitalen Inhalt speichern. Der digitale Inhalt kann in Verbindung mit dem Hash-Wert der Originaldatei in einem anderen Speicherbereich oder an einer anderen Speicheradresse gespeichert werden. Bei dem anderen Speicherbereich kann es sich um dieselbe Speichereinheit handeln, die auch zum Speichern der Blockchain verwendet wird, oder um einen anderen Speicherbereich oder auch um eine gesonderte relationale Datenbank. Auf den digitalen Inhalt jedes Blocks kann durch Abrufen oder Abfragen des Hash-Werts eines relevanten Blocks und anschließendes Suchen dieses Hash-Werts im Speicherbereich, der in Übereinstimmung mit den tatsächlichen digitalen Inhalt gespeichert ist, verwiesen oder zugegriffen werden. Diese Operation kann z.B. von einem Datenbank-Gatekeeper durchgeführt werden. Dies lässt sich wie folgt darstellen:
    Blockchain Speicherbereich
    Block 1 Hash-Wert Block 1 Hash-Wert ... Inhalt
    Block N Hash-Wert Block N Hash-Wert ... Inhalt
  • In der beispielhaften Ausführungsform von 7C umfasst die Blockchain 770 eine Anzahl von Blöcken 7781, 7782, ... 778N, die in einer geordneten Folge kryptografisch verknüpft sind, wobei N ≥ 1 ist. Bei der Verschlüsselung, die verwendet wird, um die Blöcke 7781, 7782, ... 778N zu verknüpfen, kann es sich um eine beliebige Anzahl von verschlüsselten oder unverschlüsselten Hash-Funktionen handeln. In einer Ausführungsform werden die Blöcke 7781, 7782, ... 778N einer Hash-Funktion unterzogen, die aus Eingaben, die auf den Informationen in den Blöcken beruhen, n-bit alphanumerische Ausgaben erzeugt (wobei n 256 oder eine andere Zahl ist). Zu Beispielen für eine solche Hash-Funktion gehören, ohne auf diese beschränkt zu sein: ein Algorithmus vom Typ SHA (SHA steht für Secured Hash Algorithm, sicherer Hash-Algorithmus), ein Merkle-Damgard-Algorithmus, ein HAIFA-Algorithmus, ein Merkle-Baum-Algorithmus, ein Nonce-gestützter Algorithmus und ein nichtkollisionsresistenter PRF-Algorithmus. In einer anderen Ausführungsform können die Blöcke 7781, 7782, ..., 778N durch eine andere Funktion als eine Hash-Funktion kryptografisch verknüpft werden. Zur Veranschaulichung folgt eine Beschreibung mit Verweis auf eine Hash-Funktion, z.B. SHA-2.
  • Jeder der Blöcke 7781, 7782, ..., 778N in der Blockchain kann einen Kopf, eine Version der Datei und einen Wert umfassen. Der Kopf und der Wert können für jeden Block unterschiedlich sein, was auf das Hashing in der Blockchain zurückzuführen ist. In einer Ausführungsform kann der Wert im Kopf enthalten sein. Wie im Folgenden ausführlicher beschrieben, kann die Version der Datei die Originaldatei oder eine andere Version der Originaldatei sein.
  • Der erste Block 7781 in der Blockchain wird als Genesis-Block bezeichnet und kann den Kopf 7721, die Originaldatei 7741 und einen Anfangswert 7761 umfassen. Das Hashing-Schema, das für den Genesis-Block und auch für alle folgenden Blöcke verwendet wird, kann unterschiedlich sein. Zum Beispiel können alle Informationen im ersten Block 7781 zusammen und auf einmal gehasht werden, oder jede Information oder ein Teil der Informationen im ersten Block 7781 kann separat gehasht werden, und dann kann ein Hash der separat gehashten Teile durchgeführt werden.
  • Der Kopf 7721 kann einen oder mehrere Anfangsparameter umfassen, die beispielsweise eine Versionsnummer, einen Zeitstempel, eine Nonce, Stamminformationen, einen Schwierigkeitsgrad, ein Konsensprotokoll, eine Dauer, ein Medienformat, eine Quelle, beschreibende Schlüsselwörter und/oder andere Informationen umfassen können, die der Originaldatei 7741 und/oder der Blockchain zugehörig sind. Der Kopf 7721 kann automatisch (z.B. durch eine Software zur Blockchain-Netzwerkverwaltung) oder manuell durch einen Blockchain-Teilnehmer erzeugt werden. Im Gegensatz zum Kopf in den anderen Blöcken 7782 bis 778N in der Blockchain kann der Kopf 7721 im Genesis-Block nicht auf einen vorherigen Block verweisen, da es keinen vorherigen Block gibt.
  • Bei der Originaldatei 7741 im Genesis-Block kann es sich beispielsweise um Daten handeln, die von einer Einheit mit oder ohne Verarbeitung vor ihrer Aufnahme in die Blockchain erfasst wurden. Die Originaldatei 7741 kann über die Schnittstelle des Systems von der Einheit, der Medienquelle oder dem Knoten empfangen werden. Der Originaldatei 7741 können Metadaten zugehörig sein, die z.B. von einem Benutzer, der Einheit und/oder dem Systemprozessor entweder manuell oder automatisch erzeugt werden können. Die Metadaten können im ersten Block 7781 enthalten sein, der der Originaldatei 7741 zugehörig ist.
  • Der Wert 7761 im Genesis-Block kann ein Anfangswert sein, der auf der Grundlage eines oder mehrerer eindeutiger Attribute der Originaldatei 7741 erzeugt wird. In einer Ausführungsform können das eine oder die mehreren eindeutigen Attribute den Hash-Wert für die Originaldatei 7741, Metadaten für die Originaldatei 7741 und andere der Datei zugehörige Informationen umfassen. In einer Implementierung kann der Anfangswert 7761 auf den folgenden eindeutigen Attributen beruhen:
    • 1) SHA-2 berechneter Hash-Wert für die Originaldatei
    • 2) ID der ursprünglichen Einheit
    • 3) Anfangszeitstempel für die Originaldatei
    • 4) Anfänglicher Speicherort der Originaldatei
    • 5) Blockchain-Netzwerk-Mitglieder-ID für Software zur aktuellen Kontrolle der Originaldatei und der zugehörigen Metadaten
  • Die anderen Blöcke 7782 bis 778N in der Blockchain verfügen ebenfalls über Köpfe, Dateien und Werte. Im Gegensatz zum Kopf 7721 des ersten Blocks umfasst jedoch jeder der Köpfe 7722 bis 772N in den anderen Blöcken den Hash-Wert eines unmittelbar vorhergehenden Blocks. Der Hash-Wert des unmittelbar vorhergehenden Blocks kann lediglich der Hash des Kopfes des vorherigen Blocks oder der Hash-Wert des gesamten vorherigen Blocks sein. Indem der Hash-Wert eines vorhergehenden Blocks in jeden der verbleibenden Blöcke integriert wird, kann eine Rückverfolgung vom N-ten Block zurück zum Genesis-Block (und der zugehörigen Originaldatei) Block für Block durchgeführt werden, wie durch die Pfeile 780 angezeigt, um eine überprüfbare und unveränderliche Chain-of-Custody herzustellen.
  • Jeder der Köpfe 7722 bis 772N in den anderen Blöcken kann auch andere Informationen enthalten, z.B. Versionsnummer, Zeitstempel, Nonce, Stamminformationen, Schwierigkeitsgrad, Konsensprotokoll und/oder andere Parameter oder Informationen, die den entsprechenden Dateien und/oder der Blockchain im Allgemeinen zugehörig sind.
  • Die Dateien 7742 bis 774N in den anderen Blöcken können der Originaldatei entsprechen, oder es kann sich um eine geänderte Version der Originaldatei im Genesis-Block handeln, beispielsweise je nach Art der durchgeführten Verarbeitung. Die Art der durchgeführten Verarbeitung kann sich von Block zu Block unterscheiden. Das Verarbeiten kann z.B. jede Änderung einer Datei in einem vorhergehenden Block umfassen, unter anderem Redigieren von Informationen oder sonstiges Ändern des Inhalts, Entfernen von Informationen oder Hinzufügen oder Anhängen von Informationen in den Dateien.
  • Zusätzlich oder alternativ kann das Verarbeiten lediglich ein Kopieren der Datei aus einem vorhergehenden Block, Ändern eines Speicherortes der Datei, Analysieren der Datei aus einem oder mehreren vorhergehenden Blöcken, Verlagern der Datei von einem Speicherort zu einem anderen oder Durchführen von Maßnahmen in Bezug auf die Datei der Blockchain und/oder ihrer zugehörigen Metadaten umfassen. Ein Verarbeiten, das Analysieren einer Datei umfasst, kann zum Beispiel Anhängen, Einbeziehen oder anderweitiges Zuordnen verschiedener analytischer, statistischer oder anderer Informationen umfassen, die der Datei zugehörig sind.
  • Die Werte in jedem der anderen Blöcke 7762 bis 776N sind eindeutige Werte, und aufgrund der durchgeführten Verarbeitung unterscheiden sie sich alle. So entspricht beispielsweise der Wert in einem beliebigen Block einer aktualisierten Version des Wertes im vorherigen Block. Die Aktualisierung spiegelt sich im Hash des Blocks wider, dem der Wert zugewiesen ist. Die Werte der Blöcke stellen somit einen Hinweis darauf bereit, welche Verarbeitung in den Blöcken durchgeführt wurde, und ermöglichen auch eine Rückverfolgung durch die Blockchain bis zur Originaldatei. Dieses Verfolgen bestätigt die Chain-of-Custody der Datei über die gesamte Blockchain.
  • Nehmen wir zum Beispiel den Fall, dass Teile der Datei in einem vorherigen Block redigiert, ausgeblendet oder verpixelt werden, um die Identität einer in der Datei gezeigten Person zu schützen. In diesem Fall umfasst der Block mit der redigierten Datei zugehörige Metadaten, z.B. wie das Redigieren durchgeführt wurde, wer das Redigieren durchgeführt hat, Zeitstempel, die angeben, wann die Redigierung(en) vorgenommen wurde(n), usw. Die Metadaten können gehasht werden, um den Wert zu bilden. Da sich die Metadaten des Blocks von den Informationen unterscheiden, die zum Bilden des Wertes im vorherigen Block gehasht wurden, unterscheiden sich die Werte voneinander und können beim Entschlüsseln wiederhergestellt werden.
  • In einer Ausführungsform kann der Wert eines vorherigen Blocks aktualisiert werden (z.B. kann ein neuer Hash-Wert berechnet werden), um den Wert eines aktuellen Blocks zu bilden, wenn einer oder mehrere der folgenden Fälle eintreten. In dieser beispielhaften Ausführungsform kann der neue Hash-Wert durch Hashing aller oder eines Teils der unten aufgeführten Informationen berechnet werden.
    1. a) Neuer SHA-2 berechneter Hash-Wert, wenn die Datei in irgendeiner Weise verarbeitet wurde (z.B. wenn die Datei redigiert, kopiert, geändert oder auf sie zugegriffen wurde oder eine andere Maßnahme durchgeführt wurde)
    2. b) Neuer Speicherort für die Datei
    3. c) Neue Metadaten identifiziert, die der Datei zugehörig sind
    4. d) Übertragung des Zugriffs auf oder der Kontrolle über die Datei von einem Blockchain-Teilnehmer auf einen anderen Blockchain-Teilnehmer
  • 7D veranschaulicht gemäß einigen Ausführungsformen eine Ausführungsform eines Blocks, die die Struktur der Blöcke in der Blockchain 790 darstellen kann. Der Block, Blocki, kann einen Kopf 772i, eine Datei 774i und einen Wert 776i umfassen.
  • Der Kopf 772i kann einen Hash-Wert eines vorherigen Blocks, Blocki-1, und zusätzliche Verweisinformationen umfassen, bei denen es sich z.B. um beliebige hier beschriebene Arten von Informationen (z.B. Kopf-Informationen mit Verweisen, Merkmalen, Parametern usw.) handeln kann. In einigen Ausführungsformen können alle Blöcke auf den Hash eines vorherigen Blocks verweisen, mit Ausnahme des Genesis-Blocks in einigen Ausführungsformen. Der Hash-Wert des vorherigen Blocks kann nur ein Hash des Kopfes im vorherigen Block sein oder ein Hash aller oder eines Teils der Informationen im vorherigen Block, einschließlich der Datei und der Metadaten.
  • Die Datei 774i kann eine Mehrzahl von Daten, z.B. Daten 1, Daten 2, ..., Daten N in Folge umfassen. Die Daten sind mit den Metadaten 1, Metadaten 2, ..., Metadaten N versehen, die den Inhalt und/oder die den Daten zugehörigen Merkmale beschreiben. Die Metadaten für die einzelnen Daten können beispielsweise Informationen zur Angabe eines Zeitstempels für die Daten, zur Verarbeitung der Daten, Schlüsselwörter zur Angabe der in den Daten abgebildeten Personen oder anderer Inhalte und/oder andere Merkmale umfassen, die hilfreich sein können, um die Gültigkeit und den Inhalt der Datei insgesamt und insbesondere ihre Verwendung als digitalen Nachweis festzustellen, wie beispielsweise im Zusammenhang mit einer unten erörterten Ausführungsform beschrieben. Zusätzlich zu den Metadaten können alle Daten mit einem Verweis REF1, REF2, ..., REFN auf frühere Daten versehen werden, um Manipulationen, Lücken in der Datei und sequenzielle Verweise in der Datei zu vermeiden.
  • Sobald die Metadaten den Daten zugewiesen sind (z.B. durch einen Smart Contract), können die Metadaten in einigen Ausführungsformen nicht mehr geändert werden, ohne dass sich der Hash ändert, der zum Ungültigmachen leicht identifiziert werden kann. Die Metadaten erzeugen in diesen Ausführungsformen somit ein Datenprotokoll mit Informationen, auf die Teilnehmer der Blockchain zur Verwendung zugreifen können.
  • Der Wert 776i kann in einigen Ausführungsformen ein Hash-Wert oder ein anderer Wert sein, der auf der Grundlage einer der zuvor beschriebenen Arten von Informationen berechnet wird. Beispielsweise kann für jeden gegebenen Block Blocki der Wert für diesen Block aktualisiert werden, um das für diesen Block durchgeführte Verarbeiten widerzuspiegeln, z.B. neuer Hash-Wert, neuer Speicherort, neue Metadaten für die zugehörige Datei, Übertragen der Kontrolle oder des Zugriffs, Kennung oder andere hinzuzufügende Maßnahme oder Informationen. Zwar ist der Wert in jedem Block getrennt von den Metadaten für die Daten der Datei und des Kopfes dargestellt, doch kann der Wert in einer anderen Ausführungsform ganz oder teilweise auf diesen Metadaten beruhen.
  • Sobald die Blockchain 770 gebildet ist, kann die unveränderliche Chain-of-Custody in einigen Ausführungsformen zu jedem beliebigen Zeitpunkt für die Datei abgerufen werden, indem die Blockchain nach der Transaktionshistorie der Werte in den Blöcken abgefragt wird. Diese Abfrage- oder Verfolgungsprozedur kann mit einem Entschlüsseln des Wertes des Blocks beginnen, der am aktuellsten erfasst ist (z.B. der letzte (N-te) Block), und dann mit dem Entschlüsseln des Wertes der anderen Blöcke fortfahren, bis der Genesis-Block erreicht und die Originaldatei wiederhergestellt ist. Das Entschlüsseln kann auch Entschlüsseln der Köpfe und Dateien und zugehöriger Metadaten in jedem Block umfassen.
  • Das Entschlüsseln kann auf der Grundlage der Art des Verschlüsselns, die in jedem Block verwendet wurde, durchgeführt werden. Dies kann Verwenden von privaten Schlüsseln, öffentlichen Schlüsseln oder von Paaren aus öffentlichen und privaten Schlüsseln umfassen. Bei der asymmetrischen Verschlüsselung können Blockchain-Teilnehmer oder ein Prozessor im Netzwerk beispielsweise ein Paar aus öffentlichem und privatem Schlüssel mithilfe eines vorgegebenen Algorithmus erzeugen. Der öffentliche und der private Schlüssel können durch eine mathematische Beziehung miteinander verbunden sein. Der öffentliche Schlüssel kann öffentlich verteilt werden und als Adresse dienen, um Nachrichten von anderen Benutzern zu empfangen, z.B. eine IP-Adresse oder eine Privatadresse. Der private Schlüssel kann geheim gehalten und zum digitalen Signieren von Nachrichten verwendet werden, die an andere Blockchain-Teilnehmer gesendet werden. Die Signatur kann ihrerseits in der Nachricht enthalten sein, damit der Empfänger sie mit dem öffentlichen Schlüssel des Senders überprüfen kann. Auf diese Weise kann der Empfänger sicher sein, dass nur der Sender diese Nachricht gesendet haben kann.
  • In einigen Ausführungsformen kann das Erzeugen eines Schlüsselpaares vergleichbar mit dem Erzeugen eines Kontos in der Blockchain sein, ohne dass man sich jedoch irgendwo registrieren muss. In diesen Ausführungsformen kann jede Transaktion, die in der Blockchain ausgeführt wird, vom Sender mit seinem privaten Schlüssel digital signiert werden. Diese Signatur kann dazu beitragen, sicherzustellen, dass nur der Inhaber des Kontos die Datei der Blockchain verfolgen und bearbeiten kann (sofern dies im Rahmen einer durch einen Smart Contract festgelegten Genehmigung liegt).
  • Computerprogrammprodukt
  • Die vorliegende Erfindung wurde zwar anhand bestimmter Beispiele ausführlich beschrieben, sie kann jedoch auch in anderen spezifischen Formen ausgeführt werden, ohne vom wesentlichen Grundgedanken oder den Attributen abzuweichen. Bei der vorliegenden Erfindung kann es sich beispielsweise um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jedem möglichen technischen Detaillierungsgrad der Integration handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) umfassen, auf dem/denen durch einen Computer lesbare Programmanweisungen gespeichert ist/sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen. Die durch einen Computer lesbaren Programmanweisungen können auf einem einzelnen Computer gespeichert und ausgeführt werden oder auf verschiedene Computer am selben Ort oder an verschiedenen Orten zum Speichern und Ausführen aufgeteilt werden.
  • Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch eine Einheit zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder gehobene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hier nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
  • Hier beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Router, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
  • Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für integrierte Schaltungen oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Kunden, teilweise auf dem Computer des Kunden, als eigenständiges Software-Paket, teilweise auf dem Computer des Kunden und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Kunden durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
  • Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, sodass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, einen Herstellungsartikel aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaubilder angegebenen Funktion/Schritts umsetzen.
  • Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, sodass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
  • Allgemeines
  • Die Ablaufpläne und die Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit als ein Schritt ausgeführt, gleichzeitig ausgeführt, im Wesentlich gleichzeitig ausgeführt, ganz oder teilweise zeitlich überlappend ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
  • Aspekte der vorliegenden Erfindung wurden hier unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können. Die Ablaufpläne und die Blockschaubilder in den Figuren veranschaulichen darüber hinaus die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
  • Eine in dieser Beschreibung verwendete bestimmte Programmnomenklatur wurde nur aus Gründen der Zweckmäßigkeit verwendet, daher sollte die Erfindung nicht darauf beschränkt sein, nur in einer bestimmten Anwendung verwendet zu werden, die durch diese Nomenklatur bezeichnet und/oder impliziert wird. Die Routinen, die zum Implementieren der Ausführungsformen der Erfindung ausgeführt werden, unabhängig davon, ob sie als Teil eines Betriebssystems oder einer spezifischen Anwendung, Komponente, eines Programms, Moduls, Objekts oder einer Anweisungssequenz implementiert sind, könnten beispielsweise als „Programm“, „Anweisung“, „Server“ oder andere sinnvolle Nomenklatur bezeichnet werden. In derTat können auch andere Hardware- und/oder Software-Umgebungen verwendet werden, ohne vom Anwendungsbereich der Erfindung abzuweichen.
  • Daher ist es wünschenswert, dass die hier beschriebenen Ausführungsformen in jeder Hinsicht als veranschaulichend und nichteinschränkend betrachtet werden und dass zum Festlegen des Anwendungsbereichs der Erfindung auf die beigefügten Ansprüche Bezug genommen wird.

Claims (20)

  1. Verfahren zum Orchestrieren eines Zugriffsverwaltungsprozesses, das aufweist: Empfangen einer Anforderung zum Zugreifen auf eine verwaltete Ressource eines Informationssystems; Abfragen einer Berechtigung zum Zugreifen auf die Ressource von einem Zugriffsmanager; und als Reaktion auf das Abfragen der Berechtigung Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie, um Zugriff auf die verwaltete Ressource zu gewähren; wobei das Empfangen der Anforderung, das Abrufen der Berechtigung und das Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie aufweisen: Erzeugen eines Transaktionsdatensatzes; und Hinzufügen des Transaktionsdatensatzes zu einem Distributed Ledger, wobei das Distributed Ledger den Transaktionsdatensatz gleichzeitig an mehreren Knoten in einem Netzwerk verwaltet.
  2. Verfahren nach Anspruch 1, wobei das Verfahren weiterhin Austauschen des Transaktionsdatensatzes zwischen den mehreren Knoten des Distributed Ledger aufweist.
  3. Verfahren nach einem der vorherigen Ansprüche, wobei die mehreren Knoten über kryptografische gesicherte Kanäle miteinander verbunden sind.
  4. Verfahren nach einem der vorherigen Ansprüche, wobei der Transaktionsdatensatz mindestens eine Verwaltungsmaßnahme aufweist, die aus der Gruppe ausgewählt wird, die aus einer Maßnahme „Zugriff anfordern“, einer Maßnahme „Zugriff genehmigt“, einer Maßnahme „Zugriff abgelehnt“, einer Maßnahme „Zugriff gewährt“, einer Maßnahme „Zugriff zurücknehmen“ und einer Maßnahme „Zugriff zurückgenommen“ besteht.
  5. Verfahren nach Anspruch 4, wobei die der Maßnahme „Zugriff gewährt“ zugehörige Verwaltungsmaßnahme eine Berechtigungsrichtlinie ändert, um einem Benutzer Zugriff auf das Informationssystem zu ermöglichen.
  6. Verfahren nach einem der Ansprüche 4 und 5, wobei die der Maßnahme „Zugriff zurücknehmen“ zugehörige Verwaltungsmaßnahme eine Berechtigungsrichtlinie ändert, um einem Benutzer den Zugriff auf das Informationssystem zu verweigern.
  7. Verfahren nach einem der Ansprüche 4 bis 6, das weiterhin aufweist: Übermitteln des Transaktionsdatensatzes an das Informationssystem; und automatisches Ausführen der Verwaltungsmaßnahme im Informationssystem.
  8. Verfahren nach einem der vorherigen Ansprüche, wobei das Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie Ausführen eines Smart Contract aufweist, der Transaktionen im Distributed Ledger verarbeitet.
  9. Verfahren nach einem der vorherigen Ansprüche, wobei: die verwaltete Ressource des Informationssystems eine von einer Mehrzahl von verwalteten Ressourcen einer Mehrzahl von Informationssystemen ist; jede der Mehrzahl von Informationssystemen ein lokales Zugriffssteuerungssystem umfasst; und das Verfahren weiterhin Aufrufen eines der lokalen Zugriffssteuerungssysteme aufweist, um eine Änderung an einer lokalen Berechtigungsrichtlinie anzufordern.
  10. Verfahren nach einem der vorherigen Ansprüche, das weiterhin aufweist: Übermitteln der empfangenen Anforderung an einen Eigner des Informationssystems; Empfangen einer Genehmigung als Reaktion auf die Anforderung vom Eigner des Informationssystems; Aufzeichnen der Genehmigung im Distributed Ledger; Übermitteln der Anforderung an einen Administrator des Informationssystems; Ausführen einer Maßnahme als Reaktion auf die Anforderung im Informationssystem; und Aufzeichnen der Maßnahme im Distributed Ledger.
  11. Governance-Orchestrator für die Zugriffsverwaltung, der aufweist: einen Peer-Knoten, der einem Blockchain-Netzwerk zugehörig ist, wobei das Blockchain-Netzwerk eine Mehrzahl von Knoten aufweist, die einer Asset-Eignerfunktion, einer Administratorfunktion und/oder einer Prüffunktion zugehörig sind, wobei der Peer-Knoten so ausgelegt ist, dass er: einen „Zugriff anfordern“-Datensatz von einem Benutzer eines Informationssystems in einem Distributed Ledger aufzeichnet; einen Eignergenehmigungsdatensatz von der Asset-Eignerfunktion aufzeichnet, wobei der Eignergenehmigungsdatensatz auf den „Zugriff anfordern“-Datensatz im Distributed Ledger reagiert; einen Smart Contract als Reaktion auf den „Zugriff anfordern“-Datensatz und den Eignergenehmigungsdatensatz, der Zugriff im Informationssystem gewährt, ausführt, wobei der Smart Contract eine Berechtigungsrichtlinie ändert, um dem Benutzer Zugriff auf das Informationssystem zu ermöglichen; und einen Aufzeichnungsdatensatz des Smart Contract im Distributed Ledger aufzeichnet.
  12. Governance-Orchestrator für die Zugriffsverwaltung nach Anspruch 11, wobei der Peer-Knoten weiterhin so ausgelegt ist, dass er: den „Zugriff anfordern“-Datensatz, den Eignergenehmigungsdatensatz und/oder den Ausführungsdatensatz in einem Transaktionsblock speichert; einen aus der Mehrzahl von Knoten als einen Signaturknoten auswählt, um den Transaktionsblock gemäß einem Konsensprotokoll zu signieren; und den Transaktionsblock von dem ausgewählten Signaturknoten signiert.
  13. Governance-Orchestrator für die Zugriffsverwaltung nach einem der Ansprüche 11 und 12, wobei der Peer-Knoten weiterhin so ausgelegt ist, dass er: eine neue Peer-Anforderung empfängt, um dem Blockchain-Netzwerk einen neuen Knoten hinzuzufügen; und die neue Peer-Anforderung an die Mehrzahl von Knoten im Blockchain-Netzwerk zur Genehmigung gemäß einem Konsensprotokoll übermittelt.
  14. Governance-Orchestrator für die Zugriffsverwaltung nach einem der Ansprüche 11 bis 13, wobei das Ändern der Berechtigungsrichtlinie Aufrufen eines lokalen Zugriffssteuerungssystems aufweist, das dem Informationssystem zugehörig ist, um eine Änderung einer lokalen Berechtigungsrichtlinie anzufordern.
  15. Governance-Orchestrator für die Zugriffsverwaltung nach einem der Ansprüche 11 bis 14, wobei der Peer-Knoten weiterhin so ausgelegt ist, dass er das Distributed Ledger auf Ausführungsdatensätze überprüft, die nicht Eignergenehmigungsdatensätzen zugehörig sind.
  16. Computerprogrammprodukt, das ein nichtflüchtiges, durch einen Computer lesbares Speichermedium mit einer Mehrzahl von darauf gespeicherten Anweisungen aufweist, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen: eine Anforderung zum Zugreifen auf eine verwaltete Ressource eines Informationssystems zu empfangen; eine Berechtigung zum Zugreifen auf die Ressource von einem Zugriffsmanager abzufragen; und als Reaktion auf das Abfragen der Berechtigung eine Aktualisierung der Zugriffssteuerungsrichtlinie anzufordern, um den Zugriff auf die verwaltete Ressource zu gewähren; wobei das Empfangen der Anforderung, das Abrufen der Berechtigung und das Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie aufweist: Erzeugen eines Transaktionsdatensatzes; und Hinzufügen des Transaktionsdatensatzes zu einem Distributed Ledger.
  17. Computerprogrammprodukt nach Anspruch 16, wobei der Transaktionsdatensatz mindestens eine Verwaltungsmaßnahme aufweist, die aus der Gruppe ausgewählt wird, die aus einer Maßnahme „Zugriff anfordern“, einer Maßnahme „Zugriff genehmigt“, einer Maßnahme „Zugriff abgelehnt“, einer Maßnahme „Zugriff gewährt“, einer Maßnahme „Zugriff zurücknehmen“ und einer Maßnahme „Zugriff zurückgenommen“ besteht.
  18. Computerprogrammprodukt nach einem der Ansprüche 16 und 17, wobei: die verwaltete Ressource des Informationssystems eine von einer Mehrzahl von verwalteten Ressourcen einer Mehrzahl von Informationssystemen ist; jedes der Informationssysteme ein lokales Zugriffssteuerungssystem umfasst; und weiterhin Anweisungen aufweist, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, eines der lokalen Zugriffssteuerungssysteme aufzurufen, um eine Änderung einer lokalen Berechtigungsrichtlinie anzufordern.
  19. Computerprogrammprodukt nach einem der Ansprüche 16 bis 18 , das weiterhin Programmanweisungen aufweist, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen: die empfangene Anforderung an einen Eigner des Informationssystems zu übermitteln; eine Genehmigung als Reaktion auf die Anforderung vom Eigner des Informationssystems zu empfangen; die Genehmigung im Distributed Ledger aufzuzeichnen; die Anforderung an einen Administrator des Informationssystems zu übermitteln; eine Maßnahme als Reaktion auf die Anforderung im Informationssystem auszuführen; und die Maßnahme im Distributed Ledger aufzuzeichnen.
  20. Computerprogramm nach einem der Ansprüche 16 bis 19, wobei das Anfordern einer Aktualisierung der Zugriffssteuerungsrichtlinie Ausführen eines Smart Contract aufweist, der Transaktionen im Distributed Ledger verarbeitet.
DE112021001413.7T 2020-05-05 2021-04-07 Verwaltung eines privilegierten zugriffs mit geringer vertrauenswürdigkeit Pending DE112021001413T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/866,929 US20210352077A1 (en) 2020-05-05 2020-05-05 Low trust privileged access management
US16/866,929 2020-05-05
PCT/IB2021/052873 WO2021224696A1 (en) 2020-05-05 2021-04-07 Low trust privileged access management

Publications (1)

Publication Number Publication Date
DE112021001413T5 true DE112021001413T5 (de) 2023-01-12

Family

ID=78413301

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021001413.7T Pending DE112021001413T5 (de) 2020-05-05 2021-04-07 Verwaltung eines privilegierten zugriffs mit geringer vertrauenswürdigkeit

Country Status (8)

Country Link
US (1) US20210352077A1 (de)
JP (1) JP2023524659A (de)
KR (1) KR20220160021A (de)
CN (1) CN115552441A (de)
AU (1) AU2021269192A1 (de)
DE (1) DE112021001413T5 (de)
GB (1) GB2610144A (de)
WO (1) WO2021224696A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11550307B2 (en) * 2020-08-26 2023-01-10 Accenture Global Solutions Limited Asset management, registry, and tracking on shared blockchain nodes
CN112347456B (zh) * 2020-10-28 2023-09-01 达闼机器人股份有限公司 程序验证方法和装置、平台和用户终端及在线服务***
US11675917B2 (en) * 2021-04-22 2023-06-13 Bank Of America Corporation Electronic system for dynamically permitting and restricting access to and modification of computer resources
US20220383305A1 (en) * 2021-05-28 2022-12-01 Civic Technologies, Inc. Methods and apparatus for validation of rules of a smart contract on a centralized or distributed digital ledger
WO2024016022A1 (en) * 2022-07-15 2024-01-18 Ramdass Vivek Anand Variable node box ("vnb")
WO2024096914A1 (en) * 2022-10-31 2024-05-10 Venkataraman Mohan Blockchain based document and data sharing
CN116860362B (zh) * 2023-07-05 2024-03-19 广州市玄武无线科技股份有限公司 一种应用于流程编排引擎的插件事务管理方法及装置

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2256934C (en) * 1998-12-23 2002-04-02 Hamid Bacha System for electronic repository of data enforcing access control on data retrieval
US10484343B1 (en) * 2017-10-03 2019-11-19 Cerebri AI Inc. Distributed logging for securing non-repudiable multi-party transactions
CN111699504A (zh) * 2017-10-23 2020-09-22 维恩知识产权有限公司 经由区块链交易平台进行ip所有权和ip注册的***和方法
US11093558B2 (en) * 2017-11-14 2021-08-17 International Business Machines Corporation Providing accountability of blockchain queries
US20190173854A1 (en) * 2017-11-22 2019-06-06 Michael Beck Decentralized information sharing network
US11243945B2 (en) * 2017-12-11 2022-02-08 International Business Machines Corporation Distributed database having blockchain attributes
CN108123936B (zh) * 2017-12-13 2021-04-13 北京科技大学 一种基于区块链技术的访问控制方法及***
CN110401618A (zh) * 2018-04-24 2019-11-01 ***通信集团广东有限公司 区块链数据访问控制的方法及装置
MX2021005659A (es) * 2018-11-13 2021-09-10 Banqu Inc Gestión de permisos para acceder a datos de usuario en una red de confianza de registro distribuido.
US11140201B2 (en) * 2019-02-19 2021-10-05 International Business Machines Corporation Security platform for multi-component system and services thereof
US11436368B2 (en) * 2019-04-04 2022-09-06 Accenture Global Solutions Limited Personal data management system
US11556923B2 (en) * 2019-05-24 2023-01-17 Visa International Service Association Blockchain enabled service request system
US11252166B2 (en) * 2019-07-31 2022-02-15 Advanced New Technologies Co., Ltd. Providing data authorization based on blockchain
US11496518B2 (en) * 2019-08-02 2022-11-08 Dell Products L.P. System and method for distributed network access control
US20210135857A1 (en) * 2019-11-05 2021-05-06 Verizon Patent And Licensing Inc. System and methods for distributed runtime logging and transaction control for multi-access edge computing services
US11611560B2 (en) * 2020-01-31 2023-03-21 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing consensus on read via a consensus on write smart contract trigger for a distributed ledger technology (DLT) platform

Also Published As

Publication number Publication date
AU2021269192A1 (en) 2022-11-03
GB202218057D0 (en) 2023-01-18
JP2023524659A (ja) 2023-06-13
US20210352077A1 (en) 2021-11-11
CN115552441A (zh) 2022-12-30
GB2610144A (en) 2023-02-22
KR20220160021A (ko) 2022-12-05
WO2021224696A1 (en) 2021-11-11

Similar Documents

Publication Publication Date Title
DE112021001413T5 (de) Verwaltung eines privilegierten zugriffs mit geringer vertrauenswürdigkeit
DE112020005289B4 (de) Teilweise sortierte blockchain
DE112020005075B4 (de) Effiziente schwellenwertspeicherung von datenobjekten
DE112021004344T5 (de) Konsensdienst für Blockchain-Netzwerke
DE102021123128A1 (de) Mittels blockchains realisiertes datenmigrationsprüfprotokoll
DE112017005040T5 (de) Betriebssystem und Verfahren auf Container-Grundlage
DE102019123253A1 (de) System und einrichtung für datenvertraulichkeit im distributed ledger
DE112021002797T5 (de) Datenschutzerhaltende architektur für genehmigungspflichtige blockchains
DE202016008801U1 (de) Systeme zur Verwaltung digitaler Identitäten
DE112021000608T5 (de) Schnellere ansichtsänderung für eine blockchain
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
DE112021000688T5 (de) Indexstruktur für blockchain-ledger
DE19960978A1 (de) System für ein elektronisches Datenarchiv mit Erzwingung einer Zugriffskontrolle beim Suchen und Abrufen von Daten
US11711286B2 (en) Compliance mechanisms in blockchain networks
DE112021001671T5 (de) Netzübergreifendes bereitstellen von identitäten
DE112021003971T5 (de) Nachhaltige token für eine lieferkette mit datenschutzerhaltendem protokoll
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
DE102016105062A1 (de) Nähengestützte Berechtigungsprüfung für einheitenübergreifend verteilte Daten
DE112022000906T5 (de) Trennen von blockchain-daten
DE102021129514A1 (de) Binden von post-quanten-zertifikaten
DE112021004008T5 (de) Validieren von verfolgten abschnitten von empfangenen sensordaten mithilfe von kryptographischer computerverarbeitung
DE112021005837T5 (de) Dezentrale sendeverschlüsselung und schlüsselerzeugungseinrichtung
DE102011077513A1 (de) Verfahren zur sicheren Verarbeitung von Daten
DE112021005862T5 (de) Selbstprüfende blockchain
DE112021006165T5 (de) Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf

Legal Events

Date Code Title Description
R012 Request for examination validly filed