Mise en réseau (vers le cloud) : point de vue d’un architecte

Dans cet article, Ed Fisher, architecte de sécurité & conformité chez Microsoft, explique comment optimiser votre réseau pour la connectivité cloud en évitant les pièges les plus courants.

À propos de l’auteur

Capture d’écran de la photo d’Ed Fisher.

Je suis actuellement spécialiste technique principal au sein de notre équipe de vente au détail et de biens de consommation, qui se concentre sur la sécurité & la conformité. J’ai travaillé avec des clients qui déménagent à Office 365 au cours des dix dernières années. J’ai travaillé avec des magasins plus petits avec une poignée d’emplacements pour des agences gouvernementales et des entreprises avec des millions d’utilisateurs répartis dans le monde entier, et beaucoup d’autres clients entre les deux, avec la majorité ayant des dizaines de milliers d’utilisateurs, plusieurs emplacements dans différentes parties du monde, la nécessité d’un niveau de sécurité plus élevé et une multitude d’exigences de conformité. J’ai aidé des centaines d’entreprises et des millions d’utilisateurs à migrer vers le cloud en toute sécurité.

Avec une expérience au cours des 25 dernières années qui inclut la sécurité, l’infrastructure et l’ingénierie réseau, et après avoir déménagé deux de mes anciens employeurs à Office 365 avant de rejoindre Microsoft, j’ai été de votre côté de la table beaucoup de fois, et je me souviens de ce que c’est comme. Bien qu’il n’y ait pas deux clients identiques, la plupart ont des besoins similaires, et lorsque vous consommez un service standardisé tel que n’importe quelle plateforme SaaS ou PaaS, les meilleures approches ont tendance à être les mêmes.

Ce n’est pas le réseau , c’est la façon dont vous l’utilisez (mal) !

Peu importe le nombre de fois où cela se produit, il ne manque jamais de m’étonner de voir comment les équipes de sécurité créatives et les équipes de mise en réseau essaient d’obtenir la façon dont elles pensent qu’elles doivent se connecter aux services cloud Microsoft. Il existe toujours une stratégie de sécurité, une norme de conformité ou une meilleure façon d’utiliser, sans être prêt à participer à une conversation sur ce qu’ils essaient d’accomplir, ou sur la façon dont il existe des moyens de le faire mieux, plus faciles, plus rentables et plus performants.

Lorsque ce genre de chose est remontée vers moi, je suis généralement prêt à relever le défi et à les guider à travers les comment et les pourquoi et les amener là où ils doivent être. Mais si je suis totalement franc, je dois partager que parfois je veux juste les laisser faire ce qu’ils vont, et revenir pour dire que je vous l’ai dit quand ils finalement concèdent que ça ne fonctionne pas. Je veux peut-être le faire parfois, mais je ne le fais pas. Ce que je fais est d’essayer d’expliquer tout ce que je vais inclure dans ce billet. Quel que soit votre rôle, si votre organization souhaite utiliser les services cloud Microsoft, il y a probablement une certaine sagesse dans ce qui suit qui peut vous aider.

Principes directeurs

