Bewährte Methoden zum Schützen von Standortsystemen
Betrifft: System Center Configuration Manager 2007, System Center Configuration Manager 2007 R2, System Center Configuration Manager 2007 R3, System Center Configuration Manager 2007 SP1, System Center Configuration Manager 2007 SP2
Letzte Aktualisierung des Themas – November 2007
Microsoft System Center Configuration Manager 2007 verwendet eine Reihe von Standortsystemen mit speziellen Funktionen. Configuration Manager 2007-Clients interagieren mit Verwaltungspunkten. Verwaltungspunkte interagieren mit dem Standortserver und dem Configuration Manager 2007-Standortdatenbankserver. Clients benötigen möglicherweise einen Serverlocatorpunkt, um einen Verwaltungspunkt zu finden. Darüber hinaus sind für die Features, die Sie implementieren möchten, möglicherweise zusätzliche Standortsystemrollen erforderlich, darunter Standortsystemrollen im Umkreisnetzwerk zur Unterstützung der internetbasierten Clientverwaltung. Durch die Vielfalt der Standortsysteme wird die Angriffsfläche von Configuration Manager 2007 unvermeidlich im gesamten Unternehmen vergrößert. Fehler beim Sichern von Standortservern, Verwaltungspunkten und Standortdatenbankservern können einem Angreifer das Spoofing auf Standortsystemen und das Verteilen nicht autorisierter Software an Clients ermöglichen. Unzureichend geschützte Standortsysteme können auch den Standortserver gefährden. Um diese Bedrohung zu entschärfen, muss jedes Standortsystem einen möglichst umfassenden Schutz aufweisen.
Bewährte Methoden für alle Standortsysteme
Verwenden der Rollentrennung für Standortsysteme Es ist möglich, alle Standortsystemrollen auf einem einzelnen Computer zu installieren. Diese Vorgehensweise ist allerdings nicht empfehlenswert, weil damit ein einziger Fehlerpunkt erstellt wird. Es gibt allerdings einige wenige Ausnahmen vom Konzept der Rollentrennung. Generell sollte eine bestimmte Version von SQL Server auf demselben Computer wie der Standortserver installiert und dieser dann als Standortdatenbankserver verwendet werden. Diese Konfiguration ermöglicht Configuration Manager 2007 die größte Kontrolle über die Datenbankkonfiguration und vereinfacht die Sicherheitskonfiguration für SQL Server.
Verringern der Angriffsfläche Das Isolieren jeder Standortserverrolle auf einem anderen Server reduziert das Risiko, dass ein Angriff gegen Schwachstellen in einem Standortsystem auch auf ein anderes Standortsystem übertragen werden kann. Für viele Standortsystemrollen ist die Installation von Internetinformationsdiensten (IIS) auf dem Standortsystem erforderlich. Weitere Informationen finden Sie unter Voraussetzungen für die Configuration Manager-Installation. Das Installieren von IIS vergrößert die Angriffsfläche. Wenn Sie Standortsystemrollen aufgrund von Hardwareausgaben kombinieren müssen, sollten Sie Rollen, für die IIS erforderlich sind, nur mit anderen Rollen kombinieren, für die IIS ebenfalls erforderlich sind.
Wichtig
Eine Ausnahme zur Regel, nur Standortsystemrollen zu kombinieren, für die IIS erforderlich sind, bildet der Fallbackstatuspunkt. Die Fallbackstatuspunktrolle sollte nie einer anderen Configuration Manager 2007-Standortsystemrolle zugewiesen werden, da sie selbst im einheitlichen Modus nicht authentifizierte Daten von Clients akzeptiert.
Ausführen des Sicherheitskonfigurations-Assistenten auf allen Standortsystemen Mithilfe des Sicherheitskonfigurations-Assistenten (Security Configuration Wizard, SCW) können Sie eine Sicherheitsrichtlinie erstellen, die auf jedem beliebigen Server des Netzwerks angewendet werden kann. Nach dem Installieren der Configuration Manager 2007-Vorlage erkennt der Configuration Manager 2007-Sicherheitskonfigurations-Assistent (SCW) Serverrollen, Dienste, Anschlüsse und Anwendungen und lässt notwendigen Datenverkehr zu, blockiert jedoch Kommunikation, die als unnötig eingestuft wird. Es ist geplant, die Configuration Manager 2007-Vorlage für SCW im Configuration Manager 2007-Toolkit zu versenden (https://go.microsoft.com/fwlink/?LinkId=93071).
Verwenden von NTFS für alle Standortsysteme Obwohl einige Standortsysteme die Verwendung von FAT32-Partitionen zulassen, sollten Sie grundsätzlich NTFS verwenden, damit die Zugriffssteuerung auf Dateiebene möglich ist.
Kein Entfernen der Admin$-Freigabe auf Standortsystemen Die Admin$-Freigabe auf Standortsystemen ist für Configuration Manager 2007 erforderlich und sollte weder deaktiviert noch entfernt werden. Der Configuration Manager 2007-Standortserver verwendet die Admin$-Freigabe, um eine Verbindung mit Standortsystemen herzustellen und Dienstvorgänge auf diesen auszuführen.
Genaues Überwachen internetbasierter Standorteinstellungen auf Standortsystemen Die Configuration Manager 2007-Konsole lässt zu, dass eine Standortrolle zur Unterstützung internetbasierter Clients konfiguriert wird, auch wenn diese nicht als internetbasierte Standortrolle unterstützt wird. Nach dem Erstellen eines Zweigverteilungspunkts können Sie beispielsweise die Standortsystemeigenschaften für diese Rolle so konfigurieren, dass ein Internet-FQDN verwendet wird und Internetverbindungen zugelassen werden, obwohl die Unterstützung internetbasierter Clients durch Zweigverteilungspunkte nicht zulässig ist. Überwachen Sie die Internetkonfigurationen der Standortsysteme regelmäßig.
Konfigurieren von statischen IP-Adressen für Standortsysteme Statische IP-Adressen erleichtern die Konfiguration von IPsec zwischen Standortsystemen. Dies ist eine empfohlene bewährte Methode. Statische IP-Adressen können leichter vor Namensauflösungsangriffen geschützt werden.
Verwenden von FQDN-Servernamen Obwohl FQDN-Servernamen nur in bestimmten Szenarien erforderlich sind (z. B. zur Unterstützung der internetbasierten Clientverwaltung oder zur Verwendung von IPv6), sollten Sie FQDN-Servernamen für alle Standortsysteme konfigurieren, da bei der FQDN-Konfiguration DNS anstatt WINS für die Namensauflösung verwendet wird und DNS sicherer verwaltet werden kann als WINS. Weitere Informationen finden Sie unter Bestimmen, ob FQDN-Servernamen verwendet werden.
Keine anderen Dienste installieren, die das lokale Systemkonto verwenden Minimieren Sie die Nutzung des lokalen Systemkontos auf den Standortservern und -systemen, indem Sie keine anderen Dienste installieren, die das lokale Systemkonto verwenden. Hierdurch stellen Sie sicher, dass andere Prozesse die erweiterten Rechte des Systemcomputerkontos nicht nutzen und auf Configuration Manager 2007-Dateien und -Daten über diese anderen Systeme zugreifen können. Konfigurieren Sie SQL Server so, dass es unter einem Domänenbenutzerkonto ausgeführt wird anstatt unter dem lokalen Systemkonto.
Hinweis
IIS erfordern das lokale Systemkonto. Da jedoch viele Standortsystemrollen IIS benötigen, müssen IIS auf Standortsystemen installiert sein. Um das Risiko einer Manipulation von IIS durch einen Angreifer und der anschließenden Manipulation von Configuration Manager 2007-Servern über das lokale Systemkonto zu vermeiden, sollten Sie ausschließlich Configuration Manager 2007-Webanwendungen ausführen, und eine Rollentrennung für Standortsystemrollen verwenden, die IIS erfordern, wie später in diesem Abschnitt beschrieben.
Bewährte Methoden für Standortserver
Configuration Manager 2007 auf einem Mitgliedsserver anstatt auf einem Domänencontroller installieren Der Configuration Manager 2007-Standortserver und die Standortsysteme müssen nicht notwendigerweise auf einem Domänencontroller installiert werden. Domänencontroller verfügen neben der Domänendatenbank über keine andere lokale SAM-Datenbank (Security Accounts Management). Das Installieren von Configuration Manager 2007 auf einem Mitgliedsserver ermöglicht Ihnen die Wartung von Configuration Manager 2007-Konten in der lokalen SAM-Datenbank anstelle der Domänendatenbank. Außerdem wird die Angriffsfläche Ihrer Domänencontroller verringert.
Sekundäre Standorte auf dem sekundären Standortserver anstatt per Pushinstallation installieren Theoretisch kann ein Angreifer auf das Installationspaket des sekundären Standorts zugreifen und die darin enthaltenen Dateien vor der Installation manipulieren, obwohl das Timing eines solchen Angriffs schwierig wäre. Ein Angriff kann verhindert werden, indem IPsec vor dem Übertragen der Dateien zur gleichzeitigen Authentifizierung des primären und sekundären Standortservers verwendet wird. Bei Verwendung einer Pushinstallation muss das Computerkonto am primären Standort Mitglied der lokalen Gruppe „Administratoren“ des sekundären Standortservers sein. Diese Berechtigung ist für normale Vorgänge übertrieben.
Bewährte Methoden für SQL Server
Configuration Manager 2007 verwendet SQL Server als Back-End-Datenbank. Wenn die Datenbank kompromittiert ist, können Angreifer die Configuration Manager 2007-Konsole umgehen und direkt auf SQL Server zugreifen, um Angriffe über Configuration Manager 2007 zu starten. Angriffe auf SQL Server müssen als hochriskant angesehen und dementsprechend entschärft werden.
Verwenden dedizierter SQL Server-Computer für jeden Standort Mehrere Standorte können zum Speichern von Daten zwar denselben SQL Server-Computer verwenden, empfehlenswert ist diese Konfiguration allerdings nicht. Wenn eine Configuration Manager 2007-Standortdatenbank auf einem SQL Server-Computer kompromittiert wird, kann ein Angreifer leichter auf eine andere Configuration Manager 2007-Standortdatenbank auf demselben SQL Server-Computer zugreifen. Das Freigeben eines SQL Server-Computers zwischen Standorten erschwert möglicherweise die Wiederherstellung eines Standorts, wodurch die Funktionsfähigkeit von Configuration Manager 2007 zu einem kritischen Zeitpunkt verzögert werden kann. Wenn ein Standort einen Computer mit SQL Server gemeinsam mit einem anderen Standort nutzt und dabei Fehler auftreten, müssen Sie sicherstellen, dass der Wiederherstellungsvorgang für den fehlerhaften Standort sich nicht auf andere, fehlerfreie Standorte auswirkt. Ein Wiederherstellungsvorgang wird in dieser Situation komplizierter, da Sie die Wiederherstellungsschritte auf den ausgefallenen Standort beschränken müssen.
Den Configuration Manager-Standortdatenbankserver nicht zum Ausführen anderer SQL Server-Anwendungen verwenden Je mehr Zugriffsmöglichkeiten auf den Configuration Manager 2007-Standortdatenbankserver vorhanden sind, desto größer ist das Risiko für Ihre Configuration Manager 2007-Daten. Darüber hinaus sind auch andere Anwendungen auf demselben SQL Server-Computer einem Risiko ausgesetzt, wenn die Configuration Manager 2007-Standortdatenbank kompromittiert ist.
Konfigurieren von SQL Server zur Verwendung der Windows-Authentifizierung Configuration Manager 2007 verwendet grundsätzlich ein Windows-Konto und die Windows-Authentifizierung für den Zugriff auf die Standortdatenbank. SQL Server kann jedoch auch weiterhin für die Verwendung des gemischten Modus von SQL Server konfiguriert werden. Der gemischte Modus von SQL Server ermöglicht die Konfiguration zusätzlicher SQL-Anmeldungen für den Zugriff auf die Datenbank. Dies ist jedoch nicht erforderlich und vergrößert die Angriffsfläche.
Installieren von Configuration Manager und SQL Server auf demselben Computer Das Installieren von SQL Server und Configuration Manager 2007 auf demselben Computer scheint der Idee der Rollentrennung zum Steigern der Verfügbarkeit zuwiderzulaufen, stellt aber kein großes Sicherheitsrisiko dar. Wenn die Configuration Manager 2007-Standortdatenbank oder der Standortserver offline geschaltet werden, ist der andere Server praktisch nutzlos. Das Installieren von Configuration Manager 2007 und SQL Server auf demselben Computer vereinfacht die Konfiguration von SQL Server und reduziert damit das Risiko sicherheitsbezogener Fehler.
Befolgen der bewährten Sicherheitsmethoden für SQL Server Befolgen Sie die bewährten Methoden für SQL Server 2005 https://go.microsoft.com/fwlink/?LinkId=95071 (möglicherweise in englischer Sprache). Berücksichtigen Sie dabei aber zusätzlich Folgendes:
Das Computerkonto des Standortservers muss Mitglied der Administratorengruppe auf dem Computer sein, auf dem SQL Server ausgeführt wird. Wenn Sie der Empfehlung nachkommen, die Administratorprinzipale explizit bereitzustellen, muss das Konto, das zur Ausführung des Setups auf dem Standortserver verwendet wird, Mitglied der SQL-Benutzergruppe sein.
Wenn Sie SQL Server mit einem Domänenbenutzerkonto installieren, stellen Sie sicher, dass ein Dienstprinzipalname (SPN) an die Active Directory-Domänendienste weitergegeben wird. Andernfalls schlagen die Kerberos-Authentifizierung und das Configuration Manager 2007-Setup fehl. Weitere Informationen finden Sie unter Konfigurieren eines SPN für SQL Server-Standortdatenbankserver.
Bewährte Methoden für Standortsysteme, die IIS erfordern
Für einige Serverrollen sind IIS erforderlich. Ein umfassender Schutz von IIS ermöglicht den Betrieb von Configuration Manager 2007 bei gleichzeitiger Reduzierung des Risikos. Setzen Sie möglichst wenige Server ein, für die IIS erforderlich sind. Legen Sie zum Beispiel Verwaltungspunkte zu einer möglichst kleinen Anzahl zusammen. Verwenden Sie nur einen einzelnen Serverlocatorpunkt für die Umgebung.
Deaktivieren nicht erforderlicher IIS-Funktionen Installieren Sie nur die Mindestanzahl IIS-Features, die für die Unterstützung der verwendeten Serverrolle erforderlich sind. Weitere Informationen finden Sie unter Voraussetzungen für die Configuration Manager-Installation.
Den Standortserver nicht auf einem Computer mit IIS installieren Die Rollentrennung trägt zur Verringerung der Angriffsfläche bei und verbessert die Wiederherstellbarkeit. In der Regel verfügt das Computerkonto des Standortservers zudem über Administratorberechtigungen auf allen Standortsystemrollen (und möglicherweise auf Configuration Manager 2007-Clients, wenn die Clientpushinstallation verwendet wird). IIS und Configuration Manager 2007 werden über das lokale Systemkonto ausgeführt. Daher könnte sich ein Angreifer, der die auf dem Standortserver ausgeführten IIS kompromittieren kann, Zugriff auf alle Configuration Manager 2007-Funktionen des lokalen Systems verschaffen.
Verwenden dedizierter IIS-Server für Configuration Manager Es ist zwar möglich, mehrere webbasierte Anwendungen auf den von Configuration Manager 2007 verwendeten IIS-Servern zu hosten, dies kann jedoch die Angriffsfläche erheblich vergrößern. Eine unzureichend konfigurierte Anwendung kann dazu führen, dass ein Angreifer die Kontrolle über die Standortsysteme auf dem Standort und somit die Kontrolle über den gesamten Standort erhält. Wenn andere webbasierte Anwendungen auf Configuration Manager 2007-Standortsystemen ausgeführt werden müssen, sollte immer eine benutzerdefinierte Website für Configuration Manager 2007-Standortsysteme erstellt werden. Weitere Informationen finden Sie unter Konfigurieren von benutzerdefinierten Websites für Configuration Manager-Standorte.
Bewährte Methoden für Verwaltungspunkte
Immer einen separaten Verwaltungspunkt verwenden, wenn in einer Hierarchie mit einem einzelnen Standort die Authentifizierung eines vertrauenswürdigen Stammschlüssels erforderlich ist Wenn das Active Directory-Schema nicht erweitert wurde und Configuration Manager 2007 nicht zum Veröffentlichen in den Active Directory-Domänendiensten berechtigt ist, müssen Configuration Manager 2007-Clients vertrauenswürdige Stammschlüssel für die Authentifizierung von Verwaltungspunkten verwenden, bevor die Kommunikation gestartet wird. Der vertrauenswürdige Stammschlüssel am zentralen Standortserver wird zum Signieren des Verwaltungspunktzertifikats verwendet. Wenn der zentrale Standort wiederhergestellt werden muss, vertrauen Clients den Verwaltungspunkten so lange, bis bei der Wiederherstellung des zentralen Standortservers ein neuer vertrauenswürdiger Stammschlüssel generiert wird. Wenn ein Verwaltungspunkt wiederhergestellt werden muss, vertrauen Clients dem neuen Verwaltungspunkt, sobald die Verwaltungspunktzertifikate vom vertrauenswürdigen Stammschlüssel signiert werden. Wenn Clients jedoch einem zentralen Standortserver untergeordnet sind, der auch als Verwaltungspunkt für den Standort dient, und dieser Computer wiederhergestellt wird, vertrauen Clients diesem Verwaltungspunkt erst dann, wenn der aktuelle vertrauenswürdige Stammschlüssel auf den Clients gelöscht wird und der neue vertrauenswürdige Stammschlüssel bereitgestellt wird. Um dies zu vermeiden, erweitern Sie das Active Directory-Schema, und aktivieren Sie die Veröffentlichung für den Standort. Wenn dies nicht möglich ist, weisen Sie die Verwaltungspunktrolle nicht dem zentralen Standortserver zu, wenn dieser über untergeordnete Clients verfügt. Weitere Informationen zum vertrauenswürdigen Stammschlüssel finden Sie unter Informationen zum vertrauenswürdigen Stammschlüssel.
Den Standortserver zum Abrufen der Daten vom Standortsystem konfigurieren, wenn die Standortsystemrolle in einem Umkreisnetzwerk konfiguriert ist Standardmäßig übertragen Standortsysteme Daten mithilfe von Push zurück zum Standortserver. Ein Standortsystem kann so konfiguriert werden, dass stattdessen der Standortserver angewiesen wird, die Daten mithilfe von Pull zu übertragen. Dies ermöglicht eine bessere Kontrolle der für die Datenübertragung erforderlichen Ports und Berechtigungen. Die Einstellung Nur von Standortservern initiierte Datenübertragungen von diesem Standortsystem zulassen gilt für das gesamte Standortsystem und alle in ihm konfigurierten Standortsystemrollen.
Möglichst wenige Verwaltungspunkte verwenden Das Einrichten eines Verwaltungspunkts an jedem primären Standort stellt kein hohes Sicherheitsrisiko dar, eine Verringerung der Anzahl der Verwaltungspunkte verkleinert jedoch die Angriffsfläche. Verwaltungspunkte erfordern IIS. Um die Angriffsfläche ihrer Netzwerke zu reduzieren, haben einige Unternehmen Richtlinien zur Reduzierung der Anzahl von IIS-Servern. Wenn dies für Sie ein wichtiger Gesichtspunkt ist, können Sie die Anzahl der Verwaltungspunkte auf ein Minimum verringern, indem Sie alle Clients einem einzigen Standort zuweisen und sie als Roamingclients an den Standorten behandeln, an denen sie sich befinden.
Bewährte Methoden für den Fallbackstatuspunkt
Keine anderen Standortsystemrollen auf dem Computer mit dem Fallbackstatuspunkt installieren Der Fallbackstatuspunkt ist dafür vorgesehen, nicht authentifizierte Daten von jedem beliebigen Computer zuzulassen. Wenn auf dem Computer mit dem Fallbackstatuspunkt eine andere Standortrolle installiert wird, erhöht sich das Risiko für diese Standortrolle erheblich.
Den Fallbackstatuspunkt nicht auf einem Domänencontroller installieren
Im einheitlichen Modus den Fallbackstatuspunkt vor allen Clients bereitstellen Wenn ein Standort keinen Fallbackstatuspunkt hat, kann es zu einer Situation kommen, in der Sie sich nicht darüber im Klaren sind, dass aufgrund PKI-bezogener Zertifikatsprobleme eine hohe Anzahl von Clients nicht verwaltet ist. Wenn es beispielsweise ein Problem mit einem Clientzertifikat im einheitlichen Modus gibt, weist der Verwaltungspunkt im einheitlichen Modus die gesamte Kommunikation mit dem Client zurück, und der Client wird nicht verwaltet. Wenn jedoch der Client einem Fallbackstatuspunkt zugewiesen wird, meldet er erfolgreich seinen Kommunikationsfehler im einheitlichen Modus mit dem Fallbackstatuspunkt, da der Fallbackstatuspunkt keine PKI-Zertifikate verwendet. Fallbackstatuspunkte sind vorteilhaft sowohl für den einheitlichen als auch für den gemischten Modus, jedoch sind hohe Anzahlen von nicht verwalteten Clients im gemischten Modus weniger wahrscheinlich, da diese keine Abhängigkeit von PKI-Zertifikaten aufweisen, die extern von Configuration Manager verwaltet werden.
Die Verwendung des Fallbackstatuspunkts im Umkreisnetzwerk vermeiden Der Fallbackstatuspunkt lässt Daten von jedem beliebigen Client zu, was beabsichtigt ist. Durch das Platzieren des Fallbackstatuspunkts im Umkreisnetzwerk kann die Problembehandlung bei internetbasierten Clients erleichtert werden. Die Vorteile der Problembehandlung sollten jedoch gegen die Risiken abgewogen werden, die entstehen, wenn ein Standortsystem nicht authentifizierte Daten in einem öffentlich zugänglichen Netzwerk zulässt. Wenn Sie den Fallbackstatuspunkt im Umkreisnetzwerk oder einem anderen nicht vertrauenswürdigen Netzwerk platzieren müssen, konfigurieren Sie den Standortserver so, dass Daten mittels Pull vom Standortsystem übertragen werden, anstatt zuzulassen, dass der Fallbackstatuspunkt eine Verbindung zum Standortserver herstellt und Datenübertragungen initiiert. Wenn Sie den Standortserver für die Datenübertragung mittels Pull konfigurieren möchten, legen Sie Nur von Standortservern initiierte Datenübertragungen von diesem Standortsystem zulassen in den Eigenschaften des Standortsystems fest.
Bewährte Methoden für den Serverlocatorpunkt
Keinen Serverlocatorpunkt im Umkreisnetzwerk einrichten Wenn Clientcomputer im Umkreisnetzwerk für die Suche nach Configuration Manager 2007-Ressourcen benötigt werden, sollten diese Clients manuell mit dem Namen ihres Softwarelocatorpunkts konfiguriert werden.
Zusätzliche Ressourcen für sicherheitsbezogene bewährte Methoden
Informationen zum Schützen von Computern mit der Configuration Manager 2007-Konsole finden Sie unter Bewährte Sicherheitsmethoden und Datenschutzinformationen für die Configuration Manager-Konsole
Informationen zum Schützen von Verteilungspunkten und Zweigverteilungspunkten finden Sie unter Bewährte Sicherheitsmethoden und Datenschutzinformationen zur Softwareverteilung.
Informationen zum Schützen des PXE-Dienstpunkts und des Zustandsmigrationspunkts bei der Betriebssystembereitstellung finden Sie unter Bewährte Sicherheitsmethoden und Datenschutzinformationen zur Betriebssystembereitstellung.
Weitere Informationen zum Schützen von Berichterstattungspunkten finden Sie unter Bewährte Sicherheitsmethoden für die Berichterstattung.
Siehe auch
Andere Ressourcen
Bewährte Sicherheitsmethoden für Configuration Manager
Weitere Informationen finden Sie unter Configuration Manager 2007 – Informationen und Support (möglicherweise in englischer Sprache).
Das Dokumentationsteam erreichen Sie per E-Mail unter: SMSdocs@microsoft.com