Sicherheit - Bewährte Methoden für die Bereitstellung von WorkSpaces

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.

Sicherheit

In diesem Abschnitt wird erläutert, wie Sie Daten mithilfe von Verschlüsselung sichern, wenn Sie Amazon- WorkSpaces Services verwenden. Es beschreibt die Verschlüsselung während der Übertragung und im Ruhezustand sowie die Verwendung von Sicherheitsgruppen zum Schutz des Netzwerkzugriffs auf die WorkSpaces. Dieser Abschnitt enthält auch Informationen dazu, wie Sie den Zugriff auf Endgeräte mithilfe WorkSpaces von vertrauenswürdigen Geräten und IP-Zugriffskontrollgruppen steuern können.

Weitere Informationen zur Authentifizierung (einschließlich MFA-Unterstützung) im AWS Directory Service finden Sie in diesem Abschnitt.

Verschlüsselung während der Übertragung

Amazon WorkSpaces verwendet Kryptografie, um die Vertraulichkeit in verschiedenen Kommunikationsphasen (bei der Übertragung) sowie Daten im Ruhezustand (verschlüsselt) zu schützen WorkSpaces. Die Prozesse in jeder Phase der Verschlüsselung, die von Amazon WorkSpaces während der Übertragung verwendet wird, werden in den folgenden Abschnitten beschrieben.

Informationen zur Verschlüsselung im Ruhezustand finden Sie im Abschnitt Verschlüsselt WorkSpaces dieses Dokuments.

Registrierung und Aktualisierungen

Die Desktop-Client-Anwendung kommuniziert mit Amazon für Updates und Registrierungen mithilfe von HTTPS.

Authentifizierungsphase

Der Desktop-Client initiiert die Authentifizierung, indem er Anmeldeinformationen an das Authentifizierungs-Gateway sendet. Die Kommunikation zwischen dem Desktop-Client und dem Authentifizierungs-Gateway verwendet HTTPS. Wenn die Authentifizierung am Ende dieser Phase erfolgreich ist, gibt das Authentifizierungs-Gateway über dieselbe HTTPS-Verbindung ein OAuth-2.0-Token an den Desktop-Client zurück.

Anmerkung

Die Desktop-Client-Anwendung unterstützt die Verwendung eines Proxyservers für Port-443-(HTTPS)-Datenverkehr, für Updates, Registrierung und Authentifizierung.

Nach Erhalt der Anmeldeinformationen vom Client sendet das Authentifizierungs-Gateway eine Authentifizierungsanforderung an AWS Directory Service. Die Kommunikation vom Authentifizierungs-Gateway zu AWS Directory Service erfolgt über HTTPS, sodass keine Benutzeranmeldeinformationen im Klartext übertragen werden.

Authentifizierung – Active Directory Connector (ADC)

AD Connector verwendet Kerberos, um eine authentifizierte Kommunikation mit On-Premises-AD herzustellen, sodass es an LDAP binden und nachfolgende LDAP-Abfragen ausführen kann. Clientseitige LDAPS-Unterstützung in Bol ist auch für die Verschlüsselung von Abfragen zwischen Microsoft AD und AWS Anwendungen verfügbar. Bevor Sie clientseitige LDAPS-Funktionalität implementieren, überprüfen Sie die Voraussetzungen für clientseitiges LDAPS .

Der AWS Directory Service unterstützt auch LDAP mit TLS. Es werden keine Benutzeranmeldeinformationen im Klartext übertragen. Für mehr Sicherheit ist es möglich, eine WorkSpaces VPC über eine VPN-Verbindung mit dem On-Premises-Netzwerk (in dem sich AD befindet) zu verbinden. Bei Verwendung einer AWS Hardware-VPN-Verbindung können Kunden die Verschlüsselung während der Übertragung einrichten, indem sie Standard-IPSEC (Internet Key Exchange (IKE) und IPSEC-SAs) mit symmetrischen AES-128- oder AES-256-Verschlüsselungsschlüsseln, SHA-1 oder SHA-256 für Integritäts-Hash und DH-Gruppen (2,14-18, 22, 23 und 24 für Phase 1; 1,2,5, 14-18, 22, 23 und 24 für Phase 2) unter Verwendung von Perfect Forward Secrecy (PFS) verwenden.

Broker-Phase

Nach dem Empfang des OAuth-2.0-Tokens (vom Authentifizierungs-Gateway, falls die Authentifizierung erfolgreich war) fragt der Desktop-Client Amazon- WorkSpaces Services (Broker Connection Manager) über HTTPS ab. Der Desktop-Client authentifiziert sich selbst, indem er das OAuth-2.0-Token sendet. Daher erhält der Client die Endpunktinformationen des WorkSpaces Streaming-Gateways.

Streaming-Phase

Der Desktop-Client fordert auf, eine PCoIP-Sitzung mit dem Streaming-Gateway zu öffnen (mit dem OAuth-2.0-Token). Diese Sitzung ist mit AES-256 verschlüsselt und verwendet den PCoIP-Port für die Kommunikationssteuerung (4172/TCP).

