Designmethodik Zugriffslayer

Der zweite Layer der Designmethodik ist der Zugriffslayer, der für jede Benutzergruppe definiert wird.

Das Erstellen eines geeigneten Designs für den Zugriffslayer ist ein wichtiger Bestandteil der Desktopvirtualisierung. Dieser Layer erledigt die Benutzervalidierung durch Authentifizierung und orchestriert den Zugriff auf alle Komponenten, die für die Einrichtung einer sicheren virtuellen Desktopverbindung erforderlich sind.

Die Entscheidungen bezüglich des Zugriffslayer-Designs hängen von den Mobilitätsanforderungen der einzelnen Benutzergruppen und den verwendeten Endgeräten ab.

Authentifizierung

Der Zugriff auf Ressourcen basiert auf der Identität des Benutzers. Bei der Wahl der Authentifizierungsstrategie wird der Einstiegspunkt des Benutzers in die Umgebung sowie die Art und Weise seiner Authentifizierung berücksichtigt.

Entscheidung: Authentifizierungsanbieter

Normalerweise benötigen Benutzer einen Active Directory-Benutzernamen und ein Kennwort, um Zugriff auf ihre XenApp- und XenDesktop-Ressourcen zu erhalten. Da in den meisten Organisationen Active Directory on premises bereitgestellt wurde, konnte diese Anforderung einfach erfüllt werden.

Organisationen nutzen die Dienste externer Auftragnehmer, sodass ein Konto für den Zugriff auf die Ressourcen von XenApp und XenDesktop benötigt wird. Einige Organisationen überlegen die Nutzung eines externen Identitätsanbieters (IdP) wie Azure Active Directory, Google, LinkedIn usw. anstatt ihres eigenen.

Durch die Implementierung des Citrix Verbundauthentifizierungsdiensts unterstützen XenApp und XenDesktop die Verwendung eines externen IdP. Ein Administrator kann einem Auftragnehmer die Nutzung seines Google-Kontos gestatten, um Zugriff auf seine genehmigten Anwendungen und Desktops zu erhalten, was das Onboarding vereinfacht.

Entscheidung: Authentifizierungspunkt

Bevor ein Benutzer eine Verbindung zu einer virtuellen Ressource herstellt, muss er sich authentifizieren. Der Ort der Authentifizierung hängt oft von den Mobilitätsanforderungen der Benutzergruppe ab, die bei der Benutzersegmentierung festgelegt wurden. In XenDesktop stehen zwei Authentifizierungspunkte zur Verfügung:

  • StoreFront: Citrix StoreFront bietet Authentifizierungs- und Ressourcenbereitstellungsdienste für Citrix Receiver; Sie können dann zentralisierte Unternehmensstores erstellen, die Desktops, Anwendungen und anderen Ressourcen bereitstellen.
  • NetScaler Gateway: NetScaler Gateway ist eine Appliance, die einen sicheren Anwendungszugriff und eine zielgenaue Steuerung auf Richtlinienbasis und Anwendungsebene für Anwendungen und Daten bietet und Benutzern die ortsunabhängige Arbeit gestattet.

In der folgenden Tabelle werden die geeigneten Authentifizierungspunkte je nach Mobilitätsanforderungen von Benutzergruppen aufgelistet:

Mobilitätsanforderungen Bevorzugter Authentifizierungspunkt
Lokal StoreFront
Lokales Roaming StoreFront
Remote NetScaler Gateway
Lokal NetScaler Gateway

Die Authentifizierung von Benutzergruppen, die remote oder per Mobilgerät arbeiten, kann bei Bedarf direkt in StoreFront erfolgen. Beispielsweise können DMZ-Sicherheitsrichtlinien den Zugriff vom NetScaler Gateway auf die Domäne unterbinden, die zur Unterstützung der Smartcard-Clientzertifikatauthentifizierung erforderlich ist. Der Zugriff auf StoreFront zur Authentifizierung kann dann über einen virtuellen NetScaler-Server (SSL_BRIDGE) bereitgestellt werden, der eine Leitung für den HTTPS-Datenverkehr bietet. Normalerweise wird ein solcher virtueller Server parallel zum NetScaler Gateway auf demselben NetScaler gehostet, der für den HDX-Proxyzugriff auf die virtuelle Desktopumgebung konfiguriert ist. Ein solcher Anwendungsfall kann zwar in Einzelfällen notwendig sein, es empfiehlt sich jedoch, externe Benutzer über NetScaler Gateway zu authentifizieren.

Entscheidung: Authentifizierungsrichtlinie

