DE10008153A1 - Verfahren zur Sicherung von in einer digitalen Verarbeitungseinheit abgelegten Daten gegen unbefugten Zugriff - Google Patents

Abstract

Gegenstand der Erfindung ist ein Verfahren zur Sicherung von in einer digitalen Verarbeitungseinheit abgelegten Daten gegen unbefugten Zugriff. Dabei liegen die Daten jeweils als aus einzelnen Datenfeldern bestehende Datensätze vor. Ausgewählten Datensätzen werden ein oder mehrere Sicherheitsdatenfelder hinzugefügt, welche Zugriffsmöglichkeiten und/oder Zugriffsrechte zur gegebenenfalls bedienerabhängigen Manipulation des betreffenden Datensatzes definieren.

Description

Die Erfindung betrifft ein Verfahren zur Sicherung von in einer digitalen Verarbeitungseinheit abgelegten Daten gegen unbefugten Zugriff, wonach die Daten jeweils als aus einzelnen Datenfeldern bestehende Datensätze vorliegen.

Derartige Sicherungsverfahren führen in der Praxis ein stiefmütterliches Dasein. Üblicherweise wird hier so vorgegangen, dass einer (berechtigten) Bedienperson, einem User, bestimmte "Pfade" durch eine aus den Datensätzen gebildete Datenbank vorgegeben werden. Die Auswahl der bedienerabhängigen Pfade erfolgt nach komplizierten Verfahren. Letztlich bemessen sich die Zugriffsrechte nach dem physikalischen Speicherplatz, welcher von dem betref­ fenden Datensatz eingenommen wird. Hierdurch versucht man mit großem Aufwand, nicht zugriffsberechtigte Bediener bzw. User von den für sie nicht bestimmten Daten fernzuhalten. - Derartige Vorgehensweisen können von ihrer Flexibilität und der umfangreichen Datenbehandlung her nicht überzeugen.

Der Erfindung liegt das technische Problem zugrunde, ein einfaches Verfahren zur Sicherung von in einer digitalen Verarbeitungseinheit abgelegten Daten gegen unbefugten Zugriff anzugeben, welches eine flexible Anpassung an bestimmte Zugriffsmöglichkeiten unter Berücksichtigung wechselnder Zugriffsrechte ermöglicht.

Zur Lösung dieses technischen Problems ist Gegenstand der Erfindung ein Verfahren zur Sicherung von in einer digitalen Verarbeitungseinheit abgelegten Daten gegen unbefugten Zugriff, wonach die Daten jeweils als aus einzelnen Datenfeldern bestehende Datensätze vorliegen, und wonach ausgewählten Datensätzen ein oder mehrere Sicher­ heitsdatenfelder programmtechnisch und automatisch hinzu­ gefügt werden, welche Zugriffsmaglichkeiten und/oder Zugriffsrechte zur gegebenenfalls bedienerabhängigen Bearbeitung bzw. Manipulation des betreffenden Datensatzes definieren. Folglich geschieht die Flankierung der bestehenden (ausgewählten) Datensätze mittels der Sicher­ heitsdatenfelder im Rahmen eines hierfür (speziell) entwickelten (Rechner-)Programms - gleichsam automatisch.

Unter einem Datenfeld ist nach allgemeinem Verständnis ein Informationsträger zu verstehen, welcher Informationen derselben Art speichert. Bei einer Adressdatenbank sind beispielsweise eigene Datenfelder für den Vornamen, den Nachnamen, und die Adresse usw. der hierin gespeicherten Personen verwirklicht. Im Rahmen industrieller Abläufe können in einzelnen Datenfeldern auch sämtliche für die Realisierung eines bestimmten Projektes erforderlichen Informationen abgelegt werden. Ja es ist sogar denkbar, mit einzelnen Datenfeldern bzw. Datensätzen Dateien zu identifizieren, die nach (berechtigtem) Zugriff auf den entsprechenden Datensatz gelesen und gegebenenfalls bearbeitet werden können.

