Quelles parties d’une application auto-hébergée ont besoin d’un accès à Internet ? Checklist de cartographie de l’exposition

Pourquoi « accessible publiquement » n’est pas une exigence de déploiement complète

« L’application doit être publique » peut recouvrir plusieurs réalités très différentes. Cela peut signifier que tout le monde doit pouvoir charger un site web, que seuls des employés nommément désignés doivent pouvoir se connecter depuis n’importe où, qu’un système partenaire doit pouvoir envoyer des webhooks, ou que l’application doit simplement appeler une API externe. Ces exigences conduisent à des décisions différentes en matière d’exposition réseau.

Considérez l’accessibilité entrante et la connectivité sortante comme deux décisions distinctes. Dans le réseau Docker, un conteneur peut établir des connexions sortantes lorsque son hôte dispose d’un accès à Internet, tandis qu’un port de conteneur n’est normalement pas accessible depuis l’extérieur de l’hôte à moins d’être délibérément publié ou routé. Une application peut donc avoir besoin d’un accès à Internet sans nécessiter de port d’application publiquement accessible.

L’objectif n’est pas de rendre chaque composant privé ou chaque composant public. Il consiste à autoriser explicitement chaque flux de données, à n’exposer que les points d’entrée requis et à consigner la raison d’être de chacun. Cela correspond au résultat visé par le NIST Cybersecurity Framework 2.0, qui prévoit de maintenir des représentations des communications réseau et des flux de données internes et externes autorisés.

• Remplacez « public » par une formulation précise : qui se connecte, depuis où, à quel nom d’hôte, avec quel protocole et dans quel but.
• Distinguez l’accès par navigateur, les requêtes entrantes de machine à machine, les appels sortants et l’accès des administrateurs.
• Décidez si chaque flux relève de l’Internet public, est limité à des adresses IP connues, est réservé à un réseau privé ou n’est pas autorisé.
• Consignez les données échangées sur chaque flux, notamment les identifiants, les données personnelles, les dossiers clients, les fichiers et les jetons d’API.

Commencez par une carte d’exposition : utilisateurs, administrateurs, intégrations et services de support

Une carte d’exposition est un inventaire pratique des chemins de communication autorisés de l’application. Établissez-la avant de choisir des domaines, d’ouvrir des règles de pare-feu ou de publier des ports de conteneur. Elle doit couvrir plus que l’écran principal de l’application : les services de support, les outils d’administration, les systèmes d’identité, les fournisseurs d’e-mail et les destinations de supervision peuvent tous créer des dépendances réseau.

Commencez par répertorier les actifs et les acteurs. Le NIST CSF 2.0 considère les logiciels, les services, les systèmes, les données et les services de fournisseurs comme des actifs qui doivent être identifiés et gérés. Pour un déploiement auto-hébergé, cela implique de documenter à la fois vos propres composants et les services externes qu’ils contactent.

Tracez ensuite des flèches directionnelles. Chaque flèche doit avoir un responsable et une décision : autorisée, restreinte, privée uniquement ou refusée. Cela rend visibles les hypothèses cachées dès le début — par exemple, un flux d’automatisation qui doit recevoir le webhook d’un fournisseur, ou un tableau de bord interne supposé accessible depuis tous les réseaux des employés.

• Utilisateurs : visiteurs publics, clients, personnel, sous-traitants, utilisateurs mobiles et comptes de service.
• Administrateurs : administrateurs de l’application, administrateurs de l’infrastructure et personnel de support.
• Intégrations entrantes : webhooks, clients API, retours de fournisseurs d’identité et systèmes partenaires.
• Intégrations sortantes : envoi d’e-mails, fournisseurs d’identité, API externes, téléchargements de logiciels, téléchargements de modèles et destinations de supervision.
• Services de support : bases de données, caches, files d’attente, stockage d’objets, services de recherche, proxys inverses et tableaux de bord d’administration.
• Pour chaque flux, consignez la source, la destination, le protocole et le port, le nom d’hôte, la direction, la méthode d’authentification, la classification des données, le responsable et la justification métier.

Classifiez les accès entrants : interface web publique, utilisateurs authentifiés, points de terminaison partenaires et récepteurs de webhooks

L’accès entrant est ce que la plupart des équipes entendent par exposition, mais il doit être séparé en catégories distinctes. Une interface publique de marketing ou de publication présente un profil de risque différent de celui d’une application réservée aux employés. Un récepteur de webhook peut devoir accepter des requêtes provenant d’un système externe alors qu’aucune interface destinée aux humains ne devrait être largement accessible.

