VPC-Design - Bewährte Methoden für die Bereitstellung von WorkSpaces
NetzwerkschnittstellenDatenverkehrsflussClient-Gerät zu WorkSpaceAmazon WorkSpaces Service zu VPCBeispiel für eine typische KonfigurationAWS Directory Service

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

VPC-Design

In diesem Abschnitt werden bewährte Methoden für die Dimensionierung Ihrer VPC und Subnetze, den Datenverkehrsfluss und die Auswirkungen auf das Design von Verzeichnisservices beschrieben.

Hier sind einige Dinge, die Sie beim Entwerfen der VPC, der Subnetze, Sicherheitsgruppen, Routing-Richtlinien und Netzwerkzugriffskontrolllisten (ACLs) für Ihr Amazon berücksichtigen sollten, WorkSpaces damit Sie Ihre WorkSpaces Umgebung für Skalierbarkeit, Sicherheit und Benutzerfreundlichkeit erstellen können:

  • VPC – Wir empfehlen, eine separate VPC speziell für Ihre WorkSpaces Bereitstellung zu verwenden. Mit einer separaten VPC können Sie die erforderlichen Leitlinien für Governance und Sicherheit für Ihre angeben, WorkSpaces indem Sie eine Trennung des Datenverkehrs einrichten.

  • Directory Services – Jedes AWS Directory Service Konstrukt erfordert ein Paar von Subnetzen, die eine hochverfügbare Verzeichnisserviceaufteilung zwischen AZs bieten.

  • Subnetzgröße – WorkSpaces Bereitstellungen sind an ein Verzeichniskonstrukt gebunden und befinden sich in derselben VPC wie Ihr gewähltes AWS Directory Service, können sich jedoch in verschiedenen VPC-Subnetzen befinden. Einige Überlegungen:

    • Subnetzgrößen sind dauerhaft und können sich nicht ändern. Sie sollten genügend Platz für zukünftiges Wachstum lassen.

    • Sie können eine Standardsicherheitsgruppe für die von Ihnen ausgewählten angeben AWS Directory Service. Die Sicherheitsgruppe gilt für alle WorkSpaces , die dem spezifischen AWS Directory Service Konstrukt zugeordnet sind.

    • Sie können mehrere Instances von dasselbe Subnetz AWS Directory Service verwenden.

Berücksichtigen Sie zukünftige Pläne, wenn Sie Ihre VPC entwerfen. Sie können beispielsweise Verwaltungskomponenten wie einen Antivirenserver, einen Patch-Managementserver oder einen AD- oder RADIUS-MFA-Server hinzufügen. Es lohnt sich, zusätzliche verfügbare IP-Adressen in Ihrem VPC-Design zu planen, um solche Anforderungen zu erfüllen.

Ausführliche Anleitungen und Überlegungen zum VPC-Design und zur Dimensionierung von Subnetzen finden Sie in der re:Invent-Präsentation Wie Amazon.com zu Amazon wechselt WorkSpaces.

Netzwerkschnittstellen

Jede WorkSpaces hat zwei Elastic Network-Schnittstellen (ENIs), eine Verwaltungsnetzwerkschnittstelle (eth0) und eine primäre Netzwerkschnittstelle (eth1). AWS verwendet die Verwaltungsnetzwerkschnittstelle zur Verwaltung der WorkSpace – es ist die Schnittstelle, auf der Ihre Client-Verbindung beendet wird. AWS verwendet einen privaten IP-Adressbereich für diese Schnittstelle. Damit das Netzwerk-Routing ordnungsgemäß funktioniert, können Sie diesen privaten Adressraum nicht in einem Netzwerk verwenden, das mit Ihrer WorkSpaces VPC kommunizieren kann.

Eine Liste der privaten IP-Bereiche, die pro Region verwendet werden, finden Sie unter Amazon WorkSpaces Details.

Anmerkung

