/
/

Comment bloquer les logiciels non approuvés sur les terminaux Windows sans dépendance à un fournisseur

par Team Ninja
How to Block Unapproved Software on Windows Endpoints Without Vendor Lock-In blog banner image

Points clés

  • Utilisez WDAC, AppLocker ou les SRP pour bloquer les applications non autorisées sur les terminaux Windows 10 et 11 : vous empêchez toute exécution non approuvée et protégez les données sensibles sans dépendance à un fournisseur.
  • Créez des listes d’autorisation basées sur l’éditeur, bloquez les chemins accessibles en écriture par l’utilisateur et commencez en mode audit avant d’appliquer les politiques, pour garantir sécurité et stabilité.
  • Appuyez-vous sur le Pare-feu Windows et l’automatisation NinjaOne pour surveiller l’application des règles, bloquer les applications à risque et gérer les exceptions dans une logique de conformité continue.

La présence de logiciels non approuvés sur les appareils de l’entreprise, sans validation préalable, est un problème sérieux. L’idée est inquiétante : des informations confidentielles pourraient fuiter ou des données sensibles être volées. Cet article vous montre comment bloquer les applications indésirables et mettre en place un contrôle des exécutables avec les options natives de Windows.

Bloquer les logiciels non approuvés sur les terminaux Windows

Pour bloquer les logiciels non approuvés sur les terminaux Windows sans dépendance à un fournisseur, vous devez choisir un plan de contrôle natif de Windows, concevoir un jeu de règles, échelonner le déploiement, appliquer les règles via GPO, ajouter un pare-feu local, surveiller, puis gérer les exceptions.

📌 Prérequis :

  • Des éditions et licences Windows compatibles avec le plan de contrôle retenu.
  • Des droits d’administration et un accès à la stratégie de groupe ou à un MDM pour déployer les politiques.
  • Une collecte centralisée des journaux des terminaux, pour l’application des règles et les preuves d’audit.
  • Une courte liste des applications critiques pour l’activité, afin d’amorcer la liste d’autorisation initiale.

Étape 1 : choisir un plan de contrôle natif de Windows

La première étape consiste à sélectionner l’outil natif de Windows adapté pour contrôler l’exécution des applications, en trouvant le bon équilibre entre niveau de sécurité et compatibilité.

📌 Cas d’utilisation : un administrateur doit empêcher l’exécution d’applications non approuvées sur des appareils Windows 10 et 11 à l’aide de fonctionnalités intégrées, avec un déploiement simple des politiques via la stratégie de groupe ou un MDM.

Windows Defender Application Control (WDAC)

WDAC applique le contrôle au niveau du noyau et garantit que seul du code signé et approuvé s’exécute. Utilisez-le dans les environnements à haut niveau d’exigence ou les grandes entreprises qui ont besoin des garanties d’intégrité les plus fortes. Partez de la politique de base de Microsoft et ajoutez des règles d’éditeur pour les logiciels approuvés.

AppLocker

AppLocker propose des contrôles en mode utilisateur : il autorise ou refuse des exécutables selon l’éditeur, le chemin d’accès ou le hachage. C’est l’option la plus pertinente pour des déploiements souples sur les éditions Pro et Entreprise.

Stratégies de restriction logicielle (SRP)

Enfin, les SRP constituent un cadre ancien de restriction des exécutables. Elles conviennent surtout aux environnements plus anciens ou non professionnels, dépourvus de WDAC ou d’AppLocker.

Étape 2 : concevoir un jeu de règles à fort impact

Un jeu de règles ciblé bloque d’abord les comportements les plus risqués, puis pose des bases claires pour élargir l’application des règles par la suite.

📌 Cas d’utilisation : un administrateur souhaite empêcher l’exécution d’exécutables à risque tout en laissant les mises à jour et les applications approuvées fonctionner normalement.

