Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien Kapitel 3: Ermitteln des aktuellen Status der IT-Infrastruktur

Dieses Kapitel enthält Anweisungen dazu, wie Sie die erforderlichen Informationen zur Planung und Bereitstellung einer Lösung zur Server- und Domänenisolierung erhalten können. Für eine erfolgreiche Bereitstellung müssen Sie sich zunächst ein genaues und aktuelles Bild der IT-Infrastruktur machen. Im Anschluss an die Lektüre dieses Kapitels sollten Sie genau verstehen, welche Informationen erforderlich sind, um den Entwurf der Lösung zur Server- und Domänenisolierung fertig zu stellen.

Im letzten Teil dieses Kapitels wird erörtert, wie ermittelt und dokumentiert werden kann, welche Computer höchstwahrscheinlich in der Lösung als "vertrauenswürdige" Computer eingesetzt werden können. Diese Informationen werden vom Entwurfsteam bei der Erstellung von Plänen für die Lösung benötigt.

Auf dieser Seite	In diesem Beitrag
Voraussetzungen für das Kapitel Zielgruppe des Kapitels Ermitteln des aktuellen Status Überlegungen zur Kapazität Überlegungen vor der Bereitstellung Bestimmung der Vertrauensstellung Erfassen der Aktualisierungskosten für aktuelle Hosts Zusammenfassung	Überblick - Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien Kapitel 1: Einführung in die Server- und Domänenisolierung Kapitel 2: Grundlagen der Server- und Domänenisolierung Kapitel 3: Ermitteln des aktuellen Status der IT-Infrastruktur Kapitel 4: Entwerfen und Planen von Isolierungsgruppen Kapitel 5: Erstellen von IPSec-Richtlinien für Isolierungsgruppen Kapitel 6: Verwalten einer Server- und Domänenisolierungsumgebung Kapitel 7: Problembehandlung für IPSec Anhang A: Überblick über IPSec-Richtlinienkonzepte Anhang B: Zusammenfassung zu IPSec-Richtlinien Anhang C: Leitfaden zum Aufbau einer Testumgebung Anahng D: IT-Bedrohungskategorien Danksagungen
	Vollständige Lösung downloaden Server-und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien (engl.)

Voraussetzungen für das Kapitel

Bevor Sie mit den Informationen in diesem Kapitel arbeiten, sollten Sie sicherstellen, dass Sie und Ihre Organisation die nachstehenden Voraussetzungen erfüllen. Die in diesem Kapitel bereitgestellten Anleitungen sind speziell auf die Anforderungen einer Organisation zugeschnitten, bei der diese Voraussetzungen großteils gegeben sind. Sollten nicht alle Voraussetzungen erfüllt sein, so hat dies nicht unbedingt negative Auswirkungen auf Ihr Projekt; wenn jedoch allen Anforderungen entsprochen wird, können Sie einen optimalen Nutzen aus diesen Anleitungen ziehen.

Vorausgesetzte Kenntnisse

Sie sollten mit den Konzepten von IPSec vertraut sein und zudem fundierte Kenntnisse zu folgenden Themen besitzen:

• Microsoft® Windows®-Authentifizierung (insbesondere Kerberos-Authentifizierungsprotokoll Version 5)
• Active Directory®-Verzeichnisdienstkonzepte, darunter Active Directory-Struktur und -Tools; Verwalten von Benutzern, Gruppen und anderen Active Directory-Objekten und Verwenden von Gruppenrichtlinien.
• Windows-Systemsicherheit, einschließlich Sicherheitskonzepte wie Benutzer, Gruppen, Überwachung und Zugriffssteuerungslisten (Access Control Lists, ACL).
• Namenskonventionen Ihrer Organisation
• Physische und logische Standorte Ihrer Organisation
• In der Organisation eingesetzte Verfahren zur Verwaltung von Sicherheitsrisiken
• Hauptnetzwerkkonzepte, z. B. Portfilterung mithilfe von Firewalls

Bevor Sie mit diesem Kapitel fortfahren, sollten Sie die vorangegangenen Kapitel dieses Leitfadens gelesen und die Konzepte hinsichtlich Architektur und Entwurf der Lösung vollständig verstanden haben.

Unternehmensvoraussetzungen

An der Planung von Isolierungsgruppen für eine Organisation sind normalerweise zahlreiche verschiedene Personen beteiligt. Die zur Ermittlung der genauen Anforderungen erforderlichen Informationen stammen oft aus eine Reihe unterschiedlicher Quellen innerhalb der Organisation. Sie sollten sich mit anderen Mitarbeitern Ihres Unternehmens beraten, die unter Umständen in die Planung dieser Lösung mit einbezogen werden müssen. Dazu können beispielsweise die folgenden Personen gehören:

• Geschäftssponsoren

• Für Sicherheit und Überwachung zuständige Mitarbeiter

• Für Verwaltung, Betrieb und technische Aspekte von Active Directory zuständige Mitarbeiter

• Verantwortliche für DNS (Domain Name System, Domänennamensystem), Webserver und Anwendungen

• Für Netzwerkverwaltung und -betrieb zuständige Mitarbeiter

• Firmeninternes Schulungs- und Helpdeskpersonal

  Hinweis

  
  Je nach Struktur Ihrer IT-Organisation werden diese Rollen jeweils von einer Reihe von Mitarbeitern ausgefüllt, oder aber einige wenige Mitarbeiter sind jeweils für mehrere Rollen zuständig.
  

Es sind nicht nur Informationen von den aufgelisteten Teams erforderlich, sondern darüber hinaus muss mit der Einführung von IPSec in die Umgebung eine Aktualisierung der zurzeit bestehenden Betriebsverfahren stattfinden. Auch müssen gegebenenfalls Software und Hardware aktualisiert werden, etwa das BIOS und die Firmware von Netzwerkgeräten. Schließlich kann es sein, dass zusätzliche Netzwerktools für Support und Problembehandlung in der IPSec-Umgebung erforderlich sind.

Grundvoraussetzungen der IT-Infrastruktur

In diesem Kapitel wird auch davon ausgegangen, dass die folgende IT-Infrastruktur vorhanden ist:

• Eine Microsoft Windows Server 2003 Active Directory-Domäne im gemischten oder einheitlichen Modus. Bei dieser Lösung werden universelle Gruppen für die Anwendung von Gruppenrichtlinienobjekten (Group Policy Objects, GPOs) verwendet. Auch wenn in der Organisation nicht der gemischte oder der einheitliche Modus ausgeführt wird, ist es dennoch möglich, das GPO durch standardmäßige Konfigurationen globaler und lokaler Gruppen anzuwenden. Da diese Option jedoch schwieriger zu verwalten ist, wird sie in dieser Lösung nicht verwendet.

  Hinweis

  
  Windows Server 2003 umfasst eine Reihe von Verbesserungen, die sich auf IPSec-Richtlinien auswirken. In der vorliegenden Lösung sind keine speziellen Konfigurationen enthalten, die einem einwandfreien Betrieb mit Windows 2000 im Wege stehen würden. Die Lösung wurde jedoch nur mit Windows Server 2003 Active Directory getestet.
  Weitere Informationen zu den Verbesserungen an IPSec in Windows Server 2003 finden Sie auf der Seite New features for IPsec der Microsoft-Website unter www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/ipsec_whatsnew.asp (in englischer Sprache).

• Die Fähigkeit und Kompetenz zur Durchführung von Netzwerküberwachung, Analyse von Überwachungsdaten und Entscheidungsfindung hinsichtlich der Kapazitätsplanung auf der Basis dieser Daten.

  Hinweis

  
  Die Verwendung von Netzwerküberwachungstools unterliegt in vielen Organisationen bestimmten Beschränkungen. Daher muss sichergestellt werden, dass bei Einsatz dieser Tools die entsprechenden Betriebsverfahren berücksichtigt werden.

• Es ist ein Tool vorhanden, mit dem die Netzwerkkonfigurationsdaten der Hosts im Netzwerk erfasst werden können. Beispielsweise können vorhandene Ressourcenmanagementsysteme zur Sammlung dieser Informationen eingesetzt werden. Weitere Informationen dazu finden Sie im Abschnitt "Hostermittlung" weiter unten in diesem Kapitel.

Zum Seitenanfang

Zielgruppe des Kapitels

Dieses Kapitel richtet sich an IT-Spezialisten, die für die Erstellung der IT-Infrastrukturbestandsliste zuständig sind, die von Lösungsarchitekten und -entwicklern eingesetzt wird. Bei diesen IT-Spezialisten handelt es sich in der Regel um Mitarbeiter des Supports oder der Systemadministration. Es sind solide technische Kenntnisse sowohl in Bezug auf die im Informationserfassungsprozess eingesetzten Tools und Technologien als auch auf die aktuelle Infrastruktur der Organisation erforderlich, um maximalen Nutzen aus diesem Kapitel zu ziehen.

Zum Seitenanfang

Ermitteln des aktuellen Status

Ein Prozess, mit dem zuverlässig über alle Computer, Softwareanwendungen und Netzwerkgeräte einer Organisation Buch geführt werden kann, hat sich schon immer als eine Herausforderung an die IT-Abteilung erwiesen. Der Erfolg eines Projekts hängt in direktem Maße von solch einem Prozess ab. Bevor Sie den Planungsprozess für ein Projekt zur Server- und Domänenisolierung starten, müssen Sie aktuelle Informationen über die Computer, das Netzwerk und die bereits in Ihrer Organisation implementierten Verzeichnisdienste erfassen und analysieren. Anhand dieser Informationen können Sie dann einen Entwurf anfertigen, in dem alle potenziellen Elemente der bestehenden Infrastruktur berücksichtigt werden. Falls die zusammengetragenen Informationen nicht exakt sind, können Probleme entstehen, wenn Geräte und Computer, die in der Planungsphase nicht berücksichtigt wurden, während der Implementierungsphase in Erscheinung treten. In den folgenden Abschnitten werden die erforderlichen Informationen für die jeweiligen Bereiche umrissen und Beispieldaten bereitgestellt, die für die Server- und Domänenisolierungslösung der Woodgrove Bank erfasst wurden.

Netzwerkermittlung

Der vielleicht wichtigste Aspekt bei der Planung einer Server- und Domänenisolierungslösung ist die Architektur des Netzwerks, denn IPSec wird auf einer Ebene über dem eigentlichen Internetprotokoll selbst angesiedelt. Ein unvollständiges oder ungenaues Verständnis des Netzwerks wird den Erfolg einer jeden Server- und Domänenisolierungslösung verhindern. Sich ein genaues Bild von Subnetzlayout, IP-Adressierungsschemata und Datenverkehrsmustern zu machen, ist Teil dieser Bemühungen, jedoch sind die folgenden zwei Komponenten zum Abschluss der Planungsphase dieses Projekts unerlässlich:

• Dokumentieren der Netzwerksegmentierung
• Dokumentieren des aktuellen Netzwerkverkehrsmodells

Dabei wird das Ziel verfolgt, ausreichende Informationen vorliegen zu haben, um eine Ressource neben ihrem tatsächlichen physischen Standort anhand ihrer Position im Netzwerk identifizieren zu können.

Es sollte möglichst mit einer gut durchdachten Netzwerkarchitektur begonnen werden, die mühelos zu identifizierende Adressbereiche sowie möglichst wenige überlappende oder diskontinuierliche Bereiche aufweist. Es könnten bestimmte Geschäftsanforderungen oder Umstände bestehen (z. B. Unternehmenszusammenschlüsse und -zukäufe), die ein "rationalisiertes" Netzwerk unmöglich machen; wenn jedoch der aktuelle Status dokumentiert ist und verstanden wird, vereinfacht dies die Identifizierung des Netzwerks und seiner verwalteten Ressourcen. Verwenden Sie kein komplexes, schlecht dokumentiertes Netzwerk als Ausgangspunkt für den Lösungsentwurf, da hierbei zu viele nicht erkannte Bereiche offen gelassen werden könnten, die während der Implementierung höchstwahrscheinlich zu Problemen führen.

Diese Anleitung soll Sie dabei unterstützen, die wichtigsten Informationen für die Server- und Domänenisolierungslösung zusammenzutragen. Andere Themen, wie z. B. TCP/IP-Adressierung und Erstellen von Subnetzmasken mit variabler Länge, Segmentierung virtueller Lokalnetzwerke (VLANs) oder andere Netzwerkoptimierungsmethoden und -verfahren werden hier nicht angesprochen. Die zusammengetragenen Informationen dienen später dazu, die Implementierungs- und Betriebskomponenten für die Server- und Domänenisolierung zu entwickeln.