Mit dem OAuth2.0-Token fordert das Streaming-Gateway die benutzerspezifischen WorkSpaces Informationen vom Amazon WorkSpaces-Service über HTTPS an.

Das Streaming-Gateway empfängt auch das TGT vom Client (das mit dem Passwort des Client-Benutzers verschlüsselt ist). Durch die Verwendung von Kerberos-TTT-Pass-Through initiiert das Gateway eine Windows-Anmeldung auf dem WorkSpace, wobei das abgerufene Kerberos-TTT des Benutzers verwendet wird.

Das initiiert WorkSpace dann eine Authentifizierungsanforderung an den konfigurierten AWS Directory Service unter Verwendung der Kerberos-Standardauthentifizierung.

Nachdem erfolgreich angemeldet WorkSpace wurde, wird das PCoIP-Streaming gestartet. Die Verbindung wird vom Client auf Port TCP 4172 mit dem Rückverkehr auf Port UDP 4172 initiiert. Darüber hinaus erfolgt die erste Verbindung zwischen dem Streaming-Gateway und einem WorkSpaces Desktop über die Verwaltungsschnittstelle über UDP 55002. (Informationen zu IP-Adressen- und Portanforderungen für Amazon WorkSpaces finden Sie in der Dokumentation. Der anfängliche ausgehende UDP-Port ist 55002.) Die Streaming-Verbindung, die die Ports 4172 (TCP und UDP) verwendet, wird mit 128- und 256-Bit-Verschlüsselungen von AES verschlüsselt, aber standardmäßig auf 128-Bit. Kunden können dies aktiv in 256-Bit ändern, entweder mit PCoIP-spezifischen AD-Gruppenrichtlinieneinstellungen für Windows WorkSpacesoder mit der Datei pcoip-agent.conf für Amazon Linux WorkSpaces. Weitere Informationen zur Gruppenrichtlinienverwaltung für Amazon WorkSpacesfinden Sie in der Dokumentation .

Netzwerkschnittstellen

Jede Amazon WorkSpace verfügt über zwei Netzwerkschnittstellen, die als primäre Netzwerkschnittstelle und Verwaltungsnetzwerkschnittstelle bezeichnet werden.

Die primäre Netzwerkschnittstelle bietet Konnektivität zu Ressourcen innerhalb der Kunden-VPC, z. B. Zugriff auf AWS Directory Service, das Internet und das Unternehmensnetzwerk des Kunden. Es ist möglich, Sicherheitsgruppen an diese primäre Netzwerkschnittstelle anzufügen. Konzeptionell werden die Sicherheitsgruppen anhand des Umfangs der deployment: WorkSpaces security-Gruppe und der ENI-Sicherheitsgruppen unterschieden, die dieser ENI zugeordnet sind.

Verwaltungsnetzwerkschnittstelle

Die Verwaltungsnetzwerkschnittstelle kann nicht über Sicherheitsgruppen gesteuert werden. Kunden können jedoch eine hostbasierte Firewall auf verwenden, WorkSpaces um Ports zu blockieren oder den Zugriff zu steuern. Wir empfehlen nicht, Einschränkungen für die Verwaltungsnetzwerkschnittstelle anzuwenden. Wenn ein Kunde beschließt, hostbasierte Firewall-Regeln hinzuzufügen, um diese Schnittstelle zu verwalten, sollten einige Ports geöffnet sein, damit der Amazon- WorkSpaces Service den Zustand und die Zugänglichkeit für die verwalten kann WorkSpace. Weitere Informationen finden Sie unter Netzwerkschnittstellen im Amazon Workspaces Administration Guide.

WorkSpaces Sicherheitsgruppen

Eine Standardsicherheitsgruppe wird pro AWS Directory Service erstellt und automatisch an alle angefügt WorkSpaces , die zu diesem spezifischen Verzeichnis gehören.

Amazon nutzt WorkSpaceswie viele andere - AWS Services Sicherheitsgruppen. Amazon WorkSpaces erstellt zwei AWS Sicherheitsgruppen, wenn Sie ein Verzeichnis beim WorkSpaces Service registrieren. Eine für Verzeichniscontroller directoryId _controllers und eine für WorkSpaces in Verzeichnis directoryId _workspacesMembers . Löschen Sie keine dieser Sicherheitsgruppen, sonst WorkSpaces wird Ihr beeinträchtigt. Standardmäßig ist der Ausgang der Sicherheitsgruppe des WorkSpaces Mitglieds auf 0.0.0.0/0 geöffnet. Sie können einem Verzeichnis eine WorkSpaces Standardsicherheitsgruppe hinzufügen. Nachdem Sie eine neue Sicherheitsgruppe mit einem WorkSpaces Verzeichnis verknüpft haben, wird die neue Sicherheitsgruppe für neue WorkSpaces , die Sie starten, oder vorhandene , WorkSpaces die Sie neu erstellen, verwendet. Sie können diese neue Standardsicherheitsgruppe auch zu vorhandenen hinzufügen, WorkSpaces ohne sie neu zu erstellen. Wenn Sie einem WorkSpaces Verzeichnis mehrere Sicherheitsgruppen zuordnen, WorkSpaces aggregieren Sie die Regeln aus jeder Sicherheitsgruppe in einem einzigen Regelsatz. Wir empfehlen, Ihre Sicherheitsgruppenregeln so weit wie möglich zu verdichten. Weitere Informationen zu Sicherheitsgruppen finden Sie unter Sicherheitsgruppen für Ihre VPC im Amazon-VPC-Benutzerhandbuch.