Mehrere Datenfelder sind zu einem Datensatz zusammen­ gefasst, welcher sich durch einen Schlüssel oder auch einen Namen eindeutig identifizieren lässt. Bei einer Adress­ datenbank lässt sich ein solcher Datensatz beispielsweise mit dem Nachnamen der Person, deren Daten hier gespeichert sind, kennzeichnen. Bei den vorerwähnten projektbezogenen Daten ist es denkbar, hier auf einen Projektnamen zurückzugreifen. In (Konto-)Buchungsdatenbanken können als Namen auch Vorgangsnummern vergeben werden.

Selbstverständlich empfiehlt es sich im Rahmen der Erfindung, nur die Datensätze mit einem oder mehreren Sicherheitsdatenfeldern zu flankieren, die tatsächlich gegenüber unbefugtem Zugriff zu schützen sind. Allgemein verbindliche Mitteilungen, wie beispielsweise datumsab­ hängige Geburtstagsgrüße oder andere unsensible Daten lassen sich hiervon grundsätzlich ausnehmen. Es ist aber eine Auswahl sensibler Datensätze möglich und auch gewollt.

Im Einzelnen schlägt die Erfindung vor, dass zumindest ein Sicherheitsdatenfeld in Form eines Buchungsdatenfeldes vorgesehen ist, welches ab dem Zeitpunkt seiner Festlegung bzw. Erstellung Änderungen an dem hiermit flankierten Datensatz unterbindet. Das belegte Buchungsdatenfeld sorgt also dafür, dass Änderungen oder Manipulationen an dem hiermit flankierten Datensatz nicht (mehr) vorgenommen werden können. Der solchermaßen "gebuchte" Datensatz verbleibt also (nach Belegung des Buchungsdatenfeldes) unverändert in der Datenbank.

Es sei denn, dieser Datensatz wird "storniert", was durch die Belegung zumindest eines weiteren Sicherheitsdaten­ feldes in Form eines Stornierungsdatenfeldes möglich ist. Denn dieses Stornierungsdatenfeld sorgt ab dem Zeitpunkt seiner Festlegung dafür, dass der hiermit flankierte Datensatz für allgemeine Zugriffe gesperrt ist. D. h. im Umkehrschluss, dass der "stornierte" Datensatz bei einem speziellen Zugriff unverändert wenigstens ausgelesen werden kann. Dies lässt sich bedienerabhängig festlegen.

Hierzu kann üblicherweise ein additives Bedienerdatenfeld realisiert werden, welches bedienerabhängig bestimmte Zugriffsrechte mit einstellbarer Priorität definiert. So ist es denkbar, dass ein übergeordneter Bediener, ein sogenannter "Supervisor", uneingeschränkten Zugriff auch auf "stornierte" Datensätze hat. Selbstverständlich sind auch zwei oder mehr übergeordnete Bediener denkbar. In diesem Zusammenhang kann die Sicherheit programmtechnisch noch weiter gesteigert werden, indem bestimmte Änderungen oder Vorgänge nur dann vollführt werden, wenn z. B. beide übergeordneten Bediener zustimmen. Dies kann voneinander abhängig oder unabhängig geschehen. Folglich wird im Rahmen der Erfindung wahlweise eine Manipulation an dem betreffenden Datensatz nur dann durchgeführt, wenn die entsprechenden Bediener gemeinsam zugestimmt haben.

Dagegen sind diese Datensätze für die meisten Anwender nicht (mehr) lesbar und werden auch in normale Anwendungen, wie Kalkulationen, Buchungen etc. nicht (mehr) eingefügt. Die "stornierten" Datensätze liegen also - wenn man so will - nur mehr noch virtuell vor. Jedenfalls kann beispielsweise über ein zusätzliches Bedienerdatenfeld selbst ein "stornierter" Buchungssatz unverändert gelesen werden. Ein Überschreiben oder Ändern wird man dabei vernünftigerweise nicht zulassen, wenngleich eine solche Option natürlich denkbar ist.

Darüber hinaus schlägt die Erfindung wenigstens ein weiteres Sicherheitsdatenfeld in Form eines Löschungs­ datenfeldes vor. Dieses Löschungsdatenfeld arbeitet in gewisser Hinsicht wie das Stornierungsdatenfeld. Denn auch in diesem Fall werden ab dem Zeitpunkt der Festlegung des Löschungsdatenfeldes der oder die hiermit flankierten Datensätze für allgemeine Zugriffe gesperrt. Zusätzlich führt die Belegung des Löschungsdatenfeldes jedoch noch dazu, dass nach einem festgelegten Zeitablauf eine (zwangsweise) Löschung des betreffenden Datensatzes veran­ lasst wird. Hierin unterscheidet sich das belegte Löschungsdatenfeld von dem Stornierungsdatenfeld, welches grundsätzlich nicht - oder nicht sofort - zu einer Löschung des hiermit flankierten Datensatzes korrespondiert.

