Sicherung des LLM-Zugriffs mit vertrauenswürdigen Egress-IPs

Der Zugriff auf die meisten gehosteten LLM-Endpunkte ist durch einen gemeinsamen API-Schlüssel geschützt, der in Clientkonfigurationen codiert ist. API-Schlüssel lassen sich problemlos bereitstellen, sind aber leicht zu teilen, weiterzugeben oder abzugreifen — und da LLM-Inferenzberechnung teuer ist, können nicht autorisierte Nutzungen zu erheblichen und unerwarteten Kosten führen.

Dies ist sowohl ein Sicherheitsproblem als auch ein Problem der Kostenkontrolle.

Jamfs Network Relay in Kombination mit vertrauenswürdigen Egress-IP-Beschränkungen behebt diese Lücke mit einem Zero-Touch-Ansatz.

Das Problem: API-Schlüssel allein reichen nicht aus

Ein typisches Bereitstellungsbeispiel für gehostete LLM:

Die Organisation stellt ein Modell (z. B. Llama 3, Mistral oder eine angepasste Variante) auf interner Infrastruktur oder in einer Cloud-VPC (AWS, Azure, GCP) bereit.
Ein API-Endpunkt wird verfügbar gemacht — häufig OpenAI-kompatibel — der Anfragen akzeptiert, die mit einem gemeinsamen API-Schlüssel authentifiziert sind.
Der API-Schlüssel wird über Konfigurationsprofile, MDM, Umgebungsvariablen oder Entwicklerdokumentation an Clients verteilt.

Das Problem besteht darin, dass API-Schlüssel statische, langfristige Geheimnisse sind, die leicht weitergegeben werden können:

Ein Entwickler kopiert den Schlüssel in ein persönliches Projekt oder Notizbuch.
Der Schlüssel wird in ein Git-Repository committet (auch in ein privates).
Ein Mitarbeiter teilt den Schlüssel mit einem nicht autorisierten Kollegen oder Auftragnehmer.
Ein Gerät mit dem konfigurierten Schlüssel geht verloren oder wird kompromittiert.

Sobald ein Schlüssel bekannt ist, kann jeder damit Ihre LLM-Ressourcen von jedem Gerät, jedem Netzwerk, überall nutzen. Da LLM-Inferenz je nach Modell und Eingabelänge von Bruchteilen eines Cents bis zu mehreren Dollar pro Anfrage kosten kann, können nicht autorisierte Nutzungen erhebliche Rechnungen verursachen — oder schlimmer noch, vertrauliche interne Daten offenlegen, wenn das Modell auf proprietäre Informationen abgestimmt wurde.

Herkömmliche Maßnahmen wie Schlüsselrotation helfen, führen aber zu operativer Komplexität und lösen das Grundproblem nicht:

Der Schlüssel allein kann nicht überprüfen, dass die Anfrage von einem vertrauenswürdigen, verwalteten Gerät stammt.

Die Lösung: Network Relay + Vertrauenswürdige Egress-IP-Sperrung

Jamfs Network Relay, basierend auf Apples nativem MASQUE-Protokoll und Managed Device Attestation (MDA), ermöglicht es Organisationen, den Zugriff auf LLM-Endpunkte auf verifizierten, verwalteten Apple-Geräten zu beschränken — ohne jegliche Benutzerinteraktion erforderlich.

Die Architektur:

1. Datenverkehr von verwalteten Geräten wird über die Jamf Security Cloud geleitet

Wenn Network Relay über MDM bereitgestellt wird, wird der gesamte für die Domäne Ihres LLM-Endpunkts bestimmte Datenverkehr automatisch über die Jamf Security Cloud unter Verwendung verschlüsselter MASQUE/HTTP3-Tunnel geleitet. Die Identität des Geräts wird durch hardwaregebundene Schlüssel aus dem Apple Secure Enclave mittels Managed Device Attestation kryptografisch überprüft, sodass nur echte, unternehmensmanagierte Geräte diese Tunnel einrichten können.

