LLM-toegang Beveiligen met Vertrouwde Egress-IP's

Toegang tot de meeste gehoste LLM-endpoints wordt beschermd door een gedeelde API-sleutel die is gecodeerd in clientconfiguraties. API-sleutels zijn eenvoudig te implementeren maar gemakkelijk te delen, lekken of exfiltreren — en met LLM-inferentie-compute dat duur is, kan ongeautoriseerd gebruik aanzienlijke en onverwachte kosten genereren.

Dit is zowel een beveiligingsprobleem als een kostenbeheerprobeem.

Jamf's Network Relay gecombineerd met vertrouwde egress-IP-beperkingen pakt deze kloof aan met een zero-touch-aanpak.

Het Probleem: API-sleutels Alleen Zijn Niet Genoeg

Een typisch gehost LLM-implementatievoorbeeld:

De organisatie implementeert een model (bijv. Llama 3, Mistral of een gefinetuned variant) op interne infrastructuur of binnen een cloud VPC (AWS, Azure, GCP).
Een API-endpoint wordt blootgesteld — vaak OpenAI-compatibel — dat verzoeken accepteert die zijn geauthenticeerd met een gedeelde API-sleutel.
De API-sleutel wordt gedistribueerd naar clients via configuratieprofielen, MDM, omgevingsvariabelen of ontwikkelaarsdocumentatie.

Het probleem is dat API-sleutels statische, langlevende secrets zijn die gemakkelijk kunnen lekken:

Een ontwikkelaar kopieert de sleutel naar een persoonlijk project of notebook.
De sleutel wordt gecommit naar een Git-repository (zelfs een private).
Een werknemer deelt de sleutel met een ongeautoriseerde collega of contractor.
Een apparaat met de geconfigureerde sleutel raakt verloren of gecompromitteerd.

Zodra een sleutel in het wild is, kan iedereen ermee uw LLM-bronnen consumeren vanaf elk apparaat, elk netwerk, overal. Aangezien LLM-inferentie overal van fracties van een cent tot meerdere dollars per verzoek kan kosten, afhankelijk van het model en de promptlengte, kan ongeautoriseerd gebruik substantiële rekeningen genereren — of erger, gevoelige interne gegevens blootstellen als het model is gefinetuned op eigen informatie.

Traditionele mitigaties zoals sleutelrotatie helpen, maar introduceren operationele complexiteit en lossen het fundamentele probleem niet op:

De sleutel alleen kan niet verifiëren dat het verzoek afkomstig is van een vertrouwd, beheerd apparaat.

De Oplossing: Network Relay + Vertrouwde Egress-IP-vergrendeling

Jamf's Network Relay, gebouwd op Apple's native MASQUE-protocol en Managed Device Attestation (MDA), stelt organisaties in staat om LLM-endpoint-toegang te beperken tot geverifieerde, beheerde Apple-apparaten — met nul eindgebruikersinteractie vereist.

De architectuur:

1. Verkeer van Beheerde Apparaten Loopt via Jamf Security Cloud

Wanneer Network Relay via MDM wordt geïmplementeerd, wordt al het verkeer bestemd voor het domein van uw LLM-endpoint automatisch getunneld via Jamf's Security Cloud met behulp van versleutelde MASQUE/HTTP3-tunnels. De identiteit van het apparaat wordt cryptografisch geverifieerd met behulp van hardware-gebonden sleutels van de Apple Secure Enclave via Managed Device Attestation, zodat alleen echte, door het bedrijf beheerde apparaten deze tunnels kunnen opzetten.

2. Verkeer Verlaat via Bekende Jamf IP-adressen

Zodra verkeer door de Jamf Security Cloud en beleidsevaluatie gaat, verlaat het (egress) naar het internet — en dus naar uw LLM-endpoint — vanaf een bekende, deterministische set Jamf IP-adressen. Deze kunnen zijn:

Gedeelde egress-IP's van een van Jamf's wereldwijde datacenterregio's.
Toegewijde egress-IP's die uniek aan uw organisatie zijn toegewezen — met twee hoog beschikbare publieke IP's per regio die geen andere Jamf-klant gebruikt.