Dokumentieren der Netzwerksegmentierung

Wenn die aktuelle Netzwerkarchitektur Ihrer Organisation nicht dokumentiert und als Referenz verfügbar ist, sollte eine solche Dokumentation baldmöglichst erstellt werden, bevor Sie mit der Lösung fortfahren. Falls die dokumentierten Informationen nicht aktuell sind oder nicht vor kurzer Zeit auf ihre Gültigkeit überprüft wurden, haben Sie zwei Möglichkeiten:

• Sie akzeptieren, dass das Projekt durch diese Informationen übermäßigen Risiken ausgesetzt sein kann.
• Sie starten ein Ermittlungsprojekt, entweder durch manuelle Prozesse oder mit einem Netzwerkanalysetool, das die Informationen bereitstellen kann, die zum Dokumentieren der aktuellen Netzwerktopologie erforderlich sind.

Obwohl sich die benötigten Informationen auf verschiedene Weise darstellen lassen, ist oft der Einsatz einer Reihe schematischer Diagramme die effektivste Methode, um die aktuelle Netzwerkkonfiguration zu veranschaulichen und zu verstehen. Achten Sie bei der Erstellung von Netzwerkdiagrammen darauf, diese nicht mit zu vielen Informationen zu füllen. Verwenden Sie gegebenenfalls mehrere Diagramme, um verschiedene Detailebenen darzustellen.

Beispielsweise wurde für das Szenario der Woodgrove Bank das folgende Diagramm erstellt, um eine Gesamtübersicht über ihr vorhandenes WAN und ihre Standortumgebung zu veranschaulichen:

Abbildung 3.1: Netzwerkdiagramm für WAN und Standortumgebung der Woodgrove Bank

Bild in voller Größe anzeigen

Nach dem Erstellen dieses Diagramms wurden detailliertere Diagramme für jeden Standort und schließlich für die einzelnen Subnetze an den verschiedenen Standorten erstellt.

Beim Dokumentieren Ihres Netzwerks können Sie unter Umständen feststellen, dass einige Netzwerkanwendungen und -dienste nicht mit IPSec kompatibel sind. Zum gegenwärtigen Zeitpunkt sind u. a. folgende Komponenten nicht kompatibel:

• Cisco NetFlow auf Routern kann keine Pakete analysieren, die auf Protokoll- oder Portbasis zwischen IPSec-Mitgliedern ausgetauscht werden.

• Routerbasierte QoS-Klassifizierung (Quality of Service) kann keine Ports oder Protokolle zur Priorisierung von Datenverkehr einsetzen. Das Verwenden von IP-Adressen zur Verkehrspriorisierung ist davon jedoch nicht betroffen. Beispielsweise würde die Regel "Von allen Quellen zu jedem Ziel priorisieren, das Port 80 verwendet" nicht funktionieren, während die Regel "Verbindungen von einer beliebigen Quelle zu 10.0.1.10 priorisieren" unbeeinträchtigt bliebe.

• Geräte, die IP-Protokoll 50, den von ESP (Encapsulating Security Payload) verwendeten Port, nicht unterstützen oder zulassen.

• WFQ (Weighted Fair Queuing) und andere flussbasierte Prioritätsmethoden für Routerverkehr schlagen möglicherweise fehl.

• Netzwerküberwachungsprogramme sind eventuell nicht in der Lage, ESP-Pakete zu analysieren, die nicht verschlüsselt sind (ESP-Null).

  Hinweis

  
  Der Version 2.1 von Microsoft Netzwerkmonitor wurde durch einen ESP-Parser ergänzt, um die Problembehandlung bei unverschlüsselten IPSec-Paketen zu unterstützen. Netzwerkmonitor ist ein Bestandteil von Microsoft Systems Management Server (SMS). Weitere Informationen finden Sie auf der Microsoft Systems Management Server-Seite unter www.microsoft.com/smserver/.

• Wenn das Gerät ESP nicht analysieren kann, werden alle ACLs, die Port- oder Protokollregeln festlegen, bei den ESP-Paketen nicht verarbeitet.

• Wenn das Gerät über einen ESP-Parser verfügt und Verschlüsselung einsetzt, werden alle ACLs, die Port- oder Protokollregeln festlegen, bei den ESP-Paketen nicht verarbeitet.

IPSec verhindert netzwerkbasierte Priorisierung und port-/protokollbasierte Verkehrsverwaltung, wenn Ports und Protokolle verwendet werden. Leider lässt sich das Problem bei verschlüsselten Paketen nicht umgehen. Wenn eine auf Ports oder Protokollen basierende Verkehrsverwaltung oder Priorisierung erforderlich ist, muss der Host in der Lage sein, selbst jegliche Verwaltungs- oder Priorisierungsfunktionen durchzuführen.

Als Nächstes muss eine genaue Aufstellung aller Informationen gemacht werden, die für die verschiedenen Geräte im Netzwerk benötigt werden.

Geräte der Netzwerkinfrastruktur

Nach Implementierung der Lösung kommunizieren die Geräte, aus denen sich die Netzwerkinfrastruktur zusammensetzt (Router, Switches, Lastenausgleicher und Firewalls) untereinander über IPSec. Aus diesem Grunde sollten unbedingt die folgenden Merkmale dieser Geräte im Netzwerk überprüft werden, um sicherzustellen, dass sie die technischen und physischen Anforderungen des Entwurfs bewältigen können:

• Fabrikat/Modell. Anhand dieser Informationen können Sie die Features bestimmen, die von dem Gerät unterstützt werden. Außerdem sollten Sie sich vergewissern, dass IPSec vom BIOS bzw. von der Software auf dem Gerät unterstützt wird.

• RAM-Kapazität. Diese Information kann nützlich sein, wenn Sie Ermittlungen zur Kapazität oder zur Auswirkung von IPSec auf das Gerät anstellen.

• Verkehrsanalyse. Diese Angaben (Hauptnutzungszeiten in Verbindung mit täglichen/wöchentlichen Trends, die die Nutzung des Geräts im Alltag zeigen) sind immer hilfreich. In Bezug auf IPSec helfen diese Informationen, ein Bild des Geräts und seiner Nutzung über einen bestimmten Zeitraum hinweg zu vermitteln. Sollten nach der Implementierung von IPSec Probleme auftreten, kann u. a. anhand dieser Daten bestimmt werden, ob die Ursache des Problems mit einer zu hohen Auslastung des Geräts zusammenhängt.

• ACLs mit einer direkten Auswirkung auf IPSec. ACLs haben eine direkte Auswirkung auf die Funktionsfähigkeit bestimmter Protokolle. Wenn beispielsweise das Kerberos-Protokoll (User Datagram Protocol [UDP] und TCP-Port 88) oder das IP-Protokoll (nicht Port, sondern Protokoll) 50 oder 51 nicht zugelassen werden, kann IPSec nicht funktionieren. Zudem müssen Geräte für die Weiterleitung von Verkehr mit Internetschlüsselaustausch (Internet Key Exchange, IKE) (UDP 500 und 4500) konfiguriert sein, wenn Netzwerkadressübersetzungs-Durchquerung (Network Address Translation Traversal, NAT-T) verwendet wird.

• An die Geräteschnittstelle(n) angeschlossene Netzwerke/Subnetze. Diese Informationen tragen dazu bei, sich das bestmögliche Bild davon zu verschaffen, wie das interne Netzwerk aussieht. Das Definieren der Netzwerkgrenze auf der Grundlage eines Adressbereichs ist unkompliziert und hilft zu erkennen, ob andere Adressen entweder nicht verwaltet oder netzwerkfremd (z. B. Internetadressen) sind. Diese Informationen werden für IPSec-Richtlinienentscheidungen benötigt, die in nachfolgenden Kapiteln dieses Leitfadens getroffen werden.

• Stattfinden der Netzwerkadressübersetzung (NAT). Netzwerkadressübersetzung wird im Allgemeinen dazu verwendet, einen ganzen Adressbereich einem verbundenen Netzwerk oder dem Internet als eine einzige IP-Adresse zu präsentieren. Die für die Planung der Lösung zuständige Person sollte wissen, ob dieser Prozess im Netzwerk stattfindet.

  Hinweis

  
  Der Microsoft Knowledge Base-Artikel 818043 L2TP/IPSec-NAT-T-Update für Windows XP und Windows 2000 unter https://support.microsoft.com/kb/818043 stellt NAT-T-Funktionalität als downloadbares Fix für Windows XP Service Pack (SP) 1 und Windows 2000 SP4 bereit. Allerdings funktioniert ein IPSec-Responder nur dann ordnungsgemäß, wenn Windows XP SP2 oder Windows Server 2003 SP1 installiert ist.

• VLAN-Segmentierung. Durch die Ermittlung der aktuellen Implementierungsweise von VLANs im Netzwerk können Sie besser verstehen, welche Verkehrsmuster oder Sicherheitsanforderungen zurzeit vorhanden sind, und leichter feststellen, wie IPSec diese Anforderungen erhöhen bzw. potenziell damit in Konflikt stehen wird.

• Netzwerkverbindungen des Geräts. Diese Informationen vermitteln einen Überblick darüber, welche Verbindungen das Gerät zwischen welchen Netzwerken aufrechterhält. Darüber hinaus lassen sich hiermit das logische Netzwerk und die Verbindungen zu verschiedenen Standorten an einer bestimmten Schnittstelle ermitteln.

• Größe der maximalen Übertragungseinheit (Maximum Transmission Unit, MTU) an der oder den Geräteschnittstelle(n). Der MTU-Wert legt den Umfang des größten Datenpakets fest, das an einer bestimmten Schnittstelle übertragen werden kann, ohne für die Übertragung in kleinere Teile zerlegt zu werden (dieser Prozess wird auch als "Fragmentierung" bezeichnet). Bei IPSec-Kommunikation wird die MTU benötigt, um die Bereiche zu ermitteln, in denen eine Fragmentierung stattfinden wird. Die Paketfragmentierung muss für das Protokoll ISAKMP (Internet Security Association and Key Management Protocol) vom Router verfolgt werden. IPSec legt die MTU-Größe für die Sitzung auf die kleinste MTU fest, die auf dem verwendeten Kommunikationspfad festgestellt wurde, und stellt das DF-Bit ("Don't Fragment") auf 1 ein.

  Hinweis

  
  Wenn die Ermittlung der Pfad-MTU (PMTU) aktiviert ist und ordnungsgemäß funktioniert, müssen Sie die MTU-Größen an den Gerätesschnittstellen nicht erfassen. Manche Quellen, z. B. der Windows Server 2003 Hardening Guide, empfehlen die Deaktivierung der PMTU-Ermittlung. IPSec kann jedoch nur bei aktivierter PMTU-Ermittlung ordnungsgemäß funktionieren.
  

Beachten Sie auch, dass es durch IPSec zu einer Beeinträchtigung von Intrusion Detection-Systemen (IDS) kommen kann, da zur Interpretation der Daten innerhalb von Paketen ein spezifischer Parser erforderlich ist. Wenn das IDS nicht über einen solchen Parser verfügt, kann es die Daten in diesen Paketen nicht überprüfen, um zu ermitteln, ob eine bestimmte Sitzung eine potenzielle Bedrohung darstellt. In diesem Fall bedeutet eine Entscheidung für IPSec, dass Ihre Organisation IPSec dringender benötigt als das IDS.

Die in diesem Abschnitt aufgeführten Informationen sind für den Erfolg des Projekts unerlässlich, da sie Ihnen helfen, die aktuelle Konfiguration und den Zustand der Netzwerkinfrastruktur zu verstehen, bevor diese Geräte für den Einsatz von IPSec konfiguriert werden (bzw. bevor sie zusätzlich belastet werden, wenn sie bereits zur Weiterleitung von IPSec-Verkehr konfiguriert sind). Durch eine genaue Untersuchung von Informationen zu Hauptnutzungszeiten können Sie ermitteln, ob das Gerät in seinem aktuellen Zustand zur Verwendung von IPSec fähig ist oder ob ein Arbeitsspeicher- oder Firmwareupgrade erforderlich ist, damit es die erwartete Last bewältigen kann. Die Angaben zu Fabrikat und Modell erweisen sich als nützlich, sollte Hardware zur Aktualisierung der Geräte erforderlich sein. Informationen zu anderen Konfigurationsparametern und speziellen Features des jeweiligen Fabrikats und Modells können ebenfalls hilfreich sein. Anhand der Anzahl der auf Geräten konfigurierten ACLs können Sie besser den Aufwand einschätzen, der zur Konfiguration der Geräte für eine Unterstützung von IPSec erforderlich sein wird. Wenn kein Gerät im Netzwerk für IPSec-Verkehr konfiguriert ist und das Netzwerk über eine hohe Anzahl von Routern verfügt, könnte die Gerätekonfiguration mit einem beträchtlichen Aufwand verbunden sein.