Utilisez le proxy inverse comme point d’entrée entrant intentionnel. Dans le modèle de Traefik, les points d’entrée reçoivent le trafic TCP ou UDP, les routeurs font correspondre les requêtes entrantes et les services reçoivent le trafic backend routé. Cela permet une conception dans laquelle le proxy n’accepte que le trafic approuvé, tandis que les conteneurs d’application restent derrière lui.

Lorsqu’un point de terminaison est utilisé uniquement par des parties connues, documentez si une règle fondée sur l’adresse IP convient en complément de l’authentification au niveau de l’application. Traefik fournit un mécanisme de liste d’autorisation IP qui accepte ou refuse les requêtes avant qu’elles n’atteignent un backend. Cela peut réduire l’exposition inutile, mais dépend de la stabilité et de l’identification correcte des adresses sources ; cela ne doit pas être considéré comme un substitut à une authentification adaptée.

• Interface web publique : destinée aux visiteurs non authentifiés ; n’exposez que les routes web et le nom d’hôte nécessaires.
• Accès des utilisateurs authentifiés : destiné aux clients ou au personnel ; définissez les exigences d’identité, de connexion, de session et d’accès dans la conception de l’application.
• Point de terminaison API partenaire : définissez le partenaire, la méthode d’authentification, le réseau source attendu, les attentes de débit et les routes exactes.
• Récepteur de webhook : définissez l’expéditeur, la validation de signature ou d’authentification, la route, les données de charge utile attendues et la gestion des échecs.
• Interface d’administration : classez-la séparément de l’application principale ; ne supposez pas qu’elle doit figurer sur le nom d’hôte public.
• Refusez l’exposition fourre-tout : un port ou un nom d’hôte accessible de l’extérieur doit avoir un objectif et un responsable nommés.

Identifiez les dépendances sortantes avant de supposer que l’application peut fonctionner de façon privée

Un accès entrant privé ne signifie pas qu’une application n’a aucune dépendance à Internet. De nombreuses charges de travail d’entreprise, d’automatisation et d’IA doivent initier des connexions vers des services situés à l’extérieur de l’hôte. Il peut s’agir de services d’envoi d’e-mails, de fournisseurs d’identité, d’API tierces, de sources de paquets, de téléchargements de modèles ou de destinations de supervision.

Pour chaque dépendance, déterminez si elle est requise lors de l’installation, au démarrage, selon une planification ou pendant l’activité normale des utilisateurs. Cette distinction est importante dans les environnements restreints. Un téléchargement ponctuel de logiciel ou de modèle peut être traité différemment d’une connexion permanente à un fournisseur d’identité ou à une API métier externe.

Ne décrivez pas l’accès sortant comme une permission globale unique. Identifiez le nom d’hôte ou le service de destination, le protocole, le but opérationnel, les données envoyées et reçues, l’identifiant utilisé et le comportement de repli lorsque la destination est indisponible. Consultez la documentation officielle de l’application et de l’intégration concernées, car les dépendances varient selon le produit et la configuration.

• Envoi d’e-mails : identifiez le fournisseur, la méthode de connexion, l’identité d’expéditeur et si l’application doit envoyer des réinitialisations de mot de passe, des notifications ou des messages de flux de travail.
• Fournisseur d’identité : identifiez les points de terminaison d’authentification et de jetons, les détails de l’émetteur, et déterminez si la connexion cesse de fonctionner lorsque le fournisseur est injoignable.
• API externes : listez chaque fournisseur séparément, les données échangées, l’approche de stockage des identifiants et si les appels sont déclenchés par l’utilisateur ou automatisés.
• Téléchargements de paquets, plugins ou modèles : établissez si l’accès à Internet n’est nécessaire que lors de la configuration ou des mises à jour, ou régulièrement à l’exécution.
• Supervision et signalement d’erreurs : déterminez quelles données de télémétrie ou d’événements quittent l’environnement et qui approuve ce transfert.
• Vérifications de mises à jour et appels liés aux licences : vérifiez-les directement dans la documentation officielle de l’éditeur au lieu de supposer qu’ils sont requis ou absents.

Conservez les services de données privés par défaut

Une base de données, un cache, une file d’attente, un magasin d’objets ou un service de recherche est généralement un composant de support, et non un produit exposé à Internet. Partez d’un accès privé uniquement et n’ajoutez une route que lorsqu’une raison opérationnelle documentée le justifie. Dans une configuration de pont Docker, les services connectés à l’hôte ou au même réseau peuvent communiquer selon leur configuration, tandis que les ports de conteneur ne sont pas accessibles depuis l’extérieur de l’hôte par défaut, sauf s’ils sont publiés ou autrement routés de manière délibérée.

