Bloquer le stockage USB sans casser claviers et souris

février 20, 2026 • février 20, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Si vous avez déjà déployé une politique « désactiver l’USB » et vu la file d’incidents explose, vous connaissez déjà la vérité :
les postes sont hétérogènes, les utilisateurs sont créatifs, et l’USB est le cafard des interfaces. On ne peut pas simplement « l’éteindre »
sans heurter des claviers, des souris, des lecteurs de cartes à puce, des casques, des stations d’accueil, et parfois
un moniteur qui se prend pour un hub USB et a son avis.

L’objectif est plus restreint et réaliste : bloquer le stockage USB (classe de stockage de masse) tout en laissant les périphériques
d’interface humaine (HID) intacts. Faites-le avec des preuves, des déploiements graduels et un plan pour les cas limites bizarres — parce que ce sont eux qui causent les pannes.

Ce contre quoi vous vous défendez réellement

« Bloquer le stockage USB » est souvent vendu comme une case à cocher sécurité. Ce n’en est pas une. C’est un contrôle qui réduit quelques risques spécifiques :

Exfiltration de données en copiant des fichiers vers des médias amovibles.
Introduction de logiciels malveillants via des workflows de type autorun (moins fréquent aujourd’hui) et exécution initiée par l’utilisateur (toujours fréquente).
Erreurs opérationnelles comme l’image disque lancée sur la mauvaise machine ou le démarrage depuis un outil USB « utile ».
Posture réglementaire : démontrer que vous pouvez restreindre les médias amovibles quand c’est requis.

Cela ne résout pas les attaques de type « BadUSB » où un appareil se fait passer pour un clavier. Bloquer la classe de stockage de masse ne stoppera pas un HID malveillant.
Si vous en avez besoin, vous êtes sur le terrain de l’allowlisting des appareils, du contrôle des ports ou des contrôles physiques.

Une politique utilisable ressemble généralement à ceci :
bloquer la storage mass par défaut, autoriser des exceptions approuvées (IDs de périphériques spécifiques, machines spécifiques, rôles précis),
et tout consigner pour pouvoir répondre « que s’est-il passé ? » sans gymnastique d’interprétation.

Faits et bref historique à utiliser en réunion

La classe de stockage de masse USB (MSC) a standardisé le comportement « clé USB = disque » ; c’est le code de classe 08 sur l’USB.
HID est le code de classe 03. Les claviers et souris se trouvent généralement ici. Bloquer la classe 08 ne devrait pas toucher la classe 03 — sauf si vos outils sont trop grossiers.
Windows aimait l’autorun au début, et la dette de sécurité a duré des années. Windows moderne l’a largement neutralisé, mais les utilisateurs continuent de double-cliquer.
Beaucoup de « clés USB » sont des appareils composites : stockage plus émulation CD-ROM plus interfaces propres au vendeur. C’est pourquoi certains contrôles les manquent.
UASP (USB Attached SCSI Protocol) a amélioré les performances pour les SSD externes, mais a aussi changé les pilotes qui se lient — une autre façon dont les politiques sont contournées accidentellement.
Les téléphones présentent souvent MTP/PTP, pas mass storage. Si votre politique bloque seulement MSC, les utilisateurs peuvent toujours transférer des données via les protocoles de téléphone.
USB-C a rendu « un port » ambigu : le même trou peut transporter stockage, réseau, affichage et alimentation. Le blocage au niveau du port est maintenant un instrument grossier.
Linux a historiquement lié le stockage USB via le module usb-storage. Mettre hors service ce module est efficace, mais peut aussi casser des workflows de démarrage légitimes et certains comportements de dock.
Certaines claviers d’entreprise incluent des hubs USB. Le clavier fonctionne, le hub s’énumère, et soudain votre politique « pas d’USB » pense qu’elle a trouvé une nouvelle classe de périphérique.

Principes de conception : bloquer le stockage, pas l’USB

Si vous ne retenez qu’une chose : ne « désactivez pas l’USB. » Désactivez la capacité de monter ou d’accéder au stockage amovible.
Ce sont des problèmes différents avec des rayons d’impact différents.

1) Soyez précis sur ce que « stockage USB » signifie

Vous visez les appareils qui exposent des interfaces de stockage en bloc : code de classe 08, ou des pilotes comme
usb-storage sur Linux et USBSTOR sur Windows. Mais surveillez aussi :

