Securing Quick access from corporate networks with AWS PrivateLink

Wenn Unternehmensdaten hinter einer Corporate Firewall oder in einem privaten On-Premises-Rechenzentrum liegen, gibt es keinen direkten Netzwerkpfad von AWS, obwohl die AI-Agents und Dashboards in Amazon Quick praktisch jede Datenquelle abfragen können. Administratoren müssen sicherstellen, dass ihre sensiblen Unternehmensdaten nicht dem öffentlichen Internet ausgesetzt sind und gleichzeitig für KI-gestützte Erkenntnisse und Aktionen zugänglich bleiben.

Für viele Unternehmen stellt das Routen von Datenverkehr über das öffentliche Internet ein nicht akzeptables Risiko dar. Regulatorische Rahmenwerke wie HIPAA, FedRAMP und PCI-DSS schreiben häufig vor, dass sensible Daten innerhalb kontrollierter Netzwerkgrenzen bleiben. Selbst wenn Compliance nicht der Hauptgrund ist, vergrößert die Offenlegung interner Datenpfade die Angriffsfläche, erschwert Audit-Trails und führt zu variabler Latenz, die die Benutzererfahrung beeinträchtigen kann.

Diese Anleitung zeigt, wie Sie On-Premises-Datenquellen privat mit Amazon Quick verbinden, ohne dass Datenverkehr das öffentliche Internet durchläuft. Sie setzt voraus, dass Sie bereits AWS Direct Connect oder eine AWS Site-to-Site-VPN-Verbindung haben, die Ihre On-Premises-Umgebung mit Ihrer Virtual Private Cloud (VPC) verbindet. Auf dieser Grundlage konfigurieren wir VPC endpoints, die von AWS PrivateLink betrieben werden, damit Quick Ihre privaten Ressourcen über das AWS-Backbone erreichen kann, und ergänzen anschließend Security Groups und VPC-Endpoint-Policies für eine Defense-in-Depth-Strategie.

Am Ende verfügen Sie über eine Netzwerkarchitektur, die den Datenverkehr zwischen Quick und Ihren On-Premises-Datenquellen vom öffentlichen Internet fernhält, die Angriffsfläche reduziert, eine konsistente Verbindung mit niedriger Latenz bietet und Ihnen einen klaren Audit-Trail für Compliance-Zwecke liefert.

Amazon Quick ist ein KI-gestützter Workspace, der Suche, Analytics, Recherche und Automatisierung in einer einzigen konversationellen Erfahrung zusammenführt. Zu verstehen, welche Komponenten auf Ihr privates Netzwerk zugreifen und wie sie dies tun, bestimmt die Architektur in den folgenden Abschnitten.

Der Datenzugriff in Amazon Quick verläuft über zwei Pfade. Der nutzergerichtete Datenverkehr umfasst alle Personen, die die Quick-Konsole öffnen, mit einem Dashboard interagieren, einen API-Aufruf tätigen oder Quick Desktop verwenden. All dies wird über VPC endpoints geroutet (siehe VPC endpoints für Nutzer- und API-Zugriff), wodurch Nutzersitzungen das öffentliche Internet nicht durchqueren.

Datenabruf-Datenverkehr liegt vor, wenn Quick selbst in Ihr Netzwerk greift, um Daten zu ziehen. Dies wird über VPC connections abgewickelt (siehe VPC connections für den Datenquellenzugriff), und hier liegen die meisten architektonischen Entscheidungen. Die Features und Integrationen, die Datenabruf-Verbindungen initiieren, sind:

Diese beiden Datenverkehrspfade erfordern zwei unterschiedliche Mechanismen für private Konnektivität, die zusammenarbeiten:

Dieser Abschnitt geht der Reihe nach die vier Bausteine durch: VPC endpoints für Nutzer- und API-Zugriff, VPC connections für den Datenquellenzugriff, VPC endpoints für AWS-Datendienste und ausgehenden Zugriff auf erforderliche externe Domains.

