Блокувати USB-накопичувачі без порушення роботи клавіатур і мишей

February 20, 2026 • February 20, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Якщо ви колись впроваджували політику «відключити USB» і бачили, як черга звернень до служби підтримки зростає,
ви вже знаєте правду: кінцеві точки заплутані, користувачі креативні, а USB — це тарган серед інтерфейсів.
Не можна просто «вимкнути його», не зачепивши клавіатури, миші, рідери смарткарт, гарнітури, док-станції і випадковий
монітор, який вважає себе USB-хабом з власною думкою.

Мета вже конкретніша й реалістичніша: блокувати USB-накопичувачі (клас масового зберігання), залишаючи при цьому пристрої
для взаємодії з людиною (HID) працездатними. Робіть це з доказами, поетапним впровадженням і планом для дивних крайніх випадків—
бо саме в них живуть відмови.

Що ви насправді захищаєте

«Блокувати USB-накопичувачі» продається як прапорець безпеки. Це не так. Це контроль, який зменшує кілька конкретних ризиків:

Екфільтрація даних шляхом копіювання файлів на знімні носії.
Внесення шкідливого ПЗ через робочі процеси на кшталт autorun (тепер рідше) та виконання, ініційоване користувачем (все ще часто).
Операційні “пастки” наприклад, коли хтось робить образ не тієї машини або завантажується з «корисної» флешки.
Регуляторний вигляд: можливість показати, що ви можете обмежувати змінні носії там, де це потрібно.

Це не вирішує атаки типу «BadUSB», де пристрій прикидається клавіатурою. Блокування класу масового зберігання не зупиняє зловмисний HID.
Якщо вам потрібен цей захист — переходьте до allowlist пристроїв, контролю портів або фізичних обмежень.

Придатна політика зазвичай виглядає так:
блокувати масове сховище за замовчуванням, дозволяти затверджені винятки (конкретні ID пристроїв, конкретні машини, конкретні ролі),
і логувати все, щоб відповідати на питання «що сталося?» без танців з інтерпретацією.

Факти та коротка історія для нарад

USB Mass Storage Class (MSC) стандартизував поведінку «флешка виглядає як диск»; це клас код 08 в USB.
HID — це код класу 03. Клавіатури і миші зазвичай працюють тут. Блокувати клас 08 не повинно зачепити клас 03—якщо ваше інструментування не занадто грубе.
В ранніх версіях Windows сильно використовувався autorun, і наслідки безпеки відчувалися роками. Сучасні Windows значно обмежили це, але користувачі досі двічі клікають по файлах.
Багато «USB-накопичувачів» — композитні пристрої: сховище плюс емуляція CD-ROM плюс інтерфейси виробника. Тому деякі контролі їх пропускають.
UASP (USB Attached SCSI Protocol) підвищив продуктивність зовнішніх SSD, але також змінив, які драйвери прив’язуються — ще один шлях, через який політики можуть випадково обходитися.
Телефони часто представляють інтерфейси як MTP/PTP, а не масове сховище. Якщо ваша політика блокує тільки MSC, користувачі можуть продовжувати передавати дані через протоколи телефонів.
USB-C зробив «порт» неоднозначним: той самий отвір може передавати сховище, мережу, відео та живлення. Блокування на рівні порту тепер — грубий інструмент.
У Linux історично USB-сховище пов’язувалося модулем usb-storage. Блокування цього модуля ефективне, але може зламати легітимні робочі процеси завантаження і деякі поведінки док-станцій.
Деякі корпоративні клавіатури мають вбудовані USB-хаби. Клавіатура працює, хаб перелічується, і раптом ваша політика «нема USB» думає, що виявлено новий клас пристрою.

Принципи проєктування: блокувати сховище, а не USB

Якщо запам’ятати одну річ: не «відключайте USB». Вимкніть можливість монтувати або отримувати доступ до знімного сховища.
Це різні проблеми з різним радіусом ураження.

1) Будьте конкретні щодо того, що означає «USB-накопичувач»

Ви орієнтуєтеся на пристрої, що надають інтерфейси блочного сховища: код класу 08, або драйвери типу
usb-storage у Linux і USBSTOR у Windows. Але також слід дивитись на:

SD-кардрідери, вбудовані в клавіатури/доки (часто USB MSC).
Зовнішні корпуси NVMe (MSC або UASP).
Віртуальні CD-ROM у «безпечних» дисків.
Thunderbolt-сховище (взагалі не клас 08; інша площина контролю).

2) Вирішіть, чи потрібен вам «блок» або «allowlist»

Масове блокування MSC простіше і зазвичай достатнє. Allowlist всього — безпечніше, але дорого в підтримці.
На практиці:

Більшість організацій: блокують масове сховище, допускають винятки за ідентифікаторами пристроїв для затверджених зашифрованих дисків і логують.
Середовища з високим ризиком: allowlist за VID:PID і серійним номером; заборонити все інше; використовувати керовані док-станції й клавіатури.

3) Думайте шарами: ядро/драйвер + політика + файлові системи

Блокування на рівні драйвера перешкоджає роботі пристрою як сховища взагалі. Політика може забороняти встановлення або монтування.
Контролі на рівні файлової системи (наприклад, обмеження монтування) можуть зменшити шкоду, навіть якщо пристрій присутній.

Шарування важливе, бо нападники й випадковості ігнорують ваш улюблений шар.

4) Логування — частина контролю

Якщо вашим єдиним сигналом є «користувач каже, що миша перестала працювати», ви керуєтесь переказами.
Логгируйте, що було заблоковано, чому, і як правило співпало.

Парафраз ідеї від Gene Kim: виграш у надійності приходить від швидких зворотних зв’язків і навчання на помилках, а не від героїчних післяаварійних виправлень.

Інструментарій для Linux: модулі, udev, USBGuard

У Linux є кілька важелів. Використовуйте найменш грубий інструмент, який все ж утримує лінію.

Option A: Disable the `usb-storage` module (effective, blunt)

Це запобігає прив’язці пристроїв MSC до драйвера сховища. Просто і добре працює на серверах і у кіосках.
Так само може здивувати на ноутбуках розробників і у службах підтримки, де люди легітимно використовують знімні носії.

Це не повністю: UAS використовує драйвер uas, і деякі пристрої прив’язуються інакше. Якщо ви серйозні, потрібно блокувати обидва.

Option B: udev rules to de-authorize devices (surgical, easy to get wrong)

udev може співставляти пристрої й змінювати авторизацію. Перевага: можна співставляти за кодом класу, виробником, продуктом та інтерфейсом.
Недолік: одна невдала маска і ви деавторизуєте внутрішню USB-шину під клавіатурою ноутбука.

Option C: USBGuard (policy engine, best for fleets)

USBGuard дає правила allow/deny, логування та мову політик, що розуміє атрибути пристроїв.
Це кращий вибір для «блокувати сховище, але дозволити HID», бо ви явно дозволяєте HID і явно блокуєте масове сховище,
та можете акуратно налаштовувати винятки.

Якщо у вас флот кінцевих точок, обирайте USBGuard або платформу управління кінцевими точками з аналогічними можливостями.
Для жорсткого захисту однієї машини — чорний список модулів підходить.

Інструментарій для Windows: GPO, реєстр, обмеження встановлення пристроїв

У Windows багато організацій зазнають проблем, бо існує кілька накладних механізмів:

Служба USBSTOR: її відключення блокує завантаження драйвера масового зберігання USB.
Політики доступу до знімних носіїв: обмежують читання/запис за класом.
Обмеження встановлення пристроїв: не дозволяють встановлювати певні класи або ідентифікатори пристроїв.

Чистою корпоративною відповіддю зазвичай є: GPO для блокування USB-накопичувачів з процесом винятків для затверджених зашифрованих пристроїв.
Але потрібно перевірити, що ви не блокуєте зчитувачі смарткарт, біометрію або композитні пристрої, що використовуються для входу.

Нотатка щодо macOS: неприємна правда

macOS можна контролювати через MDM-профілі, інструменти безпеки кінцевих точок і в деяких випадках шляхом обмеження знімних носіїв.
Але конкретика значно варіюється залежно від версії ОС і платформи управління.