Dadurch, dass selbst ein "gelöschter" Datensatz zumindest innerhalb des festgelegten Zeitablaufes wenigstens "virtuell" noch zur Verfügung steht, lässt sich auch dessen Inhalt (noch) auslesen, und zwar wiederum nur von bestimmten Bedienern, beispielsweise dem Supervisor. Ein typischer Wert für den betreffenden Zeitablauf liegt bei vier Wochen. Dieser Zeitablauf kann sich ab der Erstellung des mit dem Löschungsdatenfeld flankierten Datensatzes bemessen. Grundsätzlich wird jedoch so vorgegangen, dass der Zeit-Nullpunkt für den angesprochenen Zeitablauf mit der Belegung des Löschungsdatenfeldes zusammenfällt.

Darüber hinaus liegt es im Rahmen der Erfindung, jeden einzelnen ausgewählten Datensatz optional mit einem Buchungsdatenfeld und/oder einem Stornierungsdatenfeld und/oder einem Löschungsdatenfeld zu flankieren. Dabei kann natürlich unterschiedlichen Datenfeldinhalten Rechnung getragen werden. In der Regel wird man jedoch jeden ausgewählten Datensatz mit sämtlichen vorerwähnten Sicher­ heitsdatenfeldern ausrüsten, um eine möglichst umfassende und einfach zu handhabende Funktionalität zu erreichen.

Ein Beispiel hierfür ist ein unzutreffender Adressdaten­ satz. Wenn beispielsweise ein Fehler in der Adresse der zugehörigen Person und/oder Firma bemerkt wird, so eröffnet die Erfindung grundsätzlich zweierlei Möglichkeiten, diesen Datensatz zu korrigieren. Zum einen kann der Datensatz "storniert" werden, was dazu führt, dass bei eventuellen Unsicherheiten hinsichtlich der neuen Adresse zumindest der Supervisor noch die stornierte "alte" Adresse auslesen kann.

Wenn jedoch eine endgültige Änderung ohne verbleibenden Zweifel gewünscht wird, wird man den entsprechenden Datensatz "löschen". Denn dies führt zwangsläufig dazu, dass nach dem bereits erwähnten Zeitablauf die falschen Daten auch physikalisch aus dem Speicher entfernt werden.

Anhand dieses Beispieles wird deutlich, dass jeder Datensatz je nach dessen Inhalt einem gleichsam zwei­ stufigen Löschungsvorgang unterzogen werden kann. Seine Stornierung führt lediglich zu einem vordergründigen Ausschluss aus der Datenbank, wobei der Datensatz zumindest virtuell und für bestimmte Bedienpersonen unverändert noch ausgelesen werden kann. Eine Löschung erreicht einen ähnlichen Zustand, allerdings nur für eine eng begrenzte Zeit mit anschließender physikalischer Entfernung.

Um in der vorhandenen Datenbank gleichsam Selbstreinigungs­ kräfte wirken zu lassen, schlägt die Erfindung ferner zumindest ein Lebensdauerdatenfeld vor, welches zusätzlich zu dem wenigstens einen Sicherheitsdatenfeld realisiert ist. Dieses Lebensdauerdatenfeld definiert einen bestimmten Zeitraum zwischen einer Erstellung des hiermit flankierten Datensatzes und seiner obligatorischen Löschung. Mit anderen Worten werden die mit dem Lebensdauerdatenfeld ausgerüsteten Datensätze zwangsweise gelöscht, und zwar nach dem angesprochenen Zeitraum.

Im Vergleich zu dem mit dem Löschungsdatenfeld vorgegebenen Zeitablauf sorgt die Erfindung darüber hinaus dafür, dass dieser Zeitablauf geringer als der vom Lebensdauerdatenfeld festgelegte Zeitraum bemessen ist. Dies ist vernünftig und sinnvoll, weil "gelöschte" Datensätze selbstverständlich einen deutlich geringeren Verfallzeitraum als die übrigen Datensätze aufweisen sollen. Ansonsten wäre die Funktion "Löschen" sinnlos.