Nach dem Authentifizierungspunkt muss der Authentifizierungstyp festgelegt werden. Primär gibt es folgende Optionen:

  • StoreFront: Unterstützt verschiedene Authentifizierungsmethoden, die jedoch, abhängig von der Zugriffsmethode, Sicherheitsanforderungen und dem Netzwerkstandort des Benutzers, nicht alle empfohlen werden. Beachten Sie, dass StoreFront Benutzer standardmäßig direkt über Active Directory und nicht wie das Webinterface über XML authentifiziert. StoreFront 3.0 + kann optional so konfiguriert werden, dass die Authentifizierung an XML delegiert wird (z. B. wenn sich die StoreFront-Server in einer Domäne befinden, die den Benutzerdomänen nicht vertraut).
    • Benutzername und Kennwort: Die Benutzer müssen sich direkt bei der Site unter Eingabe eines Benutzernamens und eines Kennworts anmelden.
    • Domänen-Passthrough: Ermöglicht Passthrough für Domänenanmeldeinformationen von den Benutzergeräten. Benutzer authentifizieren sich bei den Windows-Computern, die der Domäne angehören, und werden beim Zugriff auf ihre Stores automatisch angemeldet.
    • Passthrough von NetScaler Gateway: Ermöglicht die Passthrough-Authentifizierung von NetScaler Gateway. Benutzer authentifizieren sich bei NetScaler Gateway und werden beim Zugriff auf ihre Stores automatisch angemeldet.
    • Smartcard: Ermöglicht die Authentifizierung mit Smartcard und PIN über Citrix Receiver für Windows und NetScaler Gateway. Zum Aktivieren der Smartcardauthentifizierung müssen Benutzerkonten entweder in der Microsoft Active Directory-Domäne der StoreFront-Server konfiguriert werden oder in einer Domäne, die über eine direkte bidirektionale Vertrauensstellung mit der StoreFront-Serverdomäne verfügt. Bereitstellungen mit mehreren Gesamtstrukturen mit unidirektionalen Vertrauensstellungen oder Vertrauensstellungen anderen Typs werden nicht unterstützt.
    • Anonym: Ermöglicht Zugriff auf Anwendungen und Desktops, ohne dass die Benutzer Anmeldeinformationen in StoreFront oder Citrix Receiver eingeben müssen. Lokale anonyme Konten werden on-demand auf dem Server-VDA erstellt, wenn Sitzungen gestartet werden. Dies erfordert einen für den nicht authentifizierten Zugriff konfigurierten StoreFront-Store, einen Serverbetriebssystem-VDA und eine XenApp-Bereitstellungsgruppe, die für nicht authentifizierte Benutzer konfiguriert ist.
  • NetScaler Gateway: NetScaler Gateway unterstützt mehrere Authentifizierungsmethoden. Die nachfolgende Liste enthält diejenigen, die hauptsächlich in virtuellen Desktopumgebungen verwendet werden. Jede kann allein verwendet werden, sie werden jedoch oft kombiniert, um eine mehrstufige Authentifizierung bereitzustellen.
    • LDAP: Lightweight Directory Access Protocol (LDAP) wird für den Zugriff auf Verzeichnisinformationsdienste wie Microsoft Active Directory verwendet. NetScaler Gateway verwendet LDAP, um Benutzer zu authentifizieren und ihre Gruppenmitgliedschaftsinformationen zu extrahieren.
    • RADIUS (Token): Remote Authentication Dial in User Service (RADIUS) ist ein UDP-basiertes Netzwerksicherheitsprotokoll, das Authentifizierung, Autorisierung und Kontoführung bereitstellt. Ein Netzwerkzugriffsserver (in diesem Fall NetScaler Gateway) leitet Anmeldeinformationen an einen RADIUS-Server weiter, der diese lokal oder in einem Verzeichnisdienst überprüfen kann. Der RADIUS-Server kann die Verbindung annehmen oder ablehnen oder eine zweite Authentifizierungsart, etwa ein Token, anfordern.
    • Clientzertifikat: Benutzer, die sich an einem virtuellen NetScaler Gateway-Server anmelden, können auch anhand der Attribute eines Clientzertifikats authentifiziert werden, das dem virtuellen Server präsentiert wird. Clientzertifikate werden in der Regel an Benutzer in Form von Smartcards oder Common Access Cards (CACs) verteilt, die von einem an das Gerät des Benutzers angeschlossenen Lesegerät gelesen werden.

Bei der Wahl des Authentifizierungstyps für eine Benutzergruppe werden neben dem Authentifizierungspunkt auch häufig Sicherheitsanforderungen berücksichtigt. Die folgende Tabelle hilft bei der Findung der geeigneten Lösung für jede Benutzergruppe auf Grundlage der erforderlichen Sicherheitsstufe:

Authentifizierungspunkt Erforderliches Sicherheitsniveau Authentifizierungstyp
StoreFront Niedrig, Mittel, Hoch Niedrig: LDAP-Benutzername und Kennwort; Pass-Through Mittel: LDAP-Benutzername und Kennwort; Pass-Through Hoch: LDAP und/oder Smartcard
NetScaler Gateway Niedrig, Mittel, Hoch Niedrig: LDAP-Benutzername und Kennwort Mittel: LDAP-Benutzername und Kennwort Hoch: LDAP und Token; LDAP und Smartcard; Token und Smartcard

Praxiserfahrung

  • Einzelhandel: Ein kleines Einzelhandelsunternehmen bietet Benutzern virtueller Desktops Zugriff auf nicht sensible Daten (z. B. Marketingkataloge, E-Mail). Es ist nicht verpflichtet, Sicherheitsvorschriften wie Sarbanes Oxley einzuhalten. Daher wurde eine LDAP-Authentifizierung mit Benutzernamen und Kennwort implementiert.
  • Finanzinstitut: Ein mittelständisches Finanzinstitut bietet Benutzern virtueller Desktops Zugriff auf Transaktionsdatensätze und andere vertrauliche Daten. Es muss gesetzliche Sicherheitsvorschriften erfüllen (z. B. SAS 70) und eine mehrstufige Authentifizierung für Benutzer implementieren, die eine Remote-Verbindung herstellen. Die LDAP-Authentifizierung mit Benutzernamen und Kennwort sowie RADIUS-Authentifizierung mithilfe von Token wurden implementiert.
  • Behörde: Eine große Behörde bietet Benutzern virtueller Desktops Zugriff auf streng vertrauliche Daten, z. B. persönliche Daten von Bürgern. Sie unterliegen z. B. der Regulierung durch die Sicherheitsstandards des US-Verteidigungsministeriums (DOD). Die LDAP-Authentifizierung mit Benutzernamen und Kennwort sowie Clientzertifikatauthentifizierung mit von CAC-Karten wurden implementiert.
  • Gesundheitswesen: Ein Krankenhaus stellt Benutzern eine EMR-Anwendung über XenApp bereit. ThinClient-Geräte auf stationären und mobilen Wagen werden von Ärzten und Pflegepersonal zum Erfassen und Abrufen von Patientendaten verwendet. Es wurde nicht authentifizierter Zugriff konfiguriert, damit sich das Personal nicht bei der Domäne und der EMR-Anwendung authentifizieren muss.

StoreFront

Citrix StoreFront authentifiziert Benutzer bei XenApp- und XenDesktop-Ressourcen. StoreFront enumeriert und aggregiert verfügbare Desktops und Anwendungen in einer einzigen Schnittstelle, auf die Benutzer über Citrix Receiver für Windows, iOS, Android oder über die StoreFront-Website zugreifen.

Entscheidung: hohe Verfügbarkeit