3. Uw LLM-endpoint Beperkt Toegang tot Alleen Vertrouwde IP's

Nu uw verkeer aankomt vanaf een bekende en vertrouwde set IP-adressen, configureert u uw LLM-infrastructuur om alleen verbindingen te accepteren van die Jamf egress-IP's — alle andere worden geweigerd. Dit is standaard IP-allowlisting toegepast op de netwerklaag:

Cloud-gehoste LLM's (AWS/Azure/GCP): Configureer Security Groups, Network Security Groups of firewallregels om alleen inkomend HTTPS (TCP/443) toe te staan vanaf uw Jamf egress-IP's. Zie hieronder voor een voorbeeld op AWS Bedrock Link naar Mijn Kop
On-premise LLM's: Configureer uw edge-firewall of reverse proxy (bijv. nginx, HAProxy, Caddy) om alleen verbindingen te accepteren van de Jamf egress-IP-bereiken.
API Gateway / LLM Proxy (bijv. LiteLLM, OpenWebUI): Veel LLM-gateway-oplossingen ondersteunen IP-allowlisting op de applicatielaag als een extra defense-in-depth-maatregel.

Het resultaat: zelfs als een API-sleutel lekt, is deze nutteloos tenzij het verzoek afkomstig is van een beheerd apparaat dat via uw Jamf Security Cloud-tenant routeert.

Waarom Network Relay

Het belangrijkste verschil met traditionele VPN-gebaseerde IP-vergrendeling is het zero-touch, zero-agent implementatiemodel:

Geen app-installatie vereist. Network Relay wordt volledig geconfigureerd via MDM-configuratieprofielen die worden geïmplementeerd vanuit Jamf Pro. Er is geen VPN-client om te installeren, geen Jamf Trust-app vereist voor basale relay-functionaliteit en geen gebruikersaanmelding of activatiestap.
Geen gebruikersinteractie. Zodra het relay-profiel is geïnstalleerd op een beheerd apparaat, wordt het automatisch geactiveerd. De gebruiker ziet geen VPN-schakelaar, voert geen inloggegevens in voor netwerktoegang en wordt niet onderbroken. Verkeer naar de gedefinieerde LLM-domeinen wordt transparant getunneld.
Hardware-geworteld apparaatvertrouwen. Managed Device Attestation gebruikt de Apple Secure Enclave om cryptografisch te bewijzen dat een apparaat echte Apple-hardware is, beheerd door de MDM van uw organisatie en niet is gemanipuleerd. Dit biedt een sterkere identiteitssignaal dan alleen-software-agents.
Per-domein precisie. In tegenstelling tot een full-tunnel VPN die al het verkeer routeert, werkt Network Relay op per-domein-basis. U definieert precies welke domeinen (bijv. llm.internal.yourcompany.com) moeten worden getunneld via Jamf — alle andere verkeer blijft onaangetast. Dit minimaliseert prestatie-impact en vermijdt de "alles of niets"-afweging van legacy VPN-architecturen.
Werkt op alle Apple-platformen. Network Relay wordt ondersteund op macOS, iOS, iPadOS en visionOS, en kan worden beheerd vanuit een enkele configuratie.

*N.b. Het is ook mogelijk om IP-vergrendeling te gebruiken met Jamf's ZTNA-oplossing op niet-Apple-platformen.

Implementatieoverzicht

De volgende stappen schetsen de end-to-end-configuratie:

Stap 1: Configureer Egress in Jamf Security Cloud

Navigeer in de Jamf Security Cloud (RADAR)-console naar Integraties > Access Gateways en noteer uw Gedeelde egress-IP's voor uw voorkeursregio, of maak een Dedicated Internet Gateway om twee unieke publieke IP's te ontvangen die exclusief aan uw organisatie zijn toegewezen.

Voor dedicated gateways kunt u meerdere regionale gateways maken en groeperen zodat apparaten automatisch het dichtstbijzijnde egresspunt gebruiken op basis van hun verbinding met de Jamf Security Cloud.

Stap 2: Maak een Toegangsbeleid voor Uw LLM-endpoint

Navigeer naar Beleid > Toegangsbeleid en maak een nieuw beleid:

