Sicherheitsüberlegungen und Best Practices

Hinweis:

Ihre Organisation muss möglicherweise bestimmte Sicherheitsstandards erfüllen, um regulatorische Anforderungen zu erfüllen. Dieses Dokument behandelt dieses Thema nicht, da sich solche Sicherheitsstandards im Laufe der Zeit ändern. Aktuelle Informationen zu Sicherheitsstandards und Citrix-Produkten finden Sie im Citrix Trust Center.

Firewalls

Schützen Sie alle Maschinen in Ihrer Umgebung mit Perimeter-Firewalls, gegebenenfalls auch an Enklavengrenzen.

Alle Maschinen in Ihrer Umgebung müssen durch eine persönliche Firewall geschützt sein. Wenn Sie Kernkomponenten und VDAs installieren, können Sie festlegen, dass die für die Komponenten- und Feature-Kommunikation erforderlichen Ports automatisch geöffnet werden, wenn der Windows-Firewall-Dienst erkannt wird (auch wenn die Firewall nicht aktiviert ist). Sie können diese Firewall-Ports auch manuell konfigurieren. Wenn Sie eine andere Firewall verwenden, müssen Sie diese manuell konfigurieren. Weitere Informationen zu den erforderlichen Ports finden Sie unter Tech Paper: Communication Ports Used by Citrix Technologies.

Wenn Sie eine herkömmliche Umgebung auf diese Version migrieren, müssen Sie möglicherweise eine vorhandene Perimeter-Firewall neu positionieren oder neue Perimeter-Firewalls hinzufügen. Angenommen, es gibt eine Perimeter-Firewall zwischen einem herkömmlichen Client und einem Datenbankserver im Rechenzentrum. Bei Verwendung dieser Version muss diese Perimeter-Firewall so platziert werden, dass der virtuelle Desktop und das Benutzergerät auf der einen Seite und die Datenbankserver und Delivery Controller im Rechenzentrum auf der anderen Seite liegen. Erwägen Sie daher, eine Enklave in Ihrem Rechenzentrum zu erstellen, um die Datenbankserver und Controller aufzunehmen. Erwägen Sie auch einen Schutz zwischen dem Benutzergerät und dem virtuellen Desktop.

Hinweis:

