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.
Zentralisierter Zugriff auf VPC private Endgeräte
Ein VPC Endpunkt ermöglicht es Ihnen, sich privat mit unterstützten AWS Diensten VPC zu verbinden, ohne dass ein Internet-Gateway oder ein NAT Gerät, eine VPN Verbindung oder eine AWS Direct Connect Verbindung erforderlich ist. Daher sind Sie VPC nicht dem öffentlichen Internet ausgesetzt. Instanzen in Ihrem System VPC benötigen keine öffentlichen IP-Adressen, um mit AWS Dienstendpunkten mit diesem Schnittstellenendpunkt zu kommunizieren. Der Datenverkehr zwischen Ihnen VPC und anderen Diensten verlässt das AWS Netzwerk-Backbone nicht. VPCEndpunkte sind virtuelle Geräte. Es handelt sich um horizontal skalierte, redundante und hochverfügbare Komponenten. VPC Derzeit können zwei Arten von Endpunkten bereitgestellt werden: Schnittstellen-Endpunkte (betrieben von AWS PrivateLink
VPC-Schnittstellenendpunkte
Ein Schnittstellenendpunkt besteht aus einer oder mehreren elastischen Netzwerkschnittstellen mit einer privaten IP-Adresse, die als Einstiegspunkt für Datenverkehr dient, der für einen unterstützten Service bestimmt ist. AWS Wenn Sie einen Schnittstellenendpunkt bereitstellen, fallen für jede Stunde, in der der Endpunkt läuft, Kosten sowie Datenverarbeitungsgebühren an. Standardmäßig erstellen Sie in jedem, VPC von dem aus Sie auf den AWS Service zugreifen möchten, einen Schnittstellenendpunkt. Dies kann in der Landing Zone-Konfiguration, in der ein Kunde mit einem bestimmten Service über mehrere kommunizieren möchte, unerschwinglich und schwierig zu verwalten sein. AWS VPCs Um dies zu vermeiden, können Sie die Schnittstellen-Endpunkte zentral hosten. VPC Alle Spoke VPCs werden diese zentralisierten Endpunkte über Transit Gateway nutzen.
Wenn Sie einen VPC Endpunkt für einen AWS Dienst erstellen, können Sie Private DNS aktivieren. Wenn diese Einstellung aktiviert ist, erstellt sie eine AWS verwaltete private gehostete Route 53-Zone (PHZ), die die Auflösung des öffentlichen AWS Dienstendpunkts in die private IP des Schnittstellenendpunkts ermöglicht. Die verwaltete PHZ Option funktioniert nur innerhalb des Endpunkts VPC mit der Schnittstelle. In unserem Setup funktioniert der verwaltete Endpunkt PHZ nicht, wenn wir möchten, dass Spoke VPCs in der Lage ist, die Lösung von VPC Endgeräten zu behebenVPC, die in einem zentralen System DNS gehostet werden. Um dieses Problem zu umgehen, deaktivieren Sie die Option, mit der DNS bei der Erstellung eines Schnittstellenendpunkts automatisch ein privater Endpunkt erstellt wird. Erstellen Sie als Nächstes manuell eine private gehostete Route 53-Zone, die dem Namen des Dienstendpunkts entspricht, und fügen Sie einen Alias-Datensatz hinzu, bei dem der vollständige AWS-Service Endpunktname auf den Schnittstellenendpunkt verweist.
-
Melden Sie sich bei Route 53 an AWS Management Console und navigieren Sie zu Route 53.
-
Wählen Sie die privat gehostete Zone aus und navigieren Sie zu Create Record.
-
Füllen Sie das Feld Datensatzname aus, wählen Sie für Datensatztyp die Option A aus und aktivieren Sie Alias.
Beachten Sie, dass für einige Dienste, wie z. B. die Docker- und OCI Client-Endpunkte (
dkr.ecr), ein Platzhalteralias (*) für den Datensatznamen verwendet werden muss. -
Wählen Sie im Abschnitt Traffic weiterleiten an den Dienst aus, an den der Datenverkehr gesendet werden soll, und wählen Sie die Region aus der Dropdownliste aus.
-
Wählen Sie die entsprechende Routing-Richtlinie aus und aktivieren Sie die Option „Zustand des Ziels bewerten“.
Sie verknüpfen diese private gehostete Zone mit anderen VPCs innerhalb der Landing Zone. Diese Konfiguration ermöglicht es SpokeVPCs, die Full-Service-Endpunktnamen für Schnittstellenendpunkte in der zentralen Umgebung aufzulösen. VPC
Anmerkung
Um auf die gemeinsam genutzte private Hosting-Zone zuzugreifen, VPCs sollten die Hosts in der Spoke ihre eigene Route 53 Resolver-IP verwenden. VPC Auf Schnittstellenendpunkte kann auch von lokalen Netzwerken aus über VPN Direct Connect zugegriffen werden. Verwenden Sie Regeln für die bedingte Weiterleitung, um den gesamten DNS Datenverkehr für die Full-Service-Endpunktnamen an eingehende Route 53 Resolver-Endpunkte zu senden, die DNS Anfragen entsprechend der privaten Hosting-Zone lösen.
In der folgenden Abbildung ermöglicht Transit Gateway den Verkehrsfluss von den Spoke VPCs zu den zentralen Schnittstellenendpunkten. Erstellen Sie VPC Endpoints und die dafür vorgesehene private Hosting-Zone im Network Services-Konto und geben Sie sie für VPCs Spoke-in-the-Spoke-Konten frei. Weitere Informationen zum Teilen von Endpunktinformationen mit anderen VPCs finden Sie im Blogbeitrag Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver
Anmerkung
Ein Ansatz mit verteilten VPC Endpunkten, d. h. ein Endpunkt pro, VPC ermöglicht es Ihnen, Richtlinien mit den geringsten Zugriffsrechten auf VPC Endpunkte anzuwenden. Bei einem zentralisierten Ansatz werden Sie Richtlinien für alle VPC Spoke-Zugriffe auf einem einzigen Endpunkt anwenden und verwalten. Mit der wachsenden Anzahl von VPCs Benutzern kann die Komplexität der Beibehaltung der geringsten Rechte mit einem einzigen Richtliniendokument zunehmen. Ein einziges Strategiedokument führt auch zu einem größeren Explosionsradius. Die Größe des Richtliniendokuments ist ebenfalls begrenzt (20.480 Zeichen).
Zentralisierung der Schnittstellenendpunkte VPC
Regionsübergreifender Endpunktzugriff
Wenn Sie mehrere Geräte in verschiedenen Regionen VPCs einrichten möchten, die sich einen gemeinsamen VPC Endpunkt teilen, verwenden SiePHZ, wie bereits beschrieben, einen. Beide VPCs in jeder Region werden PHZ mit dem Alias für den Endpunkt verknüpft. Um den Verkehr VPCs in einer Architektur mit mehreren Regionen weiterzuleiten, müssen die Transit-Gateways in jeder Region miteinander verbunden werden. Weitere Informationen finden Sie in diesem Blog: Using Route 53 Private Hosted Zones for Cross-account Multi-Region-Architectures
VPCsaus verschiedenen Regionen können entweder mithilfe von Transit Gateways oder Peering zueinander weitergeleitet werden. VPC Verwenden Sie die folgende Dokumentation für das Peering von Transit-Gateways: Transit-Gateway-Peering-Anlagen.
In diesem Beispiel verwendet die EC2 Amazon-Instance in der VPC us-west-1 Region die, PHZ um die private IP-Adresse des Endpunkts in der us-west-2 Region abzurufen und den Datenverkehr VPC über das Transit Gateway Gateway-Peering oder VPC -Peering an die us-west-2 Region weiterzuleiten. Bei dieser Architektur verbleibt der Datenverkehr im AWS Netzwerk, sodass die EC2 Instance auf sichere Weise auf den VPC Service zugreifen kann, us-west-2 ohne das Internet nutzen us-west-1 zu müssen.
VPCEndpunkte mit mehreren Regionen
Anmerkung
Beim Zugriff auf Endpunkte in verschiedenen Regionen fallen Gebühren für die Datenübertragung zwischen Regionen an.
Gemäß der vorherigen Abbildung wird ein Endpunktdienst VPC in einer Region eingerichtet. us-west-2 Dieser Endpunktdienst bietet Zugriff auf einen AWS Dienst in dieser Region. Damit Ihre Instances in einer anderen Region (z. B.us-east-1) auf den Endpunkt in der us-west-2 Region zugreifen können, müssen Sie in der einen Adressdatensatz PHZ mit einem Alias für den gewünschten VPC Endpunkt erstellen.
Stellen Sie zunächst sicher, dass die VPCs in jeder Region mit den von Ihnen PHZ erstellten verknüpft sind.
Wenn Sie einen Endpunkt in mehreren Availability Zones bereitstellen, stammt die IP-Adresse des Endpunkts, von dem zurückgegeben DNS wird, aus einem der Subnetze in der zugewiesenen Availability Zone.
Verwenden Sie beim Aufrufen des Endpunkts den vollqualifizierten Domänennamen (FQDN), der sich in der befindet. PHZ
AWS Verified Access
AWS Verified Access bietet sicheren Zugriff auf Anwendungen in privaten Netzwerken ohneVPN. Es wertet Anfragen wie Identität, Gerät und Standort in Echtzeit aus. Dieser Dienst gewährt auf der Grundlage von Richtlinien Zugriff auf Anwendungen und verbindet die Benutzer, wodurch die Sicherheit des Unternehmens verbessert wird. Verified Access ermöglicht den Zugriff auf private Anwendungen, indem es als identitätsbewusster Reverse-Proxy fungiert. Benutzeridentität und Geräteintegrität werden, falls zutreffend, vor der Weiterleitung des Datenverkehrs an die Anwendung geprüft.
Das folgende Diagramm bietet einen allgemeinen Überblick über Verified Access. Benutzer senden Anfragen für den Zugriff auf eine Anwendung. Verified Access bewertet die Anfrage anhand der Zugriffsrichtlinie für die Gruppe und aller anwendungsspezifischen Endpunktrichtlinien. Wenn der Zugriff erlaubt ist, wird die Anfrage über den Endpunkt an die Anwendung gesendet.
Überblick über den verifizierten Zugriff
Die Hauptkomponenten einer AWS Verified Access Architektur sind:
-
Verifizierte Zugriffsinstanzen — Eine Instanz bewertet Anwendungsanfragen und gewährt Zugriff nur, wenn Ihre Sicherheitsanforderungen erfüllt sind.
-
Verifizierte Zugriffsendpunkte — Jeder Endpunkt steht für eine Anwendung. Ein Endpunkt kann NLB eine ALB oder eine Netzwerkschnittstelle sein.
-
Gruppe mit verifiziertem Zugriff — Eine Sammlung von Endpunkten mit verifiziertem Zugriff. Wir empfehlen, die Endpunkte für Anwendungen mit ähnlichen Sicherheitsanforderungen zu gruppieren, um die Richtlinienverwaltung zu vereinfachen.
-
Zugriffsrichtlinien — Eine Reihe von benutzerdefinierten Regeln, die festlegen, ob der Zugriff auf eine Anwendung erlaubt oder verweigert wird.
-
Trust Providers — Verified Access ist ein Dienst, der die Verwaltung von Benutzeridentitäten und Gerätesicherheitsstatus erleichtert. Er ist sowohl mit Vertrauensanbietern als auch mit Drittanbietern kompatibel AWS und erfordert, dass jeder Verified Access-Instanz mindestens ein Vertrauensanbieter zugeordnet ist. Jede dieser Instanzen kann einen einzelnen Identity Trust Provider sowie mehrere Device Trust Provider umfassen.
-
Vertrauensdaten — Die Sicherheitsdaten, die Ihr Vertrauensanbieter an Verified Access sendet, wie z. B. die E-Mail-Adresse eines Benutzers oder die Gruppe, zu der er gehört, werden bei jedem Eingang einer Anwendungsanfrage anhand Ihrer Zugriffsrichtlinien bewertet.
Weitere Informationen finden Sie in den Blogbeiträgen von Verified Access