Amazon WorkSpaces und die zugehörigen Verwaltungsnetzwerkschnittstellen befinden sich nicht in Ihrer VPC und Sie können die Verwaltungsnetzwerkschnittstelle oder die Amazon Elastic Compute Cloud (Amazon EC2)-Instance-ID in Ihrem nicht anzeigen AWS Management Console (siehe Figure 5Figure 6, und Figure 7). Sie können jedoch die Sicherheitsgruppeneinstellungen Ihrer primären Netzwerkschnittstelle (eth1) in der -Konsole anzeigen und ändern. Die primäre Netzwerkschnittstelle jeder WorkSpace wird auf Ihre ENI-Amazon EC2Ressourcenkontingente angerechnet. Für große Bereitstellungen von Amazon müssen Sie ein Support-Ticket über die öffnen WorkSpaces, AWS Management Console um Ihre ENI-Kontingente zu erhöhen.

Datenverkehrsfluss

Sie können den Amazon- WorkSpaces Datenverkehr in zwei Hauptkomponenten aufteilen:

  • Der Datenverkehr zwischen dem Client-Gerät und dem Amazon- WorkSpaces Service.

  • Der Datenverkehr zwischen dem Amazon- WorkSpaces Service und dem Kundennetzwerkverkehr.

Im nächsten Abschnitt werden beide Komponenten behandelt.

Client-Gerät zu WorkSpace

Unabhängig von seinem Standort (lokal oder remote) verwendet das Gerät, auf dem der Amazon WorkSpaces-Client ausgeführt wird, dieselben beiden Ports für die Konnektivität mit dem Amazon- WorkSpaces Service. Der Client verwendet Port 443 (HTTPS-Port) für alle Authentifizierungs- und sitzungsbezogenen Informationen sowie Port 4172 (PCoIP-Port) mit Transmission Control Protocol (TCP) und User Datagram Protocol (UDP), um Pixel-Streaming an eine bestimmte WorkSpace und Netzwerkzustandsprüfungen durchzuführen. Der Datenverkehr auf beiden Ports ist verschlüsselt. Port 443-Datenverkehr wird für Authentifizierungs- und Sitzungsinformationen verwendet und verwendet TLS für die Verschlüsselung des Datenverkehrs. Pixel-Streaming-Datenverkehr verwendet AES-256-bitVerschlüsselung für die Kommunikation zwischen dem Client und eth0 der über WorkSpacedas Streaming-Gateway. Weitere Informationen finden Sie im Sicherheit Abschnitt dieses Dokuments.

Wir veröffentlichen pro Region IP-Bereiche unserer PCoIP-Streaming-Gateways und Endpunkte für Netzwerkzustandsprüfungen. Sie können ausgehenden Datenverkehr auf Port 4172 von Ihrem Unternehmensnetzwerk auf das AWS Streaming-Gateway und die Endpunkte für die Netzwerkintegritätsprüfung beschränken, indem Sie nur ausgehenden Datenverkehr auf Port 4172 zu den spezifischen AWS Regionen zulassen, in denen Sie Amazon verwenden WorkSpaces. Informationen zu den IP-Bereichen und Endpunkten für die Netzwerkintegritätsprüfung finden Sie unter IP-Bereiche für Amazon WorkSpaces PCoIP Gateway.

Der Amazon- WorkSpaces Client verfügt über eine integrierte Netzwerkstatusprüfung. Dieses Dienstprogramm zeigt Benutzern, ob ihr Netzwerk eine Verbindung mithilfe eines Statusindikators unten rechts in der Anwendung unterstützen kann. Die folgende Abbildung zeigt eine detailliertere Ansicht des Netzwerkstatus, auf den Sie zugreifen können, indem Sie oben rechts im Client Netzwerk auswählen.

Image, das das Netzwerkprüfungsfenster des WorkSpaces Clientbrowsers zeigt

Abbildung 1: WorkSpaces Client: Netzwerkprüfung

Ein Benutzer initiiert eine Verbindung von seinem Client zum Amazon- WorkSpaces Service, indem er seine Anmeldeinformationen für das Verzeichnis bereitstellt, das vom Directory-Service-Konstrukt verwendet wird, in der Regel sein Unternehmensverzeichnis. Die Anmeldeinformationen werden über HTTPS an die Authentifizierungs-Gateways des Amazon- WorkSpaces Services in der Region gesendet, in der sich das WorkSpace befindet. Das Authentifizierungs-Gateway des Amazon- WorkSpaces Services leitet dann den Datenverkehr an das spezifische AWS Directory-Service-Konstrukt weiter, das Ihrem zugeordnet ist WorkSpace.

