Re: Prüfsumme

"Oliver Benning" <oliver@xxxxxxxxxxxxxxxxx> writes:

Natürlich soll im Vorfeld alles dafür getan werden, daß das
Eindringen in die Datenbank erschwert wird. Da es sich aber um eine
Internet-Applikation handelt, kann man es nicht komplett
verhindern. Deshalb soll zumindest die Manipulation der Daten
zuverlässig erkannt werden. Die Benutzer verbinden sich per Internet
(SSL) mit dem Applikations-Server und authorisieren sich durch
Benutzer-ID und Passwort. Sie speichern lediglich Daten, das Ändern
ist nicht vorgesehen und sollte es manuell auf Datenbankebene durch
einen Angreifer passieren, muß das erkannt werden und die Daten sind
ungültig.

Nehmen wir mal an, du fügst solche Signaturen den Daten hinzu. Dazu
muss irgendwo ein Schlüssel rumliegen -- in diesem Fall reicht es,
wenn die Schlüssel komplett lokal auf den Anwender-Rechner (oder einem
Gateway innerhalb des LAN) liegen, auf dem DB-Server müssen sie nicht
gespeichert sein.

Was könnten die Interessen des Angreifers sein? Ist es tatsächlich
egal, dass er alle Daten lesen kann? Stört es nicht, wenn er beliebig
Daten löschen kann?

Warum ist gerade das Ändern so interessant für den Angreifer? Und wenn
es so interessant ist, warum sollte er sich nicht die Mühe machen, ins
interne LAN einzubrechen und die Signier-Schlüssel an sich zu bringen?
Sind alle internen Mitarbeiter voll vertrauenswürdig?

Ein gut abgesicherter Server ist nicht so leicht zu knacken. Ein
durchschnittlicher Desktop-Rechner auch innerhalb eines Firmen-LANs
ist erfahrungsgemäß gar nicht mal so schwer anzugreifen (Stichwort
Trojaner... OK, ein gezielter Angriff auf ein gut abgesichertes
Firmen-LAN mit entsprechend sensibilisierten Mitarbeiter ist schon
extrem schwierig... aber wo gibt es das schon).

Deine Ambitionen in allen Ehren, aber ist hier nicht evtl. etwas mehr
Gelassenheit und eine Konzentration auf's Wesentliche (gute
Absicherung des Servers inkl. regelmäßiger Sicherheitsupdates und
Kontrollen) nicht sinnvoller?

Denn der Aufwand mit den Prüfsummen ist schon nicht ganz unerheblich,
zumal sie nicht in Stored Procedures versteckt werden können (dann
müsste der Signier-Schlüssel ja auf dem Server liegen).

Banken müssten doch auch ein ähnliches System haben. Wenn jemand es
schafft, an die zentrale Kontodatenbank zu kommen und dort auf
Low-Level Ebene bei einem Konto-Datensatz den Kontostand verändert,
wird das doch sicherlich erkannt.

Hmmm... ich bin kein Experte im Banken-Sektor, habe aber noch nie
davon gehört, dass dort in den Datenbanken Prüfsummen dieser Art, wie
sie dir vorschweben, abgelegt werden -- die Server werden halt
gehärtet und abgesichert. Zudem gibt es regelmäßig Backups und
Kontrollen.

Banken sehen das realistisch (mancher mag vielleicht auch sagen: sehr
sorglos): Wenn ein Angreifer Schreibzugriff auf die zentrale Konto-DB
hat, dann ist der Super-GAU eingetreten und ein Feigenblatt wie
Prüfsummen helfen nicht mehr viel. Zumal das Handling der Prüfsummen
und Schlüssel schnell sehr aufwändig und komplex werden kann, sprich:
Fehleranfällig und damit auch schon mal kontraproduktiv. Es gilt halt,
die verschiedenen Vor- und Nachteile gut abzuwägen. 100%ige Sicherheit
ist schlicht unmöglich.

Ah, mir fällt gerade ein gutes Beispiel ein: Das Debian-Projekt hatte
schon ein oder zweimal das Problem, dass Server gehackt wurden. Durch
regelmäßige Kontrollen sollten solche Einbrüche relativ schnell
auffallen. Dann wird schnell reagiert: Server vom Netz nehmen (kurzer
Anruf beim Hoster sollte reichen), plätten, Daten aus einem noch
garantiert sicheren und unveränderten Backup zurückspielen, alle
Passwörter ändern, Server wieder ans Netz. Fertig.

Banken dürften das prinzipiell genauso machen, nur mit einem etwas
höheren Automatisierungsgrad (=teurer) als die Debian Leute.

--
Stefan.
.

Relevant Pages

  • =?UTF-8?Q?Re:_ASPNETDB.MDF_au=C3=9Ferhalb_von_A?= =?UTF-8?Q?pp=5FData?=
    ... Server-Explorer des Visual Studios wird die Datenbank nicht mehr ... Dann findet der SQL Server die Datei nicht mehr, welche er immer noch im alten Verzeichnis sucht. ... Dann verschiebst Du alle Dateien, die dazu gehören in das write Verzeichnis. ...
    (microsoft.public.de.german.entwickler.dotnet.asp)
  • Re: Daten abrufbereit halten
    ... ein wirklich ernst gemeinter Tipp vorweg: Besorge dir ein SQL-Einsteigerbuch, damit du mit den Grundtechniken eines RDMS vertraut wirst. ... Wenn du mit einer Datenbank arbeitest, lasse die Finger von irgendwelchen selbst gecachten Konstrukten. ... Server: MS SQL Server 2005 -> wird per OLEDB angesprochen ...
    (microsoft.public.de.sqlserver)
  • Re: Zugriff auf andere Datenbank
    ... Die Daten kommen in ein vom Bayerischen Landesamt für Statistik kostenlos zur ... > Wenn Ihr hier beim SQL Server bleibt bietet sich DTS an. ... >> mir zwar die Tabelle, ... Ich hab die Tabelle nicht im Linked Server, sondern ein einer Datenbank ...
    (microsoft.public.de.sqlserver)
  • Re: xp sp2 an 2003er domäne
    ... >Der Angreifer ist nicht nur eingedrungen, ... >> Also du schlägst vor dass ich da ne Firewall vor klemm. ... bzw. dann heisst die Lösung VPN. ... >stehen können frei mit dem Server kommunizieren. ...
    (microsoft.public.de.german.windows.server.networking)
  • Re: offline betrieb?
    ... Lokal hat also jemand das Gehalt des Mitarbeiters um 10% erhöht, ... Datenbank sondern auch ein Frontend ganz spezifisch zugeschnitten wird, ... Die Lokale Datenbank checkt vom server aus. ... Die Lokale Datenbank wird wieder eingecheckt, Konflikte werden gelöst. ...
    (de.comp.datenbanken.mysql)