2. Datenverkehr geht über bekannte Jamf-IP-Adressen ab

Nachdem der Datenverkehr die Jamf Security Cloud durchlaufen hat und evaluiert wurde, geht er (egress) ins Internet — und damit zu Ihrem LLM-Endpunkt — von einem bekannten, deterministischen Satz von Jamf-IP-Adressen. Diese können sein:

Gemeinsame Egress-IPs aus einer der Jamf globalen Datencenter-Regionen.
Dedizierte Egress-IPs, die Ihrer Organisation eindeutig zugewiesen sind — mit zwei hochverfügbaren öffentlichen IPs pro Region, die kein anderer Jamf-Kunde nutzt.

3. Ihr LLM-Endpunkt beschränkt den Zugriff auf vertrauenswürdige IPs

Nachdem Ihr Datenverkehr jetzt von einem bekannten und vertrauenswürdigen Satz von IP-Adressen ankommt, konfigurieren Sie Ihre LLM-Infrastruktur so, dass sie nur Verbindungen von diesen Jamf-Egress-IPs akzeptiert — alle anderen lehnt ab. Dies ist Standard-IP-Whitelisting auf Netzwerkebene:

Cloud-gehostete LLMs (AWS/Azure/GCP): Konfigurieren Sie Security Groups, Network Security Groups oder Firewall-Regeln, um nur eingehende HTTPS-Verbindungen (TCP/443) von Ihren Jamf-Egress-IPs zuzulassen. Ein Beispiel für AWS Bedrock finden Sie unten Link zu Überschrift
On-Premise-LLMs: Konfigurieren Sie Ihre Edge-Firewall oder einen Reverse Proxy (z. B. nginx, HAProxy, Caddy), um nur Verbindungen von den Jamf-Egress-IP-Bereichen zu akzeptieren.
API Gateway / LLM Proxy (z. B. LiteLLM, OpenWebUI): Viele LLM-Gateway-Lösungen unterstützen IP-Whitelisting auf Anwendungsebene als zusätzliche Defense-in-Depth-Maßnahme.

Das Ergebnis: Selbst wenn ein API-Schlüssel weitergegeben wird, ist er nutzlos, es sei denn, die Anfrage stammt von einem verwalteten Gerät, das über Ihren Jamf Security Cloud-Mandanten geleitet wird.

Warum Network Relay

Der Hauptunterschied zu traditionellen, auf VPN basierenden IP-Sperrungen ist das Zero-Touch-, No-Agent-Bereitstellungsmodell:

Keine App-Installation erforderlich. Network Relay wird vollständig über MDM-Konfigurationsprofile konfiguriert, die von Jamf Pro bereitgestellt werden. Es gibt keinen VPN-Client zum Installieren, keine erforderliche Jamf Trust-App für grundlegende Relay-Funktionalität und keinen Benutzer-Login oder Aktivierungsschritt.
Keine Benutzerinteraktion. Nachdem das Relay-Profil auf einem verwalteten Gerät installiert ist, aktiviert es sich automatisch. Der Benutzer sieht keinen VPN-Umschalter, gibt keine Anmeldedaten für Netzwerkzugriff ein und wird nicht unterbrochen. Datenverkehr zu den definierten LLM-Domänen wird transparent geleitet.
Hardwaregebundene Geräte-Vertrauenswürdigkeit. Managed Device Attestation nutzt den Apple Secure Enclave, um kryptografisch nachzuweisen, dass ein Gerät echte Apple-Hardware ist, von Ihrer Organisation über MDM verwaltet wird und nicht manipuliert wurde. Dies bietet ein stärkeres Identitätssignal als reine Software-Agenten.
Präzision pro Domäne. Im Gegensatz zu einem Full-Tunnel-VPN, der den gesamten Datenverkehr leitet, arbeitet Network Relay auf Pro-Domänen-Basis. Sie definieren genau, welche Domänen (z. B. llm.internal.yourcompany.com) über Jamf geleitet werden sollen — während der gesamte andere Datenverkehr unverändert bleibt. Dies minimiert die Leistungsauswirkungen und vermeidet die „Alles-oder-Nichts"-Kompromisse von Legacy-VPN-Architekturen.
Funktioniert auf allen Apple-Plattformen. Network Relay wird auf macOS, iOS, iPadOS und visionOS unterstützt und kann von einer einzigen Konfiguration aus verwaltet werden.

