DE112020003438T5

DE112020003438T5 - Datenintegrität und konsens mit blockchain

Info

Publication number: DE112020003438T5
Application number: DE112020003438.0T
Authority: DE
Inventors: Arun Murti; E. Brenner Adam; Mark D. Malamut; Joey C. Lei
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2019-07-18
Filing date: 2020-03-23
Publication date: 2022-04-14
Also published as: US20210019301A1; GB202117843D0; GB2599303B; WO2021011037A1; GB2599303A

Abstract

Ein beispielhaftes Verfahren umfasst das Empfangen eines vorgeschlagenen Eintrags für ein Hauptbuch von einer Entität, wobei das Hauptbuch von mehreren Usern gemeinsam genutzt wird und für diese zugänglich ist und eine Whitelist und eine Blacklist enthält, das Bestimmen oder Zuweisen eines Glaubwürdigkeits-Scores und eines Ratenbegrenzungswerts für die Entität, das Vergleichen des Glaubwürdigkeits-Scores und des Ratenbegrenzungswerts mit entsprechenden Schwellenwerten für den Glaubwürdigkeits-Score und den Ratenbegrenzungswert, das Bestimmen, dass der Glaubwürdigkeits-Score und der Ratenbegrenzungswert die entsprechenden Glaubwürdigkeits-Score- und Ratenbegrenzungswert-Schwellenwerte erfüllen oder überschreiten, und das Übermitteln des vorgeschlagenen Eintrags an das Hauptbuch.

Description

BEREICH DER ERFINDUNG
Ausführungsformen der vorliegenden Erfindung betreffen im Allgemeinen den Schutz von Daten. Insbesondere betreffen zumindest einige Ausführungsformen der Erfindung Systeme, Hardware, Software, computerlesbare Medien und Verfahren zur Erleichterung der Datenintegrität durch Userkonsens in Bezug auf Whitelisting und Blacklisting von Dateien.
HINTERGRUND
Malware, Viren und Ransomware sind bekannte Bedrohungen für die Datenintegrität, und es gibt eine Reihe von Maßnahmen, die zur Erkennung dieser Bedrohungen existieren. Die User von Hardware- und Softwaresystemen sind besorgt, dass solche Malware, Viren und Ransomware die Integrität der von ihren Datenschutzsystemen durchgeführten Sicherungen (Backups) beeinträchtigen und/oder bei der Wiederherstellung von Backups möglicherweise wieder in die Umgebung eingeschleust werden.
Bei einem Ansatz zur Lösung solcher Probleme wird eine Vielzahl von Datenbanken verwendet, die Informationen betreffend die Daten und die möglichen Bedrohungen für die Daten enthalten. Derartige Ansätze haben sich jedoch als ineffektiv erwiesen, wenn es darum geht, Bedrohungen zu verhindern oder abzuwehren, zumindest weil die Datenbanken nicht miteinander verbunden sind, so dass zwischen den Usern der Datenbanken nur ein geringer oder gar kein Informationsaustausch stattfindet. Ein weiteres Manko dieses Ansatzes ist, dass die Datenbanken von jeweils unterschiedlichen Entitäten verwaltet werden, die als vertrauenswürdig gelten. Da mehrere unterschiedliche Datenbanken von mehreren Usern verwendet werden, ist außerdem nicht ersichtlich, welchen Usern vertraut werden kann und welchen nicht.
Figurenliste
Um die Art und Weise zu beschreiben, in der zumindest einige der Vorteile und Merkmale der Erfindung erreicht werden können, wird eine genauere Beschreibung der Ausführungsformen der Erfindung durch Bezugnahme auf spezifische Ausführungsformen davon, die in den beigefügten Zeichnungen dargestellt sind, gegeben. Ausführungsformen der Erfindung werden mit zusätzlicher Spezifität und Detailgenauigkeit durch die Verwendung der beigefügten Zeichnungen beschrieben und erläutert. Diese Zeichnungen stellen jedoch nur typische Ausführungsformen der Erfindung dar und sind daher nicht als Einschränkung ihres Umfangs zu betrachten.

In 1 sind Aspekte einer beispielhaften Betriebsumgebung und Komponenten einiger Ausführungsformen der Erfindung dargestellt.
In 2 sind Aspekte einer beispielhaften Host-Konfiguration dargestellt.
3 ist ein Flussdiagramm, das einige allgemeine Aspekte eines beispielhaften Verfahrens zur Verifizierung von Einträgen in ein gemeinsames Hauptbuch offenbart.
4 ist ein Flussdiagramm, das einige allgemeine Aspekte eines beispielhaften Verfahrens zur Verwendung von Whitelist- und Blacklist-Informationen eines Hauptbuchs offenbart.