Nachdem Sie diese Informationen zusammengetragen haben, können Sie schnell bestimmen, ob es notwendig ist, die Geräte für die Anforderungen des Projekts zu aktualisieren, ACLs zu ändern oder andere Maßnahmen zu ergreifen, durch die sichergestellt wird, dass die Geräte die von ihnen erwarteten Lasten bewältigen können.

Analyse des aktuellen Netzwerkverkehrsmodells

Nachdem Sie die Informationen zu Adressierung und Netzwerkinfrastruktur zusammengetragen haben, besteht der nächste logische Schritt in der sorgfältigen Untersuchung des Kommunikationsflusses. Wenn sich beispielsweise eine Abteilung wie etwa die Personalabteilung über mehrere Gebäude erstreckt und Sie IPSec einsetzen möchten, um Daten in dieser Abteilung zu verschlüsseln, müssen Sie wissen, wie diese Gebäude miteinander verbunden sind, um die "Vertrauenswürdigkeit" einer solchen Verbindung ermitteln zu können. Ein durch starke Sicherheitsmaßnahmen geschütztes Gebäude, das über Kupferkabel mit einem nicht abgesicherten Gebäude verbunden ist, ist für einen Abhör- oder Replay-Angriff anfällig. Sollte eine Bedrohung durch einen derartigen Angriff bestehen, könnte IPSec durch die Bereitstellung starker gegenseitiger Authentifizierung und Verkehrsverschlüsselung die Sicherheit erhöhen. Jedoch kann die Lösung nicht verhindern, dass ein Mangel an physischer Sicherheit auf vertrauenswürdigen Hosts weiterhin ein Sicherheitsrisiko darstellt.

Achten Sie bei der Untersuchung des Verkehrsflusses genau darauf, wie verwaltete und nicht verwaltete Geräte interagieren. Dies gilt auch für Geräte, die nicht auf Windows, sondern auf Linux, UNIX oder Mac basieren, sowie für Vorgängerversionen von Windows 2000 SP4. Fragen Sie sich beispielsweise, ob bestimmte Kommunikationsverbindungen auf Port- oder Protokollebene stattfinden oder ob es viele Sitzungen zwischen denselben Hosts über zahlreiche unterschiedliche Protokolle gibt. Wie viele Server und Clients kommunizieren miteinander? Sind zurzeit irgendwelche Sicherheitsgeräte oder -projekte implementiert oder geplant, die Konsequenzen für das Isolierungsprojekt haben könnten? Wenn beispielsweise Windows XP SP2 und Windows Firewall verwendet werden, um bestimmte Ports wie UDP 500 zu sperren, würde dies zu einem Fehlschlag der IKE-Aushandlung führen.

Wenn Sie die verschiedenen Arten von Netzwerkverkehr mit dem in Kapitel 2 durchgeführten Verfahren zur Bedrohungsanalyse untersuchen, können Sie mühelos feststellen, welche Protokolle und Anwendungen Datenverkehr erzeugen, der von nicht vertrauenswürdigen oder nicht verwalteten Geräten ausgeht und abgesichert werden sollte. Dazu gehören u. a. die folgenden gängigen Anwendungen und Protokolle:

• NetBIOS über TCP/IP (NetBT) und SMB (Server Message Block). In einem LAN sind üblicherweise die Ports 137, 138 und 139 für NetBT und Port 445 für SMB aktiviert. Neben anderen Funktionen stellen diese Ports NetBIOS-Namensauflösungsdienste bereit. Leider bieten sie auch die Möglichkeit zum Aufbau so genannter Nullsitzungen. Eine Nullsitzung ist eine Sitzung, die auf einem Host aufgebaut wird und die nicht den Sicherheitskontext eines bekannten Benutzers oder einer bekannten Entität verwendet. Oft sind diese Sitzungen anonym.
• Remoteprozeduraufruf (RPC). Bei einem typischen RPC wird einer Anwendung ein Listener-Port (auch als die Endpunktzuordnung, TCP-Port 135, bezeichnet) verfügbar gemacht, der dann den "Anrufer" (oftmals eine andere Anwendung) auffordert, die Kommunikation auf einem anderen Port im kurzlebigen Bereich zu beginnen. In einem durch Firewalls segmentierten Netzwerk stellt diese RPC-Kommunikation ein Konfigurationsproblem dar, da hierfür der RPC-Listener-Ports und alle Ports über 1024 geöffnet werden müssen. Das Öffnen so vieler Ports vergrößert das Angriffsrisiko für das gesamte Netzwerk und reduziert die Effektivität der Firewalls. Jedoch besteht der Vorteil von RPC darin, dass es eine Abstraktion der Funktionalität in den Schichten 1 bis 4 des OSI-Modells (Open Systems Interconnection) für Anwendungen darstellt, die dieses verwenden. Daher müssen Entwickler für ihre verteilten Anwendungen keine Low-Level-Aufrufe an das Netzwerk bereitstellen. Da zahlreiche Anwendungen in ihrer grundlegenden Funktionalität von RPC abhängig sind, muss RPC in den IPSec-Richtlinien berücksichtigt werden. Weitere Informationen zur Erstellung von IPSec-Richtlinien finden Sie in Kapitel 5, "Erstellen von IPSec-Richtlinien für Isolierungsgruppen".
• Anderer Verkehr. IPSec kann zur Absicherung von Übertragungen zwischen Hosts beitragen, indem neben der Verschlüsselung von Paketdaten für eine Authentifizierung dieser Pakete gesorgt wird. Es ist wichtig zu identifizieren, was geschützt werden soll und welche Risiken vermindert werden müssen. Anderer Verkehr und andere Verkehrstypen, die abgesichert werden müssen, sollten untersucht und ein entsprechendes Modell dafür erstellt werden. Dazu könnte zum Beispiel eine besondere Datenbank gehören, auf die nur einige wenige Clients zugreifen dürfen, oder eine Spezialanwendung für die Personalabteilung, die nur von leitenden Mitarbeitern dieser Abteilung verwendet wird.

Nachdem das physische und das logische Netzwerk dokumentiert wurden, müssen im nächsten Schritt aktuelle Verkehrsmuster untersucht und folgende Fragen beantwortet werden:

• Verfügen Sie derzeit über Subnetze, die eigens für bestimmte Typen von Verkehr bestimmt sind (z. B. Mac- und UNIX-Arbeitsstationen oder Mainframe-zu-Terminal-Verbindungen)?
• Müssen Sie verschiedene Verkehrstypen oder den Verkehr zwischen Standorten trennen?

Active Directory

Nach dem Netzwerk ist Active Directory die zweitwichtigste Komponente, aus der Informationen erfasst werden müssen. Sie sollten die Gesamtstruktur einschließlich Domänenlayout, Architektur der Organisationseinheiten (Organization Units, OUs) und Standorttopologie verstehen. Aus diesen Informationen lässt sich dann ersehen, wo Computer aktuell stationiert sind, welche Konfiguration sie aufweisen und welche Auswirkungen die Änderungen an Active Directory als Folge der Implementierung von IPSec nach sich ziehen werden. In der folgenden Liste werden die Informationen aufgeführt, die für diesen Teil der Ermittlungsbemühungen erforderlich sind.

• Anzahl der Gesamtstrukturen. Da die Gesamtstruktur die Sicherheitsgrenze in einer Active Directory-Implementierung darstellt, ist es wichtig, die aktuelle Active Directory-Architektur zu verstehen, um bestimmen zu können, welche Hosts isoliert werden sollten und wie diese Isolierung erzielt werden kann.
• Namen und Anzahl der Domänen. IPSec-Authentifizierung findet als Folge des IKE-Aushandlungsprozesses statt. In dieser Lösung wird als Authentifizierungsmethode das Kerberos-Protokoll eingesetzt. Dieses Protokoll setzt voraus, dass Computer Mitglieder von Domänen sind und die Betriebssystemvoraussetzungen (Windows 2000, Windows XP oder Windows Server 2003) erfüllen.
• Anzahl und Typen der Vertrauensstellungen. Das Erfassen von Anzahl und Typen der Vertrauensstellungen ist wichtig, da die Vertrauensstellungen die logischen Grenzen der Isolierung beeinflussen und zudem bestimmen, wie IKE-Authentifizierung in der Lösung stattfinden kann (oder sollte).
• Namen und Anzahl der Standorte. Die Standortarchitektur ist in der Regel an der Netzwerktopologie ausgerichtet. Wenn Sie wissen, wie Standorte in Active Directory definiert sind, trägt dies zu einem Verständnis der Replikation und anderen Details bei. Für diese Lösung bietet die Standortarchitektur einen tiefer gehenden Einblick in die Active Directory-Implementierung in ihrer aktuellen Form.
• OU-Struktur. Durch eine gewisse Planung bei der Erstellung einer OU-Struktur lässt sich ein beachtliches Maß an operativer Effizienz gewinnen. OUs sind logische Konstrukte und können daher vielen verschiedenen Anforderungen und Zielen angepasst werden. Die OU-Struktur ist ideal geeignet, um die aktuelle Verwendungsweise von Gruppenrichtlinien und das Layout der OUs zu untersuchen. Die OU-Architektur wird in den Kapiteln 4 und 5 dieser Lösung erörtert. Dort finden Sie auch Einzelheiten dazu, wie diese Architektur zur Anwendung von IPSec-Richtlinien eingesetzt werden kann.
• Bereits vorhandene Verwendung von IPSec-Richtlinien. Da dieses Projekt mit der Implementierung von IPSec-Richtlinien enden wird, ist es von größter Bedeutung zu verstehen, wie Ihr Netzwerk derzeit IPSec verwendet (falls überhaupt). Unabhängig davon, ob Sie einfache IPSec-Filter (wie die in einer Anleitung zur Systemabsicherung beschriebenen) verwenden oder umfassende Richtlinien implementieren, wird durch einen genauen Überblick über Ihre aktuellen Nutzungsmuster und Anforderungen eine reibungslosere Integration mit dieser Lösung gewährleistet.

Im Woodgrove Bank-Szenario wird eine einzige Gesamtstruktur (corp.woodgrovebank.com) verwendet, die vier Domänen umfasst, die sich über fünf Standorte erstrecken. Jeder Standort kann einen Domänencontroller (DC), einen primären Domänencontroller (PDC) oder einen globalen Katalogserver (GC) beinhalten, wie in der folgenden Tabelle gezeigt wird:

Tabelle 3.1: Active Directory-Informationen der Woodgrove Bank

