Sécurité et Intégrité dans WUDO
Vérification de l’authenticité des données
La sécurité est un aspect crucial de Windows Update Delivery Optimization. Bien qu’avec WUDO les postes s’échangent des données entre eux, il est impératif de garantir que seules des données authentiques et non altérées seront installées sur les machines. Microsoft a donc mis en place plusieurs niveaux de vérification de l’intégrité pour s’assurer qu’un poste ne puisse jamais être compromis en téléchargeant des morceaux de fichiers depuis un pair inconnu.
Premièrement, WUDO ne traite que du contenu officiel Microsoft (mises à jour Windows, applications approuvées, etc.) – il n’est pas possible pour un utilisateur de partager ses propres fichiers via ce mécanisme. Le service Delivery Optimization ne peut être utilisé ni détourné pour distribuer du contenu arbitraire ou personnel, ce qui circonscrit son usage à des données de confiance publiées par Microsoft (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn). Ensuite, lorsque qu’un client veut télécharger un package (par exemple un correctif cumulatif Windows), il commence par obtenir auprès de Microsoft un fichier de métadonnées contenant les empreintes cryptographiques de chaque bloc du fichier cible (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn). Ce fichier de métadonnées (souvent appelé « manifeste » ou « hash file ») liste, typiquement par segments de 1 Mo, les hashes SHA-256 de chaque segment du package. Le client télécharge ce manifeste en toute sécurité (via SSL/TLS depuis les serveurs Microsoft) et en vérifie lui-même l’authenticité au moyen d’un hash ou d’une signature que Microsoft fournit séparément sur un canal sécurisé (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn). En d’autres termes, avant même de télécharger le moindre octet du contenu, le client possède une « carte d’identité » cryptographique complète de ce contenu, validée par Microsoft.
Une fois le manifeste validé, le client peut accepter des données de différentes sources (pairs, cache ou serveur). À chaque bloc (segment) reçu depuis un peer, le service WUDO sur le client calcule le hash SHA-256 de ce bloc et le compare avec le hash attendu (d’après le manifeste). Si les valeurs ne correspondent pas, le bloc est immédiatement rejeté (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn). Ce contrôle systématique garantit qu’un pair malveillant ou corrompu ne peut pas injecter de données falsifiées : toute altération serait détectée via le mismatch de hash. Après quelques tentatives infructueuses (si un pair envoie plusieurs blocs erronés), le client bannit ce pair – il ne lui demandera plus rien d’autre pour le reste du téléchargement (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn). Ainsi, même si par hypothèse un poste du réseau local était compromis et essayait d’empoisonner le flux WUDO, il ne pourrait pas tromper les autres clients quant à l’authenticité des données.
Enfin, en bout de chaîne, une fois que le client WUDO a assemblé tous les blocs et reconstitué le fichier complet, le processus standard de Windows Update ou d’installation s’exécute. Ce dernier vérifie la signature numérique globale du package ou du programme d’installation comme le ferait un téléchargement classique. Les fichiers de mise à jour Windows sont signés par Microsoft, et cette signature doit être valide pour que la mise à jour s’installe. Cette vérification finale agit comme une couche supplémentaire de sécurité : si par impossible un fichier complet avait échappé aux contrôles de blocs, il serait tout de même rejeté par Windows Update s’il n’est pas signé correctement par l’éditeur (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn) (Delivery Optimization workflow, privacy, security, and endpoints | Microsoft Learn). Grâce à l’ensemble de ces mécanismes, Microsoft assure que WUDO ne compromet pas l’intégrité des mises à jour : un bloc téléchargé en P2P est traité avec le même niveau de confiance que s’il provenait directement de Windows Update, car il est vérifié bit-à-bit.
Sécurité du transfert des mises à jour
Outre l’intégrité des données, se pose la question de la confidentialité et de la sécurité des transferts eux-mêmes. WUDO n’achemine pas des données personnelles, mais il transporte tout de même des fichiers de mise à jour qui pourraient, en théorie, être interceptés sur le réseau local. Microsoft a fait le choix d’un équilibrage entre performance et confidentialité : les échanges entre pairs sur le LAN utilisent un protocole sur TCP port 7680 qui n’est pas chiffré de bout en bout, mais dont le contenu est uniquement constitué de fragments de mises à jour chiffrés/signés ou publics. Autrement dit, les blocs transférés sont essentiellement des morceaux de fichiers .cab ou .psf de Windows Update, qui ne contiennent pas d’information sensible de l’utilisateur. Le fait de ne pas les chiffrer en TLS permet de réduire l’overhead et de faciliter la mise en cache/inspection si nécessaire, sans exposer de données privées.
En revanche, toutes les communications avec les services cloud de Microsoft se font en HTTPS (TLS) sur le port 443 (Delivery Optimization Frequently Asked Questions | Microsoft Learn). Cela inclut le téléchargement des métadonnées de contenu (manifeste de hashes) et les échanges avec le service de coordination (Discovery service). Ainsi, un attaquant ne peut pas usurper les réponses du service DO sans posséder les certificats de Microsoft. De plus, comme évoqué, même en interceptant un bloc de données P2P, celui-ci serait inutilisable pour l’attaquant et impossible à altérer sans être détecté.
Pour la sécurité réseau, un point important est que le port TCP 7680 doit être ouvert en entrée sur les postes si l’on souhaite permettre le P2P local (Delivery Optimization Frequently Asked Questions | Microsoft Learn). Ce port est enregistré et ouvert par le service Delivery Optimization sur chaque client lorsque WUDO est activé. En environnement d’entreprise, on veillera donc à autoriser le trafic TCP 7680 entrant/sortant sur le profil de domaine/privé du pare-feu Windows des postes. Ce port n’étant utilisé qu’au sein du LAN (pour du P2P local ou inter-sites), on peut le bloquer sur le profil public ou sur les périmètres non approuvés. Pour les scénarios de partage au-delà d’un même NAT (mode Groupe avec sites distants), WUDO utilise en interne le protocole Teredo sur UDP 3544 pour établir des connexions P2P à travers les NAT (Delivery Optimization Frequently Asked Questions | Microsoft Learn). Là encore, l’entreprise doit autoriser ce trafic si elle souhaite tirer parti du P2P inter-sites ; sinon, les pairs distants ne pourront pas communiquer directement. Notons que l’utilisation de Teredo peut être désactivée si on le souhaite en évitant le mode Groupe ou Internet, ou en configurant une restriction.
En résumé, le transfert des mises à jour via WUDO est sécurisé par conception : les contenus sont identifiés de manière unique et vérifiés, et les canaux de commande (métadonnées, coordination) sont chiffrés. Le trafic P2P local, lui, n’est pas chiffré afin de maximiser les performances, mais il n’achemine pas de données sensibles. L’administrateur devra simplement veiller à configurer convenablement les pare-feu pour autoriser les ports requis au sein du réseau de confiance, et empêcher ce trafic sur les réseaux non maîtrisés (réseau public, etc.).
Contrôle d’accès et configuration sécurisée
Dans un contexte entreprise, on peut vouloir restreindre l’usage de WUDO à certaines conditions afin de garder le contrôle sur où et quand les machines se partagent des données. Bien que WUDO n’expose pas de données utilisateur, on pourrait considérer qu’un poste ne devrait pas forcément envoyer des données à n’importe quel autre poste sans contrôle. Microsoft a prévu quelques garde-fous et options de configuration pour s’assurer que WUDO opère uniquement dans le périmètre prévu.
D’abord, le périmètre de peering doit être choisi judicieusement via le paramètre de Download Mode. Par défaut (mode LAN), un PC ne partagera qu’avec des machines ayant la même IP publique – ce qui, en pratique, signifie les machines du même site ou succursale derrière le même routeur. Si l’entreprise est raccordée à Internet sur plusieurs sites avec des IP publiques distinctes, WUDO cloisonne naturellement le partage par site. En mode Groupe, l’administrateur peut définir un ID de groupe personnalisé pour circonscrire ou étendre le périmètre exactement aux machines souhaitées (par ex. un groupe pour chaque bureau régional, ou au contraire un grand groupe englobant plusieurs domaines AD si le réseau interne est bien interconnecté) (Delivery Optimization reference | Microsoft Learn) (Delivery Optimization reference | Microsoft Learn). Éviter le mode Internet (3) est généralement conseillé en entreprise : ainsi, aucun partage ne se fera avec des appareils extérieurs non contrôlés. En procédant de la sorte, on s’assure que les échanges WUDO restent à l’intérieur du réseau d’entreprise ou du VPN.
Ensuite, WUDO peut être configuré pour respecter certains contextes réseau. Par exemple, Windows est capable de détecter les connexions VPN et l’administrateur peut décider de désactiver WUDO en VPN pour éviter qu’un client nomade ne télécharge depuis des pairs du LAN à travers le tunnel (ce qui consommerait de la bande passante VPN). Windows 11 introduit un réglage Disallow Downloads from Connected Cache over VPN qui, appliqué, empêche le client d’utiliser un cache local via le VPN (What’s new in Delivery Optimization | Microsoft Learn). De même, il est possible d’utiliser des mots-clés personnalisés pour que WUDO reconnaisse les noms de connexion VPN de l’entreprise (What’s new in Delivery Optimization | Microsoft Learn). On peut ainsi moduler le comportement : par exemple autoriser le P2P sur le LAN de bureau, mais pas lorsqu’un poste est en wifi invité ou en télétravail sur VPN.
Le contrôle d’accès aux données WUDO elles-mêmes (c’est-à-dire qui peut télécharger quoi) est en fait hérité du contrôle d’accès standard des mises à jour Windows. En effet, pour qu’un client télécharge un certain contenu via WUDO, il faut qu’il ait obtenu l’autorisation de Windows Update ou d’Intune pour ce contenu (par exemple, Windows Update détermine que telle mise à jour est applicable au client, Intune pousse telle application Win32 à telle machine, etc.). WUDO ne change pas ces logiques : un poste ne va pas télécharger une mise à jour qui ne lui est pas destinée. Ainsi, d’une certaine manière, l’accès est contrôlé par la ciblage des déploiements existant (groupes de mise à jour, déploiements Intune, etc.). WUDO intervient uniquement sur l’aspect transport une fois la décision de déployer un contenu prise.
Pour une configuration sécurisée, on recommande donc de : utiliser un mode de WUDO adapté (LAN ou Groupe, mais évitant le partage avec Internet), bien configurer les limites du groupe (GroupID si besoin), activer la découverte locale DNS-SD seulement sur des réseaux de confiance (le cas échéant), et intégrer WUDO dans les stratégies de sécurité réseau (pare-feu interne autorisant 7680/TCP entre postes de confiance uniquement, éventuellement contraintes supplémentaires via IPS si nécessaire). Il est également conseillé de surveiller le fonctionnement de WUDO (voir l’article sur le monitoring) pour détecter tout comportement anormal, même si par construction les risques sont faibles grâce aux validations de contenu. En appliquant ces bonnes pratiques, WUDO peut être déployé de manière sûre, en s’assurant qu’il apporte ses bénéfices sans ouvrir la porte à des échanges non maîtrisés.