Soyez particulièrement vigilant face à la publication par commodité. Docker indique que la publication d’un port sans préciser d’adresse d’hôte le lie par défaut à toutes les adresses de l’hôte, ce qui peut rendre le service accessible de l’extérieur. Si un service est destiné uniquement à l’hôte local dans le scénario documenté en mode NAT, la liaison à l’interface de bouclage est un moyen d’empêcher les hôtes distants d’accéder à ce port publié.

Les plans de contrôle administratifs méritent le même traitement privé par défaut. Traefik avertit que son API et son tableau de bord de production peuvent exposer des éléments de configuration, y compris des données sensibles, et recommande de limiter son port d’API aux réseaux internes. Appliquez également ce principe aux interfaces d’administration des applications, aux interfaces de gestion des conteneurs et aux outils d’observabilité.

• Bases de données : n’autorisez l’accès qu’aux composants de l’application et aux chemins de maintenance approuvés.
• Caches et files d’attente : conservez-les sur des réseaux privés ; ne les exposez pas seulement pour simplifier le dépannage.
• Stockage d’objets et services de fichiers internes : définissez quels composants de l’application nécessitent un accès et comment les sauvegardes interagissent avec eux.
• Services de recherche, vectoriels et de support IA : documentez s’il s’agit de backends internes ou d’API délibérément proposées à d’autres systèmes.
• Tableaux de bord de proxy, panneaux d’administration des applications et plans de contrôle de l’infrastructure : utilisez des chemins d’accès séparés et restreints.
• Avant la mise en service, examinez chaque port publié et confirmez sa liaison à l’hôte, les clients prévus et son responsable.

Vérifiez les cas limites courants qui modifient la conception des accès

Plusieurs détails de déploiement sont faciles à découvrir tardivement, une fois qu’un nom d’hôte ou une politique de pare-feu a déjà été choisi. Traitez-les tôt, car ils peuvent déterminer si un nom d’hôte public, un chemin de rappel stable ou une source réseau particulière est nécessaire.

OAuth est un exemple clé. Les URL de redirection et de rappel sont des exigences de déploiement, pas des paramètres esthétiques. La RFC 9700 exige que les serveurs d’autorisation utilisent une correspondance exacte de chaîne avec les URI de redirection préenregistrés, à l’exception de la gestion localhost spécifiée pour les applications natives. Un changement de schéma, de nom d’hôte, de chemin ou de barre oblique finale peut donc interrompre la connexion.

Sécurisez le chemin de rappel lui-même. La RFC 9700 avertit que les points de terminaison d’URI de redirection ne doivent pas agir comme des redirections ouvertes. Elle identifie également un risque lorsque les pages qui traitent les réponses OAuth renvoient vers des pages contrôlées par un attaquant ou chargent du contenu tiers susceptible de divulguer l’URL de réponse d’autorisation via l’en-tête Referer. Gardez le traitement des rappels volontairement limité et évitez tout contenu tiers intégré inutile sur cette page.

• OAuth et SSO : confirmez l’URL externe exacte, le protocole, le nom d’hôte et le chemin de rappel qui doivent être enregistrés auprès du fournisseur d’identité.
• Contenu intégré : identifiez les iframes, scripts, images ou widgets qui se connectent à des tiers, en particulier sur les pages de réponse d’authentification.
• Clients mobiles et de bureau : confirmez s’ils nécessitent un point de terminaison public, un nom d’hôte fixe, une gestion localhost ou un chemin sur réseau privé.
• Listes d’autorisation IP : validez les véritables adresses sources après prise en compte des intermédiaires, du NAT, des réseaux de diffusion de contenu ou de l’infrastructure partenaire.
• E-mails entrants ou transferts de fichiers : déterminez s’ils sont remis directement à l’application ou récupérés en sortie depuis un autre service.
• WebSockets, streaming et connexions longue durée : vérifiez les exigences du proxy et de l’application dans la documentation officielle au lieu de supposer que les paramètres HTTP ordinaires suffisent.

Questions à vérifier dans la documentation officielle de l’application avant le déploiement

La documentation de l’application fait autorité pour les exigences propres au produit. Ne déduisez pas qu’une application prend en charge un déploiement privé, un comportement particulier de proxy, un fournisseur SSO ou un modèle de webhook simplement parce qu’une autre application le fait. Confirmez les exigences dans la documentation officielle correspondant à la version et à la configuration que vous prévoyez d’utiliser.