Wenn Sie beispielsweise den AD Connector verwenden, leitet der AD Connector die Authentifizierungsanforderung direkt an Ihren AD-Service weiter, der On-Premises oder in einer AWS VPC sein könnte. Weitere Informationen finden Sie im Abschnitt AD-DS-Bereitstellungsszenarien in diesem Dokument. Der AD Connector speichert keine Authentifizierungsinformationen und fungiert als zustandsloser Proxy. Daher ist es zwingend erforderlich, dass AD Connector über Konnektivität zu einem AD-Server verfügt. Der AD Connector bestimmt, mit welchem AD-Server eine Verbindung hergestellt werden soll, indem die DNS-Server verwendet werden, die Sie beim Erstellen des AD Connectors definieren.

Wenn Sie einen AD Connector verwenden und MFA für das Verzeichnis aktiviert haben, wird das MFA-Token vor der Verzeichnisdienstauthentifizierung überprüft. Wenn die MFA-Validierung fehlschlägt, werden die Anmeldeinformationen des Benutzers nicht an Ihren AWS Directory Service weitergeleitet.

Sobald ein Benutzer authentifiziert wurde, beginnt der Streaming-Datenverkehr mit Port 4172 (PCoIP-Port) über das AWS Streaming-Gateway zur WorkSpace. Sitzungsbezogene Informationen werden während der gesamten Sitzung weiterhin über HTTPS ausgetauscht. Der Streaming-Datenverkehr verwendet die erste ENI auf der WorkSpace (eth0 auf der WorkSpace), die nicht mit Ihrer VPC verbunden ist. Die Netzwerkverbindung vom Streaming-Gateway zur ENI wird von verwaltet AWS. Im Falle eines Verbindungsfehlers von den Streaming-Gateways zur WorkSpaces Streaming-ENI wird ein CloudWatch Ereignis generiert. Weitere Informationen finden Sie im Abschnitt Überwachung oder Protokollierung mit Amazon CloudWatch in diesem Dokument.

Die Datenmenge, die zwischen dem Amazon- WorkSpaces Service und dem Client gesendet wird, hängt vom Grad der Pixelaktivität ab. Um ein optimales Benutzererlebnis zu gewährleisten, empfehlen wir, dass die Round-Trip-Zeit (RTT) zwischen dem WorkSpaces Client und der AWS Region, in der WorkSpaces sich Ihr befindet, weniger als 100 Millisekunden (ms) beträgt. In der Regel bedeutet dies, dass sich Ihr WorkSpaces Client weniger als zweitausend Kilometer von der Region befindet, in der gehostet WorkSpace wird. Die Webseite Connection Health Check kann Ihnen helfen, die optimale AWS Region für die Verbindung mit dem Amazon- WorkSpaces Service zu ermitteln.

Amazon WorkSpaces Service zu VPC

Nachdem eine Verbindung von einem Client zu einem authentifiziert WorkSpace und Streaming-Datenverkehr initiiert wurde, zeigt Ihr WorkSpaces Client entweder einen Windows- oder Linux-Desktop (Ihr Amazon WorkSpace) an, der mit Ihrer Virtual Private Cloud (VPC) verbunden ist, und Ihr Netzwerk sollte zeigen, dass Sie diese Verbindung hergestellt haben. Der primären Elastic Network Interface (ENI) WorkSpacevon eth1wird eine IP-Adresse vom Dynamic Host Configuration Protocol (DHCP)-Service zugewiesen, die von Ihrer VPC bereitgestellt wird, in der Regel aus denselben Subnetzen wie Ihr AWS Directory Service. Die IP-Adresse bleibt für die WorkSpace Dauer der Lebensdauer des bei WorkSpace. Die ENI in Ihrer VPC hat Zugriff auf jede Ressource in der VPC und auf jedes Netzwerk, das Sie mit Ihrer VPC verbunden haben (über ein VPC-Peering, eine - AWS Direct Connect Verbindung oder eine VPN-Verbindung).