Lecteurs de carte SD intégrés aux claviers/docks (souvent MSC USB).
Boîtiers NVMe externes (MSC ou UASP).
Fonctions CD-ROM virtuel sur des disques « sécurisés ».
Stockage Thunderbolt (pas la classe USB 08 du tout ; surface de contrôle différente).

2) Décidez si vous avez besoin de « bloquer » ou d’« allowlister »

Bloquer MSC largement est plus simple et habituellement suffisant. L’allowlisting complet est plus sûr mais coûteux à maintenir.
En pratique :

La plupart des organisations : bloquent le stockage de masse, autorisent des exceptions par ID de périphérique pour des disques chiffrés approuvés, et consignent.
Postes à risque élevé : allowlisting par VID:PID et numéro de série ; refuser tout le reste ; utiliser des stations d’accueil et claviers gérés.

3) Pensez en couches : noyau/driver + politique + système de fichiers

Le blocage au niveau du pilote empêche le périphérique de fonctionner comme stockage du tout. Le blocage au niveau politique peut empêcher
l’installation ou le montage. Les contrôles au niveau système de fichiers (comme les restrictions de montage) peuvent réduire les dégâts même quand le périphérique est présent.

Superposer les couches compte parce que les attaquants et les accidents n’ont que faire de votre couche préférée.

4) La journalisation fait partie du contrôle

Si votre seul signal est « l’utilisateur dit que la souris a arrêté de fonctionner », vous opérez par folklore.
Consignez ce qui a été bloqué, pourquoi et comment la règle a matché.

Idée paraphrasée de Gene Kim : le gain de fiabilité vient de boucles de rétroaction rapides et d’apprentissage à partir des échecs, pas de réparations héroïques après coup.

Boîte à outils Linux : modules, udev, USBGuard

Linux vous donne plusieurs leviers. Utilisez l’instrument le moins grossier qui maintienne toutefois la ligne.

Option A: Désactiver le module `usb-storage` (efficace, grossier)

Cela empêche les appareils MSC USB de se lier au pilote de stockage. C’est simple et fonctionne bien sur serveurs et kiosques.
Cela peut aussi surprendre sur les portables des développeurs et les bancs d’assistance, où l’on utilise légitimement des médias amovibles.

Ce n’est pas complet : UAS utilise le pilote uas, et certains appareils se lient différemment. Il faut bloquer les deux si vous êtes sérieux.

Option B: règles udev pour désautoriser des périphériques (chirurgical, facile à rater)

udev peut matcher des périphériques et basculer l’autorisation. L’avantage : vous pouvez matcher sur le code de classe, le vendeur, le produit et l’interface.
L’inconvénient : une règle maladroite et vous désautorisez le bus USB interne derrière le clavier d’un portable.

Option C: USBGuard (moteur de politique, meilleur pour les flottes)

USBGuard fournit des règles allow/deny, de la journalisation et un langage de politique qui comprend les attributs des périphériques.
C’est un meilleur choix pour « bloquer le stockage mais autoriser HID », car vous pouvez explicitement autoriser HID et explicitement bloquer le stockage de masse,
et gérer les exceptions proprement.

Si vous gérez une flotte, choisissez USBGuard ou une plateforme de gestion d’endpoints qui fait la même chose.
Si vous durcissez une seule machine, le blacklistage de modules suffit.

Boîte à outils Windows : GPO, registre, restrictions d’installation

Windows est l’endroit où la plupart des organisations trébuchent, car il y a plusieurs mécanismes qui se chevauchent :

Service USBSTOR : le désactiver empêche le chargement du pilote de stockage USB.
Politiques d’accès aux médias amovibles : restreignent l’accès en lecture/écriture par classe.
Restrictions d’installation de périphériques : empêchent l’installation de classes ou d’IDs spécifiques.

La réponse propre en entreprise est généralement : GPO pour bloquer le stockage USB, avec un processus d’exception pour les disques chiffrés approuvés.
Mais vous devez valider que vous ne bloquez pas les lecteurs de cartes à puce, la biométrie ou les appareils composites utilisés pour l’authentification.

Note macOS : la vérité inconfortable

macOS peut être contrôlé via des profils MDM, des outils d’endpoint security, et dans certains cas en restreignant les médias amovibles.
Mais les spécificités varient fortement selon la version du système et la plateforme de gestion.