*Anm. Es ist auch möglich, IP-Sperrung mit Jamfs ZTNA-Lösung auf Non-Apple-Plattformen zu verwenden.

Bereitstellungsübersicht

Die folgenden Schritte beschreiben die End-to-End-Konfiguration:

Schritt 1: Konfigurieren Sie Egress in der Jamf Security Cloud

Navigieren Sie in der Jamf Security Cloud (RADAR)-Konsole zu Integrations > Access Gateways und vermerken Sie entweder Ihre Shared Egress IPs für Ihre bevorzugte Region, oder erstellen Sie ein Dedicated Internet Gateway mit zwei eindeutigen öffentlichen IPs, die ausschließlich Ihrer Organisation zugewiesen sind.

Für dedizierte Gateways können Sie mehrere regionale Gateways erstellen und gruppieren, sodass Geräte automatisch den nächstgelegenen Egress-Punkt basierend auf ihrer Verbindung zur Jamf Security Cloud verwenden.

Schritt 2: Erstellen Sie eine Access Policy für Ihren LLM-Endpunkt

Navigieren Sie zu Policies > Access Policies und erstellen Sie eine neue Policy:

Definieren Sie die Domäne(n) Ihres LLM-Endpunkts (z. B. llm.yourcompany.com, api.ai.internal.yourcompany.com).
Legen Sie das Routing fest, um Ihr ausgewähltes Egress-Gateway (gemeinsam oder dediziert) zu verwenden.
Konfigurieren Sie die Policy so, dass sie auf die entsprechenden Gerätegruppen angewendet wird.

Schritt 3: Stellen Sie das Network Relay-Profil bereit

Navigieren Sie zu Devices > Activation Profiles und erstellen oder aktualisieren Sie Ihr Network Relay-Aktivierungsprofil:

Unter Service Capabilities stellen Sie sicher, dass Zero Trust Network Access ausgewählt ist.
Unter Authentication wählen Sie Managed Device Attestation für Zero-Touch-, passwortlose Aktivierung.
Stellen Sie die resultierenden Konfigurationsprofile über Jamf Pro auf Ihren verwalteten Geräten bereit.

Nach der Bereitstellung leiten Geräte automatisch Datenverkehr zu Ihren LLM-Domänen über die Jamf Security Cloud.

Schritt 4: Sperren Sie Ihren LLM-Endpunkt auf Jamf-Egress-IPs

Beschränken Sie auf der LLM-Infrastrukturseite eingehende Zugriffe nur auf Ihre Jamf-Egress-IP-Adressen. Beispiele:

AWS Security Group:

Inbound Rule:
  Type: HTTPS (TCP 443)
  Source: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  Description: Jamf Trusted Devices Only

nginx Reverse Proxy:

server {
    listen 443 ssl;
    server_name llm.yourcompany.com;

    # Only allow Jamf egress IPs
    allow <Jamf Egress IP 1>;
    allow <Jamf Egress IP 2>;
    deny all;

    location / {
        proxy_pass http://localhost:8080;  # Your LLM inference server
    }
}

Azure Network Security Group:

Inbound security rule:
  Priority: 100
  Source: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  Destination port: 443
  Protocol: TCP
  Action: Allow

Inbound security rule:
  Priority: 200
  Source: Any
  Destination port: 443
  Protocol: TCP
  Action: Deny

Schritt 5: Validierung und Überwachung