Der ENI-Zugriff auf Ihre Netzwerkressourcen wird durch die Routing-Tabelle des Subnetzes und der Standardsicherheitsgruppe bestimmt, die Ihr AWS Directory Service für jede konfiguriert WorkSpace, sowie durch alle zusätzlichen Sicherheitsgruppen, die Sie der ENI zuweisen. Sie können der ENI, die auf Ihre VPC ausgerichtet ist, jederzeit Sicherheitsgruppen hinzufügen, indem Sie die AWS Management Console oder verwenden AWS CLI. (Weitere Informationen zu Sicherheitsgruppen finden Sie unter Sicherheitsgruppen für Ihr WorkSpaces.) Zusätzlich zu Sicherheitsgruppen können Sie Ihre bevorzugte hostbasierte Firewall auf einem bestimmten verwenden, WorkSpace um den Netzwerkzugriff auf Ressourcen innerhalb der VPC zu beschränken.

Es wird empfohlen, Ihre DHCP-Optionsliste mit der/den DNS Server-IP(s) und vollqualifizierten Domainnamen zu erstellen, die für Ihr Active Directory spezifisch für Ihre Umgebung autoritativ sind, und diese benutzerdefinierten DHCP-Optionsliste dann der von Amazon verwendeten Amazon VPC zuzuweisen WorkSpaces. Standardmäßig verwendet Amazon Virtual Private Cloud (Amazon VPC) AWS DNS anstelle Ihres Verzeichnisservice-DNS. Durch die Verwendung eines DHCP-Optionssatzes wird eine ordnungsgemäße DNS-Namensauflösung und konsistente Konfiguration Ihrer internen DNS-Namenserver nicht nur für Ihr WorkSpaces, sondern auch für alle unterstützenden Workloads (Workloads) oder Instance(s) sichergestellt, die Sie möglicherweise für Ihre Bereitstellung geplant haben.

Wenn DHCP-Optionen angewendet werden, gibt es zwei wichtige Unterschiede in Bezug darauf, wie sie auf angewendet werden WorkSpaces , im Vergleich dazu, wie sie mit herkömmlichen EC2-Instances angewendet werden:

  • Der erste Unterschied besteht darin, wie DNS-Suffixe der DHCP-Option angewendet werden. Für jeden WorkSpace sind DNS-Einstellungen für seinen Netzwerkadapter konfiguriert, wobei die Optionen Primäre und verbindungsspezifische DNS-Suffixe anfügen und übergeordnete Suffixe der primären DNS-Suffix-Optionen anfügen aktiviert sind. Die Konfiguration wird mit dem DNS-Suffix aktualisiert, das in dem AWS von Ihnen registrierten und WorkSpace standardmäßig mit dem verknüpften Directory Service konfiguriert ist. Wenn sich das DNS-Suffix, das im verwendeten DHCP-Optionssatz konfiguriert ist, unterscheidet, wird es hinzugefügt und auf alle zugehörigen angewendet WorkSpaces.

  • Der zweite Unterschied besteht darin, dass die konfigurierten DNS-IPs der DHCP-Option nicht auf den angewendet werden, WorkSpace da der Amazon- WorkSpaces Service die IP-Adressen der Domain-Controller des konfigurierten Verzeichnisses priorisiert.

Alternativ können Sie eine privat gehostete Route-53-Zone konfigurieren, um eine Hybrid- oder Split-DNS-Umgebung zu unterstützen und eine ordnungsgemäße DNS-Auflösung für Ihre Amazon- WorkSpaces Umgebung zu erhalten. Weitere Informationen finden Sie unter Hybrid Cloud DNS-Optionen für VPC und AWS Hybrid DNS mit Active Directory .

Anmerkung

