Silverlight a officiellement atteint sa fin de support le 12 octobre 2021. Plus de quatre ans après, nous observons encore des applications métier qui dépendent de ce runtime pour afficher des interfaces critiques : formulaires de saisie, écrans de reporting, modules de gestion documentaire. Le problème n’est pas la nostalgie, c’est que des données métier restent prisonnières d’un composant sans correctifs de sécurité.
Verrou d’accès Silverlight : quand vos données dépendent d’un runtime obsolète
Le risque le plus sous-estimé ne concerne pas les failles réseau ou les malwares. Il concerne la disponibilité des données elles-mêmes. Plusieurs retours d’expérience récents montrent des entreprises incapables de relire des historiques de dossiers, des formulaires ou des exports de reporting parce que le seul frontal disponible est un écran Silverlight non migré.
Lire également : Stockage fiable : Quel support choisir pour garantir la sécurité de vos données ?
La base de données sous-jacente peut être parfaitement intacte. Si l’interface utilisateur Silverlight est le seul chemin d’accès, la donnée devient illisible dès que le runtime ne fonctionne plus. Ce n’est pas un problème de stockage, c’est un problème d’accès logique aux données.
Nous recommandons de cartographier chaque application Silverlight encore en production et de vérifier si un accès alternatif aux données existe (API, export SQL direct, interface web de remplacement). Sans cette vérification, vous découvrirez le verrou d’accès le jour où vous en aurez besoin, pas avant.
A lire aussi : Webmail 72 : les bons réflexes pour protéger vos données professionnelles
Mode Internet Explorer dans Edge : une béquille Silverlight à durée limitée
Beaucoup d’équipes IT ont contourné la fin de support en activant le mode Internet Explorer intégré à Microsoft Edge. Ce mode permet de charger des contrôles ActiveX et des plugins Silverlight dans un onglet Edge, sans maintenir un navigateur IE séparé.
Cette solution de contournement a une date d’expiration. Le mode IE d’Edge figure dans la liste des fonctionnalités Microsoft vouées à disparaître d’ici 2029. La suppression de ce mode coupera définitivement le dernier canal d’exécution Silverlight sur un poste Windows standard.
Ce que la disparition du mode IE implique concrètement
- Les applications Silverlight accessibles aujourd’hui via Edge en mode IE deviendront inaccessibles sans infrastructure dédiée (machine virtuelle, navigateur tiers non maintenu).
- Les données affichées uniquement par ces interfaces n’auront plus de chemin de consultation natif sur un poste Windows à jour.
- Toute stratégie de migration repoussée au-delà de cette échéance imposera des coûts d’isolation réseau et de virtualisation nettement plus élevés.
Attendre la suppression effective du mode IE pour lancer une migration revient à planifier un projet sous contrainte de temps maximale, avec des options techniques réduites.
Conformité RGPD et logiciel en fin de vie : ce que la CNIL attend
La CNIL recommande explicitement de choisir des formats et des composants « sécurisés et reconnus par la communauté » pour garantir la durée de conservation prévue des données personnelles. Un runtime dont l’éditeur ne publie plus aucun correctif de sécurité ne remplit pas ce critère.
L’enjeu dépasse la simple question technique. Utiliser un logiciel sans support pour traiter des données personnelles fragilise la conformité RGPD de l’ensemble du traitement, pas seulement du composant concerné. En cas de contrôle ou d’incident, l’absence de mises à jour de sécurité sur un composant exposé au réseau constitue un manquement à l’obligation de sécurité (article 32 du RGPD).
Postes exposés et périmètre de risque réglementaire
Le risque ne se limite pas au serveur hébergeant l’application. Chaque poste utilisateur exécutant le plugin Silverlight devient un point d’entrée potentiel. Sans correctifs, une vulnérabilité exploitable sur le plugin peut compromettre le poste, puis le réseau local, puis les bases de données auxquelles ce poste accède.
Nous observons que les audits de conformité récents s’attardent de plus en plus sur l’inventaire des composants logiciels obsolètes. Un registre des traitements qui mentionne une application Silverlight en production sans plan de migration documenté attire l’attention des auditeurs.
Migration des applications Silverlight : prioriser par criticité des données
Toutes les applications Silverlight ne présentent pas le même niveau de risque. Une interface de consultation d’archives internes sans données personnelles ne justifie pas le même investissement qu’un portail de gestion de dossiers clients avec historique nominatif.
La priorisation repose sur trois critères concrets :
- Le type de données exposées par l’interface (données personnelles, données financières, données opérationnelles sans caractère sensible).
- L’existence ou non d’un accès alternatif aux données sous-jacentes (API REST, connecteur SQL, export CSV automatisé).
- Le nombre d’utilisateurs actifs et la fréquence d’accès, qui déterminent la surface d’exposition réelle du plugin sur le réseau.
Pour les applications à forte criticité, la réécriture du frontal en technologie web standard (HTML5, frameworks JavaScript modernes) reste la voie la plus pérenne. Pour les applications à faible criticité, un export complet des données vers un format ouvert, suivi d’une mise hors service du composant Silverlight, suffit souvent.
Extraction des données avant mise hors service
Avant de couper une application Silverlight, nous recommandons de valider que l’intégralité des données accessibles via l’interface a été extraite et vérifiée. Les écrans Silverlight affichent parfois des champs calculés, des agrégats ou des métadonnées qui n’existent pas tels quels dans la base de données. Une extraction brute de la base peut omettre ces informations dérivées.
Un test de réconciliation entre les données extraites et les données affichées par l’interface Silverlight, écran par écran sur un échantillon représentatif, permet d’identifier les écarts avant qu’il ne soit trop tard.
Surface d’attaque d’un plugin Silverlight sans correctifs de sécurité
Un plugin navigateur qui ne reçoit plus de correctifs depuis plusieurs années constitue une cible documentée. Les vulnérabilités connues restent exploitables indéfiniment puisque aucun patch ne viendra les corriger. Les bases de vulnérabilités publiques référencent ces failles, ce qui les rend accessibles à tout attaquant disposant d’un scanner automatisé.
Chaque poste exécutant Silverlight élargit la surface d’attaque du système d’information. L’isolation du plugin dans une machine virtuelle dédiée, déconnectée du réseau de production, réduit ce risque mais ne l’élimine pas si la VM accède aux mêmes bases de données.
La suppression pure et simple du plugin de tous les postes, combinée à la migration ou à l’extraction des données, reste la seule mesure qui referme définitivement cette surface d’exposition. Reporter cette décision revient à maintenir une porte ouverte dont la serrure ne sera jamais changée.