Weitere Informationen zum Hinzufügen einer Sicherheitsgruppe zu einem WorkSpaces Verzeichnis oder vorhandenen WorkSpacefinden Sie im WorkSpaces Admin-Handbuch.

Einige Kunden möchten Ports und Ziele einschränken, die der WorkSpaces Datenverkehr verlassen kann. Um den ausgehenden Datenverkehr von der einzuschränken WorkSpaces, müssen Sie sicherstellen, dass Sie bestimmte Ports belassen, die für die Servicekommunikation erforderlich sind. Andernfalls können sich Ihre Benutzer nicht bei ihrer anmelden WorkSpaces.

WorkSpaces verwendet die Elastic Network Interface (ENI) in der Kunden-VPC für die Kommunikation mit den Domain-Controllern während der WorkSpace Anmeldung. Damit sich Ihre Benutzer WorkSpaces erfolgreich bei ihrem anmelden können, müssen Sie den folgenden Ports den Zugriff auf Ihre Domain-Controller oder die CIDR-Bereiche erlauben, die Ihre Domain-Controller in der Sicherheitsgruppe _workspacesMembers enthalten.

  • TCP/UDP 53 – DNS

  • TCP/UDP 88 – Kerberos-Authentifizierung

  • TCP/UDP 389 – LDAP

  • TCP/UDP 445 – SMB

  • TCP 3268-3269 – Globaler Katalog

  • TCP/UDP 464 – Kerberos-Passwortänderung

  • TCP 139 – Netlogon

  • UDP 137-138 – Netlogon

  • UDP 123 – NTP

  • TCP/UDP 49152-65535 Flüchtige Ports für RPC

Wenn Sie auf andere Anwendungen, das Internet oder andere Standorte zugreifen WorkSpaces müssen, müssen Sie diese Ports und Ziele in CIDR-Notation innerhalb der Sicherheitsgruppe _workspacesMembers zulassen. Wenn Sie diese Ports und Ziele nicht hinzufügen, WorkSpaces erreicht nichts anderes als die oben aufgeführten Ports. Eine letzte Überlegung: Standardmäßig hat eine neue Sicherheitsgruppe keine Regeln für eingehenden Datenverkehr. Aus diesem Grund ist kein eingehenden Verkehr von einem anderen Host zu Ihrer Instance erlaubt, bis Sie der Sicherheitsgruppe Regeln für eingehenden Verkehr hinzufügen. Die obigen Schritte sind nur erforderlich, wenn Sie entweder den WorkSpaces ausgehenden Datenverkehr von einschränken möchten oder Eingangsregeln nur auf die Ressourcen oder CIDR-Bereiche beschränkt haben möchten, die Zugriff darauf haben sollen.

Anmerkung

Eine neu zugeordnete Sicherheitsgruppe wird nur angefügt, die nach der Änderung WorkSpaces erstellt oder neu erstellt wurde.

ENI-Sicherheitsgruppen

Da es sich bei der primären Netzwerkschnittstelle um eine reguläre ENI handelt, kann sie mithilfe der verschiedenen AWS Verwaltungstools verwaltet werden. Weitere Informationen finden Sie unter Elastic Network Interfaces. Navigieren Sie zur WorkSpace IP-Adresse (auf der WorkSpaces Seite in der Amazon- WorkSpaces Konsole) und verwenden Sie diese IP-Adresse dann als Filter, um die entsprechende ENI zu finden (im Abschnitt Netzwerkschnittstellen der Amazon EC2-Konsole).

Sobald sich die ENI befindet, kann sie direkt von Sicherheitsgruppen verwaltet werden. Berücksichtigen Sie bei der manuellen Zuweisung von Sicherheitsgruppen zur primären Netzwerkschnittstelle die Portanforderungen von Amazon WorkSpaces. Weitere Informationen finden Sie unter Netzwerkschnittstellen im Administrationshandbuch für Amazon Workspaces.

Screenshot mit einem WorkSpaces Client mit aktivierter MFA

Abbildung 21: WorkSpaces Client mit aktivierter MFA

Netzwerk-Zugriffskontrolllisten (ACLs) (BP5)