Операційно: якщо у вас змішаний флот, не будуйте політику навколо платформи, яку ви розумієте найкраще.
Проєктуйте її навколо послідовних результатів: «немає монтування незадокументованих знімних носіїв», «дозволені пристрої», і «події централізовано логуються».

Практичні завдання: команди, виводи та рішення

Це завдання, які я фактично виконую, коли намагаюся блокувати USB-накопичувачі без порушення роботи клавіатур і мишей.
Кожне завдання включає: команду, як виглядає реалістичний вивід, що це значить і яке рішення ви приймаєте.

Task 1: Identify what the kernel thinks is USB vs not (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

Значення: у вас є приймач Logitech (ймовірно HID), флешка SanDisk (сховище) і кардридер (сховище).

Рішення: плануйте блокувати пристрої класу сховища і подумайте, чи потрібно блокувати інтегровані кардридери на доках.

Task 2: Check USB interface class codes (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

Значення: це класичний MSC (клас 8). Якщо ви блокуєте інтерфейси класу 8, цей пристрій перестане працювати як сховище.

Рішення: безпечно блокувати на рівні інтерфейсу/класу, залишивши клас 3 (HID) недоторканим.

Task 3: Confirm keyboards and mice enumerate as HID (Linux)

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

Значення: пристрій класу HID. Ваш підхід «блокувати клас сховища 08» не має його зачепити.

Рішення: явно дозволяйте інтерфейси HID у будь-якому рушії allow/deny, який ви розгортаєте (USBGuard), бо ясність краще за надію.

Task 4: See which kernel modules are in play (Linux)

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

Значення: usbhid завантажений (добре), і присутні usb_storage та uas (шляхи для сховища).

Рішення: якщо ви блокуєте тільки usb_storage, UASP-пристрої можуть і далі працювати через uas. Блокуйте обидва для послідовності.

Task 5: Watch what happens when a USB stick is plugged in (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)

Значення: ви бачите вузли пристрою і інтерфейсу. Сам інтерфейс (…:1.0) — це те місце, де часто виконують співставлення за класом.

Рішення: будуйте правила навколо атрибутів інтерфейсу, а не лише VID:PID пристрою, коли мета — «блокувати сховище, дозволяти HID».

Task 6: Inspect sysfs attributes for a specific device (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

Значення: sysfs дає вам відносно стабільні ідентифікатори для написання udev-правил або політик USBGuard.

Рішення: використовуйте VID:PID для списків винятків; додавайте серійний номер, якщо потрібен жорсткіший контроль.

Task 7: Blacklist storage modules (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

Значення: ви заборонили завантаження цих модулів при наступних завантаженнях і перебудували initramfs, щоб раннє завантаження це поважало.

Рішення: застосовуйте це на серверах/кіосках, де знімні носії дійсно не потрібні. На ноутбуках краще політичні рушії і винятки.

Task 8: Validate that storage no longer binds after a reboot (Linux)

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

Значення: ядро більше не пропонує звичний шлях для сховища.

Рішення: продовжуйте лише якщо підтвердили, що легітимні робочі процеси не потребують USB-сховища (або у вас є позашляховий шлях відновлення).

Task 9: Deploy USBGuard and generate a baseline policy (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:*:* }

Значення: базова політика дозволяє ваш існуючий приймач і блокує інтерфейси класу 08 (масове сховище).

Рішення: перегляньте згенеровану політику перед застосуванням режиму примусового виконання. Базові політики можуть випадково «дозволити» щось небажане, наприклад кардридер, вбудований у док.

Task 10: Turn on enforcement and confirm logging (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)

Значення: демон запущено; implicit policy встановлено в block, тому невідомі пристрої відхиляються, якщо їх не дозволено правилами.

Рішення: по можливості спочатку впроваджуйте в режимі лише логування (або починайте на канарковій групі). Промислові кінцеві точки не люблять сюрпризи.

Task 11: Prove HID still works while storage is blocked (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 }

Значення: HID (03) дозволено; сховище (08) заблоковано.

Рішення: це ключовий скріншот для запиту на зміни. Він демонструє: «клавіатури/миші ОК, сховище — ні».

Task 12: Investigate why a storage device still mounted (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)

Значення: підключився UAS. Якщо ви блокували тільки usb-storage, UAS міг і далі працювати. Або ваша політика дозволяє цей пристрій.

Рішення: переконайтеся, що uas також заблоковано (чорний список модулів) або що ваша політика блокує інтерфейси класу 08 незалежно від транспорту.

Task 13: Windows: Check whether USBSTOR is disabled (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

Значення: Start=4 означає відключено. (Поширені значення: 3=manual, 4=disabled.)

Рішення: якщо мета — широко блокувати USB-сховище, це сильний контроль. Якщо потрібні винятки — потрібен більш тонкий підхід.

Task 14: Windows: Verify removable storage access policy (PowerShell)

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

Значення: відсутність виводу зазвичай означає, що ключ політики не встановлено на цій машині (або керується звідти, звідки ви не дивитесь).

Рішення: якщо середовище покладається на GPO, перевіряйте через gpresult та центральну політику, а не правте реєстр вручну.

Task 15: Windows: See what device class a thing is (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

Значення: ви можете відрізнити HIDClass від DiskDrive. Композитні пристрої відображаються окремо.

Рішення: якщо ви бачите записи DiskDrive, яких не очікували, ваш контроль не працює або винятки занадто широкі.

Task 16: Windows: Confirm applied policies (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

Значення: ви підтвердили, які об’єкти групових політик застосовано. Це має значення при усуненні проблем «у мене працює, а в тебе ні».

Рішення: якщо очікувана GPO не в списку, не звинувачуйте драйвери — спочатку виправте цільову групу політики.

Плейбук швидкої діагностики

Коли хтось повідомляє «USB-сховище заблоковано» або «моя клавіатура померла» відразу після зміни, вам потрібен швидкий шлях до істини.
Ось порядок, який економить час.

First: Is this a storage issue or an input device issue?

Linux: виконайте lsusb і перевірте коди класів з lsusb -v для проблемного пристрою.
Windows: Get-PnpDevice відфільтрований за класом HIDClass проти DiskDrive.

Якщо це HID і воно не працює — ваша політика надто широка або ви заблокували батьківський хаб. Сприймайте це як аварію.

Second: Did the device bind to a driver?

Linux: перевірте dmesg на наявність usb-storage або uas, і перегляньте lsmod.
Windows: перевірте стан служби USBSTOR та статус пристрою в PnP.

Якщо драйвер ніколи не прив’язався — блок працює (або надто агресивний). Якщо прив’язався — ви пропустили шлях (UAS, композитна поведінка, Thunderbolt).

Third: Is the problem policy, or enforcement?

Linux: стан USBGuard і список пристроїв; udev-правила й стан авторизації в sysfs.
Windows: gpresult і ключі політик у реєстрі.

Якщо політики не застосовані — не налагоджуйте пристрої. Виправляйте таргетинг. Якщо політики застосовано, але вони неефективні — ймовірно, ви заблокували не той клас або пропустили альтернативний драйвер.

Три корпоративні міні-історії з реального життя

1) Інцидент через неправильне припущення: «HID-пристрої не зачеплені»

Середня компанія впровадила зміну «блокувати USB-сховище» на Linux-десктопах, які використовували їхні співробітники служби підтримки.
Інженер, що писав udev-правило, зробив співставлення на слово «USB» в фільтрі підсистеми і потім деавторизував весь вузол пристрою.
Припущення було таке: сховище — це «пристрій», отже блокуємо пристрій.

Що вони пропустили: багато столів використовували дешеві клавіатури з вбудованими USB-хабами. Клавіатура перелічувалася як HID,
але хаб перелічувався як окремий пристрій. udev-правило спрацювало на хабі, деавторизувало його і вивело з ладу клавіатуру.
Миша, підключена до клавіатури, теж згасла.

Потік звернень до служби підтримки зріс. Деякі системи вдалося віддалено відновити, але частина кінцевих точок не була під контролем,
бо для входу потрібні були клавіатура і миша, а віддалені інструменти вимагали інтерактивного підтвердження. Вирішували проблему фізично підходячи
до столів і підключаючи завідомо робочу дротову клавіатуру безпосередньо до ноутбука/доку.

Постмортем був нудний і правильний: співставляти тільки інтерфейсний клас 08, тестувати на композитних пристроях і зберігати механізм відкату,
який не вимагає локального введення. І ще — не випускайте правило, яке не перевірили хоча б на одній моделі дока і на одній «випадковій офісній клавіатурі».

2) Оптимізація, що відкотилася: «Просто заблокуємо модулі всюди»

Інша організація хотіла швидкого виграшу, тому через систему конфігураційного менеджменту заблокувала usb_storage на всіх Linux-хостах.
Це спрацювало. Це також зламало їхній процес аварійного відновлення в сценарії, який не проявився під час тестування.

Їхній процес відновлення сервера залежав від завантаження з відомого образу з USB-накопичувача у певних випадках bare-metal.
Не всі сервери мали робочі віртуальні носії, і не всі інциденти траплялися в дата-центрі з ідеальною консоллю.
Чорний список не лише блокував випадкове копіювання файлів; він позбавив інструменту відновлення.

Під час наступного реального інциденту інженер приїхав з USB-носієм для відновлення і виявив, що хост його не бачить.
Вони втратили час, а потім ще більше часу, пояснюючи команді безпеки, чому «просте виправлення» мало операційні наслідки.

Вони перейшли на багаторівневий підхід: чорний список на кіосках і робочих місцях центрів обслуговування клієнтів, USBGuard allow/deny на ноутбуках розробників,
і “break glass” винятки для невеликої кількості підтримуючих машин. Така сама безпека, менше самосаботажу.

3) Нудна, але правильна практика, що врятувала день: «канарка і журнали»

Велика корпорація виконала rollout так, як ніхто не хоче, бо це здається повільним: канаркове кільце, потім пілотне, потім широке розгортання.
Вони також ввімкнули детальне логування з рушія політик у центральну платформу логів зі стандартним набором полів:
ID пристрою, класи інтерфейсів, вжита дія, правило, яке збіглося.

Під час пілоту конкретна док-станція для гарнітур стала відмовляти. Не періодично — постійно. Хелпдеск мав чіткий симптом:
«USB аудіо-док не розпізнається». Логи показали, що док одночасно виставляв кардридер (MSC клас 08) і аудіо.
Політика відхиляла весь композитний пристрій, а не лише його сховище. Це нюанс політики, а не проблема користувача.

Оскільки це був пілот і логи були хороші, вони зробили цілеспрямований виняток: дозволили цей пристрій, але заборонили його інтерфейс сховища,
і примусили політику «не монтувати» на рівні ОС для знімних носіїв. Док працював, сховище — ні, і бізнес не відчув змін.

Ніхто не написав героїчного листа. Ніхто не отримав трофей. Розгортання тихо пройшло успішно — і це єдиний вид успіху, якому варто довіряти в операціях.

Поширені помилки: симптом → причина → виправлення

1) Симптом: клавіатура і миша перестали працювати після «блокування USB-сховища»

Причина: ви заблокували верхній хаб або деавторизували весь вузол USB замість інтерфейсу сховища.

Виправлення: співставляйте і блокуйте тільки інтерфейсний клас 08. Якщо використовуєте USBGuard — явно дозволяйте інтерфейси HID; уникайте за замовчуванням «блокувати весь USB» на кінцевих точках.

2) Симптом: USB-флешки все ще працюють на деяких машинах

Причина: політика не застосована (помилки в області дії GPO, дрейф конфігурацій), або шлях UAS не заблоковано (uas досі завантажується).

Виправлення: перевірте застосування політик (gpresult у Windows; стан служби/конфіг на Linux), і блокуйте одночасно usb_storage та uas або блокуйте клас 08 на рівні політики.

3) Симптом: передача файлів з телефону все ще працює після блокування USB-сховища

Причина: телефони використовують MTP/PTP, а не клас масового зберігання 08.

Виправлення: вирішіть, чи має ваша вимога включати MTP/PTP. Якщо так — обмежте ці протоколи через політику кінцевої точки/MDM і DLP-контроли.

4) Симптом: док-станція перестає працювати (мережа, дисплей, аудіо) при блокуванні сховища

