Les offres de logiciels en tant que service (SaaS) deviennent de plus en plus répandues dans tous les secteurs, car les organisations recherchent des moyens toujours plus dynamiques et flexibles d'exploiter les logiciels tout en garantissant la stabilité opérationnelle, la transparence des coûts, l'évolutivité dynamique et l'agilité.
Avant d’en arriver à l’application fournie par un tiers, nous devons toutefois mettre en place plusieurs composants pour permettre à nos utilisateurs d’y accéder, tels que : la connectivité réseau, le stockage, le calcul (dans la couche d’infrastructure), la virtualisation, le système d’exploitation, le middleware, l’environnement d’exécution et tout ce qui est nécessaire pour permettre à l’application de s’exécuter au sein de la couche de services. Ce n’est qu’alors que vous entrez dans le domaine de la configuration RBAC, de la gestion des utilisateurs et de la distribution de l’application à vos utilisateurs finaux.
Il est également important de noter que même si de nombreuses couches ci-dessus connaissent une consolidation et un chevauchement de la technologie sous-jacente au sein de la fonction, les organisations ont généralement des équipes différentes avec des processus uniques qui possèdent leur couche spécifique. Le plus souvent, plusieurs équipes opèrent à chaque niveau.
Cet article présente les idées et les innovations de Thad Széll (ingénieur distingué chez UBS) et Nuno Ferreira (Field CTO chez Volterra) pour permettre aux organisations d'adopter des applications SaaS en temps réel, de manière sécurisée et privée sans compromettre ni altérer l'environnement existant. Leur objectif a 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 surgit la première série de problèmes. Le premier problème d’infrastructure découle du fait qu’auparavant l’application reposait sur une infrastructure contrôlée, principalement statique, et qu’elle sera désormais accessible via Internet, qui est extrêmement dynamique et n’est pas sous le contrôle d’une entité spécifique.
Certains fournisseurs SaaS ont la possibilité de fournir des circuits dédiés (par exemple, Azure propose ExpressRoute) ou des VPN pour que les organisations puissent s'y connecter en privé. Pour adopter de tels mécanismes, les organisations devront au moins :
Échangez (au niveau du réseau) avec le fournisseur SaaS et maintenez les relations de routage. Injectez/publiez les adresses IP publiques du fournisseur SaaS dans le réseau de l'entreprise. Traitez le service comme un extranet ou une DMZ et superposez des niveaux de segmentation et de sécurité. Dans les cas où le fournisseur SaaS propose uniquement un service VPN au client, un appareil est alors nécessaire pour créer et maintenir ce VPN. Notez que ces technologies ne résolvent pas le problème de latence.
Disposer d’un proxy direct/NAT peut résoudre certains problèmes de sécurité, mais il ne résoudra PAS le problème de routage et la nécessité d’injecter des adresses IP publiques tierces dans le réseau d’entreprise.
De plus, les fournisseurs SaaS sont souvent extrêmement dynamiques et leurs adresses annoncées, leurs noms DNS et leurs points de terminaison publiés changent très régulièrement. Par conséquent, des mécanismes opérationnels doivent être en place pour maintenir les contrôles de peering/injection/publicité et de sécurité.
Une solution permettant le forward proxy / NAT sans avoir besoin de routage est donc plus élégante et nécessaire.
Prenons l’exemple d’Office 365. Microsoft étend son empreinte cloud avec Azure et les services d’application Microsoft se développent chaque jour. Cette plateforme permet aux grandes entreprises de disposer de liens physiques privés, dédiés et à haut débit vers Azure appelés ExpressRoute.
Microsoft pourrait donc résoudre les problèmes mentionnés ci-dessus (autour de la confidentialité et de la latence) en permettant aux employés de l’entreprise d’accéder à Office 365 via ce circuit ExpressRoute privé dédié.
ExpressRoute pour Office 365 fournit un chemin de routage alternatif vers de nombreux services Office 365 accessibles via Internet. L'architecture d'ExpressRoute pour Office 365 est basée sur la publicité des préfixes IP publics des services Office 365 qui sont déjà accessibles via Internet dans vos circuits ExpressRoute provisionnés pour une redistribution ultérieure de ces préfixes IP dans votre réseau. Avec ExpressRoute, vous activez efficacement plusieurs chemins de routage différents pour les services Office 365 : Internet et ExpressRoute. Cet état de routage sur votre réseau peut représenter un changement important dans la manière dont la topologie de votre réseau interne est conçue et sécurisée.
Ok, peut-être pas si privé que ça.
L'image ci-dessous représente 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 d'infrastructure du réseau d'entreprise devra injecter de l'espace IP routable publiquement dans son réseau d'entreprise pour permettre aux utilisateurs de suivre le chemin préféré (via ExpressRoute). De plus, afin d’éviter toute exposition du réseau d’entreprise à Microsoft, l’équipe réseau devra également mettre en œuvre du NAT vers ce réseau Microsoft. Cela entraîne non seulement une complexité opérationnelle liée à la maintenance du peering BGP (avec NAT) avec Microsoft, mais nécessite également une planification minutieuse pour tenir compte des complexités du réseau liées à la disponibilité du routage via un circuit dédié avec des routes injectées dans votre réseau principal et sur Internet. Les adresses de gestion des changements de sécurité d’Office 365 changent de temps à autre et, par conséquent, ces changements doivent être reflétés dans la sécurité interne et l’infrastructure proxy de l’entreprise. Le non-respect de cette consigne peut entraîner une perte intermittente ou totale de connectivité aux services Office 365 lorsque le circuit ExpressRoute est activé. Microsoft fournit un document complet et régulièrement mis à jour (et une API REST) qui fournit une liste de domaines, d'adresses IP et de ports TCP/UDP qui doivent être configurés et mis à jour en permanence sur les dispositifs de sécurité et de routage de l'entreprise pour appliquer les politiques de sécurité et de gouvernance de l'entreprise. Visibilité opérationnelle et de sécurité Il y a peu ou pas de visibilité avec les périphériques NAT dans l'application. Alors, comment avons-nous abordé ce scénario alors que rien ne semblait être assez bon ?
Nous avons élaboré une solution élégante qui élimine le besoin de gérer une infrastructure réseau complexe et des politiques de sécurité tout en offrant aux employés les avantages de la connectivité ExpressRoute pour accéder à Office 365 et aux services d'application associés.
La pile réseau et de sécurité intégrée de Volterra comprend un routeur d’application avec des capacités de proxy programmables et d’équilibrage de charge pour répondre à ce besoin. Outre ces fonctionnalités, Volterra offre aux entreprises un moyen simple d’évoluer vers la sécurité Zero Trust.
À un niveau élevé, l'entreprise disposera d'un cluster Volterra Application Gateway en peering avec le routeur ExpressRoute où Microsoft présente les routes/services Office 365. La passerelle d'application Volterra effectue la découverte automatisée des points de terminaison Office 365 via ce routeur, permettant aux entreprises d'accéder aux services Office 365 à partir de là. Cette innovation permet aux opérateurs de ne plus avoir à gérer un autre processus pour traduire la configuration dynamique en règles sur leur infrastructure. L'innovation Volterra Gateway Auto-Discovery permet aux clients de modifier en permanence la destination de leurs demandes et la passerelle déclenchera la découverte automatique et l'intégrité TLS pour toute demande entrante.
La deuxième partie de la solution consiste à exposer ces services aux utilisateurs de l’entreprise sans annoncer les routes publiques Microsoft au sein du réseau de l’entreprise. Cela peut être réalisé de deux manières :
La première méthode consiste à effectuer cette opération directement à partir du cluster Volterra Application Gateway dans Azure via le circuit ExpressRoute. Notez que la seule injection IP dans le réseau d’entreprise sera l’adresse IP du cluster Volterra Application Gateway dans Azure. À des fins d’illustration, nous disons que la passerelle se trouve dans Azure, mais elle peut être située n’importe où à condition que ces 2 conditions soient remplies : a. Les utilisateurs peuvent accéder à la passerelle pour lui envoyer du trafic (ou la passerelle l'intercepte) b. La passerelle est connectée à un circuit Express Route où les points de terminaison Office 365 sont situés/détectables. La deuxième méthode consiste à ajouter un (ou plusieurs) clusters Volterra Application Gateway dans les locaux de l'entreprise (et les contrôleurs de domaine privés). Nous allons ensuite configurer des stratégies pour exposer les services de point de terminaison Office 365 découverts sur le cluster Application Gateway local. Ces points de terminaison sont découverts via la passerelle d’application Volterra qui se trouve dans le cloud Azure (comme expliqué dans la première partie). En outre, l’équipe des opérations de l’entreprise peut configurer des politiques de sécurité et d’authentification supplémentaires tout en chiffrant tout le trafic. Les images ci-dessous représentent ces scénarios :
Le cluster Volterra Application Gateway implémente également des fonctionnalités de mise à l'échelle automatique, ce qui signifie que lorsqu'une passerelle dépasse un seuil spécifique, elle en fait tourner une autre et l'ajoute au cluster.
Les autres fonctionnalités de la solution Volterra qui offrent des avantages significatifs aux équipes de réseau, de sécurité et d'exploitation de l'entreprise sont :
Simplicité opérationnelle avec politique centralisée et gestion basée sur SaaS Proxy, sécurité et routage intégrés/unifiés avec plan de données programmable Visibilité granulaire et riche, journalisation et mesures de l'utilisation et de l'accès aux applications En atteignant la simplicité et l'excellence opérationnelle, nous pensons que cette solution est la véritable réponse pour les organisations qui tentent d'atteindre des objectifs similaires à ceux d'UBS, où nous pouvons garantir que l'accès privé aux services SaaS, tels qu'Office 365, est utilisé sans qu'il soit nécessaire de rendre votre réseau d'entreprise « disponible pour, ou même faisant partie des réseaux publics ».