Opérationnellement : si vous avez une flotte mixte, ne concevez pas la politique autour de la plateforme que vous maîtrisez le mieux. Concevez-la autour
d’objectifs cohérents : « pas de montages de médias amovibles non gérés », « appareils approuvés autorisés », et « événements consignés centralement ».

Tâches pratiques : commandes, sorties et décisions

Voici les tâches que j’exécute réellement quand j’essaie de bloquer le stockage USB sans casser claviers et souris.
Chaque tâche inclut : la commande, à quoi ressemble une sortie réaliste, ce que cela signifie, et la décision à prendre.

Task 1: Identifier ce que le noyau considère comme USB ou non (Linux)

cr0x@server:~$ lsusb
Bus 002 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 002 Device 003: ID 0781:5567 SanDisk Corp. Cruzer Blade
Bus 001 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. USB3.0 Card Reader

Sens : vous avez un récepteur Logitech (probablement HID), une clé SanDisk (stockage) et un lecteur de cartes (stockage).

Décision : planifier le blocage des périphériques de classe stockage et décider si vous voulez aussi bloquer les lecteurs de cartes intégrés aux docks.

Task 2: Vérifier les codes de classe d’interface USB (Linux)

cr0x@server:~$ lsusb -v -d 0781:5567 | egrep -i 'bInterfaceClass|bInterfaceSubClass|bInterfaceProtocol' | head
  bInterfaceClass         8 Mass Storage
  bInterfaceSubClass      6 SCSI
  bInterfaceProtocol     80 Bulk-Only

Sens : il s’agit du MSC classique (classe 8). Si vous bloquez les interfaces de classe 8, cet appareil cesse de fonctionner comme stockage.

Décision : sûr de bloquer au niveau interface/classe, tout en laissant la classe 3 (HID) inchangée.

Task 3: Confirmer que claviers et souris s’énumèrent comme HID (Linux)

cr0x@server:~$ lsusb -v -d 046d:c534 | egrep -i 'bInterfaceClass|HID' | head
  bInterfaceClass         3 Human Interface Device
  iInterface              0

Sens : périphérique de classe HID. Votre approche « bloquer la classe de stockage 08 » ne devrait pas le toucher.

Décision : autoriser explicitement la classe HID dans tout moteur allow/deny que vous déployez (USBGuard), car la clarté bat l’espoir.

Task 4: Voir quels modules noyau sont en jeu (Linux)

cr0x@server:~$ lsmod | egrep 'usb_storage|uas|usbhid' | head
usbhid                 61440  0
usb_storage            73728  1 uas
uas                    28672  0

Sens : usbhid est chargé (bien), et usb_storage et uas existent (voies de stockage).

Décision : si vous blacklistez uniquement usb_storage, les dispositifs UASP peuvent encore fonctionner via uas. Bloquez les deux pour être cohérent.

Task 5: Observer ce qui se passe lorsqu’une clé USB est branchée (Linux)

cr0x@server:~$ sudo udevadm monitor --kernel --udev
KERNEL[2317.332122] add      /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb)
UDEV  [2317.410923] add      /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb)
KERNEL[2317.972114] add      /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb)
UDEV  [2317.973881] add      /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb)

Sens : vous voyez des nœuds device et interface. L’interface (…:1.0) est l’endroit où les correspondances basées sur la classe ont souvent lieu.

Décision : construisez des règles autour des attributs d’interface, pas seulement VID:PID, quand vous voulez « bloquer le stockage, autoriser HID ».

Task 6: Inspecter les attributs sysfs d’un périphérique spécifique (Linux)

cr0x@server:~$ usb_path=$(readlink -f /sys/bus/usb/devices/2-1)
cr0x@server:~$ echo "$usb_path"
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1
cr0x@server:~$ cat /sys/bus/usb/devices/2-1/idVendor; cat /sys/bus/usb/devices/2-1/idProduct
0781
5567

Sens : sysfs vous donne des identifiants relativement stables pour écrire des règles udev ou des politiques USBGuard.

Décision : utilisez VID:PID pour les allowlists d’exceptions ; ajoutez le serial si vous avez besoin d’un contrôle plus strict.

Task 7: Blacklister les modules de stockage (Linux)

cr0x@server:~$ sudo tee /etc/modprobe.d/usb-storage-block.conf >/dev/null <<'EOF'
blacklist usb_storage
blacklist uas
EOF
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.5.0-26-generic