Definieer het domein(en) van uw LLM-endpoint (bijv. llm.yourcompany.com, api.ai.internal.yourcompany.com).
Stel de routering in om uw gekozen egress-gateway te gebruiken (gedeeld of dedicated).
Configureer het beleid om toe te passen op de juiste apparaatgroepen.

Stap 3: Implementeer het Network Relay-profiel

Navigeer naar Apparaten > Activatieprofielen en maak of update uw Network Relay-activatieprofiel:

Onder Servicemogelijkheden, zorg ervoor dat Zero Trust Network Access is geselecteerd.
Onder Authenticatie, selecteer Managed Device Attestation voor zero-touch, wachtwoordloze activering.
Implementeer de resulterende configuratieprofielen naar uw beheerde apparaten via Jamf Pro.

Eenmaal geïmplementeerd, zullen apparaten automatisch beginnen met het routeren van verkeer naar uw LLM-domeinen via de Jamf Security Cloud.

Stap 4: Vergrendel Uw LLM-endpoint naar Jamf Egress-IP's

Aan de kant van de LLM-infrastructuur, beperk inkomende toegang tot alleen uw Jamf egress-IP-adressen. Voorbeelden:

AWS Security Group:

Inbound Rule:
  Type: HTTPS (TCP 443)
  Source: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  Description: Alleen Jamf Vertrouwde Apparaten

nginx reverse proxy:

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

    # Alleen Jamf egress-IP's toestaan
    allow <Jamf Egress IP 1>;
    allow <Jamf Egress IP 2>;
    deny all;

    location / {
        proxy_pass http://localhost:8080;  # Uw LLM-inferentieserver
    }
}

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

Stap 5: Valideer en Monitor

Bevestig vanaf een beheerd apparaat met het geïmplementeerde relay-profiel dat verzoeken naar uw LLM-endpoint slagen.
Bevestig vanaf een onbeheerd apparaat (of met het relay-profiel verwijderd) dat verzoeken worden geblokkeerd.
Monitor toegangslogboeken op uw LLM-infrastructuur om te verifiëren dat alle inkomende verbindingen afkomstig zijn van uw verwachte Jamf egress-IP's.
Bekijk verbindingslogboeken in de Jamf Security Cloud-sectie Rapporten > Toegang voor zichtbaarheid in welke gebruikers en apparaten het LLM-endpoint benaderen.

Uitbreiden naar Beheerde LLM-services: AWS Bedrock

Dezelfde vertrouwde egress-IP-aanpak is van toepassing buiten zelf-gehoste modellen. Als uw organisatie Amazon Bedrock gebruikt voor beheerde LLM-inferentie, kunt u IP-gebaseerde beperkingen afdwingen met behulp van AWS IAM-beleid met aws:SourceIp-voorwaarden — zodat alleen verzoeken die afkomstig zijn van uw Jamf egress-IP's Bedrock-modellen kunnen aanroepen.

In tegenstelling tot zelf-gehoste implementaties waar u de netwerklaag beheert (Security Groups, firewalls), is Bedrock een volledig beheerde AWS-service. U configureert geen inkomende firewallregels op Bedrock zelf. In plaats daarvan koppelt u IAM-beleid dat modelaanroep weigert tenzij het verzoek afkomstig is van een vertrouwd IP.

IAM Deny-beleid: Beperk Bedrock-aanroep op Bron-IP

Koppel het volgende beleid aan de IAM-gebruikers, rollen of groepen die Bedrock-toegang hebben. De expliciete weigering overschrijft alle allow-statements, zodat Bedrock-aanroepen worden geblokkeerd tenzij ze afkomstig zijn van uw Jamf egress-IP's:

{
    "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"
                    ]
                }
            }
        }
    ]
}

Dit beleid staat alle andere Bedrock-machtigingen (bijv. modellen weergeven, provisioned throughput beheren) normaal toe — het beperkt alleen de inferentie-aanroepacties tot vertrouwde IP's. Als uw bestaande IAM-beleid al expliciete DENY-regels bevat, moet u mogelijk een expliciet ALLOW-statement toevoegen voor vertrouwde IP's in plaats van te vertrouwen op impliciete allow.

Service Control Policy (SCP) voor Organisatiebrede Afdwinging

