Votre endpoint d'IA n'a pas besoin d'être sur internet.
Chaque guide de déploiement suppose que l'endpoint est public et vous explique comment le défendre. Il existe une posture plus forte : l'absence. Parce que le réseau nous appartient de bout en bout, votre endpoint d'inférence peut n'être joignable que par votre propre transit privé, et l'internet public reste entièrement hors du chemin.
Dans cet article 4 sections
- Chaque guide de déploiement d'IA suppose que l'endpoint vit sur internet et vous explique comment le défendre : auth, TLS, gateways, rate limiting, un WAF.
- Il existe une posture plus forte : l'absence. Un endpoint d'inférence single-tenant joignable uniquement par votre propre transit privé n'a aucune surface publique à défendre.
- Nous pouvons l'offrir parce que le réseau nous appartient de bout en bout : notre AS, notre routage, un maillage privé chiffré. Vos prompts parcourent votre chemin privé jusqu'à votre machine et retour. L'internet public ne les transporte jamais.
- Pour les charges de travail réglementées, cela raccourcit tout : le modèle de menace, le périmètre du pentest, le schéma de l'auditeur, et la liste de ce qui peut mal tourner à 3 h du matin.
Chaque équipe qui déploie un modèle privé dessine le même schéma. L'application, puis l'API gateway, puis l'endpoint, puis le modèle, avec une icône de cadenas qui tient lieu de revue de sécurité. Les guides s'accordent tous sur la suite : authentification, TLS, rate limiting, un WAF, surveillance des logs. Tout cela est sensé. Tout cela répond à la seconde question en sautant la première.
La première question : pourquoi cet endpoint est-il sur internet tout court ? Vos documents sont privés. Votre application est privée. Le modèle tourne sur une machine que personne d'autre ne partage. Le seul tronçon public du schéma existe parce que le schéma a été copié d'un monde d'API publiques, pas parce que votre charge de travail en a besoin.
h2 (#absence-beats-defense): La défense est un budget. L'absence est une propriété.
Tout ce qui est exposé à internet est un coût permanent. La surface exposée a besoin de correctifs selon le calendrier de quelqu'un, les logs ont besoin d'être surveillés, le WAF a besoin d'être réglé, et les scans ne cessent jamais d'arriver, que vous regardiez ou non. Tout ce travail est nécessaire, tout est pour toujours, et tout est probabiliste : il abaisse les probabilités, il ne peut pas les ramener à zéro. Retirer le tronçon public convertit le budget en propriété : la plus ancienne idée de la sécurité réseau, le plan de gestion vers lequel on ne peut pas router, appliquée à la charge de travail la plus récente du rack.
h2 (#the-two-architectures): Les deux architectures
h2 (#the-ownership-tie): Pourquoi nous pouvons construire la seconde chaîne
Le chemin privé n'est pas une fonctionnalité produit que nous avons activée. C'est une conséquence de ce qu'est cette entreprise. Nous exploitons notre propre AS et notre propre routage, et un maillage chiffré toujours actif relie nos datacenters, le même fabric privé sur lequel voyage votre trafic de réplication. Pour les clients qui le souhaitent, l'endpoint d'inférence est joignable par leur propre transit privé vers ce réseau, et l'internet public n'est jamais sur le chemin : aucun listener public, aucune entrée DNS publique à trouver, aucune porte d'entrée à laquelle frapper. Une place de marché GPU qui revend de la capacité dans les installations d'autrui ne peut pas offrir cela, parce que c'est une propriété du réseau, et qu'elle n'est pas opérateur de réseau.
- Surface d'attaque publique
- aucune : il n'y a pas de listener exposé à internet
- Credential stuffing et bruit des scans
- aucune porte publique à laquelle frapper
- Données en transit
- chemin privé, chiffré, de bout en bout
- Le schéma réseau de l'auditeur
- une ligne privée, deux endpoints que vous contrôlez
- Ce qui reste, honnêtement
- l'hygiène de votre propre réseau, le contrôle d'accès de votre côté, et nous
h2 (#where-the-boundary-sits): Où se situe la frontière
La joignabilité privée est précise sur ce qu'elle retire, et l'affirmation ne reste forte que si elle reste précise. Le contrôle d'accès de votre propre réseau compte toujours : un ordinateur portable compromis sur votre VPN atteint tout ce que votre VPN atteint, ceci compris. L'endpoint authentifie toujours, parce que l'absence retire la part d'internet du modèle de menace, pas votre côté. Et les charges de travail qui veulent réellement une API publique, un produit destiné aux clients par exemple, en gardent légitimement une et la défendent correctement. L'affirmation est plus étroite et plus forte : pour les charges de travail internes et réglementées, le tronçon public est facultatif, et une exposition facultative doit être refusée. Le périmètre du pentest pour un service qui n'est pas sur internet est un document court, et les auditeurs le remarquent.
Mettez ensemble les deux moitiés de l'argument de l'IA privée et l'architecture se complète d'elle-même. Le pipeline qui ne quitte jamais la machine (l'assistant de connaissance) répond à ce qui arrive à vos données au repos et en usage. Le chemin privé répond à la façon dont les données y arrivent et en reviennent. Entre les deux, la question par laquelle commence tout acheteur réglementé, qui peut voir cela, garde sa réponse en un mot à chaque couche : personne.
“La posture de sécurité la plus forte pour un endpoint n'est pas un meilleur firewall. C'est de ne pas être sur internet tout court.”
Réponses directes
Comment sécuriser un endpoint LLM auto-hébergé ?+
Les réponses habituelles (auth, TLS, gateway, WAF) défendent un endpoint public. La question plus forte est de savoir s'il doit être public tout court : un endpoint joignable uniquement par transit privé n'a aucune surface exposée à internet à défendre, et les contrôles habituels se réduisent à votre côté de la ligne.
Que signifie « transit privé » ici ?+
Votre trafic atteint la machine par un chemin privé et chiffré, votre connectivité vers notre réseau, pas à travers l'internet ouvert. Nous restons volontairement au niveau du concept : la conversation de conception se tient par client, avec votre équipe réseau dans la pièce.
Est-ce la même chose qu'un air gap ?+
C'est son parent pratique : pas physiquement hors ligne, mais sans chemin depuis l'internet public. Les véritables exigences d'air gap sont une autre conversation que nous pouvons aussi avoir. La plupart des charges de travail réglementées ont besoin de « pas sur internet », pas de « sur aucun réseau ».
Un endpoint privé a-t-il encore besoin d'authentification ?+
Oui. L'absence de tronçon public retire la part d'internet du modèle de menace, pas celle de votre propre réseau. Tout ce que votre réseau privé atteint, une machine compromise sur ce réseau l'atteint aussi. L'auth reste. Le bruit des scans disparaît.
Pourquoi un cloud GPU ne peut-il pas offrir cela ?+
Parce que c'est une propriété du réseau, pas une fonctionnalité du serveur. Cela exige de posséder le routage de bout en bout : l'AS, les chemins, le fabric chiffré entre les sites. Les places de marché qui revendent des GPU dans les installations d'autrui n'ont pas de réseau à rendre privé.
Votre modèle, joignable uniquement par vous.
Apportez-nous le modèle et votre modèle de menace. Nous concevrons le chemin privé, et l'internet public reste en dehors.
Voir les GPU serversVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur
