| 

.NET C# Java Javascript Exception

10
Ich suche eine Idee, wie ich sicherstellen kann, dass die Zeilen in bestimmte Tabellen nach einem bestimmten Zeitpunkt nicht mehr verändert wurden - auch nicht von mir als "Entwickler".

Ich habe eine Zeiterfassungsanwendung erstellt. Auf Basis dessen werden die Gehälter gezahlt. Bis zu einem bestimmten zeitpunkt dürfen Daten noch geändert werden. Aber ab dem Tag X, geht das über die Anwendung nicht mehr.

Da ich die Anwendung geschrieben habe, weiß ich welche Tabellen die Stunden enthalten und welche GUID "meine" ist - also ratz fatz mit SQL Manager die DB angezogen und meine Überstunden angepasst.

Das soll ich zukünftig nicht mehr dürfen *Warum wohl* *grins*

Alle Ideen, die ich dazu habe, sind irgentwie recht lückenhaft. Wenn ich z.B. ein neues feld einbaue, wo eine Prüfsumme reinkommt, dann brauch ich mir nur ein Tool schreiben, was die Prüfsumme mit meinen Überstunden versieht - dann ändere ich nicht nur die Stunden, sondern auch noch die Prüfsumme.

Daher die Frage: Wie machen dass resivionssichere Datenbankanwendungen. Denn wenn ich steuern kann, wie die Prüfungsmechanismen gehen, kann ich sie wohl auch "umgehen".

Vielleicht hat ja jemand eine Idee dazu

PS: Nur zur Klärung - ich habe meine Überstunden natürlich NIE nachträglich geändert. Es geht mir hier auch eher um die Vorgehensweise und nicht um ein konkretes Beispiel. Außerdem ist die "Arbeitszeiterfassungs-Anwendung" nur als Beispiel genannt, um mein Problem zu verdeutlichen.
04.07.2012
MyKey0815 1,6k 2 9
6 Antworten
2
Wenn du in die Checksumme immer die Checksumme des vorherigen Eintrags einbeziehst, ist es nicht möglich die Daten zu ändern.

Ein Beispiel:

Datum____ Beginn Ende_ Mitarbeiter_____ CheckSum
--------------------------------------------------------
01.01.2012 | 08:00 | 17:30 | Mustermann M. | 0f765b3
02.01.2012 | 08:00 | 16:45 | Andere Mitarbe. | 5g5646c = (checksumme(currentrow + 0f765b3))
02.01.2012 | 07:30 | 16:50 | Mustermann M. | 17ff904 = (checksumme(currentrow + 5g5646c ))
....

Um eine Manipulation vorzunehmen, müsstest du alle nachfolgenden Checksummen neu berechnen.
04.07.2012
Floyd 14,5k 3 9
Floyd 14,5k 3 9
Gute Idee. Dazu müsste ich dann aber immer den letzten eingefügten Datensatz zunächst ermitteln, bevor ich den neuen Datensatz schreibe. Ich verwende als FK immer eine zufällig erzeugte GUID, daher ist das sortieren wohl nicht die ideale Lösung. Aber dennoch finde ich deinen Ansatz echt gut.
MyKey0815 04.07.2012
1
Wenn du einen Timestamp als CreateDate mitführst, kannst du daran sortieren.
Floyd 05.07.2012
2
Wenn der Entwickler aber "weiß" wie die Checksummenberechnung erfolgt: Was spricht dagegen, dass er mit einem Tool eine entsprechende Neuberechung (aller DB-Einträge) durchführt? Ich steh ein bisschen auf dem Schlauch :)
puls200 05.07.2012
Kryptografisch sichere Checksummen (auch Hash's) kannst du nicht mal eben für ein paar hundert oder tausend Datensätze neu berechnen.

Der Aufwand steigt exponenzial mit der Anzahl der Runden die innerhalb des Algorithmus gedreht werden.
Sollte eine Berechnung für eine Checksumme z.b. nur 10 Sekunden dauern, so dauert es bei 1000 Einträgen bereits 2,777 Stunden.
Im Ereignisslog (Beginn Arbeitszeit, Beginn Pause, ...) bei uns auf Arbeit sind in den letzten 5 Jahren bereits 500.000 Einträge entstanden. Diese alle neu zu berechnen würde 57 Tage (~ 2 Monate) dauern.
Floyd 05.07.2012
Und 10 Sekunden ist für ein einen Hash nicht sonderlich viel.
Floyd 05.07.2012
Letztendlich kann man die Grundidee auch weiter ausbauen, so wie du es in deinem Post getan hast.

Das einfügen einen zusätzlichen Salts, die Hash/Checksum basierend auf dem vorherigen UND nachfolgendem Datensatz erzeugen .....
Floyd 05.07.2012
1
Dann bleibt aber die Schwierigkeit, dass du beim Löschen eines Datensatzes alle darauffolgenden Checksummen ungültig werden und neu berechnet werden müssten.
puls200 05.07.2012
2
Richtig, löschen ist nicht erlaubt .. nur "Gelöscht"-Flags wären möglich.
Floyd 05.07.2012
2
Ich würde ein externes Tool erstellen, dass Prüfsummen aus einzelnen Datenbankzeilen erstellt und in eine separate Spalte schreibt. Dieses Tool läuft dann als Job zum Zeitpunkt X. Die Prüfsummenberechnung enthält einen veränderbaren Anteil (Salt), der nur dem Admin (oder wer auch immer autorisiert ist) bekannt ist, so dass Dritte nicht in der Lage sind, eine Neuberechnung durchzuführen, selbst wenn sie Zugriff auf das Tool haben.
Um eine Manipulation zu erkennen braucht man das Tool nur erneut zum Abrechnungszeitpunkt auszuführen und die Zeilen mit abweichender Checksumme identifizieren.
05.07.2012
puls200 3,7k 6
Interessanter Ansatz. Man müsste dann den veränderlichen Teil zumindestens für die autm. Durchläufe irgentwo hinterlegen - dass könnte ich als Entwickler dann ja auch wieder auslesen - den Salt mir anzeigen und dann eine Neuberechnung laufen lassen. (Wenn ich das richtig verstanden habe)

MyKey0815 05.07.2012
Klar - eine gewisse kriminelle Energie muss dahinter stehen. Nur als Entwickler des Tools hat man deutlich weniger Aufwand so einen Hack zu bauen, weil man ja den Code selber gebaut hat. Jemand der den Code/Vorgehensweise nicht kennt, ist da natürlich mit viel mehr Aufwand dran.

So wie ich das sehe, ist es wie das Admin/root Passwort eines Systems. Derjenige der es kennt, kann alles machen. Ob er es aber auch macht und letztendlich für sich ausnutzt, liegt in der Person als solches
MyKey0815 05.07.2012
So ist es. Im Prinzip sollte es immer so sein, dass der Sicherheitsmechanismus der potentiellen Bedrohung in einem vernünftigen Verhältnis gegenübersteht. Bei meinem Vorschlag könnte man den Salt Anteil einfach manuell eingeben oder aus einem geg. Vorrat (wie eine TAN) schöpfen.
puls200 05.07.2012
2
Man könnte mit dem Ansatz auch statt der Prüfsumme die Datensätze mit einer Signatur versehen.
Dann muss nur sichergestellt werden, dass nur berechtige Personen (z.B. Buchaltung, Geschäftsführung) zugriff auf den geheime Schlüssel für das Signieren haben. Da man PKs eh mit einem sicheren Passwort schützen sollte ist das aber auch kein großes Problem.
phg 05.07.2012
2
Wenn ich das wirklich nachweislich Revisionssicher machen wollte, würde ich wie folgt vorgehen:
Die Daten am Tag X in ein File exportieren und dieses auf ein (oder zwei) WORM Medium schreiben. Dieses kommt dann beim Chef in den Safe. Sollte es dann Klärungsbedarf geben, kannst Du auf die Daten im Safe verweisen.
05.07.2012
Jaksa 3,9k 1 8
2
Einen Trigger schreiben der die unerwünschten Änderung abfängt und den Trigger selbst mit einem DDL Trigger, der bei Änderung eines Triggers oder des Datenbankschemas ein Mail an den "Chef" schickt (oder eine andere unwiederrufbare Aktion ausführt), vor heimlichen Änderungen schützen... (Ich hab zwar keine Erfahrung mit DDL Triggern, aber das sollte gehen...)
05.07.2012
MaHop 71 3
0
Ein ähnlichen Fall hatten wir hier. Wir haben jede Tabelle gespiegelt im Schema und ein Hist_ davor gehängt. Zusammen mit DB Triggern für Update/Delete/Insert haben wir hier eine Nachverfolgung er bis wann etwas geändert hat. Ansonsten würde ich einen Schreibschutz des Eintrags definieren mit einer Spalte wie LockedDate . Wenn das in der Vergangenheit liegt, dann wird die Änderung verworfen.

Das ein Admin die Daten nicht ändern kann ist schmarrn, er kann natürlich alles, auch die Quersumme, neu berechnen lassen ;-) Hier ist es wichtiger ITIL Konform alle Datenbankberechtigungen fest zu legen.