Schließlich wird vorzugsweise zusätzlich zu dem wenigstens einen Sicherheitsdatenfeld ein Bedienerdatenfeld reali­ siert, wie es bereits angesprochen wurde. Dieses Bedienerdatenfeld definiert bedienerabhängig vorgegebene Zugriffsrechte mit einstellbarer Priorität. D. h., im Rahmen dieses Bedienerdatenfeldes kann festgelegt werden, welcher Bediener bzw. User auf den betreffenden Datensatz überhaupt zugreifen darf.

Im einfachsten Fall gelingt dies durch eine entsprechende Ablage der zugriffsberechtigten Usernummern. Zusätzlich eröffnet die Erfindung noch die Möglichkeit, bestimmte Prioritäten bei den Zugriffsrechten festzulegen. So kann für Sachbearbeiter vereinbart werden, dass diese lediglich den entsprechenden Datensatz erstellen und gegebenenfalls auch ändern dürfen. Dagegen ist es beispielsweise ihrem Vorgesetzten, dem Abteilungsleiter, vorbehalten, zusätzlich den besagten Datensatz löschen zu können. Die Festlegung der Lebensdauer des besagten Datensatzes obliegt dagegen beispielsweise dem zuständigen Direktor oder EDV-Leiter. Schließlich verfügen z. B. nur die Vorstandsmitglieder einer Firma über die Berechtigung, auch stornierte und gelöschte Datensätze lesen zu können. Dies alles wird im Rahmen des Bedienerdatenfeldes mit den vorgegebenen Zugriffsrechten einstellbarer Priorität festgelegt.

Üblicherweise sind zur Verarbeitung der mit dem oder den Sicherheitsdatenfeld(ern) bzw. Zusatzdatenfeld(ern) (Lebensdauerdatenfeld, Bedienerdatenfeld, etc.) flankierten Datensätze (Rechner)Programme vorgesehen, welche programm­ technisch und automatisch zur Interpretation der betref­ fenden Datenfelder in die Lage versetzt werden. D. h. nichts anderes, als das den auf die unveränderte Datenbank zugreifenden Programmen per eigenem, speziellem Programm Befehle hinzugefügt werden, welche die zusätzlichen Datenfelder (Sicherheitsdatenfelder, Zusatzdatenfelder) interpretieren und in dem beschriebenen Sinn manipulieren. Hierdurch ist eine besonders einfache Anpassung der Software möglich. Mit anderen Worten berücksichtigen die vorgenannten Befehle im Einzelnen die beschriebenen Verfahrensweisen (bei ohnehin schon vorhandenen Programmen, die auf die unveränderte Datenbank bzw. Datenbasis arbeiten).

Folglich werden nicht nur die beschriebenen Sicherheits­ datenfelder und Zusatzdatenfelder von einem speziellen Programm hinzugefügt, sondern auch erforderliche Befehle in vorhandene Programme eingefügt, damit die zusätzlichen Datenfelder sinngemäß und im Rahmen des beschriebenen Verfahrens genutzt und interpretiert werden können.

Im folgenden wird die Erfindung anhand eines Beispieles näher erläutert.

Die anliegende Tabelle 1 zeigt beispielhaft einen Datensatz, wie er im Rahmen der Erfindung erzeugt wird, um ausgewählte Datensätze gegen unbefugten Zugriff zu sichern. Dieser Datensatz ist in einer digitalen Verarbei­ tungseinheit abgelegt und kann mittels eines dortigen (Rechner-)Programms abgerufen werden.

Im Einzelnen schlägt sich der ausgewählte Datensatz in den Feldern bzw. Datenfeldern 1 bis 10 nieder und ist als "eigentlicher" Datensatz unter der Rubrik "Feldinhalt" verzeichnet.

