Überlegungen zum Aktualisieren auf Windows Server 2003
Werbung
Servercluster: Bewährte Sicherheitsmethoden für Windows 2000 und Windows Server 2003 (Engl. Originaltitel: Server Clusters: Security Best Practices for Windows 2000 and Windows Server 2003) Microsoft Corporation Veröffentlicht: Januar 2003 Zusammenfassung Dieses Dokument beschreibt bewährte Sicherheitsmethoden für Servercluster. Es enthält Richtlinien und Best Practices für Windows 2000 und Windows Server 2003, die sich auf die Verwaltung, den Betrieb und das Schreiben von Anwendungen für Servercluster beziehen. Das Dokument ist in zwei Abschnitte unterteilt. Diese behandeln Sicherheitsmethoden für Administratoren, die Servercluster bereitstellen und verwalten, sowie für Entwickler, die clusterfähige Anwendungen erstellen, oder Anwendungen entwickeln, die auf einem Cluster bereitgestellt werden sollen. Allgemeine Voraussetzungen Es gibt eine Vielzahl von allgemeinen Voraussetzungen und bewährten Betriebsmethoden, die für die Infrastruktur vorhanden sein sollten, um eine sichere Umgebung zur Ausführung der Servercluster zu gewährleisten. 1. Server und Speicher befinden sich an physikalisch sicheren Orten. 2. Praktische Sicherheitsimplementierungen zur Erkennung von unregelmäßigem Datenverkehr sind vorhanden, wie z. B. Firewalls, Netzwerkuntersuchungen und Verwaltungsprogramme. 3. Sinnvolle Verfahrensweisen/gesunder Menschenverstand im Hinblick auf Sicherheit werden/wird in Bereichen wie Verwaltung, Protokollspeicherung, Sicherung und Wiederherstellung usw. eingehalten. 4. Bewährte Sicherheitsmethoden auf Plattformebene werden im Hinblick auf die Zuweisung administrativer Berechtigungen, die ACL-Erfassung von Ressourcen und andere Verwaltungsfunktionen eingehalten. 5. Die Netzwerkinfrastrukturdienste, wie Active Directory™, DNS, DHCP, WINS usw. müssen sicher sein. Jede Gefährdung dieser Infrastrukturdienste kann zu einer Gefährdung des Clusterdienstes führen. 6. Der Clusteradministrator muss sicherstellen, dass Anwendungen zum Aufrufen der Cluster-APIs (ClusAPI) auf vertrauenswürdigen Computern ausgeführt werden. Jede Gefährdung der Computer, auf denen die (vom Clusteradministrator ausgeführten) Anwendungen ausgeführt werden, kann auch den Cluster gefährden. Wenn beispielsweise nicht vertrauenswürdige Benutzer mit erhöhten Berechtigungen an der Arbeitsstation tätig sind, auf der die Verwaltungsprogramme ausgeführt werden, kann der Clusteradministrator nicht vertrauenswürdigen oder bösartigen Code ausführen, ohne dies zu bemerken. 7. Der Zugriff auf den vom Clusterdienst erstellten und verwalteten Satz von Objekten darf nicht dadurch gefährdet werden, dass die Standardeinstellungen für diese Objekte auf einen weniger restriktiven Wert geändert werden. Der Clusterdienst verwendet einen Satz von Objekten des Betriebssystems, wie z. B. Dateien, Geräte, Registrierungsschlüssel usw. Diese Objekte verfügen über eine Standardsicherheitseinstellung, die dafür sorgt, dass unberechtigte Benutzer die Clusterkonfiguration oder die auf dem Cluster ausgeführten Anwendungen nicht beeinflussen können. Eine Änderung dieser Sicherheitseinstellungen auf weniger restriktive Werte kann zu einer Gefährdung des Clusters und einer Beschädigung der Anwendungsdaten führen. Bereitstellung und Betriebsmanagement Clusteradministratoren Administratoren können Gruppen oder Einzelpersonen angeben, die den Cluster verwalten dürfen. In aktuellen Versionen des Serverclusters gibt es keine granulare Steuerung; entweder verfügt ein Benutzer über die Berechtigungen zum Verwalten des Clusters, oder er besitzt diese Berechtigungen nicht. Um einem Benutzer oder einer Gruppe Berechtigungen zum Verwalten des Clusters zu erteilen, muss dieser bzw. diese zur Clustersicherheitsbeschreibung hinzugefügt werden. Dies kann entweder vom Clusteradministrator, oder mit Hilfe des Befehlszeilentools cluster.exe ausgeführt werden. Anmerkung: Abgesehen von der lokalen Gruppe Administratoren auf einem Knoten MÜSSEN alle anderen Mitglieder der Clustersicherheitskonfiguration entweder Domänenbenutzerkonten oder globale Gruppen sein. Auf diese Weise soll sichergestellt werden, dass dasselbe, genau definierte und autorisierte Konto auf sämtlichen Knoten im Cluster verwendet wird. Standardmäßig wird die lokale Gruppe Administratoren zur Sicherheitsbeschreibung des Clusterdienstes hinzugefügt. Das Hinzufügen eines Benutzers oder einer Gruppe zur Clustersicherheitsbeschreibung bedeutet, dass der Benutzer alle Aspekte der Clusterkonfiguration verwalten kann, einschließlich (aber nicht beschränkt auf): Offline- und Onlineschalten von Ressourcen Beenden des Clusterdienstes auf Knoten Hinzufügen von Knoten zum Cluster und Entfernen aus dem Cluster Hinzufügen von Ressourcen zum Cluster und Entfernen aus dem Cluster Wegen des Ausmaßes der Auswirkungen auf die im Cluster ausgeführten Anwendungen und Dienste muss beim Hinzufügen eines Benutzers zur Clustersicherheitsbeschreibung besonders vorsichtig vorgegangen werden. Der Clusterdienst führt den einer Ressource zugeordneten Code unter seinem Domänenbenutzerkonto aus (das nicht mit dem für die Verwaltung des Clusters verwendeten Konto verwechselt werden sollte). Da ein Clusteradministrator neue Ressourcen zu einem Cluster hinzufügen kann und diese Ressourcen als Clusterdienstkonto ausgeführt werden, kann ein Clusteradministrator Code installieren, der mit lokalen Administratorrechten auf dem Computer ausgeführt wird. Sinnvolle Verfahrensweisen Clusteradministratoren sollten ein anderes Konto als das Clusterdienstkonto zum Verwalten des Clusters verwenden. Dies bietet die Möglichkeit, unterschiedliche Richtlinien (z. B. zum Kennwortablauf) auf das Clusterdienstkonto und die zum Verwalten des Clusters verwendeten Domänenkonten getrennt anzuwenden. Sie sollten nur Benutzer mit lokalen Administratorrechten zur Sicherheitsbeschreibung des Clusterdienstes hinzufügen. Anmerkung: Wird ein Domänenbenutzer oder eine globale Gruppe zur lokalen Gruppe Administratoren hinzugefügt, so wird diese Gruppe bzw. dieses Konto automatisch zu einem Clusteradministrator. Entfernen Sie die lokale Gruppe Administratoren nicht aus der Sicherheitskonfiguration des Clusterdienstes. Remoteverwaltung und -konfiguration von Clustern Verwaltungsprogramme oder andere Anwendungen, welche die Servercluster-APIs (ClusAPI) aufrufen, können auf Remotearbeitsstationen ausgeführt werden. Dabei muss der Clusteradministrator sicherstellen, dass die Anwendungen auf vertrauenswürdigen Computern ausgeführt werden. Jede Gefährdung der Computer, auf denen die (vom Clusteradministrator ausgeführten) Anwendungen ausgeführt werden, kann auch den Cluster gefährden. Wenn ein Cluster erstellt oder die Konfiguration geändert wird (z. B. durch Hinzufügen eines neuen Clusterknotens), erstellt der Clusterkonfigurations-Assistent eine Protokolldatei auf dem Computer, auf dem er ausgeführt wird. Damit kann der Administrator das Protokoll im Fall von Fehlern zum Debuggen und für die Problembehandlung verwenden. Die Protokolldatei kann Clusterkonfigurationsdaten enthalten, z. B. Cluster-IP-Adressen, Netzwerknamen usw. Mit diesen Daten könnte die Angriffsfläche vergrößert werden, wenn sie von nicht autorisierten Benutzern gelesen werden. Clusterdienstkonto Beim Clusterdienstkonto handelt es sich um das Konto, unter dem der Clusterdienst gestartet wird. Die Anmeldeinformationen für dieses Konto werden im Dienststeuerungs-Manager (Service Control Manager oder SCM) gespeichert. Hierbei handelt es sich um die Windows®Komponente, die beim Start der Clusterknoten für das Starten des Clusterdienstes verantwortlich ist. Auf allen Knoten eines Clusters muss dasselbe Clusterdienstkonto verwendet werden – ein Konto auf Domänenebene, das außerdem über lokale Administratorrechte für jeden Knoten im Cluster verfügt. Das Domänenkonto muss vor Erstellung des Clusters existieren; der Clusterkonfigurations-Assistent fordert Sie zur Eingabe des Kontos auf, das verwendet werden soll. Wenn das Konto nicht bereits ein Mitglied der lokalen Gruppe Administratoren ist, wird es vom Clusterkonfigurations-Assistenten beim Erstellen des Clusters automatisch zu dieser Gruppe hinzugefügt. Ebenso wird das Clusterdienstkonto beim Hinzufügen von Knoten zum Cluster zur lokalen Gruppe Administratoren hinzugefügt. Wenn ein Knoten aus einem Cluster entfernt wird, bleibt das Clusterdienstkonto in der lokalen Gruppe Administratoren erhalten. Sie müssen sich dieser Semantik bewusst sein, wenn Sie vermeiden möchten, dass einem Domänenkonto unbeabsichtigt lokale Administratorrechte für einen bestimmten Knotensatz erteilt werden. Anmerkung: Durch das Entfernen eines Knotens aus einem Cluster wird das Clusterdienstkonto NICHT aus der lokalen Gruppe Administratoren entfernt. Wenn Sie einen Knoten aus dem Cluster entfernt haben, sollten Sie das Clusterdienstkonto manuell aus der lokalen Gruppe Administratoren entfernen. Auf diese Weise vermeiden Sie veraltete Konten mit lokalen Administratorrechten für einen Computer. Die Knoten in einem Servercluster stellen über authentifizierte Kommunikationsmechanismen sicher, dass nur gültige Mitglieder des Clusters die clusterinternen Protokolle verwenden können. Es ist äußerst wichtig, dass jeder Knoten im Cluster über dasselbe Clusterdienstkonto verfügt, um Authentifizierungskonsistenz zu ermöglichen. Das in Microsoft® Windows Server 2003 eingeführte Hilfsprogramm für Clusterdienstkonto-Kennwörter erfordert zwingend die Verwendung von gleichen Clusterdienstkonten. Erforderliche Berechtigungen Das Clusterdienstkonto muss sowohl ein Mitglied der lokalen Gruppe Administratoren sein, als auch über einen Satz zusätzlicher, lokal erteilter Berechtigungen verfügen. Diese sind: Einsetzen als Teil des Betriebssystems (erforderlich für Windows 2000 oder höher). Sichern von Dateien und Verzeichnissen. Anheben von Quoten. Anheben der Zeitplanungspriorität. Laden und Entfernen von Gerätetreibern. Sperren von Seiten im Speicher. Als Dienst anmelden. Wiederherstellen von Dateien und Verzeichnissen. Sie sollten KEINE dieser Berechtigungen aus dem Clusterdienstkonto entfernen. Wenn Sie eine oder mehrere dieser erforderlichen Berechtigungen entfernen, kann der Clusterdienst möglicherweise nicht mehr gestartet werden, oder er funktioniert nicht ordnungsgemäß. Während des Installationsvorgangs für den Clusterserver werden diese Berechtigungen dem Konto lokal erteilt. Wenn das Clusterdienstkonto zu irgendeinem Zeitpunkt erneut manuell erstellt werden muss, müssen Sie auch diese zusätzlichen Berechtigungen erteilen. Im englischsprachigen KB-Artikel 269229: How to Manually Re-Create the Cluster Service Account (englischsprachig) werden die erforderlichen Schritte zum erneuten Erstellen des Clusterdienstkontos beschrieben. Kennwortrichtlinien Das Clusterdienstkonto besitzt, genauso wie jedes anderes Domänenkonto, ein Kennwort, dem Richtlinien zum Kennwortablauf zugeordnet sein können. Wenn dem Kennwort für das Clusterdienstkonto Ablaufrichtlinien zugewiesen wurden, muss es vor Erreichen des Ablaufdatums geändert werden. Wird diese Änderung nicht rechtzeitig vorgenommen, funktioniert der Cluster nach dem Kennwortablauf nicht mehr, da die clusterinterne Kommunikation nicht mehr erfolgreich authentifiziert werden kann. Ändern des Kennworts In den meisten Produktionsumgebungen besitzen Domänenkonten Richtlinien zum Kennwortablauf, die eine relativ häufige Änderung des Kennworts (z. B. alle 30 Tage) erzwingen. Die Änderung des Kennworts für das Clusterdienstkonto muss sorgfältig geplant werden. Windows 2000 Das Clusterdienstkonto auf ALLEN Knoten im Cluster muss übereinstimmen, um sicherzustellen, dass die clusterinterne Kommunikation erfolgreich authentifiziert werden kann. Der Clusterdienst selbst sendet Nachrichten zwischen Clusterknoten auf viele verschiedene Arten. Wenn eine dieser Kommunikationen fehlschlägt, wird der Clusterknoten aus dem Cluster entfernt (und damit der Clusterdienst beendet). Es lässt sich nicht ermitteln, wann der Clusterdienst die Kommunikation einrichtet. Deshalb gibt es kein eindeutiges Verfahren, mit dem das Clusterdienstkonto zuverlässig geändert und gleichzeitig sichergestellt werden kann, dass der Cluster weiterhin ausgeführt wird. Unter Windows 2000 kann das Kennwort für das Clusterkonto nur über die folgenden Schritte zuverlässig geändert werden: 1. Beenden des Clusterdienstes auf ALLEN Clusterknoten 2. Ändern des Kennworts für das Clusterdienstkonto auf dem Domänencontroller 3. Aktualisieren des Kennworts für den Dienststeuerungs-Manager auf ALLEN Clusterknoten 4. Erneutes Starten des Clusterdienstes auf ALLEN Clusterknoten Windows Server 2003 Mit dem Tool cluster.exe unter Windows Server 2003 kann das Kennwort für das Clusterkonto dynamisch geändert werden, ohne dass der Clusterdienst auf einem der Knoten beendet werden muss. Cluster.exe ändert das Kennwort für das Domänenkonto und aktualisiert die Kontoinformationen des Dienststeuerungs-Managers auf allen Knoten im Cluster. Anmerkung: Dieser Befehl funktioniert nur bei Windows Server 2003-Knoten. Wenn der Cluster auch Windows 2000-Knoten enthält, wird das Kennwort für das Clusterdienstkonto nicht geändert. Cluster /cluster:Clustername1[,Clustername2,…] /changepassword[:neues_Kennwort[,altes_Kennwort]] [/skipdc] [/force] [/Optionen] Die Befehlsargumente haben folgende Bedeutungen: Argument cluster:Clustername1 [,Clustername2,…] /changepassword [:neues_Kennwort [,altes_Kennwort]] Beschreibung Identifiziert den/die Cluster für die Änderung des Kontokennworts. Wenn mehrere Cluster angegeben werden, müssen sie dasselbe Clusterdienstkonto verwenden. Falls einige Knoten nicht verfügbar sind, wird das Kennwort auf keinem der Knoten oder dem Domänencontroller geändert. Ändert das Kennwort für das Clusterdienstkonto auf dem Domänencontroller und allen Clusterknoten von „altes_Kennwort“ in „neues_Kennwort“. Wenn Sie keine Kennwörter in die Befehlszeile eingeben, werden Sie zur Kennworteingabe aufgefordert. Ändert das Kennwort für das Clusterdienstkonto nur auf den Clusterknoten. Erzwingt die Ausführung der Kennwortänderung auf den verfügbaren Knoten sogar dann, wenn einige Knoten nicht verfügbar sind. Anmerkung: Das Kennwort auf nicht verfügbaren Knoten wird nicht aktualisiert. Diese Knoten können dem Cluster erst dann beitreten, wenn das Kennwort für das Clusterdienstkonto über die Computerverwaltung manuell aktualisiert wurde. /skipdc /force Die Details des Befehls sind in der Onlinehilfe dokumentiert. Auf diese kann Clusterverwaltungsprogramm zugegriffen werden. Sinnvolle Verfahrensweisen Das Clusterdienstkonto sollte KEIN Domänenadministratorkonto sein. Allen Konten sollten die möglichen Mindestrechte und -berechtigungen erteilt werden, um bei einer Gefährdung eines bestimmten Kontos potenzielle Sicherheitsprobleme zu vermeiden. Verwenden Sie die Delegierung, um bestimmten Konten auf ALLEN Knoten eines Clusters Administratorrechte zu erteilen. Wenn eine einzelne Domäne mehrere Cluster enthält, erleichtert die Verwendung desselben Clusterdienstkontos auf allen Knoten die Verwaltung. Sie müssen die vereinfachte Verwaltung gegen die potenziellen Sicherheitsrisiken abwägen, die mit der Verwendung eines einzigen Kontos für viele Cluster verbunden sind. Wenn das Konto gefährdet ist, hängt das Ausmaß der Auswirkungen davon ab, wie viele Cluster dieses verwenden. Unter Windows Server 2003 kann das Kennwort für das Clusterdienstkonto auf mehreren Clustern gleichzeitig geändert werden. Wenn Sie Richtlinien für den Kennwortablauf bei den Clusterdienstkonten festgelegt haben, sollten Sie dieses Konto NICHT für andere Dienste verwenden. Verwenden Sie das Clusterdienstkonto beispielsweise nicht für SQL Server 2000 oder Exchange 2000, wenn Sie Richtlinien für den Kennwortablauf festgelegt haben. Falls mehrere Dienste dasselbe Konto verwenden, ist die Koordination der Kennwortänderung beim Clusterdienst und bei anderen Diensten komplex und führt dazu, dass der komplette Cluster und/oder Dienst während einer Kennwortrotation nicht verfügbar ist. Besser ist es, über ein dediziertes Konto für jeden Dienst zu verfügen, das jeweils unabhängig verwaltet werden kann. Unter Windows Server 2003 kann das Kennwort für das Clusterdienstkonto nur dann online ohne Herunterfahren des Clusters geändert werden, wenn keine Dienste dasselbe Konto verwenden. Zum Ändern des Kennworts für das Clusterdienstkonto unter Windows 2000 muss der Cluster vor der Änderung vollständig heruntergefahren werden. Das Herunterfahren und erneute Starten des Clusters bedeutet möglicherweise, dass dieser die Verfügbarkeitsanforderungen nicht erfüllen kann. Beispielsweise erfordert eine Betriebszeit von 99,999 % weniger als fünf Minuten Ausfallzeit pro Jahr für die Anwendungen und Dienste. Dieser Grad der Verfügbarkeit kann nicht erzielt werden, wenn der Cluster zur Kennwortrotation heruntergefahren wird. In Umgebungen mit hoher Verfügbarkeit sollte unter Windows 2000 eine Richtlinie für das Clusterdienstkonto festlegen, dass das Kennwort niemals abläuft. Unter Windows 2000 SP3 und Windows Server 2003 kann der Clusterdienst virtuelle Server als Computerobjekte in Active Directory veröffentlichen. Zur Sicherstellung des einwandfreien Betriebs sollte das Clusterdienstkonto über die entsprechenden Rechte oder Berechtigungen verfügen, die notwendig sind um diese Objekte im Container Active Directory Computers erstellen und bearbeiten zu können. Weitere Informationen finden Sie im Abschnitt Verwenden der KerberosAuthentifizierung in einem Servercluster. Wenn Sie mehrere Cluster unter Verwendung unterschiedlicher Clusterdienstkonten bereitstellen möchten, sollten Sie eine globale oder universelle Gruppe erstellen, die alle Richtlinien implementiert und über alle vorstehend beschriebenen Berechtigungen verfügt. Jedes Clusterdienstkonto sollte dann in die Gruppe einbezogen werden. Dies vereinfacht die Verwaltung der Clusterdienstkonten, indem ein einziger Container für alle diese Konten und eine einzige zentrale Stelle für die Änderung der Kontorichtlinien bereitgestellt wird. Verwenden der Kerberos-Authentifizierung in einem Servercluster Die Kerberos-Authentifizierung wurde als Teil der Windows-Plattform mit Windows 2000 eingeführt. Sie ist der primäre Standardsicherheitsmechanismus für die sich weiterentwickelnde Windows-Plattform und bietet etliche Vorteile gegenüber den früheren Authentifizierungsmechanismen (wie z. B. NTLM). Sie ermöglicht gegenseitige Authentifizierung von Client und Server: Der Server stellt sicher, dass der Client Zugriff auf die dort bereitgestellten Dienste oder Anwendungen hat. Für den Client wird gewährleistet, dass er tatsächlich mit dem erwarteten Server kommuniziert. Sie erlaubt die Delegierung der Authentifizierung auf mehrere Computer: Sie erlaubt den End-to-End-Identitätswechsel auf der Grundlage der Anmeldeinformationen, die mit der ursprünglichen Anforderung in einer Anwendungsbereitstellung auf mehreren Ebenen verbunden sind. So kann eine Website beispielsweise ein IIS-Webserver-Front-End, Geschäftsobjekte der mittleren Ebene sowie ein Datenbank-Back-End enthalten. Kerberos ermöglicht es, dass die Original-Clientauthentifizierung über alle Ebenen vom Webserver bis zur Datenbank als End-to-End-Authentifizierung und -Autorisierung erfolgt. Sie stellt einen Industriestandard dar, der einen gemeinsamen Authentifizierungsmechanismus über mehrere Plattformen hinweg ermöglicht. Weitere Informationen zu Kerberos und dessen Funktionsweise finden Sie auf folgender TechNet-Webseite: http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/tcevents/itevents/kerber os.asp In einem Servercluster werden Anwendungen auf virtuellen Servern bereitgestellt. Bei einem virtuellen Server handelt es sich um eine Servercluster-Ressourcengruppe, die eine IPAdressressource und eine Netzwerknamenressource, sowie alle für einen bestimmten Dienst oder eine bestimmte Anwendung erforderlichen Ressourcen enthält. Clients stellen eine Verbindung zum Clusterdienst über die dem Dienst zugeordnete IP-Adresse, bzw. den ihm zugeordneten Netzwerknamen her. Wenn eine Anwendung einen Failover von einem Knoten auf einen anderen Knoten durchführt, führen auch die IP-Adress- und die Netzwerknamenressource einen Failover durch. Folglich verwendet der Client weiterhin das gleiche Ziel für einen Dienst oder eine Anwendung – unabhängig davon, auf welchem Computer im Cluster er momentan gehostet wird. Bei Serverclustern unter Windows 2000 (bis SP2) ist NTLM der einzige verfügbare Mechanismus für die Authentifizierung eines Clients durch einen virtuellen Servernamen. Deshalb stehen die Vorteile von Kerberos nicht zur Verfügung. Unter Windows 2000 SP3 und Windows Server 2003 ist die Kerberos-Authentifizierung für Clusterserveranwendungen verfügbar und ermöglicht so einen End-to-End-Identitätswechsel bei einer hohen Verfügbarkeit. Computerobjekte virtueller Server Für die Kerberos-Authentifizierung ist ein Computerobjekt (CO) erforderlich, das in Active Directory veröffentlicht werden muss. Unter Windows 2000 SP3 oder höher verfügt die Netzwerknamenressource des Clusters über die Fähigkeit zur Veröffentlichung eines Computerobjekts für virtuelle Server in Active Directory. Dies wird über die neue Ressourceneigenschaft RequireKerberos mit folgenden Werten gesteuert: RequireKerberos = 0 Die Netzwerknamenressource erstellt in Active Directory kein Objekt. Sie stellt die gleiche Semantik wie unter Windows 2000 (bis SP2) bereit. Dieser Wert ist der Standardwert für Abwärtskompatibilität, sowie für die Sicherstellung des ordnungsgemäßen Verhaltens während paralleler Updates1. RequireKerberos = 1 Die Netzwerknamenressource erstellt in Active Directory ein Objekt und ermöglicht so die Kerberos-Authentifizierung durch den Namen des virtuellen Servercomputers. Die vollständige Semantik für diese Eigenschaft wird weiter unten in diesem Abschnitt beschrieben. Anmerkung: Obwohl die Netzwerknamenressource ein Computerobjekt in Active Directory veröffentlicht, sollte dieses Objekt NICHT für Verwaltungsaufgaben, z. B. das Anwenden von Gruppenrichtlinien, verwendet werden. Die EINZIGE Rolle für das Computerobjekt virtueller Server unter Windows 2000 und Windows Server 2003 besteht darin, der KerberosAuthentifizierung und -Delegierung sowie cluster- und Active Directory-fähigen Diensten (z. B. MSMQ) das Veröffentlichen von Dienstanbieterinformationen zu ermöglichen. Lebensdauer eines Computerobjekts Die Netzwerknamenressource steuert das Erstellen und Löschen von Computerobjekten aufgrund einer Reihe von Faktoren wie z. B. den Eigenschaftseinstellungen und der Lebensdauer der Ressource. Erstellen von Computerobjekten Die Netzwerknamenressource erstellt ein Computerobjekt, wenn die Ressourceneigenschaft RequireKerberos auf 1 festgelegt wird (der Standardwert lautet 0). Für die Festlegung dieses Wertes auf 1 muss das Clusterdienstkonto auf Active Directory zugreifen können. Dazu muss es entweder über die Berechtigung Hinzufügen von Arbeitsstationen zur Domäne verfügen, oder ihm muss spezifischer Zugriff auf Active Directory erteilt werden. Wenn das Konto über keinen Zugriff verfügt, kann die Netzwerknamenressource nicht online geschaltet werden. Domänenadministratoren können Computerobjekte für virtuelle Server vorbereiten (ggf. in einer getrennten OU) und so das Erteilen der Berechtigung Hinzufügen von Arbeitsstationen zur Domäne an das Clusterkonto vermeiden. In diesem Fall muss das Computerobjekt über eine Zugriffssteuerungsliste (Access Control List oder ACL) verfügen, die es dem Clusterdienstkonto ermöglicht, das Kennwort zurückzusetzen sowie in die Attribute vom Typ DnsHostName und ServicePrincipalName zu schreiben (die individuelle Zugriffsrechte besitzen). Wenn ein „verwaistes“ Computerobjekt oder ein vom Domänenadministrator erstelltes Computerobjekt in Active Directory mit dem Namen des virtuellen Computers vorhanden ist, das Clusterdienstkonto über die erforderlichen Zugriffsrechte für das Objekt verfügt und das Objekt nicht deaktiviert ist, verwendet die Netzwerknamenressource das bestehende Computerobjekt. Das gleiche passiert zum Beispiel, wenn ein neuer Computer zu einer Domäne hinzugefügt wird, die ein altes, nicht verwendetes Computerobjekt mit dem gleichen Namen enthält. Die Netzwerknamenressource legt das DnsHostName-Attribut des Computerobjekts auf den vollqualifizierten DNS-Namen ihrer Name-Eigenschaft und das primäre DNS-Suffix des Knotens2 fest. Deaktivieren von Computerobjekten Computerobjekte werden deaktiviert, wenn entweder die Kerberos-Authentifizierung nicht mehr erforderlich ist (die RequireKerberos-Eigenschaft von 1 in 0 geändert wurde), oder wenn die Ressource selbst gelöscht wurde. Wenn das Computerobjekt zwar weiterhin vorhanden ist, aber die Netzwerknamenressource ohne aktivierte Kerberos-Authentifizierung online geschaltet wird, schlägt die Clientauthentifizierung fehl. Beim Entfernen der KerberosAuthentifizierung von einer Netzwerknamenressource muss der Systemadministrator explizit entscheiden, dass das entsprechende Computerobjekt gelöscht werden soll. Beachten Sie, dass Active Directory-fähige Anwendungen, die auf dem virtuellen Server gehostet werden (wie z. B. Exchange Server und MSMQ), möglicherweise eigene Informationen mit dem Computerobjekt verknüpft haben. Wenn das Computerobjekt gelöscht wird, werden diese Eigenschaften ebenfalls gelöscht, und die Anwendungen funktionieren eventuell nicht mehr ordnungsgemäß. Daher sollte mit größter Vorsicht vorgegangen werden, wenn die KerberosAuthentifizierung von einem Netzwerknamen entfernt wird. Wenn die Netzwerknamenressource gelöscht, oder die Kerberos-Authentifizierung entfernt wurde, versucht diese Ressource ein einziges Mal, das Computerobjekt zu deaktivieren. Sämtliche Vorgänge zur Deaktivierung werden zusammen mit dem letzten Status in den Cluster- und Systemereignisprotokollen aufgezeichnet. Wenn die Deaktivierung des Computerobjekts aus irgendeinem Grund fehlschlägt, wird kein weiterer Deaktivierungsversuch unternommen. Umbenennen von Computerobjekten Das Computerobjekt ist mit dem von der Netzwerknamenressource veröffentlichten Namen des virtuellen Netzwerks eng verbunden. Wenn die Name-Eigenschaft der Netzwerknamenressource geändert wird, muss diese Änderung in das Computerobjekt übernommen werden. Da diese Änderungen eng gekoppelt und synchronisiert sind, kann eine Änderung der Name-Eigenschaft nur erfolgen, wenn die Netzwerknamenressource offline geschaltet ist. Falls die Umbenennung des Computerobjekts aus irgendeinem Grund fehlschlägt, schlägt die Änderung der Name-Eigenschaft ebenfalls fehl. Hierzu gibt es eine Vorsichtsmaßnahme: Die Netzwerknamenressource ermöglicht eine Änderung von Eigenschaftswerten, während sie online geschaltet ist; in diesem Fall wird die Umbenennung so lange aufgeschoben, bis der Name offline geschaltet wird. Wenn der Umbenennungsversuch fehlschlägt, wird der Vorgang im Rahmen des Onlineprozesses wiederholt. Der Name wird erst wieder online geschaltet, nachdem der Umbenennungsvorgang erfolgreich abgeschlossen wurde. Anmerkung: Viele Anwendungen und Dienste, wie z. B. MSMQ und SQL Server, unterstützen die Änderung der Name-Eigenschaft für die Netzwerknamenressource NICHT. Kennwortrotation Das Computerobjekt behält das Kennwort bei, das bei der Herausgabe von Kerberos-Tickets zur Authentifizierung verwendet wurde. In der aktuellen Implementierung für Windows 2000 SP3 und Windows Server 2003 wird das Kennwort für das Computerobjekt nach dem Erstellen des Objekts nicht mehr geändert. Vorsichtsmaßnahmen, Probleme und Überlegungen Verwaiste Computerobjekte Viele Betriebssystemdienste und -anwendungen verwenden eine Sicherheitsaushandlung. Dabei handelt es sich um eine von der Windows-Plattform bereitgestellte Komponente, die einem Client die Authentifizierung bei einem Dienst ermöglicht. Sie verbirgt die Einzelheiten eines bestimmten Authentifizierungsschemas und ermöglicht einem Client den Versuch einer Kerberos-Authentifizierung. Wenn sie nicht verfügbar ist, greift der Client auf die NTLMAuthentifizierung zurück. Wenn Active Directory ein Computerobjekt enthält, das dem vom Client verwendeten Zielnamen entspricht, setzt die Sicherheitsaushandlung voraus, dass die Kerberos-Authentifizierung erforderlich ist3. Enthält Active Directory ein virtuelles Computerobjekt (deaktiviert oder nicht deaktiviert), greifen künftige Clientverbindungen mit dem Namen dieses virtuellen Servers NICHT auf NTLM zurück. Wenn die Authentifizierung bei einem virtuellen Server fehlschlägt und dieser Server NTLM verwendet, sollten Sie überprüfen, ob Active Directory ein verwaistes oder altes Computerobjekt enthält, das dem Namen des virtuellen Servers entspricht. Cluster- und Active Directory-fähige Dienste Es gibt einige Dienste, die sowohl cluster- als auch Active Directory-fähig sind. Hierzu gehören vor allem SQL Server 2000, Exchange 2000 und MSMQ. Manche dieser Dienste verknüpfen Dienstinformationen mit den Computerobjekten. MSMQ insbesondere verknüpft Dienstinformationen mit dem Computerobjekt virtueller Server. Beim Entfernen der Kerberos-Authentifizierung von einer Netzwerknamenressource wird das Computerobjekt deaktiviert. Dann muss der Systemadministrator explizit entscheiden, dass das Objekt gelöscht werden soll. Wenn das Computerobjekt gelöscht wird, werden die durch Active Directory-fähige Anwendungen verwendeten Eigenschaften ebenfalls gelöscht, und diese Anwendungen funktionieren möglicherweise nicht mehr ordnungsgemäß. Daher sollte äußerst vorsichtig vorgegangen werden, wenn die Kerberos-Authentifizierung von einer Netzwerknamenressource entfernt wird. Verzögerungen bei der Active Directory-Replikation Bis jetzt wurde bei Active Directory davon ausgegangen, dass es sich um eine einzelne, sehr konsistente Infrastruktur handelte. In einer Produktionsumgebung werden mehrere Domänencontroller bereitgestellt, um sicherzustellen, dass die Domäneninfrastruktur kontinuierlich verfügbar ist. Änderungen an Active Directory werden über Knoten hinweg repliziert, und in einigen Fällen kann die so entstehende Replikationsverzögerung sehr groß sein. Dies kann einige anscheinend inkonsistente Effekte verursachen. Diese müssen Sie berücksichtigen. Clients können das Computerobjekt für eine Netzwerknamenressource nicht finden Verschiedene Knoten können auf unterschiedliche Domänencontroller zugreifen. Wenn ein Computerobjekt auf einem Domänencontroller erstellt wird, ist es für die Clients möglicherweise erst dann sichtbar, nachdem es auf andere Domänencontroller repliziert wurde. Sinnvolle Verfahrensweisen Planen Sie die Verwendung der Kerberos-Authentifizierung in einem Cluster sorgfältig: Aktivieren Sie die Kerberos-Authentifizierung auf den virtuellen Servern, die für Ihre Bereitstellung sinnvoll sind. Sie sollten die Kerberos-Authentifizierung auf einem virtuellen Server nur dann deaktivieren, wenn Sie die Dienste, die diesen Server verwenden, vollständig verstehen und genau wissen, wie sich eine Deaktivierung auf die Dienste auswirken wird. Das Computerobjekt und alle damit verknüpften Dienstinformationen werden gelöscht (vorausgesetzt, dass korrekte Berechtigungen existieren). Dies kann dazu führen, dass ein Dienst nicht verfügbar ist, oder nicht wiederhergestellt werden kann. Das Clusterdienstkonto sollte die Berechtigung Hinzufügen von Arbeitsstationen zur Domäne besitzen, um ihm das Erstellen von Computerobjekten in Active Directory zu ermöglichen. Wenn Sie dem Clusterdienstkonto diese Berechtigung nicht erteilen möchten, MÜSSEN Sie das Computerobjekt in Active Directory manuell erstellen, bevor Sie die Kerberos-Authentifizierung aktivieren. Anmerkung: Die Berechtigung Hinzufügen von Arbeitsstationen zur Domäne erlaubt das Erstellen von 10 Computerobjekten über dieses Konto. Diese Berechtigung erlaubt jedoch NICHT, dass das Computerobjekt über das Konto gelöscht oder umbenannt wird. Das Clusterdienstkonto sollte über die Zugriffsrechte Alle Eigenschaften schreiben verfügen, damit das Computerobjekt umbenannt werden kann. Viele Dienste, darunter MSMQ und SQL Server 2000, unterstützen das Ändern der Name-Eigenschaft der Netzwerknamenressource nicht. Deshalb sollten Sie diese Eigenschaft nur dann ändern, wenn Sie die möglichen Auswirkungen vollständig verstehen. In einigen Fällen kann eine Änderung der Name-Eigenschaft zum Datenverlust oder zum Ausfall eines Dienstes führen. Sie sollten sicherstellen, dass die Domänencontroller die Möglichkeit hatten, neu erstellte und den Netzwerknamenressourcen zugeordnete Computerobjekte zu replizieren, bevor Sie Clients den Zugriff auf die Objekte erlauben, oder bevor ein Failover der Ressource auf einen anderen Knoten im Cluster durchgeführt wird. Bei Nichtbeachtung dieser Empfehlung kann es zu unvorhersehbaren Ergebnissen kommen (Weitere Informationen finden Sie im Abschnitt Verzögerungen bei der Active Directory-Replikation). Netzwerksicherheit Netzwerküberflutung Der Clusterdienst verwendet den UDP-Port 3343 für clusterinterne Kommunikation. Diese Kommunikation umfasst Taktdatenverkehr zur Erkennung von Knotenfehler- und Clustersteuervorgängen. Einige dieser Vorgänge (wie z. B. Takte) sind zeitkritisch. Wenn die Anschlüsse infolge von Netzwerküberflutungsangriffen (Network Flooding) stark belastet sind, kann dies zu einer falschen Knotenfehlererkennung führen und deshalb unnötige Failover verursachen, die wiederum zu einer Ausfallzeit für die Anwendung führen. Port-Squatting Es ist möglich, dass eine bösartige Anwendung auf Port 3343 zugreift. Damit wird das Starten des Clusterdienstes verhindert. In diesem Fall besteht die einzige Möglichkeit darin, Prozesse die diesen Port verwenden zu beenden. Port 3343 ist ausschließlich für den Clusterdienst registriert. Rogue-Server Der Clusterdienst stellt Remoteverwaltungsfunktionen über die Cluster-APIs bereit, so dass ein Cluster von einer Arbeitsstation aus verwaltet werden kann. Die Cluster-APIs verwenden NTLM zur Authentifizierung am Server. NTLM ermöglicht es dem Server, zu bestätigen, dass der Client über ausreichende Rechte und Berechtigungen zum Verwalten des Clusters verfügt, bietet jedoch keine gegenseitige Authentifizierung. Mit anderen Worten: Der Client hat keine hundertprozentige Garantie, dass es sich bei dem mit ihm verbundenen Knoten oder Cluster um den richtigen Cluster handelt. Wenn ein Rogue-Computer im Netzwerk mit derselben IP-Adresse oder demselben Netzwerknamen (bei einer Kompromittierung der DNS-Server) angezeigt wird, könnte sich dieser Computer als Cluster ausgeben. Wenn dieser Rogue-Computer außerdem die Clusterdienst-APIs zur Verfügung stellt, würden alle an den Cluster gesendeten Verwaltungsbefehle vom Rogue-Computer abgefangen. In vielen Fällen stellt dies keine Bedrohung dar, weil der Administrator eine falsche Meldung zurückerhält. Es gibt jedoch sicherheitsrelevante Vorgänge (z. B. das Ändern der Clusterkonfiguration), bei denen ein nicht autorisierter Empfänger Clusterkonfigurationsdaten sammeln und und diese für einen Angriff verwenden könnte. Damit dieser Angriff überhaupt möglich wird, müssen die folgenden Bedingen gegeben sein: 1. Der Rogue-Computer muss im selben Subnetz wie der Zielcluster sein und auf Datenverkehr an die Cluster-IP-Adresse reagieren (dies kann die IP-Adresse des physischen Computers, oder die IP-Adresse der vom Computer gehosteten virtuellen Server sein). 2. In einer Standartumgebung kann der Rogue-Computer die IP-Adresse nur „übernehmen“, wenn der Clusterknoten oder der virtuelle Server nicht ausgeführt wird. 3. Der Rogue-Computer muss den Anschein erwecken, als ob er die Cluster-APIs zur Verfügung stelle. Bei einem typischen Verwaltungsvorgang führt die Clientanwendung mehrere Aufrufe an den Server durch und gibt in einigen Fällen Handles für nachfolgende Aufrufe zurück. 4. Der Administrator muss die Konfiguration sicherheitsrelevanter Daten ändern (beispielsweise das Kennwort für das Clusterkonto). Sinnvolle Verfahrensweisen Angriffe, die den Cluster gefährden, erfolgen normalerweise in dem Subnetz, in dem sich der Cluster befindet. Zum Schutz vor diesen Angriffen sollten die Subnetze gesichert werden. Netzwerke mit Clients Das von den Clusterknoten verwendete Subnetz sollte nur Knoten enthalten, die physikalisch gesichert wurden, oder denen vertraut werden kann. Sie müssen sicherstellen, dass Rogue- oder potenziell unsichere Computer nicht an das Subnetz der Cluster angeschlossen werden. Da dieses Netzwerk möglicherweise Domänencontroller, DNS-Server, WINS-Server, DHCP-Server und eine andere Netzwerkinfrastruktur enthält, müssen Sie mit entsprechenden Maßnahmen dafür sorgen, dass diese Infrastrukturserver ebenfalls sicher sind. Es sollten typische Netzwerksicherheitsverfahren implementiert werden, wie z. B. Firewalls, die nur bestimmte Anwendungsanforderungen zulassen. Die Thematik des Sicherns von Netzwerken und Infrastrukturservern würde den Umfang dieses Dokuments jedoch sprengen. Private Netzwerke In einem privaten Netzwerk sollten nur Knoten im Cluster sichtbar sein (mehrere Cluster können dasselbe private Netzwerk verwenden). Im privaten Subnetz sollten sich keine anderen Netzwerk-Infrastrukturserver oder anderen Anwendungsserver befinden. Dies kann auf zwei verschiedene Arten erreicht werden: Durch physikalisches Einschränken des Netzwerks (z. B. ist das private Netzwerk ein nur mit den Clusterknoten verbundenes LAN). Durch Isolieren der privaten Clusternetzwerke mit Hilfe von VLAN-fähigen Switches. NTLM V1 und NTLM V2 Windows 2000 Windows 2000-Cluster (bis einschließlich SP2) müssen die NTLM V1-Authentifizierung zwischen Clusterknoten verwenden. Es gibt mehrere Sicherungstools und Richtlinienvorlagen (z. B. HiSecDC), die unterschiedliche Richtlinien auf die Knoten anwenden und so NTLM V2 als Standardsicherheitsprofil erzwingen. Wenn diese Richtlinienvorlagen oder Tools auf einen Windows 2000-Cluster angewendet werden, schlägt der Clusterdienst fehl. Das Standardsicherheitsprofil muss auf LM- und NTLM-Antworten senden zurückgesetzt werden. Dieser Vorgang wird in den KB-Artikeln 295091 und 272129 näher erläutert (beide englischsprachig). Windows Server 2003 und Windows 2000 SP3 (oder höher) Unter Windows 2000 SP3 oder höher sowie unter Windows Server 2003 ist der Clusterdienst zur Verwendung von NTLM V2 fähig. Sicherheitsrichtlinien, die NTLM V2 aktivieren, gefährden den Cluster nicht. NetBIOS Die Sicherheit eines Systems ist abhängig von der Anzahl der Möglichkeiten, in das System zu gelangen. Unter Windows Server 2003 ist für den Clusterdienst kein NetBIOS erforderlich. Allerdings werden einige Dienste beeinträchtigt, wenn NetBIOS deaktiviert ist. Sie sollten folgende Punkte berücksichtigen: Bei der Konfiguration eines Clusters wird NetBIOS standardmäßig auf der Cluster-IPAdressressource aktiviert. Nach Erstellung des Clusters sollten Sie NetBIOS deaktivieren, indem Sie das Kontrollkästchen auf der Eigenschaftsseite für die Cluster-IP-Adressressource deaktivieren. Wenn Sie weitere IP-Adressressourcen erstellen, sollten Sie das Kontrollkästchen NetBIOS deaktivieren. Bei deaktiviertem NetBIOS können Sie die Durchsuchen-Funktion in der Clusterverwaltung nicht für die Verbindung mit einem Cluster verwenden. Die Clusterverwaltung listet mit Hilfe von NetBIOS alle Cluster in einer Domäne auf. Druck- und Dateidienste sind deaktiviert – es werden keine virtuellen Namen als Umleitungsendpunkte hinzugefügt. Die Clusterverwaltung funktioniert nicht, wenn ein Clustername angegeben wird. Die Clusterverwaltung ruft GetNodeClusterState auf, das die Remoteregistrierungs-APIs verwendet, die wiederum Named Pipes auf der Grundlage des virtuellen Namens verwenden. IPSec Obwohl IPSec (Internet Protocol Security) bei Anwendungen einsetzbar ist, für die in einem Servercluster ein Failover durchgeführt werden kann, wurde es nicht für Failover-Situationen konzipiert. Deshalb sollten Sie IPSec bei Anwendungen in einem Servercluster NICHT verwenden. Das Hauptproblem besteht darin, dass IKE SAs (Internet Key Exchange Security Associations) beim Auftreten eines Failovers nicht von einem Server zum anderen übertragen werden, weil sie in einer lokalen Datenbank auf jedem Knoten gespeichert sind. In einer durch IPSec geschützten Verbindung wird ein IKE SA in Aushandlungsphase-I erstellt. Zwei IPSec SAs werden in Phase II erstellt. Den IKE- und IPSec-SAs ist ein Zeitlimitwert zugeordnet. Wenn die Haupt-PFS (Perfect Forward Secrecy) nicht verwendet wird, werden die IPSec SAs unter Verwendung von Schlüsseldaten aus den IKE SAs erstellt. Falls dies zutrifft, muss der Client warten, bis die Standardzeitüberschreitung oder die Lebensdauer für die eingehende IPSec SA abgelaufen ist. Anschließend wartet er auf die der IKE SA zugeordnete Zeitüberschreitung oder Lebensdauer. Die Standardzeitüberschreitung für den Security Association-Leerlauf-Timer beträgt 5 Minuten. Bei einem Failover können Clients Verbindungen erst dann wiederherstellen, wenn mindestens 5 Minuten vergangen sind, nachdem alle Ressourcen mit Hilfe von IPSec online geschaltet wurden. Obwohl IPSec für eine Clusterumgebung nicht optimal ausgelegt ist, kann es verwendet werden, wenn Ihre Unternehmensanforderung für eine sichere Konnektivität die entstehende Clientausfallzeit bei einem Failover überwiegt. Clusterdatenträger Im Allgemeinen entsprechen Clusterdatenträger (d. h. Datenträger, die über eine entsprechende Ressource in der Clusterkonfiguration verfügen) anderen von Windows gehosteten Datenträgern. Es gibt jedoch einige zusätzliche Überlegungen, die Sie verstehen müssen: Allgemeine bewährte Methoden Der Clusterserver unterstützt auf Clusterdatenträgern nur das NTFS-Dateisystem. Damit wird sichergestellt, dass der Dateischutz für den Schutz der Daten auf den Clusterdatenträgern verwendet werden kann. Da bei Clusterdatenträgern ein Failover zwischen Knoten durchgeführt werden kann, dürfen Sie für den Schutz der Dateien nur Domänenbenutzerkonten (oder aber das lokale Systemkonto, das Netzwerkdienstkonto oder das lokale Dienstkonto) verwenden. Lokale Benutzerkonten auf einem bestimmten Computer haben auf anderen Computern im Cluster keine Bedeutung. Clusterdatenträger werden regelmäßig überprüft, um ihren einwandfreien Zustand sicherzustellen. Das Clusterdienstkonto MUSS über Schreibzugriff auf das Verzeichnis der obersten Ebene aller Clusterdatenträger verfügen. Wenn das Konto nicht über Schreibzugriff verfügt, wird der Datenträger möglicherweise als fehlerhaft deklariert. Quorumdatenträger Die Fehlerfreiheit des Quorumdatenträgers ist entscheidend für die Fehlerfreiheit des gesamten Clusters. Wenn der Quorumdatenträger ausfällt, steht der Clusterdienst auf keinem der Clusterknoten mehr zur Verfügung. Der Clusterdienst überprüft die Fehlerfreiheit des Quorumdatenträgers und handelt den exklusiven Zugriff auf das physische Laufwerk mit Hilfe von Standard-E/A-Vorgängen aus. Diese Vorgänge werden in der Warteschlange des Geräts eingereiht, zusammen mit allen anderen E/AVorgängen für das Gerät. Wenn die E/A-Vorgänge des Clusterdienstes durch besonders starken Datenverkehr verzögert werden, deklariert der Dienst den Quorumdatenträger als fehlerhaft und erzwingt eine Neugruppierung, um den Datenträger an einer anderen Stelle im Cluster wieder online zu schalten. Zum Schutz vor bösartigen Anwendungen, die den Quorumdatenträger mit E/A-Vorgängen überfluten, sollte dieser gesichert werden. Der Zugriff auf den Quorumdatenträger sollte auf die lokale Gruppe Administratoren und das Clusterdienstkonto beschränkt werden. Wenn der Quorumdatenträger voll wird, ist der Clusterdienst möglicherweise nicht mehr in der Lage, die erforderlichen Daten zu protokollieren. In diesem Fall fällt der Clusterdienst – eventuell auf allen Clusterknoten – aus. Zum Schutz vor bösartigen Anwendungen, die den Quorumdatenträger füllen, sollte der Zugriff auf die lokale Gruppe Administratoren und das Clusterdienstkonto beschränkt werden. Aus diesen beiden Gründen sollte der Quorumdatenträger NICHT zum Speichern anderer Anwendungsdaten verwendet werden. Clusterdatenträger Genauso wie der Quorumdatenträger werden andere Clusterdatenträger regelmäßig mit derselben Technik überprüft. Wenn bösartige Anwendungen die Datenträger für die Clusteranwendungen mit E/A-Vorgängen überfluten, kann der Clusterdienst möglicherweise nicht auf Fehlerfreiheit überprüft werden. Dies führt dazu, dass für den Datenträger (und alle davon abhängigen Anwendungen) ein Failover auf einen anderen Clusterknoten durchgeführt wird. Zur Vermeidung eines solchen Denial-ofService-Angriffs sollte der Zugriff auf die Clusterdatenträger auf diejenigen Anwendungen beschränkt werden, die Daten auf den spezifischen Datenträgern speichern. EFS und Servercluster Unter Windows Server 2003 wird EFS (Encrypting File System oder verschlüsselndes Dateisystem) auf Clusterdateifreigaben unterstützt. Zur Aktivierung von EFS auf einer Clusterdateifreigabe müssen Sie eine Reihe von Aufgaben ausführen, um die Umgebung korrekt zu konfigurieren: 1. EFS kann auf Dateifreigaben nur aktiviert werden, wenn Kerberos auf dem virtuellen Server aktiviert ist. Standardmäßig ist Kerberos auf einem virtuellen Server nicht aktiviert. Zum Aktivieren von Kerberos müssen Sie das Kontrollkästchen KerberosAuthentifizierung aktivieren derjenigen Netzwerknamenressource aktivieren, die zum Herstellen der Verbindung mit der Clusterdateifreigabe verwendet wird. Anmerkung: Die Aktivierung von Kerberos für einen Netzwerknamen hat verschiedene Konsequenzen, die Sie vollständig verstehen müssen, bevor Sie das Kontrollkästchen aktivieren. 2. Allen Computerkonten für den Clusterknoten und dem Computerkonto für den virtuellen Server muss für Delegierungszwecke vertraut werden können. Das hierzu erforderliche Verfahren wird in der Onlinehilfe beschrieben. 3. Um sicherzustellen, dass die privaten Schlüssel des Benutzers für alle Knoten im Cluster verfügbar sind, müssen Sie servergespeicherte Profile für die Benutzer aktivieren, die Daten mit Hilfe von EFS verschlüsseln möchten. Das erforderliche Verfahren zum Aktivieren von servergespeicherten Profilen wird in der Onlinehilfe beschrieben. Nachdem die Clusterdateifreigaben erstellt und die vorstehend erläuterten Konfigurationsschritte ausgeführt worden sind, können die Daten der Benutzer als zusätzliche Sicherheitsmaßnahme verschlüsselt werden. Verwalten von Dateifreigaben in einem Cluster Normale Dateifreigaben Normale Dateifreigaben sind im Hinblick auf Sicherheit am flexibelsten und am einfachsten zu verstehen. Der einzige Unterschied besteht darin, dass die Sicherheit auf Freigabeebene über die Benutzeroberfläche des Clusters statt über den Windows-Explorer verwaltet wird. Die NTFS-Sicherheitseinstellungen für Dateien auf den Clusterdatenträgern werden mit Hilfe der Windows-Standardprogramme wie dem Windows-Explorer verwaltet. Weitere Informationen zum Verwalten von Clusterdateifreigaben finden Sie in der Onlinedokumentation für Servercluster. Dateifreigaben, die über die Clusterverwaltung erstellt wurden, weisen den gleichen Standardschutz wie ein einzelner Knoten auf. Einziger Unterschied ist, dass die ACL mit Hilfe der Clusterverwaltungsprogramme festgelegt wird. Eine Beschreibung der StandardACL für eine Dateifreigabe finden Sie in der Dokumentation zu den Dateidiensten. Anmerkung: Verwenden Sie zum Ändern der Sicherheit bei einer Clusterdateifreigabe immer die Clusterverwaltungsprogramme. Wenn Sie das Verwaltungsprogramm für Dateifreigaben verwenden, geht eine vorhandene Konfiguration bei einem Failover der Freigabe auf einen anderen Clusterknoten verloren. Freigegebene Unterverzeichnisse Freigegebene Unterverzeichnisse sind in aktuelleren Windows-Versionen als Windows NT® 4.0 Service Pack 4 verfügbar. Sie ermöglichen Administratoren das schnelle Erstellen von Verzeichnissen zum Hosten einer großen Anzahl von Freigaben, z. B. Basisverzeichnissen, mit einer einzigen Clusterressource. Eine Stammfreigabe wird angegeben, und sämtliche Unterverzeichnisse eine Ebene unter dem angegebenen Stamm werden als reguläre Dateifreigaben erstellt. Es gibt keine Möglichkeit zur Angabe unterschiedlicher Sicherheitsattribute für jedes freigegebene Unterverzeichnis; deshalb erbt jede Freigabe die gleichen Berechtigungen auf Freigabeebene wie die Stammfreigabe. Weil jede Freigabe normalerweise von einem unterschiedlichen Benutzer verwendet wird, sollten die Berechtigungen auf Freigabeebene jedem einzeln überlassen bleiben. Über dateibasierte Sicherheit auf Dateisystemebene sollte gesteuert werden, wer auf welche Dateien zugreifen darf. DFS-Stämme DFS-Stämme sind seit Windows 2000 verfügbar. Servercluster unterstützen nur eigenständige DFS-Stämme als Clusterressourcen4. Sie können Berechtigungen auf Freigabeebene für den Stamm über die Benutzeroberfläche der Clusterverwaltung verwenden und jede Verknüpfung über Dateifreigabeberechtigungen auf dem entsprechenden Server verwalten. Diese Methode der Zugriffssteuerung kann jedoch bei DFS-Strukturen schwierig sein, die sich über zahlreiche Server und Verknüpfungen erstrecken. Es wird daher empfohlen, für die Verwaltung der DFS-Strukturen die Berechtigungen auf Dateifreigabeebene offen zu lassen und den Zugriff mit Hilfe von NTFS-Dateisystemberechtigungen einzuschränken. Clusterserverknoten als Domänencontroller Für das ordnungsgemäße Funktionieren von Serverclustern (wobei der Clusterdienst auf jedem Knoten gestartet wird) müssen die Knoten, aus denen der Cluster besteht, das Domänenkonto des Clusterdienstes überprüfen können. Dabei handelt es sich um das Konto, das bei der Konfiguration des Clusters konfiguriert wird. Zu diesem Zweck muss jeder Knoten in der Lage sein, einen sicheren Kanal mit einem Domänencontroller zur Überprüfung des Kontos einzurichten. Wenn das Konto nicht überprüft werden kann, wird der Clusterdienst nicht gestartet. Dies gilt auch für andere Clusterprogramme, bei denen das Konto überprüft werden muss, damit die Dienste, wie Microsoft SQL Server und Microsoft Exchange, gestartet werden können. Wenn es bei einer Clusterbereitstellung keine Verknüpfung mit einer Windows NT 4.0-, Windows 2000- oder Windows Server 2003-Domäne gibt, müssen Sie die Clusterknoten als Domänencontroller konfigurieren, damit das Clusterdienstkonto immer im Hinblick auf einwandfreie Clusterfunktionalität überprüft werden kann. Ist die Verknüpfung bei der Konnektivität zwischen Clusterknoten und Domänencontrollern entweder langsam oder unzuverlässig, erwägen Sie die Zusammenlegung eines Domänencontrollers mit dem Cluster, oder das Konfigurieren der Clusterknoten als Domänencontroller. Microsoft rät allerdings davon ab, Clusterknoten als Domänencontroller zu verwenden. Wenn Sie die Clusterknoten als Domänencontroller konfigurieren müssen, berücksichtigen Sie die folgenden wichtigen Hinweise: Wenn ein Clusterknoten in einem Cluster mit zwei Knoten ein Domänencontroller ist, müssen alle Knoten Domänencontroller sein. Es wird empfohlen, mindestens zwei der Knoten in einem Datacenter-Cluster mit vier Knoten als Domänencontroller zu konfigurieren. Mit der Ausführung eines Domänencontrollers ist ein Overhead verbunden. Ein Domänencontroller im Leerlauf kann zwischen 130 und 140 MB RAM verwenden, unter anderem für die Durchführung von Serverclustering. Außerdem kommt es zu Replikationsverkehr, wenn diese Domänencontroller eine Replikation mit anderen Domänencontrollern innerhalb der Domäne und domänenübergreifend durchführen müssen. Da die meisten Clustern Knoten in Unternehmen über Speicherkapazitäten im GB-Bereich verfügen, ist dies normalerweise kein Problem. Wenn die Windows 2000-Clusterknoten die einzigen Domänencontroller sind, müssen sie jeweils auch DNS-Server sein. Für die primäre DNS-Auflösung sollten sie aufeinander und für die sekundäre DNS-Auflösung auf sich selbst zeigen. Sie müssen das Problem einer möglichen Nicht-Registrierung der privaten Schnittstelle im DNS berücksichtigen – insbesondere, wenn deren Verbindung über ein Crossoverkabel hergestellt wird (nur bei 2 Knoten). Informationen zum Konfigurieren der Taktschnittstelle finden Sie im KB-Artikel 258750 (englischsprachig). Bevor Sie jedoch Schritt 12 in diesem KB-Artikel ausführen können, müssen Sie zunächst andere Konfigurationseinstellungen ändern. Diese werden im KB-Artikel 275554 (englischsprachig) beschrieben. Wenn die Clusterknoten die einzigen Domänencontroller sind, müssen sie jeweils globale Katalogserver sein, oder Sie müssen Domainlets implementieren. Weitere Informationen zum Implementieren von Domainlets finden Sie auf der folgenden englischsprachigen Microsoft-Webseite: http://www.microsoft.com/windows2000/techinfo/administration/cluster/domainlets.a sp Der erste Domänencontroller in der Gesamtstruktur übernimmt alle FSMOFunktionen (Flexible Single Master Operations). Informationen hierzu finden Sie im englischsprachigen KB-Artikel 192132. Sie können diese Funktionen an jeden Knoten verteilen. Wenn ein Knoten jedoch einen Failover durchführt, sind die von ihm übernommenen FSMO-Funktionen nicht mehr verfügbar. Sie können dann diesem Knoten die Funktionen mit Hilfe des Tools Ntdsutil zwangsweise entziehen und dem Knoten zuweisen, der weiterhin ausgeführt wird (Informationen hierzu finden Sie im KB-Artikel 223787 - englischsprachig). Informationen zur Platzierung von FSMOFunktionen in der gesamten Domäne finden Sie im KB-Artikel 223346 (englischsprachig). Wenn ein Domänencontroller so ausgelastet ist, dass der Clusterdienst nicht nach Bedarf auf das Quorumlaufwerk zugreifen kann, interpretiert der Dienst dies möglicherweise als Ressourcenfehler und bewirkt, dass die Clustergruppe einen Failover auf den anderen Knoten durchführt. Falls sich das Quorumlaufwerk in einer anderen Gruppe befindet (obwohl dies nicht so sein sollte) und so konfiguriert ist, dass es sich auf die Gruppe auswirkt, werden bei einem Ausfall sämtliche Gruppenressourcen auf den anderen Knoten verschoben. Dies ist nicht wünschenswert. Weitere Informationen zu Quorumkonfigurationen finden Sie im englischsprachigen KB-Artikel 280345 im Abschnitt Reference. Das Clustering anderer Programme, wie SQL Server 2000 oder Exchange 2000, in einem Szenario, in dem die Knoten auch Domänencontroller sind, erbringt aufgrund von Ressourceneinschränkungen möglicherweise nicht die optimale Leistung. Daher sollten Sie eine solche Konfiguration in einer Testumgebung gründlich prüfen, bevor Sie diese bereitstellen. Sie müssen einen Clusterknoten mit Hilfe des Tools Dcpromo zu einem Domänencontroller hochstufen, bevor Sie einen Servercluster erstellen oder einen Knoten zum Cluster hinzufügen (weitere Informationen hierzu finden Sie im englischsprachigen KB-Artikel 247720). Besonders vorsichtig müssen Sie beim Herabstufen eines Domänencontrollers zu einem Mitgliedsserver sein, der auch ein Clusterknoten ist. Wenn ein Knoten von einem Domänencontroller zu einem Mitgliedsserver herabgestuft wird, werden die Sicherheitseinstellungen und die Benutzerkonten radikal geändert (Benutzerkonten werden beispielsweise zu lokalen Konten herabgestuft). Informationen zum Herabstufen eines Domänencontrollers, der auch ein Clusterknoten ist, finden Sie im englischsprachigen KB-Artikel 247720. Allgemeine Ressourcen Die allgemeinen Ressourcentypen (Allgemeine Anwendung, Allgemeiner Dienst und Allgemeines Skript5) ermöglichen es, dass nicht clusterfähige Anwendungen mit geringem oder keinem Aufwand überwacht und ein Failover durchgeführt werden kann. Ein Dateinamenpfad wird zur Identifizierung der Anwendung bzw. des Skripts verwendet. Der Clusterdienst führt die Ressourcen-DLL unter dem Clusterdienstkonto aus; deshalb erfolgt die Ausführung mit höheren Berechtigungen (lokalen Administratorberechtigungen). Bei Verwendung einer allgemeinen Ressource sollten Sie sicherstellen, dass die Dateien, die den Code/das Skript und alle von dem Skript, der Anwendung oder dem Dienst verwendeten Registrierungsschlüssel enthalten, vor Angriffen geschützt sind. Allgemeines Skript Sorgen Sie mit Hilfe der NTFS-Dateisystemberechtigungen dafür, dass Skriptdateien sicher sind. Geben Sie den vollqualifizierten Pfad zum Skript an, um Spoofing-Probleme zu vermeiden, die mit der PATH-Variablen verbunden sind. Allgemeine Anwendung Stellen Sie sicher, dass der Anwendung vertraut wird und dass die Dateien, die mit Prüfpunkten zu protokollierenden Registrierungsschlüssel und alle anderen für die Ausführung der Anwendung erforderlichen Ressourcen sicher sind. Geben Sie den vollqualifizierten Pfad zur Anwendung an, um SpoofingProbleme zu vermeiden, die mit der PATH-Variablen verbunden sind. Allgemeiner Dienst Stellen Sie sicher, dass dem Dienst vertraut wird und dass alle Registrierungsschlüssel oder alle anderen für die Ausführung des Dienstes erforderlichen Ressourcen sicher sind. Anmerkung: Parameter und Konfigurationen für Windows-Dienste werden in der Registrierung normalerweise unter HKEY_LOCAL_MACHINE (HKLM) gespeichert. Im vorliegenden Dokument wird vorausgesetzt, dass diese Registrierungsstruktur vor Angriffen geschützt ist. Die Standardsicherheitsattribute der HKLM-Struktur sorgen für deren Sicherheit. Zusammenfassung der Sicherheitsattribute Dieser Abschnitt gibt einen Überblick über die verschiedenen Objekte und die zugehörigen Sicherheitsattribute, mit denen die erfolgreiche Ausführung des Clusterdienstes sichergestellt werden muss. Er führt die Mindestsicherheitsanforderungen auf. Wenn die Sicherheitsattribute restriktiver sind, wird der Clusterdienst möglicherweise nicht ausgeführt. Sind die Sicherheitsattribute weniger restriktiv, kann dies dazu führen, dass Angriffe den Cluster gefährden oder Endbenutzerdaten beschädigen. Daher wird empfohlen, die Sicherheitsattribute für die Objekte in den Standardeinstellungen nicht zu ändern. Verzeichnis- und Dateischutz Objekt %windir%\help Beschreibung Hilfedateien zum Cluster Clusterverzeichnis (und unterverzeichnisse) Empfohlene Mindestsicherheitsattribute BUILTIN\Users:R BUILTIN\Administrators:F %windir%\cluster BUILTIN\Administrators:F BUILTIN\Administrators:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F CREATOR OWNER:(OI)(CI)(IO)F %windir%\cluster\* Dateien im BUILTIN\Administrators:F Clusterverzeichnis NT AUTHORITY\SYSTEM:F <Quorumlaufwerk> Datenträger mit BUILTIN\Administrators:F Quorumdaten BUILTIN\Administrators:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F <Quorumlaufwerk>:\MSCS Quorumverzeichnis BUILTIN\Administrators:F (und BUILTIN\Administrators:(OI)(CI)(IO)F unterverzeichnisse) CREATOR OWNER:(OI)(CI)(IO)F <Quorumlaufwerk>:\MSCS\* Dateien im BUILTIN\Administrators:F Quorumverzeichnis Datenträger auf BUILTIN\Administrators:F Clusterdatenträgern BUILTIN\Administrators:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F Systemressourcen Der Clusterdienst verwendet andere Systemressourcen, die standardmäßig geschützt sind. Objekt HKLM\* Beschreibung Empfohlene Mindestsicherheitsattribute HKLMSYSTEM: Vollzugriff Registrierungsstruktur BUILTIN\Administrators: Vollzugriff Richtlinien für das Clusterdienstkonto Sorgen Sie dafür, dass das Kennwort nicht abläuft. Unter Windows Server 2003 können Sie mit Hilfe des Kennwortänderungsmechanismus sicherstellen, dass das Kennwort regelmäßig geändert wird. Verwenden Sie für das Clusterdienstkonto sichere Kennwörter. Active Directory Um sicherzustellen, dass die Kerberos-Authentifizierung erwartungsgemäß funktioniert, muss das Clusterdienstkonto Zugriff auf Active Directory haben. Dies wird im Abschnitt Verwenden der Kerberos-Authentifizierung in einem Servercluster behandelt. DNS Das Clusterdienstkonto muss Datensätze veröffentlichen können. In einer sicheren DNS-Zone kann der DNS-Administrator wählen, dass die Zugriffsrechte für Benutzer eingeschränkt werden sollen. Dem Clusterdienstkonto muss die Berechtigung zum Erstellen von Datensätzen erteilt werden. Als Alternative können die Datensätze vorbereitet werden. Wenn die Datensätze vorbereitet werden, sollten Sie für die Zone keine dynamische Aktualisierung festlegen. Überlegungen zum Hauptknotensatz Windows Server 2003 stellt eine neue quorumfähige Ressource namens „Hauptknotensatz“ bereit. Das primäre Ziel dieser Ressource besteht darin, mehrere Kopien von Daten, die über einen Cluster verteilt sind, ständig zu synchronisieren. Mit Hilfe des Hauptknotensatzes kann eine Quorumressource in einem Cluster bereitgestellt werden, ohne einen freigegebenen Datenträger für die Quorumdaten zu verwenden. Der Hauptknotensatz ist in erster Linie für folgende Szenarien vorgesehen: Geografisch verteilte Cluster – zum Bereitstellen eines einzelnen, allgemeinen Quorummechanismus für Clusterkonfigurationen mit mehreren Standorten. Sie sollen es Anbietern ermöglichen, Lösungen zu erstellen, ohne sich mit Quorumanforderungen befassen zu müssen. Cluster von Geräten – Gruppe von Standardcomputern, die über keine freigegebenen Datenträger mit Bindung an einen einzigen Cluster verfügen, der eine andere Replikationstechnik für Anwendungs- und/oder Benutzerdaten verwendet. In einem Hauptknotensatz-Cluster gibt es eine einzige Hauptknotensatz-Ressource. Sie ist für die Übertragung von Änderungen an die auf jedem Clusterknoten gespeicherten Quorumdaten verantwortlich. Jeder Clusterknoten verfügt über eine eigene Kopie der Daten. Für den Zugriff auf die Daten auf den anderen Knoten in einem Cluster (d. h. die Knoten außer demjenigen, auf dem die Ressource gehostet wird) verwendet die Hauptknotensatz-Ressource die Infrastruktur der Dateifreigabe. Beim Erstellen einer Hauptknotensatz-Ressource wird auf jedem Clusterknoten (sowie auf Knoten, die zum Cluster hinzugefügt werden) eine Dateifreigabe erstellt. Dabei handelt es sich um eine versteckte Dateifreigabe mit einem Namen im folgenden Format: \\<Knotenname>\<Ressourcen_GUID>$ Die Standardsicherheitseinstellung für die Dateifreigabe lautet: BUILTIN\Administrators:F (Diesen Ordner, Unterordner und Dateien) CREATOR OWNER:F (Nur Unterordner und Dateien) Um den einwandfreien Betrieb eines Hauptknotensatz-Clusters sicherzustellen, berücksichtigen Sie folgende Punkte: Löschen Sie die Dateifreigabe NICHT. Entfernen Sie das Clusterdienstkonto NICHT aus der Gruppe der Konten, die Zugriff auf die Freigabe haben. Ändern Sie die Standardzugriffssteuerungen für die Dateifreigabe NICHT. Das Dateifreigabeziel ist ein Ordner im Verzeichnis %windir%\Cluster\MSCS. Sie sollten die Standardzugriffsberechtigungen für die Dateien oder Verzeichnisse nicht ändern. Sie sollten niemals andere Dateien im MNS-Zielverzeichnis %windir%\Cluster\MSCS\MNS speichern. Falls Sie in diesem Verzeichnis andere Dateien speichern, werden diese beim Cleanup, dieser findet beim löschen der MNSRessource statt, gelöscht. Überlegungen zum Aktualisieren auf Windows Server 2003 Windows 2000 und Windows NT4 verfügen über Standardsicherheitsattribute für das Verzeichnis %windir%\Cluster und das Quorumverzeichnis, die jedem authentifizierten Benutzer das Lesen der Inhalte erlauben. Die Sicherheit der Verzeichnisse wurde in Windows Server 2003 verstärkt, um den Zugriff durch Nicht-Administratoren vollständig zu unterbinden und sicherzustellen, dass nicht autorisierte Benutzer keine Informationen zur Clusterkonfiguration erhalten können. Da diese Sicherheitsattribute bei einer Aktualisierung auf Windows Server 2003 jedoch nicht geändert werden, verfügen alle authentifizierten Benutzer eines aktualisierten Windows Server 2003-Computers möglicherweise weiterhin über Lesezugriff auf diese Verzeichnisse. Sie sollten eine manuelle Festlegung der Berechtigungen erwägen, damit diese den Mindestanforderungen entsprechen. Entwickeln von clusterfähigen Anwendungen Ressourcen-DLLs werden im Kontext des Clusterdienstkontos ausgeführt. Dieses Konto besitzt eine Reihe von erhöhten Berechtigungen und ist außerdem auf jedem Knoten im Cluster Mitglied der lokalen Gruppe Administratoren. Bei der Entwicklung einer clusterfähigen Anwendung sollten Sie überlegen, wie diese zwischen der Ressourcen-DLL und einem unabhängigen Dienst oder einer ausführbaren Datei am besten aufgeteilt werden kann. So können Sie ihre Ausführung mit den erforderlichen Mindestberechtigungen und rechten sicherzustellen. Wenn Anwendungen und Dienste mit nicht erforderlichen Berechtigungen ausgeführt werden, entsteht bei einer Gefährdung der Anwendung und Dienste ein potenzielles Sicherheitsrisiko. Aufrufen der Servercluster-APIs Die Servercluster-APIs sind geschützt. Daher können nicht vertrauenswürdige Benutzer den Status des Clusters oder die Verfügbarkeit von Anwendungen nicht beeinflussen. Der Clusterdienst verwaltet eine Sicherheitsbeschreibung zum Steuern des Zugriffs. Nur Konten, die in die Sicherheitsbeschreibung einbezogen sind, können Cluster-APIs aufrufen (tatsächlich steuert die Sicherheitsbeschreibung, welche Konten einen Handle zum Cluster öffnen können, da andere Clusterserver-APIs einen Handle erfordern. Auf diese Weise wird der Zugriff wirksam eingeschränkt). Bei diesem Mechanismus gibt es eine Vorsichtsmaßnahme. Der Clusterkonfigurationsmechanismus in Windows Server 2003 erfordert es, dass ein Benutzer, der einen Knoten zu einem Cluster hinzufügt, lokale Administratorrechte für jeden Knoten im Cluster besitzt. Wenn er diese Rechte für die vorhandenen Clusterknoten nicht besitzt, kann der Benutzer keinen neuen Knoten zum Cluster hinzufügen. Um einem Konto Administratorrechte für einen Cluster zu erteilen, sollten Sie: 1. Das Konto zur Sicherheitsbeschreibung für den Clusterdienst hinzufügen. 2. Sicherstellen, dass das Konto der lokalen Gruppe Administratoren auf ALLEN Computern im Cluster angehört. Diese Vorgänge können mit Hilfe der Cluster- und Sicherheits-APIs programmgesteuert erledigt werden. Weitere Einzelheiten hierzu finden Sie im Plattform SDK. Sicherheitsprüfungen werden von der OpenCluster-API durchgeführt. Wenn der Aufruf erfolgreich zurückgegeben wird, verfügt der Aufrufer über einen gültigen Handle und kann beliebige Änderungen an der Clusterkonfiguration vornehmen oder diese auflisten. Es gibt keine Anzeige für den „Lese-“ bzw. „Schreibzugriff“. Sichern/Wiederherstellen von APIs Der angegebene Sicherungspfad zur Sicherungs-API sollte geschützt werden. Die von der API zurückgegebenen Daten enthalten Informationen zur Clusterkonfiguration, die für einen Angriff verwendet werden können (z. B. Auflisten aller Cluster-IP-Adressen). Während eines Wiederherstellungsvorgangs übernimmt die Sicherungs-API die Clusterkonfiguration zum „Einfügen“ der Daten. Diese Daten müssen geschützt werden, da sie zum Wiederherstellen des Clusters durch Überschreiben aller momentan vorhandenen Konfigurationen verwendet werden. Installieren von Ressourcen Clusterfähige Anwendungen installieren möglicherweise Clusterressourcen. Beim Installieren von Ressourcen sollte vorsichtig vorgegangen werden, da die Ressourcen mit erhöhter Berechtigung ausgeführt werden. Deshalb müssen sie beim Installieren standardmäßig mit folgenden Maßnahmen vor Angriffen geschützt werden: Stellen Sie sicher, dass die Ressourcen-DLLs auf Dateisystemebene geschützt sind, damit nur der lokale Administrator und das Clusterdienstkonto darauf zugreifen können. Seien Sie äußerst vorsichtig bei allen Pfadangaben. Es gibt verschiedene bekannte Probleme bei Pfaden, insbesondere solchen, die Leerzeichen enthalten (folgen Sie hierzu den Empfehlungen auf Seite 419 von Writing Secure Code). Geben Sie im Zweifelsfall beim Erstellen des Ressourcentyps einen vollqualifizierten Pfad zur Ressourcen-DLL an. 1 Bei einem für MSMQ erforderlichen Netzwerknamen wird RequireKerberos standardmäßig aktiviert, um sicherzustellen, dass MSMQ nach Abschluss der Aktualisierung weiterhin in der erwarteten Weise funktioniert. 2 Alle Knoten in einem Cluster müssen sich in derselben NT- und DNS-Domäne befinden. 3 In einer Nur-Windows Server 2003-Domäne funktioniert dies erwartungsgemäß. 4 Dies bedeutet NICHT, dass Sie keine Domänenstämme auf Clusterknoten erstellen können, da ein Clusterknoten genauso wie jeder andere Server arbeitet; es handelt sich jedoch nicht um Clusterressourcen. 5 Ein allgemeines Skript ist nur unter Windows Server 2003 verfügbar. Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren. Dieses Dokument dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT. Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht. Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft eingeräumt. © 2002. Microsoft Corporation. Alle Rechte vorbehalten. Microsoft, SQL Server, Windows und Windows NT sind eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Die in diesem Dokument aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.