Ist der Server, auf dem StoreFront gehostet wird, nicht verfügbar, können die Benutzer keine neuen virtuellen Desktops oder veröffentlichte Anwendungen starten oder ihre Abonnements verwalten. Daher sollten mindestens zwei StoreFront-Server bereitgestellt werden, damit diese Komponente keine einzelne Schwachstelle darstellt. Durch die Implementierung einer Lastausgleichslösung erleben die Benutzer keine Dienstunterbrechung. Es gibt folgende Optionen:

  • Hardwarelastausgleich: Eine intelligente Appliance, die die Verfügbarkeit des StoreFront-Diensts überprüft und einen aktiven Lastausgleich für Benutzeranfragen durchführt. Citrix NetScaler ist ein gutes Beispiel für einen Hardware-Load Balancer. Citrix NetScaler wird mit StoreFront-Integritätsprüfungen vorkonfiguriert geliefert und ist der ideale Load Balancer.
  • DNS-Roundrobin: Bietet einen rudimentären Lastausgleich über mehrere Server, ohne dass die Verfügbarkeit überprüft wird. Fällt ein StoreFront-Server aus, leitet das DNS-Roundrobin die Benutzer weiterhin an diesen weiter. Aus diesem Grund wird DNS-Roundrobin von Citrix nicht empfohlen.
  • Windows-Netzwerklastausgleich: Windows-Dienst, der eine rudimentäre Prüfung der Serververfügbarkeit durchführen, jedoch den Status einzelner Dienste nicht ermitteln kann. Dies kann dazu führen, dass Benutzer an StoreFront-Server weitergeleitet werden, die keine neuen Anforderungen verarbeiten können. Ein solcher Benutzer kann dann nicht auf Anwendungen oder Desktops zugreifen.

Entscheidung: Verweis auf Delivery Controller

Um Benutzern Desktops und Anwendungen zur Verfügung zu stellen, muss StoreFront mit der IP-Adresse oder dem DNS-Namen von mindestens einem Controller pro XenDesktop- und XenApp-Site konfiguriert werden. Zur Gewährleistung von Fehlertoleranz sollten für jede Site und/oder jede Farm mehrere Controller eingegeben werden. Standardmäßig verarbeitet StoreFront eine Liste von Servern in der Failoverreihenfolge (aktiv/passiv).

In großen Bereitstellungen oder Umgebungen mit hoher Anmeldelast wird eine aktive Verteilung der Benutzerlast (aktiv/aktiv) empfohlen. Dies kann durch einen Load Balancer mit integrierten XML-Monitoren wie Citrix NetScaler erreicht werden oder indem StoreFront so konfiguriert wird, dass es unter den Controllern einen Lastausgleich ausführt, statt sie als Liste mit fester Reihenfolge zu behandeln.

Entscheidung: Beacons

Citrix Receiver verwendet Beacons (Websites), um festzustellen, ob ein Benutzer mit einem internen oder externen Netzwerk verbunden ist. Interne Benutzer werden zur Authentifizierung direkt mit StoreFront verbunden, externe Benutzer über Citrix NetScaler Gateway. Was für einen Benutzer angezeigt wird, kann über eine Einschränkung der Anwendungen auf der Basis des Beacons, über den er Zugriff hat, gesteuert werden.

Der interne Beacon muss eine Site sein, die nicht extern aufgelöst werden kann. Standardmäßig ist der interne Beacon die StoreFront-Basis-URL. Dies muss angepasst werden, wenn die gleiche externe und interne URL konfiguriert ist. Der externe Beacon kann jede externe Site sein, die eine HTTP-Antwort erzeugt. Citrix Receiver überwacht kontinuierlich den Status von Netzwerkverbindungen (z. B. Verbindung steht, Verbindung unterbrochen oder Wechsel des Standardgateways). Wird eine Statusänderung erkannt, überprüft Citrix Receiver zunächst, ob auf die internen Beaconpunkte zugegriffen werden kann, und dann, ob Zugriff auf externe Beaconpunkte möglich ist. StoreFront übergibt die HTTP(S)-Adressen der Beaconpunkte beim Download während der ersten Verbindung/Konfiguration an Citrix Receiver und meldet bei Bedarf Updates. Es müssen mindestens zwei hoch verfügbare externe Beacons angegeben werden, die von öffentlichen Netzwerken aufgelöst werden können.

Entscheidung: Präsentation der Ressourcen

Standardmäßig können Benutzer in StoreFront die Ressourcen auswählen (abonnieren), die sie regelmäßig verwenden möchten, nachdem sie sich angemeldet haben (Favoriten). Dieser “Self-Service” ermöglicht es, die Ressourcen auf dem Homebildschirm auf diejenigen zu beschränken, die regelmäßig verwendet werden. Die von den einzelnen Benutzern für die einzelnen Stores ausgewählten Ressourcen werden vom Abonnementdienst aufgezeichnet und lokal auf jedem StoreFront-Server gespeichert (unter automatischer Synchronisierung zwischen den Servern einer Servergruppe), sodass sie auf dem Citrix Receiver-Homebildschirm jedes Geräts angezeigt werden können, über das der Benutzer zugreift. Abonnements gelten zwar standardmäßig pro Store und pro Servergruppe, Administratoren können allerdings, falls erforderlich, zwei Stores in einer Servergruppe zur gemeinsamen Nutzung einer Abonnementdatenbank konfigurieren und/oder Abonnements zwischen zwei Stores mit identischen Namen in zwei separaten Servergruppen nach einem festgelegten Zeitplan synchronisieren.

Die Administratoren sollten bestimmen, welche Anwendungen immer auf dem Homebildschirm oder auf der Highlights-Registerkarte angezeigt werden sollen. Das sind im Allgemeinen gängige Anwendungen wie Microsoft Office sowie alle anderen, die jeder Benutzer in einer Umgebung ggf. benötigt. StoreFront kann diese Ressourcen anhand von Schlüsselwörtern filtern/präsentieren, die im Beschreibungsfeld der Eigenschaften der veröffentlichten Anwendung definiert sind.

In der folgenden Tabelle werden die Optionen der Schlüsselwörter aufgeführt:

Schlüsselwort Beschreibung
Automatisch Abonniert die Anwendung automatisch für alle Benutzer eines Stores. Wenn Benutzer sich an dem Store anmelden, wird die Anwendung automatisch bereitgestellt, ohne dass die Benutzer sie manuell abonnieren müssen. Die Benutzer können dieses Abonnement, falls gewünscht, nachträglich entfernen.
Mandatory Dieses in StoreFront 2.5 neue Schlüsselwort abonniert Anwendungen automatisch für die Benutzer eines Stores. Die Benutzer können die Anwendung jedoch nicht entfernen. Diese Einstellung ist nützlich, wenn Sie einen Satz von Anwendungen erstellen, die immer allen Benutzern präsentiert werden müssen.
Featured Anwendungen werden den Benutzern angekündigt bzw. häufig verwendete Anwendungen werden leichter gefunden, indem Sie sie in der Receiver-Liste “Highlights” aufgeführt werden.
Prefer Eine lokal installierte Anwendung soll statt einer in Receiver verfügbaren Anwendung verwendet werden. Receiver sucht nach dem angegebenen Namen/Pfad, um festzustellen, ob die Anwendung lokal installiert ist. Wenn dies der Fall ist, abonniert Receiver die Anwendung und erstellt keine Verknüpfung. Wenn der Benutzer die Anwendung vom Receiver-Fenster aus startet, startet Receiver die lokal installierte (bevorzugte) Anwendung. Wenn ein Benutzer eine bevorzugte Anwendung außerhalb von Receiver deinstalliert, wird das Abonnement für die Anwendung bei der nächsten Receiver-Aktualisierung gekündigt. Wenn ein Benutzer eine bevorzugte Anwendung vom Receiver-Fenster deinstalliert, kündigt Receiver das Anwendungsabonnement; die Anwendung wird jedoch nicht deinstalliert.
TreatAsApp Standardmäßig werden freigegebene, von der XenDesktop-VDI und XenApp gehostete Desktops von Receiver für Web-Sites wie andere Desktops behandelt. Mit dem Schlüsselwort “TreatAsApp” wird ein Desktop in den Anwendungsansichten von Receiver für Web-Sites und nicht in den Desktopansichten angezeigt. Die Benutzer können erst nach einem Abonnement auf den Desktop zugreifen.
Primary In einer Bereitstellung mit mehreren Sites stellt die Verwendung dieses Schlüsselworts sicher, dass eine Anwendung von einer bestimmten Site bereitgestellt wird. Wenn eine Anwendung aus mehreren Sites mit demselben Namen verfügbar ist, wird sie aus der sekundären Site nur angezeigt, wenn sie nicht über die primäre Site verfügbar ist.
Secondary Eine Eigenschaft wie “Primary”, die jedoch eine Anwendung zur Anwendung einer sekundären Site festlegt.

Entscheidung: Aggregationsgruppen

Wenn die XenApp/XenDesktop-Lösung mehrere Bereitstellungssites enthält, führt StoreFront die verfügbaren Ressourcen für die Benutzer zu einer einzigen Schnittstelle für alle veröffentlichten Ressourcen zusammen. Wenn jedoch mehrere Sites die gleichen Ressourcen veröffentlichen, werden dem Benutzer möglicherweise einzelne Anwendungen mehrmals angezeigt.

Abbildung: Benutzererfahrung ohne Aggregation

Über StoreFront-Aggregationsgruppen wird definiert, wie Ressourcen an mehreren Sites zusammengeführt werden, um dem Benutzer eine einzige, klare Ansicht zu bieten. StoreFront aggregiert doppelte veröffentlichte Ressourcen in einem Einzelsymbol.

Abbildung: Benutzererfahrung mit Aggregation

Der Administrator muss festlegen, wie Benutzer über die verschiedenen XenApp/XenDesktop-Sites verteilt werden, wenn ein Symbol eine Aggregation darstellt. Es gibt folgende Optionen:

  • Lastausgleich: Wird verwendet, wenn die doppelten Sites aufgrund von Kapazitätsempfehlungen erstellt werden. StoreFront verteilt die Benutzeranforderungen auf alle konfigurierten Sites.
  • Failover: Wird verwendet, wenn geografische Regionen für den Fall eines Ausfalls über Ressourcen verfügen müssen oder wenn Benutzer von einer Site zu einer anderen migriert werden (z. B. bei einem XenApp-Migrationsprojekt).

Es ist ratsam, Benutzer, Stores und Aggregationsmethoden in der Designphase zu dokumentieren.

Benutzergruppe Verfügbare Stores Stores für Lastausgleich Stores für Failover
NA_FinanceUsers NA_West_Store, NA_East_Store, EMEA_Store NA_West_Store, NA_East_Store EMEA_Store
EMEA_SalesUsers EMEA_Store, NA_East_Store EMEA_Store NA_East_Store

Entscheidung: Skalierbarkeit

Die Anzahl der Citrix Receiver-Benutzer, die von einem StoreFront-Server unterstützt werden, hängt von den zugewiesenen Ressourcen und dem Grad der Benutzeraktivität ab. Receiver für Web-Benutzer verbrauchen durchschnittlich mehr RAM als Benutzer einer nativen Receiver-Instanz. Pro StoreFront-Server werden jedoch in allen Fällen mindestens 4 GB RAM empfohlen. Darüber hinaus steigen bei einer höheren Anzahl Sites/Farmen, die pro Store aufgelistet werden, die CPU-Auslastung und die Reaktionszeit des Servers, wobei XenApp IMA-Farmen eine größere Skalierbarkeitsauswirkungen haben als XenApp/XenDesktop-FMA-Sites.

StoreFront-Bereitstellung CPU-Nutzung Simultane Aktivitäten
Standalone-Bereitstellung: 4 CPUs, 4 GB RAM, hohe Auslastung (Anmeldung, Auflisten, Abonnieren, Abonnementkündigung, Abmelden) 75 % 291 pro Sekunde
Standalone-Bereitstellung: 4 CPUs, 4 GB RAM, hohe Auslastung (Anmeldung, Auflisten, Abonnieren, Abonnementkündigung, Abmelden) 90 % 375 pro Sekunde
Cluster-StoreFront-Bereitstellung: 2 Knoten mit je 4 CPUs, 4 GB RAM, hohe Auslastung (Anmeldung, Auflisten, Abonnieren, Abonnementkündigung, Abmelden) 75 % 529 pro Sekunde
Cluster-StoreFront-Bereitstellung: 2 Knoten mit je 4 CPUs, 4 GB RAM, hohe Auslastung (Anmeldung, Auflisten, Abonnieren, Abonnementkündigung, Abmelden) 90 % 681 pro Sekunde