Neben diesem eigentlichen Datensatz in den Datenfeldern 1 bis 10 finden sich erfindungsgemäß noch ein Erstellungs­ datenfeld 11, Änderungsdatenfeld 13, Buchungsdatenfeld 15, Stornierungsdatenfeld 17, Löschungsdatenfeld 19, Lebensdauerdatenfeld 21 und Bedienerdatenfeld 23. Diese sind den jeweiligen Feldern mit den zugehörigen Feldinhalten zuge­ ordnet. Die Datenfelder 11 bis 24 gemäß Tabelle 1 werden im Rahmen eines eigenen speziellen (Rechner-)Programmes erzeugt bzw. dem "eigentlichen" Datensatz in den Daten­ feldern 1 bis 10 hinzugefügt. Ein weiteres spezielles (Rechner-)Programm sorgt dafür, dass den auf die "eigent­ lichen" Datensätze zugreifenden Softwareprogrammen Befehle hinzugefügt werden, welche in der Lage sind, die zusätzlichen Datenfelder 11 bis 24 zu interpretieren.

Auf diese Weise werden die "eigentlichen" Datensätze in den jeweiligen Datenfeldern 1 bis 10 automatisch und programm­ technisch um die zusätzlichen Datenfelder 11 bis 24 erweitert. Entsprechendes geschieht mit den auf die "eigentlichen" Datensätze in den Datenfeldern 1 bis 10 zugreifenden Programme. Denn diese werden mit Hilfe eines wiederum eigenständigen und speziellen Programmes in die Lage versetzt, die entsprechenden (zusätzlichen) Daten­ felder 11 bis 24 - wie beschrieben - interpretieren zu können. Auch eine Manipulation dieser besagten Datenfelder ist programmtechnisch und automatisch möglich. Hier ist es beispielsweise denkbar, für die entsprechenden Feldinhalte zu sorgen.

Im Rahmen des Ausführungsbeispieles ist zu jedem zusätz­ lichen Sicherheitsdatenfeld 15, 17, 19 auch der jeweilige Bediener in einem eigenen Feld abgelegt, wenngleich dies natürlich nicht zwingend ist. Vergleichbares gilt für die übrigen Zusatzdatenfelder 11, 13, 21 und 23. So beinhaltet beispielsweise das Erstellungsdatenfeld 11 den Zeitpunkt der Erstellung des "eigentlichen" Datensatzes in den Datenfeldern 1 bis 10. Dieser ist im Datenfeld 11 abgelegt. Der die Erstellung durchführende Bediener findet sich im Datenfeld 12.

Das Änderungsdatenfeld 13 dokumentiert den Zeitpunkt der letzten Änderung der Datenfelder 1 bis 10. Im zugehörigen Feld Nr. 14 ist der ändernde Bediener verzeichnet. Anhand dieses Änderungsdatenfeldes 13 ist erfindungsgemäß eine Kontrolle dergestalt möglich, ob es sich bei dem vorangestellten Datensatz insgesamt um einen solchen handelt, der gebucht, storniert oder gelöscht worden ist. Denn ein solcher Datensatz kann und darf nicht geändert werden.

Im Rahmen des Buchungsdatenfeldes 15 wird u. a. der Zeit­ punkt der Buchung festgelegt. Die Belegung dieses Feldes bzw. Datenfeldes hat zur Folge, dass Änderungen an dem "eigentlichen" Datensatz in den Feldern 1 bis 10 nicht (mehr) vorgenommen werden können. Ein Zugriff auf das Änderungsdatenfeld 13 bei "gebuchtem" Datensatz führt also dazu, dass hier, im Änderungsdatenfeld 13, eine ent­ sprechende Fehlermeldung erzeugt wird bzw. an den Bediener übermittelt wird.

Im Rahmen der Buchung lassen sich grundsätzlich Prozesse jeglicher Art genehmigen, die ab dem betreffenden Buchungs­ zeitpunkt zuverlässig zur Verfügung stehen (sollen). Der "gebuchte" Datensatz verbleibt also unverändert in der Datenbank, und zwar theoretisch einen unendlichen Zeitraum lang, sofern keine begrenzte Lebensdauer im Rahmen des nachfolgend noch zu diskutierenden Lebensdauerdatenfeldes 21 vereinbart ist. Auch das Buchungsdatenfeld 15 ist von einem Feld 16 flankiert, in welchem der buchende Bediener abgelegt wird.

