Peut-on encore raisonnablement exposer directement nos applications ?

Nous enchaînons les CVE à un rythme qui pose une véritable question d’architecture. Peut-on encore considérer qu’une application exposée sur Internet restera suffisamment sécurisée pour lui confier seule la protection de ses accès ? Nous multiplions les applications, leurs dépendances, leurs frameworks et leurs cycles de mises à jour, tout en sachant qu’une seule vulnérabilité peut suffire à compromettre un système.

Prenons Confluence. En 2023, la CVE-2023-22515 permettait à un attaquant non authentifié de créer un compte administrateur sur certaines versions. En 2024, la CVE-2024-27198 de TeamCity permettait de contourner son authentification et potentiellement de compromettre entièrement le serveur. Ces vulnérabilités concernaient des applications professionnelles largement déployées, maintenues par des éditeurs reconnus, dont les mécanismes de sécurité étaient pourtant contournables.

Avec l'IA, cette situation devient encore moins confortable. L'analyse de vulnérabilités, la recherche de chemins d'exploitation et l'automatisation des attaques peuvent s'accélérer. Nous ne pouvons plus construire notre sécurité en pariant sur la capacité de chaque éditeur à corriger ses applications avant qu'un attaquant ne les exploite. Notre architecture doit rester défendable même lorsqu'une application est vulnérable.

Nginx et OIDC : pourquoi confier la première barrière à l'application ?

Chez Ariovis, nous avons fait un choix que je trouve de plus en plus pertinent : remonter une partie de la sécurité au niveau des middlewares et de l'infrastructure, avant même que les requêtes n'atteignent nos applications.

En plaçant un reverse proxy Nginx devant nos outils, avec une authentification fédérée en OpenID Connect (OIDC), nous imposons un contrôle d'identité indépendant du logiciel protégé. L'utilisateur doit s'authentifier auprès de notre fournisseur d'identité avant que le proxy n'autorise sa requête. L'application conserve ses propres contrôles, mais elle ne constitue plus notre unique ligne de défense.

Reprenons TeamCity. Si son mécanisme d'authentification peut être contourné par une CVE, un reverse proxy correctement configuré continuera d'exiger une identité valide avant de laisser passer la requête malveillante. La vulnérabilité applicative existe toujours, mais son exploitation anonyme depuis Internet devient beaucoup plus difficile. Nous avons déplacé la frontière de sécurité hors du composant qui présente la faille.

Je considère aussi qu'il est plus raisonnable de maîtriser un nombre limité de composants d'authentification standardisés que de dépendre de dizaines d'implémentations applicatives différentes. Nginx n'est pas invulnérable, et aucune statistique ne permet d'affirmer qu'il sera toujours moins vulnérable que les applications protégées. En revanche, cette architecture réduit le nombre de mécanismes d'authentification à maintenir et nous permet d'intervenir directement sur la politique d'accès, sans dépendre du calendrier de chaque éditeur.

Encore faut-il que toutes les routes sensibles passent réellement par ce contrôle et que les serveurs applicatifs ne soient pas directement joignables. C'est une contrainte d'architecture que nous pouvons maîtriser et vérifier.

Cloud privé ou SSO généralisé ? Nous avons choisi les deux.

L'autre réaction face à l'augmentation des vulnérabilités consiste à tout refermer. Héberger ses applications en cloud privé, supprimer leurs expositions publiques et contrôler strictement les flux réseau est une stratégie parfaitement défendable. Mais elle peut devenir pénible pour les utilisateurs, surtout lorsqu'elle repose sur des VPN traditionnels donnant accès à des portions entières du système d'information.

Chez Ariovis, nous combinons cette isolation avec du ZTNA et des contrôles d'identité au niveau des reverse proxies. Nos ressources internes ne sont pas directement accessibles depuis Internet ; l'accès réseau est conditionné à l'identité, tandis que le middleware contrôle les requêtes HTTP avant leur transmission aux applications.

Cette combinaison renverse notre manière de penser le pare-feu. Le réseau est verrouillé par défaut, mais c'est l'identité qui permet de le déverrouiller pour atteindre une ressource précise. Le collaborateur accède à ses outils grâce à son identité, sans devoir nécessairement connaître leur emplacement réseau ou gérer un VPN complexe.

Le SSO apporte ici un bénéfice supplémentaire : l'authentification forte, les politiques d'accès conditionnel et la révocation des sessions sont centralisées. Nous pouvons modifier les conditions d'entrée de plusieurs applications sans intervenir dans chacune de leurs bases de code. C'est aussi une manière de réduire les délais de réaction lorsqu'une application devient particulièrement exposée.

L'IA rend cette séparation encore plus nécessaire

Les agents IA vont multiplier les interactions entre applications, API et données. Chaque nouvel outil connecté à un agent représente potentiellement un nouveau chemin d'accès, tandis que les identités non humaines et les délégations introduisent des risques que le SSO traditionnel ne couvre pas entièrement.

La réponse ne consiste pas à permettre à un agent authentifié de tout faire. Nous devons distinguer trois contrôles : l'identité qui autorise l'ouverture du chemin réseau, l'authentification qui permet d'atteindre le service et l'autorisation qui détermine ce que l'agent peut effectivement exécuter. Pour les appels machine-à-machine, des jetons OAuth adaptés et des contrôles d'autorisation au niveau des API complètent les protections destinées aux utilisateurs humains.

Cette séparation est essentielle : une authentification réussie ne garantit jamais qu'une action soit légitime. Elle permet néanmoins de conserver une première frontière de sécurité indépendante de la logique applicative, y compris lorsque celle-ci évolue rapidement.

Une conviction que nous appliquons chez Ariovis

Nous appliquons cette approche à notre propre système d'information, avec une infrastructure hybride, des ressources protégées derrière un reverse proxy fédéré à Microsoft Entra ID et des mécanismes d'accès réseau conditionnel.

Ariovis a obtenu sa certification ISO/IEC 27001:2022 le 25 octobre 2026. Notre audit de certification de deuxième étape n'a relevé aucune non-conformité, majeure ou mineure. Ce résultat ne signifie pas que nos applications seront exemptes de vulnérabilités, mais il confirme la conformité du système de management audité, dont les contrôles d'accès font partie.

« Identity is the new firewall » était une conviction d'architecte IAM. Aujourd'hui, c'est une réponse concrète à la multiplication des vulnérabilités applicatives et à l'accélération des usages de l'IA.

Nous ne pouvons pas garantir que toutes nos applications resteront sécurisées. Nous pouvons en revanche décider qu'aucune application interne ne sera seule responsable de sa propre protection.