Physischer Standort	Domäne	Benutzer	Domänencontrollertyp
New York, NY	corp.woodgrovebank.com americas.corp.woodgrovebank.com	5.000	Globaler Katalog der Gesamtstruktur-Stammdomäne PDC Regionaler GC für "Americas" Regionaler DC für "Europe" Regionaler DC für "Asia"
Chicago, IL	americas.corp.woodgrovebank.com	750	Regionaler GC für "Americas"
Atlanta, GA	americas.corp.woodgrovebank.com	1.450	Regionaler GC für "Americas"
Boston, MA	americas.corp.woodgrovebank.com	480	Regionaler GC für "Americas"
San Francisco, CA	americas.corp.woodgrovebank.com	250	Regionaler GC für "Americas"
Pittsburgh, PA	americas.corp.woodgrovebank.com	50	Regionaler GC für "Americas"
Phoenix, AZ	americas.corp.woodgrovebank.com	50	Regionaler GC für "Americas"
Miami, FL	americas.corp.woodgrovebank.com	50	Regionaler GC für "Americas"
Washington, DC	americas.corp.woodgrovebank.com	75	Regionaler GC für "Americas"
Cambridge, MA	americas.corp.woodgrovebank.com	36	Regionaler GC für "Americas"
Toronto, Kanada	americas.corp.woodgrovebank.com	25	Regionaler GC für "Americas"
London, England	europe.corp.woodgrovebank.com corp.woodgrovebank.com	5.200	Gesamtstruktur-Stammdomänen-GC PDC-Emulator Regionaler GC für "Europe" Regionaler DC für "Americas" Regionaler DC für "Asia"
Genf, Schweiz	europe.corp.woodgrovebank.com	350	Regionaler GC für "Europe"
Amsterdam, Niederlande	europe.corp.woodgrovebank.com	295	Regionaler GC für "Europe"
München, Deutschland	europe.corp.woodgrovebank.com	149	Regionaler GC für "Europe"
Rom, Italien	europe.corp.woodgrovebank.com	80	Regionaler GC für "Europe"
Dublin, Irland	europe.corp.woodgrovebank.com	79	Regionaler GC für "Europe"
Edinburgh, Schottland	europe.corp.woodgrovebank.com	40	Regionaler GC für "Europe"
Johannesburg, Südafrika	europe.corp.woodgrovebank.com	37	Regionaler GC für "Europe"
Tokio, Japan	asia.corp.woodgrovebank.com corp.woodgrovebank.com	500	Gesamtstruktur-Stammdomänen-GC PDC-Emulator Regionaler GC für "Asia" Regionaler DC für "Europe" Regionaler DC für "Americas"
Hongkong, China	asia.corp.woodgrovebank.com	100	Regionaler GC für "Asia"
Bangkok, Thailand	asia.corp.woodgrovebank.com	150	Regionaler GC für "Asia"
Singapur	asia.corp.woodgrovebank.com	210	Regionaler GC für "Asia"
Sydney, Australien	asia.corp.woodgrovebank.com	45	Regionaler GC für "Asia"
Bangalore, Indien	asia.corp.woodgrovebank.com	35	Regionaler GC für "Asia"
Taipei, Taiwan	asia.corp.woodgrovebank.com	65	Regionaler GC für "Asia"

Das Active Directory-Design der Woodgrove Bank verwendet beiderseitige Vertrauensstellungen, die automatisch durch die Gesamtstruktur erstellt werden. Es bestehen keine zusätzlichen domänenübergreifenden oder externen Vertrauensstellungen.

Die folgende Abbildung zeigt ein Beispiel für eine Gesamtübersicht der von der Woodgrove Bank verwendeten OU-Struktur. Diese Struktur wurde in einheitlicher Weise für die regionalen Domänen Americas, Europe und Asia eingesetzt.

Abbildung 3.2: Beispiel für die OU-Struktur der Woodgrove Bank

Bild in voller Größe anzeigen

Da es sich bei dem Projekt zur Server- und Domänenisolierung um die erste IPSec-Implementierung der Woodgrove Bank handelte, waren noch keine IPSec-Richtlinien etabliert.

Hostermittlung

Der größte Vorteil eines Projekts zur Ressourcenermittlung ist die beachtliche Menge an Daten, die über die Hosts (Arbeitsstationen und Server) im Netzwerk empfangen werden. In Kapitel 4, "Entwerfen und Planen von Isolierungsgruppen", werden Entscheidungen gefällt, die genaue Informationen über den Zustand aller Hosts voraussetzen, um sicherzustellen, dass sie zur Teilnahme an der IPSec-Kommunikation des Entwurfs fähig sind.

Erforderliche Hostdaten

In diesem Abschnitt werden die benötigten Hostinformationen beschrieben, und es wird erörtert, wie diese Informationen physisch und logisch dargestellt werden können.

• Computername. Hierbei handelt es sich um den NetBIOS- oder DNS-Namen des Computers, durch den er im Netzwerk identifiziert wird. Da ein Computer über mehrere MAC-Adressen (Media Access Control) und/oder IP-Adressen verfügen kann, ist der Computername eines der Kriterien, um die Eindeutigkeit im Netzwerk zu bestimmen. Unter bestimmten Umständen kann ein Computername doppelt vorhanden sein, daher sollte die Eindeutigkeit nicht als absolut angesehen werden.

• IP-Adresse(n) für die einzelnen Netzwerkkarten (NICs). Die IP-Adresse ist die Adresse, die mit der Subnetzmaske verwendet wird, um einen Host im Netzwerk zu identifizieren. Es sollte beachtet werden, dass eine IP-Adresse keine verlässliche Methode zur Identifizierung einer Ressource darstellt, da sie oftmals Änderungen unterliegt.

• MAC-Adresse für die einzelnen NICs. Die MAC-Adresse ist eine eindeutige 48-Bit-Adresse, die zur Identifizierung einer Netzwerkschnittstelle dient. Mit ihrer Hilfe können verschiedene Netzwerkschnittstellen auf demselben Gerät leichter unterschieden werden.

• Betriebssystem, Service Pack und Hotfixversionen. Die Betriebssystemversion ist einer der Hauptfaktoren um zu bestimmen, ob ein Host für die Kommunikation mit IPSec geeignet ist. Darüber hinaus sollte unbedingt auch der aktuelle Status von eventuell installierten Service Packs und Hotfixes berücksichtigt werden, da anhand dieser oftmals festgestellt werden kann, ob die Mindestsicherheitsstandards erfüllt sind.

• Domänenmitgliedschaft. Anhand dieser Informationen kann ermittelt werden, ob ein Computer IPSec-Richtlinien aus Active Directory abrufen kann oder ob er lokale IPSec-Richtlinien verwenden muss.

• Physischer Standort. Hierbei handelt es sich einfach um Angaben zum Standort des Geräts innerhalb Ihrer Organisation. Diese Informationen können verwendet werden, um basierend auf dem Gerätestandort bzw. den Standorten der Geräte, mit denen es regelmäßig kommuniziert, zu bestimmen, ob das Gerät in eine bestimmte Isolierungsgruppe aufgenommen werden soll.

• Hardwaretyp/-rolle. Es ist unter Umständen nicht möglich, diese Informationen mithilfe eines automatisierten Prozesses zu erfassen. Manche Tools, die Hostermittlung durchführen, können diese Informationen bereitstellen, indem sie die Hardwareinformationen abfragen und Anwendungen ausführen, um den jeweiligen Typ (z. B. Server, Arbeitsstation oder Tablet PC) zu ermitteln. Anhand dieser Informationen könnten Sie bestimmen, ob sich der PC zur Teilnahme an der Isolierung eignet und in welche Isolierungsgruppe er aufgenommen werden soll.

  Hinweis

  
  Die Informationen zum Hardwaretyp werden durch Dateninterpolation oder durch ein Softwareprodukt, das Abfragen hinsichtlich dieser Daten durchführt, ermittelt. Beispielsweise ist allgemein bekannt, dass es sich bei einem HP Evo n800 um einen mobilen Computer handelt. Wenn Sie eine Abfrage auf Handwareebene durchführen können (bzw. wenn ein Ressourcenkennzeichen vorhanden ist, das ihn als solchen identifiziert), können sie leichter die entsprechenden IPSec-Richtlinien bestimmen, die dem Gerät zugewiesen werden sollen.
  

Nachdem Sie alle diese Informationen erfasst und in einer Datenbank konsolidiert haben, sollten Sie regelmäßig neue Ermittlungen anstellen, um die Informationen aktuell zu halten. Sie benötigen ein absolut genaues und aktuelles Bild der verwalteten Hosts in Ihrem Netzwerk, um einen Entwurf erarbeiten zu können, der den Anforderungen Ihrer Organisation gerecht wird.

Zur Erfassung von Daten aus den Hosts im Netzwerk können verschiedene Methoden verwendet werden. Diese Methoden reichen vom Einsatz voll automatisierter High-End-Systeme bis zur vollständig manuell durchgeführten Datenerfassung. In der Regel ist die Verwendung automatisierter Datenerfassungsmethoden aufgrund ihrer Geschwindigkeit und Genauigkeit manuellen Methoden vorzuziehen. Allerdings sind die benötigten Daten dieselben, gleichgültig, welche Methode verwendet wird; der einzige Unterschied liegt in dem zum Zusammentragen der Daten investierten Zeitaufwand. Manuelle Prozesse bringen eine Reihe typischer Probleme mit sich; u. a. könnten Informationen doppelt vorhanden sein, es muss sichergestellt werden, dass die Bemühungen im richtigen Umfang durchgeführt wurden (z. B. ob alle Netzwerke durchsucht und die entsprechenden Informationen daraus erfasst wurden oder nur die Client-Subnetze), und es kann sich als schwierig erweisen, alle Informationen rechtzeitig zusammenzutragen, um für das Projekt nützlich zu sein. Eine Betrachtung aller Elemente für die vollständige Bestandsprüfung eines IT-Systems würde über den Rahmen dieses Projekts hinausgehen. Es ist jedoch wichtig zu verstehen, dass diese Prüfungsinformationen der Organisation nicht nur für diese Lösung, sondern auch aus zahlreichen anderen Gründen zur Verfügung stehen sollten. Ressourcenverfolgung und die Verwaltung von Sicherheitsrisiken stellen lediglich zwei wichtige Beispiele für Prozesse dar, für die eine aktuelle und genaue Systembestandsaufnahme erforderlich ist.

Automatische Ermittlung

Durch Einsatz eines automatisierten Netzwerkverwaltungssystems zur Überwachung und Überprüfung werden viele wertvolle Daten zum aktuellen Status der IT-Infrastruktur bereitgestellt. Ein Problem bei automatisierten Systemen besteht allerdings darin, dass Hosts, die offline, nicht angeschlossen oder anderweitig physisch (oder logisch) nicht in der Lage sind, auf Abfragen zu reagieren, nicht in der endgültigen Datenbank aufgeführt werden. Selbst bei hoch automatisierten Systemen ist ein bestimmter manueller Verwaltungsaufwand erforderlich, um sicherzustellen, dass auf die Hosts zugegriffen werden kann und dass sie entsprechend berücksichtigt werden.

Es sind zahlreiche Produkte und Tools von verschiedenen Herstellern verfügbar. Manche Methoden verwenden einen zentralen Scanmechanismus, während andere auf den Clientcomputern installierte Agenten einsetzen. In diesem Leitfaden sollen keine Produktvergleiche oder -empfehlungen bereitgestellt werden; es sei lediglich gesagt, dass die in diesem Kapitel beschriebenen Ermittlungsdaten für die in den Kapiteln 4 und 5 angestellten Überlegungen vorliegen müssen.

Weitere Informationen dazu, wie SMS 2003 Sie bei der Ressourcenverwaltung (oder bei der Erfassung der für dieses Projekt erforderlichen Daten) unterstützen kann, finden Sie in der Demonstration und dem Datenblatt zur Ressourcenverwaltung auf der Seite SMS 2003 Asset Management unter www.microsoft.com/smserver/evaluation/capabilities/asset.asp.

Manuelle Ermittlung

Der größte Unterschied zwischen manuellen und automatischen Ermittlungsmethoden liegt im Zeitaufwand. Um die für dieses Projekt erforderlichen Daten zusammenzutragen, könnten Dutzende von Personen mehrere Tage oder Wochen beschäftigt sein, bei einem großen Unternehmen unter Umständen noch länger. Falls Sie planen, eine manuelle Methode zur Überprüfung des aktuellen Status Ihrer Infrastruktur einzusetzen, müssen die erfassten Informationen unbedingt in einem elektronischen Format vorliegen, z. B. in einer Kalkulationstabelle oder einer Datenbank. Das reine Volumen von Daten, die potenziell generiert werden können, kann den Analyse- und Filterprozess sehr erschweren, wenn Sie nicht schnell konkrete Abfragen definieren können, die die benötigten Informationen zurückgeben. Darüber hinaus können Sie lokale IT-Administratoren dazu einsetzen, die Informationen zu beschaffen bzw. die Gültigkeit zuvor erfasster Informationen zu bestätigen.

Auch wenn Ihre Organisation kein Tool zur automatisierten Bestandsprüfung besitzt, lässt sich eine bestimmte Automatisierung erreichen, indem Sie die standardmäßigen Remoteverwaltungs- und Skripterstellungstools einsetzen, die auf der Windows-Plattform verfügbar sind. Bei diesen Tools muss besonders darauf geachtet werden, dass keine Clients übersehen werden, nur weil sie nicht mit dem Verwaltungstool oder dem Skript kompatibel sind.

Sie können Windows Scripting Host (WSH), Microsoft Visual Basic® Scripting Edition (VBScript) und Windows Management Instrumentation (WMI) verwenden, um eine Skriptdatei zu erstellen, die Informationen zur Systemkonfiguration erfassen kann. In der folgenden Tabelle wird die Verfügbarkeit von VBScript und WMI nach Plattform angegeben.

Tabelle 3.2: Verfügbarkeit von VBScript und WMI nach Plattform