Mit Hilfe des Stornierungsdatenfeldes 17 lässt sich erreichen, dass der "eigentliche" Datensatz in den Datenfeldern 1 bis 10 bei üblichen Abfragen in Formularen und Berichten nicht (mehr) erscheint. Dennoch können die Datenfelder 1 bis 10 ausgelesen werden, allerdings nur von einer Person mit spezieller Berechtigung. Über diese verfügt im Rahmen des Ausführungsbeispiels der zuvor bereits angesprochene Supervisor. Eventuell sind auch zwei (oder mehr) übergeordnete Bediener denkbar, die beispielsweise durch (voneinander abhängige oder unabhängige) Zustimmung für eine entsprechende Feldbelegung oder eine gewünschte Manipulation sorgen. Auf diese Weise lässt sich im Sinne einer gleichsam Doppelschlüsselsicherung ein besonders ausgeprägter Datenschutz erreichen. - Auch das Stornierungsdatenfeld 17 ist von einem Feld 18 flankiert, in dem die den stornierenden Bediener betreffenden Daten abgelegt sind.

Mit Hilfe des Löschungsdatenfeldes 19 gelingt eine ver­ gleichbare Funktionalität wie beim Stornierungsdatenfeld 17. Mit anderen Worten sorgt eine entsprechende Belegung dieses Feldes dafür, dass der "eigentliche" Datensatz nicht mehr von einem normalen Bediener gelesen oder auch geändert werden kann. Stornierungs- und/oder Löschungsbefehle führen also dazu, dass die Datenfelder 1 bis 10 in eine Art virtuellen Speicher überführt werden. Auch hier wird dem Supervisor unverändert ein Leserecht eingeräumt.

Im Unterschied zum Stornierungsdatenfeld 17 wird bei Belegung des Löschungsdatenfeldes 19 zusätzlich noch ein Zeitablauf T₁ festgelegt. Nach Beendigung dieses Zeitab­ laufes T₁ erfolgt eine Löschung des gesamten dargestellten Datensatzes. Selbstverständlich ist auch das Löschungs­ datenfeld 19 mit einer entsprechenden Angabe über den löschenden Bediener im Feld 20 ausgerüstet.

Insgesamt sorgen also Belegungen des Stornierungs- und/oder Löschungsdatenfeldes 17, 19 dafür, dass der betreffende Datensatz markiert und in einem virtuellen Speicher abgelegt wird. Das physikalische Löschen eines stornierten Datensatzes wird am Ende dessen Gesamtlebensdauer vorgenommen, während ein gelöschter Datensatz bereits nach der Zeit T₁ physikalisch aus dem Speicher entfernt wird. Dieser Zeitraum T₁ kann mehrere Wochen, beispielsweise vier Wochen, betragen. Grundsätzlich ist es möglich, einen gelöschten - aber nicht einen stornierten - Datensatz (natürlich innerhalb des Zeitraumes T₁) wiederzubeleben.

Dies ist ein weiterer Unterschied zum Stornierungsvorgang. Das Lebensdauerdatenfeld 21 sorgt für eine obligatorische Einstellung des Verfallsdatums des gesamten Datensatzes. Dieser wird also nach der eingestellten Lebensdauer bzw. einem zugehörigen Zeitraum T₂ mit T₁ < T₂ zwangsweise gelöscht. Selbstverständlich wird das Lebensdauerdatenfeld 21 nur optional bei solchen Datensätzen belegt, die beispielsweise zeitabhängige Daten enthalten, welche nach einem gewissen Zeitraum mit Sicherheit überholt sind. Hierbei kann es sich um Nachrichten handeln, die temporäre Ereignisse, wie z. B. Messen od. dgl. betreffen.

Im Rahmen des Bedienerdatenfeldes 23 wird die bereits angesprochene Festlegung des Zugriffs auf den Datensatz als solche festgelegt. Im einfachsten Fall können hier Usernummern hinterlegt werden, die zu Bedienern korrespondieren, welche auf den entsprechenden Datensatz zugreifen dürfen. Eine weitere Diversifizierung in diesem Zusammenhang ist durch das Datenfeld 24 möglich, welches prioritätsabhängige Zugriffsrechte definiert. Diese sind in der Tabelle 2 ("prioritätsabhängige" Zugriffsrechte) im Einzelnen aufgelistet.

