Defender Device Control: Bloquear e Controlar USB no Windows

O rato é o único periférico que devia andar livremente na rede. Pen USB, discos externos, impressoras baratas e telemóveis em modo MTP são o caminho mais curto entre a internet exterior e um ficheiro com ransomware — e a pergunta “quem ligou um disco USB ao servidor?” só tem resposta se houver política a responder por ela.

As três camadas de controlo da Microsoft

A Microsoft organiza o controlo de dispositivos em três categorias, cada uma com um papel próprio:

  1. Device installation settings (Windows/ADMX): controlo de instalação de dispositivos nativo do sistema operativo. Funciona com templates ADMX (Intune ou GPO) e decide se um dispositivo pode ser instalado — ideal para bloquear instalação por classe de dispositivo.
  2. Device Control no Defender for Endpoint: controlo granular com âmbito preciso — só entra o que cria disco (removable media), Windows Portable Devices (WPD/telemóveis), CD/DVD e impressoras — e, em Windows, removable media não é qualquer USB, e o Bluetooth fica fora (cortar por conteúdo lá é a Endpoint DLP — e o Device Control de Bluetooth é do macOS). Define acesso por dispositivo, tipo de dispositivo, operação (leitura, escrita, execução), grupo de utilizadores ou localização de rede, com relatórios e advanced hunting integrados.
  3. Endpoint DLP: camada de conteúdo — monitoriza informação sensível nos dispositivos onboarded e aplica acções de protecção sobre onde os ficheiros são guardados ou usados.

O Device Control do Defender for Endpoint é a camada central deste artigo. As outras duas servem de complemento: a primeira para requisitos básicos de instalação, a segunda quando o objectivo é o conteúdo que sai, não o dispositivo que entra.

Antes de começar: requisitos e estado inicial

O Device Control do Defender for Endpoint aplica-se a dispositivos onboarded no serviço. Três factos do estado inicial que apanham muitos administradores desprevenidos:

  • Não é para servidores — a Microsoft suporta o Device Control em Windows 10/11 com o cliente antimalware 4.18.2103.3 ou superior. Em Windows Server não é suportado — aí resta a camada ADMX (device installation restrictions).
  • Por omissão, o Device Control está desactivado e não há restrições a nenhum periférico.
  • A auditoria de eventos básicos de device control está activa para dispositivos onboarded, visível no device control report — mesmo sem qualquer política aplicada.
  • O estado mostra-se em Get-MpComputerStatus: os campos DeviceControlState, DeviceControlDefaultEnforcement e DeviceControlPoliciesLastUpdated dizem em segundos se a política chegou à máquina.

Get-MpComputerStatus | Select-Object DeviceControlState,
    DeviceControlDefaultEnforcement, DeviceControlPoliciesLastUpdated

O modelo: grupos, regras e entradas

O Device Control funciona com políticas compostas por grupos (que identificam dispositivos por propriedades) e regras (que concedem ou negam permissões a esses grupos, opcionalmente com condições sobre utilizadores).

Propriedades de dispositivo mais usadas para formar grupos:

Propriedade Identifica Uso típico
PrimaryId Tipo de dispositivo (RemovableMediaDevices, WPD, Printers…) Políticas por família
VID_PID Vendor ID (4 dígitos, USB-IF) e Product ID do fabricante Autorizar um modelo de pen/drive
FriendlyNameId Nome amigável do Device Manager Nomear dispositivos específicos
SerialNumberId Número de série do dispositivo Autorizar unidades concretas
InstancePathId Caminho de instância único Identificador mais específico

⚠️ Atenção

As propriedades diferem por plataforma — FriendlyNameId, por exemplo, só se aplica a dispositivos Windows e impressoras, não a Mac. Na dúvida sobre o valor exacto de um dispositivo, o device control report e o advanced hunting mostram as propriedades de tudo o que já foi ligado.

As entradas das regras têm duas naturezas: de enforcement (Allow/Deny) e de auditoria (AuditAllow/AuditDeny). As entradas de enforcement avaliam-se por ordem até que todas as permissões pedidas fiquem correspondidas — depois seguem-se as de auditoria.

Avaliação sem correspondência: se nenhuma entrada corresponde a uma regra, aplica-se o enforcement por omissão. Em Intune, o parâmetro DefaultEnforcement define esse comportamento: 1 = Allow por omissão, 2 = Deny por omissão.

⚠️ Atenção

se configurar apenas políticas de auditoria, as permissões herdam o enforcement por omissão — sem uma regra Allow/Deny ao lado, o resultado pode surpreender. A documentação aconselha adicionar uma política Allow ou Deny quando se adiciona uma política de auditoria.

