DE112019006673T5

DE112019006673T5 - Schutz vor datenverlust

Info

Publication number: DE112019006673T5
Application number: DE112019006673.0T
Authority: DE
Inventors: Assaf Natanzon
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2019-01-17
Filing date: 2019-10-03
Publication date: 2021-10-14
Also published as: CN113330714A; WO2020149899A1; US20200234375A1; GB2594879A; GB2594879B; GB202110717D0

Abstract

Es werden Systeme, Vorrichtungen und Verfahren zum Schutz von Daten, die in einer Cloud oder einem anderen Speicher gespeichert sind, bereitgestellt. Ein verteiltes Hauptbuch (distributed Ledger) wird verwendet, um Transaktionen zwischen einem Client und einem Objektspeicher aufzuzeichnen. Das verteilte Hauptbuch zeichnet die Transaktion auf und bestätigt auch die Authentizität des Objekts. So können die Transaktionen verifiziert werden und können bei der Lösung von Problemen helfen, die in Bezug auf die gespeicherten Objekte auftreten. Das Hauptbuch und die darin enthaltenen Einträge ermöglichen es, das mit den Daten verbundene Verlustrisiko zu bewerten und die Daten gegen Verlust und/oder für die Haftung zu versichern.

Description

BEREICH DER ERFINDUNG
Ausführungsformen der vorliegenden Erfindung betreffen Systeme und Verfahren zum Schutz von Daten und zur Durchführung von Datenschutzoperationen einschließlich der Versicherung von Daten. Insbesondere betreffen Ausführungsformen der Erfindung Systeme und Verfahren zur Speicherung von Objekten mit bestätigtem Inhalt zur Speicherung und Aufbewahrung. Ausführungsformen der Erfindung betreffen ferner Systeme, Vorrichtungen und Verfahren zum Versichern von Daten, die in der Cloud gespeichert sind.
HINTERGRUND
Hauptbuch-basierte verteilte Technologien sind aus verschiedenen Gründen weit verbreitet. Allerdings bestehen bei Hauptbuch-basierten Technologien immer noch Probleme. Beispielsweise besteht eines der Probleme beim Speichern von Objekten (z.B. Daten, Dateien, Inhalten) in einem Cloud-System darin, dass es bei der Verwendung herkömmlicher Hauptbücher keine Sicherheit gibt, dass das Objekt nicht manipuliert wurde. Obwohl Signaturen und Fehlerkorrekturcodes verwendet werden können, um beschädigte Objekte zu erkennen, kann der Cloud-Provider behaupten, dass die Beschädigung des Objekts nicht sein Fehler war und dass der Benutzer das Objekt in einer beschädigten Form gespeichert hat.
Insbesondere gibt es keine Garantie, dass Objekte, die in einem Cloud-Speicher gespeichert oder aufbewahrt werden, in identischer Form zurückgegeben werden. Mit anderen Worten, es gibt keine Garantie, dass ein aus dem Cloud-System gelesenes Objekt mit dem Objekt identisch ist, das in das Cloud-System geschrieben wurde. Zum Beispiel kann ein Benutzer ein Objekt in dem Cloud-System speichern. Wenn derselbe Benutzer das Objekt später liest, kann ein anderes Objekt von dem Cloud-System zurückgegeben werden. Der Benutzer kann nicht beweisen, dass die aus der Cloud zurückgegebenen Daten sich von dem Objekt unterscheiden, das ursprünglich in der Cloud gespeichert wurde. Der Benutzer kann nicht beweisen, dass das Objekt in der Cloud beschädigt wurde, und die Cloud kann nicht beweisen, dass das Objekt nicht in der Cloud beschädigt wurde.
Mit anderen Worten, wann immer ein Problem mit einem Objekt auftritt, das in ein Cloud-System hochgeladen und dort gespeichert wurde, ist es sehr schwierig, festzustellen, wie und wann das Problem aufgetreten ist. Wie bereits erwähnt, kann der Benutzer behaupten, dass das Objekt durch das Cloud-System beschädigt wurde, und das Cloud-System kann behaupten, dass der Benutzer ein beschädigtes Objekt gespeichert hat.
Ähnliche Probleme können in Bezug auf Objekte auftreten, die gelöscht oder nicht gelöscht wurden. Zum Beispiel kann ein Benutzer ein Objekt anfordern, nur um festzustellen, dass das Objekt nicht mehr existiert. In diesem Fall kann der Benutzer nicht nachweisen, dass kein Löschbefehl erteilt wurde. Außerdem ist die Cloud nicht vor einem Benutzer geschützt, der ein Objekt löscht, nur um es zu einem späteren Zeitpunkt anzufordern. In einem anderen Beispiel hat der Benutzer keine Sicherheit, dass das Cloud-System einem Löschbefehl nachkommt. Dies ist besonders relevant bei einigen Vorschriften (wie zum Beispiel GDPRs „Recht auf Vergessenwerden“, DMCA-Takedown), die die Vernichtung bestimmter Objekte oder Daten verlangen. Der Benutzer hat möglicherweise Schritte unternommen, um das Objekt zu zerstören, aber das Cloud-System hat das Objekt nicht tatsächlich zerstört, wodurch der Benutzer möglicherweise haftbar gemacht werden kann. Auch wenn die Wahrscheinlichkeit eines Datenverlusts in der Cloud sehr gering ist, handelt es sich hierbei um einen theoretischen Wert, und Katastrophen können immer noch passieren. Derzeit gibt es keine Garantie, dass Daten in der Cloud niemals verloren gehen oder beschädigt werden. Folglich ist die Versicherung der Daten gegen Verlust oder Beschädigung sehr schwierig, auch weil das Risiko des Datenverlusts von Versicherungsträgern nicht abgeschätzt werden kann.
Figurenliste
Um die Art und Weise zu beschreiben, in der zumindest einige Aspekte dieser Offenbarung erreicht werden können, wird eine genauere Beschreibung durch Bezugnahme auf spezifische Ausführungsformen davon gegeben, die in den beigefügten Zeichnungen dargestellt sind. In dem Verständnis, dass diese Zeichnungen nur beispielhafte Ausführungsformen der Erfindung darstellen und daher nicht als Einschränkung ihres Umfangs anzusehen sind, werden Ausführungsformen der Erfindung mit zusätzlicher Spezifität und Detailgenauigkeit mit Hilfe der beigefügten Zeichnungen beschrieben und erläutert, in denen:

1 ein Beispiel für ein System mit einem verteilten Hauptbuch (distributed Ledger) zum Speichern von Objekten und zum Garantieren von Inhalten zur Datensicherung und Aufbewahrung veranschaulicht;
2 ein Beispiel für ein verteiltes Hauptbuch, das Transaktionen aufzeichnet und Objekte bescheinigt, die mit den aufgezeichneten Transaktionen in Beziehung stehen, veranschaulicht;
3 ein Beispiel für ein Verfahren zum Schreiben eines Objekts in einen Objektspeicher unter Verwendung eines verteilten Hauptbuchs veranschaulicht;
4 ein Beispiel für ein Verfahren zum Lesen eines Objekts aus einem Objektspeicher unter Verwendung eines verteilten Hauptbuchs veranschaulicht;
5 ein Beispiel für ein Verfahren zum Löschen eines Objekts aus einem Objektspeicher unter Verwendung eines verteilten Hauptbuchs veranschaulicht;
6 ein Beispiel für ein System mit einem verteilten Hauptbuch zum Speichern von Daten und zum Versichern der gespeicherten Daten veranschaulicht; und
7 ein Beispiel für ein Verfahren zum Versichern von Daten, die in der Cloud gespeichert sind, veranschaulicht.