Commencez par les listes d’autorisation par éditeur. Utilisez les certificats d’éditeurs de fournisseurs de confiance, comme Microsoft et Adobe, plutôt que des hachages de fichiers individuels : la maintenance sera bien plus légère. Bloquez ensuite les chemins accessibles en écriture par l’utilisateur en empêchant l’exécution depuis des dossiers tels que Downloads, AppData ou Temp, qui sont des points de lancement courants pour les malwares et les outils non autorisés.

Une fois les chemins traités, ajoutez des blocages ciblés par hachage : utilisez les hachages de fichiers pour bloquer les binaires malveillants connus ou les outils en zone grise, comme les logiciels d’accès à distance non autorisés. Enfin, ne vous limitez pas aux fichiers .exe : incluez les .msi, les scripts et les .dll pour fermer les contournements couramment exploités par les attaquants.

Étape 3 : échelonner le déploiement avec des garde-fous

Un déploiement progressif évite les interruptions d’activité et assure une transition en douceur des tests à une protection complète.

📌 Cas d’utilisation : un administrateur veut déployer AppLocker dans plusieurs services sans perturber les opérations. Il lui faut une méthode à faible risque pour tester, ajuster et démontrer la stabilité avant l’implémentation complète.

Pour échelonner le déploiement avec des garde-fous, suivez les étapes ci-dessous :

  • Commencez en mode audit seul : enregistrez les blocages potentiels sans les appliquer. Consultez les journaux AppLocker pour repérer les applications qui seraient bloquées en mode application.
  • Testez sur un petit groupe pilote : composez-le d’utilisateurs avancés et de terminaux représentatifs, puis recueillez les retours, affinez les règles d’accès et documentez les exceptions.
  • Définissez un plan de retour arrière et de support : documentez la procédure d’annulation des politiques et formez les équipes du service d’assistance à identifier et résoudre les incidents.
  • Passez en mode application : une fois les exceptions approuvées et validées, activez l’application par phases contrôlées. Surveillez de près les premiers jours pour repérer les éventuelles lacunes.

Étape 4 : appliquer les règles via la stratégie de groupe

Un déploiement centralisé garantit une protection homogène, un audit simplifié et une restauration plus rapide lorsque les politiques doivent être annulées ou mises à jour.

📌 Cas d’utilisation : une équipe informatique souhaite un contrôle des exécutables homogène sur les appareils Windows sur site et distants, en s’appuyant sur la stratégie de groupe existante pour les systèmes internes et sur un MDM pour les utilisateurs mobiles ou hybrides.

Modélisez d’abord les politiques en laboratoire. Testez l’application, la journalisation et le comportement de retour arrière avant le déploiement, afin de vérifier que les mises à jour, les programmes d’installation et les workflows critiques fonctionnent comme prévu. Vous pouvez ensuite déployer les politiques via GPO. Liez-les aux unités d’organisation ou aux groupes de sécurité visés. Gardez les fichiers de règles versionnés et documentés, et n’activez le mode application qu’une fois la phase pilote terminée.

Pour les parcs distribués, diffusez les politiques avec Microsoft Intune. Automatisez le rafraîchissement des politiques et le suivi des versions pour garantir cohérence et fiabilité. Enfin, assurez la gestion des versions et la traçabilité en stockant les fichiers XML ou CI dans un gestionnaire de versions, afin de suivre les modifications et de conserver un historique de retour arrière. Indiquez l’auteur, la date et l’objectif de chaque révision.

Étape 5 : ajouter un confinement par pare-feu local

Le confinement par pare-feu renforce la défense en limitant les dégâts causés par les applications qui échappent au contrôle des exécutables.

📌 Cas d’utilisation : un administrateur veut confiner des applications potentiellement risquées ou en zone grise sans les supprimer immédiatement des terminaux.

Pour mettre en place ce confinement, veillez à :

Créer des règles de pare-feu propres à chaque programme

Utilisez le Pare-feu Windows Defender avec fonctions avancées de sécurité pour définir des règles entrantes et sortantes associées à des exécutables précis. Concentrez-vous sur les applications à haut risque qui n’ont pas besoin d’accès externe, comme les clients de partage de fichiers ou les utilitaires anciens.