Plattform	VBScript	WMI
Windows 95	WSH 5.6 installieren	WMI CORE 1.5 installieren
Windows 98	Integriert	WMI CORE 1.5 installieren
Windows Millennium	Integriert	Integriert
Microsoft Windows NT® Version 4.0	WSH 5.6 installieren	WMI CORE 1.5 installieren
Windows 2000	Integriert	Integriert
Windows XP	Integriert	Integriert
Windows Server 2003	Integriert	Integriert

Ein Beispiel für VBScript mit dem Namen Discovery.vbs ist im Ordner "Tools and Templates" für diesen Leitfaden verfügbar. Dieses Skript verwendet WMI, um alle Informationen abzurufen, die im Abschnitt "Erforderliche Hostdaten" dieses Kapitels aufgeführt werden, mit Ausnahme der Rolle und des physischen Standorts. Diese Informationen werden in der Datei C:\Discovery\<Systemname>_info.txt auf dem lokalen Computer aufgezeichnet. Sie haben die Möglichkeit, das Skript so zu modifizieren, dass zusätzliche Daten erfasst oder die erfassten Informationen in einer Remotedateifreigabe gespeichert werden.

Wenn WMI oder VBScript nicht verfügbar sind, können Sie bestimmte Informationen mithilfe eines Batchskripts und externer Tools erfassen. Die Schwierigkeit hierbei besteht darin, dass die Batchsprache über eine extrem eingeschränkte Funktionalität verfügt und dass Konfigurationsinformationen in älteren Versionen von Windows nicht problemlos über die Befehlszeile abgerufen werden können.

Zur Durchführung einer Hostermittlung müssen Hosts abgefragt und ein Ort bereitgestellt werden, an dem die Ergebnisse dieser Abfragen gespeichert werden.

Gleichgültig, ob Sie eine automatisierte, manuelle oder gemischte Methode zur Erfassung der Informationen einsetzen, besteht eines der größten Probleme, das dem Erfolg des Entwurfs im Wege stehen kann, darin, die Änderungen zwischen der ursprünglichen Bestandsprüfung und dem Zeitpunkt zu erfassen, an dem mit der Implementierung begonnen werden kann. Nachdem eine erste Prüfung stattgefunden hat, sollten Sie Supportmitarbeiter darauf aufmerksam machen, dass jegliche weiteren Änderungen aufgezeichnet und eventuelle Updates in das Bestandsprotokoll aufgenommen werden müssen.

Dieses Bestandsprotokoll ist für die Planung und Implementierung von IPSec-Richtlinien, die in nachfolgenden Kapiteln erörtert werden, von wesentlicher Bedeutung.

Zum Seitenanfang

Überlegungen zur Kapazität

Nachdem Sie alle Informationen zusammengetragen haben, sollten Sie sich als Nächstes mit den Auswirkungen von IPSec (sowie einer gewissen Kapazitätsplanung) beschäftigen. In diesem Abschnitt werden einige grundlegende Aspekte der ordnungsgemäßen Planung für IPSec in Ihrer Umgebung beschrieben.

Auswirkungen von IPSec

Da IPSec verschiedene Verschlüsselungsmethoden einsetzt, kann dies auf einem Computer beträchtliche Ressourcen erfordern. Szenarien, in denen eine Verschlüsselung erforderlich ist, müssen genauer untersucht werden. So könnten etwa 3DES (Triple Data Encryption Standard) und SHA-1 (Secure Hash Algorithm) dazu eingesetzt werden, die Integrität in Situationen zu prüfen, in denen der stärkste verfügbare Schutz durch Verschlüsselung und Schlüsselaustausch erforderlich ist. In einem anderen Szenario wird die Aushandlung der Sicherheitszuordnung (Security Association, SA) verwendet. Sie könnten für die Hauptmodus-SA eine kürzere Gültigkeitsdauer verwenden, z. B. drei Stunden, doch sollten Sie wie bei vielen Sicherheitsfragen auch hier davon ausgehen, dass Sie Kompromisse schließen müssen. Jede Hauptmodus-SA belegt etwa 5 KB RAM. In einer Situation, in der von einem Server erwartet wird, dass er Zehntausende gleichzeitiger Verbindungen aushandelt, könnte dies zu einer übermäßigen Auslastung führen. Zu weiteren Faktoren zählen die CPU-Auslastung auf Netzwerkinfrastrukturservern, erhöhte Ressourcennutzung auf Servern und Arbeitsstationen, auf denen IPSec ausgeführt wird (insbesondere auf Servern, da diese in den meisten Fällen mehr Hauptmodus-SAs enthalten) und erhöhte Netzwerkwartezeiten als Folge der IPSec-Aushandlung.

Auch muss unbedingt die Problematik von Netzwerken beachtet werden, die unter Verwendung eines zwischengeschalteten NAT-Geräts verbunden sind. Das Problem besteht darin, dass NAT keine AH-Konversationen (Authentication Header) zwischen Hosts ermöglicht, da NAT genau das Prinzip verletzt, auf dessen Basis AH konzipiert ist: die Authentifizierung eines unveränderten Pakets, einschließlich des Headers. Sollten im internen Netzwerke NAT-Geräte vorhanden sein, muss ESP anstelle von AH gewählt werden. ESP kann verschlüsselte Daten verarbeiten, erfordert aber keine Verschlüsselung. Dieser Faktor ist von einem Kapazitätsstandpunkt aus gesehen wichtig, da Verschlüsselung mit einem Ressourcenaufwand verbunden ist, der in den Planungs- und Entwicklungsphasen eines Projekts mit berücksichtigt werden muss. ESP kann auch mit Nullverschlüsselung bereitgestellt werden, wodurch die stärkste Peer-to-Peer-Kommunikation bereitgestellt wird, die möglich ist, ohne dass die Kommunikation mit NAT unterbrochen wird. Und da hierbei keine Verschlüsselung verwendet wird, hat dies eine geringere Auswirkung als ESP mit Verschlüsselung.

Auswirkungen von Richtlinien

Sowohl IPSec-Richtlinien als auch Gruppenrichtlinien beeinflussen die zum Hochfahren von Computern und zur Anmeldung von Benutzern erforderliche Zeit. Während der Phase der Informationserfassung sollten Sie die Computerstartzeiten und Anmeldezeiten von Benutzern vor der Implementierung der Lösung festhalten. Diese festgehaltenen Zeiten dienen als Basisrichtlinie, mit der Sie die Testsysteme in der Testphase vergleichen können, um festzustellen, inwiefern die Gesamtdauer für die Systemanmeldung für einen Benutzer beeinträchtigt wird.

Zum Seitenanfang

Überlegungen vor der Bereitstellung

In den vorangegangenen Abschnitten wurde beschrieben, welche Informationen Sie aus Active Directory, dem Netzwerk und den Hosts erfassen sollten, um zum Erfolg des Isolierungsprojekts beizutragen. In diesem Abschnitt werden problematische Bereiche angesprochen, die Sie vor der Bereitstellung von IPSec genau untersuchen sollten.

Netzwerkinfrastruktur

Die Erfassung von Informationen ermöglicht es Ihnen, die IPSec-Isolierung in einem Netzwerk zu planen. Im Anschluss an das Zusammentragen dieser Daten lassen sich durch eine sorgfältige Analyse dieser Daten die meisten Probleme erkennen, die in der Testphase und bei der Bereitstellung auftreten können. Obgleich die folgenden Aspekte keine umfassende Liste bilden, sollten sie unbedingt erwogen werden, wenn Sie vor dem Testen und Bereitstellen der Lösung mit der Analyse der Informationen beginnen.

Überlastete Geräte

Eventuell müssen Sie Switches oder Router aktualisieren oder umkonfigurieren, die zum jeweiligen Zeitpunkt eine 75-prozentige Auslastung überschreiten, um für einen erhöhten Verkehr auf dem Gerät vorzusorgen und gleichzeitig Kapazität für zusätzliche Auslastung bei Verkehrsspitzen zu schaffen. Bei einer ordnungsgemäßen Kapazitätsplanung für eine Implementierung von IPSec geht es mehr um Tests und Vorhersagen für Verkehrslasten als um exakte Berechnungen. Da es höchst unwahrscheinlich ist, dass für zwei Kunden genau dieselben Szenarien, Verkehrsmuster, Benutzerkonzentrationen und Anwendungen vorliegen, sind eine ordnungsgemäße Planung und Überlegungen zu den jeweiligen Auswirkungen auf Netzwerkgeräte unabdinglich. So sind bestimmte Aspekte von IPSec beispielsweise absolut vorhersehbar. Jedes Paket, das IPSec mit ESP verwendet, ist genau 36 Byte größer als ein identisches Paket, das kein IPSec verwendet. Da sechs Nachrichten erforderlich sind, um eine einzige Hauptmodus-SA herzustellen, ist es leichter einzuschätzen, wie die Auslastung auf einem bestimmten Gerät betroffen sein könnte. Sie können Tools wie PROVISO von Quallaby unter www.quallaby.com oder andere Netzwerkanalyselösungen einsetzen, um sich die Kapazitätsplanung für IPSec in Ihrer IT-Umgebung zu erleichtern.

Nicht kompatible Geräte

Geräte, die mit IPSec nicht kompatibel sind, können an der IPSec-Kommunikation nicht teilnehmen. Falls solche Geräte mit einem verwalteten Gerät eine Verbindung herstellen müssen, sollten Sie sie in die IPSec-Ausnahmeliste aufnehmen. Eine Alternative besteht darin, die Hardware oder Software des Geräts für die Unterstützung von IPSec zu aktualisieren. Oder es könnte diesen nicht verwalteten Geräten die Kommunikation mit Computern in der Grenzgruppe erlaubt werden, wenn sie für ihre ausgehende Kommunikation auf unsichere Verbindungen zurückgreifen.

Nicht ordnungsgemäß konfigurierte Geräte

Geräte, die nicht ordnungsgemäß konfiguriert sind, können die Wahrscheinlichkeit fehlgeschlagener Verbindungen und verstärkter Auslastung des Geräts erhöhen und sogar die Sicherheit von Geräten in Frage stellen. Durch Befolgen bewährter Vorgehensweisen für die Konfiguration, Administration und Sicherheit auf den Geräten lässt sich dieses Problem weitgehend vermeiden.

IP-Adressierung

Da IP-Adressen das Fundament einer IPSec-Lösung bilden, ist es wichtig, dass die Adressierung so "sauber" wie möglich erfolgt. Überlappende Adressbereiche, doppelt vorhandene Adressen, inkorrekte Subnetzmasken und andere Probleme können den normalen Netzwerkbetrieb komplizieren. Das Hinzufügen von IPSec zu einem solchen Netzwerk erschwert die Problembehandlung nur noch und kann bewirken, dass diese Probleme IPSec zugeschrieben werden. Unternehmenswachstum, -zusammenschlüsse und -zukäufe und andere Faktoren können schnell zu einem veralteten und ungenauen Bild der IP-Adressierung in einem Netzwerk führen. Um die größten Probleme mit IPSec zu vermeiden, stellen Sie sicher, dass das Netzwerk in nicht überlappende Subnetze eingeteilt ist, dass die Routertabellen schön übersichtlich sind und dass Adressengruppierungen einfach zu erkennen sind.

Active Directory-Informationen

Wenn die aktuelle Active Directory-Implementierung reibungslos funktioniert (d. h. Namensauflösung, DHCP [Dynamic Host Configuration Protocol], Zuweisung von Gruppenrichtlinien, Vertrauensstellungen usw.), sollte IPSec durch nichts beeinträchtigt werden. Sie sollten alle Änderungen genau untersuchen, die zwischen der Prüfung von Active Directory und dem Startzeitpunkt des Isolierungsprojekts vorgenommen wurden, um sicherzustellen, dass keine Kompatibilitätsprobleme auftreten werden.

Hostinformationen

Anhand der vorangegangenen Abschnitte konnten Sie ausreichende Informationen über die Hosts in Ihrem Netzwerk zusammentragen. Nachdem Sie ermittelt haben, welche Clients und Server zur Verwendung von IPSec fähig sind, beachten Sie, wie diese isoliert werden müssen und welche Anwendungen auf die potenziellen Auswirkungen der Isolierungslösung hin genau untersucht werden sollten.

Bestimmen der Teilnahme von Clients und Servern