DETAILLIERTE BESCHREIBUNG EINIGER BEISPIELHAFTER AUSFÜHRUNGSFORMEN
Ausführungsformen der Erfindung betreffen Systeme und Verfahren zum Schutz von Daten, die zum Beispiel in einem Speicher, wie beispielsweise einem Cloud-Objektspeicher (z.B. AWS S3) oder einem Cloud-Speicher oder -System gespeichert sind. Ausführungsformen der Erfindung betreffen ferner das Versichern von Objekten, die in einem Speicher, wie zum Beispiel einem Objektspeicher, gespeichert sind. Ein Cloud-Objektspeicher kann als Cloud oder als Cloud-System bezeichnet werden. Ein Rechenzentrum oder ein verteiltes Rechenzentrum, das Hardware zum Speichern von Objekten umfasst, kann ein Beispiel für einen Cloud-Objektspeicher sein. Der Cloud-Objektspeicher kann, nur als Beispiel, eine öffentliche Cloud, eine private Cloud oder eine hybride Cloud sein. Daten können allgemein verwendet werden und können als Objekt, Datenobjekt oder in einer anderen geeigneten Form bezeichnet werden.
Ausführungsformen der Erfindung betreffen ferner das Speichern von Objekten in einer Weise, die gewährleistet, dass die Objekte, die in den Cloud-Objektspeicher (hier als Cloud oder Cloud-Speicher bezeichnet) geschrieben werden, so zurückgegeben werden, wie sie ursprünglich geschrieben wurden, oder dass das Objekt in Übereinstimmung mit einem Löschbefehl gelöscht wird. Ausführungsformen der Erfindung betreffen ferner das Versichern der Daten gegen Verlust. Ausführungsformen der Erfindung ermöglichen es, Objekte in der Cloud in einer Weise zu speichern, die es einem Versicherer ermöglicht, das Risiko zu bewerten und eine Police für die Objekte auszustellen.
Wenn die Gewährleistung gebrochen ist (z.B. die Daten sind beschädigt, fehlen, sind nicht gelöscht), ermöglichen Ausführungsformen der Erfindung die Bestimmung der Ursache des Problems mit dem Objekt und ermöglichen die Bereitstellung geeigneter Abhilfemaßnahmen. Des Weiteren können die Daten versichert werden, so dass in einem Fall, in dem die Daten nicht wiederhergestellt werden können oder das Problem mit den Daten nicht zufriedenstellend gelöst werden kann, der Eigentümer vor Verlust geschützt werden kann und der Speicher-Provider vor Haftung geschützt werden kann. Ausführungsformen der Erfindung ermöglichen es Speicher-Providern und/oder Eigentümern von Daten, sich gegen Verlust oder andere Probleme mit Daten, wie zum Beispiel Zugänglichkeit und dergleichen, zu versichern.
Daten sind für die Operationen eines Unternehmens oder Benutzers von entscheidender Bedeutung und haben oft einen direkten Einfluss auf die Einnahmen. Jedes Unternehmen, das seine Daten nicht sichert, riskiert einen erheblichen Verlust. Insbesondere kann, weil die Daten für das Unternehmen wertvoll sind, der Verlust der Daten einen erheblichen Verlust in Form von mindestens Zeit und/oder Einnahmen verursachen. Diese Offenbarung beschreibt, wie ein Vertrag zwischen einem Unternehmen oder Benutzerdaten und einem Speicher-Provider in Bezug auf die Daten des Unternehmens erstellt werden kann. Ausführungsformen der Erfindung nutzen diesen Vertrag, um es Versicherungsgesellschaften zu ermöglichen, die Daten zu versichern. Der Vertrag ermöglicht es der Versicherungsgesellschaft, das Risiko abzuschätzen und eine Police für die Daten auszustellen. Die Police kann für bestimmte Daten oder Datenobjekte, für Datencontainer oder andere Datenspeicheranordnungen ausgestellt werden.
Wenn beispielsweise das Objekt nicht in dem Zustand aus dem Datenspeicher zurückgegeben wird, in dem es ursprünglich in den Datenspeicher geschrieben wurde (z.B. in einem beschädigten oder teilweise beschädigten Zustand), oder wenn das Objekt nicht gemäß einem Löschbefehl gelöscht wird, ermöglichen Ausführungsformen der Erfindung die Überprüfung der Transaktion und die Bestimmung des Fehlers. Dies wird zum Beispiel mit Hilfe von Smart Contracts und/oder Hauptbüchern erreicht. Ausführungsformen der Erfindung ermöglichen somit zum Beispiel die Verwendung eines Cloud-Objektspeichers als Datensicherung (Backup) oder zu Sicherungszwecken und ermöglichen die Aufbewahrung und Verwaltung von Objekten in einem Cloud-Objektspeicher. Die Smart Contracts und/oder Hauptbücher ermöglichen es, dass die betreffende Person/das Unternehmen für einen Verlust auf der Grundlage einer Versicherungspolice entschädigt wird, sobald ein Verlust oder andere Zustände festgestellt werden.
Ausführungsformen der Erfindung betreffen ferner ein verteiltes Hauptbuch (distributed Ledger), das den Lebenszyklus oder den Status von Objekten verwaltet, die in dem Cloud-Objektspeicher gespeichert sind. Ein Hauptbuch oder ein verteiltes Hauptbuch kann als eine Datenbank oder eine verteilte Datenbank ausgeführt sein, die es erlaubt, Transaktionen darin zu notieren (aufzuzeichnen) oder zu speichern. Ein verteiltes Hauptbuch kann Daten enthalten, die über mehrere Stellen hinweg repliziert, gemeinsam genutzt und/oder synchronisiert werden, oder aus diesen bestehen. In einigen Beispielen kann ein verteiltes Hauptbuch keinen zentralisierten Administrator haben.
Das verteilte Hauptbuch, in Übereinstimmung mit Ausführungsformen der Erfindung, bestätigt das Objekt selbst zusätzlich zu oder in Verbindung mit der Aufzeichnung einer Transaktion, die mit dem Objekt verbunden ist. So kann das Hauptbuch zusätzlich zu der Angabe, dass das Objekt Y im Cloud-Objektspeicher gespeichert wurde, auch einen Identifikator (z.B. einen Hash) enthalten, mit dem die Integrität des Objekts überprüft werden kann. Somit bestätigt das Hauptbuch das Objekt selbst und bestätigt den Inhalt des Objekts, indem es den Hash des Objekts speichert.
In einem Beispiel können Einträge im Hauptbuch mithilfe von Smart Contracts vorgenommen werden. Ein Smart Contract ist ein Protokoll, mit dem die Aushandlung oder Erfüllung eines Vertrags digital erleichtert, verifiziert oder durchgesetzt werden kann. Ein Smart Contract kann die Verwendung von privaten/öffentlichen Schlüsseln beinhalten. So kann zum Beispiel ein Eintrag in einem Hauptbuch, der mit einem privaten Schlüssel vorgenommen wurde, mit dem entsprechenden öffentlichen Schlüssel bestätigt werden. Auf diese Weise kann die Identität eines Benutzers bestätigt werden, und Verträge können in einem Computerkontext gültig sein. Mit Smart Contracts werden Einträge im verteilten Hauptbuch gültig und durchsetzbar.
Ausführungsformen der Erfindung ermöglichen die Aufzeichnung von Transaktionen und erlauben es auch, die Integrität des Objekts zumindest anfänglich zu gewährleisten. Wenn ein Objekt nachträglich beschädigt wird oder nicht im Datenspeicher vorhanden ist, oder wenn ein Befehl, der sich auf das Objekt bezieht, nicht oder ohne Berechtigung ausgeführt wird, erlaubt das verteilte Hauptbuch dem Client und der Cloud zu bestimmen, wer die Verantwortung trägt. Durch die Fähigkeit, Fehler zu bewerten, die Fähigkeit, festzustellen, dass Objekte erfolgreich und korrekt in der Cloud gespeichert wurden, die Fähigkeit, festzustellen, dass Aktionen, die angeblich vom Benutzer/Cloud-Provider durchgeführt wurden, tatsächlich durchgeführt wurden, auf der Grundlage des verteilten Hauptbuchs, wird es ermöglicht, Risiken zu bewerten und die Daten zu versichern.
Beim Speichern eines Objekts (z.B. beim Schreiben eines Objekts in einen Cloud-Objektspeicher) kann ein Client (oder der Benutzer) beispielsweise Informationen zu einem verteilten Hauptbuch hinzufügen, dass ein Objekt in den Objektspeicher geschrieben wurde. Der Client kann auch eine Signatur des Objekts angeben oder bereitstellen (z.B. eine Hash-Signatur oder einen Fingerabdruck, der das Objekt eindeutig identifiziert). Der Client kann auch den Fingerabdruck und/oder das Objekt digital signieren, um einen Smart Contract zu erleichtern. Der Client oder Benutzer kann auch eine Aufbewahrungsrichtlinie für das Objekt (wie lange das Objekt verfügbar bleiben muss) und Verfügbarkeitsanforderungen (z.B. 99,999 %) angeben oder definieren. Diese können Teil eines Vertrags oder einer Vereinbarung sein, die in Bezug auf das Objekt zwischen dem Client (z.B. einem Benutzer oder einem Unternehmen) und einem Speicher-Provider geschlossen wird.
Wenn das Objekt im Cloud-Objektspeicher gespeichert wird, wird das Cloud-System (oder der Cloud-Provider) über die Hauptbuch-Transaktion informiert. Als Antwort bestätigt das Cloud-System, dass das Objekt empfangen wurde und dass die Signatur des Objekts, wie sie im Hauptbuch festgelegt ist, korrekt ist. Zum Beispiel kann der Cloud-Speicher auch einen Hash (den gleichen Hash, den der Client durchgeführt hat) an dem Objekt durchführen, um zu verifizieren, dass das empfangene Objekt das Objekt ist, das vorgeblich von einem Client hochgeladen wurde. Die Cloud kann auch den Aufbewahrungs- und Verfügbarkeitsanforderungen (und/oder anderen Anforderungen) zustimmen. Selbstverständlich kann der Cloud-Speicher die Anforderung oder die Benachrichtigung über die Hauptbuch-Transaktion auch ignorieren oder ablehnen. Auf diese Weise kann sowohl der Client wissen, dass das Cloud-System das richtige Objekt und nicht ein beschädigtes Objekt erhalten hat, als auch das Cloud-System überprüfen, was tatsächlich vom Client hochgeladen wurde.
Wenn der Cloud-Speicher die Transaktion akzeptiert, wird durch die Speicherung des Objekts im Cloud-Objektspeicher sichergestellt, dass die Bedingungen, die in der im verteilten Hauptbuch aufgezeichneten Transaktion festgelegt sind, eingehalten werden, und es kann ein Smart Contract geschlossen werden. Der Cloud-Provider kann sogar zustimmen, eine Geldstrafe zu zahlen oder eine andere Entschädigung oder Abhilfe zu leisten, wenn das Objekt nicht gemäß den Verfügbarkeitsanforderungen verfügbar ist oder wenn sich das Objekt später als beschädigt herausstellt. In einem Beispiel kann das Objekt mit einem Schlüssel verschlüsselt werden, der nur dem Client oder Benutzer bekannt ist. Beim Akzeptieren der Transaktion kann der Cloud-Provider den Hash des verschlüsselten Objekts prüfen. Der Hash eines verschlüsselten Objekts kann verwendet werden, um zu überprüfen, ob das verschlüsselte Objekt in der Cloud beschädigt wurde. Ein ähnliches Verfahren kann für Objekte durchgeführt werden, die nicht verschlüsselt sind. Mit anderen Worten: Ausführungsformen der Erfindung können unabhängig davon durchgeführt werden, ob das Objekt verschlüsselt ist oder nicht.
Beim Lesen eines Objekts aus dem Cloud-Speicher kann ein Client das Objekt aus dem Cloud-Objektspeicher und die zugehörige Transaktion aus dem Hauptbuch lesen, in dem auch das Hash-Verfahren spezifiziert sein kann. Der Client kann den Hash des gelesenen Objekts berechnen oder bestimmen, um festzustellen, ob das gelesene Objekt beschädigt ist oder sich von dem im Hauptbuch wiedergegebenen Objekt unterscheidet. Wenn das Objekt nicht existiert oder wenn der Client feststellt, dass das wiedergeholte Objekt nicht mit dem Objekt identisch ist, das in den Cloud-Speicher geschrieben wurde, kann der Client oder Benutzer eine Entschädigung oder andere Abhilfe erhalten.
In einem Beispiel kann eine vertrauenswürdige Drittpartei („trusted third party“) als Schiedsrichter eingesetzt werden. Die Drittpartei kann Zugriff auf den Cloud-Objektspeicher des Benutzers oder Clients und das Hauptbuch erhalten. Eine Anwendungsprogrammierschnittstelle (Application Programming Interface; API) kann verwendet werden, um das Objekt aus dem Cloud-Objektspeicher zu lesen und zu prüfen, ob das Objekt tatsächlich fehlt oder beschädigt ist. Wenn der Drittanbieterdienst feststellt, dass die Service-Level-Vereinbarung (Service Level Agreement; SLA) für das Objekt nicht erfüllt ist, kann der Cloud-Provider verpflichtet werden, eine vorher festgelegte Abhilfe gemäß der Vereinbarung zu schaffen. Wie im Folgenden näher erläutert, kann ein Objekt auch versichert werden.
Beim Löschen eines Objekts kann ein Client (oder der Benutzer) den Cloud-Speicher auffordern, ein Objekt zu löschen, indem er eine Löschanforderung im Hauptbuch zusammen mit dem Identifikator oder Hash des Objekts platziert. In einer Ausführungsform kann das Hauptbuch verwendet werden, um Anforderungen an den Cloud-Speicher zu stellen. Das Hauptbuch kann somit als eine Liste von auszuführenden Aktionen dienen. Alternativ kann das Hauptbuch so konfiguriert sein, dass es Transaktionen aufzeichnet, wenn sie auftreten. Es kann mehr als ein Hauptbuch verwendet werden.
In einem Beispiel kann eine Anforderung an die Cloud von der Benutzeroberfläche automatisch im Hauptbuch aufgezeichnet werden.
Der Client kann gleichzeitig mit der Aufzeichnung des Löschbefehls im Hauptbuch den Cloud-Speicher auffordern, das Objekt zu löschen (z.B. durch Auswählen eines Objekts und Drücken von „löschen“ oder durch Ziehen des Objekts in einen Papierkorb oder auf andere Weise). Nach dem Löschen des Objekts wird der Cloud-Speicher im Hauptbuch bestätigen, dass das Objekt gelöscht wurde. Dies stellt sicher, dass der Client nicht versucht, gelöschte Objekte zu lesen und stellt sicher, dass gelöschte Objekte gelöscht sind (zumindest aus Sicht des Clients), was einen Benutzer von der Haftung befreien kann. In einer Ausführungsform kann die Cloud das Hauptbuch asynchron auf Löschanforderungen prüfen (z.B. wenn ein Löschbefehl nicht spezifisch vom Cloud-Speicher empfangen wird) oder asynchron auf Befehle prüfen und solche Objekte löschen, auch wenn der Befehl oder die Anforderung nicht vom Benutzer kam.
Ausführungsformen der Erfindung können ein verteiltes Hauptbuch (distributed Ledger) und/oder eine digitale Währung verwenden, um eine Versicherung für die Daten zu erstellen. Es können jedoch auch andere Zahlungsmodalitäten verwendet werden. Das Versichern von Daten, die in einem Speichersystem gespeichert sind, das ein Cloudbasiertes Speichersystem sein kann, kann das Speichern einer Kopie der Daten in dem Speichersystem, das Unterzeichnen oder Ausführen eines Vertrags zwischen dem Speichersystem (z.B. dem Cloud-Provider) und dem Client (z.B. dem Benutzer) und dann das Versichern der Daten umfassen.
Insbesondere wird ein Cloud-Speicher oft verwendet, um Datensicherungen zu speichern. Alternativ können einige Cloud-basierte Daten auch als Produktionsdaten verwendet werden. Ausführungsformen der Erfindung können Daten im Zusammenhang mit der Erstellung einer Sicherung von Daten versichern. Anfänglich können Datenobjekte in der Cloud oder in einem Cloud-Speicher gespeichert werden. Wie bereits erwähnt, sind die Sicherungsdaten für den Client nur dann von Nutzen, wenn die Daten erfolgreich aus dem Cloud-Speicher extrahiert werden können. Wenn die Daten beschädigt sind oder fehlen, ist die Sicherung nicht sehr nützlich. In einem Beispiel können sich der Client und der Cloud-Speicher auf einen Hash- oder anderen Identifikationsalgorithmus einigen. Der Benutzer kann eine Liste von Hash-Werten oder anderen Identifikatoren für alle Datenobjekte bereitstellen, die mit einer Datensicherung verbunden sind. In einem Beispiel können alle diese Hash-Werte kombiniert (z.B. konkatiniert) und ein einziger Hash-Wert aus den kombinierten Hash-Werten erzeugt werden. Auf diese Weise kann ein einziger Hash-Wert für die Sicherung oder den durchgeführten Sicherungsvorgang generiert werden. Dieser einzige Hash ermöglicht es dem Client und dem Cloud-Speicher zu verifizieren, dass die im Cloud-Speicher gespeicherten Objekte mit den in den Cloud-Speicher hochgeladenen Objekten übereinstimmen. Außerdem können so bestimmte Datenobjekte ausgewertet werden, z.B. im Falle eines teilweisen Verlusts oder einer teilweisen Beschädigung.
Nachdem die Daten im Cloud-Speicher gespeichert sind, kann ein Vertrag (Contract) zwischen dem Cloud-Speicher und dem Client unterzeichnet oder geschlossen werden. Der Client kann den Auftrag in den Objektspeicher hochladen, wie zuvor beschrieben. Dies ermöglicht es sowohl dem Client als auch dem Cloud-Speicher, die Hash-Werte der Objekte und den einzelnen Hash der kombinierten Hash-Werte unabhängig voneinander zu berechnen. Als nächstes kann der Client den einzelnen Hash des kombinierten Hashs für den Auftrag in das Hauptbuch eingeben. Der Cloud-Speicher oder Provider kann dann auf den Hauptbuch-Eintrag zugreifen und verifizieren, dass die Objekte tatsächlich erfolgreich empfangen wurden, indem er den vom Cloud-Speicher generierten einzelnen Hash mit dem vom Client bereitgestellten Hash-Wert vergleicht. Diese Verifizierung kann zum Hauptbuch hinzugefügt werden.
Dadurch kann ein Vertrag unter Verwendung des Hauptbuchs unterzeichnet werden. Im Zusammenhang mit einem Sicherungsvorgang kann der Vertrag auch eine Aufbewahrungsrichtlinie aufweisen, die festlegt, dass die Daten nicht geändert oder gelöscht werden können. Andere Aufbewahrungsrichtlinien, Zugriffsanforderungen usw. können ebenfalls im Vertrag festgelegt werden, der im Hauptbuch wiedergegeben wird.
Als nächstes können die Daten versichert werden. Eine Versicherungsgesellschaft kann die Daten im Hauptbuch (z.B. die vom Client und/oder dem Cloud-Speicher vorgenommenen Einträge) lesen, die den Vertrag oder die Transaktionen widerspiegeln, die zwischen dem Client und dem Cloud-Speicher stattgefunden haben. Die Versicherungsgesellschaft kann möglicherweise auch die Aufbewahrungsrichtlinie, die Verfügbarkeit des Cloud-Speichers (die vom Cloud-Speicher-Provider veröffentlicht werden kann) und dergleichen erkennen. Nachdem die Versicherungsgesellschaft diese Faktoren erfasst und erkannt hat, kann sie den Client oder Benutzer zumindest gegen Datenverlust versichern, da das Risiko besser eingeschätzt werden kann. Die Versicherungsgesellschaft kann einen Preis festlegen. Als nächstes kann die Police auch einen Eintrag im Hauptbuch darstellen, der in den Einträgen des Sicherungsvorgangs oder eines anderen Speichervorgangs enthalten oder mit ihnen verbunden ist. Die Zahlung kann mit einer digitalen Währung oder einer anderen Zahlungsmethode erfolgen.
1 ist ein Blockdiagramm, das ein Beispiel für eine Computerumgebung zeigt, in der Ausführungsformen der Erfindung implementiert sein können. In 1 ist ein Client 102 dargestellt. Der Client 102 kann eine Rechenvorrichtung sein, wie zum Beispiel ein Computer, ein Tablet-Gerät, ein Smartphone oder dergleichen, und kann einen Prozessor, einen Speicher und andere Schaltungen umfassen. Der Client 102 kann mit einem Cloud-Objektspeicher 104 oder damit verbundenen Servern über ein Netzwerk, wie zum Beispiel das Internet, kommunizieren. Der Cloud-Objektspeicher 104 kann Objekte von mehreren Clients speichern und kann verschiedene Speichervorrichtungen umfassen. Der Cloud-Objektspeicher 104 kann ein Rechenzentrum, eine Sammlung von Rechenzentren oder eine andere Sammlung von Prozessoren, Speichern und anderer Hardware und Schaltungen, wie zum Beispiel Switches, Hardwareschnittstellen usw., sein.
In diesem Beispiel speichert der Client 102 ein Objekt 108 in dem Cloud-Objektspeicher 104. Das Objekt 108 ist als Objekt 108a und Objekt 108b dargestellt. Das Objekt 108a repräsentiert das Objekt, wie es vom Client 102 in den Cloud-Objektspeicher 104 geschrieben oder hochgeladen wird. Das Objekt 108b repräsentiert das Objekt 108, wie es im Cloud-Objektspeicher 104 gespeichert ist. Idealerweise ist das Objekt 108b identisch mit dem Objekt 108a. Das Objekt 108 kann eine einzelne Datei, eine gesamte Datensicherung, eine Vielzahl von Dateien oder Objekten, ein Container oder eine Sammlung von Containern oder dergleichen oder eine Kombination davon sein.
Ausführungsformen der Erfindung stellen sicher, dass das Objekt 108b mit dem Objekt 108a identisch ist, und stellen sicher, dass im Falle einer Abweichung die fehlerhafte Entität identifiziert werden kann. Ausführungsformen der Erfindung erleichtern auch die Versicherung gegen partiellen Datenverlust, da die erfolgreiche Speicherung des Objekts durch Prüfung des Hauptbuchs verifiziert werden kann. Das Risiko wird bewertet, weil die Versicherungsgesellschaft weiß, dass sowohl der Client als auch der Cloud-Speicher sich einig sind, dass das Datenobjekt erfolgreich im Cloud-Speicher gespeichert wurde. Dies wird beispielsweise mit einem Hauptbuch 106 erreicht, das ein vertrauenswürdiges oder nicht vertrauenswürdiges verteiltes Hauptbuch (distributed Ledger) sein kann. Das Hauptbuch 106 kann zum Beispiel eine verteilte Datenbank sein.
Das Hauptbuch 106 zeichnet nicht nur auf, dass eine Transaktion stattgefunden hat (z.B. Client 102 hat Objekt 108 in den Cloud-Objektspeicher 104 geschrieben), sondern zeichnet auch Informationen auf, die es erlauben, das Objekt und seinen Zustand (z.B. beschädigt, sicher, fehlend) im Cloud-Objektspeicher 104 zu bestimmen. Das Hauptbuch 106 verhindert vorteilhafterweise zumindest einige potenziell betrügerische Aktivitäten.
Insbesondere kann das Hauptbuch für eine bestimmte Transaktion Informationen sowohl vom Client 102 (und/oder dem Benutzer) als auch vom Cloud-Objektspeicher 104 (dem Cloud-Provider) enthalten. Das Hauptbuch enthält die Transaktion und ermöglicht es, die Transaktion zu verifizieren, gültig und/oder durchsetzbar zu machen. Neben der Bestätigung, dass eine Transaktion stattgefunden hat, oder der Aufzeichnung einer Transaktion (Schreiben, Lesen, Ändern, Löschen, Verschieben usw.) ermöglichen es Ausführungsformen der Erfindung sowohl dem Client 102 als auch dem Cloud-Objektspeicher 104, die Transaktion zu bestätigen und den Zustand des Objekts zu bestätigen und möglicherweise verschiedenen Verpflichtungen bezüglich des Objekts 108 zuzustimmen. Dies kann unter Verwendung eines Smart Contracts erreicht werden.
In einem Beispiel erlaubt das Hauptbuch 106 dem Cloud-Objektspeicher 104 effektiv zu verifizieren, dass das Objekt 108b mit dem Objekt 108a identisch ist. Sowohl der Client 102 als auch der Cloud-Objektspeicher 104 können einen Eintrag im Hauptbuch 106 vornehmen, der sich auf die Transaktion bezieht, oder können Informationen in die relevanten Hauptbuch-Einträge eingeben. Wie hier besprochen, kann der Client 102 anzeigen, dass eine Transaktion in Bezug auf ein Objekt durchgeführt wurde, und kann einen Identifikator des Objekts 108 identifizieren oder bereitstellen. Der Cloud-Objektspeicher 104 kann einen Eintrag in das Hauptbuch 106 vornehmen, der bestätigt, dass das Objekt 108 empfangen wurde und dass das empfangene Objekt das hochgeladene Objekt ist. Dies wird durch Verwendung eines Fingerabdrucks oder eines anderen Identifikators des Objekts, wie z.B. einen Hash, erreicht. Wenn der Cloud-Objektspeicher 104 einen Fingerabdruck des Objekts generiert, der mit dem vom Client 102 bereitgestellten Fingerabdruck übereinstimmt, ist das Objekt 108a das gleiche wie das Objekt 108b, und sowohl der Client 102 als auch der Cloud-Objektspeicher 104 wissen, dass das Objekt erfolgreich vom Cloud-Objektspeicher 104 empfangen wurde. Dies verhindert effektiv, dass der Cloud-Objektspeicher 104 behauptet, dass ein beschädigtes Objekt 108 hochgeladen wurde, und verhindert, dass der Client 102 behauptet (oder erlaubt dem Client 102, zu einem späteren Zeitpunkt zu behaupten), dass das Objekt im Cloud-Objektspeicher 104 beschädigt wurde.
2 zeigt ein Beispiel für ein Hauptbuch 206, das von einem Client 202 und einem Cloud-Objektspeicher 204 verwendet wird. Das Hauptbuch 206 speichert Transaktionen, die Smart Contracts enthalten können. Jede Transaktion kann eine Aufzeichnung einer Aktion enthalten, die in Bezug auf den Client 202 und den Cloud-Objektspeicher 204 durchgeführt wurde. Transaktionen oder Einträge können gruppiert werden. Eine beispielhafte Transaktion 210 enthält Informationen, wie zum Beispiel eine Aktion 212 (z.B. Lesen, Schreiben, Löschen, Kopieren usw.), einen Identifikator 214 und/oder eine Vereinbarung 216.
Der Identifikator 214 kann einen Identifikator (z.B. einen Hash oder einen anderen Fingerabdruck) des Objekts 218 umfassen. Zum Beispiel kann der Client 202 einen Hash des Objekts 218 erzeugen und den Hash in der Transaktion 210 aufzeichnen. Der Cloud-Objektspeicher 204 kann nach dem Empfang des Objekts 218 den Identifikator aus dem Objekt generieren, indem er z.B. denselben Hash durchführt. Wenn der vom Cloud-Objektspeicher 204 generierte Hash mit dem vom Client 202 bereitgestellten Hash übereinstimmt, dann wissen sowohl der Client 202 als auch der Cloud-Objektspeicher 204, dass das im Cloud-Objektspeicher 204 gespeicherte Objekt 218 mit dem vom Client 202 hochgeladenen Objekt identisch ist. Dies wird im Hauptbuch 208 weiter bestätigt. Zum Beispiel kann die Transaktion 210 Platz für Bestätigungen oder Signaturen oder andere Hinweise auf die Bestätigung oder Vereinbarung enthalten.
In einem Beispiel kann die Vereinbarung 216 eine Bestätigung vom Cloud-Objektspeicher 206 enthalten, dass das Objekt 218 im Cloud-Objektspeicher 206 in einer akzeptablen Form vorliegt (z.B. identisch mit dem ist, was hochgeladen wurde). Die Vereinbarung 216 kann auch eine Aufbewahrungsrichtlinie und/oder Verfügbarkeitsanforderungen und/oder Abhilfemaßnahmen enthalten. Diese Vereinbarung 216 stellt effektiv ein Service Level Agreement (SLA) in Bezug auf das Objekt 218 dar. Die Aufbewahrungsrichtlinie kann festlegen, wie lange das Objekt 218 gespeichert werden soll, die Verfügbarkeit kann angeben, wie verfügbar das Objekt 218 sein soll, und die Abhilfemaßnahme kann eine vorbestimmte Strafe (z.B. eine Geldstrafe, eine Rückerstattung usw.) festlegen, wenn die Vereinbarung 216 verletzt wird. Die Strafe kann vom Ausmaß der Verletzung abhängen. Ein beschädigtes Objekt, das noch nutzbar ist, unterscheidet sich z.B. von einem fehlenden Objekt.
In 2 ist dargestellt, dass die Transaktion 210 auch mit einer Police 220 verbunden sein kann. Die Police 220 kann von einer Versicherungsgesellschaft ausgestellt werden und kann von der Versicherungsgesellschaft in das Hauptbuch 206 eingetragen werden. Die Police 220 kann beispielsweise eine Versicherung gegen Datenverlust für das mit der Transaktion 210 verbundene Objekt oder für mehrere Transaktionen oder für mehrere Objekte oder für einen Satz von Objekten bieten. Die Police 220 kann wiedergeben, dass die Versicherungsgesellschaft verschiedene Faktoren ausgewertet hat, um das Risiko zu bewerten. Diese Faktoren können unter anderem eine behauptete Verfügbarkeit des Cloud-Speichers 204, die Bedingungen der Vereinbarung 216, ob der Cloud-Objektspeicher 204 zustimmt, dass das Objekt erfolgreich in den Cloud-Objektspeicher 204 hochgeladen wurde, oder dergleichen umfassen. Die Police 220 kann für eine Laufzeit gelten, die kürzer ist als eine Aufbewahrungsdauer des Objekts.
3 zeigt ein Beispiel für ein Verfahren zum Versichern eines in einem Cloud-Objektspeicher gespeicherten Objekts. In 3 wird ein Objekt 302 zur Speicherung in einen Cloud-Speicher geschrieben. Ausführungsformen der Erfindung ziehen andere Szenarien als einen Cloud-Speicher in Betracht. Zum Beispiel können Ausführungsformen der Erfindung in einem lokalen Netzwerk, das Netzwerkspeicher umfasst, implementiert sein.
Wenn das Objekt in den Cloud-Objektspeicher geschrieben wird, wird die Transaktion 304 in einem Hauptbuch oder in einem verteilten Hauptbuch aufgezeichnet. Die Transaktion kann die durchgeführte Aktion, einen Identifikator des Objekts und/oder eine Vereinbarung identifizieren oder beinhalten. Die Vereinbarung kann bereits Teil des Hauptbuchs sein und bei allen Transaktionen vorausgesetzt oder angehängt werden. Der Identifikator kann auf wiederholbare Weise generiert werden und kann auf unverschlüsselte Objekte und verschlüsselte Objekte angewendet werden. Der Identifikator (z.B. ein Hash) ist eine Möglichkeit, das entsprechende Objekt eindeutig zu identifizieren.
Der Cloud-Objektspeicher kann dann das Objekt bestätigen 306 oder die Transaktion, wie vom Client spezifiziert, bestätigen und verifizieren. Das Bestätigen des Objekts kann das Verifizieren des Objekts beinhalten, z.B. durch Generieren des Identifikators aus dem geschriebenen Objekt und Vergleichen des Identifikators mit dem im Hauptbuch aufgezeichneten und vom Client im Hauptbuch gespeicherten Identifikator. Eine Übereinstimmung zeigt an, dass das Objekt erfolgreich empfangen worden ist. Liegt keine Übereinstimmung vor, kann dies ebenfalls im Hauptbuch festgehalten werden, so dass der Cloud-Objektspeicher auf überprüfbare Weise feststellen kann, dass das vom Client mutmaßlich hochgeladene Objekt nicht empfangen wurde oder dass das vom Client bereitgestellte Objekt beschädigt ist oder nicht mit dem Identifikator übereinstimmt. Das Bestätigen des Objekts kann optional die Zustimmung zu einer Vereinbarung in Bezug auf das Objekt beinhalten (z.B. Aufbewahrungsdauer, Verfügbarkeit usw.). Wenn die Identifikatoren nicht übereinstimmen, kann der Client imstande sein, das Objekt erneut hochzuladen. Beispielsweise kann der Client benachrichtigt werden, das Objekt erneut hochzuladen.
Als nächstes wird das Objekt versichert 308. Dies kann die Koordination mit einer Versicherungsgesellschaft oder einem Makler beinhalten, um das Objekt zu versichern. Die Police wird im Hauptbuch aufgezeichnet und mit der Transaktion und dem Objekt verknüpft. Wenn später ein Problem auftritt, kann ein Anspruch auf Grundlage der Police erhoben werden. Darüber hinaus kann es eine Vereinbarung zwischen dem Client und dem Cloud-Objektspeicher geben. Die Vereinbarung kann zusätzlich zur Police oder anstelle der Police durchgesetzt werden. Die Durchsetzung der Vereinbarung kann durch den Cloud-Objektspeicher und/oder den Client und/oder durch einen Drittanbieterdienst erfolgen. Zum Beispiel kann der Client geltend machen, dass der Cloud-Objektspeicher das Objekt nicht ordnungsgemäß gespeichert hat und zugelassen hat, dass das Objekt beschädigt wird. Der Cloud-Objektspeicher kann geltend machen, dass das ursprüngliche Objekt oder das unbeschädigte Objekt nie empfangen wurde. Mit dem Hauptbuch kann diese Situation geklärt werden. Durch eine Überprüfung des Objekts im Cloud-Speicher und im Hauptbuch kann festgestellt werden, ob das Objekt korrekt hochgeladen wurde oder ob das Objekt im Cloud-Objektspeicher beschädigt wurde.
In ähnlicher Weise kann die Behauptung eines Clients, dass ein Objekt fehlt, mithilfe des Hauptbuchs aufgelöst werden. Das Hauptbuch kann verwendet werden, um festzustellen, dass das Objekt hochgeladen wurde und dass es keinen nachfolgenden Löschbefehl gibt und, zum Beispiel, dass die Garantiezeit für die Objektspeicherung noch nicht abgelaufen ist (der Vertrag kann z.B. die Speicherung für 1 Jahr vorsehen). Somit erlauben es Ausführungsformen der Erfindung, mehrere Aspekte der Vereinbarung zu berücksichtigen, wie zum Beispiel Client-Befehle, Aktionen des Speicher-Providers, vereinbarte Speicherbedingungen und dergleichen. Die Vereinbarung kann jedoch den Client nicht angemessen entschädigen. Die Police kann so verwendet werden, dass der Client einen angemessenen Schutz im Falle von Problemen oder Anliegen in Bezug auf die Daten oder Objekte des Clients hat.
4 zeigt ein Beispiel für ein Verfahren zum Lesen eines Objekts aus einem Cloud-Objektspeicher und veranschaulicht ein Beispiel dafür, wann eine Police verwendet werden kann. Zunächst wird ein Objekt aus dem Cloud-Objektspeicher (oder Speicher) gelesen 402. Als nächstes wird das Objekt überprüft 404. Dies kann die Feststellung beinhalten, dass das Objekt fehlt oder dass das Objekt beschädigt ist. Die Überprüfung des Objekts kann auch den Vergleich eines Identifikators des gelesenen Objekts mit dem Identifikator, der dem Objekt im Hauptbuch zugeordnet ist, beinhalten. Eine Übereinstimmung verifiziert das Objekt, während eine Nichtübereinstimmung ein Problem anzeigt. Wenn ein Problem festgestellt wird, kann die Police 406 aufgerufen werden. Das Aufrufen der Police kann es der Versicherungsgesellschaft ermöglichen, auf das Hauptbuch, den Cloud-Objektspeicher und gegebenenfalls andere Quellen zuzugreifen, um zu überprüfen, ob die Transaktion ursprünglich erfolgreich war, und um Fehler zu ermitteln, die Auswirkungen auf die Police haben können.
5 zeigt ein Beispiel für ein Verfahren zum Löschen eines Objekts. Eine Anforderung zum Löschen eines Objekts kann von dem Cloud-Objektspeicher und/oder vom Hauptbuch empfangen werden 502. Anschließend wird die Löschanforderung bestätigt 504. Löschanforderungen oder andere Anforderungen im Hauptbuch können asynchron vom Cloud-Objektspeicher bedient werden. Wie bereits erwähnt, kann die Löschanforderung den Identifikator des Objekts enthalten oder einfach eine Identifikation des zu löschenden Objekts beinhalten (z.B. kann ein Client ein Objekt in den Mülleimer ziehen). Vor dem Löschen des Objekts 508 kann der Cloud-Objektspeicher überprüfen 506, ob das richtige Objekt gelöscht wird. Das Hauptbuch ermöglicht es dem Cloud-Objektspeicher, anhand des Identifikators zu überprüfen, ob das richtige Objekt gelöscht wird. Der Cloud-Objektspeicher kann dann das Objekt asynchron oder in einem Batch-Modus löschen 506, indem er Löschanforderungen im Hauptbuch in Batches identifiziert, oder dergleichen.
Im Allgemeinen ermöglicht das verteilte Hauptbuch, dass die darin aufgezeichneten Transaktionen sowohl die Aktion als auch die Bestätigung des Objekts wiedergeben. Für verschiedene Aktionen kann das Objekt gegebenenfalls identifiziert werden, zum Beispiel durch Verwendung des Identifikators oder Fingerabdrucks des Objekts und des im Hauptbuch aufgezeichneten Identifikators oder Fingerabdrucks. Das Hauptbuch hilft sicherzustellen, dass Löschanforderungen an dem richtigen Objekt ausgeführt werden, dass Objekte, die in den Cloud-Objektspeicher geschrieben werden, erfolgreich geschrieben werden, und dass Leseanforderungen das richtige Objekt abrufen.
Wann immer ein Fehler auftritt (das Objekt ist beschädigt, kann nicht gefunden werden, ist nicht wirklich gelöscht usw.), ermöglicht das Hauptbuch die Überprüfung der Transaktionen, die sich auf die mit den Fehlern verbundenen Objekte beziehen, in einer Weise, dass die Fehlerquelle ermittelt werden kann. Infolgedessen können je nach Fehlerquelle entsprechende Maßnahmen ergriffen werden. Wenn das falsche Objekt gelöscht wird oder wenn das Objekt nicht tatsächlich gelöscht wird, kann eine Police aufgerufen werden 510. So können Ausführungsformen der Erfindung gegen Datenverluste absichern. Ausführungsformen der Erfindung ermöglichen es einem Client oder Speicher-Provider, sich gegen Ereignisse im Zusammenhang mit nicht gelöschten Daten zu versichern.
6 veranschaulicht ein Beispiel für ein System zur Versicherung von Daten, die in einem Cloud-basierten Speichersystem gespeichert sind. 6 zeigt einen Client 602, der mit einem Datensatz 610 verbunden ist. Der Client 602 kann ein Unternehmen darstellen, und der Datensatz 610 kann Daten darstellen, die mit den Mitarbeitern des Unternehmens verbunden sind. Bei dem Datensatz 610 kann es sich um Produktionsdaten oder andere Daten handeln.
In diesem Beispiel kann der Client 602 Datensicherungsoperationen an oder für den Datensatz 210 (z.B. Daten, Datenobjekte, einen Backup-Sicherungssatz usw.) durchführen. Ein Sicherungsserver kann in der Cloud betrieben werden, um den Sicherungsvorgang zu erleichtern. Zum Beispiel kann der Client 602 die Daten in einem Cloud-Speicher 604 sichern. Wenn der Sicherungsvorgang abgeschlossen ist, wird eine Sicherung des Datensatzes 612 im Cloud-Speicher 604 gespeichert.
Die Datensicherung 612 (oder ausgewählte Teile davon) kann bei Bedarf abgerufen und für den Client 602 wiederhergestellt werden. Die Datensicherung 612 kann auch mit verschiedenen Policen verbunden sein, einschließlich einer Aufbewahrungsrichtlinie, die angeben kann, wie lange die Datensicherung 612 aufbewahrt werden soll. Nach (oder vor oder während) des Sicherungsvorgangs kann der Client 602 eine Transaktion in das Hauptbuch 614 eintragen. In diesem Fall hat der Client 602 Daten mit einem Hash Y an die Cloud gesendet. Der Hash Y kann einem Hash eines Datenobjekts, einem Hash einer Sammlung von Hashes oder dergleichen entsprechen. Wie bereits erwähnt, kann der Datensatz 610 mehrere Datenobjekte enthalten, und jedes Datenobjekt kann mit einem Fingerabdruck oder Hash verknüpft sein. Der Hash Y kann in diesem Fall ein Hash eines Strings sein, der durch Konkatenieren aller Hashes der Datenobjekte im Datensatz 610 gebildet wird. Der Client kann auch Bedingungen, wie zum Beispiel eine Aufbewahrungsrichtlinie, eine Verfügbarkeitsanforderung, einen Speichertyp oder dergleichen spezifizieren.
Der Cloud-Speicher 604 kann nach dem Empfang des Datensatzes 612 einen ähnlichen Satz von Hashes berechnen und dann den Hash Y für die Datensicherung 612 berechnen. Der Hash des Datensicherungssatzes 612 wird dann mit dem Hash des Datensatzes 610 verglichen. Eine Übereinstimmung zeigt an, dass die Daten erfolgreich im Cloud-Speicher 604 gesichert wurden.
Die Cloud kann dann einen Eintrag im Hauptbuch vornehmen, der besagt, dass der Benutzer Daten mit einem Hash Y hochgeladen hat.
Als nächstes kann der Client 602 mit einer Versicherungsgesellschaft 608 kommunizieren, um die Datensicherung 612 zu versichern. Die Versicherungsgesellschaft 608 kann die verschiedenen Faktoren rund um die Datensicherung 612 bewerten. Zum Beispiel kann die Versicherungsgesellschaft 608 die mit der Datensicherung 612 verbundenen Einträge im Hauptbuch 614 überprüfen, den Cloud-Speicher 604 bewerten, die vom Cloud-Speicher 604 bereitgestellte Verfügbarkeit überprüfen, die Fähigkeit des Cloud-Speichers 604, die Datensicherung 612 wiederherzustellen, überprüfen, wenn eine teilweise Beschädigung festgestellt wird, und dergleichen. Basierend auf diesen Faktoren, die jedes mit der Datensicherung 612 verbundene Risiko (z.B. Verlust, Beschädigung) identifizieren können, wird eine Police 616 ausgegeben. Die Police 616 wird im Hauptbuch 614 wiedergegeben und gibt an, dass die Datensicherung 612 (oder andere Daten) mit einem Wert X versichert ist (sind).
Wenn ein versichertes Ereignis eintritt, ist der Client 602 bis zum Wert X geschützt. Der Client 602 kann Zahlungen an die Versicherungsgesellschaft 608 leisten.
7 ist ein Beispiel für ein Flussdiagramm zur Versicherung von Daten, die in der Cloud gespeichert oder gesichert werden. Zu Beginn werden Daten in der Cloud 702 gespeichert. In einem Beispiel handelt es sich bei den Daten um eine Sicherung (Backup) vorhandener Daten oder von Produktionsdaten. In diesem Beispiel umfasst das Speichern der Daten die Eingabe von Informationen in ein verteiltes Hauptbuch, das die Transaktion widerspiegelt und Informationen enthält, die zur Identifizierung (z.B. zur eindeutigen Identifizierung) der Daten erforderlich sind. Beispielsweise können die Identifikationsinformationen einen Fingerabdruck, wie zum Beispiel einen Hash, umfassen.
Sobald die Daten in der Cloud gespeichert wurden, kann die Cloud verifizieren, dass die gespeicherten Daten den Daten entsprechen, die der Client hochgeladen hat. Dies wird dadurch erreicht, dass die Cloud den Identifikator/die Identifikatoren für die Daten generiert und dann diese unabhängig generierten Identifikatoren mit denen vergleicht, die vom Client bereitgestellt wurden. Die Cloud kann dann bestätigen, dass die Daten ordnungsgemäß empfangen und gespeichert wurden.
Als nächstes wird ein Vertrag (Contract) zwischen der Cloud und dem Client 704 geschlossen. Dieser Vertrag kann ein Smart Contract sein. Da der Client und die Cloud jeweils bestätigen können, dass die Daten korrekt gespeichert wurden, kann der Vertrag mit diesem Einvernehmen ausgeführt werden. Der Vertrag kann auch im Hauptbuch wiedergegeben werden. In einem Beispiel ist es nicht notwendig, einen Vertrag zu erstellen. Es ist jedoch für die Cloud von Nutzen, einen Eintrag im Hauptbuch vorzunehmen, der bestätigt, dass die Daten korrekt empfangen wurden und mit den vom Client hochgeladenen Daten übereinstimmen.
Als nächstes werden die Daten versichert 706. Die Police, die zur Versicherung der Daten ausgestellt wird, kann auf den Informationen im Hauptbuch bezüglich der Daten und anderen Eigenschaften der Cloud und/oder des Client basieren. Neben dem Schutz vor Verlust kann die Versicherungspolice auch vor Haftung schützen (z.B. wenn die Cloud Daten, für die ein Löschbefehl empfangen wurde, nicht löscht). Die Laufzeit der Police kann kürzer sein als eine Aufbewahrungsfrist der Daten. Die Bezahlung kann auch digital erfolgen und kann durch das Hauptbuch erleichtert werden.
Ausführungsformen der Erfindung ermöglichen es somit, Daten korrekt zu speichern, korrekt zu lesen, korrekt zu löschen oder dergleichen in einer Art und Weise, die sowohl den Client als auch den Cloud-Objektspeicher für ihre Aktionen verantwortlich macht und die es erlaubt, das Risiko zu bewerten, so dass die Daten versichert werden können.
Es sei darauf hingewiesen, dass die vorliegende Erfindung auf zahlreiche Arten implementiert werden kann, einschließlich als Prozess, Gerät, System, Vorrichtung, Verfahren oder computerlesbares Medium, wie zum Beispiel computerlesbares Speichermedium oder ein Computernetzwerk, in dem Computerprogrammanweisungen über optische oder elektronische Kommunikationsverbindungen gesendet werden. Anwendungen können die Form von Software annehmen, die auf einem Allzweckcomputer ausgeführt wird, oder in Hardware fest verdrahtet oder fest kodiert sein. In dieser Beschreibung können diese Implementierungen oder jede andere Form, die die Erfindung annehmen kann, als Techniken bezeichnet werden. Im Allgemeinen kann die Reihenfolge der Schritte der offenbarten Prozesse im Rahmen der Erfindung geändert werden.
Die hierin offenbarten Ausführungsformen können die Verwendung eines Spezial- oder Allzweckcomputers mit verschiedenen Computerhardware- oder -softwaremodulen umfassen, wie nachstehend ausführlicher erläutert. Ein Computer kann einen Prozessor und Computerspeichermedien enthalten, die Befehle tragen, die bei Ausführung durch den Prozessor und/oder bei Veranlassung der Ausführung durch den Prozessor eines oder mehrere der hierin offenbarten Verfahren durchführen.
Wie oben beschrieben, umfassen Ausführungsformen im Rahmen der vorliegenden Erfindung auch Computer-Speichermedien, die physische Medien sind, die darauf gespeicherte computerausführbare Anweisungen oder Datenstrukturen tragen oder aufweisen. Solche Computer-Speichermedien können irgendwelche verfügbaren physischen Medien sein, auf die ein Allzweck- oder Spezialcomputer zugreifen kann.
Beispielsweise - und ohne darauf beschränkt zu sein - können solche Computerspeichermedien Hardware, wie zum Beispiel Solid State Disk (SSD), RAM, ROM, EEPROM, CD-ROM, Flash-Speicher, Phasenwechselspeicher (Phase-Change-Memory, „PCM“) oder andere optische Plattenspeicher, magnetische Plattenspeicher oder andere magnetische Speichervorrichtungen oder irgendwelche anderen Hardware-Speichervorrichtungen umfassen, die verwendet werden können, um Programmcode in Form von computerausführbaren Befehlen oder Datenstrukturen zu speichern, auf die ein Allzweck- oder Spezialcomputersystem zugreifen und sie ausführen kann, um die offenbarte Funktionalität der Erfindung zu implementieren. Kombinationen der oben genannten sollten ebenfalls in den Bereich von Computerspeichermedien einbezogen werden. Solche Medien stellen auch Beispiele für nicht-transitorische Speichermedien dar, und nicht-transitorische Speichermedien umfassen auch Cloud-basierte Speichersysteme und -strukturen, obwohl der Umfang der Erfindung nicht auf diese Beispiele für nicht-transitorische Speichermedien beschränkt ist.
Computerausführbare Befehle umfassen beispielsweise Befehle und Daten, die einen Allzweckcomputer, einen Spezialcomputer oder eine Spezialverarbeitungsvorrichtung veranlassen, eine bestimmte Funktion oder eine Gruppe von Funktionen auszuführen. Obwohl der Gegenstand in einer Sprache beschrieben wurde, die spezifisch für strukturelle Merkmale und/oder methodische Handlungen ist, ist es so zu verstehen, dass der in den beigefügten Ansprüchen definierte Gegenstand nicht notwendigerweise auf die oben beschriebenen spezifischen Merkmale oder Handlungen beschränkt ist. Vielmehr werden die hierin offenbarten spezifischen Merkmale und Handlungen als beispielhafte Formen der Ausführung der Ansprüche offenbart.
Wie hierin verwendet, kann sich der Begriff „Modul“ oder „Komponente“ auf Softwareobjekte oder Routinen beziehen, die auf dem Computersystem ausgeführt werden. Die verschiedenen hier beschriebenen Komponenten, Module, Engines und Dienste können als Objekte oder Prozesse implementiert sein, die auf dem Computersystem ausgeführt werden, z.B. als separate Threads. Während das hier beschriebene System und die beschriebenen Verfahren in Software implementiert werden können, 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 „Rechenentität“ irgendein beliebiges Rechensystem sein, wie zuvor hier definiert, oder irgendein beliebiges Modul oder eine Kombination von Modulen, die auf einem Rechensystem laufen.
In mindestens einigen Fällen wird ein Hardware-Prozessor bereitgestellt, der betreibbar ist, um ausführbare Anweisungen zur Durchführung eines Verfahrens oder Prozesses, wie zum Beispiel die hierin offenbarten Verfahren und Prozesse, auszuführen. Der Hardware-Prozessor kann ein Element anderer Hardware, wie zum Beispiel die hierin offenbarten Rechenvorrichtungen und -systeme, umfassen oder auch nicht.
In Bezug auf Datenverarbeitungsumgebungen können Ausführungsformen der Erfindung in Client-Server-Umgebungen, ob Netzwerk- oder lokale 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 Client, Server und/oder virtuelle Zielmaschinen in einer Cloud-Umgebung residieren und operieren können.
Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt werden, ohne von ihrem Gedanken oder 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 Bedeutungsgehalt und den Äquivalenzbereich der Ansprüche fallen, sind in deren Umfang einzubeziehen.