Limiter les connexions sortantes

Restreignez ou bloquez le trafic sortant des applications suspectes. Appuyez-vous sur des restrictions par domaine ou par adresse IP pour empêcher les tentatives de commande et contrôle ou d’exfiltration de données.

Confiner pendant les investigations

Appliquez des blocages temporaires au niveau du pare-feu pour isoler un système ou une application suspecte le temps d’évaluer l’impact.

Intégrer à la gestion centralisée

Enfin, distribuez les politiques de pare-feu via GPO pour une application renforcée. Centralisez la collecte des journaux du pare-feu afin de détecter les tentatives de connexion répétées des programmes bloqués.

Étape 6 : surveiller, alerter et démontrer l’application des règles

Une surveillance active et des rapports de preuve transforment les politiques en contrôles mesurables.

📌 Cas d’utilisation : un administrateur veut vérifier que les règles AppLocker et de pare-feu fonctionnent sur l’ensemble des terminaux et pouvoir démontrer la conformité lors d’audits ou de revues trimestrielles.

Pour surveiller, alerter et démontrer l’application des règles, veillez à :

  • Collecter les journaux d’application : récupérez les événements AppLocker et les journaux d’intégrité du code (Code Integrity) de WDAC sur les terminaux. Ajoutez les journaux du Pare-feu Windows pour repérer le trafic inhabituel, avant de centraliser le tout dans votre Windows Event Forwarding pour analyse.
  • Configurer des alertes sur les signaux clés : signalez les tentatives d’exécution répétées depuis des chemins accessibles en écriture par l’utilisateur ou depuis des outils non approuvés. Alertez en cas d’altération des politiques ou de tentative de désactivation du service, et traitez en priorité les refus récurrents associés au même chemin, au même utilisateur ou au même éditeur.
  • Produire des rapports de preuve réguliers : résumez les événements refusés, les exceptions actives et les modifications apportées aux listes d’autorisation. Corrélez les journaux pour démontrer l’application des règles et identifier les tendances.
  • Alimenter l’ajustement des politiques : exploitez les données collectées pour affiner les listes d’autorisation et supprimer les exceptions inutiles. Documentez l’efficacité des politiques et joignez les rapports aux rapports trimestriels d’activité (QBR) ou aux dossiers de conformité.

Étape 7 : gérer les exceptions

📌 Cas d’utilisation : un administrateur doit approuver certains outils pour des développeurs et des fournisseurs tiers, tout en évitant que ces exceptions ne deviennent des angles morts permanents.

Une bonne gouvernance des exceptions commence par un responsable et une justification. Chaque exception doit avoir un propriétaire, un motif clair et une trace d’approbation correspondante.

De plus, conservez les détails dans un journal central ou un système de gestion des tickets pour garantir la visibilité en audit. Définissez également des dates d’expiration et des cycles de revue. Par défaut, toutes les exceptions doivent expirer automatiquement sauf renouvellement ; planifiez ensuite des revues pour confirmer que le besoin persiste.

Automatisez le suivi et les notifications à l’aide de scripts ou d’outils de gestion afin de signaler les expirations à venir. Invitez les propriétaires à renouveler, justifier ou supprimer leurs exceptions. Cette démarche préserve l’intégrité du contrôle, limite la dérive du risque et fournit une piste d’audit solide.

Bonnes pratiques pour bloquer les logiciels non approuvés sur les terminaux

Le tableau suivant résume les bonnes pratiques à suivre pour bloquer les logiciels non approuvés sur les terminaux Windows :

Pratique

Objectif

Bénéfice apporté

Listes d’autorisation par éditeur en priorité Réduire les modifications de règles Moins de ruptures et de mises à jour
Blocage des chemins accessibles en écriture par l’utilisateur Stopper les abus les plus courants Moins d’exécutions de malwares et de droppers
Déploiement progressif avec audit d’abord Déploiement sans risque Détecte les lacunes avant l’application
Confinement par pare-feu Limiter l’impact Coupe les canaux C2 et d’exfiltration de données
Preuves et revues Responsabilisation Piste d’audit claire et rapports prêts pour les QBR