Commençons par quelques règles de base concernant ce que nous faisons ici. Nous discutons de la façon de se connecter en toute sécurité aux services cloud pour garantir la complexité minimale et les performances maximales, tout en conservant une sécurité réelle. Rien de ce qui suit n’est contraire à cela, même si vous, ou votre client, ne pourrez pas utiliser votre serveur proxy favori pour tout.

  • Juste parce que vous pouvez, ne signifie pas que vous devriez : Ou pour paraphraser dr. Ian Malcolm du film Jurassic Park « ... Oui, oui, mais votre équipe de sécurité était tellement préoccupée de savoir si elle pouvait ou non qu’elle ne s’arrêtait pas à penser si elles le devaient.
  • La sécurité n’est pas synonyme de complexité : vous n’êtes pas plus sécurisé simplement parce que vous dépensez plus d’argent, que vous acheminez plus d’appareils ou que vous cliquez sur d’autres boutons.
  • Office 365 est accessible via Internet : Mais ce n’est pas la même chose que Office 365 est l’Internet. Il s’agit d’un service SaaS géré par Microsoft et administré par vous. Contrairement aux sites web que vous visitez sur Internet, vous pouvez réellement jeter un coup d’œil derrière le rideau, et peut appliquer les contrôles dont vous avez besoin pour répondre à vos politiques et à vos normes de conformité, tant que vous comprenez que bien que vous pouvez atteindre vos objectifs, vous devrez peut-être simplement les faire d’une manière différente.
  • Les points d’étranglement sont mauvais, les petits groupes localisés sont bons : tout le monde veut toujours rétrocéder tout son trafic Internet pour tous leurs utilisateurs à un point central, généralement pour qu’ils puissent le surveiller et appliquer la stratégie, mais souvent parce que c’est moins cher que de provisionner l’accès à Internet dans tous leurs emplacements, ou c’est juste la façon dont ils le font. Mais ces points d’étranglement sont exactement ça... points où le trafic s’étouffe. Il n’y a rien de mal à empêcher vos utilisateurs d’accéder à Instagram ou de diffuser en continu des vidéos de chat, mais ne traitez pas le trafic de votre application stratégique de la même façon.
  • Si LE DNS n’est pas heureux, ce n’est pas heureux : le réseau le mieux conçu peut être paralysé par un DNS médiocre, que ce soit en récursant les requêtes adressées aux serveurs dans d’autres régions du monde ou en utilisant les serveurs DNS de votre fournisseur de services Internet ou d’autres serveurs DNS publics qui mettez en cache les informations de résolution DNS.
  • Ce n’est pas parce que c’est comme ça que vous devez le faire maintenant : la technologie change constamment et Office 365 ne fait pas exception. L’application de mesures de sécurité qui ont été développées et déployées pour les services locaux ou pour contrôler la navigation sur le web n’offre pas le même niveau d’assurance de sécurité et peut avoir un impact négatif significatif sur les performances.
  • Office 365 a été conçu pour être accessible sur Internet : c’est tout en un mot. Peu importe ce que vous voulez faire entre vos utilisateurs et votre périphérie, le trafic passe toujours sur Internet une fois qu’il quitte votre réseau et avant qu’il n’arrive sur le nôtre. Même si vous utilisez Azure ExpressRoute pour acheminer un trafic sensible à la latence de votre réseau directement vers le nôtre, la connectivité Internet est absolument nécessaire. Acceptez-le. Ne le pensez pas trop.

Où les mauvais choix sont souvent faits

Bien qu’il y ait beaucoup d’endroits où les mauvaises décisions sont prises au nom de la sécurité, ce sont ceux que je rencontre le plus souvent avec les clients. De nombreuses conversations avec les clients impliquent toutes ces opérations à la fois.

Ressources insuffisantes à la périphérie

Très peu de clients déploient des environnements greenfield, et ils ont des années d’expérience avec le fonctionnement de leurs utilisateurs et leur sortie Internet. Que les clients disposent de serveurs proxy ou autorisent l’accès direct et simplement le trafic sortant NAT, ils le font depuis des années et ne tiennent pas compte de la quantité de plus qu’ils vont commencer à pomper dans leur périphérie à mesure qu’ils déplacent des applications internes vers le cloud.

La bande passante est toujours un problème, mais les appareils NAT peuvent ne pas avoir suffisamment de puissance pour gérer la charge accrue et peuvent commencer à fermer prématurément les connexions pour libérer des ressources. La plupart des logiciels clients qui se connectent à Office 365 s’attendent à des connexions persistantes et un utilisateur utilisant pleinement Office 365 peut avoir au moins 32 connexions simultanées. Si l’appareil NAT les supprime prématurément, ces applications peuvent ne plus répondre lorsqu’elles essaient d’utiliser les connexions qui n’y sont plus. Lorsqu’ils abandonnent et tentent d’établir de nouvelles connexions, ils mettent encore plus de charge sur votre équipement réseau.

Petit groupe localisé

