17
Hilfe bei Netzwerkinfrastruktur für Abschlussprojekt
Hallo zusammen,
für mein Abschlussprojekt plane ich eine Netzwerkinfrastruktur und benötige die Einschätzung erfahrener Experten, ob einer meiner beiden Lösungsvorschläge praktikabel ist und welche Variante bevorzugt werden sollte.
Rahmenbedingungen
Das Unternehmen hat folgende Abteilungen:
Webentwicklung
Marketing
Vertrieb
Controlling
In jeder Abteilung gibt es 50 Arbeitsplatzrechner, die alle unter einer gemeinsamen Domäne verwaltet werden sollen. Zusätzlich betreibt das Unternehmen eine SaaS-Plattform, bestehend aus:
Die Anforderungen an die Infrastruktur:
Lösungsvorschlag 1
Jede Abteilung erhält ein eigenes Subnetz. Ein fünftes Subnetz wird eingerichtet, in dem das Produktivsystem, das Entwicklungssystem und der Domänencontroller untergebracht sind. Der Zugriff auf das Produktivsystem und den Domänencontroller wird für alle Abteilungen durch großzügige Firewall-Regeln erlaubt.
Problem:
Da alle Abteilungen Zugriff auf das fünfte Subnetz haben, könnten auch andere Mitarbeiter auf das Entwicklungssystem zugreifen, obwohl dies nur für die Webentwicklung gedacht ist. Dies birgt ein Sicherheitsrisiko.
Lösungsvorschlag 2
Die Abteilungen Marketing, Vertrieb und Controlling teilen sich ein gemeinsames Subnetz (A) mit einer eigenen Domäne und einem separaten Domaincontroller. Die Webentwicklung wird in einem eigenen Subnetz (B) untergebracht, zusammen mit dem Entwicklungssystem. Das Produktivsystem befindet sich in einem weiteren separaten Subnetz (C), in dem keine Clients stehen.
Zugriffskontrolle:
Frage an die Experten
Welcher der beiden Vorschläge ist besser geeignet, um Sicherheit und Funktionalität zu gewährleisten? Gibt es vielleicht andere Empfehlungen oder Änderungen, die ich berücksichtigen sollte?
Vielen Dank für eure Unterstützung!
für mein Abschlussprojekt plane ich eine Netzwerkinfrastruktur und benötige die Einschätzung erfahrener Experten, ob einer meiner beiden Lösungsvorschläge praktikabel ist und welche Variante bevorzugt werden sollte.
Rahmenbedingungen
Das Unternehmen hat folgende Abteilungen:
Webentwicklung
Marketing
Vertrieb
Controlling
In jeder Abteilung gibt es 50 Arbeitsplatzrechner, die alle unter einer gemeinsamen Domäne verwaltet werden sollen. Zusätzlich betreibt das Unternehmen eine SaaS-Plattform, bestehend aus:
- Produktivsystem: Unternehmensportal mit wichtigen Apps für alle Abteilungen.
- Entwicklungssystem: Wird ausschließlich von der Webentwicklung genutzt, um das Unternehmensportal weiterzuentwickeln.
Die Anforderungen an die Infrastruktur:
- Alle Abteilungen benötigen Zugriff auf das Produktivsystem.
- Nur die Abteilung Webentwicklung darf auf das Entwicklungssystem zugreifen.
Lösungsvorschlag 1
Jede Abteilung erhält ein eigenes Subnetz. Ein fünftes Subnetz wird eingerichtet, in dem das Produktivsystem, das Entwicklungssystem und der Domänencontroller untergebracht sind. Der Zugriff auf das Produktivsystem und den Domänencontroller wird für alle Abteilungen durch großzügige Firewall-Regeln erlaubt.
Problem:
Da alle Abteilungen Zugriff auf das fünfte Subnetz haben, könnten auch andere Mitarbeiter auf das Entwicklungssystem zugreifen, obwohl dies nur für die Webentwicklung gedacht ist. Dies birgt ein Sicherheitsrisiko.
Lösungsvorschlag 2
Die Abteilungen Marketing, Vertrieb und Controlling teilen sich ein gemeinsames Subnetz (A) mit einer eigenen Domäne und einem separaten Domaincontroller. Die Webentwicklung wird in einem eigenen Subnetz (B) untergebracht, zusammen mit dem Entwicklungssystem. Das Produktivsystem befindet sich in einem weiteren separaten Subnetz (C), in dem keine Clients stehen.
Zugriffskontrolle:
- Der Zugriff auf das Produktivsystem (C) wird für alle Abteilungen offen gehalten.
- Der Zugriff auf das Entwicklungssystem (B) wird stark eingeschränkt, sodass nur die Webentwicklung darauf zugreifen kann.
Frage an die Experten
Welcher der beiden Vorschläge ist besser geeignet, um Sicherheit und Funktionalität zu gewährleisten? Gibt es vielleicht andere Empfehlungen oder Änderungen, die ich berücksichtigen sollte?
Vielen Dank für eure Unterstützung!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-ID: 669732
Url: https://administrator.de/contentid/669732
Printed on: December 5, 2024 at 15:12 o'clock
17 Comments
Latest comment
Du machst einfach ein paar VLANs auf - und die Firewall regelt dann eben welches VLAN auf welchen Server zugreifen darf (oder du packst den Entwicklungsserver in nen eigenes VLAN bzw. mit ins Dev-VLAN, das ist ein wenig Geschmacksfrage).
1
Moin,
Wie @maretz schon schrieb: man darf auch mehr als nur 5 VLANs etablieren.
Würde die DCs noch separieren.
Das Entwicklungssystem entweder in ein eigenes packen oder die Firewall am Router + am DevServer selbst so reglementieren, dass nur die richtigen Abteilungen Zugriff haben.
Am Rande: Du schreibst SaaS. Ist das Zeig auch aus dem WAN erreichbar?
Dann brauchst du Themen wie DMZ und WAF etc…
Wie @maretz schon schrieb: man darf auch mehr als nur 5 VLANs etablieren.
Würde die DCs noch separieren.
Das Entwicklungssystem entweder in ein eigenes packen oder die Firewall am Router + am DevServer selbst so reglementieren, dass nur die richtigen Abteilungen Zugriff haben.
Am Rande: Du schreibst SaaS. Ist das Zeig auch aus dem WAN erreichbar?
Dann brauchst du Themen wie DMZ und WAF etc…
1
Hallo,
vermutlich ist die Prämisse, dass die Subnetze die Grenzen des dedizierten Firewallings definieren. Dann sind beide Vorschläge ungeeignet, weil die Subnetze keine sinnvolle Sicherheitsklassifikation der Systeme erkennen lassen.
Clients, DCs, Produktiv- und Entwicklungsumgebung sind voneinander zu separieren. Das ist die zentrale Erwartung bei einer solchen Aufgabenstellung und auch in der Praxis. Ob man Subnetze für Abteilungen aufmacht, hängt von weiteren Annahmen ab, etwa der eingesetzten Netzwerktechnik, oder wie antiquiert die Aufgabenstellung ist. In der Praxis würde man das eher nicht tun, weil die Clients ohnehin innerhalb ihrer Subnetze voneinander isoliert sein sollten, und Subnetze auch nicht zwingend für die Zuordnung zu Abteilungen/Firewall-Gruppen erforderlich sind.
Grüße
Richard
vermutlich ist die Prämisse, dass die Subnetze die Grenzen des dedizierten Firewallings definieren. Dann sind beide Vorschläge ungeeignet, weil die Subnetze keine sinnvolle Sicherheitsklassifikation der Systeme erkennen lassen.
Clients, DCs, Produktiv- und Entwicklungsumgebung sind voneinander zu separieren. Das ist die zentrale Erwartung bei einer solchen Aufgabenstellung und auch in der Praxis. Ob man Subnetze für Abteilungen aufmacht, hängt von weiteren Annahmen ab, etwa der eingesetzten Netzwerktechnik, oder wie antiquiert die Aufgabenstellung ist. In der Praxis würde man das eher nicht tun, weil die Clients ohnehin innerhalb ihrer Subnetze voneinander isoliert sein sollten, und Subnetze auch nicht zwingend für die Zuordnung zu Abteilungen/Firewall-Gruppen erforderlich sind.
Grüße
Richard
Moin @Enrixk,
ich würde die Clients nicht nur per normalen V-LAN's separieren, sondern mit Isolated-Private-V-LAN's.
So stellst du auf eine sehr einfache Weise sicher, dass z.B. ein infizierter Client die anderen Clients im selben Subnetz nicht auch mit infizieren kann, da in einem Isolated-P-VLAN kein Client direkt den anderen erreichen kann.
Die DC, das Produktivsystem und auch das Entwicklungssystem sollten so wie die Kollegen das vorher schon angesprochen haben auch jeweils per eigenständigem V-LAN separiert werden und dazwischen schön alles mit einem anständigen SGW regeln und schon ist der 🐟 geputzt.
By the way ...
... nein, nix großzügige Firewall-Regeln, sondern nur das was wirklich benötigt wird. 😉
Gruss Alex
ich würde die Clients nicht nur per normalen V-LAN's separieren, sondern mit Isolated-Private-V-LAN's.
So stellst du auf eine sehr einfache Weise sicher, dass z.B. ein infizierter Client die anderen Clients im selben Subnetz nicht auch mit infizieren kann, da in einem Isolated-P-VLAN kein Client direkt den anderen erreichen kann.
Die DC, das Produktivsystem und auch das Entwicklungssystem sollten so wie die Kollegen das vorher schon angesprochen haben auch jeweils per eigenständigem V-LAN separiert werden und dazwischen schön alles mit einem anständigen SGW regeln und schon ist der 🐟 geputzt.
By the way ...
Der Zugriff auf das Produktivsystem und den Domänencontroller wird für alle Abteilungen durch großzügige Firewall-Regeln erlaubt.
... nein, nix großzügige Firewall-Regeln, sondern nur das was wirklich benötigt wird. 😉
Gruss Alex
1
Isolated-Privat-Vlans sind nicht einfach wenn man es richtig umsetzt 🙈.
der vorschlag ist auch - sofern man die umgebung nicht kennt - schon fragwürdig. Wenn da _wirklich_ nur Rechner drin hängen -> ok... Aber: wenn zB. irgendwelche Drucker, Scanner usw. ins Spiel kommen kann es schon (je nach Setup) interessant werden. Ob es einen Sicherheitsgewinn bietet ist auch je nach Umgebung unterschiedlich -> im besten Fall sollte der Client-PC ja eh nix offen haben wenn es nich nötig ist. Auch da gilt eben wieder "Sicherheit ist kein Produkt, es ist ein Konzept".
802.1x Port Security bzw. NAC wäre da dann sinnvoller. Bei einem seriösen Infrastrukturprojekt mit Zugangsbeschränkungen wie dem des TO mit Thema Sicherheit so oder so immer ein Muss.
Interessant auch das das Thema Gäste, Captive Portal etc. in dem Projekt scheinbar keins ist?!
Interessant auch das das Thema Gäste, Captive Portal etc. in dem Projekt scheinbar keins ist?!
Zitat von @aqui:
802.1x Port Security bzw. NAC wäre da dann sinnvoller. Bei einem seriösen Infrastrukturprojekt mit Thema Sicherheit so oder so ein Muss.
Interessant auch das das Thema Gäste, Captive Portal etc. in dem Projekt scheinbar keins ist?!
802.1x Port Security bzw. NAC wäre da dann sinnvoller. Bei einem seriösen Infrastrukturprojekt mit Thema Sicherheit so oder so ein Muss.
Interessant auch das das Thema Gäste, Captive Portal etc. in dem Projekt scheinbar keins ist?!
Es ist eine _ABSCHLUSSARBEIT_ -> d.h. da ist der Rahmen normal limitiert. Das sollte man auch ein wenig im Hinterkopf behalten -> ansonsten kann man so ein Projekt auch soweit aufblähen das man nie fertig wird.
Moin @Spirit-of-Eli,
ja P-VLAN's sind etwas komplizierter als normale VLAN's, aber, so viel nun auch nicht, zumindest wenn man nur die Clients in ein Isolated-Private-V-LAN steckt.
Im Gegenzug ist jeder Client gegenüber den anderen Clients im selben Netzsegment absolut abgeschottet und zwar ohne, dass die Clients eine eigene lokale SW-FW benötigen, deren Pflege ja auch einen zusätzlichen Aufwand erzeugt.
Gruss Alex
Isolated-Privat-Vlans sind nicht einfach wenn man es richtig umsetzt 🙈.
ja P-VLAN's sind etwas komplizierter als normale VLAN's, aber, so viel nun auch nicht, zumindest wenn man nur die Clients in ein Isolated-Private-V-LAN steckt.
Im Gegenzug ist jeder Client gegenüber den anderen Clients im selben Netzsegment absolut abgeschottet und zwar ohne, dass die Clients eine eigene lokale SW-FW benötigen, deren Pflege ja auch einen zusätzlichen Aufwand erzeugt.
Gruss Alex
1
Moin @maretz,
angesichts der mageren Information, die der TO zu der (theoretischen) Umgebung bisher geliefert hat, sehe ich noch keine grossen Probleme.
Na ja, wenn man Netzsegmentierung richtig macht, dann befinden sich in einem Client (P)V-LAN normalerweise auch nur Clients drin und kein sonstiger Krust.
Die packt man am Besten in ein separates (P)V-LAN und steuert die Zugriffe zwischen diesen Geräten und den Clients und oder auch Server, zentral über ein ordentliches SGW oder von mir aus auch eine NGFW.
Na ja, so ist meiner Ansicht nach mit relativ überschaubaren Mitteln sichergestellt, dass sich ein Schädling sich nicht wirklich über das selbe Subnetz verteilen kann und zwar ganz ohne zusätzliche Schutzmassnahmen auf der Clientseite.
In der Theorie ja, wie es in der Praxis jedoch aussieht, weist du glaube ich auch selber gut genug.
Und ja, natürlich kann man die Clients per lokaler SW-FW & Co "härten". Ich finde jedoch die Möglichkeit der Isolierung per PV-LAN durchaus auch einen guten Ansatz, zumal dieser meiner Erfahrung nach deutlich weniger Aufwand nach sich zieht, als die Härtung der Clients z.B. per lokaler SW-FW.
👍👍👍
Gruss Alex
der vorschlag ist auch - sofern man die umgebung nicht kennt - schon fragwürdig.
angesichts der mageren Information, die der TO zu der (theoretischen) Umgebung bisher geliefert hat, sehe ich noch keine grossen Probleme.
Wenn da _wirklich_ nur Rechner drin hängen -> ok...
Na ja, wenn man Netzsegmentierung richtig macht, dann befinden sich in einem Client (P)V-LAN normalerweise auch nur Clients drin und kein sonstiger Krust.
Aber: wenn zB. irgendwelche Drucker, Scanner usw. ins Spiel kommen kann es schon (je nach Setup) interessant werden.
Die packt man am Besten in ein separates (P)V-LAN und steuert die Zugriffe zwischen diesen Geräten und den Clients und oder auch Server, zentral über ein ordentliches SGW oder von mir aus auch eine NGFW.
Ob es einen Sicherheitsgewinn bietet ist auch je nach Umgebung unterschiedlich
Na ja, so ist meiner Ansicht nach mit relativ überschaubaren Mitteln sichergestellt, dass sich ein Schädling sich nicht wirklich über das selbe Subnetz verteilen kann und zwar ganz ohne zusätzliche Schutzmassnahmen auf der Clientseite.
-> im besten Fall sollte der Client-PC ja eh nix offen haben wenn es nich nötig ist.
In der Theorie ja, wie es in der Praxis jedoch aussieht, weist du glaube ich auch selber gut genug.
Und ja, natürlich kann man die Clients per lokaler SW-FW & Co "härten". Ich finde jedoch die Möglichkeit der Isolierung per PV-LAN durchaus auch einen guten Ansatz, zumal dieser meiner Erfahrung nach deutlich weniger Aufwand nach sich zieht, als die Härtung der Clients z.B. per lokaler SW-FW.
Auch da gilt eben wieder "Sicherheit ist kein Produkt, es ist ein Konzept".
👍👍👍
Gruss Alex
1Zitat von @MysticFoxDE:
Moin @Spirit-of-Eli,
ja P-VLAN's sind etwas komplizierter als normale VLAN's, aber, so viel nun auch nicht, zumindest wenn man nur die Clients in ein Isolated-Private-V-LAN steckt.
Im Gegenzug ist jeder Client gegenüber den anderen Clients im selben Netzsegment absolut abgeschottet und zwar ohne, dass die Clients eine eigene lokale SW-FW benötigen, deren Pflege ja auch einen zusätzlichen Aufwand erzeugt.
Gruss Alex
Moin @Spirit-of-Eli,
Isolated-Privat-Vlans sind nicht einfach wenn man es richtig umsetzt 🙈.
ja P-VLAN's sind etwas komplizierter als normale VLAN's, aber, so viel nun auch nicht, zumindest wenn man nur die Clients in ein Isolated-Private-V-LAN steckt.
Im Gegenzug ist jeder Client gegenüber den anderen Clients im selben Netzsegment absolut abgeschottet und zwar ohne, dass die Clients eine eigene lokale SW-FW benötigen, deren Pflege ja auch einen zusätzlichen Aufwand erzeugt.
Gruss Alex
Das Resultat kenne ich und finde ich super.
Nur der Aufwand ist riesig da ja für hin und Rückweg unterschiedliche Vlan IDs notwendig sind.
Ergo muss nur für P-Vlans die gesamte switch Kette bis zum Gateway konfiguriert werden.
Moin @Spirit-of-Eli,
ja, OK, durch das "Mehrschichtmodel" (Isolated/Community) ist PV-LAN von der Materie schon etwas aufwendiger und auch das mit den "Promiscuous Ports" muss man wirklich richtig verstehen.
Aber, bevor ich bei ~ 200 Clients die lokale Windows-FW anfange zu konfigurieren, sei es auch per GPO, würde ich eher auf PV-LAN setzen.
Ist ja auch nicht der, sondern nur einer von sehr vielen möglichen Wegen nach Rom. 🙃
Ja, korrekt und die entsprechenden Switche müssen PV-LAN auch erstmal supporten, was bei weitem nicht für jedes Model zutrifft. 😔
Ich würde es dennoch und vor allem bei einer (theoretischen) Arbeit mit ins Spiel bringen, zumindest dann wenn man die entsprechende Materie auch richtig verstanden hat.
Denn würde ich diese Arbeit selbst korrigieren, dann würde der TO alleine schon für denn PV-LAN Ansatz, von mir mindestens einen extra Punkt bekommen, gerade weil es eben nicht ohne ist, aber dafür auch einiges mit sich bringt. 😁
Gruss Alex
Nur der Aufwand ist riesig da ja für hin und Rückweg unterschiedliche Vlan IDs notwendig sind.
ja, OK, durch das "Mehrschichtmodel" (Isolated/Community) ist PV-LAN von der Materie schon etwas aufwendiger und auch das mit den "Promiscuous Ports" muss man wirklich richtig verstehen.
Aber, bevor ich bei ~ 200 Clients die lokale Windows-FW anfange zu konfigurieren, sei es auch per GPO, würde ich eher auf PV-LAN setzen.
Ist ja auch nicht der, sondern nur einer von sehr vielen möglichen Wegen nach Rom. 🙃
Ergo muss nur für P-Vlans die gesamte switch Kette bis zum Gateway konfiguriert werden.
Ja, korrekt und die entsprechenden Switche müssen PV-LAN auch erstmal supporten, was bei weitem nicht für jedes Model zutrifft. 😔
Ich würde es dennoch und vor allem bei einer (theoretischen) Arbeit mit ins Spiel bringen, zumindest dann wenn man die entsprechende Materie auch richtig verstanden hat.
Denn würde ich diese Arbeit selbst korrigieren, dann würde der TO alleine schon für denn PV-LAN Ansatz, von mir mindestens einen extra Punkt bekommen, gerade weil es eben nicht ohne ist, aber dafür auch einiges mit sich bringt. 😁
Gruss Alex
1
Wenn es das denn nun war als Lösung bitte nicht vergessen deinen Tread dann auch als erledigt zu markieren!
How can I mark a post as solved?
How can I mark a post as solved?
Clients, DCs, Produktiv- und Entwicklungsumgebung sind voneinander zu separieren. Das ist die zentrale Erwartung bei einer solchen Aufgabenstellung und auch in der Praxis. Ob man Subnetze für Abteilungen aufmacht, hängt von weiteren Annahmen ab, etwa der eingesetzten Netzwerktechnik, oder wie antiquiert die Aufgabenstellung ist. In der Praxis würde man das eher nicht tun, weil die Clients ohnehin innerhalb ihrer Subnetze voneinander isoliert sein sollten, und Subnetze auch nicht zwingend für die Zuordnung zu Abteilungen/Firewall-Gruppen erforderlich sind.
Du schreibt, man soll Clients und DC voneinander separieren und gleichzeitig die Subnetze für die Abteilungen nicht aufmachen.
Ich habe eine Rückfrage dazu. Wie können die Clients in den Abteilungen auf den DC zugreifen oder ins Internet gelangen, wenn die Subnetze "nicht aufgemacht" sind? Will man denn in der Praxis nicht immer etwas Datenverkehr durchlassen? Oder muss ich das so verstehen, dass jede Abteilung einen eigenen DC mit Fileserver und Backup-Server in ihrem Subnetz bekommt? Vielleicht verstehe ich auch etwas an dem Begriff aufmachen nicht.
Wenn es das denn nun war als Lösung bitte nicht vergessen deinen Tread dann auch als erledigt zu markieren!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Ich habe Schwierigkeiten, die praktikabelste Lösung zu beurteilen und kann nicht sicher sagen, ob die vorgeschlagenen Optionen korrekt sind. Daher fällt es mir schwer, die richtige Lösung auszuwählen. Soweit ich das verstehe, tendieren die meisten zu Lösungsvorschlag 1, unter der Voraussetzung, dass DC, Produktivsystem und Entwicklungssystem in jeweils einem separaten VLAN untergebracht werden.
Das Trennen der Clients durch VLANs wird hier auch aus Sicherheitsgründen bevorzugt. Kann mir jemand erklären, warum in diesem Fall VLANs anstelle eines normalen Routers verwendet werden müssen? Und erhöhen VLANs automatisch die Sicherheit, oder hängt dies von den spezifischen Firewall-Regeln ab
Das Zauberwort sind "VLANs". Denn wenn du einfach nur ne anderes Subnetz nimmst - was hindert mich daran meine IP entsprechend abzuändern und schon bin ich im "Server" Netz? VLANs sind im prinzip wie getrennte Switches zu sehen, da kannst du ändern so lang du willst, da geht nix. Und der Router/die Firewall kümmert sich dann halt darum das der Traffic nur auf den benötigten Ports erlaubt wird.
1Zitat von @Enrixk:
Ich habe eine Rückfrage dazu. Wie können die Clients in den Abteilungen auf den DC zugreifen oder ins Internet gelangen, wenn die Subnetze "nicht aufgemacht" sind? Will man denn in der Praxis nicht immer etwas Datenverkehr durchlassen? Oder muss ich das so verstehen, dass jede Abteilung einen eigenen DC mit Fileserver und Backup-Server in ihrem Subnetz bekommt? Vielleicht verstehe ich auch etwas an dem Begriff aufmachen nicht.
Ich habe eine Rückfrage dazu. Wie können die Clients in den Abteilungen auf den DC zugreifen oder ins Internet gelangen, wenn die Subnetze "nicht aufgemacht" sind? Will man denn in der Praxis nicht immer etwas Datenverkehr durchlassen? Oder muss ich das so verstehen, dass jede Abteilung einen eigenen DC mit Fileserver und Backup-Server in ihrem Subnetz bekommt? Vielleicht verstehe ich auch etwas an dem Begriff aufmachen nicht.
Hatte ich unglücklich formuliert, ich meinte mit "aufmachen" das Anlegen von Subnetzen pro Abteilung. Dein erster Vorschlag war:
Jede Abteilung erhält ein eigenes Subnetz. Ein fünftes Subnetz wird eingerichtet, in dem das Produktivsystem, das Entwicklungssystem und der Domänencontroller untergebracht sind.
Die (klar vorrangige) Berücksichtung unterschiedlicher Abteilungen mit individuellen Subnetzen ist eine falsche Prioritätensetzung. Alle Abteilungen zusammen können unter Sicherheitsaspekten als eine Gruppe Clients betrachtet werden, die zwar vom Rest, aber nicht zwingend untereindander separiert werden müssen. Wenn hingegen von einem Entwicklungs- und Produktivsystem die Rede ist, ist das ein Wink mit dem Zaunpfahl, da deren Trennung standardmäßiger Bestandteil von Prüfkatalogen ist. Und DCs müssen immer geschützt werden, können also weder mit den Web-Servern in Vorschlag 1, noch mit den Clients in Vorschlag 2 zusammengebracht werden.
Dabei sei vorausgesetzt, dass die Netze physisch getrennt oder in eigenen VLANs geswitcht werden, und sich nicht Layer 2 teilen. Auch werden (nur) die erforderlichen Verbindungen in der Firewall freigegeben.
Man kann natürlich dennoch mit einem Client-Netz pro Abteilung (anstelle eines einzigen) arbeiten, z.B. wenn die Zugehörigkeit zu einem Subnetz das Kriterium sein soll, nach dem Zugriff auf das Entwicklungssystem gewährt wird oder nicht. Oder um der Tatsache Rechnung zu tragen, dass die Nutzer/Clients unterschiedlicher Abteilungen leicht unterschiedliche Risiko-Charakteristiken haben, und - ohne weitere Maßnahmen - Client-zu-Client-Verkehr möglich wäre.
Es ist nur mit den in der Praxis flankierenden Maßnahmen (NAC, Port-Isolation) nicht erforderlich. Das sind weitergehende Fragen, die davon abhängen, unter welchen Gegebenheiten bei dieser Aufgabenstellung gearbeitet werden soll.
