Windows Server 2008 Sicherheit – Die technische Referenz - Gattner

398 Kapitel 14: Schützen des Netzwerks
grammen ganz toll aussieht, aber in Wirklichkeit unmöglich zu implementieren ist. Das ist
Ihre Chance zu überprüfen, wie gut Ihre Strategie tatsächlich implementiert werden kann.
Falls Sie keine Risikomanagementstrategie haben, sollten Sie wahrscheinlich diese Gelegenheit
nutzen, um eine zu formulieren.
Hinweis Vielleicht ist Ihnen aufgefallen, dass wir die stillschweigende Annahme gemacht haben, dass es
keinen Unterschied bei der Zugriffsebene auf einen bestimmten Computer gibt. Oder genauer: dass dieser
Unterschied für die Netzwerkgefahrenmodellierung nicht relevant ist. Windows bietet aber in beträchtlichem
Umfang Isolierungsmechanismen, die verhindern, dass jemand mit bloßem Standardbenutzerzugriff auf
einen Computer diesen Computer vollständig kontrollieren kann. Die Netzwerkgefahrenmodellierung ist
aber ohnehin schon kompliziert genug; wenn wir diesen Faktor auch noch einbeziehen, wird das Modell
noch viel komplexer. Stattdessen gehen wir von einer Worst-Case-Annahme aus: Wir bauen unsere Isolierungstechniken
darauf auf, was ein Angreifer mit vollständiger Kontrolle über einen Computer mit diesem
Computer tun kann. Zum Beispiel: Falls ein Angreifer vollständige Kontrolle über einen Teamworkserver
hat, welchen Zugriff gibt ihm das auf die Datenbankserver? Die Antwort hängt davon ab, wie wir das Netzwerk
verwalten (welche Benutzer sich an den Teamworkservern anmelden) und welcher Verkehr zwischen
den beiden Computern erlaubt ist.
Schritt 5: Entwerfen der Isolierungsstrategie
Wenn Sie ein Netzwerkgefahrenmodell haben, das Sinn ergibt, können Sie damit beginnen,
die Isolierungsstrategie abzuleiten. Die Isolierungsstrategie basiert in weiten Teilen auf den
Kommunikationsmustern, die Sie in Abbildung 14.8 identifiziert haben. Sie sollten so restriktiv
wie möglich sein, aber natürlich dürfen Sie es nicht übertreiben. Sie können das
Ergebnis in einer Tabelle dokumentieren, die die Servertypen und Kommunikationsmuster
aufführt. Die Tabelle listet auf: Quell- und Zielhosts, Ports, Protokolle, ob der Verkehr authentifiziert
und/oder verschlüsselt sein muss und ob die Verbindung auch in umgekehrter
Richtung (gespiegelt) verlaufen kann. Hier wird es wirklich konkret. Statt einfach »DC-
Verkehr« zu sagen, müssen Sie die Ports und Protokolle auflisten. Eine sehr nützliche Referenz
für diese Phase ist der Microsoft Knowledge Base-Artikel 832017, »Dienste und Port-
Anforderungen für das Microsoft Windows-Serversystem«.
Das Endergebnis dieses Schritts sollte eine Tabelle sein, die alle erforderlichen Kommunikationsmuster
in Ihrem Netzwerk auflistet. Ihre Tabelle sollte ähnlich wie Tabelle 14.3 aussehen,
aber natürlich wird sie viel länger sein.
Wie Sie sehen, können die Daten in dieser Tabelle recht umfangreich werden. Aber wenn
Sie das Netzwerk angemessen untergliedert haben, müsste das Zusammenstellen der Daten
mühsam, aber nicht schwierig sein. Wenn Sie damit fertig sein, haben Sie die IPsec-Implementierung
der Serverisolierung in Ihrem Netzwerk fast abgeschlossen. Beachten Sie, dass
die Spaltenüberschriften in Tabelle 14.3 genau die Informationen wiedergeben, die Sie für
Ihre IPsec-Regeln brauchen. Wenn Sie echte Initiative zeigen wollen, können Sie Tabelle 14.3
in eine Tabellenkalkulation eingeben und sie dann mit einem Makro in einer Reihe von
IPsec-Befehlen konvertieren, die die erforderlichen IPsec-Richtlinien generieren. Sie können
IPsec auf der Befehlszeile konfigurieren, indem Sie den Befehl netsh advfirewall consec add
rule aufrufen. Weitere Informationen zu IPsec finden Sie auf der Microsoft-IPsec-Site unter
http://technet.microsoft.com/en-us/network/bb531150.aspx.