Причина: композитний пристрій трактовано як «одне ціле», і відмова зачіпає весь пристрій; або рушій політики відхиляє док через вбудований MSC кардридер.

Виправлення: дозволіть док за ID і відхиліть тільки інтерфейс сховища, якщо інструмент підтримує правила по інтерфейсу; інакше оберіть модель дока без вбудованого рідера.

5) Симптом: користувачі можуть записувати на USB, але не читати (або навпаки)

Причина: часткова політика (параметри читання/запису встановлені непослідовно) або опції монтування застосовано лише до деяких точок монтування.

Виправлення: стандартизуйте: або повністю забороніть драйвер, або застосуйте послідовні обмеження читання/запису через централізовану політику і протестуйте обидва напрямки.

6) Симптом: «заблоковане USB-сховище» ламає завантаження/робочі процеси відновлення

Причина: ви заблокували сховище на рівні драйвера на машинах, яким потрібні USB-носії для відновлення.

Виправлення: винесіть окремі «break-glass» хости або ролі; документуйте шляхи відновлення; розгляньте тимчасові токени дозволу замість постійних винятків.

7) Симптом: пристрої випадково перемикаються між дозволеним і заблокованим станом

Причина: allowlist без серійних номерів; VID:PID співпадає з кількома партіями пристроїв; зміни топології хабів; необережні оновлення базових політик.