Bevor Sie die private Konnektivität für Quick konfigurieren, stellen Sie sicher, dass Folgendes vorhanden ist:

VPC endpoints, die von PrivateLink betrieben werden, verarbeiten den gesamten nutzergerichteten Datenverkehr zu Amazon Quick, einschließlich der Website, API-Aufrufen und eingebetteten Inhalten. Sie verhindern, dass Nutzer das öffentliche Internet durchqueren müssen, um auf die Amazon-Quick-Konsole zuzugreifen.

Abbildung 1: Privater Zugriff auf Amazon Quick aus einem Corporate-Rechenzentrum über einen VPC endpoint

Wie in Abbildung 1 dargestellt: (1) Ein Client im Unternehmensnetzwerk sendet eine Anfrage an Quick; (2) die Anfrage läuft über AWS Direct Connect, durch das Direct Connect Gateway in Ihre VPC; (3) der Quick-VPC-Endpoint prüft die Endpoint-Policy und erlaubt oder verweigert die Anfrage; (4) erlaubte Anfragen erreichen Amazon Quick über das AWS-Netzwerk.

Planen Sie bei der Entwicklung Ihrer Endpoint-Architektur zunächst die AWS-Region, in der Ihr Quick-Konto bereitgestellt ist, da sich VPC endpoints in derselben Region befinden müssen. Wählen Sie Subnets über mehrere Availability Zones für die Platzierung der Endpoint-ENIs und stellen Sie sicher, dass diese Subnets Routen zu Ihrem On-Premises-Netzwerk über Direct Connect oder VPN haben.

Entwerfen Sie Security Groups, die den Datenverkehr auf den Endpoint-ENIs auf nur die erforderlichen Ports und Quellbereiche beschränken. Wenn der gesamte Datenverkehr privat geroutet werden soll (einschließlich der Aufrufe, die Amazon Quick an Amazon S3, Amazon Redshift und Amazon Athena richtet), planen Sie auch VPC endpoints für diese Dienste (siehe Konfiguration von Datenquellen-VPC endpoints).

Quick benötigt zwei Interface-VPC-Endpoints für vollständigen privaten Zugriff:

Hinweis: Nicht jede Quick-API ist über den API-VPC-Endpoint verfügbar. Die folgenden 13 APIs werden nicht unterstützt: die Action-Connector-APIs (CreateActionConnector, DeleteActionConnector, DescribeActionConnector, DescribeActionConnectorPermissions, ListActionConnectors, SearchActionConnectors, UpdateActionConnector, UpdateActionConnectorPermissions) und die Flow-APIs (GetFlowMetadata, GetFlowPermissions, ListFlows, SearchFlows, UpdateFlowPermissions). Automatisierungen, die Action Connectors oder Flows programmatisch verwalten, benötigen einen Pfad zum öffentlichen API-Endpoint. Siehe Quick und Interface-VPC-Endpoints.

Wenn sich Administratoren über die VPC als IAM-Nutzer bei Amazon Quick anmelden, erstellen Sie zusätzlich die AWS Management Console Endpoints:

So erstellen Sie den Website-Endpoint in der Amazon Virtual Private Cloud (Amazon VPC)-Konsole:

Abbildung 2: Benennen des Endpoints und Auswählen des Quick-Website-Endpoint-Service

Abbildung 3: Auswählen der VPC, des privaten DNS, der Subnets und der Security Group für den Endpoint

Abbildung 4: Auswählen der Endpoint-Policy und Erstellen des Endpoints

Für den Website-Endpoint erstellen Sie einen A-Record für <region>.quicksight.aws.amazon.com und verweisen ihn auf den DNS-Namen des VPC-Endpoints. Auf diese Weise wird bei der Auflösung der Quick-URL durch Nutzer in Ihrem Unternehmensnetzwerk der Datenverkehr über den privaten Endpoint statt über das öffentliche Internet geroutet. Für den API-Endpoint reicht es aus, privates DNS auf dem VPC-Endpoint zu aktivieren, da API-Aufrufe automatisch zu den privaten IP-Adressen des Endpoints aufgelöst werden.

