Sécurisation de l'accès aux LLM avec des adresses IP de sortie fiables

L'accès à la plupart des points de terminaison LLM hébergés est protégé par une clé API partagée codée dans les configurations client. Les clés API sont simples à déployer mais faciles à partager, divulguer ou exfiltrer — et comme l'inférence LLM est coûteuse, l'utilisation non autorisée peut générer des coûts importants et imprévus.

C'est à la fois un problème de sécurité et un problème de gouvernance des coûts.

Le Network Relay de Jamf combiné aux restrictions d'adresses IP de sortie fiables répond à ce besoin avec une approche sans intervention.

Le problème : les clés API seules ne suffisent pas

Un exemple de déploiement LLM hébergé typique :

L'organisation déploie un modèle (par ex., Llama 3, Mistral ou une variante affinée) sur une infrastructure interne ou au sein d'un VPC cloud (AWS, Azure, GCP).
Un point de terminaison API est exposé — souvent compatible avec OpenAI — qui accepte les demandes authentifiées par une clé API partagée.
La clé API est distribuée aux clients via des profils de configuration, MDM, des variables d'environnement ou la documentation pour développeurs.

Le problème est que les clés API sont des secrets statiques et persistants qui sont faciles à divulguer :

Un développeur copie la clé dans un projet personnel ou un bloc-notes.
La clé est envoyée vers un référentiel Git (même privé).
Un employé partage la clé avec un collègue ou un entrepreneur non autorisé.
Un appareil avec la clé configurée est perdu ou compromis.

Une fois que la clé est exposée, quiconque la possède peut utiliser vos ressources LLM à partir de n'importe quel appareil, n'importe quel réseau, n'importe où. Étant donné que l'inférence LLM peut coûter de quelques centimes à plusieurs dollars par demande selon le modèle et la longueur de l'invite, l'utilisation non autorisée peut générer des factures substantielles — ou pire, exposer des données internes sensibles si le modèle a été affiné sur des informations propriétaires.

Les atténuations traditionnelles telles que la rotation des clés aident, mais introduisent une complexité opérationnelle et ne résolvent pas le problème fondamental :

La clé seule ne peut pas vérifier que la demande provient d'un appareil fiable et géré.

La solution : Network Relay + restriction d'adresse IP de sortie fiable

Le Network Relay de Jamf, construit sur le protocole MASQUE natif d'Apple et l'attestation d'appareil géré (MDA), permet aux organisations de restreindre l'accès aux points de terminaison LLM aux appareils Apple vérifiés et gérés — sans aucune interaction de l'utilisateur final.

L'architecture :

1. Le trafic des appareils gérés transite par le Jamf Security Cloud

Quand Network Relay est déployé via MDM, tout le trafic destiné au domaine de votre point de terminaison LLM est automatiquement acheminé via le Jamf Security Cloud à l'aide de tunnels MASQUE/HTTP3 chiffrés. L'identité de l'appareil est vérifiée de manière cryptographique à l'aide de clés liées au matériel de la Secure Enclave Apple via l'attestation d'appareil géré, donc seuls les appareils véritables gérés par l'entreprise peuvent établir ces tunnels.

2. Le trafic sort via des adresses IP Jamf connues

Une fois que le trafic traverse le Jamf Security Cloud et l'évaluation des politiques, il sort (s'écoule) vers Internet — et donc vers votre point de terminaison LLM — à partir d'un ensemble connu et déterministe d'adresses IP Jamf. Celles-ci peuvent être :

Des adresses IP de sortie partagées provenant de l'une des régions de centre de données global de Jamf.
Des adresses IP de sortie dédiées attribuées de manière unique à votre organisation — fournissant deux adresses IP publiques hautement disponibles par région qu'aucun autre client Jamf n'utilise.

3. Votre point de terminaison LLM restreint l'accès aux adresses IP fiables uniquement

Avec votre trafic arrivant désormais à partir d'un ensemble d'adresses IP connu et fiable, vous configurez votre infrastructure LLM pour n'accepter les connexions que de ces adresses IP de sortie Jamf — en rejetant toutes les autres. Il s'agit d'une liste d'autorisation IP standard appliquée à la couche réseau :

LLM hébergés dans le cloud (AWS/Azure/GCP) : Configurez les groupes de sécurité, les groupes de sécurité réseau ou les règles de pare-feu pour ne permettre que HTTPS entrant (TCP/443) à partir de vos adresses IP de sortie Jamf. Voir ci-dessous pour un exemple sur AWS Bedrock Lien vers Mon Titre
LLM sur site : Configurez votre pare-feu de périmètre ou proxy inverse (par ex., nginx, HAProxy, Caddy) pour n'accepter les connexions que des plages d'adresses IP de sortie Jamf.
Passerelle API / proxy LLM (par ex., LiteLLM, OpenWebUI) : De nombreuses solutions de passerelle LLM supportent la liste d'autorisation IP au niveau de la couche application comme mesure de défense supplémentaire.

Le résultat : même si une clé API est divulguée, elle est inutile à moins que la demande n'origine d'un appareil géré routant via votre tenant Jamf Security Cloud.

