Hallo zusammen,
um kurz mal ein-zwei Schritte zurück zu gehen: Das für den "sa" SQL Account eine strenges Passwort gesetzt und dieses niemand mitteilt, ist schön und gut; aber abgesichert
gegenüber dem Kunden ist der SQL Server damit gar nicht.
Als lokaler Admin kann man sich immer über die Windows Authentifizierung an den SQL Server anmelden und das natürlich mit SysAdmin Rechten.
Man könnte Trigger auf alle Tabellen, die über den Kontext (wie Context_Info
http://msdn.microsoft.com/de-de/library/ms189252.aspx) entscheiden, ob eine Datenänderung erlaubt ist oder nicht; wenn nicht, dann führe ein Rollback aus.
Hat jemand Kenntnisse vom SQL Server und die Möglichkeit & Rechte (siehe zuvor), kann der die Trigger deaktivieren oder löschen.
Man könnte je Tabelle eine Spalte mit dem Hash-Wert/CheckSum (z.B. BINARY_CHECKSUM =>
http://msdn.microsoft.com/en-us/library/ms173784.aspx) anlegen, der von der Applikation mit den Werten bestimmter Spalten und ggf. einem zusätzlichen Applikationspezifischen
Wert (analog zu einem Salt) gesetzt wird.
Ändert jemand an der Applikation vorbei Daten, stimmt diese Wert nicht mehr und man kann manipulierte Zeilen erkennen; vor einer Änderung selbst schützt es aber nicht.
TDE arbeitet mit einem Zertifikat und wenn man das nicht hat, kann man nicht auf die Daten zugreifen; aber eben TDE aus der Enterprise und auch ein Zertifikat kann gestohlen werden.
Nicht nur bestimmte Berufsgruppen sind an gesetzliche Bestimmungen gebunden, das ist auch jede Buchhaltung mit der GoB so.
Rechnungen in elektronischer Form die zum Vorsteuerabzug berechtigen müssen ebenfalls versionssicher / "unveränderbar" gespeichert werden.
Auch das kann eigentlich nur dadurch sicher gestellt werden, das die Daten digital mit Zertifikat signiert werden. Dabei wird das Timestamp von einem (zertifizierten) Zeitserver abgerufen und mit in der Signatur gespeichert; denn sonst könnte man selbst
das Dokument abändern und neu signieren.
Und was den Datenexport betrifft: Selbst da gibt es in bestimmten Bereich Vorschrift, wie eben bei einer Buchhaltung.
Kommt es zur Betriebsprüfungen, will das Finanzamt die "steuerlich relevante Daten" haben und das heisst entweder ein (IDEA) Export in elektronischer Form oder ein Backup der Datenbank, wenn es sich um ein Standardsystem handelt.
Kannst Du das nicht liefern, wird vor Ort geprüft ... oder sie nehmen gleich den Server mit, um in Ruhe auf dem Amt zu prüfen; da kommt dann wenig Freude beim Kunden auf.
Das ist in vielen Bereich genaus so. Auch ein Arzt wird zuweilen geprüft, ob alles korrekt abgerechnet, im öffentlichem Bereich kommt der Wirtschaftsprüfer vorbei und so weiter. Und heutzutage geht keiner mehr riesige Aktenberge durch, da
werden elektronische Daten gesichtet & analysiert.
Und auch hier wieder Thema Kundenakzeptanz:
Wer oder was garantiert mir als Kunde, das Du als Hersteller das Produkt auch noch in 10 Jahren pflegst und Du verfügbar bist, um bei einer Prüfung die Daten hierzu extrahierst? Nicht das womöglich morgen an Deinem Briefkasten ein Zettel klebt:
"Meine neue Adresse: Karibik, dritte Insel von links".
Wenn ich als Kunde unter diesem Gesichtspunkten zwei Produkt zur Auswahl habe, eine abgeschottete und ein offenes System, rate mal welches Produkt ich kaufen werde. Denn ich als Kunde will Planungssicherheit und wenn es mal zu dem Fall kommt und ich auf
ein anderes System wechseln musss, dann werde ich nicht alle Altdaten der letzten 10 Jahre (Zeitraum der Aufbewahrungspflicht) manuell nacherfassen.
Karsten, wenn ich Dich richtig verstehe, geht es bei Dir aber mehr um die Dateninhalte und die sind wohl aber Auslieferung statisch; sowas wie Regelwerke und ähnlich. Wie Thomas anmerkte ist eine Freitext-Suche in verschlüsselt Daten nicht so optimal,
ein Index könnte nie verwendet werden (Suche geht selbst schon). Bei einem Regelwerk sucht man aber eigentlich nie nach Texten, sondern arbeitet nur mit IDs, da könntest Du den textuellen Inhalt schon verschlüsseln.
Hängt aber zugegeben sehr vom Konstrukt ab, wieweit das umsetzbar wäre.
Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog
Xing