Eine private Route 53 Hosted Zone antwortet nur auf Abfragen aus den VPCs, die mit ihr verknüpft sind. Da Ihre Nutzer sich aus dem Unternehmensnetzwerk verbinden, konfigurieren Sie Ihre On-Premises-DNS-Server so, dass Abfragen für <region>.quicksight.aws.amazon.com an einen Route 53 Resolver Inbound Endpoint in der VPC weitergeleitet werden (oder hosten Sie einen äquivalenten Record in Ihrem On-Premises-DNS). Validieren Sie abschließend die DNS-Auflösung aus Ihrem Unternehmensnetzwerk, um zu bestätigen, dass Anfragen zu privaten IPs innerhalb Ihrer VPC statt zu öffentlichen Adressen aufgelöst werden.

Abbildung 5: Erstellen einer privaten Hosted Zone in Amazon Route 53

Abbildung 6: Erstellen eines Records in der neuen privaten Hosted Zone

Abbildung 7: Erstellen eines Alias-A-Records, der auf den Quick-Website-VPC-Endpoint verweist

VPC-Endpoint-Policies beschränken, welche Accounts oder Organisationen den Endpoint nutzen dürfen. Bei Quick können Policies nach AWS-Account-ID oder Organization ID eingegrenzt werden. Um eine Policy zu ändern, öffnen Sie den Endpoint in der Amazon VPC-Konsole, wählen Sie den Tab Policy und wählen Sie Edit Policy (Abbildung 8).

Wichtige Einschränkung: Für den Quick-Website-Endpoint müssen die Felder Principal, Action und Resource alle auf * gesetzt sein. Conditions können nur gegen die Attribute aws:PrincipalAccount oder aws:OrgId angegeben werden. Restriktivere Policies auf Action-Ebene werden nur auf dem API-Endpoint unterstützt.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalAccount": ["012345678901"] } } } ] } Abbildung 8: Öffnen der Endpoint-Policy über die Detailseite des VPC-Endpoints

Beispiel einer API-Endpoint-Policy (eingeschränkt auf bestimmte Aktionen):

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": [ "quicksight:DescribeUser", "quicksight:ListUsers" ], "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalAccount": ["012345678901"] } } } ] } Abbildung 9: Bearbeiten einer benutzerdefinierten VPC-Endpoint-Policy

Während VPC endpoints den nutzergerichteten Datenverkehr verarbeiten, übernehmen VPC connections den serverseitigen Pfad, das heißt, Amazon Quick greift in Ihre VPC zu, um auf Datenbanken, Amazon Redshift Knowledge-Base-Quellen und interne APIs zuzugreifen.

Amazon Quick Enterprise Edition ist vollständig in Amazon VPC integriert. Wenn Sie eine VPC connection in Amazon Quick erstellen, fügen Sie elastische Netzwerkschnittstellen (ENIs) in Ihre VPC-Subnets ein. Diese ENIs ermöglichen Quick den Austausch von Netzwerkverkehr mit Ressourcen innerhalb Ihrer VPC und damit auch mit allem, was von dieser VPC aus erreichbar ist, einschließlich On-Premises-Systemen, die über Direct Connect oder VPN verbunden sind.

Alle standardmäßigen VPC-Sicherheitskontrollen gelten für diesen Datenverkehr. Route Tables, Network ACLs, Subnets und Security Groups steuern den Datenverkehr zu und von Quick auf dieselbe Weise, wie sie den Datenverkehr zwischen allen anderen Instanzen in Ihrer VPC steuern. Das bedeutet, Sie können Verbindungen herstellen zu:

Erstellen Sie eine dedizierte Security Group (zum Beispiel QuickSight-VPC) für die ENIs der VPC connection. Erlauben Sie in der Security Group jeder Datenquelle eingehenden Datenverkehr auf dem Datenbankport von dieser Security-Group-ID aus.

Hinweis für VPC-Verbindungen, die vor dem 27. April 2023 erstellt wurden: Die der Quick-Netzwerkschnittstelle zugeordnete Sicherheitsgruppe ist nicht stateful. Sie müssen eine Inbound-Regel hinzufügen, die explizit Rückverkehr von der Sicherheitsgruppe Ihrer Datenquelle auf allen Ports (0 bis 65535) erlaubt, da Rückpakete zufällig zugewiesene Zielports verwenden. Verbindungen, die nach diesem Datum erstellt wurden, verwenden das standardmäßige stateful-Verhalten. Siehe Security groups: inbound and outbound rules.

Amazon Quick erstellt die Ausführungsrolle der VPC-Verbindung nicht für Sie. Bevor Sie die Verbindung hinzufügen, erstellen Sie eine dedizierte IAM-Rolle (empfohlen) oder aktualisieren Sie eine vorhandene Rolle, die Quick bereits vertraut, wie beispielsweise die aws-quicksight-service-role-v0, die in den Screenshots dieses Beitrags verwendet wird. Die Rolle benötigt:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:ModifyNetworkInterfaceAttribute", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource": "*" } ] } Abbildung 10: Hinzufügen der von der Ausführungsrolle der VPC-Verbindung benötigten Amazon-EC2-Berechtigungen

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "quicksight.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } Konfiguration einer VPC-Verbindung So erstellen Sie eine VPC-Verbindung in der Quick-Konsole:

Abbildung 11: Aufrufen von Manage account über das Quick-Profilmenü

Abbildung 12: Manage VPC connections unter Security auf der Seite Manage account

Abbildung 13: Hinzufügen einer VPC-Verbindung in der Quick-Konsole

Der Verbindungsstatus zeigt UNAVAILABLE an, bis Quick die Bereitstellung der ENIs abgeschlossen hat, und wechselt dann zu AVAILABLE. Der Status PARTIALLY AVAILABLE bedeutet, dass eines der ENIs nicht verfügbar ist, die Verbindung jedoch weiterhin verwendet werden kann.

VPC-Endpunkte (PrivateLink, das hier für AWS-Service-APIs verwendet wird) und VPC-Verbindungen (Quick-ENIs, die in Ihrer VPC platziert werden; siehe VPC connections for data source access) sind unterschiedliche Mechanismen. Quick greift beim Abrufen von Daten für Dashboards und Analysen auf andere AWS-Services zu (Amazon S3, Amazon Redshift, Amazon Athena, AWS Secrets Manager). Wenn der gesamte Verkehr privat bleiben soll, einschließlich der Aufrufe, die Amazon Quick an diese AWS-Services richtet, erstellen Sie Interface- oder Gateway-VPC-Endpunkte für jeden davon:

* Athena wird als Datenquelle für VPC-Verbindungen nicht unterstützt. Der Athena-Endpunkt hält den Athena-API-Verkehr ausschließlich auf AWS PrivateLink.

Erstellen Sie diese Endpunkte in derselben VPC, in der sich die Amazon-Quick-ENIs befinden. Stellen Sie sicher, dass Routingtabellen und Sicherheitsgruppen den Verkehr zwischen den Amazon-Quick-Subnetzen und den Endpunkt-Subnetzen zulassen.

Während der Datenverkehr zwischen Quick und Ihren lokalen Quellen im privaten Netzwerk bleibt, müssen die Browser der Benutzer dennoch eine Reihe von Domains für Anmeldung, statische Assets, clientseitige Metriken und Integrationen erreichen. Selbst wenn VPC-Endpunkte konfiguriert sind, benötigen Domains ohne VPC-Endpunkt-Unterstützung ausgehende Konnektivität, typischerweise über Ihren Unternehmensproxy oder Ihre Firewall. Wenn Ihr Konto IAM Identity Center verwendet, erfordert die Browseranmeldung zusätzlich die öffentlichen AWS-Anmelde- und IAM-Identity-Center-Endpunkte (siehe Secure user access and identity federation).