Sens : vous avez empêché ces modules de se charger aux prochains boots, et reconstruit initramfs pour que le démarrage précoce le respecte.

Décision : utilisez ceci sur serveurs/kiosques où vous ne voulez vraiment jamais de stockage amovible. Sur les portables, favorisez les moteurs de politique et les exceptions.

Task 8: Valider que le stockage ne se lie plus après un reboot (Linux)

cr0x@server:~$ lsmod | egrep 'usb_storage|uas' || echo "no usb storage modules loaded"
no usb storage modules loaded

Sens : le noyau n’offre plus la voie de stockage habituelle.

Décision : procédez seulement si vous avez confirmé que les workflows légitimes n’auront pas besoin du stockage USB (ou si vous avez un chemin de récupération hors-bande).

Task 9: Déployer USBGuard et générer une politique de base (Linux)

cr0x@server:~$ sudo apt-get install -y usbguard
Reading package lists... Done
Setting up usbguard (1:1.0.0-2) ...
cr0x@server:~$ sudo usbguard generate-policy
allow id 046d:c534 serial "" name "Unifying Receiver" hash "..."
block with-interface equals { 08:*:* }

Sens : la politique de base autorise votre récepteur existant et bloque les interfaces de classe 08 (stockage de masse).

Décision : révisez la politique générée avant de l’appliquer en mode enforcement. Les baselines peuvent accidentellement « autoriser » quelque chose que vous ne souhaitez pas, comme un lecteur de carte intégré à un dock.

Task 10: Activer l’enforcement et confirmer la journalisation (Linux USBGuard)

cr0x@server:~$ sudo sed -i 's/^ImplicitPolicyTarget=.*/ImplicitPolicyTarget=block/' /etc/usbguard/usbguard-daemon.conf
cr0x@server:~$ sudo systemctl enable --now usbguard
cr0x@server:~$ sudo systemctl status usbguard --no-pager | head
● usbguard.service - USBGuard daemon
     Loaded: loaded (/lib/systemd/system/usbguard.service; enabled)
     Active: active (running)

Sens : le démon tourne ; la politique implicite est block, donc les périphériques inconnus sont refusés sauf exception par règle.

Décision : déployez l’enforcement en « log-only » d’abord si possible (ou commencez sur un groupe canari). Les postes de production détestent les surprises.

Task 11: Prouver que les HID fonctionnent pendant que le stockage est bloqué (Linux)

cr0x@server:~$ sudo usbguard list-devices
1: allow id 046d:c534 name "Unifying Receiver" serial "" via-port "usb2" with-interface { 03:00:00 }
2: block id 0781:5567 name "Cruzer Blade" serial "..." via-port "usb2" with-interface { 08:06:80 }

Sens : HID (03) autorisé ; stockage (08) bloqué.

Décision : c’est la capture d’écran clé pour votre demande de changement. Elle démontre « claviers/souris OK, stockage non. »

Task 12: Enquêter pourquoi un périphérique de stockage est encore monté (Linux)

cr0x@server:~$ dmesg | tail -n 12
[ 4123.112233] usb 2-1: new SuperSpeed USB device number 7 using xhci_hcd
[ 4123.134455] scsi host6: uas
[ 4123.145678] scsi 6:0:0:0: Direct-Access     Samsung  Portable SSD T7  0    PQ: 0 ANSI: 6
[ 4123.156789] sd 6:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)

Sens : UAS attaché. Si vous n’avez bloqué que usb-storage, UAS peut encore fonctionner. Ou votre politique l’autorise.

Décision : assurez-vous que uas est bloqué (blacklist de module) ou que votre politique bloque l’interface de classe 08 indépendamment du transport.