Tout le reste de cette liste se résume à une seule chose : sortir de votre réseau et accéder au nôtre aussi rapidement que possible. Le retour du trafic de vos utilisateurs vers un point de sortie central, en particulier lorsque ce point de sortie se trouve dans une autre région que celle de vos utilisateurs, introduit une latence inutile et a un impact à la fois sur l’expérience client et les vitesses de téléchargement. Microsoft a des points de présence dans le monde entier avec des front-ends pour tous nos services et peering établis avec pratiquement tous les principaux isp, de sorte que le routage du trafic de vos utilisateurs localement garantit qu’il accède rapidement à notre réseau avec une latence minimale.

Le trafic de résolution DNS doit suivre le chemin de sortie Internet

Bien entendu, pour qu’un client trouve un point de terminaison, il doit utiliser DNS. Les serveurs DNS de Microsoft évaluent la source des requêtes DNS pour nous assurer que nous renvoyons la réponse la plus proche, en termes Internet, de la source de la requête. Assurez-vous que votre DNS est configuré de sorte que les demandes de résolution de noms sortent du même chemin que le trafic de vos utilisateurs, de sorte que vous ne leur donniez pas une sortie locale, mais à un point de terminaison dans une autre région. Cela signifie que les serveurs DNS locaux « vont à la racine » au lieu de les transférer vers des serveurs DNS dans des centres de données distants. Et watch pour les services DNS publics et privés, qui peuvent mettre en cache les résultats d’une partie du monde et les servir aux demandes provenant d’autres parties du monde.

Pour ou non pour le proxy, c’est la question

L’une des premières choses à prendre en compte est de savoir si les connexions des utilisateurs doivent être proxy vers Office 365. C’est facile. ne pas proxy. Office 365 est accessible via Internet, mais ce n’est pas l’Internet. Il s’agit d’une extension de vos services de base et doit être traité comme tel. Tout ce que vous souhaitez qu’un proxy fasse, tel que DLP ou anti-programme malveillant ou inspection du contenu, est déjà disponible dans le service et peut être utilisé à grande échelle et sans avoir à déchiffrer les connexions chiffrées TLS. Mais si vous souhaitez vraiment proxy du trafic que vous ne pouvez pas contrôler autrement, faites attention à nos conseils https://aka.ms/pnc sur et aux catégories de trafic sur https://aka.ms/ipaddrs. Nous avons trois catégories de trafic pour Office 365. Optimiser et Autoriser doivent aller directement et contourner votre proxy. La valeur par défaut peut être proxiée. Les détails se trouvent dans ces documents... lisez-les.

La plupart des clients qui insistent sur l’utilisation d’un proxy, lorsqu’ils regardent réellement ce qu’ils font, se rendent compte que lorsque le client effectue une requête HTTP CONNECT au proxy, le proxy n’est plus qu’un routeur supplémentaire coûteux. Les protocoles utilisés tels que MAPI et RTC ne sont même pas des protocoles que les proxys web comprennent. Par conséquent, même avec le cracking TLS, vous n’obtenez pas vraiment de sécurité supplémentaire. Vous obtenez* une latence supplémentaire. Consultez https://aka.ms/pnc pour plus d’informations à ce sujet, notamment les catégories Optimiser, Autoriser et Par défaut pour le trafic Microsoft 365.

Enfin, tenez compte de l’impact global sur le proxy et de sa réponse correspondante pour faire face à cet impact. Comme de plus en plus de connexions sont établies via le proxy, le facteur d’échelle TCP peut diminuer afin qu’il n’ait pas à mettre en mémoire tampon autant de trafic. J’ai vu des clients où leurs proxys étaient tellement surchargés qu’ils utilisaient un facteur d’échelle de 0. Étant donné que Scale Factor est une valeur exponentielle et que nous aimons utiliser 8, chaque réduction de la valeur du facteur d’échelle a un impact négatif énorme sur le débit.

