Cibersegurança em Sistemas AV-over-IP: VLAN, Autenticação, Hardening e o Que Sua Área de SI Vai Exigir

A migração de matrizes HDMI/SDI para AV-over-IP trouxe ganhos operacionais relevantes — flexibilidade, escalabilidade, redução de cabeamento — mas também colocou os equipamentos audiovisuais no mesmo plano de risco que servidores, switches e câmeras de CFTV. Em órgãos públicos federais, isso significa que o projeto precisa atender aos requisitos da área de Segurança da Informação (SI) antes da homologação — e, cada vez mais, antes mesmo da licitação, no termo de referência.

Este artigo organiza o que tem se mostrado essencial em projetos submetidos a assessorias de segurança, equipes de redes e auditorias de conformidade: onde o AV expõe a rede, quais controles resolvem cada exposição e como transformar isso em exigência contratual.

Superfície de ataque de um sistema AV moderno

Antes de proteger, é necessário enxergar. Um sistema AV-over-IP típico expõe múltiplos pontos, e boa parte deles não aparece no inventário de TI porque foi comprada e instalada como "equipamento de sala", não como ativo de rede.

Pontos de exposição comuns

• Encoders e decoders de vídeo — interfaces web para configuração e diagnóstico;
• Processadores de DSP — interfaces de programação e controle remoto;
• Controladoras de automação — APIs e portas de programação;
• Touch panels e displays interativos — sistemas operacionais embarcados (Android, Linux);
• Câmeras IP — alvo histórico de exploits de firmware;
• Servidores de gravação e streaming — armazenam conteúdo potencialmente sensível;
• Estações de gerenciamento — Windows ou Linux, frequentemente esquecidas em ciclos de patch.

Modelo de ameaças: quem ataca e o que busca

Três perfis de ameaça cobrem a maior parte dos cenários relevantes para um órgão público:

• Oportunista automatizado — varreduras em massa procurando serviços expostos com credencial padrão. Não escolhe o alvo; encontra o que estiver acessível. É o perfil que transforma um decoder esquecido em nó de botnet.
• Interno ou com acesso físico — visitante, prestador ou servidor com acesso à sala. A porta de rede atrás do display, a USB do touch panel e o console serial da controladora são vetores que a TI raramente enxerga, porque estão do lado "de dentro" do perímetro.
• Dirigido — interessado no conteúdo: reuniões de diretoria, sessões de julgamento, salas de crise. O alvo é o microfone, a câmera e o servidor de gravação; o equipamento AV é apenas o caminho.

Cada perfil pede controles diferentes. Senha forte e patch resolvem o primeiro; controle de porta e segmentação, o segundo; criptografia, logs e gestão de gravações, o terceiro. Um projeto que só trata o primeiro perfil passa na varredura de vulnerabilidades e falha na auditoria.

Segmentação — VLAN, firewall e ACL

A primeira camada de defesa é arquitetura de rede. O desenho da rede para AV-over-IP precisa nascer com a segmentação prevista, não recebê-la depois: mover equipamentos de VLAN após a instalação implica reendereçamento, reconfiguração de multicast e nova homologação.

VLAN dedicada para AV

Equipamentos AV-over-IP devem residir em VLAN(s) dedicada(s), separada da rede corporativa de usuários. Em cenários mais maduros, separa-se também por função: VLAN para distribuição de vídeo, VLAN para controle/automação, VLAN para gerenciamento. Isso limita o raio de impacto (blast radius) de um equipamento comprometido: quem alcança o fluxo de mídia não alcança, automaticamente, a interface de configuração.

Firewall entre VLANs

Tráfego entre a VLAN de AV e a VLAN corporativa atravessa firewall com regras explícitas. Necessidades comuns: serviços de calendário, autenticação (AD/LDAP/RADIUS), NTP, DNS, atualizações de firmware e, quando aplicável, a plataforma de videoconferência. Tudo o mais é bloqueado por padrão (default-deny). Cada regra liberada deve ter dono, justificativa e data de revisão — sem isso, o firewall vira uma lista que só cresce.

ACLs em switches

