Ich finde ja, dass entsprechende Vorkehrungen vom Programmierer getroffen werden sollten und die Datenbankschnittstellen und API's es einem auch sehr leicht machen, Nutzereingaben vom Rest zu trennen. Eine solche Firewall schafft da nur Mehraufwand und Overhead.
Das sollten sie, aber ich denke nicht, dass Programmierer alles abdecken können. Niemand entwickelt fehlerfrei. Wenn es in den Bereich Frameworks und agile Entwicklung geht, wo große Entwicklerteams zusammenarbeiten oder Anwendungen die (von anderen Entwicklern) erweitert werden, schleichen sich Fehler ein.
GreenSQL in betrieb zu nehmen, ist kein großer Aufwand, verspricht aber zusätzlichen Schutz. Der Overhead hält sich auch in Grenzen, denn es werden lediglich die Queries analysiert und weitergeleitet und danach die Ergebnisse zurückgespielt.
> ist kein großer Aufwand > verspricht aber zusätzlichen Schutz
Nö. GreenSQL benötigt ja eine zweite Maschine und Netzwerk. Der Aufwand zur Absicherung von nun zwei Maschinen ist mindestens doppelt so hoch wie vorher, außerdem müssen bei jeder Änderung auch die Regeln in GreenSQL ständig gepflegt werden. Bei Audits sind nun doppelt so viele Maschinen zu prüfen wie vorher, und man benötigt mehr Leute mit Fachwissen. Man denke an so Dinge wie Stored Procedures, Trigger etc. Da kann GreenSQL nur die Parameter prüfen, aber nicht eventuelle Nebeneffekte der Prozeduren.
In der Praxis wird es dann auch gerne so sein dass der Datenbank-Server hinter der Firewall dann weniger Aufmerksamkeit bekommt - er steht ja hinter einer Firewall... Oder die Entwickler laufen ständig in Probleme und die GreenSQL-Regeln sind irgendwann löchrig wie ein Käse.
Man muss da schon GANZ genau wissen was man da tut. Sicherheits gibts nicht mal so nebenbei.
> Der Overhead hält sich auch in Grenzen
Öhm da hätte Ich gerne ein paar Messungen, denn bei häufigen kleinen Queries ist die erhöhte Latenz durch die Firewall sicher messbar, und bei Queries mit vielen Ergebnissen müssen die Daten vom Datenbankserver komplett hoch bis auf den Anwendungsstack der Firewall und wieder runter aufs Netz. Da wird die Firewall dann zum Flaschenhals.
Greensql benötigt nicht zwingend eine zweite Maschine. Andere Proxies wie Squid teilen sich die Hardware auch mit anderen Services.
Für Prozeduren und Trigger brauchst du genauso viele Fachleute wie vorher, die werden ja auf Datenbankebene implementiert und kommen nicht als Query von der Anwendung. Wenn eine Anwendung aufgesetzt ist, kommen auch nicht viele neue Regeln hinzu, denn an den Abfragen ändert sich danach voraussichtlich nichst mehr. So hält sich die Pflege in Grenzen.
Ich habe eine solche Installation am Laufen. GreenSQL ist einfach aufzusetzen, dann kommt eine Lernphase, in der die Whitelist gefüllt wird, so dass das nicht von Hand gemacht werden muss, und danach wird alles "scharf" geschaltet und läuft. Es ist auf jeden Fall einen Blick wert.
Hört sich interessant an.
Hat schon jemand Erfahrungen mit solch einer "Datenbank-Firewall"?
Ich finde ja, dass entsprechende Vorkehrungen vom Programmierer getroffen werden sollten und die Datenbankschnittstellen und API's es einem auch sehr leicht machen, Nutzereingaben vom Rest zu trennen. Eine solche Firewall schafft da nur Mehraufwand und Overhead.
Das sollten sie, aber ich denke nicht, dass Programmierer alles abdecken können. Niemand entwickelt fehlerfrei. Wenn es in den Bereich Frameworks und agile Entwicklung geht, wo große Entwicklerteams zusammenarbeiten oder Anwendungen die (von anderen Entwicklern) erweitert werden, schleichen sich Fehler ein.
GreenSQL in betrieb zu nehmen, ist kein großer Aufwand, verspricht aber zusätzlichen Schutz. Der Overhead hält sich auch in Grenzen, denn es werden lediglich die Queries analysiert und weitergeleitet und danach die Ergebnisse zurückgespielt.
> ist kein großer Aufwand
> verspricht aber zusätzlichen Schutz
Nö. GreenSQL benötigt ja eine zweite Maschine und Netzwerk. Der Aufwand zur Absicherung von nun zwei Maschinen ist mindestens doppelt so hoch wie vorher, außerdem müssen bei jeder Änderung auch die Regeln in GreenSQL ständig gepflegt werden. Bei Audits sind nun doppelt so viele Maschinen zu prüfen wie vorher, und man benötigt mehr Leute mit Fachwissen. Man denke an so Dinge wie Stored Procedures, Trigger etc. Da kann GreenSQL nur die Parameter prüfen, aber nicht eventuelle Nebeneffekte der Prozeduren.
In der Praxis wird es dann auch gerne so sein dass der Datenbank-Server hinter der Firewall dann weniger Aufmerksamkeit bekommt - er steht ja hinter einer Firewall... Oder die Entwickler laufen ständig in Probleme und die GreenSQL-Regeln sind irgendwann löchrig wie ein Käse.
Man muss da schon GANZ genau wissen was man da tut. Sicherheits gibts nicht mal so nebenbei.
> Der Overhead hält sich auch in Grenzen
Öhm da hätte Ich gerne ein paar Messungen, denn bei häufigen kleinen Queries ist die erhöhte Latenz durch die Firewall sicher messbar, und bei Queries mit vielen Ergebnissen müssen die Daten vom Datenbankserver komplett hoch bis auf den Anwendungsstack der Firewall und wieder runter aufs Netz. Da wird die Firewall dann zum Flaschenhals.
Greensql benötigt nicht zwingend eine zweite Maschine. Andere Proxies wie Squid teilen sich die Hardware auch mit anderen Services.
Für Prozeduren und Trigger brauchst du genauso viele Fachleute wie vorher, die werden ja auf Datenbankebene implementiert und kommen nicht als Query von der Anwendung. Wenn eine Anwendung aufgesetzt ist, kommen auch nicht viele neue Regeln hinzu, denn an den Abfragen ändert sich danach voraussichtlich nichst mehr. So hält sich die Pflege in Grenzen.
Ich habe eine solche Installation am Laufen. GreenSQL ist einfach aufzusetzen, dann kommt eine Lernphase, in der die Whitelist gefüllt wird, so dass das nicht von Hand gemacht werden muss, und danach wird alles "scharf" geschaltet und läuft. Es ist auf jeden Fall einen Blick wert.
Vielen Dank für die kurze Schilderung!