L’inspection TLS signifie SÉCURITÉ ! Mais pas vraiment ! De nombreux clients disposant de proxys souhaitent les utiliser pour inspecter tout le trafic, ce qui signifie que TLS « casse et inspecte ». Lorsque vous faites cela pour un site web accessible via HTTPS (indépendamment des problèmes de confidentialité), votre proxy peut avoir à le faire pour 10 ou même 20 flux simultanés pendant quelques centaines de millisecondes. S’il y a un téléchargement volumineux ou peut-être une vidéo impliquée, une ou plusieurs de ces connexions peuvent durer beaucoup plus longtemps, mais dans l’ensemble, la plupart de ces connexions s’établissent, transfèrent et se ferment très rapidement. L’arrêt et l’inspection signifie que le proxy doit effectuer le double du travail. Pour chaque connexion du client au proxy, le proxy doit également établir une connexion distincte au point de terminaison. Donc, 1 devient 2, 2 devient 4, 32 devient 64...voir où je vais ? Vous avez probablement bien dimensionné votre solution de proxy pour la navigation web classique, mais lorsque vous essayez de faire la même chose pour les connexions clientes à Office 365, le nombre de connexions simultanées de longue durée peut être supérieur à ce que vous avez dimensionné.

Le streaming n’est pas important, sauf qu’il est

Les seuls services dans Office 365 qui utilisent UDP sont Skype (bientôt mis hors service) et Microsoft Teams. Teams utilise UDP pour le trafic de streaming, y compris le partage audio, vidéo et de présentation. Le trafic de streaming est en direct, par exemple lorsque vous avez une réunion en ligne avec voix, vidéo, présentation de decks ou exécution de démonstrations. Ceux-ci utilisent UDP, car si les paquets sont supprimés ou arrivent dans le désordre, cela est pratiquement imperceptible par l’utilisateur et le flux peut simplement continuer.

Lorsque vous n’autorisez pas le trafic UDP sortant des clients vers le service, ils peuvent revenir à l’utilisation de TCP. Toutefois, si un paquet TCP est supprimé, tout s’arrête jusqu’à ce que le délai d’expiration de retransmission (RTO) expire et que le paquet manquant puisse être retransmis. Si un paquet arrive dans le désordre, tout s’arrête jusqu’à ce que les autres paquets arrivent et peuvent être réassemblons dans l’ordre. Les deux conduisent à des problèmes perceptibles dans l’audio (vous vous souvenez Max Headroom ?) et la vidéo (avez-vous cliqué sur quelque chose... Oh, c’est là) et conduire à des performances médiocres et une mauvaise expérience utilisateur. Et rappelez-vous ce que j’ai mis en haut sur les proxys ? Lorsque vous forcez un client Teams à utiliser un proxy, vous le forcez à utiliser TCP. Vous êtes donc à l’origine de deux impacts négatifs sur les performances.

Le tunneling fractionné peut sembler effrayant

Mais ce n’est pas le cas. Toutes les connexions à Office 365 sont via TLS. Nous offrons TLS 1.2 depuis un certain temps maintenant et désactiverons bientôt les versions antérieures, car les clients hérités les utilisent toujours et c’est un risque.

Le fait de forcer une connexion TLS, ou 32 d’entre eux, à passer par un VPN avant d’accéder au service n’ajoute pas de sécurité. Il ajoute une latence et réduit le débit global. Dans certaines solutions VPN, il force même UDP à tunneliser via TCP, ce qui aura là encore un impact très négatif sur le trafic de streaming. Et, sauf si vous effectuez une inspection TLS, il n’y a pas d’avantage, tout inconvénient. Un thème très courant parmi les clients, maintenant que la plupart de leur personnel est à distance, est qu’ils constatent des impacts significatifs sur la bande passante et les performances du fait que tous leurs utilisateurs se connectent à l’aide d’un VPN, au lieu de configurer le tunneling fractionné pour l’accès à la catégorie Optimiser Office 365 points de terminaison.

Il s’agit d’une solution facile à faire du tunneling fractionné et c’est une solution que vous devez faire. Pour plus d’informations, consultez Optimiser la connectivité Office 365 pour les utilisateurs distants à l’aide du tunnel partagé VPN.

Les péchés du passé