Die TCP-Ports 1494 und 2598 werden für ICA und CGP verwendet und sind daher wahrscheinlich an Firewalls geöffnet, damit Benutzer außerhalb des Rechenzentrums darauf zugreifen können. Citrix empfiehlt, diese Ports nicht für andere Zwecke zu verwenden, um die Möglichkeit zu vermeiden, administrative Schnittstellen versehentlich für Angriffe offen zu lassen. Die Ports 1494 und 2598 sind offiziell bei der Internet Assigned Number Authority (http://www.iana.org/) registriert.

Sichere Kommunikation mit Delivery Controller™

Verschlüsselung der Kommunikation mit HTTPS

StoreFront und NetScaler Gateway kommunizieren mit dem XML-Dienst, der auf dem Delivery Controller läuft, über HTTP oder HTTPS. Je nach Konfiguration können VDAs über WebSocket mit dem Delivery Controller kommunizieren. Director kommuniziert mit den Überwachungsdaten über OData über HTTP oder HTTPS. Es wird empfohlen, HTTPS zu aktivieren und HTTP zu deaktivieren. Dies erfordert, dass Sie TLS auf Delivery Controllern aktivieren.

Sicherheitsschlüssel

Sie können Sicherheitsschlüssel verwenden, um sicherzustellen, dass nur autorisierte StoreFront- und NetScaler-Server über die Cloud-Connectors eine Verbindung zu DaaS herstellen können. Dies ist besonders wichtig, wenn Sie XML-Vertrauen aktiviert haben.

XML-Vertrauen

Standardmäßig muss StoreFront, wenn es sich für Aktionen wie die Enumeration und den Start mit dem Delivery Controller verbindet, die Active Directory-Anmeldeinformationen des Benutzers weiterleiten, damit DaaS den Benutzer authentifizieren und dessen Gruppenmitgliedschaft überprüfen kann. Bei der Verwendung anderer Authentifizierungsmethoden wie Domain-Pass-Through, Smartcards oder SAML verfügt StoreFront jedoch nicht über das Active Directory-Passwort. In diesem Fall müssen Sie „XML-Vertrauen“ aktivieren. Wenn XML-Vertrauen aktiviert ist, ermöglicht Citrix Virtual Apps and Desktops StoreFront, Aktionen im Namen eines Benutzers auszuführen, z. B. Anwendungen aufzulisten und zu starten, ohne das Passwort des Benutzers zu validieren. Bevor Sie XML-Vertrauen aktivieren, verwenden Sie Sicherheitsschlüssel oder einen anderen Mechanismus wie Firewalls oder IPsec, um sicherzustellen, dass nur vertrauenswürdige StoreFront-Server eine Verbindung zu den Delivery Controllern herstellen können.

Verwenden Sie das Citrix Virtual Apps and Desktops PowerShell SDK, um die XML-Vertrauenseinstellung zu überprüfen, zu aktivieren oder zu deaktivieren.

  • Um den aktuellen Wert der XML-Vertrauenseinstellung zu überprüfen, führen Sie Get-BrokerSite aus und überprüfen Sie den Wert von TrustRequestsSentToTheXMLServicePort.
  • Um XML-Vertrauen zu aktivieren oder zu deaktivieren, führen Sie Set-BrokerSite mit dem Parameter TrustRequestsSentToTheXmlServicePort aus.

Kommunikation zwischen VDA und Delivery Controller

Es gibt zwei Mechanismen für die Kommunikation von VDAs mit Controllern.

  • Windows Communication Foundation

    Der Nachrichtenebenenschutz von Windows Communication Foundation (WCF) sichert die Kommunikation zwischen dem Delivery Controller und dem VDA. Dadurch entfällt die Notwendigkeit eines zusätzlichen Transportebenen-Schutzes mittels TLS. Der Standardport für die Kommunikation zwischen VDA und Delivery Controller ist 80. Sie können den Port jedoch anpassen. Weitere Informationen finden Sie unter Anpassen eines VDA.

    Informationen zur Nachrichtensicherheit in WCF finden Sie in der Microsoft-Dokumentation Nachrichtensicherheit in WCF.

    Die WCF-Konfiguration verwendet Kerberos für die gegenseitige Authentifizierung zwischen Controller und VDA. Die Verschlüsselung verwendet AES im CBC-Modus mit einem 256-Bit-Schlüssel. Die Nachrichtenintegrität verwendet SHA-1.

    Laut Microsoft entsprechen die von WCF verwendeten Sicherheits-Protokolle den Standards von OASIS (Organization for the Advancement of Structured Information Standards), einschließlich WS-SecurityPolicy 1.2. Microsoft gibt außerdem an, dass WCF alle in Security Policy 1.2 aufgeführten Algorithmus-Suites unterstützt.

    Die Kommunikation zwischen Controller und VDA verwendet die basic256-Algorithmus-Suite, deren Algorithmen wie zuvor angegeben sind.

    Die WCF-Konfiguration verwendet das SOAP über HTTP-Protokoll zusammen mit der Nachrichtenebenen-Sicherheitsverschlüsselung.

  • WebSockets

    Dies ist der moderne Ersatz für WCF. Es bietet den Vorteil, dass für die Kommunikation vom VDA zum Delivery Controller nur der TLS-Port 443 benötigt wird. Es ist derzeit nur für MCS-bereitgestellte Maschinen verfügbar. Weitere Informationen finden Sie unter WebSocket-Kommunikation zwischen VDA und Delivery Controller.

Sichere Kommunikation zwischen Delivery Controller und Lizenzserver

Der Delivery Controller kommuniziert über HTTPS mit dem Lizenzserver. Standardmäßig wird ein selbstsigniertes Zertifikat verwendet, es wird jedoch empfohlen, dieses durch ein von einer Unternehmens- oder öffentlichen Zertifizierungsstelle ausgestelltes Zertifikat zu ersetzen. Weitere Informationen finden Sie unter Manuelles Installieren eines von Citrix Licensing Manager und Web Services for Licensing verwendeten Zertifikats.

Sichere Kommunikation zwischen Webbrowsern und Web Studio und Director

Web Studio und Director können auf derselben Maschine wie der Delivery Controller oder auf separaten Maschinen installiert werden. Benutzer verbinden sich über einen Webbrowser mit Web Studio und Director. Standardmäßig aktiviert Web Studio HTTPS mit einem selbstsignierten Zertifikat, während Director bei einer eigenständigen Installation HTTPS nicht konfiguriert. Es wird empfohlen, TLS für Web Studio und Director zu aktivieren, indem ein geeignetes Zertifikat verwendet wird.

Sichern der ICA®-Kommunikation

Citrix Virtual Apps and Desktops™ bietet verschiedene Optionen zur Sicherung des ICA-Datenverkehrs zwischen Client und VDA. Die folgenden Optionen stehen zur Verfügung:

  • Standardverschlüsselung: Die Standardeinstellung.
  • SecureICA: Ermöglicht die Verschlüsselung von Sitzungsdaten mithilfe der RC5 (128-Bit)-Verschlüsselung.
  • VDA TLS/DTLS: Ermöglicht die Verwendung von Verschlüsselung auf Netzwerkebene mithilfe von TLS/DTLS.

Standardverschlüsselung

Bei Verwendung der Standardverschlüsselung wird der Datenverkehr wie in der folgenden Abbildung gezeigt verschlüsselt.

Datenverkehrsverschlüsselung bei Verwendung der Standardverschlüsselung

SecureICA

Bei Verwendung von SecureICA wird der Datenverkehr wie in der folgenden Grafik dargestellt verschlüsselt.

Datenverkehrsverschlüsselung bei Verwendung von SecureICA

Weitere Informationen finden Sie unter Sicherheitsrichtlinieneinstellungen

Hinweis 1:

SecureICA wird nicht unterstützt, wenn die Workspace-App für HTML5 verwendet wird.

Hinweis 2:

Citrix SecureICA ist Teil des ICA/HDX-Protokolls, aber kein standardkonformes Netzwerksicherheitsprotokoll wie Transport Layer Security (TLS).

VDA TLS/DTLS

Bei Verwendung der VDA TLS/DTLS-Verschlüsselung wird der Datenverkehr wie in der folgenden Grafik dargestellt verschlüsselt.

Datenverkehrsverschlüsselung bei Verwendung von TLS/DTLS

Informationen zum Konfigurieren von VDA TLS/DTLS finden Sie unter TLS-Einstellungen auf VDAs.

Virtuelle Kanäle

Verwenden Sie die Zulassungsliste für virtuelle Kanäle, um zu steuern, welche virtuellen Kanäle, die nicht von Citrix stammen, in Ihrer Umgebung zugelassen sind.

Sichere Kommunikation mit dem Druckserver

Sie können TLS für TCP-basierte Verbindungen zwischen dem Virtual Delivery Agent (VDA) und dem Universal Print Server aktivieren. Weitere Informationen finden Sie unter Transport Layer Security (TLS) auf dem Universal Print Server.

Sichere Kommunikation mit der Sitedatenbank

Informationen zum Aktivieren von TLS für die Sitedatenbank finden Sie unter CTX137556.

VDA-Maschinensicherheit

Allgemeine Empfehlungen

Stellen Sie sicher, dass Ihre VDAs mit den neuesten Betriebssicherheitsupdates und Antivirenprogrammen auf dem neuesten Stand sind.

Anwendungssicherheit

Um zu verhindern, dass Nicht-Administratoren bösartige Aktionen ausführen, empfiehlt Citrix®, Windows AppLocker-Regeln für Installationsprogramme, Anwendungen, ausführbare Dateien und Skripte auf dem VDA-Host zu konfigurieren.

8.3-Dateinamen

Sie können 8.3-Dateinamen auf VDAs deaktivieren. Siehe Microsoft fsutil-Dokumentation.

Überlegungen zur Datenspeicherung

Ihre Desktopumgebung kann aus verschiedenen Arten von Desktops bestehen, z. B. gepoolten und dedizierten Desktops. Benutzer dürfen niemals Daten auf Desktops speichern, die von mehreren Benutzern gemeinsam genutzt werden, wie z. B. gepoolte Desktops. Wenn Benutzer Daten auf dedizierten Desktops speichern, müssen diese Daten entfernt werden, wenn der Desktop später anderen Benutzern zur Verfügung gestellt wird.

Benutzerkontenverwaltung

Wenden Sie die Windows-Best Practices für die Kontenverwaltung an. Erstellen Sie kein Konto auf einer Vorlage oder einem Image, bevor es von Machine Creation Services oder Provisioning Services dupliziert wird. Planen Sie keine Aufgaben mit gespeicherten privilegierten Domänenkonten. Erstellen Sie keine manuellen freigegebenen Active Directory-Computerkonten. Diese Praktiken helfen, zu verhindern, dass ein Maschinenangriff lokale persistente Kontokennwörter erhält und diese dann verwendet, um sich bei MCS/PVS-Freigabe-Images anderer Benutzer anzumelden.

Gewähren Sie Benutzern nur die benötigten Berechtigungen. Microsoft Windows-Berechtigungen werden weiterhin wie gewohnt auf Desktops angewendet: Konfigurieren Sie Berechtigungen über die Zuweisung von Benutzerrechten und Gruppenmitgliedschaften über Gruppenrichtlinien. Ein Vorteil dieser Version ist, dass es möglich ist, einem Benutzer administrative Rechte für einen Desktop zu gewähren, ohne ihm auch die physische Kontrolle über den Computer zu geben, auf dem der Desktop gespeichert ist.

Beachten Sie bei der Planung von Desktop-Berechtigungen Folgendes:

  • Standardmäßig sehen nicht-privilegierte Benutzer, wenn sie sich mit einem Desktop verbinden, die Zeitzone des Systems, auf dem der Desktop ausgeführt wird, anstatt der Zeitzone ihres eigenen Benutzergeräts. Informationen dazu, wie Benutzer ihre lokale Zeit bei der Verwendung von Desktops sehen können, finden Sie im Artikel „Bereitstellungsgruppen verwalten“.
  • Ein Benutzer, der Administrator eines Desktops ist, hat die volle Kontrolle über diesen Desktop. Wenn es sich bei einem Desktop um einen gepoolten Desktop und nicht um einen dedizierten Desktop handelt, muss dem Benutzer in Bezug auf alle anderen Benutzer dieses Desktops, einschließlich zukünftiger Benutzer, vertraut werden. Alle Benutzer des Desktops müssen sich des potenziellen dauerhaften Risikos für ihre Datensicherheit bewusst sein, das diese Situation birgt. Diese Überlegung gilt nicht für dedizierte Desktops, die nur einen einzigen Benutzer haben; dieser Benutzer sollte kein Administrator auf einem anderen Desktop sein.
  • Ein Benutzer, der Administrator eines Desktops ist, kann im Allgemeinen Software auf diesem Desktop installieren, einschließlich potenziell bösartiger Software. Der Benutzer kann auch potenziell den Datenverkehr in jedem mit dem Desktop verbundenen Netzwerk überwachen oder steuern.

Anmeldeberechtigungen verwalten

Anmeldeberechtigungen sind sowohl für Benutzerkonten als auch für Computerkonten erforderlich. Wie bei Microsoft Windows-Berechtigungen werden Anmeldeberechtigungen weiterhin auf die übliche Weise auf Desktops angewendet: Konfigurieren Sie Anmeldeberechtigungen über die Zuweisung von Benutzerrechten und Gruppenmitgliedschaften über die Gruppenrichtlinie.

Die Windows-Anmeldeberechtigungen sind: lokal anmelden, über Remotedesktopdienste anmelden, über das Netzwerk anmelden (auf diesen Computer vom Netzwerk aus zugreifen), als Batchauftrag anmelden und als Dienst anmelden.

Gewähren Sie Computerkonten nur die Anmeldeberechtigungen, die sie benötigen. Die Anmeldeberechtigung „Auf diesen Computer vom Netzwerk aus zugreifen“ ist für die Computerkonten von Delivery Controllern erforderlich.

Gewähren Sie Benutzerkonten nur die Anmeldeberechtigungen, die sie benötigen.

Laut Microsoft wird der Gruppe „Remotedesktopbenutzer“ standardmäßig die Anmeldeberechtigung „Anmeldung über Remotedesktopdienste zulassen“ gewährt (außer auf Domänencontrollern).

Die Sicherheitsrichtlinie Ihrer Organisation kann explizit festlegen, dass diese Gruppe von dieser Anmeldeberechtigung entfernt werden sollte. Berücksichtigen Sie den folgenden Ansatz:

  • Der Virtual Delivery Agent (VDA) für Multi-Session OS verwendet Microsoft Remotedesktopdienste. Sie können die Gruppe „Remotedesktopbenutzer“ als eingeschränkte Gruppe konfigurieren und die Mitgliedschaft der Gruppe über Active Directory-Gruppenrichtlinien steuern. Weitere Informationen finden Sie in der Microsoft-Dokumentation.
  • Für andere Komponenten von Citrix Virtual Apps and Desktops, einschließlich des VDA für Single-Session OS, ist die Gruppe „Remotedesktopbenutzer“ nicht erforderlich. Daher benötigt die Gruppe „Remotedesktopbenutzer“ für diese Komponenten die Anmeldeberechtigung „Anmeldung über Remotedesktopdienste zulassen“ nicht; Sie können sie entfernen. Zusätzlich:
    • Wenn Sie diese Computer über Remotedesktopdienste verwalten, stellen Sie sicher, dass alle diese Administratoren bereits Mitglieder der Administratorengruppe sind.
    • Wenn Sie diese Computer nicht über Remotedesktopdienste verwalten, sollten Sie die Remotedesktopdienste selbst auf diesen Computern deaktivieren.

Obwohl es möglich ist, Benutzer und Gruppen zur Anmeldeberechtigung „Anmeldung über Remotedesktopdienste verweigern“ hinzuzufügen, wird die Verwendung von verweigerten Anmeldeberechtigungen im Allgemeinen nicht empfohlen. Weitere Informationen finden Sie in der Microsoft-Dokumentation.

Sicherheit des Delivery Controllers

Windows-Dienste auf dem Delivery Controller

Die Installation des Delivery Controllers erstellt die folgenden Windows-Dienste:

  • Citrix AD Identity Service (NT SERVICE\CitrixADIdentityService): Verwaltet Microsoft Active Directory-Computerkonten für VMs.
  • Citrix Analytics (NT SERVICE\CitrixAnalytics): Erfasst Informationen zur Nutzung der Sitekonfiguration für Citrix, sofern diese Erfassung vom Siteadministrator genehmigt wurde. Diese Informationen werden dann an Citrix übermittelt, um die Produktverbesserung zu unterstützen.
  • Citrix App Library (NT SERVICE\CitrixAppLibrary): Unterstützt die Verwaltung und Bereitstellung von AppDisks, die AppDNA-Integration und die Verwaltung von App-V.
  • Citrix Broker Service (NT SERVICE\CitrixBrokerService): Wählt die virtuellen Desktops oder Anwendungen aus, die Benutzern zur Verfügung stehen.
  • Citrix Configuration Logging Service (NT SERVICE\CitrixConfigurationLogging): Zeichnet alle Konfigurationsänderungen und andere Statusänderungen auf, die von Administratoren an der Site vorgenommen wurden.
  • Citrix Configuration Service (NT SERVICE\CitrixConfigurationService): Site-weites Repository für freigegebene Konfigurationen.
  • Citrix Delegated Administration Service (NT SERVICE\CitrixDelegatedAdmin): Verwaltet die Administratoren erteilten Berechtigungen.
  • Citrix Environment Test Service (NT SERVICE\CitrixEnvTest): Verwaltet Selbsttests der anderen Delivery Controller-Dienste.
  • Citrix Host Service (NT SERVICE\CitrixHostService): Speichert Informationen über die in einer Citrix Virtual Apps- oder Citrix Virtual Desktops-Bereitstellung verwendeten Hypervisor-Infrastrukturen und bietet auch Funktionen, die von der Konsole zum Auflisten von Ressourcen in einem Hypervisor-Pool verwendet werden.
  • Citrix Machine Creation Services (NT SERVICE\CitrixMachineCreationService): Orchestriert die Erstellung von Desktop-VMs.
  • Citrix Monitor Service (NT SERVICE\CitrixMonitor): Erfasst Metriken für Citrix Virtual Apps oder Citrix Virtual Desktops, speichert historische Informationen und bietet eine Abfrageschnittstelle für Fehlerbehebungs- und Berichterstellungstools.
  • Citrix StoreFront Service (NT SERVICE\ CitrixStorefront): Unterstützt die Verwaltung von StoreFront. (Er ist nicht Teil der StoreFront-Komponente selbst.)
  • Citrix StoreFront Privileged Administration Service (NT SERVICE\CitrixPrivilegedService): Unterstützt privilegierte Verwaltungsoperationen von StoreFront. (Es ist nicht Teil der StoreFront-Komponente selbst.)
  • Citrix Config Synchronizer Service (NT SERVICE\CitrixConfigSyncService): Überträgt Konfigurationsdaten von der Haupt-Sitedatenbank an den lokalen Hostcache.
  • Citrix High Availability Service (NT SERVICE\CitrixHighAvailabilityService): Wählt die virtuellen Desktops oder Anwendungen aus, die Benutzern zur Verfügung stehen, wenn die Haupt-Sitedatenbank nicht verfügbar ist.

Die Installation des Delivery Controller erstellt auch die folgenden Windows-Dienste. Diese werden auch bei der Installation mit anderen Citrix-Komponenten erstellt:

  • Citrix Diagnostic Facility COM Server (NT SERVICE\CdfSvc): Unterstützt die Sammlung von Diagnoseinformationen zur Verwendung durch den Citrix Support.
  • Citrix Telemetry Service (NT SERVICE\CitrixTelemetryService): Sammelt Diagnoseinformationen zur Analyse durch Citrix, sodass die Analyseergebnisse und Empfehlungen von Administratoren eingesehen werden können, um Probleme mit der Site zu diagnostizieren.

Die Installation des Delivery Controller erstellt auch den folgenden Windows-Dienst. Dieser wird derzeit nicht verwendet. Falls er aktiviert wurde, deaktivieren Sie ihn.

  • Citrix Remote Broker Provider (NT SERVICE\XaXdCloudProxy)

Die Installation des Delivery Controller erstellt auch die folgenden Windows-Dienste. Diese werden derzeit nicht verwendet, müssen aber aktiviert sein. Deaktivieren Sie sie nicht.

  • Citrix Orchestration Service (NT SERVICE\CitrixOrchestration)
  • Citrix Trust Service (NT SERVICE\CitrixTrust)

Mit Ausnahme des Citrix StoreFront™ Privileged Administration Service erhalten diese Dienste das Anmelde-Recht „Als Dienst anmelden“ und die Berechtigungen „Arbeitsspeicher-Kontingente für einen Prozess anpassen“, „Sicherheitsüberwachungen generieren“ und „Prozess-Ebene-Token ersetzen“. Sie müssen diese Benutzerrechte nicht ändern. Diese Berechtigungen werden vom Delivery Controller nicht verwendet und automatisch deaktiviert.

Mit Ausnahme des Citrix StoreFront Privileged Administration Service und des Citrix Telemetry Service sind die zuvor aufgeführten Delivery Controller Windows-Dienste so konfiguriert, dass sie sich als Identität NETWORK SERVICE anmelden. Ändern Sie diese Dienst-Einstellungen nicht.

Der Citrix Config Synchronizer Service benötigt das NETWORK SERVICE-Konto, um zur Gruppe der lokalen Administratoren auf dem Delivery Controller zu gehören. Dies ermöglicht die korrekte Funktion des lokalen Hostcaches.

Der Citrix StoreFront Privileged Administration Service ist so konfiguriert, dass er sich als Lokales System (NT AUTHORITY\SYSTEM) anmeldet. Dies ist für Delivery Controller StoreFront-Operationen erforderlich, die normalerweise für Dienste nicht verfügbar sind (einschließlich der Erstellung von Microsoft IIS-Sites). Ändern Sie dessen Dienst-Einstellungen nicht.

Der Citrix Telemetry Service ist so konfiguriert, dass er sich mit einer eigenen dienstspezifischen Identität anmeldet.

Sie können den Citrix Telemetry Service deaktivieren. Abgesehen von diesem Dienst und bereits deaktivierten Diensten sollten Sie keinen der anderen Windows-Dienste des Delivery Controllers deaktivieren.

Anmelderechte verwalten

Die Computerkonten von VDAs müssen über das Anmelderecht „Zugriff auf diesen Computer vom Netzwerk aus“ verfügen. Siehe Active Directory OU-basierte Controller-Erkennung.

Clientzugriff

Der Clientzugriff wird normalerweise durch die Bereitstellung von Citrix StoreFront ermöglicht. Weitere Informationen zur Absicherung von StoreFront finden Sie in der StoreFront-Dokumentation.

Um Remotebenutzern eine sichere Verbindung zu StoreFront und den VDAs zu ermöglichen, stellen Sie ein NetScaler® Gateway bereit.

Citrix empfiehlt, dass Clients über die Citrix Workspace-App eine Verbindung zu StoreFront herstellen. Weitere Informationen finden Sie in den Sicherheitsabschnitten der Dokumentation für die Citrix Workspace-App für jedes Betriebssystem. Alternativ können Benutzer einen Webbrowser verwenden, um auf StoreFront zuzugreifen.

Erwägen Sie, Benutzern Thin Clients zur Verfügung zu stellen, bei denen Benutzer nur eingeschränkt andere Anwendungen als die Citrix Workspace™-App ausführen können. Wenn Geräte von Ihrer Organisation verwaltet werden, sollten Sie Richtlinien festlegen, um die Bereitstellung von Betriebssystem-Sicherheitsupdates und Antivirensoftware sicherzustellen. In vielen Fällen müssen Benutzer jedoch in der Lage sein, sich von nicht verwalteten Geräten außerhalb der Kontrolle Ihrer Organisation zu verbinden. Erwägen Sie die Verwendung der folgenden Funktionen:

  • Endpoint Analysis scannt Endpunkte nach Sicherheitsinformationen wie Betriebssystem und Antivirensoftware und verweigert Clients den Zugriff, die Ihre Sicherheitsanforderungen nicht erfüllen.
  • App Protection blockiert Keylogger und Bildschirmaufnahmen.

Umgebungen mit gemischten Versionen

Umgebungen mit gemischten Versionen, beispielsweise wenn die VDAs eine andere Version als der Delivery Controller haben, sind bei einigen Upgrades unvermeidlich. Befolgen Sie Best Practices und minimieren Sie die Zeit, in der Citrix-Komponenten unterschiedlicher Versionen koexistieren. In Umgebungen mit gemischten Versionen wird die Sicherheitsrichtlinie beispielsweise möglicherweise nicht einheitlich durchgesetzt.

Hinweis:

Dies ist typisch für andere Softwareprodukte. Die Verwendung einer früheren Version von Active Directory erzwingt die Gruppenrichtlinie mit späteren Windows-Versionen nur teilweise.

Das folgende Szenario beschreibt ein Sicherheitsproblem, das in einer bestimmten Citrix-Umgebung mit gemischten Versionen auftreten kann. Wenn Citrix Receiver 1.7 verwendet wird, um eine Verbindung zu einem virtuellen Desktop herzustellen, auf dem der VDA in XenApp and XenDesktop 7.6 Feature Pack 2 ausgeführt wird, ist die Richtlinieneinstellung Dateiübertragung zwischen Desktop und Client zulassen in der Site aktiviert, kann aber nicht von einem Delivery Controller deaktiviert werden, auf dem XenApp and XenDesktop 7.1 ausgeführt wird. Dieser erkennt die Richtlinieneinstellung nicht, da sie in einer späteren Produktversion veröffentlicht wurde. Diese Richtlinieneinstellung ermöglicht Benutzern das Hoch- und Herunterladen von Dateien auf ihren virtuellen Desktop, was das Sicherheitsproblem darstellt. Um dies zu umgehen, aktualisieren Sie den Delivery Controller (oder eine eigenständige Instanz von Studio) auf Version 7.6 Feature Pack 2 und verwenden Sie dann die Gruppenrichtlinie, um die Richtlinieneinstellung zu deaktivieren. Alternativ verwenden Sie die lokale Richtlinie auf allen betroffenen virtuellen Desktops.

Sicherheitsüberlegungen für Remote PC Access

Remote PC Access(/de-de/citrix-virtual-apps-desktops/2411/install-configure/remote-pc-access.html) implementiert die folgenden Sicherheitsfunktionen:

  • Die Verwendung von Smartcards wird unterstützt.
  • Wenn eine Remotesitzung verbunden ist, bleibt der Monitor des Büro-PCs leer.
  • Remote PC Access leitet alle Tastatur- und Mauseingaben an die Remotesitzung um, mit Ausnahme von STRG+ALT+ENTF und USB-fähigen Smartcards und biometrischen Geräten.
  • SmoothRoaming wird nur für einen einzelnen Benutzer unterstützt.
  • Wenn ein Benutzer eine Remotesitzung mit einem Büro-PC verbunden hat, kann nur dieser Benutzer den lokalen Zugriff auf den Büro-PC wieder aufnehmen. Um den lokalen Zugriff wieder aufzunehmen, drückt der Benutzer Strg-Alt-Entf auf dem lokalen PC und meldet sich dann mit denselben Anmeldeinformationen an, die von der Remotesitzung verwendet wurden. Der Benutzer kann den lokalen Zugriff auch durch Einstecken einer Smartcard oder durch Nutzung biometrischer Daten wieder aufnehmen, sofern Ihr System über eine entsprechende Integration eines Drittanbieter-Anmeldeinformationsanbieters verfügt. Dieses Standardverhalten kann durch Aktivieren der schnellen Benutzerumschaltung über Gruppenrichtlinienobjekte (GPOs) oder durch Bearbeiten der Registrierung außer Kraft gesetzt werden.

Hinweis:

Citrix empfiehlt, allgemeinen Sitzungsbenutzern keine VDA-Administratorrechte zuzuweisen.

Automatische Zuweisungen

Standardmäßig unterstützt Remote PC Access die automatische Zuweisung mehrerer Benutzer zu einem VDA. In XenDesktop 5.6 Feature Pack 1 können Administratoren dieses Verhalten mithilfe des PowerShell-Skripts RemotePCAccess.ps1 außer Kraft setzen. Diese Version verwendet einen Registrierungseintrag, um mehrere automatische Remote-PC-Zuweisungen zuzulassen oder zu verbieten. Diese Einstellung gilt für die gesamte Site.

Vorsicht:

Eine falsche Bearbeitung der Registrierung kann schwerwiegende Probleme verursachen, die eine Neuinstallation Ihres Betriebssystems erforderlich machen können. Citrix kann nicht garantieren, dass Probleme, die aus der falschen Verwendung des Registrierungs-Editors resultieren, behoben werden können. Verwenden Sie den Registrierungs-Editor auf eigenes Risiko. Sichern Sie die Registrierung unbedingt, bevor Sie sie bearbeiten.

So schränken Sie automatische Zuweisungen auf einen einzelnen Benutzer ein:

Auf jedem Controller im Site legen Sie den folgenden Registrierungseintrag fest:

HKEY\_LOCAL\_MACHINE\Software\Citrix|DesktopServer
Name: AllowMultipleRemotePCAssignments
Type: REG_DWORD
Data: 0 = Disable multiple user assignment, 1 = (Default) Enable multiple user assignment.

Wenn bereits Benutzerzuweisungen vorhanden sind, entfernen Sie diese mithilfe von SDK-Befehlen, damit der VDA anschließend für eine einzelne automatische Zuweisung infrage kommt.

  • Entfernen Sie alle zugewiesenen Benutzer vom VDA: $machine.AssociatedUserNames | %{ Remove-BrokerUser-Name $_ -Machine $machine
  • Entfernen Sie den VDA aus der Bereitstellungsgruppe: $machine | Remove-BrokerMachine -DesktopGroup $desktopGroup

Starten Sie den physischen Büro-PC neu.