Jeder WorkSpace muss die IP-Tabelle aktualisieren, wenn ein neuer oder anderer DHCP-Optionssatz auf die VPC angewendet wird. Zur Aktualisierung können Sie ipconfig /renew ausführen oder eine WorkSpace(s) in der VPC neu starten, die mit Ihrem aktualisierten DHCP-Optionssatz konfiguriert ist. Wenn Sie AD Connector verwenden und die IP-Adressen Ihrer verbundenen IP-Adressen/Domain-Controller aktualisieren, müssen Sie dann den Bollight-DomainJoinDNSRegistrierungsschlüssel auf Ihrem aktualisieren WorkSpaces. Es wird empfohlen, dies über ein GPO zu tun. Der Pfad zu diesem Registrierungsschlüssel ist HKLM:\SOFTWARE\Amazon\Skylight. Der Wert dieses Werts REG_SZ wird nicht aktualisiert, wenn die DNS-Einstellungen des AD Connectors geändert werden und VPC DHCP Options Sets diesen Schlüssel ebenfalls nicht aktualisiert.

Die Abbildung im Abschnitt AD-DS-Bereitstellungsszenarien dieses Whitepapers zeigt den beschriebenen Datenverkehrsfluss.

Wie zuvor erläutert, priorisiert der Amazon- WorkSpaces Service die Domain-Controller-IP-Adressen des konfigurierten Verzeichnisses für die DNS-Auflösung und ignoriert die in Ihrem DHCP-Optionssatz konfigurierten DNS-Server. Wenn Sie eine genauere Kontrolle über Ihre DNS-Servereinstellungen für Ihr Amazon benötigen WorkSpaces, können Sie die Anweisungen zum Aktualisieren von DNS-Servern für Amazon WorkSpaces im Handbuch DNS-Server für Amazon aktualisieren WorkSpaces des Amazon- WorkSpaces Administratorhandbuchs verwenden.

Wenn Sie andere -Services in auflösen WorkSpaces müssen und wenn Sie die standardmäßigen DHCP-Optionen verwenden AWS, die mit Ihrer VPC festgelegt sind, muss Ihr Domain-Controller-DNS-Service in dieser VPC daher so konfiguriert sein, dass er DNS-Weiterleitung verwendet, die auf den Amazon-DNS-Server mit der IP-Adresse auf der Basis Ihres VPC-CIDR plus zwei verweist. Das heißt, wenn Ihr VPC-CIDR 10.0.0.0/24 ist, konfigurieren Sie die DNS-Weiterleitung so, dass der standardmäßige Route-53-DNS-Resolver bei 10.0.0.0.2 verwendet wird. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html

Falls Ihre eine DNS-Auflösung von Ressourcen in Ihrem On-Premises-Netzwerk WorkSpaces benötigen, können Sie einen ausgehenden Route-53-Resolver-Endpunkt verwenden, eine Route-53-Weiterleitungsregel erstellen und diese Regel den VPCs zuordnen, die diese DNS-Auflösung benötigen. Wenn Sie die Weiterleitung auf Ihrem Domain-Controller-DNS-Service an den standardmäßigen Route-53-DNS-Resolver Ihrer VPC konfiguriert haben, wie im vorherigen Absatz beschrieben, finden Sie den DNS-Auflösungsprozess im Abschnitt Auflösen von DNS-Abfragen zwischen VPCs und in Ihrem Netzwerkhandbuch für Amazon Route 53-Entwicklerhandbuch.

Wenn Sie den standardmäßigen DHCP-Optionssatz verwenden und andere Hosts in Ihren VPCs, die nicht Teil Ihrer Active-Directory-Domain sind, in der Lage sein müssen, Hostnamen in Ihrem Active-Directory-Namespace aufzulösen, können Sie diesen ausgehenden Route-53-Resolver-Endpunkt verwenden und eine weitere Route-53-Weiterleitungsregel hinzufügen, die DNS-Abfragen für Ihre Active-Directory-Domain an Ihre Active-Directory-DNS-Server weiterleitet. Diese Route-53-Weiterleitungsregel muss dem ausgehenden Route-53-Resolver-Endpunkt zugeordnet sein, der Ihren Active-Directory-DNS-Service erreichen kann, sowie allen VPCs, die Sie aktivieren möchten, um DNS-Datensätze in Ihrer WorkSpaces Active-Directory-Domain aufzulösen.

Ebenso kann ein Route 53 Resolver Inbound Endpoint verwendet werden, um die DNS-Auflösung von DNS-Datensätzen Ihrer WorkSpaces Active-Directory-Domain aus Ihrem On-Premises-Netzwerk zu ermöglichen.