Als u de IP-beperking wilt afdwingen over alle AWS-accounts in uw organisatie — niet alleen individuele IAM-principals — pas het dan toe als een SCP in AWS Organizations:

{
    "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"
                }
            }
        }
    ]
}

De aws:ViaAWSService-voorwaarde is opgenomen zodat de weigering niet per ongeluk Bedrock-aanroepen blokkeert die door andere AWS-services namens u worden gedaan (bijv. een Lambda-functie die Bedrock aanroept binnen uw VPC, Step Functions-workflows die Bedrock aanroepen, of SageMaker-notebooks die Bedrock gebruiken voor inferentie). Het zorgt ervoor dat de IP-beperking alleen van toepassing is op directe API-aanroepen — wat precies het pad is dat eindgebruikerapparaten nemen via de Jamf-relay.

Belangrijke Overwegingen voor Bedrock

aws:SourceIp is van toepassing op directe API-aanroepen via het openbare internet. Dit is het verwachte pad wanneer verkeer stroomt van een beheerd apparaat → Jamf Security Cloud → Jamf egress-IP → AWS Bedrock API-endpoint.
VPC Endpoint-toegang: Als u ook toegang hebt tot Bedrock via een VPC-endpoint, wordt aws:SourceIp niet geëvalueerd. Gebruik aws:VpcSourceIp of VPC-endpoint-beleid om de toegang in dat pad afzonderlijk te beheren.
Bedrock cross-region inferentie: Als u cross-region inferentieprofielen gebruikt, zorg ervoor dat uw beleid Resource de relevante regio's dekt of gebruik een wildcard zoals hierboven weergegeven.
Testen: Gebruik de IAM Policy Simulator of maak test-InvokeModel-aanroepen vanaf zowel een beheerd apparaat (moet slagen) als een onbeheerd apparaat (moet AccessDenied ontvangen) om het beleid te valideren voordat u het breed implementeert.

Defense in Depth: IP-vergrendeling Combineren met API-sleutels

Het is belangrijk op te merken dat IP-gebaseerde toegangsbeperking API-sleutelauthenticatie aanvult — het vervangt het niet. De aanbevolen houding is om beide controles te combineren:

Laag	Controle	Wat Het Bewijst
Netwerk	Jamf egress-IP allowlist	Verzoek is afkomstig van een beheerd, geattesteerd apparaat
Applicatie	API-sleutel / token	Verzoek is geautoriseerd voor de specifieke LLM-service
(Optioneel) Identiteit	IdP-integratie / OAuth	Verzoek is gekoppeld aan een specifieke geauthenticeerde gebruiker

Met deze gelaagde aanpak zou een aanvaller tegelijkertijd een geldige API-sleutel moeten bezitten en moeten werken vanaf een Jamf-beheerd, hardware-geattesteerd apparaat — een aanzienlijk hogere drempel dan beide controles alleen.

Samenvatting

Zelf-gehoste LLM's vertegenwoordigen een aanzienlijke infrastructuurinvestering voor organisaties die hun gegevens, kosten en AI-toeleveringsketen moeten beheren. Die investering wordt ondermijnd als toegang uitsluitend afhankelijk is van gedeelde API-sleutels die kunnen lekken en vanaf elk apparaat op het internet kunnen worden gebruikt.

Het implementeren van Network Relay met vertrouwde egress-IP-beperkingen biedt:

Cryptografisch apparaatvertrouwen geworteld in Apple hardware-attestatie, niet een software-token of gedeeld secret.
Zero-touch, zero-agent implementatie zonder VPN-clients, zonder gebruikersinteractie en zonder activatiestappen.
Deterministische bron-IP-adressen die eenvoudige IP-allowlisting mogelijk maken op elke LLM-infrastructuur.
Per-domein routeringsprecisie die de prestatie- en privacy-afwegingen van full-tunnel VPN's vermijdt.
Gelaagde beveiliging die netwerklaag-apparaatvertrouwen combineert met applicatielaag-API-authenticatie.

Het netto-effect is dat alleen vertrouwde, beheerde apparaten de LLM-infrastructuur kunnen bereiken, zonder enige wijziging in eindgebruikersworkflows.

Handleidingen