Tests ergaben einen abnehmenden Ertragszuwachs, wenn eine StoreFront-Bereitstellung über 3 bis 4 StoreFront-Knoten hinauswächst, wobei in einer Servergruppe maximal 5 bis 6 Server unterstützt werden.

NetScaler Gateway

Für Benutzergruppen, die NetScaler Gateway als Authentifizierungspunkt verwenden, müssen zusätzliche Designentscheidungen gefällt werden. Diese Entscheidungen sind bei anderen Authentifizierungspunkten als NetScaler Gateway nicht erforderlich.

Entscheidung: Topologie

Die Auswahl der Netzwerktopologie ist für die Planung der Remotezugriffsarchitektur von zentraler Bedeutung, um sicherzustellen, dass sie die erforderliche Funktionalität, Leistung und Sicherheit liefert. Das Design der Remotezugriffsarchitektur sollte in Zusammenarbeit mit dem Sicherheitsteam erstellt werden, um die Einhaltung der Sicherheitsanforderungen des Unternehmens zu gewährleisten. Es gibt zwei primäre Topologien mit unterschiedlichen Sicherheitsniveaus:

  • Einarm (normale Sicherheit): Bei einer Topologie mit einem Zweig nutzt NetScaler Gateway eine physische oder logische aggregierte Schnittstelle mit zugeordnetem VLAN und IP-Subnetz für den Transport von Front-End-Datenverkehr für Benutzer und Back-End-Datenverkehr für die Server und Dienste der virtuellen Desktop-Infrastruktur.

Topologieabbildung

  • Zweiarm (hohe Sicherheit): Bei einer Topologie mit zwei Zweigen nutzt NetScaler Gateway zwei oder mehr physisch oder logisch aggregierte Schnittstellen mit zugehörigen VLANs und IP-Subnetzen. Der Transport des Front-End-Datenverkehrs für Benutzer wird zu einer dieser Schnittstellen geleitet. Der Front-End-Datenverkehr ist vom Back-End-Datenverkehr zwischen den Servern und Diensten der virtuellen Desktop-Infrastruktur isoliert, da dieser an eine zweite Schnittstelle geleitet wird. Dies ermöglicht die Verwendung separater DMZs zur Isolierung des Front-End- und Backend-Datenverkehrs sowie eine detaillierte Firewallsteuerung und Überwachung.

Topologieabbildung

Entscheidung: hohe Verfügbarkeit

Wenn NetScaler Gateway nicht verfügbar ist, können Remotebenutzer nicht auf die Umgebung zugreifen. Daher sollten mindestens zwei NetScaler Gateway-Hosts bereitgestellt werden, damit diese Komponente keine einzelne Schwachstelle darstellt.

Bei Konfigurationen von NetScaler Gateway in einem Hochverfügbarkeitspaar (aktiv/passiv) überwacht das sekundäre NetScaler Gateway die primäre Appliance, indem es in regelmäßigen Abständen Heartbeat-Meldungen zur Integritätsprüfung sendet, um festzustellen, ob die primäre Appliance Verbindungen akzeptiert. Schlägt die Integritätsprüfung fehl, wiederholt das sekundäre NetScaler Gateway für eine festgelegte Zeit den Verbindungsversuch. Sind auch diese Versuche nicht erfolgreich, wird die primäre Appliance als nicht funktionierend erachtet. Wenn die sekundäre Appliance die nicht bestandene Integritätsprüfung bestätigt, übernimmt sie den Betrieb anstelle des primären NetScaler Gateways.