Image mit WorkSpaces DNS-Auflösung

Beispiel für eine Auflösung in Abbildung 2: WorkSpaces DNS mit Route-53-Endpunkten

  • Ihr Amazon WorkSpaces verwendet den AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD)-DNS-Service für die DNS-Auflösung. Der AWS Managed Microsoft AD DNS-Service löst die example.aws Domain auf und leitet alle anderen DNS-Abfragen an den standardmäßigen Route 53 DNS Resolver an die VPC-CIDR-Basis-IP-Adresse +2 weiter, um die DNS-Auflösung zu aktivieren

    Die Shared Services VPC enthält einen Route 53 Outbound Resolver-Endpunkt, der zwei Route 53-Weiterleitungsregeln zugeordnet ist. Eine dieser Regeln leitet DNS-Abfragen für die example.com Domain an die On-Premises-DNS-Server weiter. Die zweite Regel leitet DNS-Abfragen für Ihre AWS Managed Microsoft AD Domain example.aws an Ihren Active-Directory-DNS-Service in der VPC für freigegebene Services weiter.

    Mit dieser Architektur WorkSpaces kann Ihr Amazon DNS-Abfragen für Folgendes auflösen:

    • Ihre AWS Managed Microsoft AD Domain example.aws.

    • EC2-Instances in der Domäne, die mit Ihrem standardmäßigen DHCP-Optionssatz (z. B. host1.eu-west-1.compute.internal) konfiguriert sind, sowie andere AWS Services oder Endpunkte.

    • Hosts und Services in Ihrer On-Premises-Domain, z. B. host3.example.com.

  • • Die anderen EC2-Workloads in der Shared Services VPC (host1.eu-west-1.compute.internal) und in der WorkSpaces VPC (host2.eu-west-1.compute.internal) können die gleichen DNS-Auflösungen wie Ihr haben WorkSpaces, solange die Route 53-Weiterleitungsregeln beiden VPCs zugeordnet sind. Die DNS-Auflösung für die example.aws Domain wird in diesem Fall über den standardmäßigen Route 53 DNS Resolver an der VPC-CIDR-Basis-IP-Adresse +2 geleitet, die sie gemäß den konfigurierten und zugehörigen Route 53-Weiterleitungsregeln über den ausgehenden Route 53 Resolver-Endpunkt an den WorkSpaces Active Directory-DNS-Service weiterleitet.

  • • Schließlich kann ein On-Premises-Client auch dieselbe DNS-Auflösung durchführen, da der On-Premises-DNS-Server mit bedingten Weiterleitungen für die eu-west-1.compute.internal Domains example.aws und konfiguriert ist und DNS-Abfragen für diese Domains an die eingehenden Endpunkt-IP-Adressen des Route 53 Resolvers weiterleitet.

Beispiel für eine typische Konfiguration

Betrachten wir ein Szenario, in dem Sie zwei Arten von Benutzern haben und Ihr AWS Directory Service ein zentralisiertes AD für die Benutzerauthentifizierung verwendet:

  • Mitarbeiter, die vollen Zugriff von überall aus benötigen (z. B. Mitarbeiter in Vollzeit) – Diese Benutzer haben vollen Zugriff auf das Internet und das interne Netzwerk und werden durch eine Firewall von der VPC an das On-Premises-Netzwerk weitergeleitet.

  • Auftragnehmer, die nur eingeschränkten Zugriff innerhalb des Unternehmensnetzwerks haben sollten (z. B. Auftragnehmer und Berater) – Diese Benutzer haben eingeschränkten Internetzugang über einen Proxyserver auf bestimmte Websites in der VPC und eingeschränkten Netzwerkzugriff in der VPC und auf das On-Premises-Netzwerk.

Sie möchten Mitarbeitern in Echtzeit die Möglichkeit geben, auf ihrem lokalen Administratorzugriff WorkSpace zur Installation von Software zu haben, und Sie möchten die Zwei-Faktor-Authentifizierung mit MFA erzwingen. Außerdem möchten Sie den Mitarbeitern in Echtzeit den Zugriff auf das Internet ermöglichen, ohne Einschränkungen durch ihre WorkSpace.

