DMZ Verständnisfrage

drmiu

Cadet 4th Year
Registriert
Juni 2011
Beiträge
126
Hallo Leute,

eine Verständnisfrage zum Thema DMZ:

Eine DMZ ist ja dafür da, dass kompromittierte Server von außen aus keinen Schaden im internen Netzwerk anrichten können, so zum Beispiel ein Webserver.

Wenn ich jetzt aber einen Webserver habe, der mit einer SQL-Datenbank kommuniziert, muss ich ja von der DMZ aus einen Port ins interne Netzwerk freigeben - und umgekehrt.
Oder?

Meine Idee wäre jetzt, dass man in die DMZ einen zusätzlichen Readonly SQL-Server stellt. Aber dann muss ja wieder etwas aufgemacht werden.

Oder wie wird sowas in der Regel umgesetzt?

Viele Grüße
 
Eine DMZ ist für viele Dinge da..

2 Netzwerke, Netzwerk 1 kann auf Netzwerk 2 zu greifen, aber nicht andersherum.. Das ist die Erklärung in einfachen Worten.

Mir fällt da observer und observable ein, hat aber nicht mit deiner Frage zu tun^^
 
Deine Defintion der DMZ ist falsch.

Eine DMZ ist der Bereich eines Netzwerkes, der von außen öffentlich erreichbar ist. Darin können u.a. Webserver etc stehen. Das hat nichts mit direkt mit kompromitierten Servern zu tun.


Zum weiterlesen:

https://de.wikipedia.org/wiki/Demilitarized_Zone

---

zur SQL Datenbank:

idR liegt die SQL Datenbank mit auf den Webserver, daher brauch die keine Verbindung ins Interne Netzwerk. Ansonsten, wenn so etwas gemacht wird, dann werden explizite Regeln in der FW eingestellt, wer die Verbindung nutzen darf und wer nicht.


p.s. ich rieche irgendwie Hausaufgaben, kann das sein?
 
Es gibt ungefähr genau so viele Lösungen wie es Voraussetzungen gibt, die einzuhalten sind. Sei es physikalisch, logisch, organisatorisch, rechtlich...

Du könntest die Datenbank mit auf dem Webserver laufen lassen. Oder in deiner DMZ mit einer Firewall einen weiteren Tier für die Datenhaltung abtrennen. Oder auf der Firewall zwischen der DMZ und deinem Netz die Kommunikation zur Datenbank freischalten. Oder, oder, oder...
 
Aber würde es keine kompromittierungen von außen geben, gäbe es keine DMZ :D
Außer man möchte den Traffic vom Internet aus Performancegründen nicht im Netz haben...

Hmm, schwierig, schwierig.

Ist es eine grobe Sicherheitslücke, wenn ich den Datenbankserver im internen Netzwerk stehen habe und den Webserver + Applikation in der DMZ? Weil - in der Applikation sind ja (zwingend) Logindaten für den SQL-Server hinterlegt. Damit hat der Herr Angreifer mit einem erfolgreichen Angriff auf den Webserver ja automatisch den Zugriff auf sämtliche Daten...
Dann ist es meines Erachtens sogar eher sinnvoller, den Webserver gar nicht nach außen zu veröffentlichen...

Nein, keine Hausaufgaben :D Nur wohl nicht ganz richtig damals aufgepasst ;)

Edit: Habe hier gerade etwas gefunden:
https://www.bsi.bund.de/DE/Themen/I...utzKataloge/Inhalt/_content/m/m05/m05117.html

Wenn das schon vom Amt so geregelt ist, dann muss man wohl auf die Sicherheitsfeatures im Gateway vertrauen und die Kommunikation zwischen Webserverapplikation und SQL-Server zulassen. 100%ige Sicherheit kann man wohl nie erreichen...
Oder gibt es da Lösungsansätze wie eine Art SQL-Proxy?
 
Zuletzt bearbeitet:
Wenn du dir Gedanken über IT Sicherheit machst, dann gehören zu den wichtigen Fragen auch diese: Wovor will ich mich schützen? Was ist das realistische Gefahrenpotenzial? Wie attraktiv ist das Ziel? Und so weiter...

Warum sind die Fragen wichtig?

Weil du klären must wer und mit welchen Fähigkeiten angelockt wird und wie viel Aufwand es demjenigen wert ist bei dir einzubrechen. Das Ziel ist nicht unbedingt 100% Sicherheit zu erreichen, denn das ist oft einfach unmöglich. Wie bei einem klassischen Einbruch, z.B. in eine Bank, geht es nur darum es dem Angreifer möglichst schwer zu machen. Deswegen sind die Maßnahmen in einer Bank umfangreicher als bei einem Kiosk. Und genau so funktioniert das in der IT auch. Wenn deine Daten uninteressant sind, dann hast du evtl. nur jemanden, der deinen Webserver kompromittieren will um Rechenkapazität oder Bandbreite zu bekommen. Wenn deine Daten wertvoll sind und das bekannt ist, dann hast du jemanden, den das wiederum nicht interessiert und der dann an deine Daten ran will.

Deine Applikation muss die Logindaten ja nicht im Klartext irgendwo sichtbar stehen haben. Nicht nur "muss nicht", sollte auch einfach nicht. Wenn jemand über eine Sicherheitslücke in deinen Webserver einbricht hat er noch lange nicht automatisch Zugriff auf deine Datenbank.

Wenn du dich auf das BSI berufen willst, dann solltest du folgendes nicht vergessen. Das BSI, insbesondere mit dem IT Grundschutz Katalog, gibt Empfehlungen ab. Das ist nicht die absolute Lösung für alle Probleme der IT Sicherheit, sondern eine Sammlung von Empfehlungen, Best Practices wenn du so willst, um ein Mindestmaß an Sicherheit herzustellen. Wenn du überhaupt gar keine Ahnung hast, dann kann dir das helfen, allerdings solltest du dann auch nichts vermeintlich kritisches alleine anpacken.
 
Zum einen geht es mir darum zu wissen, wie man soetwas mal implementieren könnte. Zum Anderen geht es um Patientendaten - und den Patienten gilt es höchste Sicherheit zu gewährleisten.

Ich gehe immer vom worst case aus - habe ich Zugriff auf den administrativen Zugriff einer Applikation bei der Daten eingetragen sind, kann ich die im Rahmen der Applikation vorgesehenen Daten abgreifen. Habe ich Rootzugriff auf den Webserver setze ich das Passwort des Applikationsadmins zurück (ja, lässt sich durch Remoteauth. umgehen, ich weiß :p).

Ich denke, du hast Recht. 100%ige Sicherheit geht kaum.
Warscheinlich sind die Sicherheitsmaßnahmen die vor den Webserver geschalten sind sogar schon relativ ausreichend... Ist aber auch Interessehalber - wenn einer hinter diese Türe kommt, weiß er ganz genau was er tut. Dann müssen vorher Maßnahmen getroffen werden, damit er nicht noch weiter kommt.
 
Zuletzt bearbeitet:
Zum Anderen geht es um Patientendaten - und den Patienten gilt es höchste Sicherheit zu gewährleisten.

der Geruch von Hausaufgaben ist ja hier zu heftig, sry bin raus da
 
Zurück
Oben