Les services NinjaOne qui aident à bloquer les logiciels non approuvés

Avec NinjaOne, vous pouvez déployer des scripts appuyés sur des GPO ou configurer des charges utiles, collecter les journaux d’application des règles et déclencher des alertes en cas d’exécution refusée. Vous pouvez aussi automatiser la génération de dossiers de preuves et joindre les rapports aux revues mensuelles ou aux QBR pour simplifier le suivi de la conformité.

Protégez les données sensibles en bloquant les logiciels non approuvés

Bloquer les applications ou logiciels indésirables donne les meilleurs résultats avec un plan de contrôle natif, un déploiement progressif sécurisé et une gestion rigoureuse des exceptions. En ajoutant un confinement par pare-feu local pour la profondeur de défense et en conservant journaux et rapports, vous rendez l’application des règles visible, auditable et défendable.

Sujets connexes :

FAQs

Non, les règles de pare-feu n’empêchent pas un programme de s’exécuter : elles bloquent ses communications réseau. Utilisez WDAC, AppLocker ou les SRP pour empêcher l’exécution.

Choisissez WDAC pour un niveau d’intégrité renforcé sur les éditions compatibles, et AppLocker pour des politiques d’autorisation et de refus flexibles dans les environnements hétérogènes.

Pour éviter de casser les applications métier, commencez en mode audit seul, examinez les refus, ajoutez des exceptions ciblées avec une date d’expiration, puis passez en mode application.

Les outils à haut risque, les logiciels d’accès à distance non autorisés ou les fichiers malveillants connus qui ne sont pas couverts par les règles d’éditeur ou de chemin d’accès.

Envoyez les journaux CodeIntegrity, AppLocker et pare-feu vers votre SIEM, résumez les événements refusés et suivez les exceptions avec leurs propriétaires et leurs dates d’expiration.

You might also like

Prêt à simplifier les aspects les plus complexes de l'informatique et de la sécurité ?

Termes et conditions NinjaOne

En cliquant sur le bouton « J’accepte » ci-dessous, vous indiquez que vous acceptez les termes juridiques suivants ainsi que nos conditions d’utilisation:

  • Droits de propriété: NinjaOne possède et continuera de posséder tous les droits, titres et intérêts relatifs au script (y compris les droits d’auteur). NinjaOne vous accorde une licence limitée pour l’utilisation du script conformément à ces conditions légales.
  • Limitation de l’utilisation: Les scripts ne peuvent être utilisés qu’à des fins personnelles ou professionnelles internes légitimes et ne peuvent être partagés avec d’autres entités.
  • Interdiction de publication: Vous n’êtes en aucun cas autorisé à publier le script dans une bibliothèque de scripts appartenant à, ou sous le contrôle d’un autre fournisseur de logiciels.
  • Clause de non-responsabilité: Le texte est fourni « tel quel » et « tel que disponible », sans garantie d’aucune sorte. NinjaOne ne promet ni ne garantit que le script sera exempt de défauts ou qu’il répondra à vos besoins ou attentes particulières.
  • Acceptation des risques: L’utilisation du script est sous votre propre responsabilité. Vous reconnaissez qu’il existe certains risques inhérents à l’utilisation du script, et vous comprenez et assumez chacun de ces risques.
  • Renonciation et exonération de responsabilité: Vous ne tiendrez pas NinjaOne pour responsable des conséquences négatives ou involontaires résultant de votre utilisation du script, et vous renoncez à tout droit ou recours légal ou équitable que vous pourriez avoir contre NinjaOne en rapport avec votre utilisation du script.
  • EULA: Si vous êtes un client de NinjaOne, votre utilisation du script est soumise au contrat de licence d’utilisateur final qui vous est applicable (End User License Agreement (EULA)).