Souvent, la raison pour laquelle les mauvais choix sont faits provient d’une combinaison de (1) ne pas connaître le fonctionnement du service, (2) d’essayer d’adhérer aux stratégies de l’entreprise qui ont été écrites avant l’adoption du cloud et (3) d’équipes de sécurité qui peuvent ne pas être facilement convaincues qu’il existe plusieurs façons d’atteindre leurs objectifs. Espérons que ce qui précède, et les liens ci-dessous, vous aideront à la première. Le parrainage exécutif peut être nécessaire pour passer la seconde. Le fait de répondre aux objectifs des stratégies de sécurité, plutôt qu’à leurs méthodes, aide à la troisième. De l’accès conditionnel à la modération du contenu, de la protection contre la perte de données à la protection des informations, de la validation des points de terminaison aux menaces zero-day : tout objectif final qu’une stratégie de sécurité raisonnable peut avoir peut être atteint avec ce qui est disponible dans Office 365, et sans dépendance vis-à-vis de l’équipement réseau local, des tunnels VPN forcés et de l’arrêt et de l’inspection TLS.

D’autres fois, le matériel qui a été dimensionné et acheté avant le organization a commencé à passer au cloud ne peut tout simplement pas être mis à l’échelle pour gérer les nouveaux modèles et charges de trafic. Si vous devez vraiment acheminer tout le trafic via un point de sortie unique et/ou le proxy, préparez-vous à mettre à niveau l’équipement réseau et la bande passante en conséquence. Surveillez attentivement l’utilisation sur les deux, car l’expérience ne diminue pas lentement à mesure que d’autres utilisateurs s’y intègrent. Tout va bien jusqu’à ce que le point bascule soit atteint, alors tout le monde souffre.

Exceptions aux règles

Si votre organization nécessite des restrictions de locataire, vous devez utiliser un proxy avec arrêt et inspection TLS pour forcer le trafic via le proxy, mais vous n’avez pas à forcer tout le trafic via celui-ci. Il ne s’agit pas d’une proposition tout ou rien. Faites donc attention à ce qui doit être modifié par le proxy.

Si vous envisagez d’autoriser le tunneling fractionné, mais également d’utiliser un proxy pour le trafic web général, assurez-vous que votre fichier PAC définit ce qui doit être direct, ainsi que la façon dont vous définissez le trafic intéressant pour ce qui passe par le tunnel VPN. Nous proposons des exemples de fichiers PAC sur https://aka.ms/ipaddrs qui facilitent la gestion.

Conclusion

Des dizaines de milliers d’organisations, y compris presque toutes les fortunes 500, utilisent Office 365 quotidiennement pour leurs fonctions stratégiques. Ils le font en toute sécurité, et ils le font sur Internet.

Quels que soient les objectifs de sécurité que vous avez en jeu, il existe des moyens de les accomplir qui ne nécessitent pas de connexions VPN, de serveurs proxy, de coupure et d’inspection TLS, ou de sortie Internet centralisée pour que le trafic de vos utilisateurs sortent de votre réseau et accèdent au nôtre aussi rapidement que vous le pouvez, ce qui offre les meilleures performances, que votre réseau soit le siège social de l’entreprise, un bureau distant, ou cet utilisateur travaillant à domicile. Nos conseils sont basés sur la façon dont les services Office 365 sont créés et pour garantir une expérience utilisateur sécurisée et performante.

Pour plus d’informations

Principes de connectivité réseau Office 365

URL et plages d’adresses IP Office 365

Gestion des points de terminaison Office 365

Service web URL et adresses IP Office 365

Évaluation de la connectivité réseau Office 365

Paramétrage des performances et du réseau Office 365

Évaluation de la connectivité réseau Office 365

Réglage des performances Office 365 à l’aide du planning de référence et de l’historique des performances

Plan de résolution des problèmes de performances pour Office 365

Réseaux de distribution de contenu

Test de connectivité Microsoft 365

Comment Microsoft construit son réseau mondial rapide et fiable

Blog sur la mise en réseau Office 365

Office 365 connectivité pour les utilisateurs distants à l’aide du tunneling vpn fractionné