Bei Auftragnehmern möchten Sie den lokalen Administratorzugriff blockieren, damit sie nur bestimmte vorinstallierte Anwendungen verwenden können. Sie möchten restriktive Netzwerkzugriffskontrollen mithilfe von Sicherheitsgruppen für diese anwenden WorkSpaces. Sie müssen die Ports 80 und 443 nur für bestimmte interne Websites öffnen und ihren Zugriff auf das Internet vollständig blockieren.

In diesem Szenario gibt es zwei völlig unterschiedliche Arten von Benutzern mit unterschiedlichen Anforderungen für den Netzwerk- und Desktopzugriff. Es ist eine bewährte Methode, ihre WorkSpaces unterschiedlich zu verwalten und zu konfigurieren. Sie müssen zwei AD Connectors erstellen, einen für jede Benutzerpersona. Jeder AD Connector benötigt zwei Subnetze, die über genügend IP-Adressen verfügen, um Ihre WorkSpaces Schätzungen des Nutzungswachstums zu erfüllen.

Anmerkung

Jedes AWS VPC-Subnetz verbraucht zu Verwaltungszwecken fünf IP-Adressen (die ersten vier und die letzte IP-Adresse) und jeder AD Connector verbraucht eine IP-Adresse in jedem Subnetz, in dem er bestehen bleibt.

Weitere Überlegungen zu diesem Szenario sind:

  • AWS VPC-Subnetze sollten private Subnetze sein, damit der Datenverkehr, z. B. der Internetzugang, entweder über ein NAT-Gateway (Network Address Translation), einen Proxy-NAT-Server in der Cloud gesteuert oder über Ihr On-Premises-Datenverkehrsmanagementsystem zurückgeleitet werden kann.

  • Für den gesamten VPC-Datenverkehr, der für das On-Premises-Netzwerk bestimmt ist, ist eine Firewall vorhanden.

  • Microsoft-AD-Server und die MFA-RADIUS-Server sind entweder On-Premises (siehe Szenario 1: Verwenden von AD Connector zur Proxy-Authentifizierung an On-Premises-AD-DS in diesem Dokument) oder Teil der AWS Cloud-Implementierung (siehe Szenario 2 und Szenario 3, AD-DS-Bereitstellungsszenarien in diesem Dokument).

Da allen eine Form des Internetzugangs gewährt WorkSpaces wird und sie in einem privaten Subnetz gehostet werden, müssen Sie auch öffentliche Subnetze erstellen, die über ein Internet-Gateway auf das Internet zugreifen können. Sie benötigen ein NAT-Gateway für die Mitarbeiter, das ihnen den Zugriff auf das Internet ermöglicht, und einen Proxy-NAT-Server für die Berater und Auftragnehmer, um ihren Zugriff auf bestimmte interne Websites zu beschränken. Um Ausfälle zu planen, Hochverfügbarkeit zu entwerfen und die Gebühren für den AZ-übergreifenden Datenverkehr zu begrenzen, sollten Sie zwei NAT-Gateways und NAT- oder Proxy-Server in zwei verschiedenen Subnetzen in einer Multi-AZ-Bereitstellung haben. Die beiden AZs, die Sie als öffentliche Subnetze auswählen, stimmen mit den beiden AZs überein, die Sie für Ihre WorkSpaces Subnetze in Regionen mit mehr als zwei Zonen verwenden. Sie können den gesamten Datenverkehr von jeder WorkSpaces AZ an das entsprechende öffentliche Subnetz weiterleiten, um die AZ-übergreifenden Datenverkehrsgebühren zu begrenzen und eine einfachere Verwaltung zu ermöglichen. Die folgende Abbildung zeigt die VPC-Konfiguration.

Beispielarchitektur, die ein Beispiel für eine VPC-Konfiguration mit NAT-Gateway zeigt

Abbildung 3: High-Level-VPC-Design

In den folgenden Informationen wird beschrieben, wie Sie die beiden verschiedenen WorkSpaces Typen konfigurieren:

So konfigurieren Sie WorkSpaces für Vollzeit-Mitarbeiter:

  1. Wählen Sie in der Amazon WorkSpaces -Managementkonsole in der Menüleiste die Option Verzeichnisse aus.

  2. Wählen Sie das Verzeichnis aus, in dem sich Ihre Mitarbeiter befinden.

  3. Wählen Sie Local Administrator Setting aus.

Wenn Sie diese Option aktivieren, WorkSpace verfügen alle neu erstellten über lokale Administratorrechte. Um Internetzugang zu gewähren, konfigurieren Sie NAT für ausgehenden Internetzugang von Ihrer VPC aus. Um MFA zu aktivieren, müssen Sie einen RADIUS-Server, Server-IPs, Ports und einen vorinstallierten Schlüssel angeben.

Im Fall von Arbeitskräften WorkSpace kann WorkSpacesder eingehende Datenverkehr zum auf das Remote Desktop Protocol (RDP) aus dem Helpdesk-Subnetz beschränkt werden, indem eine Standardsicherheitsgruppe über die AD-Connector-Einstellungen angewendet wird.

So konfigurieren Sie WorkSpaces für Auftragnehmer und Berater:

  1. Deaktivieren Sie in der Amazon- WorkSpaces Managementkonsole Internet Access und die Einstellung Lokaler Administrator.

  2. Fügen Sie im Abschnitt Sicherheitsgruppeneinstellungen eine Sicherheitsgruppe hinzu, um eine Sicherheitsgruppe für alle neuen WorkSpaces zu erzwingen, die unter diesem Verzeichnis erstellt wurden.

Beschränken Sie für Berater den ausgehenden und eingehenden Datenverkehr auf WorkSpaces, WorkSpaces indem Sie eine Standardsicherheitsgruppe über die AD-Connector-Einstellungen auf alle anwenden, die dem AD Connector WorkSpaces zugeordnet sind. Die Sicherheitsgruppe verhindert ausgehenden Zugriff vom WorkSpaces auf alles andere als HTTP- und HTTPS-Datenverkehr sowie eingehenden Datenverkehr zum RDP vom Helpdesk-Subnetz im On-Premises-Netzwerk.

Anmerkung

Die Sicherheitsgruppe gilt nur für die ENI, die sich in der VPC befindet (eth1 auf der WorkSpace), und der Zugriff auf die WorkSpace vom WorkSpaces Client aus ist aufgrund einer Sicherheitsgruppe nicht eingeschränkt. Die folgende Abbildung zeigt das endgültige WorkSpaces VPC-Design.

Beispielarchitektur, die ein Beispiel für ein endgültiges WorkSpaces VPC-Design zeigt.

Abbildung 4: WorkSpaces Entwurf mit Benutzerpersonas

AWS Directory Service

Wie in der Einführung erwähnt, AWS istDirectory Service eine Kernkomponente von Amazon WorkSpaces. Mit AWS Directory Service können Sie drei Arten von Verzeichnissen mit Amazon erstellen WorkSpaces:

  • AWS Managed Microsoft AD ist ein verwaltetes Microsoft AD, das von Windows Server 2012 R2 unterstützt wird. AWS Managed Microsoft AD ist in der Standard- oder Enterprise Edition verfügbar.

  • Simple AD ist ein eigenständiger, Microsoft-AD-kompatibler, verwalteter Verzeichnisservice, der von Samba 4 unterstützt wird.

  • AD Connector ist ein Verzeichnis-Proxy zum Umleiten von Authentifizierungsanforderungen und Benutzer- oder Gruppen-Lookups an Ihr vorhandenes On-Premises-Microsoft-AD.

Im folgenden Abschnitt werden Kommunikationsabläufe für die Authentifizierung zwischen dem Amazon WorkSpaces Brokerage Service und AWS Directory Service, bewährte Methoden für die Implementierung WorkSpaces mit AWS Directory Service und erweiterte Konzepte wie MFA beschrieben. Außerdem werden Konzepte der Infrastrukturarchitektur für Amazon WorkSpaces in großem Umfang, Anforderungen an Amazon VPC und AWS Directory Service erörtert, einschließlich der Integration mit lokalen Microsoft AD Domain Services (AD DS).