Task 13: Windows : Vérifier si USBSTOR est désactivé (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\USBSTOR' -Name Start"
Start : 4
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\USBSTOR

Sens : Start=4 est désactivé. (Valeurs communes : 3=manual, 4=disabled.)

Décision : si votre but est de bloquer largement le stockage USB, c’est un contrôle fort. Si vous avez besoin d’exceptions, il faudra une approche plus nuancée.

Task 14: Windows : Vérifier la politique d’accès aux médias amovibles (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices' -ErrorAction SilentlyContinue"

Sens : aucune sortie signifie généralement que la clé de politique n’est pas définie sur cette machine (ou qu’elle est gérée ailleurs).

Décision : si l’environnement repose sur des GPO, confirmez avec gpresult et la politique centrale plutôt que d’éditer le registre à la main.

Task 15: Windows : Voir la classe d’un périphérique (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | Where-Object { $_.FriendlyName -match 'USB' } | Select-Object -First 8 Status,Class,FriendlyName"
OK  HIDClass  USB Input Device
OK  DiskDrive Samsung Portable SSD T7 USB Device
OK  USB       USB Composite Device
OK  HIDClass  HID-compliant mouse

Sens : vous pouvez distinguer HIDClass de DiskDrive. Les appareils composites s’affichent séparément.

Décision : si vous voyez des entrées DiskDrive inattendues, votre contrôle ne fonctionne pas ou les exceptions sont trop larges.

Task 16: Windows : Confirmer les politiques appliquées (gpresult)

cr0x@server:~$ powershell -NoProfile -Command "gpresult /r | Select-String -Pattern 'Applied Group Policy Objects' -Context 0,8"
Applied Group Policy Objects
-----------------------------
    Workstation Baseline
    Removable Media Restrictions

Sens : vous avez vérifié les objets de stratégie appliqués. Cela compte quand vous dépannez « ça marche sur ma machine ».

Décision : si le GPO attendu n’est pas listé, arrêtez de blâmer les pilotes et corrigez d’abord le ciblage de la politique.

Playbook de diagnostic rapide

Quand quelqu’un signale « le stockage USB est bloqué » ou « mon clavier est mort » juste après un changement, vous avez besoin d’un chemin rapide vers la vérité.
Voici l’ordre qui fait gagner du temps.

Première étape : Est-ce un problème de stockage ou d’entrée ?

Linux : lancez lsusb et vérifiez les codes de classe avec lsusb -v pour le périphérique en question.
Windows : Get-PnpDevice filtré par classe HIDClass vs DiskDrive.

Si c’est un HID et qu’il est cassé, votre politique est trop large ou vous avez bloqué un hub parent. Traitez-le comme une panne.

Deuxième étape : Le périphérique s’est-il lié à un pilote ?

Linux : vérifiez dmesg pour usb-storage ou uas, et contrôlez lsmod.
Windows : vérifiez l’état du service USBSTOR et le statut du périphérique dans PnP.

Si le pilote ne s’est jamais lié, votre blocage fonctionne (ou est trop agressif). S’il s’est lié, il y a un chemin manquant (UAS, comportement composite, Thunderbolt).

Troisième étape : Le problème est-il de politique ou d’application ?

Linux : état et liste des périphériques USBGuard ; règles udev et état d’autorisation sysfs.
Windows : gpresult et clés de registre de politique.

Si les politiques ne sont pas appliquées, ne déboguez pas les périphériques. Corrigez le ciblage. Si les politiques sont appliquées mais inefficaces, vous avez probablement bloqué la mauvaise classe ou manqué un pilote alternatif.

Trois mini-récits d’entreprise depuis le terrain

1) Incident causé par une mauvaise hypothèse : « les HID ne sont pas affectés »

Une entreprise de taille moyenne a déployé un changement « bloquer le stockage USB » sur des desktops Linux utilisés par leur équipe support client.
L’ingénieur qui écrivait la règle udev a matché sur le mot « USB » dans un filtre de sous-système puis a désautorisé tout le nœud device.
L’hypothèse était que le stockage est « un périphérique », donc bloquer le périphérique.

Ce qu’ils ont manqué : beaucoup de bureaux utilisaient des claviers bon marché avec hubs USB intégrés. Le clavier s’énumérait comme HID,
mais le hub s’énumérait comme un périphérique séparé. La règle udev a déclenché sur le hub, l’a désautorisé, et a fait tomber le clavier.
La souris, branchée sur le clavier, a aussi cessé de fonctionner.

Les appels au support ont afflué. La réparation à distance était possible pour certains systèmes, mais une partie des postes ne pouvait pas être contrôlée car
il fallait un clavier/souris fonctionnel pour se connecter, et les outils distants demandaient une approbation interactive. La correction a finalement nécessité de se rendre physiquement
aux bureaux avec un clavier filaire connu branché directement dans l’ordinateur/dock.

Le post-mortem était ennuyeux et correct : matcher uniquement sur la classe d’interface 08, tester avec des appareils composites, et garder un mécanisme de rollback qui ne nécessite pas d’entrée locale.
Aussi, ne pas déployer une règle non testée sur au moins un modèle de station d’accueil et un « clavier de bureau aléatoire ».

2) Optimisation qui s’est retournée contre eux : « on blackliste les modules partout »

Une autre organisation voulait une victoire rapide, alors ils ont blacklisté usb_storage sur tous les hôtes Linux via leur gestion de configuration.
Ça a fonctionné. Ça a aussi cassé leur workflow on-call d’une façon qui n’était pas apparue en test.

Leur processus de récupération serveur reposait sur le démarrage depuis une image OS connue sur une clé USB pour certains problèmes bare-metal.
Toutes les machines n’avaient pas de média virtuel fonctionnel, et tous les incidents n’avaient pas lieu dans un datacenter avec un console parfait.
Le blacklistage n’a pas seulement bloqué la copie de fichiers occasionnelle ; il a retiré un outil de récupération.

Lors du prochain incident réel, un ingénieur on-call est arrivé avec son média de récupération USB et a découvert que l’hôte ne le voyait pas.
Ils ont perdu du temps, puis encore du temps à expliquer à la sécurité pourquoi le « correctif simple » avait des conséquences opérationnelles. L’ironie est que
l’équipe sécurité n’a pas été amusée, mais l’incident était réel.

Ils ont pivoté vers une approche par niveaux : blacklist sur kiosques et desktops de centres d’appel, USBGuard allow/deny sur portables développeurs,
et exceptions « break glass » pour un petit groupe de machines de support. Même intention sécurité, moins d’autosabotage.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « canary et logs »

Une grande entreprise a fait le déploiement de la façon que personne ne veut faire parce que ça paraît lent : anneau canari, puis pilote, puis déploiement large.
Ils ont aussi activé une journalisation détaillée depuis le moteur de politique vers leur plateforme de logs centrale avec un jeu de champs standard :
ID de périphérique, classes d’interface, action prise, règle matchée.

Pendant le pilote, une station d’accueil casque spécifique a commencé à échouer. Pas de façon intermittente — de façon constante. Le support avait un symptôme clair :
« Station USB audio non reconnue. » Les logs montraient que le dock exposait un lecteur de carte (classe MSC 08) plus de l’audio.
La politique refusait l’appareil composite entier, pas seulement l’interface de stockage. C’est une nuance de politique, pas un problème utilisateur.

Comme c’était le pilote et que les logs étaient bons, ils ont fait une exception ciblée : autoriser ce périphérique, mais refuser son interface de stockage,
et appliquer « pas de montage » au niveau OS pour les médias amovibles. Le dock a fonctionné, le stockage non, et l’activité n’a pas ressenti le changement.

Personne n’a écrit un courriel héroïque. Personne n’a eu de trophée. Le déploiement a réussi discrètement — qui est le seul succès digne de confiance en opérations.

Erreurs courantes : symptômes → cause → correctif

1) Symptom : le clavier et la souris arrêtent de fonctionner après « blocage du stockage USB »