Виправлення: включайте серійні номери де можливо; ставтеся до оновлень політик як до коду; тестуйте на репрезентативному обладнанні; логгуйте співпадіння правил.

Жарт #1: USB означає «Universal Serial Bus», але в продакшені це часто читається як «Usually Someone Broke-it».

Чеклісти / покроковий план

Step 1: Decide the policy boundary (and write it down)

Блокувати клас USB MSC 08 за замовчуванням?
Дозволяти затверджені зашифровані диски?
Що робити з SD-кардридерами в доках?
Що з телефонами (MTP/PTP), камерами та USB Ethernet-адаптерами?
Потрібно заборонити завантаження з USB, чи лише монтування в ОС?

Якщо ви не можете відповісти на ці питання — у вас немає політики; у вас є відчуття.

Step 2: Inventory real hardware in your environment

Щонайменше один приклад кожної моделі ноутбука.
Кожна модель док-станції, яка використовується.
Щонайменше дві «випадкові офісні клавіатури» (серйозно).
Зчитувачі смарткарт і біометричні пристрої, що використовуються для входу.

Збирайте VID:PID і класи інтерфейсів. Не вгадуйте.

Step 3: Pick your enforcement mechanism by endpoint type

Сервери/кіоски: чорний список модулів у Linux + обмеження монтування файлової системи; у Windows — відключення USBSTOR, якщо винятки не потрібні.
Ноутбуки співробітників: рушій політик (USBGuard / інструменти кінцевих точок) з allowlist винятками і сильним логуванням.
Привілейовані/адмін робочі станції: режим allowlist; ставте будь-який новий пристрій під підозру до схвалення.