Em ambientes onde múltiplos equipamentos AV compartilham VLAN, ACLs em switches limitam a comunicação lateral. Um touch panel não precisa falar com um encoder — apenas com a controladora. Mapeiam-se os fluxos legítimos por classe de equipamento e nega-se o restante dentro da própria VLAN.

Controle de acesso na porta física

Sala de reunião é espaço semipúblico. A porta de rede atrás do display ou embaixo da mesa precisa ser tratada como não confiável: autenticação 802.1X (ou autenticação por endereço MAC para equipamentos que não suportam suplicante), port security limitando endereços por porta, portas ociosas desabilitadas administrativamente e negociação de trunk desligada em portas de acesso. Um notebook conectado na porta do encoder não pode herdar a VLAN de gerenciamento.

Multicast e IGMP snooping

AV-over-IP usa intensivamente multicast. Switches devem ter IGMP snooping habilitado, querier configurado e mecanismos de proteção contra tempestades de tráfego (storms). Sem isso, o tráfego de vídeo pode degradar a rede como um todo. Do ponto de vista de segurança, uma tempestade de multicast mal contida é um ataque de negação de serviço acidental — com o mesmo efeito de um proposital.

Autenticação e gestão de identidades

Senha padrão de fábrica é o vetor mais explorado em equipamentos embarcados. Em um parque AV, o problema é multiplicado pela quantidade: dezenas de decoders, painéis e câmeras, cada um com sua interface e sua credencial.

Padrões mínimos

• Senhas padrão alteradas em todos os equipamentos antes da homologação;
• Política de complexidade aplicável a AV — comprimento e composição definidos pela política de senhas do órgão, sem exceção para "equipamento de sala";
• Contas individuais por usuário — sem usuário "admin" compartilhado entre técnicos;
• RADIUS ou LDAP integrado, quando o equipamento suporta — autenticação centralizada com AD;
• Segundo fator de autenticação (2FA) em painéis de gestão críticos.

Gestão de credenciais técnicas

Credenciais de programação (ferramentas de configuração da controladora, do DSP e da distribuição de vídeo) precisam de cofre. Senha em planilha compartilhada é incidente esperando para acontecer. O padrão esperado é um cofre de senhas corporativo, com registro de quem consultou cada credencial e quando — e rotação obrigatória na troca de integrador ou de técnico responsável.

Acesso remoto do integrador

Suporte remoto é legítimo e necessário; acesso remoto permanente sem governança, não. O caminho aceito por áreas de SI é VPN do órgão com conta nominal para o técnico do integrador, janela de acesso aprovada por chamado e registro da sessão. Ferramenta de acesso remoto instalada pelo integrador na estação de gerenciamento, fora do controle da TI, costuma ser o primeiro item reprovado em auditoria.

Hardening por plataforma

Cada ecossistema tem suas particularidades. Resumo do que tem aparecido em homologações de SI — os fabricantes publicam guias de hardening próprios, e a versão vigente desse guia deve ser exigida como referência na entrega.

Crestron

• Ferramenta de configuração e SSH com chave assimétrica, não senha;
• HTTPS com certificado válido (não autoassinado em produção);
• Console serial protegido fisicamente;
• Firmware em versão suportada pelo fabricante, com prazo residual de suporte documentado;
• Autenticação RADIUS/AD habilitada nos processadores;
• Plataformas de gerenciamento e nuvem do fabricante com hardening específico — auditoria de quem acessa.

Q-SYS

• Software de design com login obrigatório no Core;
• SSL/TLS habilitado em todas as conexões de gerenciamento;
• Plataforma de gerenciamento com controle de acesso granular — diferentes papéis para diferentes usuários;
• Atualizações do software de design e do firmware do Core sincronizadas.

Extron

• Plataforma de gerenciamento com autenticação centralizada;
• HTTPS habilitado, TLS 1.2 mínimo;
• Telnet desabilitado (legado, sem criptografia);
• Hardening de processadores de controle — desativação de serviços não usados.

Câmeras e displays

• Câmeras IP — desabilitar UPnP e descoberta ONVIF quando não necessários;
• Displays profissionais com SoC Android — patch de segurança aplicado periodicamente, sandbox de apps;
• Sistemas com Linux embarcado — auditoria de pacotes instalados.

Princípios comuns a qualquer fabricante