Überprüfen Sie von einem verwalteten Gerät mit bereitgestelltem Relay-Profil, dass Anfragen an Ihren LLM-Endpunkt erfolgreich sind.
Überprüfen Sie von einem nicht verwalteten Gerät (oder mit entferntem Relay-Profil), dass Anfragen blockiert werden.
Überwachen Sie Zugriffsprotokolle in Ihrer LLM-Infrastruktur, um zu überprüfen, dass alle eingehenden Verbindungen von Ihren erwarteten Jamf-Egress-IPs stammen.
Überprüfen Sie Verbindungsprotokolle in der Jamf Security Cloud im Abschnitt Reports > Access, um zu sehen, welche Benutzer und Geräte auf den LLM-Endpunkt zugreifen.

Erweiterung auf verwaltete LLM-Services: AWS Bedrock

Der gleiche Ansatz für vertrauenswürdige Egress-IPs gilt über selbstgehostete Modelle hinaus. Wenn Ihre Organisation Amazon Bedrock für verwaltete LLM-Inferenz nutzt, können Sie IP-basierte Beschränkungen mithilfe von AWS IAM-Richtlinien mit aws:SourceIp-Bedingungen durchsetzen — um sicherzustellen, dass nur Anfragen, die von Ihren Jamf-Egress-IPs stammen, Bedrock-Modelle aufrufen können.

Im Gegensatz zu selbstgehosteten Bereitstellungen, bei denen Sie die Netzwerkebene steuern (Security Groups, Firewalls), ist Bedrock ein vollständig verwalteter AWS-Service. Sie konfigurieren keine eingehenden Firewall-Regeln in Bedrock selbst. Stattdessen fügen Sie IAM-Richtlinien an, die den Modellaufruf verweigern, es sei denn, die Anfrage stammt von einer vertrauenswürdigen IP.

IAM-Deny-Richtlinie: Bedrock-Aufruf nach Quell-IP einschränken

Fügen Sie die folgende Richtlinie den IAM-Benutzern, Rollen oder Gruppen an, die Bedrock-Zugriff haben. Das explizite Deny überschreibt alle Allow-Anweisungen und stellt sicher, dass Bedrock-Aufrufe blockiert werden, es sei denn, sie stammen von Ihren Jamf-Egress-IPs:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyBedrockUnlessTrustedIP",
            "Effect": "Deny",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "arn:aws:bedrock:*:*:model/*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "<Jamf Egress IP 1>/32",
                        "<Jamf Egress IP 2>/32"
                    ]
                }
            }
        }
    ]
}

Diese Richtlinie ermöglicht alle anderen Bedrock-Berechtigungen (z. B. Auflisten von Modellen, Verwalten bereitgestellten Durchsatzes) normalerweise zu funktionieren — sie beschränkt nur die Inferenzaufrufsaktionen auf vertrauenswürdige IPs. Wenn Ihre vorhandenen IAM-Richtlinien bereits explizite DENY-Regeln enthalten, müssen Sie möglicherweise stattdessen eine explizite ALLOW-Anweisung für vertrauenswürdige IPs hinzufügen.

Service Control Policy (SCP) für organisationsweite Durchsetzung

Wenn Sie die IP-Beschränkung über alle AWS-Konten in Ihrer Organisation durchsetzen möchten — nicht nur einzelne IAM-Prinzipale — wenden Sie sie als SCP in AWS Organizations an:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceBedrockIPRestriction",
            "Effect": "Deny",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "<Jamf Egress IP 1>/32",
                        "<Jamf Egress IP 2>/32"
                    ]
                },
                "BoolIfExists": {
                    "aws:ViaAWSService": "false"
                }
            }
        }
    ]
}

Die aws:ViaAWSService-Bedingung ist enthalten, damit das Deny nicht versehentlich Bedrock-Aufrufe blockiert, die von anderen AWS-Services in Ihrem Namen durchgeführt werden (z. B. eine Lambda-Funktion, die Bedrock innerhalb Ihrer VPC aufruft, Step Functions-Workflows, die Bedrock aufrufen, oder SageMaker-Notebooks, die Bedrock für Inferenz nutzen). Es stellt sicher, dass die IP-Beschränkung nur auf direkte API-Aufrufe — genau dem Pfad, den End-User-Geräte durch das Jamf Relay verwenden — angewendet wird.