Aufgrund der zusätzlichen Komplexität bei der Verwaltung noch einer anderen Firewall werden Netzwerk-ACLs häufig in sehr komplexen Bereitstellungen verwendet und im Allgemeinen nicht als bewährte Methode verwendet. Wenn Netzwerk-ACLs an die Subnetze in der VPC angefügt werden, konzentriert sich ihre Funktion auf Layer 3 (Netzwerk) des OSI-Modells. Da Amazon in Directory Services entwickelt WorkSpaces wurde, müssen zwei Subnetze definiert werden. Netzwerk-ACLs werden getrennt von Directory Services verwaltet, und es ist sehr wahrscheinlich, dass eine Netzwerk-ACL nur einem der WorkSpaceszugewiesenen Subnetze zugewiesen wird.

Wenn eine zustandslose Firewall erforderlich ist, sind Netzwerk-ACLs eine bewährte Methode für die Sicherheit. Stellen Sie sicher, dass alle Änderungen an Netzwerk-ACLs, die über die Standardeinstellungen hinausgehen, als bewährte Methode pro Subnetz validiert werden. Wenn die Netzwerk-ACLs nicht wie vorgesehen funktionieren, sollten Sie VPC-Flow-Protokolle verwenden, um den Datenverkehr zu analysieren.

AWS Netzwerk-Firewall

AWS Network Firewall bietet Funktionen, die über das hinausgehen, was native Sicherheitsgruppen und Netzwerk-ACLs bieten, jedoch zu Kosten. Wenn Kunden nach der Möglichkeit gefragt haben, die Sicherheit in Bezug auf Netzwerkverbindungen wie Server Name Inspection (SNI) für HTTPS-basierte Websites, Intrusion Detection und Prevent sowie eine Zulassungs- und Ablehnungsliste für Domainnamen zu erhöhen, mussten sie keine alternativen Firewalls auf der finden AWS Marketplace. Die Komplexität bei der Bereitstellung dieser Firewalls führte zu Herausforderungen, die über das hinausgehen, was Standard-EUC-Administratoren sind. AWS Die Netzwerk-Firewall bietet eine native AWS Erfahrung und aktiviert gleichzeitig Schutzmechanismen der Ebenen 3 bis 7. Die Verwendung von AWS Network Firewall in Verbindung mit NAT Gateway ist eine bewährte Methode, wenn Organisationen keine anderen Mittel (vorhandene On-Premises-Lizenzierung für Firewalls von Drittanbietern, die in die Cloud übertragen werden können, oder separate Teams, die Firewalls verwalten) haben, um alle EUC-Netzwerkschutzmaßnahmen abzudecken. NAT Gateway ist bei AWS Network Firewall ebenfalls kostenlos.

Bereitstellungen von AWS Network Firewall sind auf das bestehende EUC-Design ausgelegt. Einzelne VPC-Designs können eine vereinfachte Architektur mit Subnetzen für Firewall-Endpunkte und separaten Überlegungen zum Internet-Egress-Routing erreichen, während mehrere VPC-Designs von einer konsolidierten Inspektions-VPC mit Firewall- und Transit-Gateways-Endpunkten profitieren.

Designszenarien

Szenario 1: Grundlegende Instance-Sperre

Die WorkSpaces Standardsicherheitsgruppe lässt keinen eingehenden Datenverkehr zu, da Sicherheitsgruppen standardmäßig verweigert und zustandsbehaftet werden. Das bedeutet, dass keine zusätzlichen Konfigurationen konfiguriert werden müssen, um die WorkSpaces Instances selbst weiter zu sichern. Berücksichtigen Sie die Regeln für ausgehenden Datenverkehr, die den gesamten Datenverkehr zulassen, und ob dies dem Anwendungsfall entspricht. Beispielsweise kann es am besten sein, den gesamten ausgehenden Datenverkehr zu Port 443 für jede Adresse zu verweigern, und bestimmte IP-Bereiche, die Port-Anwendungsfälle wie 389 für LDAP, 636 für LDAPS, 445 für SMB unter anderem erfüllen. Beachten Sie jedoch, dass die Komplexität der Umgebung mehrere Regeln erfordert und daher besser über Netzwerk-ACLs oder eine Firewall-Appliance bedient werden kann.

Szenario 2: Eingehende Ausnahmen

Es ist zwar keine konstante Anforderung, es kann jedoch vorkommen, dass der Netzwerkdatenverkehr in initiiert wird WorkSpaces. Zum Beispiel erfordert das Ausprobieren von Instances, wenn der WorkSpaces Client keine Verbindung herstellen kann, eine alternative Remote-Konnektivität. In diesen Fällen empfiehlt es sich, eingehendes TCP 3389 vorübergehend für die Sicherheitsgruppe der Kunden-ENI WorkSpacedes zu aktivieren.

Ein anderes Szenario sind Organisationsskripte, die Befehle für Bestands- oder Automatisierungsfunktionen ausführen, die von einer zentralen Instance initiiert werden. Die Sicherung des Datenverkehrs auf diesem Port von diesen spezifischen zentralisierten Instances auf dem Inbound kann dauerhaft konfiguriert werden. Es hat sich jedoch bewährt, dies für die zusätzliche Sicherheitsgruppe zu tun, die an die Verzeichniskonfiguration angehängt ist, da sie auf mehrere Bereitstellungen im AWS Konto angewendet werden kann.