Cause racine : vous avez bloqué un hub en amont ou désautorisé tout le nœud USB au lieu de l’interface de stockage.

Correctif : matcher et bloquer uniquement l’interface de classe 08. Si vous utilisez USBGuard, autorisez explicitement les interfaces HID ; évitez les defaults « block all USB » sur les postes.

2) Symptom : les clés USB fonctionnent encore sur certaines machines

Cause racine : politique non appliquée (ciblage GPO, dérive de la gestion de config), ou chemin UAS non bloqué (uas toujours chargé).

Correctif : vérifiez l’application des politiques (gpresult sur Windows ; état/service/config sur Linux), et bloquez à la fois usb_storage et uas ou bloquez la classe 08 au niveau politique.

3) Symptom : le transfert de fichiers depuis un téléphone fonctionne encore après le blocage

Cause racine : les téléphones utilisent MTP/PTP, pas la classe de stockage de masse 08.

Correctif : décidez si votre exigence inclut MTP/PTP. Si oui, restreignez ces protocoles via la politique endpoint/MDM et des contrôles DLP.

4) Symptom : une station d’accueil cesse de fonctionner (réseau, affichage, audio) en bloquant le stockage

Cause racine : appareil composite traité comme « une seule entité », et le refus affecte l’appareil entier ; ou le moteur de politique refuse le dock parce qu’il inclut un lecteur MSC.