Independentemente da marca, a lista de verificação converge: serviços não utilizados desabilitados (Telnet, FTP, HTTP sem TLS, descoberta automática), interface de gerenciamento acessível apenas pela VLAN de gerenciamento, certificados emitidos pela autoridade certificadora do órgão, aviso legal na tela de login, tempo de sessão limitado e recursos de nuvem do fabricante avaliados pela SI antes de serem habilitados — não depois.

Criptografia: conteúdo em trânsito e em repouso

Segmentação limita quem alcança o tráfego; criptografia protege o que trafega. Em AV, os dois são confundidos com frequência, e um terceiro conceito piora a confusão: HDCP protege conteúdo comercial contra cópia no enlace entre fonte e display; não foi concebido para garantir a confidencialidade de uma reunião. Se o fluxo entre encoder e decoder trafega cifrado ou não pela rede depende dos recursos de criptografia da plataforma escolhida e de sua configuração — e não deve ser presumido só porque os equipamentos suportam HDCP.

Mídia em trânsito

Nem todo protocolo de AV-over-IP criptografa o fluxo de vídeo e áudio; alguns oferecem criptografia opcional, outros dependem inteiramente da segmentação para garantir confidencialidade. Antes de transportar conteúdo sensível por infraestrutura compartilhada, verifique o comportamento real da plataforma escolhida — inclusive nos protocolos de áudio em rede, cuja comparação entre Dante, AES67 e AVB mostra diferenças relevantes de arquitetura. Canais de controle e gerenciamento (HTTPS, SSH, APIs) devem ser criptografados sem exceção.

Gravações e dados pessoais

Servidores de gravação e streaming armazenam voz, imagem e, frequentemente, deliberações. Isso é dado pessoal — e às vezes dado sensível — nos termos da LGPD (Lei 13.709/2018). Criptografia em repouso, política de retenção com prazo definido, controle de acesso por papel e trilha de auditoria de quem assistiu ou baixou cada gravação são requisitos que a área de SI vai cobrar em conjunto com o encarregado de dados. O tema tem desdobramentos próprios, tratados no guia sobre LGPD em sistemas audiovisuais.

Atualização de firmware com governança

Firmware desatualizado é vulnerabilidade conhecida — e auditável. Ninguém precisa de ataque sofisticado quando a versão instalada tem falha publicada há meses. O tema merece o guia próprio sobre firmware e atualizações em sistemas AV; aqui, o recorte de segurança.

Boas práticas mínimas

• Inventário de equipamentos e versões em uso;
• Classificação das atualizações — correção crítica de segurança fora da cadência, funcionalidade dentro da janela regular;
• Janela de manutenção planejada — fora do horário operacional;
• Procedimento de rollback documentado;
• Validação em ambiente de homologação antes de produção, quando viável;
• Subscrição a alertas de segurança dos fabricantes;
• Registro de cada atualização como mudança, com aprovação e evidência de resultado.

O conflito com garantia e suporte

Uma armadilha recorrente: o contrato de manutenção ou a garantia do fabricante condiciona o suporte a versões homologadas, enquanto a equipe de SI exige a correção mais recente. A solução é contratual — a obrigação de manter o firmware em versão suportada e sem vulnerabilidades críticas conhecidas deve constar do contrato de serviços técnicos e manutenção, com prazo para aplicação após a publicação da correção pelo fabricante. Sem essa cláusula, o órgão fica preso entre a garantia e a auditoria.

Auditoria, logs e SIEM

Sem registro, não há detecção. Em contratos federais, a integração com o SIEM corporativo tem deixado de ser diferencial para virar requisito recorrente — sobretudo em órgãos que operam um Centro de Operações de Segurança, cujas fronteiras com o NOC e com o centro de operações estão detalhadas no comparativo entre NOC, SOC e COP.

Logs essenciais

• Acessos administrativos (quem entrou, quando, de onde);
• Mudanças de configuração;
• Eventos de falha e recuperação;
• Tentativas de autenticação falhadas;
• Eventos de rede anômalos (varreduras, conexões inesperadas).

Encaminhamento para SIEM