Wichtige Überlegungen für Bedrock

aws:SourceIp gilt für direkte API-Aufrufe über das öffentliche Internet. Dies ist der erwartete Pfad, wenn Datenverkehr von einem verwalteten Gerät → Jamf Security Cloud → Jamf-Egress-IP → AWS Bedrock API-Endpunkt fließt.
VPC-Endpunktzugriff: Wenn Sie auch Bedrock über einen VPC-Endpunkt aufrufen, wird aws:SourceIp nicht evaluiert. Verwenden Sie aws:VpcSourceIp oder VPC-Endpunktrichtlinien, um den Zugriff in diesem Pfad separat zu steuern.
Bedrock-regionsübergreifende Inferenz: Wenn Sie Inferenzprofile über Regionen hinweg verwenden, stellen Sie sicher, dass Ihre Richtlinie Resource die relevanten Regionen abdeckt, oder verwenden Sie ein Wildcard wie oben gezeigt.
Testen: Verwenden Sie den IAM Policy Simulator oder führen Sie Test-InvokeModel-Aufrufe sowohl von einem verwalteten Gerät (sollte erfolgreich sein) als auch von einem nicht verwalteten Gerät (sollte AccessDenied erhalten) durch, um die Richtlinie vor breiterer Bereitstellung zu überprüfen.

Defense in Depth: Schichtung von IP-Sperrung mit API-Schlüsseln

Es ist wichtig zu beachten, dass IP-basierte Zugriffsbeschränkung API-Schlüsselauthentifizierung ergänzt — sie ersetzt sie nicht. Das empfohlene Vorgehen besteht darin, beide Kontrollen zu schichten:

Schicht	Kontrolle	Was es beweist
Netzwerk	Jamf-Egress-IP-Whitelist	Anfrage stammt von einem verwalteten, attestierten Gerät
Anwendung	API-Schlüssel / Token	Anfrage ist für den spezifischen LLM-Service autorisiert
(Optional) Identität	IdP-Integration / OAuth	Anfrage ist an einen spezifischen authentifizierten Benutzer gebunden

Mit diesem geschichteten Ansatz müsste ein Angreifer gleichzeitig über einen gültigen API-Schlüssel verfügen und von einem Jamf-verwalteten, hardwareattestierten Gerät aus operieren — eine erheblich höhere Hürde als nur eine dieser Kontrollen.

Zusammenfassung

Selbstgehostete LLMs stellen ein erhebliches Infrastruktur-Engagement für Organisationen dar, die ihre Daten, Kosten und AI-Lieferkette kontrollieren müssen. Dieses Engagement wird untergraben, wenn der Zugriff nur auf gemeinsamen API-Schlüsseln beruht, die weitergegeben werden können und von jedem Gerät im Internet aus verwendet werden können.

Das Bereitstellen von Network Relay mit vertrauenswürdigen Egress-IP-Beschränkungen bietet:

Kryptografische Geräte-Vertrauenswürdigkeit, die in Apple-Hardware-Attestation verwurzelt ist, nicht in einem Software-Token oder gemeinsamen Geheimnis.
Zero-Touch-, No-Agent-Bereitstellung ohne VPN-Clients, keine Benutzerinteraktion und keine Aktivierungsschritte.
Deterministische Quell-IP-Adressen, die unkompliziertes IP-Whitelisting auf jeder LLM-Infrastruktur ermöglichen.
Präzisions-Routing pro Domäne, das die Leistungs- und Datenschutz-Kompromisse von Full-Tunnel-VPNs vermeidet.
Geschichterte Sicherheit, die netzwerkgestützte Geräte-Vertrauenswürdigkeit mit anwendungsseitiger API-Authentifizierung kombiniert.

Das Ergebnis ist, dass nur vertrauenswürdige, verwaltete Geräte die LLM-Infrastruktur erreichen können, ohne dass Änderungen an Benutzer-Workflows erforderlich sind.

Anleitungen