Nachdem Ihre Endpunkte konfiguriert und getestet wurden, können Sie erzwingen, dass jeder Zugriff auf Ihr Quick-Konto über den VPC-Endpunkt erfolgen muss, und so den allgemeinen Internetzugang vollständig blockieren. Benutzer können Quick dadurch nur noch über den von Ihnen eingerichteten privaten Pfad aus Ihrem Unternehmensnetzwerk erreichen.

Quick bietet IP- und VPC-Endpunkt-Einschränkungssteuerungen, die den Kontozugriff auf eine vordefinierte Liste von IP-Bereichen, VPC-IDs oder VPC-Endpunkt-IDs beschränken. Sie können beispielsweise eine Regel erstellen, die den Zugriff nur über den VPC-Endpunkt erlaubt, der für Direct Connect verwendet wird, sodass jeder Versuch, Quick aus dem öffentlichen Internet zu erreichen, abgelehnt wird.

So konfigurieren Sie es über die Quick-Konsole (nur Administratoren, die mit IAM-Anmeldedaten angemeldet sind, können auf die Einschränkungsseite zugreifen):

Abbildung 14: Hinzufügen einer VPC-Endpunkt-Regel auf der Seite IP and VPC endpoint restrictions

Alternativ können Sie die Konfiguration über das AWS Command Line Interface (AWS CLI) vornehmen:

aws quicksight update-ip-restriction \ --aws-account-id ACCOUNT_ID \ --region REGION \ --enabled \ --vpc-endpoint-id-restriction-rule-map \ vpce-001122def=CorporateVpcEndpoint Hinweis: UpdateIpRestriction ersetzt die gesamte Regelzuordnung. Rufen Sie Ihre aktuellen Regeln mit aws quicksight describe-ip-restriction ab und berücksichtigen Sie alle vorhandenen Regeln im Update.

Nachdem Sie die Einschränkungen durchgesetzt haben, kann nur Verkehr, der über den angegebenen VPC-Endpunkt (oder die erlaubten IP-Bereiche) eintrifft, Ihr Quick-Konto erreichen. Jeder andere Zugriff wird abgelehnt.

Private Netzwerkkonnektivität hält den Verkehr vom öffentlichen Internet fern, beantwortet jedoch nicht die Frage, wer innerhalb von Quick auf was zugreifen kann. Dieser Abschnitt behandelt, wie Sie Ihren unternehmenseigenen Identitätsanbieter integrieren, die Benutzerbereitstellung steuern und eine feingranulare Zugriffssegmentierung über die Quick-Komponenten hinweg durchsetzen.

Wichtig: Für Quick-Konten, die in IAM Identity Center integriert sind, erfordert die browserbasierte Authentifizierung den Zugriff auf die öffentlichen AWS-Anmelde- und IAM-Identity-Center-Endpunkte. VPC-Endpunkte stellen diesen Browser-Anmeldepfad nicht bereit. Öffentliche IP-Adressen sind nicht erforderlich. Stellen Sie die ausgehende Konnektivität über ein NAT-Gateway oder einen Proxy bereit. Siehe Considerations for private access im IAM Identity Center User Guide.

Amazon Quick nutzt AWS IAM Identity Center als zentralen Punkt für das Identity-Management der Belegschaft. IAM Identity Center verbindet sich über SAML 2.0 für die Authentifizierung und SCIM 2.0 für die automatische Bereitstellung von Benutzern und Gruppen mit Ihrem vorhandenen unternehmenseigenen Identitätsanbieter (IdP). Dies bietet:

Eine Schritt-für-Schritt-Anleitung zum Einrichten von IAM Identity Center mit Ihrem Identitätsanbieter finden Sie unter Getting started with IAM Identity Center.

Quick unterstützt drei Basisrollen, die bestimmen, was ein Benutzer tun kann:

Diese Rollen werden IAM-Rollen zugeordnet, die föderierte Benutzer bei der Anmeldung annehmen. Durch die Verwaltung der Rollenzuweisung in Ihrem IdP haben Sie eine einzige zentrale Quelle dafür, wer über welches Zugriffsniveau verfügt.

Zusätzlich unterstützt Quick benutzerdefinierte Berechtigungsprofile, die die Standardberechtigungen der Rollen auf Konto-, Rollen- oder Benutzerebene überschreiben können. Berechtigungen auf Benutzerebene überschreiben die auf Rollenebene, welche wiederum die auf Kontoebene überschreiben. Dies gibt Administratoren eine granulare Kontrolle, die über die drei Basisrollen hinausgeht.

Quick Spaces bieten eine zusätzliche Ebene der Zugriffssegmentierung über die Rollen hinaus. Jeder Space kann mit spezifischen Benutzer- und Gruppenberechtigungen konfiguriert werden, was bedeutet:

Der Zugriff auf Space-Ebene wird durch die von Ihrem Identitätsanbieter synchronisierten Gruppen gesteuert, sodass ein neues Teammitglied automatisch Zugriff auf die relevanten Spaces erhält, sobald es der entsprechenden Gruppe hinzugefügt wird.

Für Dashboards, die auf strukturierten Daten basieren, unterstützt Quick Sight eine Zeilenebene-Sicherheit (RLS), die einschränkt, welche Datenzeilen jeder Benutzer oder jede Gruppe sehen kann. RLS wird über Dataset-Regeln konfiguriert, bei denen es sich um ein Berechtigungs-Dataset handelt, das Benutzer oder Gruppen den Feldwerten zuordnet, auf die sie zugreifen können.

Ein regionales Vertriebs-Dashboard kann beispielsweise so konfiguriert werden, dass:

RLS-Regeln werden anhand der Identität des Benutzers ausgewertet, wie sie durch IAM Identity Center bestimmt wird, was bedeutet, dass dieselbe Identitätsföderation, die die Anmeldung steuert, auch den Zugriff auf Datenebene regelt. Dies gilt gleichermaßen für herkömmliche Dashboard-Ansichten und KI-gestützte Abfragen in natürlicher Sprache. Dieselben Sicherheitsrichtlinien beschränken, auf welche Daten die KI bei der Generierung von Antworten verweisen kann.

Zusätzlich zu Einschränkungen auf Zeilenebene unterstützt Quick Sight eine Spaltenebene-Sicherheit (CLS), um sensible Spalten vor bestimmten Benutzern oder Gruppen zu verbergen. Ein Dataset mit Mitarbeiterinformationen könnte beispielsweise die Spalten für Gehalt und Sozialversicherungsnummer nur für die Personalabteilung zugänglich machen, während andere Gruppen weiterhin auf die nicht sensiblen Spalten desselben Datasets zugreifen können.

Die Identitätsebene und die Netzwerkebene arbeiten zusammen:

Abgesehen vom Anmelde- und Statische-Assets-Verkehr, der unter Enabling access to required external domains beschrieben wird, durchläuft kein Verkehr das öffentliche Internet, und an jedem Punkt bestimmt die Identität des Benutzers, was er sehen und tun kann.

Bevor Sie Einschränkungen in der Produktionsumgebung durchsetzen, validieren Sie die Ende-zu-Ende-Konnektivität für jedes Zugriffsmuster:

Für laufende Transparenz aktivieren Sie VPC Flow Logs auf allen Endpunkt- und VPC-Verbindungs-ENIs, um Verkehrsmetadaten zu erfassen. Überwachen Sie die CloudWatch-Metriken der VPC-Endpunkte (ActiveConnections, BytesProcessed, PacketsDropped) und richten Sie Alarme für Verbindungsfehler oder unerwartete Verkehrsquellen ein. Diese Protokolle dienen auch als Audit-Trail, auf den in Ihren Compliance-Dokumentationen verwiesen wird.

Weder Netzwerkisolation noch Identitätssteuerungen allein sind ausreichend. Diese Architektur stützt sich auf beides: Netzwerksteuerungen verhindern unbefugte Zugriffspfade, während Identitätssteuerungen unbefugten Datenzugriff innerhalb autorisierter Sitzungen verhindern. Die folgenden Praktiken pflegen beide Ebenen.

Die folgenden Beispiele zeigen, wie die Konfiguration in diesem Beitrag gängige Anforderungen an die Netzwerksicherheit erfüllen kann. Bewerten Sie diese gemeinsam mit Ihrem Sicherheitsteam im Hinblick auf Ihre eigenen Anforderungen.

Diese Architektur etabliert vier sich ergänzende Kontrollmechanismen: VPC-Endpunkte halten den Nutzerverkehr privat, VPC-Verbindungen bieten Quick einen privaten Pfad zu Ihren Datenquellen, die Identitätsföderation legt fest, wer auf was zugreifen darf, und die Einschränkungen über VPC-Endpunkte machen den privaten Pfad zur Pflicht. Jede Ebene ist unabhängig prüfbar und lässt sich bestimmten Compliance-Anforderungen zuordnen (siehe Compliance mapping).

Mit dieser Einrichtung können Quick Agents Ihre lokalen Datenbanken abfragen, Quick Research Unternehmensquellen hinter der Firewall untersuchen, Quick Sight Dashboards sensible Daten visualisieren und Quick Flows interne Systeme orchestrieren, alles ganz ohne dass Ihre Daten das öffentliche Internet durchqueren. Die KI-Funktionen bleiben unverändert. Die Angriffsfläche wird entfernt.

Für die Umsetzung beginnen Sie mit den VPC-Endpunkten für den Nutzer- und API-Zugriff und validieren Sie den Nutzerzugriff, bevor Sie zu den VPC-Verbindungen für den Zugriff auf Datenquellen übergehen. Aktivieren Sie die Einschränkungen über VPC-Endpunkte erst, nachdem Sie bestätigt haben, dass alle Zugriffsmuster über den privaten Pfad funktionieren. Für die Einrichtung der Identitätsföderation und die erweiterte Konfiguration von RLS/CLS konsultieren Sie die Dokumentation zu IAM Identity Center.

Rahul ist Spezialist für Generative AI und Machine Learning bei AWS und unterstützt Organisationen im Finanzdienstleistungssektor dabei, KI-Workloads von der Experimentierphase in die Produktion zu überführen. Sein besonderes Interesse gilt der Frage, wie Banken, Investmentgesellschaften und Fintechs Generative AI für Research, Kundenbindung und wissensintensive Workflows einsetzen können. In seiner Freizeit reist Rahul gerne und fiebert mit den Boston Red Sox mit.

Yago ist Solutions Architect bei AWS mit Sitz in London und spezialisiert auf Generative AI, Amazon Bedrock und agentische Frameworks. Er hilft Organisationen, KI-Prototypen in produktionsreife Lösungen zu überführen. Am Wochenende ist er vermutlich beim Laufen oder beim Erkunden der Stadt, oder beides gleichzeitig.

Zain ist Solutions Architect bei AWS mit Sitz in Schweden und spezialisiert auf Generative AI. Er arbeitet mit Kunden zusammen, um deren geschäftliche Herausforderungen zu verstehen und in sichere, skalierbare Lösungen zu übersetzen, die echte Ergebnisse liefern. In seiner Freizeit verbringt er gerne Zeit mit Familie und Freunden, häufig bei einem Film oder beim Kochen.