Pourquoi Network Relay

La différence clé par rapport au blocage IP traditionnel basé sur VPN est le modèle de déploiement sans intervention et sans agent :

Aucune installation d'application requise. Network Relay est configuré entièrement via des profils de configuration MDM déployés à partir de Jamf Pro. Il n'y a pas de client VPN à installer, aucune application Jamf Trust requise pour la fonctionnalité de relais de base, et aucune étape de connexion ou d'activation utilisateur.
Aucune interaction utilisateur. Une fois que le profil de relais est installé sur un appareil géré, il s'active automatiquement. L'utilisateur ne voit pas de bascule VPN, n'entre pas de credentials pour l'accès réseau et ne subit pas d'interruption. Le trafic vers les domaines LLM définis est acheminé de manière transparente.
Confiance d'appareil enracinée dans le matériel. L'attestation d'appareil géré utilise la Secure Enclave Apple pour prouver de manière cryptographique qu'un appareil est véritable matériel Apple, géré par le MDM de votre organisation, et n'a pas été altéré. Cela fournit un signal d'identité plus fort que les agents logiciels uniquement.
Précision par domaine. Contrairement à un VPN en tunnel complet qui achemine tout le trafic, Network Relay fonctionne par domaine. Vous définissez exactement quels domaines (par ex., llm.internal.yourcompany.com) doivent être acheminés via Jamf — laissant tout autre trafic inaffecté. Cela minimise l'impact sur les performances et évite le compromis « tout ou rien » des architectures VPN héritées.
Fonctionne sur les plateformes Apple. Network Relay est supporté sur macOS, iOS, iPadOS et visionOS, et peut être géré à partir d'une seule configuration.

N.B. Il est également possible d'utiliser le blocage IP avec la solution ZTNA de Jamf sur les plateformes non-Apple.

Aperçu du déploiement

Les étapes suivantes décrivent la configuration de bout en bout :

Étape 1 : Configurer la sortie dans Jamf Security Cloud

Dans la console Jamf Security Cloud (RADAR), accédez à Integrations > Access Gateways et notez soit vos adresses IP de sortie partagées pour votre région préférée, soit créez une passerelle Internet dédiée pour recevoir deux adresses IP publiques uniques attribuées exclusivement à votre organisation.

Pour les passerelles dédiées, vous pouvez créer plusieurs passerelles régionales et les grouper afin que les appareils utilisent automatiquement le point de sortie le plus proche en fonction de leur connexion au Jamf Security Cloud.

Étape 2 : Créer une politique d'accès pour votre point de terminaison LLM

Accédez à Policies > Access Policies et créez une nouvelle politique :

Définissez le ou les domaines de votre point de terminaison LLM (par ex., llm.yourcompany.com, api.ai.internal.yourcompany.com).
Définissez le routage pour utiliser votre passerelle de sortie choisie (partagée ou dédiée).
Configurez la politique pour s'appliquer aux groupes d'appareils appropriés.

Étape 3 : Déployer le profil Network Relay

Accédez à Devices > Activation Profiles et créez ou mettez à jour votre profil d'activation Network Relay :

Sous Service Capabilities, assurez-vous que Zero Trust Network Access est sélectionné.
Sous Authentication, sélectionnez Managed Device Attestation pour une activation sans intervention et sans mot de passe.
Déployez les profils de configuration résultants vers vos appareils gérés via Jamf Pro.

Une fois déployés, les appareils commenceront automatiquement à acheminer le trafic vers vos domaines LLM via le Jamf Security Cloud.

Étape 4 : Verrouiller votre point de terminaison LLM aux adresses IP de sortie Jamf

Du côté de l'infrastructure LLM, restreindrez l'accès entrant uniquement à vos adresses IP de sortie Jamf. Exemples :

Groupe de sécurité AWS :

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

Proxy inverse nginx :

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
    }
}

Groupe de sécurité réseau Azure :

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

Étape 5 : Valider et surveiller

À partir d'un appareil géré avec le profil de relais déployé, confirmez que les demandes à votre point de terminaison LLM réussissent.
À partir d'un appareil non géré (ou avec le profil de relais supprimé), confirmez que les demandes sont bloquées.
Surveillez les journaux d'accès sur votre infrastructure LLM pour vérifier que toutes les connexions entrantes proviennent de vos adresses IP de sortie Jamf attendues.
Passez en revue les journaux de connexion dans la section Reports > Access du Jamf Security Cloud pour une visibilité sur les utilisateurs et appareils qui accèdent au point de terminaison LLM.

Extension aux services LLM gérés : AWS Bedrock

La même approche d'adresse IP de sortie fiable s'applique au-delà des modèles auto-hébergés. Si votre organisation utilise Amazon Bedrock pour l'inférence LLM gérée, vous pouvez appliquer des restrictions basées sur IP à l'aide de politiques IAM AWS avec des conditions aws:SourceIp — en garantissant que seules les demandes provenant de vos adresses IP de sortie Jamf peuvent invoquer les modèles Bedrock.

