> 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.
> 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.