Correctif : autorisez le dock par ID et refusez uniquement l’interface de stockage si votre outil supporte les règles par interface ; sinon choisissez un modèle de dock sans lecteur intégré.

5) Symptom : les utilisateurs peuvent écrire sur les clés USB mais ne peuvent pas lire (ou inversement)

Cause racine : politique partielle (commutateurs lecture/écriture incohérents) ou options de montage appliquées seulement à certains points de montage.

Correctif : standardisez : soit refuser entièrement le pilote, soit appliquer des restrictions lecture/écriture cohérentes via une politique centralisée et testez les deux sens.

6) Symptom : « stockage USB bloqué » casse les workflows de démarrage/récupération

Cause racine : vous avez bloqué le stockage au niveau du pilote sur des machines qui ont besoin de média de démarrage USB pour la récupération.

Correctif : prévoyez des hôtes ou rôles « break-glass » ; documentez les chemins de récupération ; envisagez des jetons d’autorisation temporaires plutôt que des exceptions permanentes.

7) Symptom : les appareils basculent aléatoirement entre autorisé et bloqué

Cause racine : allowlisting sans numéro de série ; VID:PID couvre plusieurs lots d’appareils ; changements de topologie de hub ; baselines de politique mises à jour sans soin.

Correctif : inclure le numéro de série quand c’est possible ; traitez les mises à jour de politique comme du code ; testez sur du hardware représentatif ; consignez les correspondances de règles.

Blague #1 : USB signifie « Universal Serial Bus », mais en production cela veut souvent dire « Usually Someone Broke-it ».

Listes de contrôle / plan étape par étape

Étape 1: Décidez la délimitation de la politique (et écrivez-la)

Bloquer la classe MSC USB 08 par défaut ?
Autoriser des clés chiffrées approuvées ?
Qu’en est-il des lecteurs SD sur les docks ?
Qu’en est-il des téléphones (MTP/PTP), appareils photo et adaptateurs Ethernet USB ?
Faut-il empêcher le démarrage depuis l’USB, ou seulement le montage dans l’OS ?

Si vous ne pouvez pas répondre, vous n’avez pas de politique ; vous avez une impression.

Étape 2: Inventoriez le matériel réel dans votre environnement

Au moins un exemple de chaque modèle de portable.
Chaque modèle de dock en circulation.
Au moins deux « claviers de bureau aléatoires » (sérieusement).
Lecteurs de carte à puce et dispositifs biométriques utilisés pour l’authentification.

Collectez VID:PID et classes d’interface. Ne devinez pas.

Étape 3: Choisissez votre mécanisme d’enforcement par type de poste

Serveurs/kiosques : blacklist de module Linux + restrictions de montage système de fichiers ; Windows USBSTOR désactivé si pas d’exceptions nécessaires.
Portables employés : moteur de politique (USBGuard / outil endpoint), avec exceptions allowlistées et journalisation robuste.
Postes privilégiés/admin : mode allowlist ; traiter tout nouvel appareil comme suspect jusqu’à approbation.

Étape 4: Construisez les exceptions délibérément

Préférez l’allowlisting de modèles de clés chiffrées par VID:PID + numéro de série.
Limitez les exceptions dans le temps (p.ex. approbations temporaires) si votre outil le permet.
Exigez une raison métier et un propriétaire pour chaque exception.

Étape 5: Déploiement canari (non négociable si vous aimez dormir)

Commencez par les postes IT et sécurité. Ils peuvent se sauver eux-mêmes.
Puis un groupe pilote avec des setups de dock représentatifs.
Puis déploiement large.

Blague #2 : La meilleure fenêtre de changement est « jamais », mais la deuxième meilleure est « après avoir testé sur le dock du CFO ».

Étape 6: Journalisation et alerting

Centralisez les logs pour « périphérique bloqué » et « périphérique autorisé par exception ».
Alertez sur des blocs répétés sur une même machine (comportement utilisateur ou staging de malware possible).
Suivez les modèles de périphériques bloqués en tête ; c’est souvent un dock/lecteur de carte inconnu.

Étape 7: Runbook opérationnel et rollback