Contrairement aux déploiements auto-hébergés où vous contrôlez la couche réseau (groupes de sécurité, pare-feu), Bedrock est un service AWS entièrement géré. Vous ne configurez pas de règles de pare-feu entrant sur Bedrock lui-même. Au lieu de cela, vous attachez des politiques IAM qui refusent l'invocation de modèle à moins que la demande ne provienne d'une IP fiable.

Politique IAM Deny : restreindre l'invocation Bedrock par adresse IP source

Attachez la politique suivante aux utilisateurs IAM, rôles ou groupes qui ont accès à Bedrock. Le refus explicite remplace toutes les instructions d'autorisation, garantissant que les appels Bedrock sont bloqués à moins qu'ils ne proviennent de vos adresses IP de sortie Jamf :

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

Cette politique permet à toutes les autres autorisations Bedrock (par ex., énumération des modèles, gestion du débit provisionné) de fonctionner normalement — elle restreint uniquement les actions d'invocation d'inférence aux IP fiables. Si vos politiques IAM existantes contiennent déjà des règles DENY explicites, vous devrez peut-être ajouter une instruction ALLOW explicite pour les IP fiables à la place de vous fier à une autorisation implicite.

Politique de contrôle de service (SCP) pour l'application à l'échelle de l'organisation

Si vous souhaitez appliquer la restriction IP dans tous les comptes AWS de votre organisation — et non seulement aux principaux IAM individuels — appliquez-la en tant que SCP dans 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"
                }
            }
        }
    ]
}

La condition aws:ViaAWSService est incluse pour que le refus n'interfère pas inadvertidement avec les appels Bedrock effectués par d'autres services AWS en votre nom (par ex., une fonction Lambda invoquant Bedrock dans votre VPC, les flux de travail Step Functions appelant Bedrock, ou les carnets SageMaker utilisant Bedrock pour l'inférence). Elle garantit que la restriction IP s'applique uniquement aux appels API directs — qui est exactement le chemin emprunté par les appareils utilisateurs finaux via le relais Jamf.

Considérations clés pour Bedrock

aws:SourceIp s'applique aux appels API directs sur l'Internet public. C'est le chemin attendu quand le trafic s'écoule d'un appareil géré → Jamf Security Cloud → adresse IP de sortie Jamf → point de terminaison API AWS Bedrock.
Accès via le point de terminaison VPC : Si vous accédez également à Bedrock via un point de terminaison VPC, aws:SourceIp n'est pas évalué. Utilisez aws:VpcSourceIp ou les politiques du point de terminaison VPC pour contrôler séparément l'accès dans ce chemin.
Inférence cross-région Bedrock : Si vous utilisez des profils d'inférence cross-région, assurez-vous que votre politique Resource couvre les régions pertinentes ou utilisez un caractère générique comme indiqué ci-dessus.
Tests : Utilisez le simulateur de politique IAM ou effectuez des appels InvokeModel de test à partir d'un appareil géré (devrait réussir) et d'un appareil non géré (devrait recevoir AccessDenied) pour valider la politique avant un déploiement large.

Défense en profondeur : combiner le blocage IP avec les clés API

Il est important de noter que la restriction d'accès basée sur IP complète l'authentification par clé API — elle ne la remplace pas. La posture recommandée est de combiner les deux contrôles :

Couche	Contrôle	Ce qu'il prouve
Réseau	Liste d'autorisation IP Jamf	La demande provient d'un appareil géré et attesté
Application	Clé API / jeton	La demande est autorisée pour le service LLM spécifique
(Optionnel) Identité	Intégration IdP / OAuth	La demande est liée à un utilisateur authentifié spécifique

Avec cette approche en couches, un attaquant devrait posséder simultanément une clé API valide et opérer à partir d'un appareil géré par Jamf avec attestation matérielle — une barre significativement plus élevée que l'un ou l'autre contrôle seul.

Résumé

Les LLM auto-hébergés représentent un engagement d'infrastructure important pour les organisations qui ont besoin de contrôler leurs données, leurs coûts et leur chaîne d'approvisionnement en IA. Cet engagement est compromis si l'accès repose uniquement sur des clés API partagées qui peuvent être divulguées et utilisées à partir de n'importe quel appareil sur Internet.

Le déploiement de Network Relay avec des restrictions d'adresses IP de sortie fiables offre :

Confiance d'appareil cryptographique enracinée dans l'attestation matérielle Apple, pas un jeton logiciel ou un secret partagé.
Déploiement sans intervention et sans agent sans clients VPN, sans interaction utilisateur et sans étapes d'activation.
Des adresses IP sources déterministes qui permettent une liste d'autorisation IP simple sur toute infrastructure LLM.
Précision de routage par domaine qui évite les compromis de performance et de confidentialité des VPN en tunnel complet.
Sécurité en couches qui combine la confiance d'appareil au niveau réseau avec l'authentification API au niveau application.

L'effet net est que seuls les appareils fiables et gérés peuvent atteindre l'infrastructure LLM, sans nécessiter aucun changement dans les flux de travail des utilisateurs finaux.

Guides