Equipamentos AV modernos suportam syslog. A integração com o SIEM corporativo deve ser parte do escopo de implantação, não retrofit: definir quais eventos são enviados, em qual formato, com relógio sincronizado por NTP e com regras de correlação mínimas (tentativas de login falhas em sequência, alteração de configuração fora de janela, novo endereço na VLAN de AV). Monitoramento remoto e segurança operam melhor juntos: a mesma telemetria que indica falha de equipamento indica comportamento anômalo.

Cenário hipotético: 40 salas e um centro de operações

Imagine um órgão com 40 salas de reunião equipadas com AV-over-IP, um auditório com gravação e um centro de operações com videowall — tudo entregue por um único contrato, dois anos atrás, sem exigência de segurança no termo de referência. O que uma avaliação de postura tipicamente encontra:

• VLAN "dedicada" de AV roteada sem firewall para a rede corporativa — segmentação apenas nominal;
• Credencial padrão remanescente em parte dos decoders e nos displays de áreas comuns, porque "só mostram sinalização";
• Estação de gerenciamento com ferramenta de acesso remoto do integrador ativa desde a implantação;
• Gravações do auditório acessíveis por compartilhamento de rede, sem controle por papel;
• Firmware na versão de fábrica, porque atualizar "poderia quebrar a programação".

A correção, em ordem de prioridade: fechar o acesso remoto não governado e trocar todas as credenciais (dias); inserir firewall entre VLANs com regras mínimas e desabilitar portas ociosas (semanas); atualizar firmware em janelas planejadas com rollback (um ciclo trimestral); integrar logs ao SIEM e formalizar a gestão de gravações (junto com a renovação do contrato de manutenção). Nada disso exige trocar equipamento — exige a governança que deveria ter nascido no edital.

Erros comuns que reprovam a homologação

• Gerenciamento na mesma VLAN da mídia — quem acessa o fluxo de vídeo alcança a interface de configuração;
• Certificado autoassinado em produção — treina o usuário a ignorar avisos de segurança;
• Conta "admin" compartilhada pela equipe — nenhum log responde "quem";
• As-built sem mapa lógico de rede — a SI não consegue validar o que não consegue ver;
• Recursos de nuvem do fabricante habilitados por padrão — telemetria e controle saindo do órgão sem análise de risco;
• Displays de sinalização tratados como "não críticos" — mesmo SoC, mesma rede, mesmo risco;
• Teste de vulnerabilidade só depois do recebimento definitivo — quando já não há alavanca contratual.

Cibersegurança no termo de referência

Para o gestor público, o caminho mais eficaz é exigir desde o edital. Itens que têm passado em auditorias:

• Política de hardening documentada por equipamento;
• Autenticação centralizada integrada ao AD do órgão;
• Plano de gestão de patches com cadência mínima trimestral;
• Encaminhamento de logs para SIEM corporativo;
• Inventário e mapa de rede entregues como parte do as-built;
• Teste de invasão ou avaliação de vulnerabilidades antes do recebimento definitivo;
• Cláusula de continuidade — quem responde em caso de vulnerabilidade crítica divulgada após a implantação.

Como exigir sem restringir a competição

Requisitos de segurança são funcionais, não de marca: "autenticação centralizada via LDAP ou RADIUS" é atendida por vários fabricantes; "integração nativa com o produto X" não. A técnica é a mesma de especificar sem marca: descrever o resultado verificável, referenciar normas e boas práticas reconhecidas (Lei 14.133/2021 para o processo; ISO/IEC 27001 e a política de segurança do próprio órgão para os controles) e definir a evidência que comprova o atendimento. O recebimento provisório e o definitivo devem prever a verificação: sem evidência, sem aceite.

Checklist de evidências para a homologação de SI

Em ambientes de missão crítica — salas de situação e um Centro de Operações que precisa funcionar sem interrupção — esses controles deixam de ser exigência de conformidade e passam a ser condição de disponibilidade: o mesmo equipamento comprometido que vaza informação é o que sai do ar na hora errada. Segurança e continuidade são o mesmo projeto.

Matheus Lourencatto — Engenharia Netfocus. Integração audiovisual para o governo federal desde 2009: 150+ projetos entregues em 50+ órgãos, SICAF ativo e SLA contratual de 4h. Fale com a engenharia →

Publicado em 18 Nov 2025 · Revisado em 22 Set 2026