Ab Firmwareversion 10.5 können auch mehrere NetScaler Gateway-Instanzen im Cluster betrieben werden, um eine hohe Verfügbarkeit bereitzustellen. Allerdings hängt die Unterstützung einer Spotted- bzw. Stripped-Konfiguration von der Firmware und der Gateway-Konfiguration ab (vollständiges SSL-VPN/ICA-Proxy). (https://docs.citrix.com/en-us/netscaler/11-1/clustering/cluster-features-supported.html)

Entscheidung: Plattform

Zur Wahl der bestgeeigneten NetScaler-Plattform müssen die wichtigsten Ressourcenkriterien identifiziert werden. Da der gesamte Remotezugriffs-Datenverkehr mit Secure Sockets Layer (SSL) geschützt und in Form von HTTPS über HTTP transportiert wird, sind zwei Ressourcenkennzahlen wichtig:

  • SSL-Durchsatz: Der SSL-Durchsatz ist der SSL-Datenverkehr in Gigabit, der pro Sekunde verarbeitet werden kann (Gbit/s).
  • SSL-Transaktionen pro Sekunde (TPS): TPS gibt an, wie oft pro Sekunde ein Application Delivery Controller (ADC) eine SSL-Transaktion ausführen kann. Die Kapazität hängt in erster Linie von der erforderlichen Schlüssellänge ab. Die TPS-Kapazität ist in erster Linie in der Aushandlungsphase relevant, in der SSL erstmals eingerichtet wird. In der Phase der Massenverschlüsselung/-entschlüsselung, die den größten Teil der Sitzungsdauer darstellt, spielt sie eine geringere Rolle. TPS ist eine wichtige Kennzahl, die überwacht werden muss, doch die Praxiserfahrung hat gezeigt, dass der SSL-Durchsatz der wichtigste Faktor bei der Wahl des geeigneten NetScaler Gateways ist.

Der durchschnittliche SSL-Bandbreitenmehraufwand wird im Verhältnis zum Volumen des virtuellen Desktop-Datenverkehrs oft als vernachlässigbar angesehen und normalerweise nicht im SSL-Durchsatz berücksichtigt. Die Berücksichtigung der SSL-Bandbreite stellt jedoch sicher, dass der geschätzte Gesamtdurchsatz ausreichend ist. Die feste Paketheader-Bandbreite hängt von dem Verschlüsselungsalgorithmus ab und der Gesamtprozentsatz der Bandbreite kann je nach Paketgröße stark variieren. Idealerweise sollte der Mehraufwand im Rahmen einer Machbarkeitsstudie oder eines Pilotprojekts gemessen werden. In Ermangelung solcher Daten gilt die Erhöhung der Workloadbandbreite um 2 % als gute Faustregel. Um den von einer NetScaler-Plattform benötigten SSL-Durchsatz zu ermitteln, multiplizieren Sie daher die maximale gleichzeitige Datencenter-Bandbreite mit 1,02:

SSL-Durchsatz = maximale gleichzeitige Bandbreite x 1,02

Beispiel: Bei einer maximalen gleichzeitigen Bandbreite von 128 MBit/s wird das geeignete NetScaler-Modell wie folgt ermittelt:

~ 130 MBit/s = 128 MBit/s x 1,02

Der SSL-Durchsatzwert sollte mit der Durchsatzkapazität der verschiedenen NetScaler-Plattformen verglichen werden, um die bestgeeignete zu finden. Es gibt drei Hauptplattformgruppen, von denen jede vielfältige Skalierbarkeitsoptionen bietet.

  • VPX: Ein NetScaler VPX-Gerät bietet die gleiche Funktionalität wie NetScaler-Hardware. NetScaler VPX-Geräte können jedoch über serienmäßige Server gehostet werden und sind für kleine bis mittelgroße Umgebungen geeignet. In der Regel stellen Organisationen ein Baselinelimit von 500 Benutzern pro VPX-Instanz auf.
  • MPX: NetScaler MPX ist die Hardwareversion der NetScaler-Geräte. MPX-Geräte sind leistungsfähiger als virtuelle NetScaler und unterstützen Netzwerkoptimierungen für große Bereitstellungen, insbesondere wenn SSL-Offload konfiguriert ist, denn dieser erfolgt auf dem VPX in der Software, während auf dem MPX dafür dedizierte SSL-Chips verwendet werden.
  • SDX: Eine NetScaler-SDX-Maschine ist eine Mischung zwischen dem virtuellen und dem Hardware-NetScaler. Eine SDX-Maschine ist ein physisches Gerät, das mehrere virtuelle NetScaler hosten kann. Die Gerätekonsolidierung ist platzsparender. NetScaler-SDX-Maschinen eignen sich für die Netzwerkkommunikation in Großunternehmen und für Anbieter von Mehrmandantenhosting.

Informationen zur SSL-Durchsatzkapazität der NetScaler-Plattformen finden Sie im Citrix NetScaler-Datenblatt. Für das obige Beispiel wäre ein NetScaler MPX 5550 ausreichend. Tatsächlich hängt die Skalierbarkeit von den Sicherheitsanforderungen ab. Der NetScaler-SSL-Durchsatz sinkt mit steigender Komplexität der Verschlüsselungsalgorithmen und Schlüssellänge. Außerdem gründet diese Berechnung auf einem einzelnen NetScaler. Es wird zumindest eine N + 1-Redundanz empfohlen, die einen weiteren NetScaler der gleichen Plattform und des gleichen Modells erfordern würde.

Hinweis

Die Durchsatzangaben im Citrix NetScaler-Datenblatt basieren auf optimalen Bedingungen für die Leistung. Die Leistung hängt jedoch direkt von den Sicherheitsanforderungen ab. Beispiel: Bei Verwendung der RC4-Verschlüsselung und einer Schlüssellänge von 1000 kann eine VPX-Plattform möglicherweise über 500 HDX-Proxyverbindungen verarbeiten. Wird jedoch die 3DES-Verschlüsselung mit einer Schlüssellänge von 2000 verwendet (die immer weitere Verbreitung finden), kann sich der Durchsatz halbieren.

Entscheidung: Vorauthentifizierungsrichtlinie

Eine optionale Vorauthentifizierungsrichtlinie kann auf Benutzergruppen mit NetScaler Gateway als Authentifizierungspunkt angewendet werden. Vorauthentifizierungsrichtlinien beschränken den Zugriff auf die Umgebung auf Endpunkte, die bestimmte Kriterien erfüllen. Dies wird anhand einer Endpunktanalyse (EPA) geprüft.

Vorauthentifizierungszugriffsrichtlinien können für Tests von Antivirus-, Firewall-, Betriebssystem- oder sogar Registrierungseinstellungen konfiguriert werden. Mit solchen Richtlinien kann der Zugriff vollständig verhindert werden oder sie ermöglichen XenDesktop die Steuerung von Sitzungsfunktionen wie etwa die Zuordnung der Zwischenablage, die Druckerzuordnung und sogar die Verfügbarkeit spezifischer Anwendungen und Desktops. Wenn beispielsweise auf einem Benutzergerät kein Antivirenprogramm installiert ist, kann ein entsprechender Filter dafür sorgen, dass sensible Anwendungen verborgen werden.

Die folgende Abbildung bietet einen Überblick darüber, wie die Funktionen einer Virtualisierungsressource über Richtlinien angepasst werden können:

Abbildung der Zugriffsentscheidungslogik

Praxiserfahrung

  • Einzelhandel: Ein kleines Privathandelsunternehmen verwendet EPA, um nach aktualisierten Virenschutzdefinitionen zu suchen, bevor der Zugriff gewährt wird.
  • Finanzsektor: Ein mittelständischer Finanzdienstleister verwendet EPA-Scans der Domänen-SID, um zu überprüfen, ob Benutzer Mitglieder der Unternehmensdomäne sind, bevor der Zugriff gewährt wird.
  • Behörden: Eine große Behörde überprüft Endpunktgeräte mit EPA, um sicherzustellen, dass ein spezifisches Zertifikat (oder auch mehrere Zertifikate) auf einem Gerät installiert ist, bevor der Zugriff gewährt wird.

Entscheidung: Sitzungsrichtlinie

Für Benutzergruppen, die NetScaler Gateway als Authentifizierungspunkt verwenden, müssen entsprechende Sitzungsrichtlinien definiert werden. Über Sitzungsrichtlinien wird die allgemeine Benutzererfahrung nach der Authentifizierung festgelegt.

Die Sitzungsrichtlinien werden basierend auf dem verwendeten Citrix Receiver-Typ erstellt. Für die Zuweisung von Sitzungsrichtlinien werden Geräte üblicherweise in nicht mobile Geräte (etwa solche mit Windows, Mac und Linux) und mobile Geräte (mit iOS oder Android) eingeteilt. Daher muss basierend auf den bei der Bewertung ermittelten Clientgeräteanforderungen entschieden werden, ob mobile Geräte, nicht mobile Geräte oder beides unterstützt werden sollen.

Zur Identifizierung von Sitzungsrichtlinien für Geräte verwenden Sie die hier beschriebenen Ausdrücke.

  • Mobile Geräte: Der Ausdruck ist auf “REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver” festgelegt und hat eine höhere Priorität als die Richtlinie für nicht-mobile Geräte, um sicherzustellen, dass mobile Geräte ausgewählt werden, nicht aber nicht mobile Geräte.
  • Nicht-mobile Geräte: Der Ausdruck ist auf “ns_true” festgelegt, was bedeutet, dass er für den gesamten Datenverkehr gelten soll, der an ihn gesendet wird.

Eine alternative Verwendung von Sitzungsrichtlinien besteht darin, Endpunktanalyseausdrücke anzuwenden. Diese Sitzungsrichtlinien werden nach der Authentifizierung angewendet, bilden jedoch die oben erwähnten Vorauthentifizierungsrichtlinien nach. Sitzungsrichtlinien können verwendet werden, um für Endpunkte, die die Sicherheitsanforderungen nicht vollständig erfüllen, ein Fallback wie etwa den schreibgeschützten Zugriff auf bestimmte Anwendungen bereitzustellen.

Entscheidung: Sitzungsprofil

Für jede Sitzungsrichtlinie muss ein Sitzungsprofil definiert sein. Das Sitzungsprofil definiert die für Benutzergruppen zum Zugriff auf die Umgebung erforderlichen Details. Es gibt zwei primäre Arten von Sitzungsprofilen, die die Zugriffsmethode für die virtuelle Desktopumgebung bestimmen:

  • SSLVPN: Die Benutzer erstellen ein virtuelles privates Netzwerk und tunneln den gesamten durch IP-Adressen konfigurierten Datenverkehr durch das interne Netzwerk. Die Clientgeräte der Benutzers können auf zulässige Intranetressourcen so zugreifen, als wären sie im internen Netzwerk. Dazu gehören XenDesktop-Sites und jeder andere interne Datenverkehr, etwa Dateifreigaben oder Intranetwebsites. Dies gilt als potenziell weniger sichere Zugriffsmethode, da Netzwerkports und -routen zu Diensten außerhalb der virtuellen Desktop-Infrastruktur geöffnet werden könnten und das Unternehmen dann den Risiken ausgesetzt wäre, die mit vollem VPN-Zugriff einhergehen. Zu den Risiken gehören Denial-of-Service-Angriffe, Versuche, interne Server zu hacken, und jede andere Form bösartiger Aktionen, die von einem Client im Internet über Malware, Trojaner oder andere Viren gegen anfällige Dienste über Routen und Ports ausgeführt werden können.

Bei Verwendung von SSLVPN muss außerdem entschieden werden, ob Split-Tunneling für den Clientnetzwerkdatenverkehr aktiviert werden soll. Bei Aktivieren von Split-Tunneling kann der von Citrix Receiver an das Intranet geleitete Clientnetzwerkdatenverkehr auf Routen und Ports beschränkt werden, die bestimmten Diensten zugeordnet sind. Wird Split-Tunneling deaktiviert, dann wird der gesamte Clientnetzwerkdatenverkehr an das Intranet geleitet und sowohl der für interne Dienste als auch der für externe Dienste (Internet) bestimmte Datenverkehr läuft durch das Unternehmensnetzwerk. Der Vorteil des Split-Tunnelings besteht in einer geringeren Gefährdung des Unternehmensnetzwerks und der Einsparung von Netzwerkbandbreite. Der Vorteil der Deaktivierung von Split-Tunneling besteht darin, dass der Clientnetzwerkdatenverkehr über Webfilter, Angriffserkennungssysteme o. Ä. überwacht und gesteuert werden kann.

Abbildung: SSL-VPN

  • HDX-Proxy: Bei Verwendung von HDX-Proxy stellen die Benutzer eine Verbindung zu ihren virtuellen Desktops und Anwendungen über das NetScaler Gateway her, ohne dass interne Adressen extern verfügbar gemacht werden. In dieser Konfiguration fungiert NetScaler Gateway als Micro-VPN und verarbeitet nur HDX-Datenverkehr. Für Datenverkehr anderer Art auf Endgeräten, wie z. B. privater E-Mail- oder Internetdatenverkehr, wird NetScaler Gateway nicht verwendet.

Basierend auf dem verwendeten Endpunkt und Citrix Receiver muss entschieden werden, ob diese Methode für die einzelnen Benutzergruppen unterstützt wird. HDX-Proxy gilt als sichere Methode des Remotezugriffs auf virtuelle Desktops, da nur der für die Desktopsitzung spezifische Datenverkehr an die Unternehmensinfrastruktur weitergeleitet werden kann. Die meisten Citrix Receiver unterstützen HDX-Proxy und HDX-Proxy ist die bevorzugte Methode:

Abbildung: HDX-Proxy

Entscheidung: Bevorzugtes Datencenter

Unternehmen haben oft mehrere aktive Datencenter, die hohe Verfügbarkeit für geschäftskritische Anwendungen bieten. In diese Kategorie fallen möglicherweise einige virtuelle Desktops oder Anwendungen, während auf andere nur von einem bestimmten bevorzugten Datencenter aus zugegriffen werden kann. Daher befindet sich das NetScaler Gateway, bei dem sich ein Benutzer in einer Umgebung mit mehreren aktiven Datencentern authentifiziert, möglicherweise nicht in dem seinen VDI-Ressourcen entsprechenden bevorzugten Datencenter. StoreFront kann den Standort der dem Benutzer zugewiesenen Ressourcen ermitteln und die HDX-Sitzung an diese Ressourcen weiterleiten. Der Pfad ist dann aber möglicherweise nicht optimal (WAN-Verbindung anstelle von LAN-Verbindung vom NetScaler Gateway zu den virtuellen Ressourcen).

Es gibt statische und dynamische Methoden der Weiterleitung von HDX-Sitzungen an die virtuellen Desktopressourcen im primären Datencenter. Die Wahl der Methode sollte gemäß der Verfügbarkeit von Technologien zur dynamischen Zuweisung von Sites (z. B. Global Server Load Balancing) und der Bewertung von Intranet- und Internetbandbreite sowie QoS-Funktionen (Quality of Service) erfolgen.

Hinweis

Weitere Informationen zum Konfigurieren der statischen und dynamischen GSLB-Methoden finden Sie in der Citrix-Produktdokumentation unter Konfigurieren von GSLB für Nähe.

Statisch

  • Direkt: Dem Benutzer kann ein FQDN zugewiesen werden, der einem für das NetScaler Gateway des primären Datencenters reservierten A-Datensatz zugeordnet ist, sodass er von jedem Standort der Welt aus direkt auf seinen virtuellen Desktop zugreifen kann. Dieser Ansatz ist weniger komplex als die dynamische Zuweisung. Allerdings gibt es dann keine Fehlertoleranzoptionen, z. B. die Möglichkeit, über einen anderen Intranetpfad auf den virtuellen Desktop zuzugreifen, wenn ein Ausfall des primären Datencenters auf die Zugriffsinfrastruktur beschränkt ist.

Dynamisch

  • Intranet: In den meisten dynamischen Umgebungen wird für die Authentifizierung zunächst das dem Benutzer nächstgelegene Datencenter ausgewählt. Protokolle wie GSLB Dynamic Proximity berechnen die geringste Latenz zwischen dem lokalen DNS-Server des Benutzers und dem NetScaler Gateway. Danach wird die HDX-Sitzung standardmäßig über dasselbe NetScaler Gateway an das Datencenter weitergeleitet, das die virtuellen Desktops und Anwendungen des Benutzers hostet. Der Vorteil hierbei besteht darin, dass der Großteil der HDX-Sitzung das Unternehmens-WAN durchquert, in dem QoS genutzt werden kann.

Abbildung: Intranetverbindung

  • Internet: Die HDX-Sitzung kann auch über ein alternatives NetScaler Gateway umgeleitet werden, das sich in der Nähe des Back-End-VDI-Desktops/XenApp-Servers befindet, sodass der Großteil der HDX-Sitzung über das Internet übertragen läuft. Beispielsweise kann ein Benutzer mit einem dedizierten Desktop in Europa, der in den USA unterwegs ist, nach dem Näheprinzip zu einem NetScaler Gateway in einem amerikanischen Datencenter geleitet werden. Doch wenn der Benutzer seinen Desktop startet, wird eine HDX-Verbindung mit dem virtuellen Desktop über ein NetScaler Gateway hergestellt, das im bevorzugten Datencenter in Europa gehostet wird.

Dies verringert die WAN-Nutzung (auf Kosten des QoS) und wird empfohlen, wenn die Internetverbindung zuverlässiger ist als das Unternehmens-WAN.

Abbildung: Internetverbindung

Einige Unternehmen verwenden wahrscheinlich eine Kombination dieser Methoden, z. B. geospezifische dynamische URLs für Fehlertoleranz in einem geografischen Gebiet (z. B. Europa) ohne kompliziertes GSLB.

Verbindung zwischen Sites

Eine XenApp- und XenDesktop-Bereitstellung kann mehrere Sites umfassen. Um eine Lösung für mehrere Sites erfolgreich zu implementieren, muss das Design die Verbindungen zwischen den Sites und das XenApp- und XenDesktop-Sitzungsrouting zwischen den Sites für eine optimale Benutzererfahrung berücksichtigen.

Entscheidung: HDX-optimiertes Routing

In einer XenApp und XenDesktop-Lösung mit mehreren Sites werden Benutzer nach Kriterien wie kürzester Reaktionszeit oder größte Nähe zur optimalen Site geleitet. Diese Algorithmen berücksichtigen nicht die Ressourcen, auf die ein Benutzer zugreifen möchte.

Ein unsachgemäßes Routing von Sitzungen hat folgenden Effekt:

Abbildung: HDX-Routing

  1. Der Benutzer wird basierend auf Nähe oder Reaktionszeit an die bevorzugte Site weitergeleitet.
  2. NetScaler Gateway leitet den ICA-Datenverkehr, möglicherweise über das Unternehmens-WAN, an die richtige Ressource weiter.

Das ideale Routing würde folgendermaßen aussehen:

Abbildung: optimales Routing

  1. Der Benutzer wird basierend auf Nähe oder Reaktionszeit an die bevorzugte Site weitergeleitet.
  2. Basierend auf der ausgewählten Ressource leitet NetScaler Gateway die Sitzung an ein NetScaler Gateway in der bevorzugten Site um.
  3. NetScaler Gateway leitet den ICA-Datenverkehr an die richtige Ressource weiter, wobei der Datenverkehr im lokalen LAN verbleibt.

Mit dem optimierten HDX-Routing in StoreFront wird der Datenverkehr aus dem Unternehmens-WAN und auf das öffentliche Netzwerk übertragen.

Entscheidung: virtuelles WAN

In Umgebungen mit Zweigstellen muss für ein XenApp und XenDesktop-Design die Verbindung der Zweigstellen mit den Datencentern, welche die Anwendungs- und Desktopressourcen hosten, berücksichtigt werden. Erfüllt die WAN-Verbindung zwischen Zweigstelle und Datencenter nicht die Benutzeranforderungen, verschlechtert sich die allgemeine Benutzererfahrung. Für ihre WAN-Verbindungen gibt es mehrere Optionen:

  • Skalieren: Es kann einfach die Größe der WAN-Pipe zwischen Zweigstellen und Datencenter erhöht werden. Dabei fallen normalerweise erhebliche Kosten an.
  • Horizontal skalieren: Die WAN-Verbindung wird beibehalten und durch mehrere kostengünstige Alternativen ergänzt. Durch die Integration aller Verbindungen zwischen Zweigstelle und Datencenter entsteht ein softwaredefiniertes virtuelles WAN wie etwa NetScaler SDWAN. Die Appliance sendet doppelte Netzwerkpakete über alle im virtuellen WAN definierten WAN-Verbindungen. Die Appliance am anderen Ende des WAN verwendet das erste ankommende Paket und verwirft alle nachfolgenden. Bei wechselhaften Bedingungen der Mehrfachverbindungen garantiert dieser Ansatz das bestmögliche Erlebnis.

Abbildung: NetScaler SD-WAN

Designmethodik Zugriffslayer