-
Die Erfindung betrifft ein Verfahren zur sicheren Verarbeitung von Daten mit den Merkmalen des Anspruchs 1.
-
Durch Systeme elektronischer Datenverarbeitung werden Geschäfts- und Verwaltungsprozesse beschleunigt und vereinfacht. Mit einer eher prozessorientierten Abarbeitung von Dienstleistungen – also der sinnvollen Bündelung einzelner Services zu bedarfsgerechten Paketen – kann eine höhere Qualität der im Internet angebotenen Dienste entstehen. Zunächst steht jedoch zu Beginn jedes Prozesses die Erhebung der Daten des Nutzers (z. B. eines Antragstellers oder eines Kunden und/oder eines Safe-Nutzers (in der folgenden Terminologie).
-
Da keine einzelne Leistung beauftragt wird, sondern u. U. mehrere Einzelaufträge abzuwickeln sind, entsteht ein sehr großer Aufwand bei der Erfassung von Daten, insbesondere durch die wiederkehrende Erfassung derselben Daten für mehrere Aufträge, was häufig zu einem Abbruch der begonnenen Transaktionen führt.
-
Bisher ist der gesamte Prozess relativ ineffizient und zudem unsicher.
-
1) Erfassung:
-
Zunächst müssen die Daten für die Verwendung durch einen Geschäfts- oder Verwaltungsprozess erfasst werden. Dies erfolgt üblicherweise von Eingabeportal zu Eingabeportal unterschiedlich. Nahezu jedes Formular an einem Eingabeportal reagiert unterschiedlich und folgt anderen gestalterischen Gesichtspunkten. Häufige Software-Updates z. B. der PDF-Reader, Flash-Viewer sind erforderlich, um Sicherheitslücken zu beheben. Dies schafft Inkompatibilitäten. Es ist nicht transparent, welche Software sich wo einmal eingegebene Daten merkt und ggf. wieder auslesen kann. Update-Vorgänge geschehen auf völlig unterschiedliche Art und Weise.
-
2) Client-Sicherheit:
-
Im Prozess der Datenerfassung müssen die Daten vom Client des Nutzers an das Eingabeportal des Anbieters der Dienstleistung übertragen werden. Die Vielzahl der täglich in Umlauf kommenden Computerviren macht es für den Nutzer problematisch, die im Internet angebotenen Dienstleistungen zu nutzen. Die Dienstleistungsanbieter, insbesondere öffentliche Stellen, können nicht davon ausgehen, dass der Nutzer immer in der Lage ist, seinen heimischen PC frei von Schadsoftware zu halten.
-
3) Vertrauen, Transparenz:
-
Nachdem die sensiblen Daten des Nutzers an den Anbieter übertragen wurden, werden sie als Entscheidungsgrundlage häufig an vielen verschiedenen Stellen aufbewahrt, ohne dass der Nutzer als Eigentümer der Daten die Kontrolle darüber hat. Der Eigentümer der Daten kann die Haltung, die Verwertung und das Löschen der Daten de facto nicht prüfen oder beeinflussen.
-
Die Weitergabe der fallbezogenen sensiblen personenbezogenen Daten innerhalb von Institutionen als auch zwischen unterschiedlichen Institutionen erfolgt meist ohne Steuerungsmöglichkeit bzw. Benachrichtigung des Nutzers. Die nicht abreißende Folge von Datenverlusten bei öffentlichen und privaten Stellen zeigt: die Aufbewahrung sensitiver Daten beim Anbieter ist zumeist unsicher.
-
Daraus ergibt sich eine diffuse Unsicherheit gegenüber kooperativen elektronischen Dienstleistungsprozessen, weil der Nutzer nicht einschätzen kann, wo seine Daten sicher aufgehoben sind und wo nicht. Durch die oben beschriebene Komplexität der Datensicherheit kann der Nutzer nicht sicher sein, dass seine Daten nicht weitergegeben, auf USB-Sticks kopiert oder per E-Mail versendet werden, ohne dass er zugestimmt hat.
-
4) Datenverlust beim Nutzer:
-
Aber auch, wenn man die Probleme der Aufbewahrung sensitiver Daten beim Anbieter zu vermeiden versucht: Die streng dezentrale Aufbewahrung der digitalen Daten beim Nutzer beinhaltet die Möglichkeit des Datenverlustes. Deshalb erfordert die dezentrale Aufbewahrung digitaler Daten entsprechende Datensicherungen und/oder Konvertierungen etc., deren Komplexität oftmals die Fähigkeiten des Nutzers übersteigt.
-
5) Verarbeitung:
-
In sehr vielen Institutionen wird die eigentliche Dienstleistung direkt auf Basis der in den Prozess eingespeisten Daten erbracht. Dabei werden die Daten durch Softwaresysteme verarbeitet, aggregiert, Berechnungen ausgeführt etc. Die Daten sind somit nicht gegen unerlaubte Weitergabe, Kopieren oder Verfälschen geschützt.
-
6) Kosten:
-
Schließlich entstehen in den beschriebenen Prozessen für die elektronische Verarbeitung von Daten und Dokumenten in Geschäftsprozessen erhebliche Kosten. Die Aufbewahrung sensibler Daten (im Verwaltungsbereich z. B. nach SGB II) muss die Kriterien Verfügbarkeit, Integrität und Vertraulichkeit erfüllen. Damit werden die umzusetzenden Mechanismen sehr teuer. Oftmals existieren bei öffentlichen Einrichtungen eigene IT-Abteilungen, weil argumentiert wird, dass die gesetzlichen Anforderungen anders nicht erfüllt werden können.
-
Somit erfolgt die Einbeziehung von Dokumenten oder Daten in Prozesse meist so, dass diese Daten bzw. Dokumente auf zentralen Speicherstrukturen zumindest zeitweise unverschlüsselt vorliegen.
-
Grundlegende Prinzipien des Identity-Managements beinhalten Identity- bzw. Attribute-Provider, die bestimmte sensitive Daten nur nach Zustimmung des Eigentümers herausgeben. Diese Daten liegen jedoch aufgrund dieser Prinzipien zumindest zeitweise beim Identity- bzw. Attribute-Provider im Klartext vor.
-
Das Abspeichern der Daten bei Unternehmen und Verwaltungen geschieht in Datenbanken, die teils Klartext, teils verschlüsselte Daten beinhalten. Für Administratoren sind diese Daten jedoch meist im Zugriff.
-
Um das Problem des „Vertrauens in die Anzeige” (Trusted Display) zu lösen wurde in
Dirk Weber, Arnd Weber, Stephone Lo Presti, "Requirements and Design Guidelines for a Trusted Hypervisor Interface", p. 178–189, erschienen in
"Future of Trust in Computing", Proc. of the First International Conference Future of Trust in Computing 2008, vorgeschlagen, auf dem Bildschirm des Nutzers mit einem sichtbaren Wasserzeichen kenntlich zu machen, wenn er mit einem vertrauenswürdigen System arbeitet. Das Wasserzeichen wird jedoch auf dem PC selbst angezeigt und ist deshalb nicht geeignet, mit Sicherheit zu vermitteln, dass der Nutzer tatsächlich einen „vertrauenswürdigen Bereich” (Trusted Compartment) bearbeitet.
-
Für die oben genannten Problemstellungen wurde ein Modell aus verschiedenen Komponenten und Services entwickelt, das als elektronischer Safe für Daten und Dokumente bezeichnet wird. Grundsätzlich sind seit der Mitte der neunziger Jahre technische Mittel als elektronische Safes für Dokumente bekannt.
-
-
Die Vertraulichkeit in verteilten, nicht vertrauenswürdigen Speicherumgebungen wird in folgenden Veröffentlichungen diskutiert:
Zhang, et al. (2008), „Towards A Secure Distribute Storage System", Advanced Communication Technology, (ICACT 2008), IEEE Press, Apr. 2008, pp. 1612–1617, doi: 10.1109/ICACT.2008.4494090), (
US-A 7,349,987 ), (
Iyengar, A. et al. (1998), "Design and Implementation of a Secure Distributed Data Repository", In Proc. of the 14th IFIP Internat. Information Security Conf., pp. 123–135.) (
Kubiatowicz et al. (2000), "Oceanstore: An architecture for global-scale persistent storage", Proc. of the ninth international conference on Architectural support for programming languages and operating systems (ASPLOS '00), ACM SIGARCH Computer Architecture News, Dec. 2000, pp. 190–201, ISSN: 0163–5964), as distributed p2p systems (US Patent Application 20060078127), as smart card extension (
US-A 7,206,847 ), as backup.
-
Dieses Modell und die dazugehörigen Kommunikationsprotokolle ermöglichen es jedoch nicht, dass Daten aktiv vom Eigentümer versendet werden oder dass diese Daten – wie bei prozessorientierter Vorgehensweise üblich – von Stelle zu Stelle weitergegeben werden können: Daten werden geändert, ergänzt oder neu erstellt.
-
Die Daten wieder in den elektronischen Safe zurückzuschreiben und vom folgenden Teilnehmer anfordern zu lassen ist eine Möglichkeit, die mehrere Nachteile hat:
- • Der Safe-Eigentümer wird involviert, obwohl er nicht immer involviert werden möchte.
- • Der Prozess kommt durch die fällige Freigabe ins Stocken.
- • Für jegliche Daten, die so ausgetauscht werden, ist das Safe-Datenmodell zu erweitern, um die Daten über die bisherigen Mittel abfragen zu können. Der Safe-Eigentümer sieht sich damit unnötiger Komplexität gegenüber, die ihn überhaupt nicht betrifft.
-
Es wurde stattdessen nach einem neuen Modell mit dazugehörigen Kommunikationsprotokollen gesucht, das zur flexiblen, vertrauenswürdigen Weitergabe von Daten geeignet ist und das zusätzlich die folgenden Bedingungen erfüllt:
- 1. Der Safe-Eigentümer soll in der Lage sein, Teilnehmern des Prozesses Daten für ihren Prozessschritt zur Verfügung stellen.
- 2. Ad-hoc-Prozesse sollen möglich sein. Somit ist nicht davon auszugehen, dass zu Beginn des Prozesses alle Teilnehmer des Prozesses (Safe-Nutzer) bekannt sind.
- 3. Der Safe-Eigentümer soll immer in der Lage sein, die transferierten Daten zu sehen.
- 4. Der Safe-Eigentümer soll in der Lage sein, seine Sicherheitseinstellungen zu ändern, während der Prozess schon läuft. Der Safe-Eigentümer muss in der Lage sein, den Zugriff auf transferierte Daten zu stoppen.
- 5. Der Safe-Eigentümer soll in der Lage sein, unter verschiedenen Sicherheits-Niveaus zu wählen.
- 6. Der Safe-Eigentümer soll sehen können, wer wann auf welche Daten zugegriffen hat.
- 7. Die Kommunikation über den Safe soll unbeobachtbar sein.
- B. Der Safe-Eigentümer soll in der Lage sein, Safe-Nutzer nach verschiedenen Kriterien zu suchen.
- 9. Der Prozess darf nicht stoppen, wenn ein Teilnehmer des Prozesses im Urlaub oder nicht mehr anwesend ist. Sendende Safe-Nutzer und/oder ein vom Safe-Nutzer entsprechend, für bestimmte Bereiche autorisierter Prozessadministrator muss in der Lage sein, den Zugriff auf Daten einem anderen Empfänger zuzuordnen.
-
Gegenstand dieser Erfindung sind Verfahren zur sicheren und effizienten Erfassung, Bearbeitung und Weitergabe von Daten und Dokumenten entlang einer Prozesskette.
-
Verschiedene Ausführungsformen der Verfahren und der Vorrichtung werden im Folgenden beispielhaft dargestellt. Dabei zeigt
-
1 einen Überblick über das Zusammenwirken von Safe-Eigentümer und Safe-Nutzer, über Komponenten des Safe und solche zur Überprüfung der Authentizität des safe-Client;
-
2 eine schematische Übersicht über die logische Gliederung des elektronischen Safes;
-
3 eine Darstellung einer Initialisierung des elektronischen Safes;
-
4 Ausschnitt eines Bildschirms mit einer Ausführungsform für eine Überprüfung der Authentizität des Safe-Client mit einem mobilen Gerät;
-
5–7 Sequenzdiagramme für die nutzerseitig initiierten Datentransfers bei Ausführungsformen.
-
Das im Folgenden skizzierte Verfahren umfasst mehrere Teile, mit denen die zuvor dargestellten Probleme gelöst werden können. In 1 ist eine zusammenfassende Darstellung des Verfahrens und des Systems gegeben. In 2 wird der grundsätzliche Aufbau eines elektronischen Safes 10 beschrieben. In der dargestellten Ausführungsform des elektronischen Safes 10 sind drei Bereiche für die Speicherung von Datensätzen vorgesehen: ein Bereich für eingehende Daten (inbox) 101, ein Bereich für ausgehende Daten (outbox) 102, sowie ein Bereich für die eigentlichen Inhalte 103 des elektronischen Safes 10. Des Weiteren enthält der elektronische Safe 10 noch einen Speicherbereich 104 mit gespeicherten Prozessen, die für die Verarbeitung der Daten im Zusammenhang mit dem elektronischen Safe 100 eine Rolle spielen.
-
Safe Verifikation ohne Störung der Arbeitsabläufe
-
Dem Safe-Eigentümer 1 (z. B. ein Bürger, ein Kunde, ein Antragsteller) oder dem mindestens einen Safe-Nutzer 2 (In 1 werden 1 bis n Safe-Nutzer angegeben) soll eine Einschätzung zur Sicherheit seines jeweiligen Safe Clients 100, 201, 202 gegeben werden. Safe Clients 100, 201, 202 sind Programme, die auf Rechnern des Safe-Eigentümers 1 und/oder der Safe Nutzer 2 laufen, um die Arbeit mit dem elektronischen Safe 10 zu ermöglichen. Typische Safe-Nutzer 2 können z. B. Mitarbeiter von Behörden oder Firmen sein.
-
Der elektronische Safe 10 ist hier schematisch mit einigen seiner Eigenschaften (z. B. einer Safe Transferbox 12) dargestellt, die im Folgenden erläutert werden.
-
Es liegt in der Natur der Sache, dass es dem Safe-Eigentümer 1 oder Safe-Nutzer 2 nicht möglich ist, anhand eines Bildschirmes zu erkennen, ob er die Ausgabe seiner Anwendung (z. B. Web-Browsers) sieht oder ein von einem heimtückischen Virus erzeugtes digitales Bildschirmabbild, das so aussieht, als ob es von eben diesem Programm (Web-Browser) stammen würde. Einem bösartigen Programm ist es möglich, die Bildschirmausgabe eines anderen Programms so zu ändern, dass z. B. Geldbeträge verändert sind, Willenserklärungen unvollständig dargestellt sind etc. Für den elektronischen Safe wäre dies ein starker Vertrauensverlust.
-
Deshalb wird in einer Ausführungsform folgendes Verfahren eingesetzt:
Ein Attestierungsprotokoll zwischen Safe-Client 100, 201, 202 und Safe-Provider sieht vor, bei jeder erfolgreichen Attestierung des Safe-Clients 100, 201, 202 gegenüber dem Safe-Provider den Namen, den Index in einer Liste und/oder einen Link eines safe-spezifischen, in seiner Gültigkeit zeitlich, begrenzten Bildes, d. h. eines ersten Autorisierungsdatensatzes 20 (Zeitraum z. B. 10 min) an den Safe-Client zu übermitteln.
-
Dieses Bild 20 ist eine Auswahl aus einer genügend großen Anzahl von Bildern, die am Safe-Client 100, 201, 202 verfügbar sind. Es wird z. B. vom Safe-Client 100, 201, 202 an prädestinierter Stelle angezeigt.
-
Durch die prädestinierte Platzierung kann der Safe-Nutzer 2 sicherer sein, dass diese Art der Authentifizierung korrekt ist; ein falsch platzierter erster Autorisierungsdatensatz 20 würde sein Misstrauen wecken.
-
In der vorliegenden Ausführungsform ist der erste Autorisierungsdatensatz 21 ein Bild. Alternativ oder zusätzlich kann auch eine Sounddatei abgespielt werden. Es ist auch möglich, dass eine Animation auf dem Safe-Client 100, 201, 202 erzeugt wird, die den Nutzer nicht von der eigentlichen Arbeit ablenkt, wie z. B. ein vorübergehende farbliche Änderung am Bildschirmrand. Der erste Autorisierungsdatensatz 20 kann auch ein formatierter oder unformatierter Text sein, der sich leicht und schnell mit einem anderen Text vergleichen lässt.
-
Der Nutzer des Safe-Clients 100, 201, 202 erhält zusätzlich die Möglichkeit, über den Safe-Client 100, 201, 202 weitere Authentifizierungsvorrichtungen 22 zur Kontrolle des ersten Autorisierungsdatensatzes 21 einzurichten. Mit Hilfe eines mobilen Safe-Clients kann der Safe-Nutzer 2 dieses zeitlich sich ändernde Bild verifizieren, wann immer er möchte.
-
Er kann z. B. sein Smart Phone mit einer Authentifizierungsvorrichtung 22 neben seinen Bildschirm stellen und gelegentlich auf die Übereinstimmung der Bilder achten. Die Authentifizierungsvorrichtung 22 ist z. B. eine Software auf einem Smartphone.
-
Somit kann ein Angreifer nicht wissen, wann der Zustand des Safe-Clients 100, 201, 202 überwacht wird, und diese zusätzliche Sicherheit stört die gewohnten Arbeitsabläufe in keiner Weise. Wichtig ist, dass nur Safe-Client und/oder Authentifizierungsvorrichtungen 22, die vom Server als vertrauenswürdig eingestuft werden, Zugriff auf das richtige – gerade aktuelle – Bild (d. h. die Autorisierungsdatensätze 20, 21) erhalten.
-
In 4 ist eine Ausführungsform in Zusammenhang mit einem elektronischen Safe beschrieben. Grundsätzlich ist es aber möglich, die Überprüfung der Authentizität eines Client mit Autorisierungsdatensätzen 20, 21 auch ohne einen elektronischen Safe zu betreiben.
-
Safe-Formulare Erfassung und Verarbeitung von Daten direkt über den Safe
-
Safe-Formulare 11 sind ein Mittel zur Erfassung und Bearbeitung von Daten im elektronischen Safe 10.
-
Anstatt die Daten dort zu erfassen, wo sie benötigt werden (z. B. bei Anträgen an die öffentliche Verwaltung im Verwaltungsportal, bei e-Business-Anwendungen auf der Firmen-Website), werden die Daten immer im elektronischen Safe 10 erfasst und von dort aus in den Prozess verteilt.
-
Alle für öffentliche und nichtöffentliche Dienstleister notwendigen Daten, die bisher über Formulare oder Webanwendungen erfasst werden, lassen sich auf Daten abbilden, die der Eigentümer im Safe gespeichert hat. Die im Safe gespeicherten Daten lassen sich so häufig wiederverwenden.
-
Der elektronische Safe 10 beinhaltet die Möglichkeit, durch Dritthersteller Abbildungen von Antragsdaten zu Safe-Daten einzuspeisen. Somit müssen Portale öffentlicher Verwaltungen keine Formulare bereitstellen, um Anträge online zu erfassen.
-
Der Safe-Eigentümer 1 hat eine grafische Benutzeroberfläche, mit der er theoretisch alle Verwaltungen erreichen kann.
-
Diese eine Benutzeroberfläche reagiert immer auf bekannte Art und Weise, was die gefühlte Sicherheit des Safe-Eigentümers 1 erhöht.
-
Die Erfassung der Daten lässt sich unterbrechen und beliebig fortsetzen und ist komfortabler als gängige Web-Anwendungen.
-
Dem Bearbeiter der Daten ist es möglich, sich virtuell in einen Teil des elektronischen Safes 10 zu begeben (Kopie des Safe-Inhaltes), dort alle Daten zu sehen und im Sinne eines Bescheides zu bearbeiten. Dabei kann der Bearbeiter (z. B. ein Safe Nutzer) keine Daten aus dem Safe herausnehmen, im Dateisystem ablegen, per E-Mail versenden etc. Die Ausführung als minimales Trusted Compartment verhindert, dass die einmal eingegebenen Daten über Drittanwendungen (es gibt keine) unbemerkt weitergegeben werden.
-
Safe-Regeln – automatisierte Erstellung von Vorbewertungen und Bescheiden im Safe, Einbindung in unsichere Prozesse Wie oben beschrieben, wird der Safe-Client 100, 201, 202 selbst zur vertrauenswürdigen Instanz, da er sich gegen die Serverinfrastruktur und die SmartCard attestieren muss.
-
Auf dieser Grundlage werden die vom Safe-Eigentümer 1 editierten Daten vom Safe Client 100, 201, 202 nach vordefinierten Safe-Regeln 13 verarbeitet. Da der Safe-Client 100, 201, 202 nachweislich unverändert ist, kann die Software Bewertungen der Datenlage erstellen, und diese dann signieren. Die signierte Bewertung (Vorbewertung) geht in pseudonymisierter Form in nachfolgende Stationen eines Workflows ein, ohne dass dabei vom Safe-Client 100, 201, 202 identifizierende Merkmale der Daten des Safe-Eigentümers 1 weitergereicht werden. Somit ist der Schutzbedarf der resultierenden Vorbewertung wesentlich unkritischer als der Schutzbedarf der ursprünglichen Daten.
-
Aus der Vorbewertung wird in automatisierbaren Prozessen eine Autorisierung (Bescheid) abgeleitet, die dem Safe-Eigentümer 1 direkt wieder in den elektronischen Safe 10 eingestellt wird. Wenn der Bescheid auf Basis eines Pseudonyms erteilt wurde, generiert der elektronische Safe 10 daraus einen personalisierten Bescheid, da er über die identifizierenden Daten verfügt und kryptographisch nachweisen kann, dass der Safe-Eigentümer über das im Bescheid angegebene Pseudonym verfügt.
-
Für die Verarbeitung sensibler Daten durch Drittsysteme werden die Daten aus dem Safe 10 ebenfalls pseudonymisiert freigegeben. Der Fall bleibt über das Pseudonym und eine Fall-Identifikation zuordenbar, die identifizierenden Daten des Safe-Eigentümers 1 werden jedoch entfernt. Wo es bisher notwendig war, die persönliche Adresse für die Zustellung des Bescheides anzugeben, ist es jetzt möglich, einen Transportservice (z. B. Post) unter Angabe der Kombination aus Pseudonym und Fall-Identifikation zu ermächtigen, den Bescheid beim Dienstleister abzuholen und zum Eigentümer zu befördern. Somit bleiben die Falldaten unverkettbar zur Person des Eigentümers.
-
Safe-Transferbox Übergabe von Daten über den Safe Der vorgesehene Ansatz wird stark verallgemeinert, indem der Mechanismus des Übergabedatensatzes 12 (im Folgenden auch als Transferbox bezeichnet) eingeführt wird. Die Transferbox 12 stellt eine Kopplung von verschiedenen Datensätzen dar, die z. B. Inhalte (z. B. Textdokumente) mit Zusatzdaten (z. B. Zugangserlaubnissen, Anweisungen für die Durchführung von Prozessen im Folgenden etc.) verbindet. In der Funktion ist die Transferbox 12 eine Art Postfach, das mit bestimmten Regeln verknüpft ist.
-
Die Transferbox 12 dient sowohl dem Austausch von Daten und Dokumenten zwischen Safe-Nutzern 2 untereinander als auch zwischen Safe-Eigentümer 1 und Safe-Nutzern 2.
-
Ein Datensatz 15, der/die in einer Transferbox 12 abgelegt ist, muss für den Empfänger (d. h. einen Safe-Nutzer 2) und immer auch für den Safe-Eigentümer 1 entschlüsselbar sein. Wenn im Folgenden von dem Ablegen oder Speichern eines Datensatzes 15 in einer Transferbox 12 gesprochen wird, so ist dies so zu verstehen, dass die Transferbox 12 einem mit dem elektronischen Safe 10 gekoppelten Übergabedatensatz 12 entspricht, der Bedingungen 16 enthält, die den Zugriff auf den Datensatz 15 regeln. Diese Bedingungen betreffen z. B. Abfragen, deren Wahrheitsgehalt (wahr/nicht wahr) sich erst nach dem Aufstellen der Bedingungen 16 feststellen lässt. So lässt sich eine Bedingung 16 formulieren, die sagt, dass der Datensatz 15 erst dann bearbeitet werden kann, wenn von extern ein weiterer Datensatz zur Verfügung gestellt wird, dessen Existenz die Abfrage wahr werden lässt.
-
Eine Erweiterung der Transferbox 12 ist ein Zusammenarbeitsfach (Collaborationbox (CB)), das gemeinschaftliches Arbeiten an einem Dokument erlaubt.
-
Zu jedem Prozess, in den der Safe-Eigentümer 1 oder Safe Nutzer 2 einbezogen ist, gibt es einen Block an Informationen ”process information” (siehe 2), in dem z. B. die Transferboxen 12 des Prozesses vermerkt sind Der Safe-Eigentümer 1 sieht alle Transferboxen 12, wenn der Prozess von ihm initiiert wurde; als Safe Nutzer 2 sieht man nur die, auf die man Zugriff hat.
-
Die Transferboxen 12 sind immer an den Prozess gebunden, und der – vertrauenswürdige – Safe-Client 100, 201, 202 bewirkt, dass sie nur innerhalb der Bearbeitung dieses Prozesses benutzbar sind, indem stets nur ein Safe-Client 100, 201, 202 in einem System aktiv sein kann, nur ein Prozess im aktiven Safe-Client 100, 201, 202 in Bearbeitung sein kann und der Safe-Client 100, 201, 202 nur auf Daten des aktuellen Prozesses zugreift und diese nicht außerhalb des Safe-Client 100, 201, 202 und nicht über die Bearbeitung des aktuellen Prozesses hinaus speichert. Nur ein authentifizierter Nutzer erhält Zugang zu einem Safe-Client 100, 201, 202.
-
Eine einzelne Transferbox 12 ist über eine Safe_ID, box_ID vollständig bezeichnet. Des Weiteren sind in den process information eine Vielzahl von TANs (Transaktionsnummern) enthalten, die man nur innerhalb des Prozesses verwenden kann. Die TANs können z. B. dazu verwendet werden, dass ein Safe-Nutzer 2 autonom, restriktiv Zugriff auf bestimmte Daten (weiter) vergeben kann.
-
Als Infrastruktur-Dienst wird ein SafeDirectoryService (SDS) eingeführt. Er verzeichnet
- • alle Safe-Nutzer 2, deren Rollen und Positionen,
- • alle bekannten Prozess-Typen mit deren Rollen,
- • Berechtigungen für Safe-Nutzer 2 an Transferboxen 12.
-
Der SafeDirectoryService kann z. B. dazu dienen, dass für einen Prozess (z. B. eine Antragstellung) festgelegt wird, wer wann in welchem Umfang Zugriff auf die Daten in der Transferbox 12 erhält.
-
Der Dienst ist ein stark replizierter Verzeichnisdienst, der administrativ getrennt von den Safe-Providern arbeitet. Er bietet u. a. folgende logische Funktionen:
- • retrieveTANList()- bezieht vom SDS eine Liste von neuen Transaktionsnummern {TANs)
- • createAccessGrant{TAN/permissions/sender/receiverIprocessstep_id}
getAccessGrant(TAN/permissions/sender/receiverIprocessstep_id}
-
Der SDS entkoppelt die Zugriffssteuerung auf die Transferboxes 12 vom Safe-Provider. Safe-Eigentümer 1 und Safe-Nutzer 2 vergeben Rechte (z. B. durch die Vergabe von TANs) auf die von ihnen geschaffenen Transferboxen 12 und hinterlegen diese beim SDS.
-
Der SDS erhält lediglich TANs in Verbindung mit Zugriffrechten, so dass er keine zusammenhängenden Prozesse rekonstruieren kann. Auch wird ihm nicht bekannt gegeben, welche Transferboxen 12 in einem Safe 10 vorhanden sind. Der SDS prüft letztlich nur die gewünschten Bedingungen 16 – „conditions” – die der Ersteller (der Safe-Eigentümer) der Transferbox 12 gesetzt hat.
-
Wenn ein Safe-Nutzer 2 vom SDS kein Recht erhält, auf eine Transferbox 12 zuzugreifen, die er für seinen Prozessschritt benötigt, muss er auf herkömmlichen Weg eine Release Order (Freigabeanforderung) an den Safe-Eigentümer 1 stellen, um z. B. bestimmte Daten freizugeben. Damit gerät der Prozess potentiell ins Stocken.
-
Wenn ein Safe-Nutzer 2 (im Folgenden: VN – vertrauenswürdiger Nutzer) vom Safe-Eigentümer 1 als so vertrauenswürdig eingestuft wird, dass er die Daten an jegliche andere Safe-Nutzer 2 weiterleiten darf, wird diese Genehmigung direkt innerhalb des elektronischen Safes 10 gesetzt, so dass VN nicht den SDS kontaktieren muss. Dies hat den Vorteil, dass der SDS noch weniger Wissen über die Kommunikationsteilnehmer erhält, selbst wenn er sie nicht einzelnen Safes oder Prozessen zuordnen kann.
-
Der VN erzeugt im elektronischen Safe 10 eine Transferbox 12, die so gekennzeichnet ist, dass daraus lesende Safe-Nutzer 2 keine Authentifizierung benötigen. Der VN übergibt dem empfangenen Safe Nutzer 2 die ID der Transferbox 12 und eine TAN.
-
Als allgemeine Fälle gelten:
- • Im Fall (1) bezeichnet der Safe-Eigentümer 1 alle anderen Safe-Nutzer 2 als vertrauenswürdig, er möchte den Prozess in jedem Fall weiterlaufen lassen, nahezu jegliche Übergaben werden vom Eigentümer auf Kosten seiner Privatsphäre erlaubt.
- • Im Fall (2) traut der Safe-Eigentümer 1 der Übergabe von einem ersten Safe-Nutzer 2 zu einem zweiten Safe-Nutzer 2.
- • Im Fall (3) traut der Safe-Eigentümer 1 dem Empfänger, egal, wer diesem die Daten übergibt.
- • Im Fall (4) traut der Safe-Eigentümer 1 einer Übergabe von exakt einem Sender zu einem Empfänger im Rahmen eines Prozessschrittes, der Teil eines definierten Prozesses ist.
- • Im Fall (5) traut der Safe-Eigentümer 1 Sender und Empfänger genau dann, wenn der SDS feststellt, dass beide „eingetragene” Safe Nutzer 2 ohne besondere Vorkommnisse sind.
-
Detaillierung (Abläufe)
-
Zu Beginn eines Prozesses werden alle die Transferboxes 12 angelegt, in die der Safe-Eigentümer 1 Daten für den Prozess einstellt. Damit wird ermöglicht, dass die Teilnehmer (z. B. die Safe-Nutzer 2) nur wirklich die Daten erhalten, die sie entsprechend ihrer Aufgabe benötigen.
-
Alternativ müsste man dem ersten Prozessschritt alle in den folgenden Schritten erforderlichen Daten mitgeben, um weitere Anfragen zu vermeiden. Stattdessen werden die voraussichtlich notwendigen Daten bereits beim Start in den Transferboxes 12 hinterlegt, so dass keine Unterbrechung des Prozesses erforderlich wird.
-
Des Weiteren werden TANs eingestellt, mit denen die Safe Nutzer 1 eigene Datenübergaben organisieren können. Die TANs werden im Speicherbereich für processInformation (siehe 2) hinterlegt, bzw. den Safe-Nutzern 2 direkt in ihren Safe 10 zugestellt, wenn nur sie Zugriff erhalten sollen. Danach folgt der Mechanismus zum lesenden Zugriff auf die Transferboxen 12 in folgender Reihenfolge
-
• Abfragen der Berechtigung beim SDS, wenn man nicht als VN eingestuft ist
-
• Abfragen der Transferbox 12 beim Safe-Provider
-
• Abholen der Daten bei einem CloudSpaceProvider
-
Für das Schreiben der Daten werden weitere Berechtigungen benötigt, der Mechanismus ist derselbe:
-
• Abfragen der Berechtigung zum Erzeugen einer Transferbox 12 beim SDS (kann entfallen, wenn in der processInformation steht, dass eine bereits vom Safe-Eigentümer 1 erzeugte Transferbox 12 genutzt werden soll oder eine Einstufung als VN vorliegt)
- • Abfragen der Berechtigung zum Schreiben beim SDS, wenn man nicht als VN eingestuft ist
- • Schreiben der Daten beim CloudSpaceProvider
- • Beschreiben der Transferbox 12 beim Safe Provider.
-
In 3 ist die Initialisierung des Prozesses dargestellt, wobei Daten, die der Safe-Eigentümer erhält, aus Gründen der Übersichtlichkeit nicht dargestellt sind. Dabei richtet der Safe-Eigentümer 1 zuerst seine allgemeinen und besonderen Sicherheitseinstellungen ein, bevor er einen konkreten Prozesstyp instantiiert, die Transferboxen 12 erstellt und die Rechte entsprechend setzt. Dann wird dem Safe Nutzer 2 des ersten Prozessschrittes eine Berechtigung zum Zugriff auf eine Transferbox 12 in dessen Safe 10 gestellt. Damit hat der Prozess begonnen.
-
Der Safe-Eigentümer 1 verwendet seinen Safe-Client 100 um eine Transferbox 12 zu initialisieren. Dazu gibt er gegenüber dem SDS an, welchen Prozess er durchführen will. Der SDS gibt die Daten zurück, welche Personen in welchen Rollen involviert sind. Damit ist der Safe-Eigentümer in der Lage, eine Transferbox 12 zu konfigurieren, indem er festlegt, wer wann welche Zugriffsrechte auf die in der Transferbox 12 gespeicherten Daten haben darf.
-
Anschließend wird die Transferbox 12 beim Provider des elektronischen Safes 10 eingerichtet. Es wird eine TAN Liste vom SDS erfragt. Die TANs werden dann im elektronischen Safe 10 und/oder der Transferbox 12 gespeichert.
-
Anschließend werden die Zugriffsrechte auf die Transferbox 12 und dann die Transferbox 12 selbst eingerichtet (loop createAccessGrants).
-
Dann werden Datensätze vom Safe-Eigentümer 1 beim Safe-Provider gespeichert, aus denen dann, u. U. erst nach längerer Zeit, die Datensätze 15 für die Transferbox 12 ausgewählt werden (loop fillTransferBoxes).
-
In 3 ist u. a. ein CloudSpaceProvider aufgeführt, d. h. ein Speicherbetreiber.
-
In dem Sequenzdiagramm der 5 gilt, dass der Safe Nutzer 2 eine Referenz auf Process Ps_id/TransferBox box_id und das Zertifikat cert_ds vom SafeDirectoryService erhalten hat. Der Safe-Nutzer gilt nicht als so genannter Trusted User (auch als vertrauenswürdiger Nutzer VN bezeichnet).
-
In dem Sequenzdiagramm der 6 gilt, dass der Safe-Nutzer 2 eine Referenz auf Process ps_id/TransferBox box_id und das Zertifikat cert_TU bereits hat. Der Safer Nutzer gilt als so genannter Trusted User (auch als vertrauenswürdiger Nutzer VN bezeichnet).
-
In dem Sequenzdiagram der 7 gilt, dass der Safe-Nutzer 2 eine Referenz auf Process Ps_id/TransferBox box_id und das Zertifikat cert_ds vom SafeDirectoryService erhalten hat. Der Safe-Nutzer gilt nicht als so genannter Trusted User (auch als vertrauenswürdiger Nutzer VN bezeichnet).
-
Der Safe-Eigentümer kann Zugriffsrechte (AccessGrants) zwischenspeichern. In diesem Fall kann auf den Aufruf von getAccessGrant verzichtet werden.
-
Sind beim createAccessGrant TAN, Sender und/oder Empfänger (Receiver) angegeben, müssen diese auch beim getAccessGrant in übereinstimmender Form angegeben werden. Ansonsten sind sie optional.
-
Die detaillierte Parameterliste von storeSafeObject umfasst safe_id, cert_ds, box_id und den zu speichernden Inhalt.
-
In 5 und 6 umfasst writeTransferBox selbstverständlich auch die Übergabe des zu speichernden Inhalts.
-
Cert_ds, safe_id und box_id (3 und 7) sind Rückgabewerte von getAccessGrant. Cert_TU erhält der vertrauenswürdige Nutzer der Transferbox direkt vom Safe-Eigentümer 1 (wie auch safe_id und box_id) oder aus der processInformation.
-
Der Safe-Eigentümer 1 hat Zugriff auf alle seine Transferboxen, wenn er über seinen Safe zugreift.
-
Im Folgenden werden die wichtigsten Vorteile beschrieben:
- • Strukturell höhere Sicherheit in der Erfassung von Daten, deren Weitergabe und Pflege.
- • Benutzerkomfort bei der Erfassung von Daten
- • Besserer Schutz der Privatsphäre durch das automatisierte Vorverarbeiten von Daten des
- • Antragstellers, wodurch Folgeschritte mit pseudonymisierten Daten arbeiten können.
- • Der elektronische Safe 10 steht unter voller Kontrolle des Safe-Eigentümers 1, er kann genau verfolgen, wer seine Daten anfordert und wie lange diese Daten aufbewahrt werden. Der Nutzer als Souverän seiner Daten ist umso wichtiger als dass die umfassende Erhebung von Daten im Internet der Dinge immer engmaschiger wird.
- • Die Qualität der Daten, die in Workflows/Prozesse über den Safe eingespeist werden, ist höher als bisher. Wenn im Safe Zertifikate von Behörden gespeichert sind, sind diese Daten qualitativ hochwertiger als manuelle Eingaben des Eigentümers in Formulare.
- • Erhöhte Benutzerakzeptanz durch Vereinheitlichung der Datenerfassung ist möglich.
- • Die Freigabeaufforderungen erfolgen immer auf dieselbe Art und Weise.
- • Unabhängigkeit von IT-Dienstleistern und Software-Herstellern. Es kann nach diesem Modell für jede Rolle viele Anbieter geben, es wird viele Safeprovider, viele Storageprovider und
- • viele verschiedene Anbieter von Safe Clients 100, 201, 202 geben. Zusätzlich sind viele Dienstanbieter von
- • Formular-Abbildungen denkbar.
-
Folgende festzustellende Eigenschaften eines Verfahrensproduktes geben Hinweise darauf, dass das hier beschriebene Safe-Verfahren verwendet wurde:
- • Ein Produkt zur Speicherung von Daten und Dokumenten erlaubt es, mehrere unabhängige Dienstleister zum Abspeichern von Daten/Dokumenten einbinden, insbesondere, wenn Teile von Daten und Dokumenten bei jeweils unterschiedlichen Anbietern gespeichert werden.
- • Ein Produkt verifiziert das Trusted Compartment mit zeitlich gültigen Kennzeichen unter Verwendung eines externen Devices.
- • Der herkömmliche Ansatz der Erfassung von Daten über Formulare jeglicher Art wird durch die Erfassung der Daten in einem einzigen Tool abgelöst.
-
Der elektronische Safe 10 für Daten und Dokumente ist in der elektronischen Kommunikation zwischen Bürger und Behörde sowie in der elektronischen Kommunikation zwischen Unternehmen und Kunden sinnvoll. Auch im privaten Gebrauch, zur verfügbaren Bereitstellung der persönlichen Dokumenten und Daten ist er anwendbar. Soziale Netzwerke ohne zentrale Vermittlerinstanz auf Basis von Safes sind denkbar.
-
Im Folgenden wird ein Beispiel für die Verwendung einer Ausführungsform gegeben.
-
Im Rahmen der Umsetzung der EU-Dienstleistungsrichtlinie in den einzelnen Mitgliedsstaaten werden sogenannte einheitliche Ansprechpartner eingerichtet. Diese sollen Unternehmen bei der Interaktion mit der öffentlichen Verwaltung im Fall von Anträgen bspw. zur Gründung einer neuen Filiale unterstützen. Im Idealfall übernehmen diese Ansprechpartner eine Mittlerrolle zwischen den vielen beteiligten Behörden und dem Antragsteller. Dabei agieren sie im Auftrag des jeweiligen Unternehmens und können mit entsprechenden Rechten ausgestattet werden. In diesem Szenario kann der elektronische Safe eingesetzt werden.
-
Wenn z. B. ein Unternehmer (Safe-Eigentümer 1) eine neue Filiale seiner Bäckereikette gründen will, wendet er sich dazu an einen einheitlichen Ansprechpartner (EPA) in der Gemeinde Neustadt.
-
Zur Vorbereitung lädt er die notwendigen Formulare (Safe-Formulare 11) von einer Einrichtung (dies kann der EPA selbst oder ein Dienstleister sein), welche diese bereitstellt, in seinen elektronischen Safe 10. Der Unternehmer 1 füllt die Safe-Formulare 11 mit Hilfe seines Safes-Clients 100, 201, 202 aus, dabei kann er auf die bereits im elektronischen Safe 10 vorliegenden Informationen zurückgreifen.
-
Teile des Safe-Formulars 11 werden vorausgefüllt. Mit Hilfe der mitgeladenen Verarbeitungsregeln (Safe-Regeln 13) werden die Eingaben soweit möglich auf Plausibilität, Korrektheit und Vollständigkeit geprüft. Im Zwischenergebnis erfolgt eine automatisierte Vorbewertung des gestellten Antrags.
-
Aus dem SafeDirectoryService werden alle zur Bearbeitung notwendigen Safe-Nutzer 2 und deren Rollen im Prozess ermittelt.
-
Zur Umsetzung der einzelnen Bearbeitungsschritte müssen bspw. die lokalen Einrichtungen für Wirtschaftsförderung, Bauplanung, Katasterinformationen und Umwelt einbezogen werden. Da zu Beginn des Prozesses noch nicht alle Teilnehmer bekannt sind, die eventuell involviert werden müssen, übernimmt der EPA eine Steuerungsfunktion und wird vom Unternehmer berechtigt, die Daten des Unternehmers weiterzureichen.
-
Entsprechend ihrer jeweiligen Rolle werden automatisiert Übergabedatensätze 12 (Transferboxes) für den Prozess eingerichtet.
-
Der EPA findet in der Prozessinformation TAN-Nummern vor, die es ihm ermöglichen in späteren Prozessschritten weitere Einrichtungen ohne Rücksprache mit dem Unternehmer einzubinden.
-
Der Genehmigungsprozess mit unterschiedlichen beteiligten Behörden kann so ohne weitere Anfragen an den Unternehmer durchgeführt werden. Der Prozess kommt folglich zum Ziel, auch wenn der Unternehmer offline ist oder nicht gestört werden möchte.
-
Das Beispiel ist natürlich ohne weiteres auf andere Situationen übertragbar, in denen ein Safe-Eigentümer 1 vertrauliche Informationen bereit stellt, die sachlich und/oder zeitlich in besonderer Weise verarbeitet werden müssen.
-
Somit weist eine Ausführungsform des Verfahrens drei Bestandteile auf:
- – Eine Transferbox 12 mit Kopien von Teilen des elektronischen Safes 10 (oder Referenzen auf die tatsächlich benötigten Daten), wobei die Kopien auf den tatsächlich benötigten Bedarf reduziert sind.
- – Safe Clients 100, 201, 202, die verhindern, dass unbefugt Zugriff auf Daten im elektronischen Safe 10 ermöglicht wird.
- – Der SDS, d. h. eine vertrauenswürdige Komponente, die den Zugriff auf die Transferboxen 12 für nicht vertrauenswürdige Safe-Nutzer 2 steuert.
-
Bezugszeichenliste
-
- 1
- Safe-Eigentümer
- 2
- Safe-Nutzer
- 10
- elektronischer Safe
- 11
- Safe-Formulare
- 12
- Übergabedatensatz (Transferbox)
- 13
- Safe-Regeln
- 15
- Datensatz
- 16
- Bedingung
- 20
- erster Autorisierungsdatensatz
- 21
- zweiter Autorisierungsdatensatz
- 22
- Authentifizierungsvorrichtung
- 100
- Safe Client (Safe Eigentümer)
- 101
- Speicherbereich für eingehende Daten (inbox)
- 102
- Speicherbereich für ausgehende Daten (outbox)
- 103
- Inhalte des elektronischen Safes
- 104
- Speicherbereich mit gespeicherten Prozessen
- 201
- Safe Client (Safe Nutzer)
- 202
- Safe Client (Safe Nutzer)
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 7349987 A [0019]
- US 7206847 A [0019]
-
Zitierte Nicht-Patentliteratur
-
- Dirk Weber, Arnd Weber, Stephone Lo Presti, ”Requirements and Design Guidelines for a Trusted Hypervisor Interface”, p. 178–189 [0016]
- ”Future of Trust in Computing”, Proc. of the First International Conference Future of Trust in Computing 2008 [0016]
- Paul, A. et al. (2007), ”e-SAFE: An Extensible, Secure and Fault Tolerant Storage System”, Proc. IEEE Self-Adaptive and Self-Organizing Systems, (SASO '07), IEEE Press, pp. 257–268, doi: 10.1109/SASO.2007.21 [0018]
- Zhang, et al. (2008), „Towards A Secure Distribute Storage System”, Advanced Communication Technology, (ICACT 2008), IEEE Press, Apr. 2008, pp. 1612–1617, doi: 10.1109/ICACT.2008.4494090) [0019]
- Iyengar, A. et al. (1998), ”Design and Implementation of a Secure Distributed Data Repository”, In Proc. of the 14th IFIP Internat. Information Security Conf., pp. 123–135. [0019]
- Kubiatowicz et al. (2000), ”Oceanstore: An architecture for global-scale persistent storage”, Proc. of the ninth international conference on Architectural support for programming languages and operating systems (ASPLOS '00), ACM SIGARCH Computer Architecture News, Dec. 2000, pp. 190–201, ISSN: 0163–5964 [0019]
