Tema De Dds Segurança

Configurando segurança DDS na prática

O tema de dds segurança envolve configurar autenticação, autorização e criptografia no middleware DDS para comunicações em tempo real. A especificação DDS Security v1.2 define os mecanismos padrão, mas a implementação varia entre provedores como OpenDDS, Connext e Fast DDS. A maior parte dos problemas que vejo acontecer não está na teoria da especificação, mas na configuração dos credenciais e políticas no domínio. Cada domínio DDS tem um identificador numérico. Se dois sistemas usarem o mesmo domain ID sem autenticação configurada, eles se conectam automaticamente e trocam dados sem ninguém perceber. Isso já vi acontecer em ambientes industriais onde o time de OT e o time de TI configuraram sensores no mesmo domínio por acidente. O resultado foi tráfego não autorizado fluindo entre redes que deveriam ser isoladas.

O que é preciso para ativar o tema de dds segurança em um projeto

Você precisa de três coisas principais: credenciais digitais (certificados e chaves), uma política de segurança aplicada ao DomainParticipant, e um plugin de segurança instalado no provedor DDS que está usando. Sem essas três partes, a camada de segurança simplesmente não entra em vigor, mesmo que você configure propriedades no código. O processo típico começa com a geração de um par de certificados. Cada participante no sistema DDS precisa do seu próprio certificado X.509 e da sua chave privada. A autoridade certificadora pode ser uma CA interna ou um perfil self-signed para testes. Em produção, o ideal é usar uma PKI existente da organização. Eu já configurei ambientes onde cada dispositivo IoT tinha seu certificado gerado individualmente, e o processo de provisionamento levava cerca de 4 horas para um lote de 200 dispositivos quando você inclui a validação cruzada dos certificados na configuração do plugin DDS Security. Depois dos certificados prontos, você aplica as políticas. As políticas mais usadas são:

• ACCESS_CONTROL — define quem pode publicar e quem pode assinar nos tópicos
• TRANSPORT_SECURITY — habilita TLS para o transporte UDP ou TCP
• CREDENTIAL_DISCOVERY — controla como os participantes trocam certificados durante o discovery
• BUILTIN_ENDPOINT_SECURITY — protege os endpoints de Discovery e Participation Announcements

Um detalhe que muitos ignoram: o DDS Security não protege apenas os dados que trafegam nos tópicos. Ele também protege os mensagens de discovery. Se você habilitar segurança mas não configurar corretamente os built-in endpoints, um atacante pode se passar por um participant legítimo apenas sniffando e replayando as mensagens de Discovery, mesmo sem conseguir decifrar o tráfego do tópico. O OpenDDS tem suporte a DDS Security desde a versão 3.11, mas a implementação tem limitações. O plugin de segurança do OpenDDS usa OpenSSL internamente, então a compatibilidade com formatos de certificado depende da versão do OpenSSL compilada na sua instalação. Já o RTI Connext tem suporte nativo completo à especificação v1.2, com ferramentas gráficas para geração de perfis de segurança (XML-based security profiles). O Fast DDS da eProsima também oferece suporte, mas em versões anteriores à 2.14 algumas funcionalidades de RBAC (Role-Based Access Control) ainda tinham bugs conhecidos em cenários de multicast. Para downloads e instalação, o OpenDDS está disponível em ociweb.com/products/opendds. O Connext possui versão de avaliação em rti.com/get-started. O Fast DDS pode ser baixado em github.com/eProsima/Fast-DDS.

Problema real que encontrei e como resolvi

Em um projeto de monitoramento industrial, tínhamos nove sensores e um servidor central, todos usando OpenDDS com DDS Security habilitado. Os certificados estavam configurados corretamente, as políticas de acesso pareciam certas no XML. Mas um dos sensores conseguia acessar tópicos para os quais não deveria ter permissão. O log do plugin de segurança mostrava DENY, mas o dados continuavam chegando. O problema era que o DDS Security v1.2 faz a verificação de acesso em dois momentos: durante o negotiation dos endpoints e durante o delivery efetivo das amostras. Quando o sensor se conectava pelo Discovery, a primeira verificação passou porque o endpoint de Discovery é compartilhado. A segunda verificação, a de delivery, estava sendo pulada porque o QoS PROPERTY policy do participante não incluía o nome correto do plugin. A propriedade precisa ser declarada explicitamente como dds.security.plugin.security_access_check e apontar para a extensão correta do plugin. Depois de adicionar essa propriedade ao XML de configuração de cada participante, o acesso indevido parou imediatamente. Essa falha é documentada em issue trackers do OpenDDS mas raramente mencionada em tutoriais. O comportamento é particularmente traiçoeiro porque os logs indicam que a segurança está ativa, mas a verificação em tempo de delivery simplesmente não ocorre sem essa propriedade.

Limitações e cenários onde DDS Security não resolve

O tema de dds segurança cobre autenticação, integridade e confidencialidade, mas não protege contra todos os vetores de ataque. DDS Security não oferece proteção contra replay attacks de forma nativa na v1.2 — você precisa implementar mecanismos adicionais no nível da aplicação. Também não há proteção contra side-channel attacks no throughput ou timing de transmissão. Se o padrão de tráfego dos seus dados sensíveis revela informações (como frequência de leitura de sensores de presença), a criptografia não esconde esse padrão. Outro ponto importante: o overhead de performance. Habilitar criptografia AES-128-CBC com autenticação HMAC-SHA-256 adiciona tipicamente entre 15% e 30% de latência extra dependendo da carga e do hardware. Em sistemas com requisitos de sub-milissegundo, isso pode ser significativo. Para cenários assim, uma alternativa é usar DDS Security apenas para o controle de acesso e confiar em IPSec ou VLANs para a criptografia de transporte. Essa abordagem híbrida é mais comum em infraestruturas industriais maduras. Se você precisa de proteção avançada contra replay, consideraria implementar sequência de mensagens com timestamps assinados na camada de aplicação, ou migrar para DDS Security v1.3 que inclui melhorias nessa área. Ainda não vi muitas implementações comerciais em produção usando v1.3 completamente, então há um custo de maturidade a considerar se optar por essa rota.