Ayez un rollback qui ne nécessite pas d’entrée locale clavier/souris (gestion distante, console hors-bande).
Conservez une procédure « autorisation d’urgence » documentée avec approbations.
Formez le helpdesk sur quoi demander : modèle de périphérique, dock, si l’appareil est stockage ou HID.

FAQ

1) Bloquer le stockage USB arrêtera-t-il les attaques BadUSB ?

Non. BadUSB se présente souvent comme un clavier (HID). Bloquer la classe de stockage de masse 08 ne bloque pas la classe HID 03.
Pour atténuer cela, vous avez besoin d’allowlisting des appareils, de contrôle de ports ou de restrictions physiques.

2) Pourquoi ne pas simplement désactiver tous les ports USB ?

Parce que vous casserez l’entrée de base, les cartes à puce, le docking, et parfois la connectivité réseau.
De plus, les ports USB-C sont multi-usage ; « désactiver le port » équivaut souvent à « désactiver le poste de l’utilisateur ».

3) Blacklister `usb-storage` suffit-il sur Linux ?

Souvent, mais pas toujours. Beaucoup de dispositifs modernes utilisent UAS, qui se lie à uas.
Si vous prenez la voie du blacklistage de modules, bloquez à la fois usb_storage et uas, et validez avec du matériel réel.

4) Si nous bloquons le stockage USB, les utilisateurs peuvent-ils quand même sortir des données ?

Oui. Email, synchronisation cloud, captures d’écran, téléphones via MTP, et adaptateurs Ethernet USB existent.
Bloquer le stockage USB réduit un canal. Ce n’est pas une stratégie complète de prévention de perte de données.

5) Comment autoriser seulement des clés USB chiffrées approuvées ?

Utilisez l’allowlisting par VID:PID plus numéro de série quand c’est possible, et maintenez un workflow d’exception.
Sur Linux, les politiques USBGuard sont une voie pratique. Sur Windows, associez la désactivation USBSTOR/les restrictions de périphériques à un outil endpoint qui supporte le contrôle d’appareil et l’audit.

6) Qu’en est-il des lecteurs SD dans les portables et docks ?

Beaucoup s’énumèrent comme stockage de masse USB. Si votre exigence est « pas de médias amovibles », bloquez-les aussi.
Si votre exigence est « pas de clés externes », vous aurez besoin d’exceptions par périphérique pour ne pas casser les stations d’accueil qui incluent des lecteurs.

7) Peut-on bloquer le montage tout en laissant le périphérique s’énumérer ?

Oui. C’est un contrôle plus doux : le périphérique apparaît, mais l’OS ne le montera pas ni n’autorisera l’accès.
Cela peut réduire les cassures, mais c’est plus facile à contourner si les utilisateurs ont des droits admin ou si d’autres sous-systèmes peuvent accéder aux périphériques bruts.

8) Comment prouver aux auditeurs que le stockage USB est bloqué ?

Fournissez des preuves depuis plusieurs couches : configuration de politique (GPO/USBGuard), vérification sur endpoint (commandes montrant le pilote désactivé),
et logs démontrant des blocs avec identifiants de périphérique et horodatages.

9) Quelle est la raison la plus courante d’échec de ces déploiements ?

Traiter le « stockage USB » comme une catégorie de périphérique au lieu d’une catégorie d’interface/driver, et bloquer trop haut dans la pile
(hubs, appareils composites, ou tout l’USB).

Prochaines étapes que vous pouvez faire cette semaine

Si vous voulez une politique qui bloque le stockage USB et ne devienne pas une source hebdomadaire d’incidents, faites ceci dans l’ordre :

Inventaire : exécutez des vérifications de codes de classe sur votre mélange hardware réel, surtout docks et lecteurs intégrés.
Choisir l’enforcement par endpoint : blacklist de module pour systèmes à fonction fixe ; moteur de politique pour postes utilisateurs.
Bloquer les chemins classiques et modernes : sur Linux, pensez usb_storage et uas ; sur Windows, validez USBSTOR et les politiques de médias amovibles.
Déploiement canari avec journalisation : si vous ne voyez pas ce que vous bloquez, vous devinez fort bruyamment.
Planifier les exceptions : disques chiffrés approuvés et appareils composites requis obtiennent des règles explicites, pas des compromis improvisés.

Surtout : ne déployez pas un contrôle que vous ne pouvez pas annuler. Les changements de sécurité qui coupent les périphériques d’entrée restent gravés dans les mémoires pour de mauvaises raisons.