Les offres de logiciels en tant que service (SaaS) se généralisent dans tous les secteurs, les organisations recherchant des moyens toujours plus dynamiques et flexibles de tirer parti des logiciels tout en garantissant la stabilité opérationnelle, la transparence des coûts, l’évolutivité dynamique et l’agilité.
Cependant, avant d’en arriver à l’application fournie par un tiers, nous devons mettre en place plusieurs composants afin de permettre à nos utilisateurs d’y accéder, notamment : la connectivité réseau, le stockage, les ressources de calcul (dans la couche d’infrastructure), la virtualisation, le système d’exploitation, les intergiciels, l’environnement d’exécution et tout ce qui est nécessaire au fonctionnement de l’application au sein de la couche de services. Ce n’est qu’ensuite que l’on peut passer à la configuration du contrôle d’accès basé sur les rôles (RBAC), à la gestion des utilisateurs et à la distribution de l’application aux utilisateurs finaux.
Il est également important de noter que, même si bon nombre des couches mentionnées ci-dessus connaissent une consolidation et un chevauchement des technologies sous-jacentes au sein de la fonction, les organisations disposent généralement d’équipes distinctes, dotées de processus qui leur sont propres et responsables de leur couche respective. Le plus souvent, plusieurs équipes interviennent à chaque couche.
Cet article présente les idées et les innovations proposées par Thad Széll (Distinguished Engineer chez UBS) et Nuno Ferreira (Field CTO chez Volterra) afin de permettre aux organisations d’adopter des applications SaaS en temps réel, de manière sécurisée et confidentielle, sans compromettre ni altérer l’environnement existant. Leurs travaux ont commencé avec Microsoft Office 365.a
Comme nous le savons tous, les applications SaaS sont généralement accessibles via l’Internet public, et c’est là que survient une première série de problèmes. Le premier problème d’infrastructure tient au fait qu’auparavant, l’application était hébergée sur une infrastructure contrôlée et essentiellement statique, alors qu’elle sera désormais accessible via Internet, un environnement extrêmement dynamique qui n’est placé sous le contrôle d’aucune entité en particulier.
Certains fournisseurs de solutions SaaS peuvent proposer des liaisons dédiées (par exemple, Azure propose ExpressRoute) ou des VPN permettant aux organisations de se connecter à leurs services de manière privée. Pour adopter de tels mécanismes, les organisations devront au minimum :
Établir un appairage (au niveau du réseau) avec le fournisseur SaaS et maintenir les relations de routage. Injecter/annoncer les adresses IP publiques du fournisseur SaaS dans le réseau de l’entreprise. Traiter le service comme un extranet ou une DMZ et y superposer plusieurs niveaux de segmentation et de sécurité. Lorsque le fournisseur SaaS propose uniquement un service VPN au client, un équipement est nécessaire pour établir et maintenir ce VPN. Notez que ces technologies ne résolvent pas le problème de latence.
La mise en place d’un dispositif de proxy direct/NAT peut répondre à certaines préoccupations de sécurité, mais elle ne résoudra PAS le problème de routage ni la nécessité d’injecter des adresses IP publiques tierces dans le réseau de l’entreprise.
En outre, les fournisseurs de SaaS sont souvent extrêmement dynamiques, et les adresses qu’ils annoncent, leurs noms DNS et leurs points de terminaison publiés changent très régulièrement. Il est donc nécessaire de mettre en place des mécanismes opérationnels pour assurer la maintenance de l’appairage, de l’injection et de l’annonce des routes, ainsi que des contrôles de sécurité.
Une solution permettant d’utiliser un proxy direct / NAT sans avoir recours au routage est donc plus élégante et nécessaire.
Prenons l’exemple d’Office 365. Microsoft étend sa présence dans le cloud avec Azure, et les services applicatifs de Microsoft se développent chaque jour. Cette plateforme permet aux grandes entreprises de disposer de liaisons physiques privées, dédiées et à haut débit vers Azure, appelées ExpressRoute.
Microsoft pourrait donc résoudre les problèmes susmentionnés (liés à la confidentialité et à la latence) en permettant aux employés des entreprises d’accéder à Office 365 via ce circuit privé dédié ExpressRoute.
ExpressRoute pour Office 365 fournit un autre chemin de routage vers de nombreux services Office 365 accessibles via Internet. L’architecture d’ExpressRoute pour Office 365 repose sur l’annonce, dans vos circuits ExpressRoute provisionnés, des préfixes IP publics des services Office 365 déjà accessibles via Internet, afin que ces préfixes IP soient ensuite redistribués dans votre réseau. Avec ExpressRoute, vous activez de fait plusieurs chemins de routage différents vers les services Office 365 : Internet et ExpressRoute. Cette configuration du routage sur votre réseau peut entraîner une modification importante de la conception et de la sécurisation de la topologie de votre réseau interne.
Bon, ce n’est peut-être pas si privé que ça.
L’image ci-dessous illustre ce scénario :
Cette approche présente trois défis distincts pour les équipes réseau et sécurité :
Routage réseau et NAT L’équipe chargée de l’infrastructure réseau de l’entreprise devra injecter un espace d’adresses IP routables publiquement dans le réseau de l’entreprise afin de permettre aux utilisateurs d’emprunter le chemin privilégié (via ExpressRoute). En outre, afin d’éviter toute exposition du réseau de l’entreprise à Microsoft, l’équipe réseau devra également mettre en œuvre la NAT vers ce réseau Microsoft. Cela ajoute non seulement la complexité opérationnelle liée au maintien de l’appairage BGP (ainsi que de la NAT) avec Microsoft, mais nécessite également une planification rigoureuse pour tenir compte de la complexité d’un réseau où le routage est disponible à la fois via un circuit dédié, dont les routes sont injectées dans le réseau principal, et via Internet. Gestion des changements de sécurité Les adresses d’Office 365 évoluent de temps à autre. Ces changements doivent donc être répercutés dans l’infrastructure interne de sécurité et de proxy de l’entreprise. À défaut, une perte intermittente ou totale de la connectivité aux services Office 365 peut survenir lorsque le circuit ExpressRoute est activé. Microsoft fournit un document exhaustif et régulièrement mis à jour (ainsi qu’une API REST) répertoriant les domaines, les adresses IP et les ports TCP/UDP qui doivent être configurés et continuellement actualisés sur les équipements de sécurité et de routage de l’entreprise afin d’appliquer les politiques internes de sécurité et de gouvernance. Visibilité opérationnelle et de sécurité Les dispositifs NAT n’offrent que peu, voire aucune visibilité sur l’application. Alors, comment avons-nous abordé ce scénario alors qu’aucune solution ne semblait suffisamment satisfaisante ?
Nous avons élaboré une solution élégante qui évite d’avoir à gérer une infrastructure réseau et des politiques de sécurité complexes, tout en permettant aux employés de bénéficier de la connectivité ExpressRoute pour accéder à Office 365 et aux services applicatifs associés.
La pile intégrée de réseau et de sécurité de Volterra comprend un routeur applicatif doté de fonctionnalités programmables de proxy et d’équilibrage de charge pour répondre à ce besoin. Outre ces fonctionnalités, Volterra offre aux entreprises une voie simple pour évoluer vers une sécurité Zero Trust.
Dans les grandes lignes, l’entreprise disposera d’un cluster Volterra Application Gateway appairé au routeur ExpressRoute sur lequel Microsoft publie les routes et services Office 365. Volterra Application Gateway détecte automatiquement les points de terminaison Office 365 via ce routeur, ce qui permet aux entreprises d’accéder aux services Office 365 depuis celui-ci. Grâce à cette innovation, les opérateurs n’ont plus à gérer un processus supplémentaire pour convertir une configuration dynamique en règles applicables à leur infrastructure. La fonctionnalité de détection automatique de Volterra Gateway permet aux clients de modifier en permanence la destination de leurs requêtes ; la passerelle déclenche alors la détection automatique et garantit l’intégrité TLS de chaque requête entrante.
La deuxième partie de la solution consiste à rendre ces services accessibles aux utilisateurs de l’entreprise sans annoncer les routes publiques de Microsoft au sein du réseau d’entreprise. Cela peut être réalisé de deux manières :
La première méthode consiste à effectuer cette opération directement depuis le cluster Volterra Application Gateway dans Azure, via le circuit ExpressRoute. Notez que la seule adresse IP injectée dans le réseau d’entreprise sera celle du cluster Volterra Application Gateway dans Azure. À titre d’illustration, nous indiquons que la passerelle se trouve dans Azure, mais elle peut être située n’importe où, à condition que les deux conditions suivantes soient remplies : a. Les utilisateurs peuvent accéder à la passerelle pour lui envoyer du trafic (ou celle-ci l’intercepte). b. La passerelle est connectée à un circuit ExpressRoute sur lequel les points de terminaison Office 365 sont accessibles ou détectables. La seconde méthode consiste à ajouter un ou plusieurs clusters Volterra Application Gateway dans les locaux de l’entreprise (et dans ses centres de données privés). Nous configurerons ensuite des stratégies afin d’exposer, sur le cluster Application Gateway local, les services de points de terminaison Office 365 détectés. Ces points de terminaison sont détectés par le biais du Volterra Application Gateway situé dans le cloud Azure (comme expliqué dans la première partie). En outre, l’équipe chargée des opérations de l’entreprise peut configurer des stratégies de sécurité et d’authentification supplémentaires, tout en chiffrant l’ensemble du trafic. Les illustrations ci-dessous représentent ces scénarios :
Le cluster Volterra Application Gateway intègre également des fonctionnalités de mise à l’échelle automatique : lorsqu’une passerelle dépasse un seuil donné, une nouvelle passerelle est créée et ajoutée au cluster.
Les autres fonctionnalités de la solution Volterra qui offrent des avantages significatifs aux équipes chargées du réseau, de la sécurité et des opérations de l’entreprise sont les suivantes :
Simplicité opérationnelle grâce à une gestion centralisée des politiques et à une administration basée sur le SaaS. Proxy, sécurité et routage intégrés et unifiés, avec un plan de données programmable. Visibilité granulaire et détaillée, journalisation et métriques relatives à l’utilisation des applications et à leur accès. En alliant simplicité et excellence opérationnelle, nous pensons que cette solution répond véritablement aux besoins des organisations qui cherchent à atteindre des objectifs similaires à ceux d’UBS : garantir un accès privé à des services SaaS tels qu’Office 365, sans avoir à rendre leur réseau d’entreprise « accessible aux réseaux publics, voire à l’intégrer à ceux-ci ».
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.