Claims

Verfahren zum Schutz von in einem Objektspeicher gespeicherten Daten, wobei das Verfahren umfasst: Durchführen einer Transaktion mit einem von einem Client empfangenen Objekt, so dass das Objekt in dem Objektspeicher gespeichert wird; Aufzeichnen einer Transaktion in einem Hauptbuch, das mit dem Objektspeicher und einem Client verbunden ist, wobei das Hauptbuch die Transaktion und das Objekt bestätigt, wobei die Transaktion einen Identifikator des von dem Client empfangenen Objekts enthält; Aufzeichnen einer Bestätigung von dem Objektspeicher in dem Hauptbuch, wobei die Bestätigung anzeigt, dass ein von dem Objektspeicher erzeugter Identifikator des Objekts mit dem von dem Client bereitgestellten Identifikator des Objekts übereinstimmt; und Versichern des Objekts mit einer Police.
Verfahren gemäß Anspruch 1, welches ferner das Versichern des Objekts gegen Verlust oder Haftung umfasst.
Verfahren gemäß Anspruch 2, wobei das Verfahren ferner das Auswerten von Faktoren, die mit dem Objekt und dem Objektspeicher verbunden sind, umfasst, um ein Risiko zu bewerten.
Verfahren gemäß Anspruch 3, wobei die Faktoren eine Verfügbarkeit des Objektspeichers, Einträge im Hauptbuch einschließlich der Transaktion und der Bestätigung und/oder einen Vertrag zwischen dem Objektspeicher und dem Client umfassen.
Verfahren gemäß Anspruch 1, welches ferner das Schreiben des Objekts in den Objektspeicher, das Lesen des Objekts aus dem Objektspeicher und/oder das Löschen des Objekts aus dem Objektspeicher umfasst.
Verfahren gemäß Anspruch 5, welches ferner das Eingeben einer Löschanforderungs-Transaktion in das Hauptbuch, so dass das Hauptbuch die Löschanforderung bestätigt, umfasst.
Verfahren gemäß Anspruch 1, wobei die Transaktion ferner eine Vereinbarung, die von dem Objektspeicher oder von einem Provider des Objektspeichers akzeptiert wird, umfasst.
Verfahren gemäß Anspruch 7, welches ferner das Verwenden der Police umfasst, wenn das Objekt nicht wiederhergestellt werden kann oder wenn das Objekt beschädigt ist.
Verfahren gemäß Anspruch 7, welches ferner das Verwenden der Police umfasst, wenn das Objekt existiert, obwohl das Objekt gelöscht sein sollte.
Verfahren gemäß Anspruch 7, wobei die Transaktion einen Smart Contract zwischen dem Client und dem Objektspeicher oder zwischen einem Benutzer und einem Objektspeicher-Provider umfasst.
Verfahren gemäß Anspruch 1, welches ferner das Bezahlen der Police mit einer digitalen Währung umfasst.
Nicht-transitorisches computerlesbares Medium, welches Anweisungen umfasst, die, wenn sie ausgeführt werden, das Verfahren gemäß Anspruch 1 durchführen.
Verfahren zum Versichern eines Objekts, das in einem Cloud-basierten Speichersystem gespeichert ist, wobei das Verfahren umfasst: Speichern des Objekts in dem Cloud-basierten Speichersystem durch einen Client; Aufzeichnen einer Transaktion in einem Hauptbuch, die wiedergibt, dass das Objekt in den Cloud-Objektspeicher geschrieben wurde, wobei die Transaktion bestätigt, dass das Objekt in den Cloud-Objektspeicher geschrieben wurde und einen Identifikator des Objekts enthält und mit einer Vereinbarung verbunden ist, die eine Verfügbarkeit des Objekts spezifiziert; Empfangen einer Bestätigung von dem Objektspeicher, wobei die Bestätigung anzeigt, dass ein von dem Objektspeicher generierter Identifikator des Objekts mit dem vom Client bereitgestellten Identifikator des Objekts übereinstimmt, und wobei die Bestätigung eine Annahme der Vereinbarung darstellt; und Versichern des Objekts mit einer Police.
Verfahren gemäß Anspruch 13, wobei der Identifikator des Objekts einen Hash umfasst.
Verfahren gemäß Anspruch 13, welches ferner das Ausführen eines Vertrags zwischen dem Client und dem Cloud-basierten Speichersystem oder einem Provider umfasst, wobei der Vertrag in das Hauptbuch eingetragen wird.
Verfahren gemäß Anspruch 13, wobei das Objekt eine Datensicherung umfasst, die eine Vielzahl von Dateien enthält, die jeweils mit ihrem eigenen Identifikator verknüpft sind, wobei der Identifikator einen Hash aus einer Kombination aller Identifikatoren der Vielzahl von Dateien umfasst.
Verfahren gemäß Anspruch 13, wobei die Police gegen den Verlust des Objekts oder die Beschädigung des Objekts und/oder Haftung schützt.
Verfahren gemäß Anspruch 13, wobei die Transaktion verwendet wird, um das Objekt zu verifizieren, indem ein von dem Client generierter und in dem Hauptbuch gespeicherter Identifikator mit einem von dem Cloud-basierten Speichersystem generierten Identifikator verglichen wird.
Verfahren gemäß Anspruch 13, welches ferner das Auswerten von Faktoren, die mit dem Objekt und dem Objektspeicher verbunden sind, umfasst, um ein Risiko zu bewerten, um die Police zu erstellen.
Verfahren gemäß Anspruch 3, wobei die Faktoren eine Verfügbarkeit des Objektspeichers, Einträge in dem Hauptbuch einschließlich der Transaktion und der Bestätigung und/oder einen Vertrag zwischen dem Objektspeicher und dem Client umfassen.