Man erkennt hier, dass die geringste Priorität dem Erstellen des "eigentlichen" Datensatzes zukommt. Dieses Recht wird man zumeist sämtlichen zugriffsberechtigten Bedienern einräumen. Mögliche Änderungen des Datensatzes stellen die nächste Stufe dar und dürfen nur von einer demgegenüber geringeren Personenzahl durchgeführt werden. Dies gilt erst recht für das "Löschen" des Datensatzes, welches zumeist nur Vorgesetzten vorbehalten bleibt, beispielsweise dem Leiter der Buchhaltung. Den weiteren in der Liste angegebenen Tätigkeiten, wie "Buchen" und "Stornieren" kommt naturgemäß eine nochmals erhöhte Priorität zu.

Im Rahmen der Priorität 6 lässt sich das Recht an dem Datensatz vergeben. Denkbar ist es hier, dass ein Vorge­ setzter einem Untergebenen auf diese Weise den Zugriff auf eigentlich nur für ihn bestimmte Datensätze ermöglicht. D. h., der Rechtsinhaber kann das Zugriffsrecht weitergeben, allerdings nur im Rahmen seiner Zugriffsmöglichkeiten. Selbstverständlich kann dieses Weitergaberecht auf bestimmte Rechte und/oder Datensätze beschränkt werden. So ist es denkbar, dass der Leiter der Buchhaltung nur bestimmte Buchungssätze überhaupt an seine Mitarbeiter im Rahmen der Rechtevergabe nach der Priorität 6 weiterleiten darf.

Noch höher einzustufen ist das Recht, die Lebensdauer setzen und ändern zu können, wie dies im Rahmen der Priorität 7 zum Ausdruck kommt. Darüber ist nur noch das Eigentums- und Leserecht angesiedelt. Im erstgenannten Fall kann der Bediener das "Eigentum" an dem entsprechenden Datensatz erklären, so dass ihm hiermit automatisch alle nachgeordneten Rechte 1 bis 7 zur Verfügung stehen. Dies hat zur Folge, dass kein anderer Bediener entsprechende (Eigentums-)Rechte an diesem Datensatz (mehr) geltend machen kann.

Das Leserecht ermöglicht schließlich dem Rechtsinhaber den lesenden Zugriff auf sämtliche Datensätze, also auch solche, die storniert und/oder gelöscht sind. Einem Bediener, der über die Rechte bzw. Prioritäten 1 bis 8 verfügt, wird automatisch auch das Leserecht nach der Ziffer 9 eingeräumt.

Insgesamt lässt sich durch die beschriebenen und im Rahmen der Erfindung definierten prioritätsabhängigen Zugriffs­ rechte erreichen, dass beispielsweise im Rahmen der Ziffer 6 ein Abteilungsleiter seinem Mitarbeiter einen Brief zur Kenntnis bringen kann, der normalerweise nicht für den Mitarbeiter bestimmt ist. Der Mitarbeiter kann diesen Brief allerdings selber nicht weitergeben, weil ihm hierfür das Zugriffsrecht bzw. die Priorität 6 fehlt.

Das Eigentumsrecht nach der Ziffer 8 ermöglicht es beispielsweise einem (Abteilungs-)Leiter, einen bestimmten (nur für ihn vorgesehenen) Termin in der Datenbank abzulegen, ohne dass irgendein anderer Bediener diesen Termin bzw. den dahinterstehenden Datensatz überhaupt zur Kenntnis nehmen kann. Selbstverständlich sind dann auch keine Änderungen od. dgl. Manipulationen an diesem Datensatz möglich, da bekanntlich nur der Eigentümer über diesen Datensatz, sprich den Termin, verfügen kann. Im einfachsten Fall ermöglichen also die Datenfelder 23 und 24 die bedienerabhängige Eingrenzung des Zugriffs auf den "eigentlichen" Datensatz in den Feldern 1 bis 10, wobei dieses Zugriffsrecht noch durch die der jeweiligen Usernummer zugeordnete und in Tabelle 2 abgelegte Priorität beschränkt bzw. vorgegeben ist.

Jedenfalls lässt sich durch die erfindungsgemäß dem "eigentlichen" Datensatz hinzugefügten Felder, insbesondere Sicherheitsdatenfelder 15, 17 19 und Zusatzfelder 11, 13, 21 und 23, erreichen, dass der Datensatz mit Leben gefüllt wird, welcher eine Abbildung der zumeist komplexen Wirklichkeit darstellt. So können Anforderungen wie "Herr A darf den Datensatz lesen" problemlos im Rahmen des Bedienerdatenfeldes umgesetzt werden, indem dem Bediener A das entsprechende Zugriffsrecht eingeräumt wird.