Nachdem Sie Informationen zu den Hosts eingeholt haben, ist es relativ einfach zu bestimmen, welche Hosts für eine Integration in die Isolierungslösung in Frage kommen. So können beispielsweise nur Computer unter Windows 2000, Windows Server 2003, und Windows XP mit IPSec kommunizieren. Allerdings sollten eventuell nicht alle Hosts, die teilnehmen können, dies auch tun. Ein wichtiger Bestandteil des Entwurfsprozesses besteht darin, anhand der in diesem Kapitel erfassten Informationen zu bestimmen, welche Computer und Geräte in die Lösung aufgenommen werden und in welcher Gruppe sie sich befinden sollen.

Ermitteln von zu isolierenden Diensten

Im Kontext eines Server- und Domänenisolierungsprojekts handelt es sich bei einem Dienst um eine Anwendung, wie z. B. Microsoft Exchange Server, Microsoft SQL Server oder Internet Information Services (IIS), die Clients im Netzwerk ihre Dienste bereitstellt. Sie sollten diese Dienste einzeln beurteilen, um zu bestimmen, ob sie als Kandidaten für Server- und Domänenisolierung in Frage kommen. Es kann eine Reihe von Gründen geben, warum diese Dienste unter Umständen in die Lösung einbezogen werden müssen, beispielsweise Unternehmensrichtlinien, gesetzliche Bestimmungen oder andere geschäftliche Anforderungen So könnte es etwa eine Unternehmensrichtlinie geben, die bestimmt, dass jegliche Kommunikation zwischen Mailservern durch IPSec gesichert werden muss, dass aber Verbindungen zwischen Clients und Servern nicht auf diese Weise abgesichert werden müssen. In Kapitel 4, "Entwerfen und Planen von Isolierungsgruppen", wird der Isolierungsprozess im Detail besprochen. Stellen Sie bei dem Versuch, Dienste zu isolieren, sorgfältige Überlegungen für Server an, auf denen mehrere Dienste ausgeführt werden, z. B. für einen Dateiserver, der Webdienste und FTP (File Transfer Protocol) bereitstellt und gleichzeitig als Mailserver dient.

Netzwerklastenausgleich und Clusterfunktionen

Organisationen, die Server- und Domänenisolierung einsetzen, können unter Umständen beschließen, Computer, die Netzwerklastenausgleich (Network Load Balancing, NLB) und Clusterfunktionen verwenden, davon auszunehmen. IPSec ist mit NLB im "no affinity"-Modus nicht kompatibel, da IPSec Computer daran hindert, dieselbe Clientverbindung zu verwenden. Aufgrund dieser Inkompatibilität sollten Sie nicht versuchen, NLB im "no affinity"-Modus mit IPSec zu verwenden.

Verwalten von Ausnahmen

Das Verwalten von Ausnahmen spielt bei der IPSec-Planung eine bedeutende Rolle. Das Bestimmen, wo Computer eingesetzt werden sollen, die einen Zugriff von nicht vertrauenswürdigen Hosts zulassen, und das Steuern des Zugriffs zwischen verwalteten und nicht verwalteten Computern sind ein wesentlicher Bestandteil der Isolierung. Als bewährte Vorgehensweise gilt, dass die Anzahl von Ausnahmen so gering wie möglich gehalten werden sollte. Technische Anforderungen machen es gegebenenfalls erforderlich, dass bestimmte Computer oder Dienste von IPSec ausgenommen werden müssen, z. B. Domänencontroller sowie DHCP-, DNS- und WINS-Server. Da davon ausgegangen werden kann, dass diese Computer in der Regel dennoch verwaltet werden, ist das potenzielle Risiko geringer, als wenn nicht verwalteten Computern die Kommunikation mit verwalteten vertrauenswürdigen Hosts erlaubt wird.

Nicht-Windows-basierte Geräte

Die meisten Unternehmensnetzwerke sind nicht homogen. Bei der Planung einer IPSec-Implementierung müssen Sie die Vielfalt von Elementen wie Betriebssystemen, Netzwerkinfrastruktur und Hardwareplattformen berücksichtigen. Falls in Ihrer Organisation nicht-Windows-basierte Geräte vorhanden sind, sollten Sie sich darüber im Klaren sein, dass eine Durchsetzung von IPSec-Richtlinien außerhalb des Windows-Bereichs vorerst nicht möglich ist. Eine Organisation könnte versuchen, diese Einschränkung zu umgehen, indem sie beschließt, bestimmte Plattformen als vertrauenswürdig anzusehen; da die IPSec-Richtlinien auf diesen Plattformen jedoch nicht durchgesetzt werden können, sind sie nicht durch die Server- und Domänenisolierungslösung geschützt. Im folgenden Abschnitt wird besprochen, wie die Vertrauensstellung bestimmt werden kann.

Verwaltungs- und Überwachungsgeräte

Ein Aspekt von IPSec, der oft bei der anfänglichen Planung übersehen wird, ist seine Auswirkung auf die Verwaltung und Überwachung des Verkehrs im Netzwerk. Da IPSec Authentifizierung verlangt und eine Verschlüsselung zulassen kann, können manche Geräte für IPSec aktivierte Computer nicht mehr überwachen oder verwalten. In Fällen, in denen eine Verschlüsselung erfordert wird, hat sich die Organisation entschlossen, dass Sicherheit wichtiger ist als die betriebliche Notwendigkeit, die Daten bei ihrer Durchquerung des Netzwerks zu überwachen. In anderen Fällen muss beurteilt werden, welche Änderungen an einer Anwendung oder einem Gerät vorgenommen werden können, um eine IPSec-Überwachung zu ermöglichen (z. B. ein ESP-Parser, der ESP-Verkehr analysieren kann). Sollte es nicht möglich sein, Überwachungs- oder Verwaltungsgeräte für eine Unterstützung von IPSec zu aktualisieren, müssen Sie diese Tatsache unbedingt festhalten. Diese Information wird vom Lösungsarchitekten bzw. dem Architekturteam in Kapitel 4, "Entwerfen und Planen von Isolierungsgruppen", benötigt.

Zum Seitenanfang

Bestimmung der Vertrauensstellung

Nachdem Sie Informationen zu den Hostgeräten zusammengetragen haben, die zurzeit Bestandteil Ihrer Netzwerkinfrastruktur sind, müssen Sie eine grundlegende Entscheidung treffen, die sich direkt auf die Fähigkeit eines Hosts zur Teilnahme an der Lösung auswirkt. Hierbei handelt es sich um die Entscheidung, bis zu welchem Punkt ein Host als vertrauenswürdig angesehen werden kann. Der Begriff vertrauenswürdig kann für verschiedene Personen unterschiedliche Bedeutungen haben, daher ist es wichtig, allen Projektbeteiligten eine klare Definition zu vermitteln. Anderenfalls kann dies zu Problemen mit der Sicherheit in der vertrauenswürdigen Umgebung führen, da die Gesamtsicherheit immer nur so hoch sein kann, wie die Sicherheit des am wenigsten sicheren Clients, dem ein vertrauenswürdiger Status gewährt wurde.

Um dieses Konzept erfassen zu können, führen Sie sich die vier grundlegenden Statuseinstufungen vor Augen, die Hosts in einer typischen Infrastruktur zugewiesen werden können. Dabei handelt es sich um folgende (in der Reihenfolge des Risikos, geringstes Risiko zuerst):

1. Vertrauenswürdig
2. Potenziell vertrauenswürdig
3. Bekannt, nicht vertrauenswürdig
4. Unbekannt, nicht vertrauenswürdig

Im restlichen Teil dieses Abschnitts werden diese Statuseinstufungen definiert, und es wird beschrieben, wie Sie bestimmen können, welchen Hosts in Ihrer Organisation welcher Status zugewiesen werden sollte.

Status "Vertrauenswürdig"

Wenn ein Host als vertrauenswürdig eingestuft wird, heißt das nicht, dass dieser Host absolut sicher oder angriffsgeschützt ist. Im Grunde genommen sagt "vertrauenswürdig" aus, dass die Sicherheitsrisiken dieses Hosts verwaltet werden. Die Verantwortung für diesen verwalteten Zustand fällt den IT-Administratoren und den Benutzern zu, die für die Konfiguration des Hosts zuständig sind. Ein vertrauenswürdiger Host, der schlecht verwaltet ist, kann leicht zu einer Sicherheitsschwachstelle für die gesamte Lösung werden.

Wenn ein Host als vertrauenswürdig angesehen wird, sollten andere vertrauenswürdige Hosts davon ausgehen können, dass von diesem Host kein bösartiger Angriff ausgehen wird. Beispielsweise sollten vertrauenswürdige Hosts erwarten können, dass andere vertrauenswürdige Hosts keinen Virus ausführen, der sie angreift, da alle vertrauenswürdigen Hosts Sicherheitsmaßnahmen (wie z. B. Antivirusprogramme) verwenden müssen, um eine Bedrohung durch Viren zu verringern.

Die Kommunikation zwischen vertrauenswürdigen Hosts sollte nicht durch die Netzwerkinfrastruktur behindert werden. Da ein vertrauenswürdiger Host beispielsweise davon ausgehen kann, dass andere vertrauenswürdigen Hosts keine böswilligen Absichten haben, ist eine Blockierung von Paketen auf IP-Ebene zur Einschränkung des Zugriffs durch andere vertrauenswürdige Hosts in der Regel nicht erforderlich. Jegliche Einschränkungen, die notwendig sind, um die Hostkommunikation nach Port oder nach Protokoll zu steuern, sollten über eine hostbasierte Firewall auf dem Computer selbst und nicht durch IPSec implementiert werden.

Im Woodgrove Bank-Szenario wurden die folgenden fünf Hauptziele definiert, anhand derer geplant wurde, welche Technologien ein Host aufweisen sollte, damit dieser als vertrauenswürdig eingestuft werden kann:

• Die Sicherheit der Identität des Computers oder des Benutzers ist nicht in Frage gestellt.
• Die erforderlichen Ressourcen sind sicher und verfügbar, unabhängig davon, wo in der verwalteten Umgebung sie sich befinden.
  • Eine als sicher bezeichnete Ressource kann nicht manipuliert werden, ist virenfrei und vor unberechtigten Zugriffen geschützt.
  • Eine Ressource, die als verfügbar bezeichnet wird, ist für den zugesagten Zeitumfang oder darüber hinaus betriebsfähig und weist keine Sicherheitsschwachstellen auf.
  • Eine als verwaltet bezeichnete Umgebung verfügt über Computer, die unter Windows 2000 SP4 oder höher ausgeführt werden und die ordnungsgemäß konfiguriert und mit entsprechenden Patches versehen sind.
• Daten und Kommunikationsverbindungen sind geschützt, d. h. Informationen werden nur von den beabsichtigten Empfängern gelesen und genutzt.
• Der Verantwortliche für das Gerät bzw. sein Bediener versteht alle Richtlinien und Verfahren und richtet sich danach, um zu gewährleisten, dass die Umgebung auch weiterhin vertrauenswürdig bleibt.
• Auf Risiken und Bedrohungen wird rechtzeitig reagiert.

Das Supportteam der Woodgrove Bank hat anhand dieser Ziele eine Reihe von technologischen Voraussetzungen definiert, um ermitteln zu können, ob ein Host als vertrauenswürdig eingestuft werden kann.

Wenn Sie den vertrauenswürdigen Status definieren, stellen Sie sicher, dass die für Ressourcen verantwortlichen Personen den Freiraum haben, gegebenenfalls weitere Sicherheitsmaßnahmen zu implementieren, um die geschäftlichen Anforderungen einer bestimmten Ressource zu erfüllen. Beispielsweise könnte in der Personalabteilung ein biometrischer Anmeldemechanismus für bestimmte Server erforderlich sein. Diese Anforderung ist für die Fähigkeit der Server, im Kontext dieser Lösung als vertrauenswürdig eingestuft zu werden, nicht relevant. Allerdings sollten Sie Vorsorge treffen, dass die Anforderungen einer bestimmten Ressource nicht mit den Voraussetzungen für einen vertrauenswürdigen Status in Konflikt geraten.

Nehmen Sie sich die Zeit, die Ziele und technologischen Anforderungen zu definieren, die in Ihrer Organisation als Mindestkonfiguration für einen Host gelten sollen, damit dieser als vertrauenswürdig eingestuft werden kann.

Beispielsweise wurde im Woodgrove Bank-Szenario die folgende Liste technologischer Voraussetzungen verwendet:

• Betriebssystem. Ein vertrauenswürdiger Host sollte unter Windows XP SP2 oder Windows Server 2003 bzw. mindestens unter Windows 2000 SP4 ausgeführt werden.
• Domänenmitgliedschaft. Ein vertrauenswürdiger Host sollte zu einer verwalteten Domäne gehören, was bedeutet, dass in der IT-Abteilung Sicherheitsverwaltungsrechte benötigt werden.
• Verwaltungsclient. Alle vertrauenswürdigen Hosts müssen einen bestimmten Netzwerkverwaltungsclient ausführen, um die zentralisierte Verwaltung und Steuerung von Sicherheitsrichtlinien, Konfigurationen und Software zu ermöglichen.
• Antivirussoftware. Alle vertrauenswürdigen Clients müssen Antivirussoftware ausführen, die so konfiguriert ist, dass täglich nach den neuesten Virensignaturen gesucht wird und diese installiert werden.
• Dateisystem. Alle vertrauenswürdigen Hosts sollten mit dem NTFS-Dateisystem konfiguriert sein.
• BIOS-Einstellungen. Alle vertrauenswürdigen mobilen Computer müssen mit einem Kennwort auf BIOS-Ebene konfiguriert sein, das der Verwaltung des IT-Supportteams untersteht.
• Kennwortanforderungen. Vertrauenswürdige Clients müssen sichere Kennwörter verwenden.

Es ist wichtig zu verstehen, dass ein vertrauenswürdiger Zustand nicht konstant ist; es handelt sich um einen vergänglichen Zustand, der von sich ändernden Sicherheitsstandards und der Einhaltung dieser Standards abhängig ist. Es werden ständig neue Bedrohungen und neue Abwehrtechnologien entwickelt. Daher ist es dringend erforderlich, die Verwaltungssysteme einer Organisation kontinuierlich zu überprüfen, um sicherzustellen, dass allen Sicherheitsanforderungen auch weiterhin Genüge getan wird. Darüber hinaus sollten diese Systeme in der Lage sein, Aktualisierungen oder Konfigurationsänderungen vorzunehmen, wenn diese zur Aufrechterhaltung des vertrauenswürdigen Status erforderlich sind.

Ein Host, der alle diese Sicherheitsanforderungen fortlaufend erfüllt, kann als vertrauenswürdig eingestuft werden. Es ist jedoch sehr wahrscheinlich, dass die meisten Hosts, die im Rahmen des weiter vorne in diesem Kapitel diskutierten Ermittlungsprozesses identifiziert wurden, diese Anforderungen zurzeit nicht erfüllen. Daher muss unbedingt festgestellt werden, welche Host zu vertrauenswürdigen Hosts werden können und welche nicht (und folglich als nicht vertrauenswürdig eingestuft werden müssen). Als Hilfestellung für diesen Prozess können Sie einen vorläufigen Status "potenziell vertrauenswürdig" definieren. Im restlichen Teil dieses Abschnitts werden die verschiedenen Statuseinstufungen und ihre Implikationen erörtert.

Status "Potenziell vertrauenswürdig"

Sie sollten möglichst bald die Hosts in Ihrer aktuellen Infrastruktur identifizieren, die fähig sind, gegebenenfalls einen vertrauenswürdigen Zustand zu erlangen. Ein potenziell vertrauenswürdiger Status kann zugewiesen werden, um anzugeben, dass der aktuelle Host physisch in der Lage ist, mit den entsprechenden Software- und Konfigurationsänderungen in einen vertrauenswürdigen Zustand versetzt zu werden.

Sie sollten für jeden als potenziell vertrauenswürdig eingestuften Host eine Begleitnotiz erstellen, in der aufgeführt ist, was erforderlich wäre, um den Host in einen vertrauenswürdigen Zustand zu versetzen. Diese Informationen sind sowohl für das Projektentwurfsteam (zur Schätzung der mit dem Hinzufügen dieses Hosts zur Lösung verbundenen Kosten) als auch für die Supportmitarbeiter (um ihnen zu ermöglichen, die entsprechende Konfiguration vorzunehmen) von besonderer Wichtigkeit. Im Allgemeinen fallen potenziell vertrauenswürdige Hosts in eine der folgenden zwei Kategorien:

• Konfiguration erforderlich. Hardware, Betriebssystem und Software, die aktuell auf dem Host vorhanden sind, erfüllen die Voraussetzungen, um den Host in einen vertrauenswürdigen Zustand versetzen zu können. Es sind jedoch zusätzliche Konfigurationsänderungen erforderlich, bis alle Sicherheitsvoraussetzungen erfüllt sind. Wenn die Organisation beispielsweise ein sicheres Dateisystem erfordert, bevor ein Host als vertrauenswürdig angesehen wird, würde ein Host mit einer FAT32-formatierten Festplatte diese Voraussetzung nicht erfüllen.
• Aktualisierung erforderlich. Bei dieser Kategorie von Computern sind Systemaktualisierungen erforderlich, bevor sie als vertrauenswürdig eingestuft werden können. In der folgenden Liste werden einige Beispiele für die Arten von Aktualisierungen aufgeführt, die für Computer in dieser Kategorie erforderlich sein könnten:
  • Betriebssystemupgrade erforderlich. Wenn das aktuelle Betriebssystem eines Hosts nicht die Sicherheitsanforderungen der Organisation unterstützt, wäre ein Upgrade notwendig, bevor dieser Host als vertrauenswürdig eingestuft werden könnte.
  • Software erforderlich. Ein Host, auf dem eine obligatorische Sicherheitsanwendung fehlt, z. B. ein Virenprüfprogramm oder ein Verwaltungsclient, kann erst als vertrauenswürdig angesehen werden, wenn diese Anwendungen installiert wurden und aktiv sind.
  • Hardwareupgrade erforderlich. In machen Fällen muss die Hardware eines Hosts aktualisiert oder erweitert werden, bevor er als vertrauenswürdig gilt. Diese Art von Host benötigt in der Regel eine Betriebssystemaktualisierung oder zusätzliche Software, durch die ein Hardwareupgrade erforderlich wird. Beispielsweise würde Sicherheitssoftware, für die zusätzlicher Speicherplatz auf dem Computer erforderlich ist, einen Bedarf an zusätzlichem Festplattenspeicher zur Folge haben.
  • Ersatz des Computers erforderlich. In diese Kategorie fallen lediglich Hosts, die den Sicherheitsanforderungen der Lösung nicht genügen können, weil die Hardware nicht in der Lage ist, die Mindestkonfiguration zu unterstützen. Ein Beispiel hierfür wäre ein Computer, der nicht fähig ist, ein sicheres Betriebssystem auszuführen, da er über einen alten Prozessor verfügt (etwa ein x86-basierter Computer mit 100 MHz).

Verwenden Sie diese Kategorien, um die Kosten für die Implementierung der Lösung auf Computern zuzuweisen, die Upgrades erfordern.

Status "Bekannt, nicht vertrauenswürdig"

Im Verlauf der Kategorisierung der Hosts einer Organisation werden Sie einige Hosts identifizieren, die aus bestimmten bekannten und definierten Gründen nicht in einen vertrauenswürdigen Zustand versetzt werden können. Dazu gehören u. a. die folgenden Gründe:

• Finanzielle Gründe. Es ist kein Budget verfügbar, um die Hardware oder Software für diesen Host zu aktualisieren.
• Politische Gründe. Der Host muss unter Umständen in einem nicht vertrauenswürdigen Zustand belassen werden, da die politische oder geschäftliche Situation nicht zulässt, dass er die festgelegten Mindestsicherheitsvoraussetzungen der Organisation erfüllt. Es wird dringend empfohlen, dass Sie sich mit dem Geschäftsbesitzer oder dem unabhängigen Softwareanbieter (ISV) für den Host in Verbindung setzen, um das Für und Wider einer Server- und Domänenisolierung zu besprechen.
• Funktionelle Gründe. Der Host muss ein unsicheres Betriebssystem ausführen bzw. in einer nicht abgesicherten Weise ausgeführt werden, um seine Rolle erfüllen zu können. Beispielsweise könnte es sein, dass der Host unter einem älteren Betriebssystem ausgeführt werden muss, da eine bestimmte Geschäftsanwendung nur auf diesem Betriebssystem laufen kann.

Es können eine Reihe von funktionellen Gründen vorhanden sein, aus denen der Host in einem nicht vertrauenswürdigen Zustand bleiben muss. Die folgende Liste nennt einige Beispiele von funktionellen Gründen, die dazu führen können, dass der Host als "bekannt, nicht vertrauenswürdig" eingestuft wird:

• Computer unter Windows 9x oder Windows Millennium Edition. Computer, die diese Versionen des Windows-Betriebssystems ausführen, können nicht als vertrauenswürdig eingestuft werden, da auf diesen Betriebssystemen keine grundlegende Sicherheitsinfrastruktur unterstützt wird. Diese Betriebssysteme haben von sich aus keinerlei Sicherheitsinfrastruktur. Darüber hinaus weisen sie lediglich elementare zentrale Verwaltungsfunktionalität für benutzerspezifische Computerkonfigurationen auf (durch Systemrichtlinien und Benutzeranmeldeskripts). Außerdem verfügen diese Betriebssysteme über keine der erforderlichen Funktionen zur Sicherheitsverwaltung.

• Computer unter Windows NT. Computer, die unter Windows NT ausgeführt werden, können im Kontext dieser Lösung zur Server- und Domänenisolierung nicht als potenziell vertrauenswürdig eingestuft werden, da das Betriebssystem eine grundlegende Sicherheitsinfrastruktur nur zum Teil unterstützt. Beispielsweise unterstützt Windows NT weder ACLs vom Typ "deny" auf lokalen Ressourcen, noch Methoden zur Gewährleistung der Vertraulichkeit und Integrität von Netzwerkverbindungen, Smartcards für starke Authentifizierung oder die zentrale Verwaltung von Computerkonfigurationen (obwohl eine eingeschränkte zentrale Verwaltung von Benutzerkonfigurationen möglich ist). Auch bietet Windows NT keine Methode zum Schutz der Vertraulichkeit und Integrität von Daten (wie z. B. das verschlüsselnde Dateisystem (Encrypting File System, EFS) von Windows 2000).

  Darüber hinaus werden bei Windows NT nicht alle erforderlichen Sicherheitsfunktionen unterstützt. So werden weder Gruppenrichtlinien noch IPSec-Richtlinien unterstützt, und es wird keine Methode bereitgestellt, mit der bei Bedarf ein lokaler Administratorzugriff gewährt werden kann. Weiterhin werden die Sicherheitskonfigurationen des Betriebssystems nicht regelmäßig neu zugewiesen, um ihre andauernde Gültigkeit zu gewährleisten.

  Hinweis

  
  Windows NT wird hier ausschließlich im Kontext der Implementierung einer Server- und Domänenisolierung als nicht vertrauenswürdig erörtert es soll keine Kritik an seinem Einsatz als Betriebssystem allgemein geübt werden. Für die Server in diesem Projekt bietet sich eine Aktualisierung auf die Windows Server 2003-Plattform als sicherste und praktischste Lösung an.

• Eigenständige Computer. Computer mit beliebigen Windows-Versionen, die als eigenständige Computer oder als Mitglied einer Arbeitsgruppe konfiguriert sein, können normalerweise nicht in einen vertrauenswürdigen Zustand versetzt werden. Auch wenn diese Betriebssysteme die mindestens erforderliche Sicherheitsinfrastruktur aufweisen, kann in der Regel nicht die obligatorische Sicherheitsverwaltungsfunktionalität erzielt werden, wenn der Computer nicht Bestandteil einer vertrauenswürdigen Domäne ist.

• Computer in einer nicht vertrauenswürdigen Domäne. Ein Computer in einer Domäne, die von der IT-Abteilung einer Organisation nicht als vertrauenswürdig angesehen wird, kann nicht als vertrauenswürdig eingestuft werden. Eine nicht vertrauenswürdige Domäne ist eine Domäne, die ihren Mitgliedern nicht die erforderliche Sicherheitsfunktionalität bereitstellen kann. Selbst wenn die Betriebssysteme der Computer in dieser nicht vertrauenswürdigen Domäne die mindestens erforderliche Sicherheitsinfrastruktur unterstützen, kann die notwendige Sicherheitsverwaltungsfunktionalität nicht gewährleistet werden, wenn die Computer sich nicht in einer vertrauenswürdigen Domäne befinden. Beispielsweise ist in einer nicht vertrauenswürdigen Domäne keine Mechanismus verfügbar, der gewährleistet, dass bei Bedarf lokaler Administratorzugriff durch einen vertrauenswürdigen Benutzer erlangt werden kann. Auch können Sicherheitskonfigurationen (einschließlich solcher, die zentral verwaltet werden können) mühelos durch Administratoren der nicht vertrauenswürdigen Domäne außer Kraft gesetzt oder geändert werden. Darüber hinaus kann nicht gewährleistet werden, dass Vorschriften für Sicherheitskonfiguration und Software sowie Richtlinien und Standards eingehalten werden, und es sind keine Maßnahmen verfügbar, um die Einhaltung zu überwachen.