Cenário 1: negar todo o armazenamento amovível (com auditoria e notificação)

A política mínima de arranque: um grupo “All removable media devices” + uma regra Deny com AuditDeny — o evento chega ao portal. A notificação ao utilizador, essa, só chega se a regra a trouxer (ver à frente).

Em Intune, o perfil recomendado pela Microsoft é o Device control do endpoint security (Devices > Configuration profiles). Em perfil personalizado (OMA-URI), o mínimo para o default deny:

  • ./Vendor/MSFT/Defender/Configuration/DeviceControlEnabled = 1
  • ./Vendor/MSFT/Defender/Configuration/DefaultEnforcement = 2 (Deny)
  • ./Vendor/MSFT/Defender/Configuration/SecuredDevicesConfiguration = RemovableMediaDevices (famílias separadas por |, sem espaços)

Em GPO, os grupos e regras definem-se em definições XML separadas na árvore de Device Control do Microsoft Defender Antivirus .

Nota sobre os assistentes: as políticas criadas no portal Defender são o perfil Device control do endpoint security e aplicam-se a dispositivos inscritos no Intune — não geram XML para GPO. Para GPO, a Microsoft remete para os samples do repositório mdatp-devicecontrol no GitHub e para a validação local com MpCmdRun -DeviceControl -TestPolicyXml antes de distribuir.

Verificação na máquina:


Get-MpComputerStatus | Select-Object DeviceControlState,
    DeviceControlDefaultEnforcement
# DeviceControlDefaultEnforcement : DefaultDeny
# DeviceControlState : Enabled

Ao reinserir a pen, o acesso é negado — mas, com só os três OMA-URI acima, é o default deny silencioso: sem grupo e regra com Notification configurados, o utilizador não vê mensagem nenhuma — a notificação vive na regra, não no enforcement por omissão. O evento RemovableStoragePolicyTriggered surge no advanced hunting (até 300 eventos por dispositivo por dia).

Cenário 2: negar tudo, excepto as USB autorizadas

O padrão clássico de PME: bloquear todos o armazenamento amovível e abrir excepção para as pens da empresa. Constrói-se com dois grupos:

  1. Grupo All removable media devices ( PrimaryId ) — a política Deny base, com o grupo dos autorizados excluído.
  2. Grupo Authorized USBs — dispositivos identificados por InstancePathId (ou VID_PID/SerialNumberId) com uma regra Allow.

Dois pormenores que evitam horas de diagnóstico:

  • As políticas não se avaliam por ordem — cada política tem de estar correcta independentemente das outras. A exclusão do grupo autorizado da política deny-all é o que garante a avaliação das restantes.
  • Para encontrar os valores (InstancePathId, VID_PID), use o Device Manager ou o device control report — a pergunta “que valores tem esta pen?” responde-se com dados reais, não por adivinha.

Cenário 3: leitura sim, escrita não (a pen do utilizador)

Grupo Read Only USBs por VID_PID + regra com permissão de leitura apenas: o utilizador copia para fora (risco controlado pela DLP, ver em baixo), mas nada entra na rede de origem desconhecida.

Para um contraste mais rígido: só dispositivos encriptados com BitLocker podem escrever — a política Allow com a condição de BitLocker deixa as pens caseiras em escrita bloqueada e as corporativas a escrever. A documentação tem este cenário entre os exemplos (“Allow users to install and use only BitLocker-encrypted devices”) mas marca-o como Preview (a condição por estado de encriptação, DeviceEncryptionStateId).

Cenário 4: por utilizador ou grupo (condições SID)

As regras aceitam condições sobre o utilizador — identificado por SID (o genérico S-1-1-0 = todos). Exemplos: a pen autorizada só é escrita pelo SID User1 — a de leitura, pelo User2 ou por qualquer membro de um grupo.

⚠️ Atenção

para grupos em Microsoft Entra, usa-se o object id do grupo em vez do SID. Duas condições práticas: as condições por utilizador precisam de acesso não interactivo ao Microsoft Graph (uma Conditional Access interactiva pode impedir a correspondência) e não se misturam com o targeting de grupos do Intune — a atribuição da política já faz esse trabalho.

Ver eventos: relatório e advanced hunting

O device control report (portal Defender, Reports → Device control) resume a actividade de armazenamento amovível e de impressoras por política. Para investigação, o advanced hunting:


DeviceEvents
| where ActionType == "RemovableStoragePolicyTriggered"
| extend parsed=parse_json(AdditionalFields)
| extend RemovableStorageAccess = tostring(parsed.RemovableStorageAccess)
| extend MediaName = tostring(parsed.MediaName)
| extend MediaProductId = tostring(parsed.ProductId)
| extend MediaVendorId = tostring(parsed.VendorId)
| extend MediaSerialNumber = tostring(parsed.SerialNumber)
| extend RemovableStoragePolicyVerdict = tostring(parsed.RemovableStoragePolicyVerdict)
| project Timestamp, DeviceId, DeviceName, RemovableStorageAccess,
    RemovableStoragePolicyVerdict, MediaName, MediaProductId,
    MediaVendorId, MediaSerialNumber
| order by Timestamp desc

Para inventário de periféricos antes de escrever políticas (que dispositivos existem na frota?), o evento PnpDeviceConnected:


DeviceEvents
| where ActionType == "PnpDeviceConnected"
| extend parsed=parse_json(AdditionalFields)
| extend MediaClass = tostring(parsed.ClassName)
| extend MediaDeviceId = tostring(parsed.DeviceId)
| project Timestamp, DeviceId, DeviceName, MediaClass, MediaDeviceId,
    tostring(parsed.DeviceDescription), tostring(parsed.SerialNumber)
| order by Timestamp desc

Device installation settings: a camada ADMX

Para requisitos simples — “nenhum USB de armazenamento é instalado aqui” — o controlo de instalação de dispositivos do Windows resolve sem Defender: com Intune (templates ADMX) ou GPO. As classes de dispositivos usam GUIDs de setup class e as políticas Device installation restrictions bloqueiam a instalação por classe ou por ID de hardware.

As políticas ADMX de Removable Storage Access (ficheiro RemovableStorage.admx) vão mais longe: negam leitura/escrita/execução por classe de dispositivo — CD/DVD, WPD, discos amovíveis — com aplicações sobre unidades de utilizador e máquinas.

Como complemento, o BitLocker resolve a metade do risco que fica: exigir encriptação para escrita em meios amovíveis, gerido em Intune pelas políticas de disk encryption.

Quando entra a Endpoint DLP

O Device Control decide por dispositivo e a DLP decide por conteúdo. Se o objectivo é “a pen corporativa pode ser escrita, mas não com cartões de clientes”, a política DLP com as condições de informação sensível é o que falta no enquadramento — as duas camadas desenham-se juntas, e o Device Control report mostra a actividade de dispositivos que a DLP também monitoriza.

Erros Comuns

Achar que instalar o Defender resolve o controlo USB — por omissão o Device Control está desactivado e sem restrições. Sem política aplicada, a única coisa que o sistema faz é auditar a ligação de dispositivos onboarded.

Só políticas de auditoria, sem Allow/Deny — as permissões herdam o enforcement por omissão: em DefaultEnforcement=1, o resultado de uma política de auditoria isolada é acesso total com alertas — o oposto do pretendido.

VID_PID copiado — um VID_PID copiado de outro ambiente autoriza modelos diferentes, por isso os IDs obtêm-se da frota real (report ou advanced hunting) antes de as políticas saírem de teste.

Políticas que se sobrepõem — Intune não preserva a ordem de políticas para avaliação e a documentação recomenda políticas Allow/Deny sem intersecção, com exclusões explícitas — não por ordem de chegada.

Negar sem notificar — um Deny sem AuditDeny correspondente deixa o utilizador sem entender o que se passa e o helpdesk com o bilhete sem informação. A par (enforcement + auditoria) é o padrão do walkthrough oficial.

Checklist

  • [ ] Inventário de dispositivos existentes (PnpDeviceConnected) antes de escrever políticas
  • [ ] Get-MpComputerStatus a confirmar DeviceControlState = Enabled e DeviceControlDefaultEnforcement correcto nas máquinas de teste
  • [ ] Políticas com par (enforcement, auditoria) — nunca só auditoria
  • [ ] Grupos sem intersecção e exclusões explícitas em vez de ordem de política
  • [ ] 300 eventos/dispositivo/dia no advanced hunting — não usar como SIEM
  • [ ] BitLocker para escrita em removível — em Preview, quando o enquadramento é corporativo
  • [ ] Excepções por InstancePathId/VID_PID documentadas numa folha de autorizações

Artigos Relacionados

Fontes Oficiais

  1. Device control in Microsoft Defender for Endpoint (Microsoft Learn)
  2. Configure device control in Microsoft Defender for Endpoint (Microsoft Learn)
  3. Device control policies in Microsoft Defender for Endpoint (Microsoft Learn)
  4. View device control reports and events (Microsoft Learn)
  5. Walkthroughs: see device control in action (Microsoft Learn)
  6. Policy CSP – ADMX_RemovableStorage (Microsoft Learn)