Share via

Sécurité Windows Update

Le système Windows Update (WU) garantit la mise à jour sécurisée des appareils. Sa protection de bout en bout empêche la manipulation des échanges de protocole et garantit que seul le contenu approuvé est installé. Certains environnements protégés peuvent avoir besoin de mettre à jour les règles de pare-feu et de proxy pour s’assurer que les mises à jour Windows sont correctement accessibles. Cet article fournit une vue d’ensemble des fonctionnalités de sécurité de Windows Update.

Vue d’ensemble de la sécurité Windows Update

Le système Windows Update distribue une multitude de contenu. Voici quelques exemples de ce contenu :

  • Mises à jour au système d’exploitation Windows
  • mises à jour Microsoft 365 Apps (mises à jour Office)
  • Pilotes matériels
  • Définitions d’antivirus
  • Applications du Microsoft Store

Ce système est lancé lorsqu’un utilisateur interagit avec la page de paramètres Windows Update ou lorsqu’une application effectue un appel dans l’API du service client WU. Ces appels peuvent être effectués à différents moments par des applications Microsoft et différentes parties de Windows, telles que Microsoft 365 Apps, Microsoft Defender et Plug-and-Play (PnP).

Lorsque de telles interactions se produisent, le service Windows Update exécuté sur l’appareil déclenche une série d’échanges sur Internet avec les serveurs Windows Update de Microsoft. Le flux de travail général est le suivant :

  1. Un appareil Windows établit plusieurs connexions aux services Windows Update à l’aide de HTTPS (HTTP sur TLS, port TCP 443).
  2. Les métadonnées de mise à jour sont échangées via ces connexions et aboutit à une liste de mises à jour, d’applications, de pilotes et d’autres mises à jour.
  3. L’appareil décide si et quand télécharger les éléments de la liste résultante.

Une fois la liste des téléchargements décidée, les fichiers binaires de mise à jour réels sont téléchargés. Le téléchargement s’effectue via le composant Optimisation de la distribution sur un mélange d’appels HTTP standard (port TCP 80) et d’appels réseau d’égal à égal sécurisés (port TCP 7680). La méthode utilisée est basée sur les stratégies de configuration/de groupe de l’appareil.

Lors du téléchargement des mises à jour à l’aide de la mise en réseau P2P (Peer-to-Peer) de l’optimisation de la distribution, l’intégrité du contenu est validée dès réception de chaque homologue. Si le contenu demandé n’est pas disponible sur le réseau P2P, le composant Optimisation de la distribution le télécharge à l’aide de HTTP.

Quelle que soit la méthode utilisée pour télécharger le contenu, les fichiers résultants sont ensuite validés par le biais de signatures numériques et de hachages de fichiers avant d’être installés. La validation confirme que le téléchargement est ce qui était prévu, qu’il est vérifié comme authentique et qu’il n’a pas été falsifié.

Sécurisation des connexions de métadonnées

Lorsque Windows Update recherche des mises à jour, il passe par une série d’échanges de métadonnées entre l’appareil et les serveurs Windows Update. Cet échange est effectué à l’aide de HTTPS (HTTP sur TLS). Ces connexions sécurisées sont épinglées par certificat, ce qui garantit que :

  • Le certificat de serveur de la connexion TLS est validé (approbation de certificat, expiration, révocation, entrées SAN, etc.)
  • L’émetteur du certificat est validé en tant qu’authentique Microsoft Windows Update

La connexion échoue si l’émetteur est inattendu ou s’il n’est pas un certificat intermédiaire Windows Update valide. L’épinglage de certificat garantit que l’appareil se connecte aux serveurs Microsoft légitimes et empêche les attaques de l’intercepteur.

Étant donné que Windows Update connexions TLS sont épinglées par certificat, il est important que les proxys TLS passent ces connexions sans interception. Vous trouverez la liste complète des noms DNS qui nécessitent des exceptions de proxy/pare-feu dans l’article résolution des problèmes Windows Update.