• Computer in einer Windows NT-Domäne. Computer, die Mitglied einer auf Windows NT basierenden Domäne sind, können nicht als vertrauenswürdig eingestuft werden. Selbst wenn die jeweiligen Betriebssysteme die mindestens erforderliche Sicherheitsinfrastruktur vollständig unterstützen, wird die notwendige Sicherheitsverwaltungsfunktionalität nur teilweise unterstützt, wenn sich die Computer in einer Windows NT-Domäne befinden.

  Falls der Host jedoch im Entwurf berücksichtigt werden muss, weil er eine für die Organisation erforderliche Rolle erfüllt, sollten Sie ihm den Staus "bekannt, nicht vertrauenswürdig" zuweisen. Das bedeutet, das ein Risiko identifiziert wurde, das durch die Lösung nicht abgeschwächt werden kann. Sie müssen zusätzliche Maßnahmen ergreifen, um dieses bekannte Risiko zu verringern. Aufgrund der Vielfalt der Hosts in dieser Kategorie können hier keine spezifischen Anleitungen für derartige Maßnahmen gegeben werden. Das Ziel dieser zusätzlichen Schutzmaßnahmen sollte es jedoch sein, das durch den Host verkörperte Risiko auf eine Minimum zu reduzieren.

Status "Unbekannt, nicht vertrauenswürdig"

Der unbekannte, nicht vertrauenswürdige Zustand sollte als Standardzustand für alle Hosts angesehen werden. Da Hosts in diesem Zustand über eine unbekannte Konfiguration verfügen, können Sie ihnen keine Vertrauensstellung zuweisen. Jegliche Planung für Hosts in diesem Zustand sollte unter der Annahme erfolgen, dass die Sicherheit dieses Hosts beeinträchtigt wurde oder beeinträchtigt werden kann und dass er daher ein nicht akzeptables Risiko für die Organisation darstellt. Die für den Entwurf dieser Lösung zuständigen Personen sollten sich bemühen, die Auswirkungen, die Computer in diesem Zustand auf ihre Organisationen haben können, auf ein Minimum zu beschränken.

Zum Seitenanfang

Erfassen der Aktualisierungskosten für aktuelle Hosts

Der letzte Schritt in diesem Kapitel befasst sich mit dem Dokumentieren der ungefähren Kosten, die erforderlich sind, um Computer so weit zu aktualisieren, dass sie an dieser Lösung teilnehmen können. In der Entwurfsphase des Projekts müssen Sie verschiedene wichtige Entscheidungen treffen, für die eine Beantwortung der folgenden Fragen notwendig ist:

• Erfüllt der Computer die für die Isolierung erforderlichen Mindestvoraussetzungen in Bezug auf die Hardware?
• Erfüllt der Computer die für die Isolierung erforderlichen Mindestvoraussetzungen in Bezug auf die Software?
• Welche Konfigurationsänderungen sind erforderlich, um diesen Computer in die Isolierungslösung zu integrieren?
• Was sind die voraussichtlichen Kosten bzw. Konsequenzen der beabsichtigten Änderungen, um einen Computer in einen vertrauenswürdigen Zustand zu versetzen?

Indem Sie diese Fragen beantworten, können Sie schnell den Aufwand und die ungefähren Kosten einschätzen, die mit der Integration eines bestimmten Hosts oder einer Gruppe von Hosts in das Projekt verbunden sind. Es ist höchst unwahrscheinlich, dass alle diese Daten von einer Person (oder auch mehreren Personen im Rahmen einer Rolle) zusammengetragen werden. Manche Informationen werden möglicherweise von Helpdeskmitarbeitern oder Technikern im Einsatzdienst erfasst, während andere von Architekten oder Geschäftsverantwortlichen bereitgestellt werden müssen. Es ist wichtig zu beachten, dass der Zustand eines Computers nicht feststehend ist und dass Sie ihn von einem nicht vertrauenswürdigen Zustand in einen vertrauenswürdigen Zustand versetzen können, indem die aufgeführten Hilfsmaßnahmen ergriffen werden. Nachdem Sie entschieden haben, ob ein Computer in einen vertrauenswürdigen Zustand versetzt werden soll, sind Sie bereit, mit der Planung und dem Entwurf der Isolierungsgruppen zu beginnen. Dieser Prozess wird in Kapitel 4 dieses Leitfadens, "Entwerfen und Planen von Isolierungsgruppen", erörtert.

Die folgende Tabelle dient als Beispiel für ein Datenblatt, mit dessen Hilfe Sie erfassen können, wie der aktuellen Zustand eines Computers aussieht und welche Maßnahmen erforderlich wären, um den Host in einen vertrauenswürdigen Zustand zu versetzen.

Tabelle 3.3: Beispiel für erfasste Hostdaten

Hostname	HW-Anford. erfüllt	SW-Anford. erfüllt	Konfiguration erforderlich	Anmerkungen	Geplante Kosten
HOST-NYC-001	Nein	Nein	Aktualisierung von Hardware und Software.	Aktuelles Betriebssystem: Windows NT 4.0. Alte Hardware ist nicht kompatibel mit Windows XP SP2.	$XXX.
SERVER-LON-001	Ja	Nein	Aufnahme in vertrauenswürdige Domäne und Upgrade von Windows NT 4.0 auf Windows 2000 SP4 oder höher.	Keine Antivirussoftware vorhanden.	$XXX.

In der folgenden Liste werden die verschiedenen Spalten von Tabelle 3.3 erläutert:

Hostname. Der Name des Hostgeräts im Netzwerk.

• Erfüllte Hardwareanforderungen. Gibt an, ob ein Computer die Mindestanforderungen für Hardware erfüllt, die zur Teilnahme an der Lösung erforderlich sind.
• Erfüllte Softwareanforderungen. Gibt an, ob ein Computer die Mindestanforderungen für Software erfüllt, die zur Teilnahme an der Lösung erforderlich sind. Für die Woodgrove Bank handelte es sich hierbei um Windows 2000 SP4, Windows XP SP2 oder Windows Server 2003 sowie alle erforderlichen Sicherheitspatches für das jeweilige Betriebssystem. Außerdem mussten sich die Computer in einer vertrauenswürdigen Domäne befinden (d. h. einer Domäne, die vom IT-Personal der Woodgrove Bank zentral verwaltet wird), und die IT-Administratoren sollten ausdrücklich Zugriff auf den jeweiligen Computer gewähren.
• Konfiguration erforderlich. Gibt an, welche Maßnahmen ergriffen werden müssen, um den Computer in einen vertrauenswürdigen Zustand zu versetzen.
• Details. Beschreibt, warum der Computer zurzeit nicht in einem vertrauenswürdigen Zustand ist.
• Voraussichtliche Kosten. Gibt an, welche Kosten voraussichtlich anfallen, um das Gerät in einen vertrauenswürdigen Zustand zu versetzen. Diese Kosten sollten Schätzungen für Hardware, Software, Produktivitätsausfall und Support umfassen. Diese Informationen helfen Ihnen zu entscheiden, ob es von einem geschäftlichen Standpunkt aus gesehen praktisch oder lohnend ist, einen bestimmten Computer als vertrauenswürdigen Host in die Lösung aufzunehmen.

In der Tabelle oben wird der Host HOST-NYC-001 zurzeit als "bekannt, nicht vertrauenswürdig" eingestuft. Er könnte jedoch als potenziell vertrauenswürdig angesehen werden, sollten die erforderlichen Aktualisierungen möglich sein. Wenn jedoch zahlreiche Computer dieselben Aktualisierungen erfordern, werden dadurch die Gesamtkosten der Lösung beträchtlich in die Höhe getrieben.

Der Host SERVER-LON-001 erfüllt die Hardwarevoraussetzungen, muss jedoch auf ein Betriebssystem aktualisiert werden, dass IPSec-Richtlinien durchsetzen kann und Mitglied einer Domäne ist. Außerdem benötigt er eine Antivirussoftware. Bei den voraussichtlichen Kosten handelt es sich um den Aufwand, der mit der Aktualisierung des Betriebssystems und der Installation der Antivirussoftware verbunden ist, zusammen mit den Kosten für die Lizenzen für das Betriebssystem und die Antivirussoftware.

Nachdem Sie die in Tabelle 3.3 beschrieben Informationen ermittelt haben, speichern Sie sie zusammen mit den übrigen Informationen, die Sie in diesem Kapitel zusammengetragen haben, so dass der Architekt bzw. das Architekturteam sie nutzen kann. Diese Informationen bilden die Grundlage der in Kapitel 4 unternommenen Bemühungen, die sich mit dem Entwurf der Isolierungsgruppen beschäftigen.

Es sei angemerkt, dass es sich bei den in diesem Abschnitt ermittelten Kosten lediglich um die voraussichtlichen Kosten von Hostaktualisierungen handelt. Im Rahmen des Projekts fallen zahlreiche weitere Kosten für Entwurf, Support, Test und Schulungen an. Zur Ermittlung der genauen Projektkosten müssen diese Kosten im Gesamtprojektplan berücksichtigt werden.

Zum Seitenanfang

Zusammenfassung

In diesem Kapitel wurde ein Überblick über die Informationen gegeben, die zur Durchführung eines Projekts zur Server- und Domänenisolierung erforderlich sind. Des Weiteren wurden Überlegungen zu potenziellen Auswirkungen angestellt. Die hier aufgeführten Anleitungen sollen Sie bei den folgenden Aufgaben unterstützen:

• Identifizieren von Ressourcen im Netzwerk
• Erfassen von Netzwerkinformationen
• Erfassen von Hostinformationen
• Ermitteln aktueller Verkehrsinformationen
• Untersuchen der aktuellen Active Directory-Architektur und Erfassen diesbezüglich relevanter Informationen
• IPSec-Kapazitätsüberlegungen
• Vor der Bereitstellung von IPSec anzustellende Überlegungen
• Erläuterung von vertrauenswürdigen und nicht vertrauenswürdigen Geräten und ihrer Klassifizierung im Woodgrove Bank-Szenario

Anhand dieser Aufgaben lassen sich alle Informationen zusammentragen, die erforderlich sind, um mit dem Entwurf der Isolierungsgruppe im nächsten Kapitel zu beginnen.

Weitere Informationen

Dieser Abschnitt enthält Links zu Bereichen mit zusätzlichen Informationen, die sich bei der Implementierung dieser Lösung als hilfreich erweisen können:

• Weitere Informationen zur Konfiguration von Firewalls zur Unterstützung von IPSec für Windows Server 2003 finden Sie auf der Seite Configuring Firewalls der Windows Server 2003-Dokumentation unter www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dnsbj\_ips\_schx.asp (in englischer Sprache).
• Das Installationspaket für Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0) steht im Microsoft Download Center an folgender Adresse zum Download zur Verfügung: www.microsoft.com/downloads/details.aspx?
  FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875&DisplayLang=de.
• Weitere Informationen zu WMI finden Sie in der Dokumentation zu Windows Management Instrumentation in MSDN® unter https://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi\_start\_page.asp (in englischer Sprache).
• Microsoft Windows Script 5.6 für Windows 2000 und XP steht im Microsoft Download Center an folgender Adresse zum Download zur Verfügung: www.microsoft.com/downloads/details.aspx?
  FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=de.
• Microsoft Windows Script 5.6 für Windows 98, Windows Millennium Edition und Windows NT 4.0 steht im Microsoft Download Center an folgender Adresse zum Download zur Verfügung: www.microsoft.com/downloads/details.aspx?
  FamilyId=0A8A18F6-249C-4A72-BFCF-FC6AF26DC390&displaylang=de.
• Die Windows Script 5.6 Documentation steht im Microsoft Download Center an folgender Adresse zum Download zur Verfügung: www.microsoft.com/downloads/details.aspx?
  FamilyId=01592C48-207D-4BE1-8A76-1C4099D7BBB9&displaylang=en (in englischer Sprache).

Zum Seitenanfang

| Home | Technische Artikel | Community