Visio conférence et téléphonie Teams à l’épreuve des sécurités d’entreprise

L’ouverture des périphériques

La première contrainte à prendre en compte est bien naturellement les temps de transit entre les utilisateurs finaux et le point de services Microsoft Teams. Là où vous transportiez de la donnée, vous allez devoir transporter de la voix et de la vidéo avec des exigences de latence assez élevées. Si cette opération est relativement maîtrisable sur des réseaux internes, elle l’est beaucoup moins lorsqu’un tronçon se trouve être Internet.

La seconde contrainte, que vous aurez en prendre en compte et que nous allons détailler ici, est l’ouverture de tous vos périphériques vers l’environnement Microsoft Teams.

Dans un environnement Skype for Business « on Premise » connecté à des passerelles de communications gérant des trunk sip locaux, les périphériques tels que les téléphones, les salles de réunions, les dispositifs audio (Poly Trio ou autre) n’ont pas la nécessité de « sortir » vers Internet puisque leurs points de connexion (serveurs Skype, passerelles SIP) demeurent internes.

Dans l’environnement Microsoft Teams, la contrainte de faire sortir ces petits dispositifs, (dont vous aurez pris soin auparavant de vérifier qu’ils sont « Teams compatibles »), vers les points de connexion Microsoft va nécessairement se poser. Là, vont commencer les interrogations.

Dans la plupart des entreprises et depuis quelques années, la sécurité s’est considérablement renforcée, l’usage des services proxy authentifiés, effectuant de l’inspection https s’est généralisé. Je pense notamment à la présence de solutions comme Zscaler, ou Forcepoint (anciennement Websense). Il n’est actuellement plus question de sortir de façon anonyme sans que vos destinations soient validées par ces fameux services proxy ou inspectées par les Pare feu de nouvelle génération.

Si vous démarrez un téléphone Teams, qu’il soit de Marque Yealink, Polycom, ou bien Audiocode la première chose que vous verrez apparaître après le logo du constructeur est un message d’erreur vous informant qu’il ne peut joindre le service Microsoft en question dû à des problèmes réseau.

Erreur de connexion d’un téléphone Teams

La raison est simple. Là où le client Skype utilisait le protocole SIP en Tcp, le client Teams utilise le protocole de signalisation Microsoft Network Protocol version 24 (MNP24). Là où le flux de signalisation des clients Skype sortait par les routeurs et les divers pare-feu de l’entreprise, le flux de signalisation des clients Teams requiert le port 443 (Tcp) ainsi que l’usage de REST APIs (HTTPS).

Si l’on s’en tient aux recommandations Microsoft, la solution est clairement simple : le trafic de vos périphériques Teams, PC compris, doit contourner toutes les protections que vos collègues de la sécurité ont mis en place.

Extrait de la documentation Microsoft : « Les entreprises clientes doivent revoir leurs méthodes de sécurité et de réduction des risques spécifiquement pour le trafic lié à Office 365 et utiliser les fonctionnalités de sécurité d’Office 365 afin de réduire leur dépendance à l’égard de technologies de sécurité intrusives, coûteuses et ayant un impact sur les performances pour le trafic réseau d’Office 365 » A peu de chose près la même chose mais en image.

Source Microsoft

Proposer au département sécurité, le contournement systématique des équipements de sécurité que l’entreprise s’est imposée, pour des dispositifs Android dont le niveau de sécurité reste à évaluer, connectés de surcroît sur le réseau de l’entreprise, me parait comment dire … quelque peu risqué.

Autrement dit, pour revenir à des considérations plus basiques, votre téléphone Teams n’est pas près de fonctionner.

Quelle solution pour ses périphériques ?

Une fois avoir constaté que votre magnifique téléphone ou dispositif audio Teams ne se connecte pas, il y a de forte chance que vous jetiez votre dévolu sur les options réseau de votre périphérique pour in fine découvrir que la case proxy n’existe pas.

En effet, les constructeurs n’incluent pas dans le firmware, la gestion de cette méthode de connexion. Encore l’incorporaient-ils, que vous devriez supprimer l’inspection HTTPS effectuée par votre service de Proxy. Maigre consolation, si vous connectez ce même dispositif derrière une simple box Internet vous constaterez qu’il se connecte parfaitement.

Il faut cependant leur reconnaitre la prise en compte de certaines fonctionnalités réseau comme le Cisco Discovery Protocol (CDP), le Link Layer Discovery Protocol (LLDP), la gestion des options de configuration DHCP, le 802.1X ainsi que la gestion des Vlan. Ci-dessous les options avancées d’un téléphone Teams d’entrée de gamme de marque Yealink.

La solution la plus raisonnable, tant que les constructeurs ne proposent pas d’option proxy, consiste donc à se passer de ces derniers en mettant en place un VLAN spécifique que l’on prendra soin d’isoler des réseaux internes.

De ce fait, la connexion entre ces périphériques et les points de services Microsoft ne sera contrôlée que par les pare-feu de l’entreprise. D’autre part, comme la connexion entre les stations de travail Windows, (qui utilisent le client Teams), et ces périphériques audios, (isolés dans leur vlan), ne pourra s’établir, les flux audio point à point ne seront pas possibles.

Le schéma suivant illustre par conséquent la topologie qu’il convient de mettre en place pour contourner l‘absence de gestion du proxy.

Les flux en bleu représentent les flux UDP générés par les appels voix et vidéo, les flux en marron sont les flux applicatifs dont la signalisation.

Comme précisé, la séparation des VLAN pour des raisons de sécurité ne permettra pas au trafic point à point de s’établir entre deux clients Teams de natures différentes (Client Teams de Périphérique et Client Teams sous Windows). Autrement dit, les flux temps réel d’une salle de réunion Teams sur un site A invitant un client Teams Windows connecté sur le même site passeront nécessairement par le point de service chez Microsoft et par conséquent par votre connexion Internet. Cela sera à prendre en compte dans le calcul de bande passante de chaque site.  Mais est-ce vraiment un handicap ?

Comme vous le savez peut-être, le client Teams est conçu pour déterminer le chemin le plus court entre deux participants d’un appel audio ou vidéo. Si le point à point est possible, alors les flux temps réels passeront entre les deux machines des participants. Si cela n’est pas possible alors ces flux seront acheminés vers Microsoft. Dans le schéma ci-dessus, compte tenu de l’isolement du VLAN Teams vis-à-vis du Vlan Corporate, c’est exactement ce qui va se passer.  Si cela est dommageable entre deux clients Teams de natures différentes appartenant au même site, (je pense notamment au scénario de deux personnes dans le même immeuble qui s’appellent), cela peut avoir du sens entre deux personnes éloignées de quelques milliers de kilomètres.

Le schéma suivant montre l’organisation privilégiant l’usage d’internet. C’est, par ailleurs la recommandation officielle de l’éditeur. Dans ce schéma, les flux UDP entre les sites sont bloqués contraignant les clients Teams à les acheminer via leur sortie locale.

Dans ce cas de figure, le fait de forcer le flux temps réel, vers Microsoft, réduira l’utilisation du réseau MPLS au profit des connexions Internet et du réseau Azure. Cela va aussi simplifier le diagnostic en cas de problématique de bande passante car seul un chemin sera utilisé.

La question qu’il faudra donc se poser est la suivante : Ai-je intérêt à faire passer mes flux audio et vidéo par mon réseau MPLS pour les appels point à point (auquel cas je risque de rogner sur mon niveau de sécurité), ou n’ai-je pas plutôt intérêt à forcer ces flux à emprunter mes connexions internet de sites, elles-mêmes connectées aux points de présence Azure ?

Il faut avouer que la réponse dépend de chaque environnement mais qu’elle mériterait une réponse avant de se lancer dans le déploiement de Teams à grande échelle.