Microsoft ne fournit pas d’adresses IP ou de plages d’adresses IP pour ces exceptions, car elles peuvent différer au fil du temps à mesure que des modifications sont apportées à des fins telles que l’équilibrage de charge du trafic.

Utilisation attendue du serveur Windows Update

Les serveurs du service Windows Update sont utilisés uniquement par les composants WU. Il n’est pas prévu que les utilisateurs finaux interagissent avec ces points de terminaison distants. Par conséquent, ces points de terminaison de service peuvent ne pas être résolus comme prévu dans un navigateur web. Un utilisateur accédant à ces points de terminaison peut remarquer un manque d’adhésion aux dernières attentes du navigateur web, telles que l’infrastructure À clé publique approuvée, la journalisation de la transparence des certificats ou les exigences TLS. Ce comportement est attendu et ne limite pas ou n’affecte pas la sécurité et la sûreté du système Windows Update.

Les utilisateurs qui tentent d’accéder aux points de terminaison de service peuvent voir des avertissements de sécurité et même des échecs d’accès au contenu. Là encore, ce comportement est attendu, car les points de terminaison de service ne sont pas conçus pour l’accès au navigateur web ou la consommation occasionnelle des utilisateurs.

Sécurisation de la distribution de contenu

Le processus de téléchargement des fichiers binaires de mise à jour est sécurisé au niveau d’une couche au-dessus du transport. Même si le contenu peut être téléchargé via le protocole HTTP standard (port TCP 80), le contenu passe par un processus rigoureux de validation de sécurité.

La charge des téléchargements étant équilibrée via les réseaux de distribution de contenu (CDN), l’utilisation de TLS rompt leur chaîne de garde Microsoft. Étant donné qu’une connexion TLS à un CDN de mise en cache se termine au niveau du CDN, et non de Microsoft, les certificats TLS ne sont pas spécifiques à Microsoft. Cela signifie que le client WU ne peut pas prouver la fiabilité du CDN, car Microsoft ne contrôle pas les certificats TLS CDN. En outre, une connexion TLS à un CDN ne prouve pas que le contenu n’a pas été manipulé dans le réseau de mise en cache du CDN. Par conséquent, TLS n’offre aucune des promesses de sécurité au flux de travail Windows Update de bout en bout qu’il fournit autrement.

Quelle que soit la façon dont le contenu est remis, une fois qu’il a été téléchargé, il est correctement validé. Le contenu est validé pour la confiance, l’intégrité et l’intention à l’aide de diverses techniques telles que la validation de signature numérique et les vérifications de hachage de fichier. Ce niveau de validation du contenu offre encore plus de couches de sécurité que TLS seul.

Windows Server Update Services (WSUS)

Les entreprises qui utilisent WSUS ont un workflow similaire. Toutefois, les appareils clients se connectent au serveur WSUS de leur entreprise au lieu d’Internet aux serveurs de Microsoft. C’est à l’entreprise de décider s’il faut utiliser des connexions HTTP ou TLS (HTTPS) pour l’échange de métadonnées. Microsoft recommande vivement d’utiliser des connexions TLS et de configurer des appareils clients avec des configurations d’épinglage de certificat TLS appropriées pour l’échange de métadonnées avec WSUS. Pour plus d’informations sur l’épinglage de certificat TLS WSUS, consultez :

Lorsqu’un serveur WSUS met à jour son propre catalogue de mises à jour, il se connecte aux services de synchronisation de serveur de Microsoft et recherche les mises à jour. Le processus de synchronisation du serveur WSUS est similaire au processus d’échange de métadonnées pour les appareils clients qui se connectent à Windows Update. La connexion WSUS-à-Microsoft se fait via TLS et est vérifiée par un certificat Microsoft, similaire à l’épinglage de certificat TLS du client WU.