Schließlich gibt es etwas Netzwerkverkehr, der nicht zustandsbehaftet ist und erfordert, dass in den Ausnahmen für eingehenden Datenverkehr kurzlebige Ports angegeben werden. Wenn Abfragen und Skripts fehlschlagen, empfiehlt es sich, flüchtige Ports zumindest vorübergehend zuzulassen und gleichzeitig die Ursache für den Verbindungsfehler zu ermitteln.

Szenario 3: Einzelne VPC-Inspektion

Vereinfachte Bereitstellungen von WorkSpaces (z. B. eine einzelne VPC ohne Skalierungspläne) erfordern keine separate VPC zur Überprüfung, sodass die Verbindung zu anderen VPCs mit VPC-Peering vereinfacht werden kann. Für Firewall-Endpunkte müssen jedoch separate Subnetze mit für diese Endpunkte konfiguriertem Routing sowie Internet Gateway (IGW)-Ausgangs-Routing erstellt werden, andernfalls müssten sie nicht konfiguriert werden. Vorhandene Bereitstellungen verfügen möglicherweise nicht über den verfügbaren IP-Speicherplatz, wenn alle Subnetze den gesamten VPC-CIDR-Block verwenden. In diesen Fällen kann Szenario 4 besser sein, da die Bereitstellung bereits über ihr ursprüngliches Design hinaus skaliert wurde.

Szenario 4: Zentralisierte Überprüfung

Wird in mehreren EUC-Bereitstellungen in einer - AWS Region bevorzugt, wodurch die Verwaltung der zustandsbehafteten und zustandslosen Regeln der AWS Network Firewall vereinfacht wird. Vorhandene VPC-Peers werden durch Transit Gateways ersetzt, da dieses Design die Verwendung von Transit Gateway-Anhängen sowie das Inspektions-Routing erfordert, das nur über diese Anhänge konfiguriert werden kann. Ein höherer Grad an Kontrolle wird auch über diese Konfiguration geübt und ermöglicht Sicherheit über die WorkSpaces Standardumgebung hinaus.

Beispielarchitektur mit Transit-Gateway-Anhängen.

Abbildung 22: Beispielarchitektur mit Transit-Gateway-Anhängen

Verschlüsselt WorkSpaces

Jedem Amazon WorkSpace wird ein Root-Volume (C: Laufwerk für Windows WorkSpaces, Root für Amazon Linux WorkSpaces) und ein Benutzer-Volume (D: Laufwerk für Windows WorkSpaces, /home für Amazon Linux ) bereitgestellt WorkSpaces. Die verschlüsselte WorkSpaces Funktion ermöglicht die Verschlüsselung eines oder beider Volumes.

Was ist verschlüsselt?

Die im Ruhezustand gespeicherten Daten, Festplatteneingabe/-ausgabe (I/O) auf dem Volume und Snapshots, die aus verschlüsselten Volumes erstellt wurden, werden alle verschlüsselt.

Wann erfolgt die Verschlüsselung?

Die Verschlüsselung für eine WorkSpace sollte beim Starten (Erstellen) der WorkSpace. WorkSpaces Volumes nur beim Start angegeben werden: Nach dem Start kann der Volume-Verschlüsselungsstatus nicht geändert werden. Die folgende Abbildung zeigt die Amazon- WorkSpaces Konsolenseite zur Auswahl der Verschlüsselung beim Start eines neuen WorkSpace.

Screenshot der WorkSpaces Konsole und wie das Root-Volume verschlüsselt wird

Abbildung 23: Verschlüsseln von WorkSpace Root-Volumes

Wie wird ein neuer WorkSpace verschlüsselt?

Ein Kunde kann die WorkSpaces Option Verschlüsselt entweder über die Amazon- WorkSpaces Konsole oder die oder mithilfe der Amazon WorkSpaces -API auswählen AWS CLI, wenn ein Kunde ein neues startet WorkSpace.

Zum Verschlüsseln der Volumes WorkSpaces verwendet Amazon einen CMK von AWS Key Management Service (AWS KMS). Ein Standard AWS KMS -CMK wird erstellt, wenn ein zum ersten Mal in einer Region gestartet WorkSpace wird. (CMKs haben einen Regionsbereich.)

Ein Kunde kann auch einen vom Kunden verwalteten CMK zur Verwendung mit verschlüsselten erstellen WorkSpaces. Der CMK wird verwendet, um die Datenschlüssel zu verschlüsseln, die vom Amazon- WorkSpaces Service zur Verschlüsselung jedes der WorkSpace Volumes verwendet werden. (In strikter Weise verschlüsselt Amazon EBS die Volumes). Aktuelle CMK-Limits finden Sie unter AWS KMS Ressourcenkontingente.

Anmerkung

Das Erstellen benutzerdefinierter Images aus einem verschlüsselten WorkSpace wird nicht unterstützt. Außerdem kann die WorkSpaces Bereitstellung mit aktivierter Root-Volume-Verschlüsselung bis zu einer Stunde dauern.