Daneben sind aber auch Einschränkungen dergestalt denkbar, dass beispielsweise der Lebenssachverhalt "Herr A darf nur Datensätze lesen, die ein bestimmtes Kriterium erfüllen" problemlos abgebildet werden kann. Hierfür muss zunächst das Bedienerdatenfeld 23 für den entsprechenden Zugriff von Herrn A sorgen. Außerdem ist es denkbar, dass Herr A die für ihn bestimmten Datensätze lediglich erstellen darf. Dies wird im Rahmen der prioritätsabhängigen Zugriffsrechte durch die entsprechend eingestellte Priorität 1 gemäß Tabelle 2 bewerkstelligt.

Tabelle 2

Prioritätsabhängige Zugriffsrechte

Claims (10)

1. Verfahren zur Sicherung von in einer digitalen Verarbeitungseinheit abgelegten Daten gegen unbefugten Zugriff, wonach die Daten jeweils als aus einzelnen Datenfeldern bestehende Datensätze vorliegen, und wonach ausgewählten Datensätzen ein oder mehrere Sicherheits­ datenfelder automatisch hinzugefügt werden, welche Zugriffsmöglichkeiten und/oder Zugriffsrechte zur gegebe­ nenfalls bedienerabhängigen Bearbeitung des betreffenden Datensatzes definieren.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zumindest ein Sicherheitsdatenfeld in Form eines Buchungs­ datenfeldes vorgesehen ist, welches ab dem Zeitpunkt seiner Festlegung Änderungen an dem hiermit flankierten Datensatz unterbindet.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekenn­ zeichnet, dass zumindest ein Sicherheitsdatenfeld in Form eines Stornierungsdatenfeldes vorgesehen ist, welches ab dem Zeitpunkt seiner Festlegung den hiermit flankierten Datensatz für allgemeine Zugriffe sperrt.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass zumindest ein Sicherheitsdatenfeld in Form eines Löschungsdatenfeldes vorgesehen ist, welches ab dem Zeitpunkt seiner Festlegung den hiermit flankierten Datensatz für allgemeine Zugriffe sperrt und zusätzlich nach einem festgelegten Zeitablauf (T₁) eine Löschung des betreffenden Datensatzes veranlasst.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass ein Datensatz wahlweise mit einem Buchungsdatenfeld und/oder einem Stornierungsdatenfeld und/oder einem Löschungsdatenfeld flankiert wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass zumindest ein Lebensdauerdatenfeld zusätzlich zu dem wenigstens einen Sicherheitsdatenfeld vorgesehen ist, welches einen bestimmten Zeitraum (T₂) zwischen einer Erstellung des hiermit flankierten Daten­ satzes und seiner obligatorischen Löschung definiert.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der durch das Löschungsdatenfeld vor­ gegebene Zeitablauf (T₁) geringer als der vom Lebensdauer­ datenfeld festgelegte Zeitraum (T₂) bemessen ist, d. h., das gilt T₁ < T₂.

8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass zusätzlich zu dem wenigstens einen Sicherheitsdatenfeld ein Bedienerdatenfeld realisiert wird, welches bedienerabhängig vorgegebene Zugriffsrechte mit einstellbarer Priorität definiert.

9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass zur Verarbeitung der mit dem oder den Sicherheitsdatenfeld(ern) bzw. Zusatzdatenfeld(ern) (Lebensdauerdatenfeld, Bedienerdatenfeld, Erstellungs­ datenfeld, Änderungsdatenfeld, etc.) flankierten Daten­ sätze (Rechner-)Programme vorgesehen sind, welche programmtechnisch und automatisch zur Interpretation der betreffenden Datenfelder in die Lage versetzt werden.

10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass ein oder mehrere übergeordnete Bediener uneingeschränkten Zugriff auf sämtliche Datensätze haben, wobei wahlweise eine Manipulation an dem betreffenden Datensatz nur dann durchgeführt wird, wenn die Bediener gemeinsam zugestimmt haben.