Les réponses doivent être consignées dans la carte d’exposition et réexaminées lorsque les intégrations changent. Si la documentation laisse une question sans réponse, considérez-la comme un risque d’implémentation au lieu de combler cette lacune par une hypothèse.

Cette vérification est particulièrement importante pour les applications qui combinent une interface web avec des workers en arrière-plan, des moteurs d’automatisation, des services de modèles d’IA ou plusieurs conteneurs de support. L’interface visible dans le navigateur n’est souvent qu’une partie de la conception opérationnelle.

• Quels ports et protocoles entrants sont requis, le cas échéant, et quel composant termine TLS ?
• L’application peut-elle fonctionner derrière un proxy inverse et exige-t-elle des paramètres de proxy approuvé ou d’URL externe ?
• Quelle URL canonique ou URL de base l’application exige-t-elle ?
• Quelles routes doivent recevoir des webhooks, des rappels OAuth, des assertions SSO ou des requêtes d’API partenaires ?
• Quels noms d’hôte ou catégories de services sortants sont requis pour le fonctionnement normal, la configuration, les mises à jour, l’e-mail, l’identité, la supervision ou les intégrations facultatives ?
• Quels services de données sont requis et leurs ports doivent-ils rester privés ?
• Des processus ou conteneurs de workers distincts sont-ils requis, et à quoi doivent-ils pouvoir accéder ?
• Quelles données de sauvegarde, quels emplacements de stockage et quelles étapes de restauration sont requis ? Airbip propose des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables, mais le propriétaire de l’application doit toujours décider quelles données entrent dans le périmètre et tester les procédures de restauration adaptées à son environnement.

Intégrez les domaines, TLS et les proxys inverses à la conception sans exposer de services inutiles

Choisissez les domaines après avoir identifié les points d’entrée prévus. Un nom d’hôte doit représenter un objectif d’accès délibéré, comme une application destinée aux utilisateurs, un point de terminaison de webhook au périmètre limité ou un chemin d’administration soumis à des restrictions supplémentaires. Évitez de créer des noms DNS publics pour des services internes simplement parce qu’ils sont faciles à mémoriser.

La validation des certificats TLS fait également partie de la conception de l’exposition. Avec la validation HTTP-01 de Let’s Encrypt, l’autorité de certification récupère un fichier de vérification au nom d’hôte concerné, et le défi HTTP-01 est limité au port 80. Cela peut convenir à un point de terminaison web public, mais il s’agit d’une exigence concrète d’accessibilité à anticiper. La validation DNS-01 de Let’s Encrypt peut valider des noms dont les serveurs web ne sont pas exposés à l’Internet public, car la validation s’effectue au moyen d’un enregistrement DNS TXT.

Un proxy inverse permet à une équipe de faire du proxy — et non de chaque composant de l’application — la périphérie publique choisie. Il peut router des noms d’hôte et des chemins approuvés vers des services backend tandis que les ports backend restent privés. Cela ne rend pas automatiquement une architecture sûre ; l’équipe a toujours besoin d’une configuration correcte de l’application, de contrôles d’accès, de la maîtrise du DNS, du renouvellement des certificats et d’un contrôle des changements.

Airbip déploie les applications de son catalogue sous forme de charges de travail Docker sur des serveurs cloud Airbip et automatise le routage ainsi que les certificats TLS au moyen de Traefik et Let’s Encrypt. Les clients peuvent utiliser un sous-domaine Airbip ou un domaine personnalisé compatible. Ces capacités sont utiles lorsque la conception documentée prévoit un point de terminaison public géré pour l’application, mais elles ne suppriment pas la nécessité de décider quelles routes et quels flux de données sont approuvés.

• Attribuez un responsable à chaque zone DNS et à chaque nom d’hôte.
• Documentez si la validation de certificat utilise un chemin HTTP public ou une validation DNS, selon la conception des accès.
• Exposez les points d’entrée du proxy inverse requis par les services publics approuvés ; gardez les ports des services backend privés.
• Utilisez des noms d’hôte distincts ou des routes soigneusement limitées lorsque les fonctions publiques et restreintes ne peuvent pas être clairement séparées dans l’application.
• Testez le résultat visible de l’extérieur depuis un réseau extérieur au serveur, et pas seulement depuis l’hôte lui-même.
• Examinez les responsabilités liées au renouvellement des certificats et aux changements DNS dans le cadre de la responsabilité opérationnelle.