Eine detaillierte Beschreibung des WorkSpaces Verschlüsselungsprozesses finden Sie unter Wie Amazon WorkSpaces verwendet AWS KMS. Überlegen Sie, wie die Verwendung von CMK überwacht wird, um sicherzustellen, dass eine Anforderung für einen verschlüsselten korrekt bedient WorkSpace wird. Weitere Informationen zu AWS KMS Schlüsseln und Datenschlüsseln finden Sie auf der AWS KMS Seite .

Optionen für die Zugriffskontrolle und vertrauenswürdige Geräte

Amazon WorkSpaces bietet Kunden Optionen zum Verwalten, auf welche Client-Geräte zugreifen kann WorkSpaces. Kunden können den WorkSpaces Zugriff nur auf vertrauenswürdige Geräte beschränken. Der Zugriff auf WorkSpaces kann von macOS- und Microsoft Windows-PCs mithilfe digitaler Zertifikate erlaubt werden. Es kann auch den Zugriff für iOS-, Android-, Chrome OS-, Linux- und Null-Clients sowie den WorkSpaces Web Access-Client zulassen oder blockieren. Mit diesen Funktionen kann es die Sicherheitslage weiter verbessern.

Die Optionen für die Zugriffskontrolle sind für neue Bereitstellungen aktiviert, damit Benutzer WorkSpaces von Clients unter Windows, MacOS, iOS, Android, ChromeOS und Zero Clients auf ihre zugreifen können. Der Zugriff über Web Access oder einen Linux- WorkSpaces Client ist für eine neue WorkSpaces Bereitstellung standardmäßig nicht aktiviert und muss aktiviert werden.

Wenn es Beschränkungen für den Zugriff auf Unternehmensdaten von vertrauenswürdigen Geräten (auch als verwaltete Geräte bezeichnet) gibt, kann der WorkSpaces Zugriff auf vertrauenswürdige Geräte mit gültigen Zertifikaten beschränkt werden. Wenn diese Funktion aktiviert ist, WorkSpaces verwendet Amazon die zertifikatbasierte Authentifizierung, um festzustellen, ob ein Gerät vertrauenswürdig ist. Wenn die WorkSpaces Clientanwendung nicht überprüfen kann, ob ein Gerät vertrauenswürdig ist, blockiert sie Versuche, sich anzumelden oder erneut eine Verbindung vom Gerät herzustellen.

Unterstützung für vertrauenswürdige Geräte ist für die folgenden Clients verfügbar:

  • Amazon WorkSpaces -Windows-Client-App auf Windows-Geräten

Weitere Informationen zum Steuern, welche Geräte auf zugreifen können WorkSpaces, finden Sie unter WorkSpaces Zugriff auf vertrauenswürdige Geräte beschränken.

Anmerkung

Zertifikate für vertrauenswürdige Geräte gelten nur für Amazon WorkSpaces -Windows-, macOS- und Android-Clients. Diese Funktion gilt nicht für den Amazon- WorkSpaces Web-Access-Client oder Clients von Drittanbietern, einschließlich, aber nicht beschränkt auf Teradici-PCoIP-Software und mobile Clients, Teradici-PCoIP-Zero-Clients, RDP-Clients und Remote-Desktop-Anwendungen.

IP-Zugriffskontrollgruppen

Mithilfe von IP-Adressen-basierten Kontrollgruppen können Kunden Gruppen vertrauenswürdiger IP-Adressen definieren und verwalten und Benutzern WorkSpaces nur dann Zugriff auf ihre gewähren, wenn sie mit einem vertrauenswürdigen Netzwerk verbunden sind. Diese Funktion hilft Kunden, mehr Kontrolle über ihren Sicherheitsstatus zu erhalten.

IP-Zugriffskontrollgruppen können auf WorkSpaces Verzeichnisebene hinzugefügt werden. Es gibt zwei Möglichkeiten, um mit der Verwendung von IP-Zugriffskontrollgruppen zu beginnen.

  • Seite „IP-Zugriffskontrollen“ – Über die - WorkSpaces Managementkonsole können IP-Zugriffskontrollgruppen auf der Seite „IP-Zugriffskontrollen“ erstellt werden. Regeln können diesen Gruppen hinzugefügt werden, indem die IP-Adressen oder IP-Bereiche eingegeben werden, von denen aus auf sie zugegriffen werden WorkSpaces kann. Diese Gruppen können dann auf der Seite Update Details zu Verzeichnissen hinzugefügt werden.

  • Workspace-APIs – WorkSpaces APIs können verwendet werden, um Gruppen zu erstellen, zu löschen und anzuzeigen, Zugriffsregeln zu erstellen oder zu löschen oder Gruppen aus Verzeichnissen hinzuzufügen und zu entfernen.

Eine detaillierte Beschreibung der Verwendung von IP-Zugriffskontrollgruppen mit dem Amazon- WorkSpaces Verschlüsselungsprozess finden Sie unter IP-Zugriffskontrollgruppen für Ihr WorkSpaces.

Überwachung oder Protokollierung mit Amazon CloudWatch

Die Überwachung von Netzwerken, Servern und Protokollen ist ein integraler Bestandteil jeder Infrastruktur. Kunden, die Amazon bereitstellen, WorkSpaces müssen ihre Bereitstellungen überwachen, insbesondere den Gesamtzustand und den Verbindungsstatus einzelner WorkSpaces.

Amazon- CloudWatch Metriken für WorkSpaces

CloudWatch -Metriken für WorkSpaces sollen Administratoren zusätzliche Einblicke in den Gesamtzustand und den Verbindungsstatus einzelner bieten WorkSpaces. Metriken sind pro verfügbar WorkSpaceoder für alle WorkSpaces in einer Organisation innerhalb eines bestimmten Verzeichnisses aggregiert.

Diese Metriken können wie alle CloudWatch Metriken in der AWS Management Console (in der folgenden Abbildung dargestellt), über die CloudWatch APIs aufgerufen und durch CloudWatch Alarme und Tools von Drittanbietern überwacht werden.

Screenshot der Metriken in der Konsole

Abbildung 24: CloudWatch Metriken: ConnectionAttempt / ConnectionFailure

Standardmäßig sind die folgenden Metriken aktiviert und ohne zusätzliche Kosten verfügbar:

  • Verfügbar – WorkSpaces , die auf eine Statusprüfung reagieren, werden in dieser Metrik gezählt.

  • Fehlerhaft – WorkSpaces , die nicht auf dieselbe Statusprüfung reagieren, werden in dieser Metrik gezählt.

  • ConnectionAttempt – Die Anzahl der Verbindungsversuche zu einem WorkSpace.

  • ConnectionSuccess – Die Anzahl der erfolgreichen Verbindungsversuche.

  • ConnectionFailure – Die Anzahl der erfolglosen Verbindungsversuche.

  • SessionLaunchTime – Die Zeit, die benötigt wird, um eine Sitzung zu initiieren, gemessen vom WorkSpaces Client.

  • InSessionLatency – Die Round-Trip-Zeit zwischen dem WorkSpaces Client und WorkSpaces, gemessen und gemeldet vom Client.

  • SessionDisconnect – Die Anzahl der vom Benutzer initiierten und automatisch geschlossenen Sitzungen.

Darüber hinaus können Alarme erstellt werden, wie in der folgenden Abbildung gezeigt.

Screenshot mit einem CloudWatch Alarm für Verbindungsfehler

Abbildung 25: Erstellen eines CloudWatch Alarms für WorkSpaces Verbindungsfehler

Amazon CloudWatch Events für WorkSpaces

Ereignisse von Amazon CloudWatch Events können verwendet werden, um erfolgreiche Anmeldungen bei anzuzeigen, zu suchen, herunterzuladen, zu archivieren, zu analysieren und darauf zu reagieren WorkSpaces. Der Service kann Client-WAN-IP-Adressen, Betriebssystem-, WorkSpaces ID- und Verzeichnis-ID-Informationen für die Anmeldung von Benutzern bei überwachen WorkSpaces. Sie kann beispielsweise Ereignisse für die folgenden Zwecke verwenden:

  • Speichern oder archivieren Sie WorkSpaces Anmeldeereignisse als Protokolle für zukünftige Referenzen, analysieren Sie die Protokolle, um nach Mustern zu suchen, und ergreifen Sie basierend auf diesen Mustern Maßnahmen.

  • Verwenden Sie die WAN-IP-Adresse, um zu bestimmen, von wo aus Benutzer angemeldet sind, und verwenden Sie dann Richtlinien, um Benutzern nur Zugriff auf Dateien oder Daten von zu gewähren WorkSpaces , die die Zugriffskriterien des CloudWatch Ereignistyps WorkSpaces Zugriff erfüllen.

  • Verwenden Sie Richtlinien-Steuerelemente, um den Zugriff auf Dateien und Anwendungen von nicht autorisierten IP-Adressen zu blockieren.

Weitere Informationen zur Verwendung von - CloudWatch Ereignissen finden Sie im Amazon CloudWatch Events-Benutzerhandbuch. Weitere Informationen zu CloudWatch Ereignissen für WorkSpacesfinden Sie unter Überwachen Ihrer WorkSpaces mit Cloudwatch Events.

YubiKey -Unterstützung für Amazon WorkSpaces

Um eine zusätzliche Sicherheitsebene hinzuzufügen, entscheiden sich Kunden häufig dafür, Tools und Websites mit Multifaktor-Authentifizierung zu sichern. Einige Kunden entscheiden sich dafür, dies mit einem Yubico- zu tun YubiKey. Amazon WorkSpaces unterstützt sowohl Einmalpasscodes (OTP) als auch FIDO-U2F-Authentifizierungsprotokoll mit YubiKeys.