Um Zugriffsnutzern effektiv einen Riegel vorzuschieben nutzen wir immer T-SQL´s (Stored Procedures) und wenn jemand etwas ändern will, einfügen, löschen, dann muss er darüber gehen. Die Procedures werden so angelegt:

create procedure dbo.SP_MeineProzedur
with execute as owner


Die Stored Procedure wird mit einem Dienstaccount angelegt der die Rechte hat, dann brauchen zugreifende Benutzer keine CRUD Rechte dafür, nur Execute. So gießen wir die Intelligenz und Validation in die Datenbank und keiner ausser der Programmierer und ein Admin kann es mehr ändern.

Das geht denke ich schneller und einfacher als Checksummen zu berechnen, aber das ist meine Meinung.
21.01.2014
Lord_Pinhead 683 7
Deiner Lösung ist dann aber nicht mehr Revisionssicher. Im Falle eines Transaktionslogs (z.B. in der Finanzweld) wäre es fatal wenn sich Daten im Nachgang ändern lassen.

Natürlich kann ein Admin die Prüfsummen (keine Quersummen!) neu berechnen, aber wenn ich es richtig mit Kryptografisch sichere Checksummen wobei in jede Checksumme als SALT für die nachfolgende verwendet wird, implemtiere, ist es auch für einen Admin fast unmöglich. Eine neuberechnung würde dann Monate oder Jahre brauchen.
Floyd 21.01.2014
Nurmal als Beispiel zu Thema Neuberechnung durch Admins: VISA führt pro Sekunde! 10.000 Transaktionen durch. Wenn ein Admin also eine vor 24h durchgeführte Transaktion verändern wollte müsste er 864.000.000 Hashs&Salts neu berechnen. Wie lange das bei z.B. 20Hashs/s dauern würde kannst man sich ausrechnen.
Floyd 21.01.2014
Abhängig vom System, welcher Hash und ob die CPU entsprechende Unterstützung mitbringt ist es einfach. Daher sind die Rechtevergaben auch so extrem gesetzt in der Finanzwelt und Änderungen an einer Transaktion von vorher und nacher können belegt werden.

Aber alles kann verändert werden, Revisoren stellen sich das ganze zwar anders vor, aber ich habe oft mit Ihnen diskutiert um "Angriffspunkte" zu entfernen. Aber keine Lösung ist unangreifbar, auch die Hashsumme nicht.
Lord_Pinhead 28.01.2014
1
@Lorg: Richtig, keine keine Lösung ist unangreifbar. Die Wahl des HASH-Verfahrens, die Rundeanzahl, und weitere Parameter können aber Einfluss darauf haben. Aber ich denke die Diskussion führt hier (in diesem Thread) zu weit. Gerne können wir darüber aber in einem eigenen Diskussionthread weiter plaudern.
Floyd 28.01.2014
Jupp, mal einen Plauderthread aufmachen, evtl. hat der eine oder andere einen Angriffsvektor für solche "Revisionssichere" Lösungen. Hab schon einige ausgehebelt bei uns in Notfällen, muss eben nur entsprechend abgesichert und dokumentiert werden.
Lord_Pinhead 06.02.2014
0
Ich fürchte, die einzige Lösung ist: Ausdrucken bei Dritten.
Das Wort revisionssicher kenne ich nur im Zusammenhang mit Buchprüfungen/Steuern etc. -> Dafür gibt es sicher entsprechende Richtlinien.
Ich hatte selbst mal mit einer PDM zu tun. Ist relativ einfach Einträge zu ändern oder gar zu löschen. Zurück bleiben oft nur Logeinträge oder fehlende Nummern bei Nummernfolgen.
01.02.2014

Stelle deine Datenbank-Frage jetzt!