Zentralisierter Zugriff auf private VPC-Endpunkte

Ein VPC-Endpunkt ermöglicht es Ihnen, Ihre VPC privat mit unterstützten AWS-Services zu verbinden, ohne dass ein Internet-Gateway oder ein NAT-Gerät, eine VPN-Verbindung oder AWS Direct Connect eine Verbindung erforderlich ist. Daher ist Ihre VPC nicht im Internet veröffentlicht. Instances in Ihrer VPC benötigen keine öffentlichen IP-Adressen, um mit AWS-Serviceendpunkten mit diesem Schnittstellenendpunkt zu kommunizieren. Der Datenverkehr zwischen Ihrer VPC und anderen Services verlässt das AWS-Netzwerk-Backbone nicht. VPC Endpunkte sind virtuelle Geräte. Es handelt sich bei ihnen um horizontal skalierte, redundante und hochverfügbare VPC-Komponenten. Derzeit können zwei Arten von Endpunkten bereitgestellt werden: Schnittstellen-Endpunkte (betrieben von AWS PrivateLink) und Gateway-Endpunkte. Gateway-Endpunkte können für den privaten Zugriff auf Amazon S3- und Amazon DynamoDB-Services verwendet werden. Für die Nutzung von Gateway-Endpunkten fallen keine zusätzlichen Gebühren an. Für die Datenübertragung und Ressourcennutzung fallen die Standardgebühren an.

Schnittstellen-VPC-Endpunkte

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 jeder VPC, von der 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 AWS-Service über mehrere VPCs hinweg interagieren möchte, unerschwinglich und schwierig zu verwalten sein. Um dies zu vermeiden, können Sie die Schnittstellenendpunkte in einer zentralen VPC hosten. Alle Spoke-VPCs werden diese zentralisierten Endpunkte über Transit Gateway verwenden.

Wenn Sie einen VPC-Endpunkt für einen AWS Dienst erstellen, können Sie privates DNS aktivieren. Wenn diese Einstellung aktiviert ist, erstellt sie eine von AWS verwaltete private Hosted Zone (PHZ) auf Route 53, die die Auflösung des öffentlichen AWS Dienstendpunkts zur privaten IP des Schnittstellenendpunkts ermöglicht. Die verwaltete PHZ funktioniert nur innerhalb der VPC mit dem Schnittstellenendpunkt. Wenn wir möchten, dass Spoke-VPCs in unserer Konfiguration VPC-Endpunkt-DNS auflösen können, die in einer zentralen VPC gehostet werden, funktioniert die verwaltete PHZ nicht. Um dieses Problem zu umgehen, deaktivieren Sie die Option, mit der das private DNS automatisch erstellt wird, wenn ein Schnittstellenendpunkt erstellt wird. Erstellen Sie als Nächstes manuell eine Route 53-PHZ und fügen Sie einen Alias-Datensatz mit dem vollständigen Namen des AWS-Service-Endpunkts hinzu, der auf den Schnittstellenendpunkt verweist.

1. Melden Sie sich bei der Konsole an und navigieren Sie zu Service Route 53.

2. Wählen Sie die Private Hosted Zone aus und navigieren Sie zu Create Record.

3. Füllen Sie das Feld Datensatzname aus, wählen Sie für Datensatztyp die Option A aus und aktivieren Sie Alias.

4. Wählen Sie im Abschnitt Traffic weiterleiten an den Service aus, an den der Traffic gesendet werden soll, und wählen Sie die Region aus der Dropdownliste aus.

5. Wählen Sie die entsprechende Routing-Richtlinie aus und stellen Sie sicher, dass Sie die Option zur Bewertung des Zielzustands aktivieren.

Sie verknüpfen diese private gehostete Zone mit anderen VPCs innerhalb der Landing Zone. Diese Konfiguration ermöglicht es den Spoke-VPCs, die Full-Service-Endpunktnamen für Schnittstellenendpunkte in der zentralen VPC aufzulösen.

Anmerkung

Um auf die gemeinsam genutzte private Hosting-Zone zuzugreifen, sollten die Hosts in den Spoke-VPCs die Route 53 Resolver-IP ihrer VPC verwenden. Auf Schnittstellenendpunkte kann auch von lokalen Netzwerken aus über VPN und Direct Connect zugegriffen werden. Verwenden Sie Regeln für die bedingte Weiterleitung, um den gesamten DNS-Verkehr für die Full-Service-Endpunktnamen an eingehende Route 53 Resolver-Endpunkte zu senden, die DNS-Anfragen entsprechend der privaten Hosting-Zone auflö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 private Hosting-Zone dafür im Network Services Account und teilen Sie sie mit Spoke-VPCs in den Spoke-Konten. 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 verteilter VPC-Endpunktansatz, d. h. ein Endpunkt pro VPC, ermöglicht es Ihnen, Richtlinien mit den geringsten Rechten auf VPC-Endpoints anzuwenden. Bei einem zentralisierten Ansatz wenden Sie Richtlinien für den gesamten Spoke-VPC-Zugriff auf einem einzigen Endpunkt an und verwalten diese. Mit der wachsenden Anzahl von VPCs 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 von VPC-Endpunkten mit Schnittstellen

Regionsübergreifender Endpunktzugriff

Wenn Sie mehrere VPCs in verschiedenen Regionen einrichten möchten, die sich einen gemeinsamen VPC-Endpunkt teilen, verwenden Sie eine PHZ, wie bereits beschrieben. Beide VPCs in jeder Region werden der PHZ mit dem Alias für den Endpunkt zugeordnet. Um den Verkehr zwischen 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.

VPCs aus verschiedenen Regionen können entweder mithilfe von Transit Gateways oder VPC Peering zueinander geroutet werden. Verwenden Sie die folgende Dokumentation für das Peering von Transit-Gateways: Transit-Gateway-Peering-Anlagen.

In diesem Beispiel verwendet die Amazon EC2 EC2-Instance in der us-west-1 VPC-Region die PHZ, um die private IP-Adresse des Endpunkts in der us-west-2 Region abzurufen und den Datenverkehr über das Transit Gateway Gateway-Peering oder VPC-Peering an die us-west-2 Regions-VPC weiterzuleiten. Bei Verwendung dieser Architektur verbleibt der Datenverkehr innerhalb des AWS-Netzwerks, sodass die EC2-Instance sicher us-west-1 auf den VPC-Service zugreifen kann, us-west-2 ohne über das Internet gehen zu müssen.

VPC-Endpunkte mit mehreren Regionen

Anmerkung

Beim Zugriff auf Endpunkte in verschiedenen Regionen fallen Gebühren für die Datenübertragung zwischen Regionen an.

Unter Bezugnahme auf die vorherige Abbildung wird ein Endpunktdienst in einer VPC in der us-west-2 Region erstellt. Dieser Endpunktservice bietet Zugriff auf einen AWS-Service 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 PHZ einen Adressdatensatz mit einem Alias für den gewünschten VPC-Endpunkt erstellen.

Stellen Sie zunächst sicher, dass die VPCs in jeder Region der von Ihnen erstellten PHZ zugeordnet sind.

Bei der Bereitstellung eines Endpunkts in mehreren Availability Zones stammt die vom DNS zurückgegebene IP-Adresse des Endpunkts aus einem der Subnetze in der zugewiesenen Availability Zone.

Verwenden Sie beim Aufrufen des Endpunkts den vollqualifizierten Domänennamen (FQDN), der sich in der PHZ befindet.

AWS Verified Access

AWS Verified Access bietet sicheren Zugriff auf Anwendungen in privaten Netzwerken ohne VPN. 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 eine NLB-, ALB- oder 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.