23
ISCSI Storage in zwei verschiedenen Sicherheitszonen
Hallo Kollegen,
die Chefetage möchte ein Storage haben worauf Hypervisoren (wahrscheinlich Hyper-V) die VMs ablegen sollen. Nun hat man sich Open-E als mögliche Lösung angeschaut und es steht die Frage für mich im Raum wie sicher der Betrieb in verschiedenen Netzwerk-Sicherheitszonen ist. Einige HV kommen ins LAN für VMs wie Lohnbuchhaltung, andere kommen in eine gesonderte Sicherheitszone für den Zugriff aus dem Internet. Beide sollen aber das Storage (iSCSI) verwenden. Oder ist es an dieser Stelle besser auf FC zu wechseln, um einen Technikbruch zu haben?
Wie würdet ihr das einrichten?
die Chefetage möchte ein Storage haben worauf Hypervisoren (wahrscheinlich Hyper-V) die VMs ablegen sollen. Nun hat man sich Open-E als mögliche Lösung angeschaut und es steht die Frage für mich im Raum wie sicher der Betrieb in verschiedenen Netzwerk-Sicherheitszonen ist. Einige HV kommen ins LAN für VMs wie Lohnbuchhaltung, andere kommen in eine gesonderte Sicherheitszone für den Zugriff aus dem Internet. Beide sollen aber das Storage (iSCSI) verwenden. Oder ist es an dieser Stelle besser auf FC zu wechseln, um einen Technikbruch zu haben?
Wie würdet ihr das einrichten?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 460121
Url: https://administrator.de/contentid/460121
Ausgedruckt am: 25.11.2024 um 01:11 Uhr
23 Kommentare
Neuester Kommentar
Hallo Hannes,
einerseits gut, dass eure GL euch anleitet, andererseits scheint (Bisher) Noch wenig KnowHow da zu sein?
Das Storage kommt natürlich in ein Extra Netz, schon aufgrund der Leistung.
Viele Grüße,
Christian
certifiedit.net
einerseits gut, dass eure GL euch anleitet, andererseits scheint (Bisher) Noch wenig KnowHow da zu sein?
Das Storage kommt natürlich in ein Extra Netz, schon aufgrund der Leistung.
Viele Grüße,
Christian
certifiedit.net
Danke für deine Antwort. Natürlich kommt es in ein eigenes Netzwerk. Allerdings ist der Gedanke folgender: Der App-Server, der mit einem Bein am Internet hängt, wird gecrackt. Nun hat der Angreifer volle Kontrolle über den Wirt, der eine iSCSI-Platte hat. Eine Frage wäre, ob der Angreifer die Möglichkeit hat von der ISCSI-Platte auf das Storage oder eine andere iSCSI-Disk zu kommen. Weiß dazu jemand etwas? Ich kann es mir zwar nicht vorstellen, aber "ich weiß, dass ich nichts weiß". Der Teufel ist ja bekanntermaßen ein Eichhörnchen.
Hallo Hannes,
wieso willst du denn den Hypervisor in die DMZ stellen oder verstehe ich dich da falsch?
Du kannst doch einzelne Netzwerkcontroller für bestimmte VMs (respektive vSwitches) dedizieren (die Einstellung nennt sich bei Hyper-V "Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen") und so nur die VMs in die DMZ auslagern. Die Hosts bleiben somit komplett im LAN.
Wie Christian schon richtig sagte, das Storage in ein eigenes Netz auf das ausschließlich die Hosts Zugriff haben und die VMs mit dedizierten LAN-Ports in die anderen Netze verteilen, Stichwort vLANs.
Firewalls noch anständig konfigurieren, et voila.
FC kann natürlich aus Gründen der Performance durchaus Sinn machen, einen Sicherheitsrelevanten Aspekt sehe ich dabei allerdings nicht. Korrigiert mich gerne wenn ich mich da falsch liegen sollte, man lernt ja schließlich nie aus.
LG
wieso willst du denn den Hypervisor in die DMZ stellen oder verstehe ich dich da falsch?
Du kannst doch einzelne Netzwerkcontroller für bestimmte VMs (respektive vSwitches) dedizieren (die Einstellung nennt sich bei Hyper-V "Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen") und so nur die VMs in die DMZ auslagern. Die Hosts bleiben somit komplett im LAN.
Wie Christian schon richtig sagte, das Storage in ein eigenes Netz auf das ausschließlich die Hosts Zugriff haben und die VMs mit dedizierten LAN-Ports in die anderen Netze verteilen, Stichwort vLANs.
Firewalls noch anständig konfigurieren, et voila.
FC kann natürlich aus Gründen der Performance durchaus Sinn machen, einen Sicherheitsrelevanten Aspekt sehe ich dabei allerdings nicht. Korrigiert mich gerne wenn ich mich da falsch liegen sollte, man lernt ja schließlich nie aus.
LG
Danke für deine Antwort.
Dazu hatte ich kürzlich ein dreitägiges Seminar zur IT-Sicherheit. Vor dem Seminar hätte ich das auch so gemacht. Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen. Das betraf durch die Bank weg alle Hypervisoren. Aus dem Grund ist das keine Option für uns, da wir mit personenbezogenen Daten der schlimmsten Art arbeiten. Darum gibt es einen HV für die DMZ und einen für die kritischen Daten in einer Sicherheitszone im LAN.
Du kannst doch einzelne Netzwerkcontroller für bestimmte VMs (respektive vSwitches) dedizieren (die Einstellung nennt sich bei Hyper-V "Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen") und so nur die VMs in die DMZ auslagern. Die Hosts bleiben somit komplett im LAN.
Dazu hatte ich kürzlich ein dreitägiges Seminar zur IT-Sicherheit. Vor dem Seminar hätte ich das auch so gemacht. Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen. Das betraf durch die Bank weg alle Hypervisoren. Aus dem Grund ist das keine Option für uns, da wir mit personenbezogenen Daten der schlimmsten Art arbeiten. Darum gibt es einen HV für die DMZ und einen für die kritischen Daten in einer Sicherheitszone im LAN.
Ne, er hat bedenken, dass sich sichere VMs und DMZ VMs das gleiche Storage teilen.
Ich glaube nicht, dass du bedenken haben musst. Der Host ist ja nur von LAN Seite, ggfs ja sogar zusätzlich nur aus einem Management Netz erreichbar. Das LAN Netz hat einen eigenen VSwitch und das DMZ Netz ja auch.
Das Storage wird dann nochmal mit separaten NICs in nochmal einem abgeschotteten Bereich betrieben. Da sollte nix passieren.
Ich glaube nicht, dass du bedenken haben musst. Der Host ist ja nur von LAN Seite, ggfs ja sogar zusätzlich nur aus einem Management Netz erreichbar. Das LAN Netz hat einen eigenen VSwitch und das DMZ Netz ja auch.
Das Storage wird dann nochmal mit separaten NICs in nochmal einem abgeschotteten Bereich betrieben. Da sollte nix passieren.
Antwort überschnitten... 
Dann vergiss meine Antwort.
Evlt Storage Spaces Direct komplett ohne separates Storage für den DMZ Bereich?
Dann vergiss meine Antwort.
Evlt Storage Spaces Direct komplett ohne separates Storage für den DMZ Bereich?
Hello again,
Wenn ich dich richtig verstehe....
Der "App-Server" ist ja zu aller Erst eine einzelne VM (siehe mein vorheriger Post). Ist diese kompromitiert muss der Angreifer erst mal einen "Sandbox-Escape" schaffen und aus der virtuellen Maschine "ausbrechen" um auf den "Wirt", also den HV zu gelangen. Erst dort hat er dann Zugriff auf die Platte. Hier kann er sich dann problemlos Zugriff auf andere Disks schaffen die von ansprechbaren Storages bereit gestellt werden. Dann ist er allerdings schon so tief in deinem Netz dass er vermutlich nicht nur das Storage angreift sondern eher das Management-Netz respektive die IT-Abteilung. Von dort hat er dann Allmacht und einen größeren benefit.
Prinzipiell natürlich möglich, aber FC hilft da meines erachtens auch nichts =)
Zitat von @hannes.hutmacher:
Der App-Server, der mit einem Bein am Internet hängt, wird gecrackt. Nun hat der Angreifer volle Kontrolle über den Wirt, der eine iSCSI-Platte hat.
Der App-Server, der mit einem Bein am Internet hängt, wird gecrackt. Nun hat der Angreifer volle Kontrolle über den Wirt, der eine iSCSI-Platte hat.
Wenn ich dich richtig verstehe....
Der "App-Server" ist ja zu aller Erst eine einzelne VM (siehe mein vorheriger Post). Ist diese kompromitiert muss der Angreifer erst mal einen "Sandbox-Escape" schaffen und aus der virtuellen Maschine "ausbrechen" um auf den "Wirt", also den HV zu gelangen. Erst dort hat er dann Zugriff auf die Platte. Hier kann er sich dann problemlos Zugriff auf andere Disks schaffen die von ansprechbaren Storages bereit gestellt werden. Dann ist er allerdings schon so tief in deinem Netz dass er vermutlich nicht nur das Storage angreift sondern eher das Management-Netz respektive die IT-Abteilung. Von dort hat er dann Allmacht und einen größeren benefit.
Prinzipiell natürlich möglich, aber FC hilft da meines erachtens auch nichts =)
@hannes.hutmacher
@certifiedit.net
Die Ansage von Frank bezüglich der Werbung in Fragen/Beiträgen/Kommentaren war doch recht deutlich. Damit eingeschlossen sind auch Signaturen. Wobei Werbung bis dato schon laut Diskussionsrichtlinien verboten waren. Bitte zukünftig daran denken. Vielen Dank!
Gruß,
Dani
Nun hat man sich Open-E als mögliche Lösung angeschaut und es steht die Frage für mich im Raum wie sicher der Betrieb in verschiedenen Netzwerk-Sicherheitszonen ist.
Das ist nicht ganz trivial, wie es sich anhört. Vorallem wenn man bedenkt, dass man von allen zum einsatzkommenden Best Practices umsetzen soll/muss.Einige HV kommen ins LAN für VMs wie Lohnbuchhaltung, andere kommen in eine gesonderte Sicherheitszone für den Zugriff aus dem Internet. Beide sollen aber das Storage (iSCSI) verwenden.
Auf Grund deiner Beschreibung geht es wohl um LAN und DMZ. Server bzw. deren Services, die aus dem Internet erreichbar sein sollen, kommen in die DMZ. Für alle Sicherheitszonen (Ausnahme: Microsegementierung) werden immer separate Switches, Server und ggf. Storages genutzt. Alles andere ist aus Sicht der Sicherheit eine logische Brücke an der Firewall vorbei. Daher wird oft aus Kostengründen in kleineren DMZ für die verschiedenen Services einfache Server anstatt einem Storage plaziert. Das soll niemanden davon abhalten, trotzdem einen Hypervisor einzusetzen.Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen. Das betraf durch die Bank weg alle Hypervisoren.
So ist es. Wobei in diesem Bereich zu anderen selten entsprechende Meldungen gibt. Aber das heißt nicht, dass es dies nicht gibt. Der Dozent hat meiner Meinung nach völlig recht.@certifiedit.net
Die Ansage von Frank bezüglich der Werbung in Fragen/Beiträgen/Kommentaren war doch recht deutlich. Damit eingeschlossen sind auch Signaturen. Wobei Werbung bis dato schon laut Diskussionsrichtlinien verboten waren. Bitte zukünftig daran denken. Vielen Dank!
Gruß,
Dani
1Zitat von @hannes.hutmacher:
Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen.
...
Darum gibt es einen HV für die DMZ und einen für die kritischen Daten in einer Sicherheitszone im LAN.
Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen.
...
Darum gibt es einen HV für die DMZ und einen für die kritischen Daten in einer Sicherheitszone im LAN.
Richtig, Sandbox-Escape ist keine neumodische Erfindung =D
Wenn das so ist muss der HV in der DMZ aber absolut Standalone bleiben. Wenn unbedingt mit Storage dann auch ein eigenes innerhalb der DMZ ohne LAN-Zugriffe.
Dreh- und Angelpunkt ist hier einzig und allein die Firewall-Konfiguration und die Netzwerk-Segmentierung.
Zitat von @Dani:
@certifiedit.net
Die Ansage von Frank bezüglich der Werbung in Fragen/Beiträgen/Kommentaren war doch recht deutlich. Damit eingeschlossen sind auch Signaturen. Wobei Werbung bis dato schon laut Diskussionsrichtlinien verboten waren. Bitte zukünftig daran denken. Vielen Dank!
Gruß,
Dani
@certifiedit.net
Die Ansage von Frank bezüglich der Werbung in Fragen/Beiträgen/Kommentaren war doch recht deutlich. Damit eingeschlossen sind auch Signaturen. Wobei Werbung bis dato schon laut Diskussionsrichtlinien verboten waren. Bitte zukünftig daran denken. Vielen Dank!
Gruß,
Dani
Mal wieder aufgerollt? Na gut, das ist keine Signatur, sondern schlicht der Benutzername. Dies wurde auch explizit akzeptiert, wobei ich mich in dem Kontext frage, wo die Ideen für die Weiterentwicklung aufkommen?
Zitat von @hannes.hutmacher:
Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen. Das betraf durch die Bank weg alle Hypervisoren.
Das halte ich jetzt erstmal für eine sehr vage Behauptung, oder konnte er das mit irgendeiner Quelle belegen? Fakt ist sicherlich, das durch diverse Sicherheitslücken derzeit vielfältige, hauptsächlich theoretische, Möglichkeiten bestehen um aus einer VM laufende Prozesse einer anderen VM auf dem selben Server im selben Kern! zu "beobachten". Das stellt ein enormes Problem dar. Aber das ist ja nun jetzt nicht so das ein Scriptkiddie mit haxor.exe Vollzugriff auf andere Server erlangt.Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen. Das betraf durch die Bank weg alle Hypervisoren.
Generell gab z.B. auch bei VMware schon Sicherheitslücken im Hypervisor (auch wenn extrem selten) aber wo bitte sind dort Angreifer schon aus der VM im Wirt (z.B. ESXi) eingedrungen bei allen anderen großen Anbietern auch? Mit der Argumentation dürftest du nie wieder einen Fuss vor die Tür setzen bei all den Gefahren.
Die Geschäftsleitung in deinem Unternehmen tut sicherlich gut daran Risiken zu bewerten und besonnen zu handeln. Aber von solchen Szenarien kann man nicht ausgehen.
Zum Thema:
Dein iSCSI Storage gibt in der Regel dem Hypervisor Vollzugriff auf alle Daten (in einem eigenen Netz). Dieser Hypervisor stellt die Daten der jeweiligen VM zur Verfügung und zwar nur dieser. Konfigurationsfehler mal ausgenommen kann jede VM nur auf ihre Daten zugreifen. Die VMs sehen auch nicht irgendwie andere Daten auf dem Storage, nur ihre eigenen.
Wer in die VM einbrechen und aus der VM auf den Hypervisor ausbrechen kann der hat tatsächlich alles im Zugriff. Das ist besonders brisant wenn ihr z.B. dedizierte VMs auf euren Servern für Fremde bzw. Kunden hostet. Dann ist der potentielle Angreifer schon in der VM und kann unauffällig aggieren.
Handelt es sich um gewöhnliche Dienste sollte man diese natürlich mit allen Mitteln absichern. Aber Wenn ich davon ausgehe das jemand in meinen Exchange einbricht, das Windows darunter erreicht, den Hypervisor kompromitiert und alle Daten unentdeckt ausleitet dann bleibt nur ein Mittel zur Gefahrenabwehr: Internet aus. Aber 99% der wirklich gefährlichen Angriffe kommen über andere Wege, z.B. von Hans Gruber dem letzte Woche gekündigt wurde, der Hausverbot bekommen hat und vom Dach gefallen ist.
Ich würde also ganz klar empfehlen: Ein vom Netzwerk getrenntes SAN aber kein dediziertes Storage wegen 3 VMs in einer DMZ.
PS: Wer aus der VM den Hypervisor erreicht der kann natürlich auch eine andere VM kompromitieren. Das heißt wenn dediziertes Storage muss das konsequenterweise auch dedizierter Host heißen und seperates Hostmanagement. Also mehr oder weniger ein eigenes Rechenzentum für solche Dienste mit offline Datentransfer.
Hier noch ein guter Kommentar was ich so auf anhieb gefunden habe:
https://www.infoworld.com/article/3200674/how-to-handle-risks-of-hypervi ...
https://serverfault.com/questions/494975/can-a-virtual-machine-vm-hack-a ...
Hier noch ein guter Kommentar was ich so auf anhieb gefunden habe:
https://www.infoworld.com/article/3200674/how-to-handle-risks-of-hypervi ...
https://serverfault.com/questions/494975/can-a-virtual-machine-vm-hack-a ...
Moin,
Ich habe noch keinen VMWare/Microsoft Architect getroffen, der solch ein Design empfohlen bzw. abgesegnet hat. Woran das wohl liegt...
Gruß,
Dani
Generell gab z.B. auch bei VMware schon Sicherheitslücken im Hypervisor (auch wenn extrem selten) aber wo bitte sind dort Angreifer schon aus der VM im Wirt (z.B. ESXi) eingedrungen bei allen anderen großen Anbietern auch? Mit der Argumentation dürftest du nie wieder einen Fuss vor die Tür setzen bei all den Gefahren.
ich kann dir sagen, dass es solche Vorkomnisse gab. Bloß welches Unternehmen/Konzern hängt das an die große Glocke? Keiner, der nicht unbedingt dazu gezungen wird. Ich würde also ganz klar empfehlen: Ein vom Netzwerk getrenntes SAN aber kein dediziertes Storage wegen 3 VMs in einer DMZ.
Wieso ein Risiko ins Haus holen, dass ich mit relativ wenig Aufwand eleminieren kann? Die Server benötigt man so oder so. Dort einfach entsprechend Festplatten je nach notwendiger Performance und Kapazität einbauen und ein LocalStorage aufbauen. Somit sind Daten und VMs sauber voneinander getrennt.Ich habe noch keinen VMWare/Microsoft Architect getroffen, der solch ein Design empfohlen bzw. abgesegnet hat. Woran das wohl liegt...
Gruß,
Dani
Moin,
Back to the Topic!
Gruß,
Dani
Mal wieder aufgerollt?
Nein, das ist nach wie vor ein Thema. Fast wöchentlich lese ich deinem Namen in einer PN oder Meldung.Dies wurde auch explizit akzeptiert...
Falls das @Frank so abgesegnet hat, nehme ich alles zurück und entschuldige mich bei mir. Ansonsten gibt es aktuell aus meiner Sicht nichts zu diskutieren. Wenn du damit nicht einverstanden bist, darfst du dich gerne an @Frank wenden.Back to the Topic!
Gruß,
Dani
Hi,
Getrennte Storage bzw. hyperconverged, was man mit Hyper-V heute ohnehin in Betracht ziehen sollte.
Generell ist das Risiko eher überschaubar. Aber wenn darauf Wert gelegt wird, führt kein Weg dran vorbei. Wenn das Risiko der geteilten Storage akzeptiert wird, wäre andererseits eine Abwägung FC/iSCSI aus meiner Sicht übertrieben. Storage-Appliances interagieren mit dem bereitgestellten Volume meist so vielfältig (ohne mich jetzt konkret auf Open-E zu beziehen: Thin-Provisioning, Caching, Filesystem-Awareness), dass netzwerkunabhängige Schwachstellen ohnehin im Vordergrund stehen sollten. Der Gewinn durch FC ist demnach gering, zumal FC-P auch recht komplex ist.
Grüße
Richard
Zitat von @hannes.hutmacher:
Beide sollen aber das Storage (iSCSI) verwenden. Oder ist es an dieser Stelle besser auf FC zu wechseln, um einen Technikbruch zu haben?
Wie würdet ihr das einrichten?
Beide sollen aber das Storage (iSCSI) verwenden. Oder ist es an dieser Stelle besser auf FC zu wechseln, um einen Technikbruch zu haben?
Wie würdet ihr das einrichten?
Getrennte Storage bzw. hyperconverged, was man mit Hyper-V heute ohnehin in Betracht ziehen sollte.
Generell ist das Risiko eher überschaubar. Aber wenn darauf Wert gelegt wird, führt kein Weg dran vorbei. Wenn das Risiko der geteilten Storage akzeptiert wird, wäre andererseits eine Abwägung FC/iSCSI aus meiner Sicht übertrieben. Storage-Appliances interagieren mit dem bereitgestellten Volume meist so vielfältig (ohne mich jetzt konkret auf Open-E zu beziehen: Thin-Provisioning, Caching, Filesystem-Awareness), dass netzwerkunabhängige Schwachstellen ohnehin im Vordergrund stehen sollten. Der Gewinn durch FC ist demnach gering, zumal FC-P auch recht komplex ist.
Grüße
Richard
Zitat von @Dani:
Moin,
Back to the Topic!
Gruß,
Dani
Moin,
Mal wieder aufgerollt?
Nein, das ist nach wie vor ein Thema. Fast wöchentlich lese ich deinem Namen in einer PN oder Meldung.Dies wurde auch explizit akzeptiert...
Falls das @Frank so abgesegnet hat, nehme ich alles zurück und entschuldige mich bei mir. Ansonsten gibt es aktuell aus meiner Sicht nichts zu diskutieren. Wenn du damit nicht einverstanden bist, darfst du dich gerne an @Frank wenden.Back to the Topic!
Gruß,
Dani
Verlinkungen auf die Website sind nicht erlaubt, Nennung des Usernamens schon. Und wie wir alle wissen, es gibt hier leider genug User, denen anscheinend "der Name an sich" und damit jedwede Aktivität schon nicht gefällt und auf persönliche Animositäten und Unzulänglichkeiten sollten wir nichts geben.
Schöne Grüße und ein ruhiges Pfingstwochenende,
Christian
certifiedit.net
Zitat von @Dani:
Moin,
Die Nicht-existenz von Sicherheitslücken kann man nicht beweisen, das muss jedem klar sein. Ich glaube auch nicht das es keine gibt aber sehr wohl, das sie gefunden und behoben werden. Daher würde ich professionelle Hypervisoren grundsätzlich als sicher bezeichnen und die Gefahr eher an anderen Stellen sehen wo sie auch statistisch häufiger auftreten.Moin,
Generell gab z.B. auch bei VMware schon Sicherheitslücken im Hypervisor (auch wenn extrem selten) aber wo bitte sind dort Angreifer schon aus der VM im Wirt (z.B. ESXi) eingedrungen bei allen anderen großen Anbietern auch? Mit der Argumentation dürftest du nie wieder einen Fuss vor die Tür setzen bei all den Gefahren.
ich kann dir sagen, dass es solche Vorkomnisse gab. Bloß welches Unternehmen/Konzern hängt das an die große Glocke? Keiner, der nicht unbedingt dazu gezungen wird.Du hingegen könntest deine Behauptungen beweisen, tust es aber nicht.
Zitat von @Dani:
"Geringer Aufwand" ist so eine Sache. Du müstest für diese DMZ eigene, möglichst ausfallsichere, Hardware aufstellen. Diese dürfte keinen Zugriff auf Netzwerk, Storage, Hypervisor, Management oder Datensicherung der übrigen Umgebung haben. Hardware und Lizenzen müssten entsprechend so ausgelegt und angeschafft werden. Wartung und Überwachung erfolgt getrennt. Ich würde also ganz klar empfehlen: Ein vom Netzwerk getrenntes SAN aber kein dediziertes Storage wegen 3 VMs in einer DMZ.
Wieso ein Risiko ins Haus holen, dass ich mit relativ wenig Aufwand eleminieren kann? Die Server benötigt man so oder so. Dort einfach entsprechend Festplatten je nach notwendiger Performance und Kapazität einbauen und ein LocalStorage aufbauen. Somit sind Daten und VMs sauber voneinander getrennt.Ich bin kein Experte weil nur interner Admin aber bei uns würde soetwas einen ganz erheblichen Aufwand und drastische Mehrkosten verursachen. Wir beide kennen die Umgebung von hannes.hutmacher nicht daher sollten wir uns mit einer Annahme vielleicht zurück halten. Klingt aber nicht so als hätte er eine Farm von 100 Servern und 5 Storages wovon sowieso 20% Storage, 20% Server, 20% Last und 20% der Lizenzen problemlos ausgegliedert werden können.
Zitat von @Dani:
Ich habe noch keinen VMWare/Microsoft Architect getroffen, der solch ein Design empfohlen bzw. abgesegnet hat. Woran das wohl liegt...
Du solltest deine Argumentation überdenken. Weil MS etwas nicht empfliehlt soll es sicherer sein? Öm okay aber klingt ein bischen nach Verschwörungstheorie und dagegen bin ich alergisch. Risiken sollten rational bewertet werden, es gibt möglicherweise viele andere Maßnahmen, die Sicherheit mehr erhöhen und weniger Aufwand darstellen.Ich habe noch keinen VMWare/Microsoft Architect getroffen, der solch ein Design empfohlen bzw. abgesegnet hat. Woran das wohl liegt...
PS: Ein komplexes Konstrukt wird durch mehr Komplexität nicht sicherer. Es steigt im Gegenteil auch die Wahrscheinlichkeit für Fehler.
@ukulele-7
Darum das SharedStorage evtl. ein bisschen kleiner Dimensonieren und das ersparte Geld in eine kleine, separate DMZ investieren.
Gruß,
Dani
Ich glaube auch nicht das es keine gibt aber sehr wohl, das sie gefunden und behoben werden.
Die eine früher, die andere später und welche sehr viel später. Das hängt davon ab, wer Sie findet.Du hingegen könntest deine Behauptungen beweisen, tust es aber nicht.
Was willst du von mir hören? Soll ich die betroffenen namenlich erwähnen, dass du nachfragen kannst."Geringer Aufwand" ist so eine Sache. Du müstest für diese DMZ eigene, möglichst ausfallsichere, Hardware aufstellen.
Das ist doch die erste Frage: Muss die Hardware in der DMZ für die Services, die sie anbietet, ausfallsicher sein?! Bei einer genauen Definition der Anforderungen kommt meistens heraus, dass die Idee der System Engieers Overkill ist und das weniger mehr ist. Gerade im Bezug auf die Komplexität.Hardware und Lizenzen müssten entsprechend so ausgelegt und angeschafft werden.
Die Hardware sowie Lizenzen für Hypervisior und Datensicherung sind meist eh zu beschaffen, da pro Hypervisor lizenziert wird. Unabhängig von der Shared- bzw. LocalStorage Lösung.Wartung und Überwachung erfolgt getrennt
Die Überwachung kann doch problemlos in einem System erfolgen. Mit Satelliten je Zone kann eigentlich nichts passieren. Die Wartung würde ich auf jeden Fall separat durchführen. Denn meist ist eine Nichtereichbarkeit der Services in der DMZ tagsüber verschmerzlich. Hingegen im LAN es meist anders aussieht.> Klingt aber nicht so als hätte er eine Farm von 100 Servern und 5 Storages wovon sowieso 20% Storage, 20% Server, 20% Last und 20% der Lizenzen problemlos ausgegliedert werden können.
Bin ich bei dir. Darum das SharedStorage evtl. ein bisschen kleiner Dimensonieren und das ersparte Geld in eine kleine, separate DMZ investieren.PS: Ein komplexes Konstrukt wird durch mehr Komplexität nicht sicherer. Es steigt im Gegenteil auch die Wahrscheinlichkeit für Fehler.
Richtig, daher auch sozusagen zwei Plattformen, die nichts miteinander am Hut haben. Denn die Fehlersuche wird durch eine Abhängigkeiten nicht einfacher und da ist teilweise dann schon Fachwissen notwendig.Weil MS etwas nicht empfliehlt soll es sicherer sein? Öm okay aber klingt ein bischen nach Verschwörungstheorie und dagegen bin ich alergisch
Zugegeben es geht da nicht nur ausschließlich um Sicherheit. Es geht ein Stück weit auch darum, dass die Best Practices umgesetzt werden. Das weiß jeder der schon mal beim Hersteller Support auf die Schnauze gefallen ist - Not Supportet.Gruß,
Dani
Für jede Zone eigenes Storage.
Wäre mir auch am liebsten, aber ich denke nicht, dass das jemand bezahlen will.Zitat von @hannes.hutmacher:
Für jede Zone eigenes Storage.
Wäre mir auch am liebsten, aber ich denke nicht, dass das jemand bezahlen will.Dann muß man halt kleinere Brötchen backen und ggf z.B. lokalen statt iSCSI-Speicher nehmen.
Man muß halt nur aufpassen, daß man nicht am falschen Ende spart.
lks
Zitat von @hannes.hutmacher:
Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen. Das betraf durch die Bank weg alle Hypervisoren.
Der Dozent wies darauf hin, dass es in der Vergangenheit genug und immer wieder Sicherheitsvorfälle gegeben hat, wo der Angreifer aus der VM ausbrechen konnte, um sein Unwesen auf dem Wirt fortzusetzen. Das betraf durch die Bank weg alle Hypervisoren.
Es stellt sich natürlich auch die Frage auf was der Dozent hier explizit angespielt hat.
Sandbox-Escape aus einer VM mit Hilfe eines Exploits ist mehr als extrem selten und daher sehr sehr unwahrscheinlich, aber es gibt ja auch viele andere Wege den Hypervisor und auch andere Ziele zu erreichen.
Credential harvesting oder Wordlist/BruteForce Attacken auf erreichbare SMB-Shares oder RDP, angriffe auf potentiell verwundbare Netzwerkperipherie und so weiter und so fort.
Es kommt immer auf die spezifische Situation an wie sich ein Angreifer von einem beliebigen kompromittierten Host weiter voran hangeln kann.
Ist die kompromittierte VM bestenfalls kein AD-Mitglied sowie Netzwerktechnisch komplett dediziert halte ich es für nahezu unmöglich den Hypervisor und somit das Storage zu erreichen.
Meine Punkte sind einfach die:
- Der Hypervisor ist nicht unverwundbar aber extrem schwer zu knacken. Es gibt, je nach Hypervisor, keine dokumentierten Fälle auf die man sich grade stützen könnte, mir sind jedenfalls keine bekannt. Das Risiko ist also extrem gering.
- Es entstehen zusätzliche Kosten. Auch wenn man auf local storage zurück greift und z.B. keine Redundanz mit einplant (was alles sinnvoll sein kann je nach services) Kostet es ein bischen extra.
- Die Warscheinlichkeit irgendwo einen Fehler zu begehen (z.B: selbes AdminPW in beiden Umgebungen) dürfte schon steigen. Das ist nicht viel aber genauso ist das mit dem vermeintlichen Sicherheitsgewinn.
Ich vermute es lohnt sich einfach nicht. Ich finde aber auch das wir eigentlich zuwenig Informationen bekommen haben um das abschließend bewerten zu können. Dazu sollten wir zumindest wissen was von wem in der DMZ genutzt wird.
Das kann natürlich jeder selbst entscheiden, vor allem der Fragensteller bzw. seine Geschäftsleitung muss das selbst entscheiden. Aber man kann einfach nicht pauschal sagen das ein seperates storage die Sicherheit erhöht, ich finde das hilft nicht weiter und verschweigt andere Aspekte.
- Der Hypervisor ist nicht unverwundbar aber extrem schwer zu knacken. Es gibt, je nach Hypervisor, keine dokumentierten Fälle auf die man sich grade stützen könnte, mir sind jedenfalls keine bekannt. Das Risiko ist also extrem gering.
- Es entstehen zusätzliche Kosten. Auch wenn man auf local storage zurück greift und z.B. keine Redundanz mit einplant (was alles sinnvoll sein kann je nach services) Kostet es ein bischen extra.
- Die Warscheinlichkeit irgendwo einen Fehler zu begehen (z.B: selbes AdminPW in beiden Umgebungen) dürfte schon steigen. Das ist nicht viel aber genauso ist das mit dem vermeintlichen Sicherheitsgewinn.
Ich vermute es lohnt sich einfach nicht. Ich finde aber auch das wir eigentlich zuwenig Informationen bekommen haben um das abschließend bewerten zu können. Dazu sollten wir zumindest wissen was von wem in der DMZ genutzt wird.
Das kann natürlich jeder selbst entscheiden, vor allem der Fragensteller bzw. seine Geschäftsleitung muss das selbst entscheiden. Aber man kann einfach nicht pauschal sagen das ein seperates storage die Sicherheit erhöht, ich finde das hilft nicht weiter und verschweigt andere Aspekte.