DETAILLIERTE BESCHREIBUNG EINIGER BEISPIELHAFTER AUSFÜHRUNGSFORMEN
Ausführungsformen der vorliegenden Erfindung betreffen allgemein den Datenschutz. Insbesondere betreffen zumindest einige Ausführungsformen der Erfindung Systeme, Hardware, Software, computerlesbare Medien und Verfahren zur Erleichterung der Datenintegrität durch einen Userkonsens in Bezug auf das Whitelisting und Blacklisting von Dateien.
Im Allgemeinen können beispielhafte Ausführungsformen der Erfindung einen nicht vertrauenswürdigen Datenspeicherort (Trustless Data Repository, TDR) verwenden, der ein verteiltes Hauptbuch (Distributed Ledger) umfasst oder daraus besteht, zu dem jeder User (a) eine Liste von einer oder mehreren Dateien, die auf die Whitelist gesetzt werden sollen, und/oder (b) eine Liste von einer oder mehreren Dateien, die auf die Blacklist gesetzt werden sollen, beitragen kann. Das verteilte Hauptbuch dient als schreibgeschützte Datenbank, in der Einträge nur hinzugefügt, aber niemals modifiziert, gelöscht oder geändert werden können, sobald sie übergeben wurden. Die Einrichtung dieses Datenspeicherorts (Repositorium) in Form eines verteilten Hauptbuchs ermöglicht es den Usern, Informationen in einem einzigen Speicherort zu validieren, einzubringen und zu verdichten sowie den Daten in dem Speicherort und den Usern, die Einträge in das Repositorium einbringen, zu vertrauen oder nicht. Eine solche Funktionalität kann, muss aber nicht notwendigerweise, in Sicherungs- (Backup-) und Wiederherstellungssoftware als Mechanismus implementiert werden, um User auf das Vorhandensein schädlicher Daten aufmerksam zu machen.
In einer beispielhaften Ausführungsform wird ein einziger nicht vertrauenswürdiger Datenspeicherort erstellt, der ein verteiltes Hauptbuch umfasst oder daraus besteht, zu dem User und automatisierte Prozesse (a) eine Liste von Dateien, die auf die Whitelist gesetzt werden sollen, und/oder (b) eine Liste von Dateien, die auf die Blacklist gesetzt werden sollen, zum Zwecke der Datenintegrität beitragen können. Auf diese Weise kann ein User auf das Hauptbuch zugreifen, um zum Beispiel festzustellen, ob eine Website oder eine Datei, deren Nutzung der User in Betracht zieht, sicher ist oder nicht. Ausführungsformen der Erfindung können ein verteiltes Hauptbuch verwenden, das die Blockchain-Technologie und -Verfahren umfasst oder aus ihnen besteht. Durch die Schaffung dieses einzigen Repositoriums auf einem verteilten Hauptbuch können User und automatisierte Prozesse Daten validieren und einbringen, sowohl auf der Whitelist als auch auf der Blacklist. Schließlich wird jedem Eingebenden ein Glaubwürdigkeits-Score zugewiesen, der als Grundlage für die Entscheidung verwendet werden kann, ob Einträge in das verteilte Hauptbuch zugelassen werden oder nicht.
Vorteilhafterweise können Ausführungsformen der Erfindung verschiedene Vorteile und Verbesserungen gegenüber herkömmlicher Hardware, herkömmlichen Systemen und Verfahren bieten. Beispielsweise kann eine Ausführungsform der Erfindung Datenintegritätsinformationen bereitstellen und deren Verwendung ermöglichen, die in einem einzigen Speicherort (Repositorium) komprimiert sind, im Gegensatz zu einer Silo-Speicher-Konfiguration, die mehrere Datenbanken verwendet. Ausführungsformen der Erfindung ermöglichen es, dass die Integrität der Daten in einem einzigen Speicherort (Repositorium) durch einen Konsens zwischen den Usern des Repositoriums sichergestellt wird, so dass keine Notwendigkeit für mehrere verschiedene Datenbanken besteht. Diese Funktionalität kann insbesondere bei Daten nützlich sein, die von mehreren Usern gemeinsam genutzt werden. Außerdem kann der mit der Einrichtung und Aufrechterhaltung der Datenintegrität verbundene Verwaltungsaufwand gegenüber Ansätzen, die mehrere Repositorien umfassen, reduziert werden, da nur ein einziger Datenspeicherort verwendet wird und mehrere User des Speicherorts an der Überwachung der Daten und der Überprüfung anderer User teilnehmen. Ausführungsformen der Erfindung können den Betrieb und die Effektivität bestehender Datenschutzsysteme, - verfahren, -hardware und -software verbessern, indem neue Funktionen zur Datenintegritätsversicherung in diese Datenschutzsysteme, -verfahren, -hardware und -software integriert werden.
Es sei darauf hingewiesen, dass die vorstehenden vorteilhaften Aspekte verschiedener Ausführungsformen nur beispielhaft dargestellt sind und verschiedene andere vorteilhafte Aspekte von beispielhaften Ausführungsformen der Erfindung aus dieser Offenbarung ersichtlich sein werden. Es wird ferner darauf hingewiesen, dass nicht jede Ausführungsform notwendigerweise jeden der hierin offenbarten vorteilhaften Aspekte implementiert oder ermöglicht.
A. Aspekte von beispielhaften Betriebsumgebungen
Im Folgenden werden Aspekte von beispielhaften Betriebsumgebungen für verschiedene Ausführungsformen der Erfindung erörtert. Diese Erörterung soll den Umfang der Erfindung oder die Anwendbarkeit der Ausführungsformen in keiner Weise einschränken. Zusätzlich zu der folgenden Erörterung sind weitere Details zu beispielhaften Betriebsumgebungen, in denen Ausführungsformen der Erfindung implementiert werden können, in den verwandten Anmeldungen offenbart.
Im Allgemeinen können Ausführungsformen der Erfindung in Verbindung mit Systemen, Software und Komponenten implementiert werden, die einzeln und/oder gemeinsam Datenverwaltungsoperationen implementieren und/oder deren Implementierung bewirken. Solche Datenverwaltungsoperationen können unter anderem Daten-Lese/-Schreib/-Lösch-Operationen, Datensicherungsoperationen (Backup-Operationen), Datenwiederherstellungsoperationen, Datencloning-Operationen, Datenarchivierungsoperationen und Disaster-Recovery-Operationen umfassen, sind aber nicht darauf beschränkt. Auch wenn sich die Erörterungen hierin in einigen Aspekten auf eine Erörterung der Datenschutzumgebungen und -operationen beziehen, ist der Anwendungsbereich der Erfindung nicht darauf beschränkt. Allgemeiner ausgedrückt, umfasst der Anwendungsbereich der Erfindung jede Betriebsumgebung, in der die offenbarten Konzepte nützlich sein können. Beispielsweise, aber ohne darauf beschränkt zu sein, können Ausführungsformen der Erfindung in Verbindung mit und/oder integriert in Datensicherungs- und - wiederherstellungsplattformen, -systemen und -vorrichtungen eingesetzt werden. Beispiele hierfür sind unter anderem die Plattformen Dell-EMC NetWorker und Avamar, Dell-EMC Enterprise Copy Data Management (ECDM), Dell-EMC Integrated Data Protection Appliance (IDPA), Dell-EMC PowerProtect und/oder Datenschutzumgebungen, wie zum Beispiel Dell-EMC DataDomain.
Eine Datenschutzumgebung kann die Form einer öffentlichen oder privaten Cloud-Speicherumgebung, einer lokalen Speicherumgebung und von hybriden Speicherumgebungen, die öffentliche und private Elemente enthalten, annehmen, obwohl sich der Anwendungsbereich der Erfindung auch auf jede andere Art von Datenschutzumgebung erstreckt. Jede dieser beispielhaften Speicherumgebungen kann teilweise oder vollständig virtualisiert sein. Die Speicherumgebung kann ein Rechenzentrum umfassen oder daraus bestehen, das in der Lage ist, Lese- und Schreiboperationen zu bedienen, die von einem oder mehreren Clients initiiert werden.
Zusätzlich zur Speicherumgebung kann die Betriebsumgebung auch eine oder mehrere Hostvorrichtungen, wie zum Beispiel Clients, enthalten, die jeweils eine oder mehrere Anwendungen hosten. So kann ein bestimmter Client eine oder mehrere Instanzen einer oder mehrerer Anwendungen verwenden oder anderweitig damit verbunden sein. Im Allgemeinen sind die von den Clients verwendeten Anwendungen nicht auf eine bestimmte Funktionalität oder einen bestimmten Funktionalitätstyp beschränkt. Zu den beispielhaften Anwendungen und Daten gehören E-Mail-Anwendungen, wie zum Beispiel MS-Exchange, Dateisysteme sowie Datenbanken, wie zum Beispiel Oracle- Datenbanken und SQL-Server-Datenbanken. Die Anwendungen auf den Clients können neue und/oder modifizierte Daten erzeugen, die geschützt werden sollen.
Jede der hierin offenbarten Vorrichtungen oder Entitäten kann durch eine oder mehrere Datenschutz-Policen gemäß verschiedenen Ausführungsformen der Erfindung geschützt werden. Weitere Beispiele für Vorrichtungen, die durch eine Datenschutz-Police gemäß den Ausführungsformen der Erfindung geschützt werden können, sind, ohne darauf beschränkt zu sein, Container und VMs.
Jede der Vorrichtungen, einschließlich der Clients, Server und Hosts, in der Betriebsumgebung kann die Form von Software, physischen Maschinen oder virtuellen Maschinen (VM) oder einer beliebigen Kombination davon annehmen, obwohl keine bestimmte Geräteimplementierung oder -konfiguration für irgendeine Ausführungsform erforderlich ist. Auch die Komponenten des Datenschutzsystems, wie zum Beispiel Datenbanken, Speicherserver, Speichervolumina (LUNs), Speicherplatten, Replikationsdienste, Sicherungsserver, Wiederherstellungsserver, Sicherungsclients und Wiederherstellungsclients, können ebenfalls in Form von Software, physischen Maschinen oder virtuellen Maschinen (VM) vorliegen, wobei für keine Ausführungsform eine bestimmte Komponentenimplementierung erforderlich ist. Wenn VMs verwendet werden, kann ein Hypervisor oder ein anderer Virtual-Machine-Monitor (VMM) eingesetzt werden, um die VMs zu erstellen und zu kontrollieren.
Wie hierin verwendet, ist der Begriff „Daten“ weit gefasst. Daher umfasst dieser Begriff beispielhaft und ohne darauf beschränkt zu sein Datensegmente, wie sie von Datenstromsegmentierungsprozessen erzeugt werden können, Daten-Chunks, Datenblöcke, atomare Daten, E-Mails, Objekte jeder Art, Dateien, Kontakte, Verzeichnisse, Unterverzeichnisse, Volumina und jede Gruppe aus einem oder mehreren der vorgenannten.
Beispielhafte Ausführungsformen der Erfindung sind auf jedes System anwendbar, das in der Lage ist, verschiedene Arten von Objekten in analoger, digitaler oder anderer Form zu speichern und zu verarbeiten. Obwohl Begriffe, wie zum Beispiel „Dokument“, „Datei“, „Block“ oder „Objekt“ beispielhaft verwendet werden können, sind die Grundsätze der Offenbarung nicht auf eine bestimmte Form der Darstellung und Speicherung von Daten oder anderen Informationen beschränkt. Vielmehr sind diese Grundsätze gleichermaßen auf jedes Objekt anwendbar, das in der Lage ist, Informationen darzustellen.
Im Allgemeinen umfassen beispielhafte Ausführungsformen der Erfindung unter anderem die Integration der Blockchain-Technologie in Datenschutzsysteme, um die Erstellung einer Liste von Dateien zu ermöglichen, von denen bekannt ist, dass sie für die Verwendung sicher oder unsicher sind. Auf diese Weise können User überprüfen, ob eine bestimmte Datei, wie zum Beispiel „windows.dll“, sicher zu verwenden ist, d. h., ob die Datei frei von Malware, Viren, Ransomware oder anderen Elementen ist, die Userdaten und/oder -operationen gefährden könnten, wenn die Datei vom User verwendet würde.
Genauer gesagt kann eine Datenbank in einigen Ausführungsformen als nicht vertrauenswürdiger Datenspeicherort (Trustless Data Repository, TDR) implementiert werden, der in Verbindung mit einem verteilten Hauptbuch (distributed Ledger) arbeitet, zu dem jeder User (a) eine Liste mit einer oder mehreren Dateien, die auf die Whitelist gesetzt werden sollen, und/oder (b) eine Liste mit einer oder mehreren Dateien, die auf die Blacklist gesetzt werden sollen, beitragen kann. Dateien auf der Whitelist und Dateien auf der Blacklist können durch Konsens der User in den TDR aufgenommen werden. Die Fähigkeit eines Users, eine Datei in einer Whitelist oder Blacklist im Hauptbuch aufzuführen, kann durch die Verwendung eines Glaubwürdigkeits-Scores und eines Ratenbegrenzers kontrolliert werden, die beide spezifisch für diesen User sind.
Bezugnehmend nun auf 1, kann eine beispielhafte Betriebsumgebung 100 eine Datenschutzumgebung umfassen oder aus einer solchen bestehen. Die Datenschutzumgebung kann ein Unternehmensrechenzentrum oder ein Cloud-Rechenzentrum oder beides umfassen. Die Datenschutzumgebung kann verschiedene Datenschutzprozesse unterstützen, wozu zum Beispiel Datenreplikation, Datendeduplizierung, Cloning, Datensicherung und Datenwiederherstellung gehören. Der hier verwendete Begriff „Sicherung/Backup“ ist weit gefasst und umfasst unter anderem teilweise Backups, inkrementelle Backups, vollständige Backups, Clone-Backups, Schnapshots, kontinuierliche Replikation und jede andere Art von Datenkopien sowie jede Kombination der vorgenannten Prozesse. Jeder der vorgenannten Prozesse kann, muss aber nicht, dedupliziert werden.
Im Allgemeinen umfasst die beispielhafte Konfiguration in 1 verschiedene User/Contributors (UC) 210, 220 und 230. Im Allgemeinen und wie hierin offenbart, kann eine Entität, wie zum Beispiel 210, 220 und 230, sowohl ein User als auch ein Contributor, oder nur ein User oder nur ein Contributor sein. User, Contributors und User/Contributors werden hier allgemein als UCs bezeichnet. In einer Umgebung kann eine beliebige Anzahl von UCs existieren. Wie hierin verwendet, umfasst ein User eine oder mehrere Entitäten oder besteht aus diesen, wie zum Beispiel Anwendungen, die Glaubwürdigkeits-Scores in Verbindung mit ihren Operationen verwenden, wie zum Beispiel die Entscheidung, ob eine bestimmte Datei oder Dateien für solche Operationen verwendet werden sollen oder nicht. Ein Contributor umfasst eine oder mehrere Entitäten oder besteht daraus, wie zum Beispiel Computersysteme, Software und Hardware, die einen oder mehrere Einträge zur Aufnahme in ein Hauptbuch einreichen.
Jeder der UCs 210, 220 und 230 ist so konfiguriert, dass er eine Instanz eines Verifikationssystems 300 umfasst, das eine Glaubwürdigkeits-Engine 302 und eine Ratenbegrenzungs-Engine 304 enthält. Das Verifikationssystem 300 umfasst auch ein Hauptbuch 400, das eine Whitelist 402 und eine Blacklist 404 enthält. In anderen Ausführungsformen kann sich das Hauptbuch 400 an einem anderen Ort als im Verifikationssystem 300 befinden. Auch wenn dies in 1 nicht ausdrücklich angegeben ist, enthalten die UCs 220 und 230 jeweils entsprechende Instanzen des Verifikationssystems 300.
Schließlich kommuniziert ein zentralisierter Trust 500 auch mit den jeweiligen Kopien des Hauptbuchs 400 in jeder der UCs 210, 220 und 230. Obwohl nicht speziell dargestellt, können eine oder mehrere der UCs 210, 220 und 230 eine oder mehrere Anwendungen enthalten, die im Betrieb eine oder mehrere Dateien verwenden, auf die im Hauptbuch 400 verwiesen wird. Der zentralisierte Trust 500 kann (eine) beliebige Entität oder Entitäten sein, die von den UCs als vertrauenswürdig anerkannt wird/werden. Beispiele für zentralisierte Trusts sind McAfee, Symantec, Dell oder Microsoft.
Bezugnehmend auf die Elemente des Hauptbuchs 400 umfasst die Whitelist 402 eine Liste von Elementen, von denen bekannt ist, dass sie frei von Viren, Malware, Ransomware oder irgendwelchen anderen Elementen sind, die die Useroperationen oder -daten gefährden könnten. Zu diesen Elementen gehören unter anderem Dateien, Website-Namen, Programmnamen und eindeutige Fingerabdrücke von Programmen, Dateien und anderen Daten auf Treiber- und/oder Verzeichnisebene, wobei ein Beispiel für einen eindeutigen Fingerabdruck ein Hash ist. In ähnlicher Weise umfasst die Blacklist 404 eine Liste von Elementen, von denen bekannt ist, dass sie Aspekte enthalten, die die Useroperationen oder -daten gefährden könnten, wenn die Datei verwendet wird, wobei solche Elemente beispielsweise Virendateien, Malware, Ransomware, Website-Namen, Dateien, Programmnamen und eindeutige Fingerabdrücke von Programmen, Dateien und Daten umfassen können. Zumindest in einigen Ausführungsformen ist das Hauptbuch 400 in Form einer Blockchain implementiert, aber alternativ kann jeder andere Mechanismus oder Mechanismen mit einer Funktionalität, die mit der einer Blockchain vergleichbar ist, verwendet werden.
Das Hauptbuch 400 kann von den UCs 210, 220 und 230 über das Verifikationssystem 300 zugänglich sein. Im Allgemeinen umfassen UCs jede Entität, die in der Lage ist, Daten zum Hauptbuch 400 hinzuzufügen, Daten daraus zu entfernen und/oder Daten darin zu modifizieren. Die UCs 210, 220 und 230 umfassen eine beliebige Entität, die in der Lage ist, Daten aus dem Hauptbuch 400 zu lesen, um festzustellen, ob eine bestimmte Datei, die vom User verwendet wird oder verwendet werden soll, auf der Whitelist 402 oder der Blacklist 404 steht oder nicht. Zu beispielhaften Usern gehört unter anderem eine Sicherungsanwendung, wie zum Beispiel die Dell-EMC Avamar-Plattform. Einige beispielhafte Operationen eines Users in Verbindung mit den im Hauptbuch 400 aufgeführten Dateien werden weiter unten erläutert. In einigen Fällen kann eine Entität sowohl ein User als auch ein Contributor sein, während in anderen Fällen eine Entität nur ein User oder nur ein Contributor sein kann. Andere Beispiele für UCs können automatisierte Systeme und Software umfassen. Wie an anderer Stelle ausführlicher erläutert, kann die Fähigkeit irgendeines Users, einen Eintrag in die Whitelist 402 oder die Blacklist 404 einzureichen, durch ein Glaubwürdigkeits-Score-Modul 302 und ein Ratenbegrenzungs-Modul 304 geregelt werden.
Unter weiterer Bezugnahme auf 1 und obwohl dort nicht explizit dargestellt, kann jede der UCs 210, 220 und 230 in der Lage sein, direkt mit jeder der anderen UCs 210, 220 und 230 zu kommunizieren. Wenn also beispielsweise ein bestimmter UC 210, 220 und 230 eine Anfrage zum Hinzufügen eines Eintrags zur Whitelist 402 oder zur Blacklist 404 einreicht, kann diese Anfrage von diesem bestimmten UC 210, 220 und 230 an alle anderen UCs 210, 220 und 230 übermittelt werden. Die UCs, die die Anfrage erhalten, können die Anfrage basierend auf dem Glaubwürdigkeits-Score und/oder dem Ratenbegrenzungswert des Anfragenden bewerten und können Empfehlungen und/oder andere Eingaben an das Verifikationssystem 300 liefern, die angeben, ob diese UCs den angefragten Eintrag genehmigen oder nicht.
Die beispielhafte Betriebsumgebung 100 kann ferner einen zentralisierten Trust 500 umfassen, der so angeordnet ist, dass er mit den verschiedenen Instanzen des Hauptbuchs 400 kommuniziert. Im Allgemeinen ist der zentralisierte Trust 500 eine Entität oder eine Gruppe von Entitäten, die als vertrauenswürdig bekannt sind. Wie an anderer Stelle beschrieben, kann der zentralisierte Trust 500 dazu verwendet werden, anfänglich in das Hauptbuch 400 neue Einträge zu seeden. In dieser anfänglichen „Seeding“-Phase, die in einigen Ausführungsformen weggelassen werden kann, kann der zentralisierte Trust 500 nicht durch einen Ratenbegrenzer oder einen Glaubwürdigkeits-Score eingeschränkt werden. Wenn das anfängliche Seeding abgeschlossen ist, kann dem zentralisierten Trust 500 der gleiche Status wie jedem anderen UC zuerkannt werden, und als solcher können weitere Beiträge zum Hauptbuch 400 durch den zentralisierten Trust 500 durch einen Glaubwürdigkeits-Score, wie er zum Beispiel von der Glaubwürdigkeits-Engine 302 bestimmt wird, und einen Ratenbegrenzungswert, wie er zum Beispiel von der Ratenbegrenzungs-Engine 304 bestimmt wird, eingeschränkt werden.
B. Aspekte eines beispielhaften Hauptbuchs (Ledger)
Unter weiterer Bezugnahme auf 1 werden weitere Einzelheiten zu einem Hauptbuch bereitgestellt, von denen ein Beispiel das Hauptbuch 400 ist. Wie bereits erwähnt, befinden sich Kopien des Hauptbuchs 400 in jedem der UCs. Im Allgemeinen erlaubt das Hauptbuch, bei dem es sich um einen TDR-Ledger handeln kann, die Aufnahme von Daten von mehreren Usern oder UCs in das Hauptbuch 400, sofern dies vom Verifikationssystem 300 zugelassen wird. Zu Beginn kann jeder Datensatz im Hauptbuch 400 eine Kopie aus einer oder mehreren Quellen sein, wie zum Beispiel einer öffentlichen oder privaten Datenbank, die Whitelist- und/oder Blacklist-Datensätze enthält. Wenn Daten hinzugefügt, aktualisiert oder aus dem Hauptbuch 400 entfernt werden müssen, werden neue Einträge hinzugefügt, die die Statusänderung (hinzugefügt, aktualisiert oder entfernt) anzeigen, wobei die alten Einträge erhalten bleiben. Unter anderem ermöglicht die Beibehaltung der alten Einträge die Durchführung von Audits, und aufgrund der Konstruktion des Hauptbuchs 400 kann keiner der Einträge modifiziert werden, was vor Handlungen durch böswillige Akteure schützt.
Wie bereits erwähnt, kann der Aufbau und die Verwendung des Hauptbuchs 400 in Übereinstimmung mit irgendeinem von einer Vielzahl an Blockchain-Prozessen erfolgen. Im Allgemeinen enthält jeder Eintrag in das Hauptbuch 400 oder jeder Block von Einträgen in das Hauptbuch 400 einen eindeutigen Identifikator des unmittelbar vorangehenden Blocks in der Blockchain. Dieser eindeutige Identifikator kann zum Beispiel ein Hash des gesamten Inhalts des unmittelbar vorangehenden Blocks sein, und das Hauptbuch 400 kann eine verknüpfte Liste, wie zum Beispiel eine Datenstruktur, verwenden. Wenn ein neuer Block erstellt wird, enthält der neue Block den Hash des unmittelbar vorangehenden Blocks, und so weiter für jeden Block in der Blockchain.
Zu den UCs des Hauptbuchs 400 können sowohl User als auch automatisierte Systeme und Software gehören, die dem Hauptbuch 400 Daten hinzufügen und Daten darin aktualisieren können. Zum Beispiel könnte ein vertrauenswürdiger Anbieter (Trusted Provider) von Betriebssystemen (OS), wie zum Beispiel Microsoft, alle Dateihashes des Betriebssystems als Teil der Whitelist 402 in das Hauptbuch 400 aufnehmen. Zusätzlich oder alternativ kann ein solcher vertrauenswürdiger Provider auch als zentralisierter Trust 500 dienen.
Beispielsweise kann ein Datenschutzsystem oder eine Software, wie zum Beispiel die Dell-EMC Avamar-Plattform, das Verifikationssystem 300 nach einem bestimmten Fingerabdruck, wie beispielsweise einem Hash, abfragen, den es während einer normalen, vom Datenschutzsystem durchgeführten Sicherungsoperation sieht. Als Antwort kann das Verifikationssystem 300 das Hauptbuch 400 abfragen und einen passenden Hash aus der Whitelist 402 oder der Blacklist 404 an das Datenschutzsystem zurückgeben. In einigen Ausführungsformen kann das Verifikationssystem 300 einen Bloom-Filter oder einen vergleichbaren Mechanismus verwenden, um die Leistung der Suche im Hauptbuch 400 zu verbessern.
Der zurückgegebene übereinstimmende Hash kann dem Datenschutzsystem als entweder in der Whitelist 402 oder in der Blacklist 404 gefunden identifiziert werden. Wenn der zurückgegebene Hash ein Hash der Blacklist 404 ist, kann das Datenschutzsystem den Hash, der während des Sicherungsvorgangs gesehen wurde, als potenziell problematisch kennzeichnen. Handelt es sich bei dem zurückgegebenen Hash hingegen um einen Hash der Whitelist 402, kann das Datenschutzsystem sicher sein, dass der Hash, der während des Sicherungsvorgangs gesehen wurde, vertrauenswürdig ist. Wenn das Verifikationssystem 300 als Reaktion auf die Anfrage des Datenschutzsystems keinen passenden Hash im Hauptbuch findet, kann das Datenschutzsystem entsprechend benachrichtigt werden.
Wenn beispielsweise Microsoft im Hauptbuch 400 einen Hash-Wert von „1a“ für eine Datei namens „Windows.dll“ angibt und Avamar einen Hash-Wert von „9z“ für dieselbe Datei sieht, kann Avamar die Datei zur Überprüfung kennzeichnen, da die Nichtübereinstimmung zwischen den Hashes „1a“ und „9z“ die Authentizität und Sicherheit der von Avamar während des Sicherungsvorgangs identifizierten Datei „Windows.dll“ in Frage stellen kann. Alternativ könnte im Hauptbuch 400 bereits ein Eintrag für dieselbe Datei mit dem Hash ‚9z‘ als bekannte Malware (Blacklist) vorhanden sein, und Avamar könnte diese ebenfalls kennzeichnen. Auf diese Weise kann ein UC, wie zum Beispiel Avamar, die Whitelist-/Blacklist-Informationen nutzen, um Probleme bei Operationen, die von dem UC oder auf Anweisung des UC durchgeführt werden, zu vermeiden.
Beispielhafte Ausführungsformen eines Hauptbuchs können auch andere Merkmale enthalten. Zum Beispiel können einem oder mehreren Einträgen im Hauptbuch 400 erweiterte Attribute zugeordnet sein, um den UCs 210, 220 und 230 Flexibilität zu bieten. Ein Beispiel für ein solches erweitertes Attribut ist die Möglichkeit, Dateien zu versionieren. Weiter bezugnehmend auf das oben erwähnte Beispiel, könnte, während Microsoft einen Hash-Wert von „1a“ für eine Datei namens „Windows.dll“ bereitstellen könnte, Microsoft zukünftig einen neuen Hash-Wert von „4h“ herausgeben, der einer aktualisierten Version der herausgegebenen Datei „Windows.dll“ entspricht.
In diesem Beispiel ermöglichen die erweiterten Attribute den UCs 210, 220 und 230 des Hauptbuchs 400, die Version der Datei abzugleichen, über die sie verfügen. Wenn keine Version gefunden wird, können die UCs 210, 220 und 230 entscheiden, ob sie dem Inhalt der Datei vertrauen oder nicht.
C. Aspekte eines beispielhaften Verifikationssystems und beispielhafter Verifikationsoperationen
Mit Blick auf die vorangegangene Diskussion von beispielhaften Hauptbüchern werden nun Einzelheiten zu Aspekten eines Verifikationssystems bereitgestellt, von dem ein Beispiel allgemein mit 300 bezeichnet wird, das sicherstellt, dass nur gute oder vertrauenswürdige Daten zum Hauptbuch 400 hinzugefügt werden. Insbesondere muss, bevor eine Entität einen Eintrag in das Hauptbuch 400 vornehmen kann, der Eintrag durch das Verifikationssystem 300 verifiziert werden, und so müssen Eingaben von einem UC 210, 220, 230, zum Beispiel, zuerst das Verifikationssystem 300 passieren und werden dann, wenn sie verifiziert sind, vom Verifikationssystem 300 an das Hauptbuch 400 zur Aufnahme übertragen. Wie bereits erwähnt, kann eine Einzelperson, eine Organisation oder eine andere Entität berechtigt sein, (a) eine Liste von Dateien zur Whitelist 402 und/oder (b) eine Liste von Dateien zur Blacklist 404 beizusteuern. Dementsprechend verwenden Ausführungsformen der Erfindung ein Verifikationssystem 300 mit Verifikationsfunktionalität, um die Validität von Daten sicherzustellen, die zur Aufnahme in eine Whitelist 402 oder Blacklist 404 vorgeschlagen werden. Das Verifikationssystem 300 ist unter anderem in der Lage, DDoS (Distributed Denial-of-Service)-Angriffe auf das Hauptbuch 400 zu verhindern, und zu verhindern, dass böswillige Akteure gefälschte oder bösartige Daten oder andere Elemente in das Hauptbuch 400 einbringen. Beispielhafte Ausführungsformen eines Verifikationssystems 300 umfassen eine Glaubwürdigkeits-Score (CS)-Funktionalität, die von der Glaubwürdigkeits-Engine 302 implementiert werden kann, und/oder eine Ratenbegrenzungs-Funktionalität (RL), die von der Ratenbegrenzungs-Engine 304 implementiert werden kann.
In einigen Ausführungsformen kann die Funktionalität des Verifikationssystems 300 als SaaS (Software-as-a-Service) implementiert werden, die auf einer Cloud-Site, vor Ort und/oder anderswo läuft und auf die die UCs 210, 220 und 230 zugreifen können. In anderen Ausführungsformen kann das Verifikationssystem 300 auf einem eigenständigen Server implementiert werden, der für die Kommunikation mit dem Hauptbuch 400 und den UCs 210, 220 und 230 konfiguriert ist. In noch anderen Ausführungsformen, und wie in der in 1 offenbarten Konfiguration beispielhaft dargestellt, können entsprechende Instanzen eines Verifikationssystems 300 auf jedem von „n“ UCs implementiert werden. Es ist jedoch keine bestimmte Implementierungskonfiguration eines Verifikationssystems 300 erforderlich.
Zunächst wird, wie bereits erwähnt, ein zentralisierter Trust 500, wie zum Beispiel RSA (Schöpfer des RSA-Kryptosystems), Dell und Microsoft, für eine Person oder Organisation etabliert, der Datenseeding in das Hauptbuch 400 durchführt. Das heißt, ein Zweck des zentralisierten Trusts 500 ist es, Daten in das Hauptbuch 400 zu seeden und dadurch über einen gewissen Zeitraum die Notwendigkeit eines weiteren Seedings durch den zentralisierten Trust 500 zu verringern oder zu eliminieren. Um dies zu erreichen, werden jedem UC im Hauptbuch 400 zwei Attribute zugewiesen, nämlich ein Glaubwürdigkeits-Score (CS) und ein Ratenbegrenzer (Rate Limiter; RL).
Im Allgemeinen und wie nachstehend erörtert, dienen die Glaubwürdigkeits-Engine 302 und die Ratenbegrenzungs-Engine 304, die gemeinsam in einer einzigen Engine oder in separaten jeweiligen Engines implementiert werden können, der Kontrolle des Hinzufügens von Einträgen und der Implementierung anderer Änderungen im Hauptbuch 400. Solche Engine(s) können allein oder in Abstimmung mit den „non-submitting“ UCs handeln, um zu bestimmen, ob ein angefragter Eintrag in das Hauptbuch 400 vorgenommen wird oder nicht. Der hier verwendete Begriff „Eintrag“ in ein Hauptbuch ist weit gefasst und umfasst unter anderem jede Änderung des Hauptbuchs, sei es durch Hinzufügen eines neuen Elements, Änderung eines bestehenden Elements oder Hinzufügen eines Eintrags, der ein älteres Element in einer Whitelist oder Blacklist ungültig macht. Sowohl der Ratenbegrenzer als auch der Glaubwürdigkeits-Score können auf einen einzelnen UC oder auf eine definierte Gruppe von UCs angewendet werden. Die Glaubwürdigkeits-Engine 302 und/oder die Ratenbegrenzungs-Engine 304 können autonom und/oder basierend auf Eingaben von einem oder mehreren der UCs 210, 220 und 230 arbeiten.
Der Glaubwürdigkeits-Score (CS) spiegelt im Allgemeinen das Ausmaß wider, in dem zum Beispiel ein bestimmter UC 210, 220 und 230 von der Glaubwürdigkeits-Engine 302 und/oder von zum Beispiel den anderen UCs 210, 220 und 230 als vertrauenswürdig angesehen wird, so dass dem bestimmten UC 210, 220 oder 230 erlaubt werden sollte, Einträge zum Hauptbuch 400 beizutragen. Wie bereits erwähnt, kann während der anfänglichen Erstellung des Hauptbuchs 400 der zentralisierte Trust 500, der Seeding in das Hauptbuch 400 durchgeführt hat, einen relativ hohen Glaubwürdigkeits-Score haben. Der zentralisierte Trust 500 kann, zumindest für eine gewisse Zeit, neue Einträge zum Hauptbuch 400 hinzufügen, ohne durch Beschränkungen oder Mechanismen, wie beispielsweise eine Ratenbegrenzung, eingeschränkt zu sein. Nachdem das Seeding abgeschlossen ist, werden das zentralisierte Trust-Element oder die Trust-Elemente 500 nicht mehr besonders berücksichtigt und hinsichtlich ihrer Fähigkeit, zum Hauptbuch 400 beizutragen, genauso behandelt wie die anderen UCs 210, 220 und 230. In einigen Ausführungsformen kann der zentralisierte Trust 500 eine Vielzahl von UCs umfassen, wie zum Beispiel verschiedene Softwareunternehmen. In anderen Ausführungsformen besteht der zentralisierte Trust 500 aus einem einzigen UC.
Anfangs hat jeder UC 210, 220 und 230, mit der möglichen Ausnahme des/der User(s) des zentralisierten Trusts 500, einen anfänglichen Glaubwürdigkeits-Score, der auf einen Standardwert von Null gesetzt ist. Wenn ein UC Einträge zum Hauptbuch 400 hinzufügt, kann sich sein Glaubwürdigkeits-Score erhöhen oder verringern. Der Glaubwürdigkeits-Score kann sich zum Beispiel erhöhen, wenn der UC einen neuen Eintrag in das Hauptbuch einträgt, der einen älteren Eintrag ungültig macht. Um auf das Beispiel der Datei „Windows.dll“ zurückzukommen, könnte Microsoft dem Hauptbuch 400 einen neuen Eintrag hinzufügen, der eine neue Version der Datei widerspiegelt, weil sich der Hash von Windows.dll von „1a“ auf „2e“ geändert hat. Ein Glaubwürdigkeits-Score kann sich auch erhöhen, wenn ein Eintrag beispielsweise nie für ungültig erklärt wird, was beweist oder zumindest die Vermutung stützt, dass es sich um einen gültigen Eintrag handelt.
Ebenso kann ein Glaubwürdigkeits-Score sinken, wenn zum Beispiel mehrere UCs Einträge in das Hauptbuch 400 einreichen, die ältere Daten ungültig machen. Wenn zum Beispiel ein Verifikationssystem 300 einem betrügerischen Akteur erlaubt hat, einen Eintrag mit einem Hashwert von „6f“ für die Datei „Windows.dll“ an das Hauptbuch 400 einzureichen, aber sowohl Microsoft als auch RSA neue Einträge hinzufügen, die die Eingabe des betrügerischen Akteurs ungültig machen oder ihr widersprechen. In diesem Fall würde der Glaubwürdigkeits-Score des betrügerischen Akteurs sinken, während gleichzeitig die jeweiligen Glaubwürdigkeits-Scores von Microsoft und RSA steigen würden. Die Glaubwürdigkeits-Scores können auf Dateibasis und/oder auf Userbasis ermittelt und verwendet werden.
Generell können alle Daten, Indikatoren oder Ereignisse, die direkt oder indirekt auf die Wahrscheinlichkeit hinweisen, dass einer Datei Integrität fehlt oder sie ein anderes Problem aufweist, von der Glaubwürdigkeits-Engine 302 als Grundlage für die Erstellung eines Glaubwürdigkeits-Scores verwendet werden. Die vorstehenden Ausführungen dienen nur als Beispiel und sollen den Umfang der Erfindung in keiner Weise einschränken. Darüber hinaus kann die Glaubwürdigkeits-Engine 302, wie an anderer Stelle erwähnt, auch Eingaben von einem oder mehreren UCs bei der Berechnung eines Glaubwürdigkeits-Scores berücksichtigen.
Im Hinblick auf ihre Implementierung kann die Verwendung des von der Glaubwürdigkeits-Engine 302 erzeugten Glaubwürdigkeits-Scores beispielsweise in Datenschutzprodukten, wie zum Beispiel der Dell-EMC-Avamar-Plattform und der Dell-EMC-PowerProtect-Data-Manager-Plattform, enthalten sein. Das Datenschutzprodukt als solches oder eine andere Software, die Glaubwürdigkeits-Score-Informationen verwendet, ist imstande, basierend auf dem Glaubwürdigkeits-Score der Entität, die diese Datei zur Whitelist oder Blacklist beigetragen hat, für jede einzelne Datei zu entscheiden, ob sie verwendet werden soll oder nicht. Generell kann die Berücksichtigung von Glaubwürdigkeits-Scores in jede Software, Hardware oder jedes System integriert werden, das eine Datei verwendet oder von dem erwartet wird, dass es eine Datei verwendet, die im Hauptbuch 400 rückverfolgt wird oder rückverfolgt werden kann. Daher ist der Umfang der Erfindung nicht auf die Verwendung in Datenschutzanwendungen beschränkt.
Schwellenwerte für die Akzeptanz eines Glaubwürdigkeits-Scores können beispielsweise von der Anwendung, durch einen User oder durch die Glaubwürdigkeits-Engine 302 festgelegt werden. Erreicht oder übersteigt der Glaubwürdigkeits-Score eines Users in Bezug auf eine Datei einen bestimmten Schwellenwert, kann die Anwendung mit der Verwendung der Datei fortfahren. Erreicht der Glaubwürdigkeits-Score hingegen nicht den Schwellenwert, kann die Anwendung beschließen, die Datei nicht zu verwenden, und kann die Datei auch als potenziell problematisch kennzeichnen. So kann beispielsweise bei einer Wiederherstellungsoperation, die von einer Sicherungs- und Wiederherstellungsanwendung durchgeführt wird, der Glaubwürdigkeits-Score eines Users als Hinweis auf mögliche Malware oder Viren in einer Datei, die im Zusammenhang mit der Durchführung der Wiederherstellungsoperation verwendet wird, angezeigt werden. Dieselben Daten können für jede Datei von der Anwendung verwendet werden, um einen aggregierten Bericht aus Asset-Sicht oder infrastrukturweiter Sicht zu erstellen.
Zusätzlich zur Glaubwürdigkeits-Score-Funktionalität, die von einer Glaubwürdigkeits-Engine 302 implementiert wird, kann das Verifikationssystem 300 auch eine Ratenbegrenzungs-Engine 304 enthalten, die festlegt, wie oft ein UC Einträge in das Hauptbuch übermitteln kann. Im Allgemeinen kann die Ratenbegrenzungs-Engine 304 einen einstellbaren Grenzwert für die Rate festlegen, mit der ein UC Einträge in das Hauptbuch 400 einbringen kann. Der Wert, der von der Ratenbegrenzungs-Engine 304 für einen bestimmten UC festgelegt wird, kann auf der Grundlage des Glaubwürdigkeits-Scores dieses UC und/oder auf der Grundlage von Eingaben von einem oder mehreren anderen UCs festgelegt werden.
So bedeutet ein hoher Ratenbegrenzungswert für einen bestimmten UC, dass dieser UC eine relativ hohe Anzahl von Eingaben in das Hauptbuch 400 pro Zeiteinheit vornehmen kann. In ähnlicher Weise bedeutet ein niedriger Ratenbegrenzungswert, dass ein UC zwischen den Eingaben länger warten muss. Jeder UC hat einen anfänglichen Ratenbegrenzungswert, wie zum Beispiel eine Eingabe pro Stunde, aber dieser Wert kann sich nach dem Ermessen der Hauptbuch-400-Community ändern, die die anderen UCs umfassen oder aus ihnen bestehen kann. Auch der Glaubwürdigkeits-Score eines UC kann in die diesem UC zugewiesene Ratenbegrenzung einfließen. Hat ein UC beispielsweise einen niedrigen Glaubwürdigkeits-Score, kann die Ratenbegrenzung für diesen UC entsprechend niedrig sein. Das heißt, dass dieser UC zum Beispiel nur einen Eintrag pro Tag in das Hauptbuch 400 vornehmen darf. Wenn der UC beispielsweise einen DDoS-Angriff mit Hunderttausenden von Beiträgen in einem Zeitraum von 24 Stunden versuchen würde, würden alle Beiträge bis auf einen effektiv blockiert werden.
So kann ein Ratenbegrenzungswert für einen UC diesen UC daran hindern, das Hauptbuch 400 anzugreifen, z. B. durch Spamming, DDoS oder einen „Fifty-One-Percent“-Angriff. Ähnlich wie bei der Glaubwürdigkeits-Score-Funktionalität wird für jede positive Eingabe in das Hauptbuch 400 die Ratenbegrenzung für diesen einzelnen UC erhöht. Umgekehrt wird bei jeder stattfindenden negativen Eingabe die Ratenbegrenzung vermindert. Ein höherer Ratenbegrenzungswert bedeutet, dass ein bestimmter UC in einer bestimmten Zeitspanne mehr Eingaben in das Hauptbuch 400 vornehmen kann. Eine positive Eingabe ist hierin eine Eingabe, die entweder zu Beginn oder über einen bestimmten Zeitraum hinweg aus beliebigen Gründen eine relativ hohe Glaubwürdigkeit gezeigt hat. Auf der anderen Seite ist eine negative Eingabe hierin eine Eingabe, die entweder anfänglich oder über einen bestimmten Zeitraum aus irgendeinem Grund eine relativ niedrige Glaubwürdigkeit gezeigt hat.
Beispielsweise können in einer Umgebung, in der 3 von 4 Usern, von denen jeder zum Beispiel einen Knoten umfasst, einen böswilligen Eintrag in ein Hauptbuch vornehmen wollen, die Einträge durch eine Ratenbegrenzung verhindert oder zumindest reduziert werden, ungeachtet der Tatsache, dass die 3 User zahlenmäßig den einen verbleibenden User überwiegen. Weiter angenommen, dass die 3 User relativ neu sind und einen niedrigen oder einen Glaubwürdigkeits-Score von Null haben. In diesem Fall wird die Tatsache, dass eine Mehrheit der Knoten den Versuch unternimmt, einen böswilligen Eintrag in das Hauptbuch vorzunehmen, durch die jeweiligen niedrigen Glaubwürdigkeits-Scores dieser Knoten abgeschwächt. Obgleich die Knoten, die versuchen, böswillige Einträge vorzunehmen, die Mehrheit der Knoten im System darstellen können, implizieren ihre niedrigen Glaubwürdigkeits-Scores entsprechend niedrige Ratenbegrenzungen. So können in einem bestimmten Zeitrahmen nur einige wenige oder einer oder keiner der böswilligen Einträge vorgenommen werden.
D. Beispielhafte Host- und Server-Konfigurationen
Gemäß 2 können jeder oder mehrere von den UCs 210, 220, 230, dem Verifikationssystem 300, der Glaubwürdigkeits-Engine 302, der Ratenbegrenzungs-Engine 304, dem Hauptbuch 400, der Whitelist 402, der Blacklist 404 und dem zentralisierte Trust 500 die Form einer physischen Rechenvorrichtung annehmen oder diese einschließen oder auf einer solchen implementiert werden oder von dieser gehostet werden, wovon ein Beispiel mit 600 bezeichnet wird. Wenn eines der vorgenannten Elemente eine virtuelle Maschine (VM) umfasst oder aus einer solchen besteht, kann diese VM eine Virtualisierung einer beliebigen Kombination der in 2 offenbarten physischen Komponenten darstellen.
Im Beispiel von 2 umfasst die physische Rechenvorrichtung 600 einen Speicher 602, der einen, einige oder alle von: Speicher mit wahlfreiem Zugriff (Random Access Memory, RAM), nichtflüchtige Speicher mit wahlfreiem Zugriff (NVRAM) 604, Festwertspeicher (ROM) und persistente Speicher, einen oder mehrere Hardwareprozessoren 606, nichtflüchtige Speichermedien 608, eine Ul-Vorrichtung 610 und einen Datenspeicher 612 umfassen kann. Eine oder mehrere der Speicherkomponenten 602 der physischen Rechenvorrichtung 600 können die Form eines SSD (Solid State Device)-Speichers annehmen. Außerdem werden eine oder mehrere Anwendungen 614 bereitgestellt, die ausführbare Anweisungen enthalten. Solche ausführbaren Anweisungen können verschiedene Formen annehmen, beispielsweise Anweisungen, die ausführbar sind, um eine beliebige Funktion, ein beliebiges Verfahren oder einen beliebigen Teil davon, wie hierin offenbart, auszuführen, und/oder die von/an irgendeinem Speicherort, sei es vor Ort in einem Unternehmen, oder einem Cloud-Speicherort, einem Client, einem Rechenzentrum, einem Backup-Server, einem Blockchain-Netzwerk oder einem Blockchain-Netzwerkknoten ausführbar sind, um hierin offenbarte Funktionen auszuführen. Ebenso können solche Anweisungen ausführbar sein, um irgendwelche der anderen hierin offenbarten Operationen durchzuführen, einschließlich, aber nicht beschränkt auf, Blockchain-Ledger-Operationen, Hauptbucheintrag-Übermittlungen, Glaubwürdigkeits-Score-Bestimmungen, Ratenbegrenzungswert-Bestimmungen und Verwendung von Glaubwürdigkeits-Scores und/oder Ratenbegrenzungswerten in Verbindung mit Operationen, die von Anwendungen, Systemen oder Vorrichtungen durchgeführt werden.
E. Beispielhafte Verfahren
Mit Blick auf 3 werden nun Aspekte von beispielhaften Verfahren offenbart. Ein bestimmtes Verfahren wird allgemein mit 700 bezeichnet und betrifft die Behandlung von vorgeschlagenen Hauptbucheinträgen, die von einem oder mehreren UCs eingereicht werden. Das beispielhafte Verfahren 700 kann von mehreren Entitäten, wie zum Beispiel einem Verifikationssystem und einem Hauptbuch, kooperativ durchgeführt werden. Die in 3 gezeigte funktionelle Zuordnung ist jedoch nur beispielhaft, und in anderen Ausführungsformen können die offenbarten Funktionen auf andere Weise den verschiedenen Entitäten zugeordnet sein. Es sei auch darauf hingewiesen, dass, wie bei den anderen hier offenbarten Verfahren und Prozessen, die Reihenfolge der verschiedenen Prozesse in dem Verfahren 700 von der angegebenen Reihenfolge abweichen kann, und die offenbarten Prozesse nicht notwendigerweise in der in den Figuren angegebenen Reihenfolge ausgeführt werden müssen.
Das beispielhafte Verfahren 700 kann damit beginnen, dass eine Verifikation von einem UC, wie zum Beispiel einem User/Contributor, einen vorgeschlagenen Eintrag für eine Whitelist oder Blacklist eines Hauptbuchs erhält (702). Der Eintrag kann eine Vielzahl von Formen annehmen, und der Umfang der Erfindung ist nicht auf die hier dargelegten Beispiele beschränkt. Beispielsweise kann der Eintrag (i) eine Datei, eine Website oder ein anderes Element identifizieren, das entweder in der Whitelist oder in der Blacklist aufgeführt werden soll, (ii) eine neue Version einer Datei, einer Website oder eines anderen Elements identifizieren, die entweder in der Whitelist oder in der Blacklist aufgeführt werden soll, (iii) ein Element identifizieren, das entweder aus der Whitelist oder aus der Blacklist entfernt werden soll, oder (iv) einen älteren Eintrag ungültig machen, wie in dem oben genannten Beispiel der Versionierung.
Nach Erhalt (702) des vorgeschlagenen Eintrags bestimmt das Verifikationssystem dann einen Glaubwürdigkeits-Score (CS) und einen Ratenbegrenzungswert (RL) für die Entität, die den vorgeschlagenen Eintrag übermittelt hat, oder weist diesen zu (704). Wenn der UC dem Verifikationssystem vorher nicht bekannt ist, können der CS und der RL entsprechend den Standardwerten zugewiesen werden. Beispielsweise kann der Standard-CS gleich Null, das heißt neutral, sein, und der RL kann ähnlich niedrig sein, wie zum Beispiel eine Übermittlung in einem Zeitraum von 24 Stunden. Im Allgemeinen können die Standardwerte für CS und RL auf jeden beliebigen Wert gesetzt und bei Bedarf geändert werden. Ist der UC bekannt, kann das Verifikationssystem die aktuellen CS- und RL-Werte für diesen UC nachschlagen, zum Beispiel in einer für das Verifikationssystem zugänglichen Datenbank. Alternativ kann der vom UC übermittelte und vom Verifikationssystem empfangene (702) Eintragsvorschlag die CS- und RL-Informationen für diesen UC enthalten.
Als Teil des Prozesses der Bestimmung oder Zuweisung von CS- und RL-Werten (704) kann das Verifikationssystem Eingaben von einer oder mehreren Quellen erhalten (706), und diese Eingaben können als Grundlage für die Zuweisung und/oder Anpassung eines oder beider CS- und RL-Werte verwendet werden. Wenn es sich bei dem UC beispielsweise um ein bekanntes und vertrauenswürdiges Softwareunternehmen handelt, das jedoch noch nie mit dem Hauptbuch interagiert hat, können Informationen über das Unternehmen als Eingabe 706 für die Zuweisung eines CS- und RL-Werts für diesen UC verwendet werden. In diesem Beispiel können CS- und RL-Werte zugewiesen werden, die höher sind als die Standardwerte, da das Unternehmen, d. h. der UC, bekannt und vertrauenswürdig ist. Die Eingabe 706 kann von einer beliebigen Quelle stammen, einschließlich eines oder mehrerer anderer UCs, und kann zusätzlich oder alternativ Informationen über frühere Transaktionen enthalten, an denen der UC beteiligt war, wenn es sich bei dem vorgeschlagenen Eintrag, der empfangen wurde (702), nicht um eine erstmalige Eingabe des UC handelt.
Nachdem der CS und der RL bestimmt oder zugewiesen wurden, wird eine Bestimmung 708 vorgenommen, ob der CS einen festgelegten Schwellenwert für den eingebenden UC erfüllt, und auch, ob der Zeitpunkt des vorgeschlagenen Eintrags mit dem RL dieses UC übereinstimmt. Es sind verschiedene Ergebnisse der Bestimmung 708 möglich. In einem Fall kann der CS den Schwellenwert erfüllen, aber wenn der Zeitpunkt des vorgeschlagenen Eintrags nicht mit dem RL übereinstimmt, kann der vorgeschlagene Eintrag zurückgehalten werden (710), bis genügend Zeit verstrichen ist, so dass die RL-Anforderung erfüllt ist, wonach der vorgeschlagene Eintrag an das Hauptbuch weitergeleitet werden kann (712). Wenn der Eintrag zurückgehalten wird, kann der UC davon in Kenntnis gesetzt werden (710). In einem anderen Fall sind sowohl die CS- als auch die RL-Kriterien erfüllt, und der vorgeschlagene Eintrag wird ohne Verzögerung an das Hauptbuch weitergeleitet (712). In einem noch anderen Fall, wenn festgestellt wird (708), dass das CS-Kriterium nicht erfüllt ist, wird der vorgeschlagene Eintrag abgelehnt und der übermittelnde UC entsprechend benachrichtigt.
Unter weiterer Bezugnahme auf 3 und die vorgenannten Beispiele können die Ergebnisse der Abfrage 708 bei den nachfolgenden Festlegungen 704 der CS- und RL-Werte für den UC verwendet werden. Abhängig von den Ergebnissen der Abfrage 708 kann der CS und/oder RL des UC erhöht werden, zum Beispiel wenn der Eintrag an das Hauptbuch weitergeleitet wird, oder verringert werden, zum Beispiel wenn der Eintrag abgelehnt wird.
Wie bereits erwähnt, wird, wenn die CS- und RL-Schwellenwerte bei 708 erfüllt sind, der vom UC eingegebene vorgeschlagene Eintrag dann, zum Beispiel durch das Verifikationssystem, an das Hauptbuch weitergeleitet (712). Das Hauptbuch empfängt (714) den Eintrag und verwendet ihn dann als Grundlage für die Erstellung eines neuen Blocks, beispielsweise durch Hashing des Eintrags und des unmittelbar vorhergehenden Blocks, und fügt dann den neuen Block an die Blockchain an (716). Der Prozess 716 stellt somit das Hinzufügen des Eintrags zum Hauptbuch dar. Nachdem der Eintrag zum Hauptbuch hinzugefügt wurde (716), meldet (718) das Hauptbuch an den UC und/oder andere Entitäten, dass das Hauptbuch aktualisiert wurde, um den Eintrag aufzunehmen.
Obwohl in 3 nicht speziell dargestellt, wird darauf hingewiesen, dass im Hauptbuch vor der Durchführung des Verfahrens 700 ein Seeding durchgeführt werden kann. Einige beispielhafte Seeding-Prozesse sind an anderer Stelle hierin offenbart.
In 4 sind nun Einzelheiten zu den Verfahren zur Verwendung von CS- und/oder RL-Werten in Verbindung mit den Operationen einer Anwendung oder der sonstigen Verwendung eines Elements dargestellt, wobei ein Beispiel für ein solches Verfahren allgemein mit 800 bezeichnet wird. Das beispielhafte Verfahren 800 kann beginnen, wenn eine bei einem UC gehostete Anwendung instanziiert wird (802), zum Beispiel bei oder durch einen UC. Die Anwendung kann eine beliebige Anwendung sein, die einen entsprechenden Eintrag in einer Whitelist oder einer Blacklist eines Hauptbuchs hat. Es ist auch nicht notwendig, dass eine Anwendung bei 802 instanziiert wird, vielmehr und allgemeiner kann der Prozess bei 802 die Verwendung eines beliebigen Elements beinhalten, das einen entsprechenden Eintrag in einer Whitelist oder einer Blacklist eines Hauptbuchs hat, und Beispiele für solche Elemente sind hier offenbart. Daher dient die Bezugnahme auf eine Anwendung in der Diskussion des Verfahrens 800 lediglich der Veranschaulichung und soll den Umfang der Erfindung in keiner Weise einschränken.
Zu einem bestimmten Zeitpunkt wird ein Hash der Anwendung notiert (804). Der Hash der Anwendung kann von einem UC berechnet werden, dem UC zur Verfügung gestellt oder aus einer anderen Quelle erhalten werden. Als nächstes kann der UC das Hauptbuch 806 abfragen, um zu sehen, ob das Hauptbuch den Anwendungs-Hash hat, der vom UC gehalten wird. Das Hauptbuch empfängt die Abfrage (808) und sendet einen passenden Hash aus der Whitelist oder der Blacklist an den UC zurück (810). Die Antwort 810 auf die Abfrage 806 kann neben dem Hash auch einen Hinweis darauf enthalten, ob der Hash in der Whitelist oder in der Blacklist gefunden wurde.
Der UC empfängt (812) den Hash und den entsprechenden Whitelist/Blacklist-Hinweis. Wenn die Antwort 810 anzeigt (814), dass der zurückgegebene Hash von der Whitelist stammt, ist der UC sicher, dass die Anwendung, die dem von ihm gehaltenen Hash entspricht, sicher verwendet werden kann, da der zurückgegebene Whitelist-Hash mit dem vom UC gehaltenen Hash übereinstimmt. In diesem Fall kann der UC mit der Ausführung der Anwendung fortfahren (818).
Wird hingegen in der Antwort 810 festgestellt (814), dass der zurückgegebene Hash von der Blacklist stammt, wird der UC davon unterrichtet, dass die Anwendung, die dem von ihm gehaltenen Hash entspricht, möglicherweise nicht sicher in der Verwendung ist, da der zurückgegebene Blacklist-Hash mit dem vom UC gehaltenen Hash übereinstimmt. In diesem Fall kann der UC eine Benachrichtigung oder ein Flag bereitstellen (816), das auf ein potenzielles Problem bei der Nutzung der Anwendung hinweist.
In einigen Fällen kann die Antwort 810 anzeigen, dass der Hash, der Gegenstand der Abfrage 806 war, nicht im Hauptbuch gefunden wurde. In diesem Fall kann der UC ein Flag bereitstellen und die Anwendung, die dem von dem UC gehaltenen Hash entspricht, entweder beenden oder fortsetzen.
Wie die beispielhaften Verfahren 700 und 800 zeigen, können Ausführungsformen der Erfindung die Erstellung eines Hauptbuchs mit einer Whitelist und einer Blacklist beinhalten, die Informationen über Elemente enthalten, die während der Operationen eines UC verwendet werden können. Insbesondere kann der UC die Hauptbuch-Informationen verwenden, um festzustellen, ob bestimmte Elemente sicher zu verwenden sind oder nicht. Da das Hinzufügen von Informationen zum Hauptbuch kontrolliert wird, haben die User eine gewisse Sicherheit, dass die Daten im Hauptbuch vertrauenswürdig und zuverlässig sind. Darüber hinaus ist das Hauptbuch so konfiguriert und implementiert, dass es Informationen aus mehreren unterschiedlichen Quellen empfängt und dadurch die Probleme vermeiden kann, die mit der Verwendung mehrerer unverbundener Datenbanken einhergehen, die möglicherweise ungeprüfte Informationen enthalten.
F. Beispielhafte Rechenvorrichtungen und zugehörige Medien
Die hier offenbarten Ausführungsformen können die Verwendung eines Spezial- oder Universalcomputers mit verschiedenen Computerhardware- oder - softwaremodulen umfassen, wie nachstehend ausführlicher erläutert wird. Ein Computer kann einen Prozessor und Computerspeichermedien enthalten, die Anweisungen tragen, die bei Ausführung durch den Prozessor und/oder bei Veranlassung der Ausführung durch den Prozessor eines oder mehrere der hier offenbarten Verfahren ausführen.
Wie oben erwähnt, umfassen Ausführungsformen im Rahmen der vorliegenden Erfindung auch Computerspeichermedien, die physische Medien sind, die computerausführbare Anweisungen oder Datenstrukturen tragen oder darauf gespeichert haben. Solche Computerspeichermedien können alle verfügbaren physischen Medien sein, auf die ein Universal- oder Spezialcomputer zugreifen kann.
Beispielsweise und ohne darauf beschränkt zu sein können solche Computerspeichermedien Hardwarespeicher, wie zum Beispiel Solid-State-Disk/Device (SSD), RAM, ROM, EEPROM, CD-ROM, Flash-Speicher, Phase-Change-Memory („PCM“) oder andere optische Plattenspeicher, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder irgendwelche anderen Hardwarespeichervorrichtungen umfassen, die verwendet werden können, um Programmcode in Form von computerausführbaren Anweisungen oder Datenstrukturen zu speichern, auf die ein Universal- oder Spezialcomputersystem zugreifen und sie ausführen kann, um die offenbarte Funktionalität der Erfindung zu implementieren. Kombinationen der oben genannten Medien sollten ebenfalls in den Bereich der Computerspeichermedien einbezogen werden. Solche Medien sind auch Beispiele für nichtflüchtige Speichermedien, und nichtflüchtige Speichermedien umfassen auch Cloud-basierte Speichersysteme und - strukturen, obwohl der Umfang der Erfindung nicht auf diese Beispiele für nichtflüchtige Speichermedien beschränkt ist.
Computerausführbare Anweisungen umfassen beispielsweise Anweisungen und Daten, die einen Universalcomputer, einen Spezialcomputer oder eine spezielle Verarbeitungsvorrichtung veranlassen, eine bestimmte Funktion oder eine Gruppe von Funktionen auszuführen. Obwohl der Gegenstand in einer Sprache beschrieben wurde, die für strukturelle Merkmale und/oder methodische Handlungen spezifisch ist, ist der in den beigefügten Ansprüchen definierte Gegenstand nicht notwendigerweise auf die oben beschriebenen spezifischen Merkmale oder Handlungen beschränkt. Vielmehr werden die hierin offenbarten spezifischen Merkmale und Handlungen als beispielhafte Formen der Umsetzung der Ansprüche offenbart.
Wie hierin verwendet, kann sich der Begriff „Modul“ oder „Komponente“ auf Softwareobjekte oder -routinen beziehen, die auf dem Rechensystem ausgeführt werden. Die verschiedenen hier beschriebenen Komponenten, Module, Maschinen (Engines) und Dienste können als Objekte oder Prozesse implementiert werden, die auf dem Rechensystem ausgeführt werden, zum Beispiel als separate Threads. Das hier beschriebene System und die Verfahren können zwar in Software implementiert werden, doch sind auch Implementierungen in Hardware oder eine Kombination aus Software und Hardware möglich und in Betracht zu ziehen. In der vorliegenden Offenbarung kann eine „Recheneinheit/Rechenentität“ ein beliebiges Rechensystem, wie es zuvor hier definiert wurde, oder irgendein Modul oder eine Kombination von Modulen, die auf einem Rechensystem laufen, sein.
Zumindest in einigen Fällen wird ein Hardware-Prozessor bereitgestellt, der ausführbare Anweisungen zur Durchführung eines Verfahrens oder Prozesses, wie die hierin offenbarten Verfahren und Prozesse, ausführen kann. Der Hardware-Prozessor kann, muss aber nicht, ein Element anderer Hardware umfassen, wie zum Beispiel die hierin offenbarten Rechenvorrichtungen und -systeme.
In Bezug auf Computerumgebungen können Ausführungsformen der Erfindung in Client-Server-Umgebungen, in Netzwerk- oder lokalen Umgebungen oder in jeder anderen geeigneten Umgebung ausgeführt werden. Geeignete Betriebsumgebungen für zumindest einige Ausführungsformen der Erfindung umfassen Cloud-Computing-Umgebungen, in denen ein oder mehrere Clients, Server oder andere Maschinen in einer Cloud-Umgebung untergebracht sein und arbeiten können.
Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt werden, ohne von ihrem Geist oder ihren wesentlichen Merkmalen abzuweichen. Die beschriebenen Ausführungsformen sind in jeder Hinsicht nur als illustrativ und nicht einschränkend zu betrachten. Der Umfang der Erfindung ergibt sich daher eher aus den beigefügten Ansprüchen als aus der vorangehenden Beschreibung. Alle Änderungen, die in den Bedeutungs- und Äquivalenzbereich der Ansprüche fallen, sind in deren Umfang einzubeziehen.