Step 4: Build exceptions deliberately

Надавайте перевагу allowlist конкретних моделей зашифрованих дисків по VID:PID + серійному номеру.
Часові винятки (наприклад, короткострокові дозволи), якщо інструмент це підтримує.
Потребуйте бізнес-обґрунтування і власника для кожного винятку.

Step 5: Canary rollout (non-negotiable if you like sleep)

Почніть з кінцевих точок IT і безпеки. Вони можуть самі себе відновити.
Потім пілотна група з репрезентативними док-наборами.
Потім широке розгортання.

Жарт #2: Найкращий вікно для змін — «ніколи», але друге найкраще — «після тестування на доку CFO».

Step 6: Logging and alerting

Централізуйте логи для «пристрій заблоковано» і «пристрій дозволено як виняток».
Налаштуйте оповіщення при повторних блокуваннях на одній машині (можливо, це поведінка користувача або підготовка шкідливого ПЗ).
Відстежуйте топ заблокованих моделей пристроїв; це зазвичай док/кардридер, про який ви не знали.

Step 7: Operational runbook and rollback

Майте механізм відкату, що не вимагає локального введення (віддалене управління, позашляховий консольний доступ).
Збережіть документовану процедуру «аварійного дозволу» з погодженнями.
Навчіть хелпдеск, що запитувати: модель пристрою, док, чи пристрій — сховище чи HID.