Amazon unterstützt WorkSpaces derzeit den OTP-Modus und es sind keine zusätzlichen Schritte erforderlich, die ein Administrator oder Endbenutzer benötigt, um einen YubiKey mit OTP zu verwenden. Der Benutzer kann seine YubiKey an seinen Computer anfügen, sicherstellen, dass die Tastatur in der ausgerichtet ist WorkSpace (insbesondere in dem Feld, in dem das OTP eingegeben werden muss), und den Kontakt „Lift“ auf der anfassenYubiKey. Der YubiKey gibt das OTP automatisch in das ausgewählte Feld ein.

Um den FIDO-U2F-Modus mit YubiKey und zu verwenden WorkSpaces, sind zusätzliche Schritte erforderlich. Stellen Sie sicher, dass Ihren Benutzern eines dieser unterstützten YubiKey Modelle ausgestellt wird, um die U2F-Umleitung mit zu verwenden WorkSpaces:

  • YubiKey 4

  • YubiKey 5 NAT

  • YubiKey 5 Nano

  • YubiKey 5C

  • YubiKey 5C Nano

  • YubiKey 5 NAT

So aktivieren Sie die USB-Umleitung für YubiKey U2F

Standardmäßig ist die USB-Umleitung für PCoIP WorkSpaces deaktiviert. Um den U2F-Modus mit verwenden zu können YubiKeys, müssen Sie sie aktivieren.

  1. Stellen Sie sicher, dass Sie die neueste WorkSpaces administrative Gruppenrichtlinienvorlage für PCoIP (32-Bit) oder die WorkSpaces administrative Gruppenrichtlinienvorlage für PCoIP (64-Bit) installiert haben.

  2. Öffnen Sie bei einer Verzeichnisverwaltung WorkSpace oder einer Amazon EC2-Instance, die mit Ihrem WorkSpaces Verzeichnis verbunden ist, das Gruppenrichtlinienverwaltungstool (gpmc.msc) und navigieren Sie zu PCoIP-Sitzungsvariablen .

  3. Um dem Benutzer zu erlauben, Ihre Einstellung zu überschreiben, wählen Sie Überschreibbare Administratorstandardwerte aus. Wählen Sie andernfalls Keine überschreibbaren Administratorstandards aus.

  4. Öffnen Sie die Einstellung USB in der PCoIP-Sitzung aktivieren/deaktivieren.

  5. Wählen Sie Aktiviert und anschließend OK aus.

  6. Öffnen Sie die Einstellung PCoIP-USB-Geräte für zulässige und unzulässige Geräte konfigurieren.

  7. Wählen Sie Aktiviert aus und konfigurieren Sie unter USB-Autorisierungstabelle eingeben (maximal zehn Regeln) die Regeln für die Zulassungsliste Ihres USB-Geräts.

    1. Autorisierungsregeln – 110500407. Dieser Wert ist eine Kombination aus einer Vendor-ID (VID) und einer Produkt-ID (PID). Das Format für eine VID/PID-Kombination ist 1xxxxyyyy, wobei xxxx die VID im Hexadezimalformat und die PID im Hexadezimalformat yyyy ist. In diesem Beispiel ist 1050 die VID und 0407 die PID. Weitere YubiKey USB-Werte finden Sie unter YubiKey USB-ID-Werte.

  8. Konfigurieren Sie unter USB-Autorisierungstabelle eingeben (maximal zehn Regeln) Ihre USB-Geräte-Blocklistenregeln.

    1. Geben Sie für Nicht-autorisiert-Regel eine leere Zeichenfolge ein. Das bedeutet, dass nur USB-Geräte in der Autorisierungsliste zulässig sind.

      Anmerkung

      Sie können maximal 10 USB-Autorisierungsregeln und maximal 10 USB-Nicht-autorisiert-Regeln definieren. Verwenden Sie den senkrechten Strich (|), um mehrere Regeln voneinander zu trennen. Ausführliche Informationen zu den Autorisierungs-/Nichtautorisierungsregeln finden Sie unter Teradici PCoIP Standard Agent für Windows.

  9. Wählen Sie OK aus.

  10. Die Änderung der Gruppenrichtlinieneinstellung wird nach der nächsten Aktualisierung der Gruppenrichtlinien für die WorkSpace und nach dem Neustart der WorkSpace Sitzung wirksam. Führen Sie einen der folgenden Schritte aus, um die Gruppenrichtlinienänderungen anzuwenden:

    1. Starten Sie die neu WorkSpace (wählen Sie in der Amazon- WorkSpaces Konsole die und WorkSpacedann Aktionen , Neustart aus WorkSpaces).

    2. Geben Sie in einer administrativen Eingabeaufforderung gpupdate /force ein.

  11. Nachdem die Einstellung wirksam ist, können alle unterstützten USB-Geräte zu umgeleitet werden, WorkSpaces es sei denn, es sind Einschränkungen über die Einstellung für USB-Geräteregeln konfiguriert.

Sobald Sie die USB-Umleitung für YubiKey U2F aktiviert haben, können Sie Ihre YubiKey mit dem F Bol-U2F-Modus verwenden.