Claims

Verfahren, umfassend: Empfangen, von einer Entität, eines vorgeschlagenen Eintrags für ein verteiltes Hauptbuch, wobei das verteilte Hauptbuch von mehreren Usern gemeinsam genutzt wird und für diese zugänglich ist und eine Whitelist und eine Blacklist enthält; Bestimmen oder Zuweisen eines Glaubwürdigkeits-Scores und eines Ratenbegrenzungswerts für die Entität; Vergleichen der Glaubwürdigkeits-Scores und des Ratenbegrenzungswerts mit entsprechenden Schwellenwerten des Glaubwürdigkeits-Scores und des Ratenbegrenzungswerts; Bestimmen, dass der Glaubwürdigkeits-Score und der Ratenbegrenzungswert den jeweiligen Glaubwürdigkeits-Score- und Ratenbegrenzungswert-Schwellenwerten entsprechen oder diese überschreiten; und Übermittlung des vorgeschlagenen Eintrags an das verteilte Hauptbuch.
Verfahren gemäß Anspruch 1, wobei der vorgeschlagene Eintrag entweder als Kandidat für die Whitelist oder als Kandidat für die Blacklist identifiziert wird.
Verfahren gemäß Anspruch 1, wobei das Verfahren von einem Verifikationssystem durchgeführt wird, das eine Glaubwürdigkeits-Score-Engine und eine Ratenbegrenzungs-Engine umfasst.
Verfahren gemäß Anspruch 1, wobei der Glaubwürdigkeits-Score zum Teil auf irgendwelchen früheren Transaktionen, an dem die Entität beteiligt war, basiert.
Verfahren gemäß Anspruch 1, wobei der vorgeschlagene Eintrag der erste ist, der von der Entität bereitgestellt wird, und der Entität ein Standard-Glaubwürdigkeits-Score zugewiesen wird.
Verfahren gemäß Anspruch 1, wobei der Ratenbegrenzungswert eine maximale Anzahl von Eingaben angibt, die die Entität innerhalb eines Zeitraums einer bestimmten Länge vornehmen darf.
Verfahren gemäß Anspruch 1, ferner umfassend: Empfangen, von einer anderen Entität, eines weiteren vorgeschlagenen Eintrags für das verteilte Hauptbuch; Bestimmen, dass ein Glaubwürdigkeits-Score und ein Ratenbegrenzungswert, die mit der anderen Entität verbunden sind, die jeweiligen Glaubwürdigkeits-Score- und Ratenbegrenzungswert-Schwellenwerte für die andere Entität nicht erfüllen; und Zurückweisen des anderen vorgeschlagenen Eintrags in das verteilte Hauptbuch.
Verfahren gemäß Anspruch 7, ferner umfassend das Anpassen des Glaubwürdigkeits-Scores und/oder des Ratenbegrenzungswerts der anderen Entität auf der Grundlage der Feststellung, dass der Glaubwürdigkeits-Score und der Ratenbegrenzungswert der anderen Entität die jeweiligen Glaubwürdigkeits-Score- und Ratenbegrenzungswert-Schwellenwerte für die andere Entität nicht erfüllen.
Verfahren gemäß Anspruch 1, ferner umfassend das Anpassen des Glaubwürdigkeits-Scores und/oder des Ratenbegrenzungswerts auf der Grundlage der Feststellung, dass der Glaubwürdigkeits-Score und der Ratenbegrenzungswert die jeweiligen Glaubwürdigkeits-Score- und Ratenbegrenzungswert-Schwellenwerte erfüllen oder überschreiten.
Verfahren gemäß Anspruch 1, wobei der vorgeschlagene Eintrag eine Datei, eine Website-Adresse, Malware, oder Ransomware identifiziert.
Nichtflüchtiges Speichermedium, in dem Anweisungen gespeichert sind, die von einem oder mehreren Hardware-Prozessoren ausgeführt werden können, um Operationen durchzuführen, die Folgendes umfassen: Empfangen, von einer Entität, eines vorgeschlagenen Eintrags für ein verteiltes Hauptbuch, wobei das verteilte Hauptbuch von mehreren Usern gemeinsam genutzt wird und für diese zugänglich ist und eine Whitelist und eine Blacklist enthält; Bestimmen oder Zuweisen eines Glaubwürdigkeits-Scores und eines Ratenbegrenzungswerts für die Entität; Vergleichen des Glaubwürdigkeits-Scores und des Ratenbegrenzungswerts mit entsprechenden Schwellenwerten des Glaubwürdigkeits-Scores und des Ratenbegrenzungswerts; Bestimmen, dass der Glaubwürdigkeits-Score und der Ratenbegrenzungswert die jeweiligen Glaubwürdigkeits-Score- und Ratenbegrenzungswert-Schwellenwerte erfüllen oder überschreiten; und Übermittlung des vorgeschlagenen Eintrags an das verteilte Hauptbuch.
Nichtflüchtiges Speichermedium gemäß Anspruch 11, wobei der vorgeschlagene Eintrag entweder als Kandidat für die Whitelist oder als Kandidat für die Blacklist identifiziert wird.
Nichtflüchtiges Speichermedium gemäß Anspruch 11, wobei die Operationen von einem Verifikationssystem durchgeführt werden, das eine Glaubwürdigkeits-Score-Engine und eine Ratenbegrenzungs-Engine umfasst.
Nichtflüchtiges Speichermedium gemäß Anspruch 11, wobei der Glaubwürdigkeits-Score zum Teil auf irgendwelchen früheren Transaktionen, an denen die Entität beteiligt war, basiert.
Nichtflüchtiges Speichermedium gemäß Anspruch 11, wobei der vorgeschlagene Eintrag der erste ist, der von der Entität bereitgestellt wird, und der Entität ein Standard-Glaubwürdigkeits-Score zugewiesen wird.
Nichtflüchtiges Speichermedium gemäß Anspruch 11, wobei der Ratenbegrenzungswert eine maximale Anzahl von Eingaben spezifiziert, die die Entität innerhalb eines Zeitraums einer bestimmten Länge vornehmen darf.
Nichtflüchtiges Speichermedium gemäß Anspruch 11, wobei die Operationen ferner Folgendes umfassen: Empfangen, von einer anderen Entität, eines weiteren vorgeschlagenen Eintrags für das verteilte Hauptbuch; Bestimmen, dass ein Glaubwürdigkeits-Score und ein Ratenbegrenzungswert, die mit der anderen Entität verbunden sind, nicht die jeweiligen Schwellenwerte des Glaubwürdigkeits-Scores und Ratenbegrenzungswerts für die andere Entität erfüllen; und Zurückweisen des anderen vorgeschlagenen Eintrags in das verteilte Hauptbuch.
Nichtflüchtiges Speichermedium gemäß Anspruch 7, wobei die Operationen ferner das Anpassen des Glaubwürdigkeits-Scores und/oder des Ratenbegrenzungswerts der anderen Entität auf der Grundlage der Feststellung, dass der Glaubwürdigkeits-Score und der Ratenbegrenzungswert der anderen Entität die jeweiligen Glaubwürdigkeits-Score- und Ratenbegrenzungswert-Schwellenwerte für die andere Entität nicht erfüllen, umfassen.
Nichtflüchtiges Speichermedium gemäß Anspruch 11, wobei die Operationen ferner das Anpassen des Glaubwürdigkeits-Scores und/oder des Ratenbegrenzungswerts auf der Grundlage der Feststellung, dass der Glaubwürdigkeits-Score und der Ratenbegrenzungswert die jeweiligen Glaubwürdigkeits-Score- und Ratenbegrenzungswert-Schwellenwerte erfüllen oder überschreiten, umfassen.
Nichtflüchtiges Speichermedium gemäß Anspruch 11, wobei der vorgeschlagene Eintrag eine Datei, eine Website-Adresse, Malware, oder Ransomware identifiziert.