Поширені питання

1) Чи зупинить блокування USB-накопичувачів атаки BadUSB?

Ні. BadUSB часто представляється як клавіатура (HID). Блокування масового класу зберігання 08 не блокує клас HID 03.
Якщо вам потрібно це пом’якшити — застосовуйте allowlist пристроїв, контроль портів або фізичні обмеження.

2) Чому просто не відключити всі USB-порти?

Бо ви зламаєте базовий ввід, смарткарти, докінг і іноді мережеве підключення.
Крім того, USB-C порти багатофункціональні; «вимкнути порт» часто означає «вимкнути робочу станцію користувача».

3) Чи достатньо заблокувати `usb-storage` на Linux?

Часто — так, але не завжди. Багато сучасних пристроїв зберігання використовують UAS, який прив’язується до uas.
Якщо ви обираєте шлях чорного списку модулів — блокуйте і usb_storage, і uas, і перевіряйте на реальних пристроях.

4) Якщо ми блокуємо USB-сховище, чи можуть користувачі все ще виносити дані?

Так. Електронна пошта, синхронізація в хмарі, скріншоти, телефони через MTP, а також USB Ethernet-адаптери — все це канали.
Блокування USB-сховища зменшує один канал. Це не повна стратегія DLP.

5) Як дозволити лише корпоративно затверджені зашифровані USB-диски?

Використовуйте allowlist за VID:PID плюс серійні номери де можливо і тримайте процес винятків.
У Linux практичний шлях — політики USBGuard. У Windows поєднуйте відключення USBSTOR/обмеження встановлення пристроїв з інструментами кінцевих точок, що підтримують контроль пристроїв і аудит.

6) Що робити з SD-кардридерами в ноутбуках і доках?

Багато з них перераховуються як USB mass storage. Якщо ваша вимога — «жодних знімних носіїв», блокуйте і їх.
Якщо ж вимога — «немає зовнішніх флешок», вам знадобляться винятки по пристроях, щоб не зламати док-станції з внутрішніми рідерами.

7) Чи можемо ми дозволити перерахування пристрою, але заборонити монтування?

Так. Це м’який контроль: пристрій видно, але ОС не монтує його або не дозволяє доступ.
Це зменшує ризик ушкодження, але легше обійти, якщо користувачі мають права адміністратора або інші підсистеми можуть доступатися до сирих пристроїв.

8) Як довести аудиторам, що USB-сховище заблоковано?

Надайте докази з кількох шарів: конфігурацію політик (GPO/USBGuard), перевірку кінцевої точки (команди, що показують відключення драйвера),
та логи, що демонструють блокування з ідентифікаторами пристроїв і часовими мітками.

9) Яка найпоширеніша причина провалу таких rollout?

Сприйняття «USB-сховище» як категорії пристроїв замість категорії інтерфейсу/драйвера, і блокування занадто високо в стеку
(хаби, композитні пристрої або весь USB).

Наступні кроки, які ви можете зробити цього тижня

Якщо ви хочете політику, яка блокує USB-сховище й не перетвориться на щотижневий генератор інцидентів, зробіть це в такому порядку:

Інвентар: виконайте перевірки кодів класу для вашого реального набору обладнання, особливо доків і вбудованих кардридерів.
Виберіть механізм виконання по типу кінцевої точки: чорний список модулів для систем фіксованого призначення; рушій політик для користувацьких кінцевих точок.
Блокуйте і класичні, і сучасні шляхи: у Linux думайте про usb_storage та uas; у Windows перевіряйте USBSTOR і політики доступу до знімних носіїв.
Канарка та логування: якщо ви не бачите, що блокується — ви просто голосно вгадуєте.
Плануйте винятки: затверджені зашифровані диски і необхідні композитні пристрої отримують явні правила, а не усні дозволи.

Найважливіше: не випускайте контроль, який ви не зможете відкотити. Зміни безпеки, що виводять з ладу пристрої введення, запам’ятовуються з неправильних причин.