Skip to main content

Rede GL One®: arquitetura de segurança e privacidade

Versão 12/05/2026

Este documento é a leitura pública da arquitetura de segurança e privacidade da Rede GL One®. Descreve decisões de design, modelo de ameaça, defesa em profundidade, limites e responsabilidade compartilhada, em linguagem técnica acessível a leitores corporativos, jurídicos e regulatórios. A especificação técnica detalhada, com primitivas criptográficas, formato de mensagens, esquema de provisionamento e parâmetros operacionais, não é distribuída em cópia. É disponibilizada para consulta presencial, em ambiente controlado, no escritório da GL One®, mediante NDA prévio, a clientes e parceiros com necessidade legítima de verificação.

I. Premissa arquitetural​

A Rede GL One® é uma rede colaborativa de coleta e telemetria industrial. Combina duas classes de nó. Sensores físicos, embarcados em equipamentos de campo (hidrômetros, medidores de energia, equipamentos de telemedição), operam por broadcast em rádio BLE. Nós lógicos, rodando como SDK dentro de aplicativos móveis parceiros, escutam o ambiente físico ao redor do aparelho do usuário, processam o resultado e o entregam à infraestrutura. A rede transporta dados operacionais cifrados entre essas duas pontas e disponibiliza medidas, eventos e contexto a clientes regulados (concessionárias de saneamento, energia, gás) e a operadores dos aplicativos parceiros.

A premissa arquitetural é explícita: segurança em rede é propriedade da arquitetura, não do protocolo de rádio ou transmissão. Toda tecnologia de telecomunicação (BLE, WiFi, fibra óptica, LoRa, NB-IoT, qualquer outra) carrega vulnerabilidades publicadas ou por publicar. Nenhuma garantia de segurança vive no meio físico. O que separa uma rede frágil de uma rede resiliente é a arquitetura que usa esse meio.

Essa premissa não é decorativa, é a base do projeto da Rede GL One®. A arquitetura descrita neste texto é resultado de avaliação cuidadosa do estado da arte em IoT industrial, mesh colaborativa e SDKs móveis, das suas decisões de projeto, das suas trade-offs documentadas e das suas falhas conhecidas. A Rede GL One® foi desenhada a partir das lições aprendidas com esse conjunto.

O restante do documento detalha essa arquitetura, em linguagem técnica, sem omitir limites. A seção II apresenta o modelo de ameaça. As seções III a VI descrevem as duas pontas da rede (sensor físico e SDK em aplicativo parceiro), a defesa em profundidade na criptografia e a minimização de dados pessoais. As seções VII a IX cobrem a conformidade em relação à privacidade e proteção de dados pessoais (LGPD) e regulatória (ANATEL). A seção X trata da operação contínua. A seção XI declara os limites do que se promete. A seção XII descreve a postura evolutiva.

II. Adversários e contenção​

A rede GL One® opera sob modelo de ameaça formal, mapeado em STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service e Elevation of Privilege. Para cada classe, decisões arquiteturais específicas reduzem ou eliminam superfície. As duas pontas da rede operam sob modelos distintos, detalhados em separado nas seções III (nó físico) e IV (nó lógico).

Os adversários considerados incluem atacante de rádio passivo (eavesdropping), atacante ativo de proximidade (injection, replay, jamming), atacante de rede com acesso a infraestrutura intermediária, aplicativo hospedeiro malicioso ou comprometido, aparelho de usuário infectado por malware, insider com acesso parcial a tenant e atacante de cadeia de suprimentos. O que explicitamente não defendemos é o sensor físico entregue a adversário com tempo e laboratório completo, nem o smartphone do usuário sob controle total de adversário (root, jailbreak malicioso, malware com privilégio de sistema). Esses cenários estão fora do escopo defensável pela camada de arquitetura aqui descrita. O que defendemos é que comprometer um sensor ou um aparelho de usuário não comprometa a Rede. Os limites desse escopo estão detalhados na seção XI.

Esse princípio, contenção de raio de impacto, é a base da arquitetura.

III. O nó físico: edge unidirecional e identidade criptográfica por dispositivo​

A camada de borda física da rede opera em transmissão unidirecional, em broadcast. O sensor anuncia o evento. Não há pareamento, não há autenticação interativa, não há canal de retorno do lado do dispositivo. A consequência é direta: as CVEs do Bluetooth geralmente citadas em análises superficiais (BlueBorne, KNOB, BLESA, BIAS, BLURtooth) dependem todas, sem exceção, de pareamento ativo ou de troca dinâmica de chaves. Em modo broadcast unidirecional, essas classes de ataque não têm vetor.

Essa decisão tem custo. Operações sobre o dispositivo (incluindo atualização de firmware e ajuste de configuração) exigem proximidade física ao sensor e procedimento de manutenção controlado. Não há canal remoto que opere a distância sobre a frota como um todo, nem broadcast capaz de mudar o comportamento dos sensores simultaneamente. O custo é aceito de propósito: elimina o vetor mais perigoso de IoT industrial, que é o atacante remoto capaz de tocar a frota inteira por um único caminho.

Cada sensor da rede recebe material criptográfico próprio em provisionamento de fábrica. Revogação é suportada e propagada à infraestrutura de validação quando necessária. Esse desenho responde a uma classe de problema conhecida em arquiteturas com chave compartilhada ou material criptográfico replicável entre dispositivos, em que a extração de um único equipamento expõe a frota inteira. A direção arquitetural da Rede GL One® é o isolamento criptográfico por dispositivo, garantindo que cada nó tenha credencial única não exportável.

Sob essa linha, o hardware dos sensores é selecionado entre famílias de microcontroladores com recursos de segurança em silício, e configurado em produção para tirar proveito desses recursos. Após o provisionamento criptográfico, a interface de depuração do chip é travada de forma irreversível, e a memória de programa é protegida contra leitura externa, o que impede a extração do firmware e das chaves por meio de ferramentas de bancada padrão.

Antes de propagar, o payload é cifrado e autenticado pelo dispositivo com material criptográfico próprio. A cifra protege a confidencialidade do conteúdo: captura passiva por adversário com receptor rende apenas pacote opaco. A autenticação protege a integridade e a origem: tentativas de injeção, replay ou alteração de pacote são rejeitadas pela infraestrutura de validação, porque não carregam assinatura válida da chave única daquele sensor.

O identificador que o dispositivo expõe ao ar é distinto do identificador lógico interno usado pela infraestrutura. Mesmo um observador que registre o endereço de rádio (MAC ou equivalente do enlace BLE) não obtém o identificador interno necessário para forjar uma leitura, nem o material criptográfico que a assinaria. Identidade física e identidade lógica estão desacopladas por desenho, na mesma linha da randomização de endereço BLE adotada por iOS e Android.

A consequência operacional é que comprometer um sensor isolado dá ao atacante apenas a capacidade de operar aquele sensor, e nada mais. Não há escalonamento horizontal. Não há acesso à rede. O raio de impacto é exatamente um dispositivo, e a revogação remove esse dispositivo da malha imediatamente.

IV. O nó lógico: SDK em aplicativo parceiro, adesão e sandbox​

O SDK GL One® é a outra ponta da rede colaborativa. Ele participa do mesmo ativo, mas opera sob restrições e modelo de ameaça completamente diferentes do sensor físico.

Adesão voluntária​

O SDK é embarcado em aplicativos de empresas parceiras, que analisam toda a documentação e funcionalidades e, por sua própria escolha, optam pela sua instalação e, consequentemente, são responsáveis por informar aos usuários sobre eventuais conexões com aplicativos ou SDK de terceiros. Os usuários do aplicativo aceitam os termos de uso no momento da instalação ou da ativação do recurso e concede, mediante ação positiva de aceite, permissões específicas (Bluetooth, localização, notificação) que permitem que o SDK rode. Não há instalação remota e nem cooptação de aparelho de terceiro.

A Rede GL One® cresce por adesão informada. Não há retransmissão involuntária de aparelhos cujo usuário não tenha instalado um aplicativo parceiro e aceito as permissões. Quando o usuário desinstala o aplicativo ou revoga as permissões no sistema operacional, o nó deixa de fazer parte da rede no momento seguinte. Adicionalmente, a GL One disponibiliza meio de "esquecer meu dispositivo" caso o usuário deseje não fazer mais parte da rede: https://www.grouplinkone.com/esqueca-dispositivo.

O que o SDK faz, e o que ele não faz​

O SDK opera dentro da sandbox (isolamento obrigatório) de aplicativo do sistema operacional, com as mesmas restrições e permissões que qualquer outro código de terceiro embarcado. Não tem acesso elevado. Não tem privilégio de sistema. Não executa fora do contexto do aplicativo hospedeiro.

A função do SDK é escutar passivamente broadcasts BLE no ambiente físico ao redor do dispositivo, processá-los localmente quando aplicável, e transmitir o resultado contextualizado para a infraestrutura da rede via canal seguro. O SDK não coleta dados do aplicativo hospedeiro. Não acessa contatos, mensagens, fotos, histórico de navegação ou qualquer conteúdo armazenado pelo usuário. Não modifica o comportamento de outros aplicativos. Não injeta código fora do seu próprio escopo.

Essa delimitação não é declaração de boa vontade. É uma restrição técnica imposta pela sandbox do sistema operacional, e auditável por engenharia reversa de qualquer pesquisador independente.

Distribuição, atualização e auditabilidade​

A distribuição do SDK acontece via repositórios de pacotes versionados, com hash criptográfico verificável. O código é integrado ao aplicativo parceiro durante o build, e passa pelos processos de revisão da App Store e do Google Play como qualquer outra dependência. Atualizações do SDK exigem rebuild e redistribuição do aplicativo hospedeiro, com novo processo de revisão. Não há mecanismo de atualização silenciosa do código do SDK em campo.

Essa propriedade tem custo (ciclo de atualização mais lento que injeção remota) e benefício (não existe vetor para forçar mudança de comportamento do SDK em massa sem passar pelo crivo do aplicativo parceiro e das app stores). É um dos principais elementos que sustentam a confiança de operadores de aplicativos parceiros e de equipes de segurança corporativas que avaliam o SDK antes da integração.

Autenticação e segregação por aplicativo​

Cada aplicativo parceiro que integra o SDK recebe credenciais próprias para se autenticar contra a infraestrutura GL One®. Tráfego de um aplicativo é isolado lógica e criptograficamente do tráfego de outro. SDK rodando em aplicativo A não compartilha estado, cache ou identificadores com SDK rodando em aplicativo B no mesmo aparelho. Não há identidade global de usuário entre aplicativos parceiros.

Comprometer um aplicativo parceiro não compromete os outros aplicativos parceiros da rede, e não dá ao atacante visibilidade da rede como um todo.

Defesas específicas do nó lógico​

Contra aplicativo hospedeiro malicioso, o SDK não expõe APIs sensíveis nem aceita comandos arbitrários do hospedeiro. Contra malware no aparelho, a comunicação com o backend é cifrada e autenticada por credenciais protegidas por mecanismos do sistema operacional (iOS ou Android).

Contra interceptação de rede, TLS 1.2 ou superior é obrigatório, reforçado por mutual TLS (mTLS): cliente e servidor se autenticam mutuamente por certificado, de forma que um atacante on-path (posicionado entre cliente e servidor para interceptar ou modificar a comunicação) não consegue se autenticar para nenhum dos lados, tornando o ataque praticamente inviável. Contra engenharia reversa, o SDK utiliza técnicas de ofuscação para que a inspeção do código binário não exponha segredos compartilhados nem revele estrutura útil para forjar tráfego em escala.

O raio de impacto de um nó lógico comprometido é, por desenho, um único aparelho de um único aplicativo. Não cascateia.

V. Defesa criptográfica em profundidade​

Defesa criptográfica em profundidade significa que cada salto entre dois pontos da rede tem proteção criptográfica própria, e que quebrar um salto não compromete os outros.

Defesa criptográfica em profundidade — quatro camadas independentes do sensor ao disco

Camada 1, dispositivo até SDK (rádio BLE). O pacote anunciado pelo sensor carrega duas cifras simultâneas, com propósitos diferentes. A cifra de transporte protege a integridade do quadro e a validação mínima do protocolo, com chave que rotaciona em janela curta nas partes públicas o suficiente para que o SDK confirme que o pacote pertence à rede sem precisar abrir o conteúdo. A cifra de payload protege o dado útil ponta a ponta, do dispositivo até a aplicação, e o SDK nunca a abre. Em outras palavras, o nó lógico funciona como repetidor cifrado: valida proveniência, encaminha conteúdo opaco.

Camada 2, SDK até cloud. O canal usa HTTPS sobre TLS 1.2 ou superior, reforçado por mutual TLS. O servidor exige certificado de cliente válido, emitido para aquele aplicativo parceiro, e o cliente exige certificado de servidor válido. Um atacante on-path posicionado entre SDK e cloud, mesmo com controle de rede intermediária, não consegue se autenticar para nenhum dos lados. O trade-off conhecido do mTLS aparece em redes corporativas com proxy de inspeção de tráfego: o mTLS, por desenho, impede que esse proxy estabeleça a conexão em nome do cliente, o que é justamente a propriedade que torna o ataque on-path inviável, e a operação em ambiente corporativo eventualmente mais complexa.

Camada 3, cloud interna. Entre microserviços, máquinas virtuais e componentes de plataforma, toda conexão usa HTTPS sobre TLS. Credenciais de cliente, chaves de API e segredos operacionais ficam em vault dedicado, com acesso auditado e rotação periódica, e nunca aparecem em código, repositório ou variável de ambiente em texto claro.

Camada 4, cloud até armazenamento físico. O armazenamento em repouso usa AES com chave única por disco rígido, gerenciada pelo provedor de nuvem. Importa explicitar o que isso significa em termos de modelo de ameaça: do ponto de vista da GL One®, o dado que entra no banco já chega decifrado pelo provedor na camada de bloco, e a segregação lógica entre clientes acontece na aplicação, não na chave de disco. Isso não enfraquece a postura: o vetor que a cifra de disco fecha é o roubo físico do hardware no datacenter, não o isolamento lógico entre tenants, que é garantido por outras camadas.

A consequência operacional é direta. Interceptação na camada de rádio entrega pacote opaco. Interceptação no caminho SDK até cloud falha na autenticação mútua. Interceptação dentro da cloud passa por TLS interno e por vault. Acesso físico ao hardware de armazenamento esbarra na cifra de disco. Quebrar uma camada não quebra as outras. Esse é o sentido literal de defesa em profundidade.

Esta seção descreve as quatro camadas em granularidade arquitetural, intencionalmente. A especificação detalhada das primitivas em uso (algoritmos, modos de operação, tamanhos de chave, janelas de rotação, formato de pacote, esquema de derivação, processo de provisionamento e de revogação) não é distribuída em cópia. É disponibilizada para consulta presencial, em ambiente controlado, no escritório da GL One®, mediante NDA prévio, a clientes e parceiros com necessidade legítima de verificação. Esse formato segue prática estabelecida em arquiteturas comparáveis, em que o whitepaper público sustenta o argumento de design e a especificação técnica fechada sustenta a verificação adversarial, sem que cópia do material saia do perímetro de controle da GL One®.

VI. Diretrizes de Privacidade e Proteção de Dados Pessoais na Rede GL One®​

O desenho da arquitetura da Rede GL One® foi desenvolvido para atender aos princípios e aos critérios estritos da legislação e regulamentação sobre o uso de dados pessoais, especialmente a Lei Geral de Proteção de Dados (LGPD).

A Rede GL One® foi desenvolvida de forma a não realizar a coleta e o processamento de dados pessoais identificáveis tais como nome, CPF, endereço, e-mail e número de telefone. Atendendo ao princípio da minimização, os dados que circulam pela camada de rádio transportam apenas o que é estritamente necessário para o funcionamento da Rede: um identificador opaco do equipamento e a métrica de interesse, ambos cifrados. Os dados são, assim, pseudonimizados na origem, não dispondo a GL One de mecanismos razoáveis para reverter a pseudonimização ou realizar qualquer cruzamento para reidentificação. Além disso, há um isolamento lógico e dissociação entre os atores da Rede - ou seja, cada ator do ecossistema acessa apenas a fração de dados correspondente às suas próprias atividades, não havendo um ponto único de agregação de dados.

Mesmo sem o tráfego de dados pessoais diretos, a GL atua preventivamente estabelecendo e revendo periodicamente o seu Programa de Privacidade que atende aos requisitos de frameworks internacionais tais como NIST e ISO 27701/2019.

Em seu Programa de Privacidade, estabelecido sob pilares de governança estratégicos, a GL atua no aculturamento de privacidade, definição de regras de tratamento de dados pessoais em políticas e normas internas, mapeamento do tratamento interno e externo de dados pessoais, gestão de terceiros e avaliações de iniciativas sob as metodologias de privacy by design e privacy by default.

A preocupação em relação às práticas de tratamento de dados pessoais foram objeto de estudos internos e externos1, que atestaram, por meio de análises técnicas e elaboração de Relatórios de Impacto à Proteção de Dados Pessoais (RIPDs), a regularidade da operação e das medidas mitigadoras necessárias para prevenir tratamentos indevidos e incidentes com dados pessoais.

Na arquitetura da Rede, os papéis dos agentes de tratamento são claramente definidos, de forma contextual. Nas atividades de manutenção e expansão da Rede, a GL atua como Controladora de Dados Pessoais, determinando finalidade, meios e a forma do tratamento. A base legal é o legítimo interesse (art. 7º, IX, LGPD), sustentado por teste de balanceamento que verifica a proporcionalidade entre o interesse lícito de viabilizar a infraestrutura da Rede e os direitos dos titulares. Já a contratante (a exemplo de concessionárias de serviços públicos), atua como Controladora de Dados Pessoais para seus próprios tratamentos de dados pessoais, que devem estar previstos de forma explícita e informada em suas políticas e avisos de privacidade.

A GL está, de forma contínua, estabelecendo e aprimorando suas práticas de tratamento de dados que buscam preservar a privacidade e proteção de dados pessoais, seja de seus clientes, colaboradores ou terceiros relacionados.

O titular de dados pessoais ou a Agência Nacional de Proteção de Dados (ANPD) podem contatar diretamente o Encarregado pela Proteção de Dados da GL pelo e-mail dpo@groulinkone.com. Para exercer a desconexão do dispositivo com a Rede GL®, basta acessar https://www.grouplinkone.com/esquecer-dispositivo e informar o device_ID.

VIII. Padrões formais e auditorias​

A postura técnica da rede é autoavaliada e progressivamente certificada contra os padrões internacionais aplicáveis. NIST Cybersecurity for IoT Program e a série NISTIR 8259 informam o baseline de fabricante e integrador. ETSI EN 303 645 cobre o perfil de IoT de consumo nas pontas que tocam aplicativos. OWASP IoT Top 10 e OWASP Mobile Top 10 são usados como checklists de vulnerabilidades de implementação nos nós físico e lógico, respectivamente. ISA/IEC 62443 endereça os contextos OT em saneamento, energia e gás, nos quais a rede opera junto a sistemas de controle industrial.

Essa postura não é declaração interna. Está exposta publicamente no trust center da GL One® em https://trust.grouplinkone.com, operado via Oneleet, com monitoramento contínuo de controles, evidências de auditoria, status de certificações em andamento e relatório de pen test disponível mediante NDA. O trust center é atualizado automaticamente conforme cada controle é verificado, o que substitui a foto estática típica de um certificado em PDF por estado vivo e verificável por qualquer cliente, parceiro ou pesquisador interessado.

Cada componente da rede tem um modelo de ameaça documentado e revisitado. Pen test externo é parte do ciclo, tanto da infraestrutura quanto do SDK distribuído em aplicativos parceiros. Disclosure responsável é o canal preferencial para qualquer pesquisador que identifique vulnerabilidade, com canal de reporte público disponível no próprio trust center. Quando uma falha for descoberta, ela será corrigida e comunicada. Esse compromisso é tão importante quanto a postura preventiva.

IX. Homologação ANATEL​

A operação dos sensores GL One® em território brasileiro está sob duas camadas regulatórias distintas da ANATEL, que precisam ser separadas para evitar a confusão recorrente em pareceres mal informados sobre IoT.

A primeira camada é o uso de espectro. Os sensores GL One® operam em Bluetooth Low Energy na faixa ISM de 2,4 GHz, classificada pela ANATEL como radiação restrita. Radiação restrita não exige outorga de operação nem licenciamento de espectro. É regime legal e plenamente regulamentado, idêntico ao das faixas não licenciadas usadas por LoRaWAN, Sigfox, ZigBee e Open Metering System, todas aceitas em editais públicos brasileiros de telemedição.

A segunda camada é a homologação de produto. Mesmo dispositivos de radiação restrita exigem certificação técnica e homologação ANATEL antes de comercialização ou operação em volume no Brasil. A homologação é emitida pela ANATEL a partir de Certificado de Conformidade Técnica (CCT) produzido por Organismo de Certificação Designado (OCD), e atesta conformidade com requisitos técnicos aplicáveis: limites de potência radiada, máscara de emissão, espurios, segurança elétrica, e marca de identificação visível no produto. O ciclo padrão de validade é de 24 meses, com renovação periódica.

A GL One® mantém portfólio homologado sob a categoria Transceptor de Radiação Restrita, registrado em nome de Group Link Network S.A. (CNPJ 10.664.687/0001-13). O status consolidado em consulta ANATEL de 07/05/2026 lista dez modelos vigentes em campo:

  • GL-MDV208 (NCC 26048/24)
  • GL-MLV202 (NCC 26938/24)
  • GL-MSV207 (NCC 26939/24)
  • GL-WGV210 (NCC 26990/24)
  • GL-EMV203P (NCC 27028/25)
  • GL-EMV203R (NCC 27028/25)
  • GL-WGV210XL (NCC 27117/25)
  • GL-MIV204 (NCC 27118/25)
  • GL-SLV203 (NCC 27138/25)
  • GL-SLV208 (NCC 28157/25)

Modelos de gerações anteriores (Safe Button SB01, GLPlug, GLTag, GLUtilities Energy, GLUtilities Water, GLUtilities Energy L3, GLStation, GL-WGV102, GL-WGV208) foram substituídos por produtos atuais e tiveram homologação encerrada por expiração do ciclo regulatório de 24 meses, conforme prática padrão. A descontinuação de homologação não representa irregularidade: representa o ciclo normal de evolução de portfólio em IoT industrial.

A engenharia de hardware mantém calendário ativo de renovação e ciclo de testes em câmara anecóica para validação de novas famílias, com coordenação técnica conduzida pelo departamento de Engenharia. Para produtos destinados a contextos de gás e atmosferas potencialmente explosivas, a certificação EX (Inmetro/IEC 60079) é complementar à homologação ANATEL, exigida operacionalmente pelos clientes do setor. O modelo GL-WGV210XL, por exemplo, é submetido a esse duplo regime.

A homologação ANATEL é instrumento regulatório obrigatório, não diferencial competitivo. Operar em volume no Brasil sem portfólio homologado é, por definição, operação irregular. O diferencial da Rede GL One® está nas camadas que vêm antes da homologação (arquitetura, segregação, criptografia por dispositivo, descritas nas seções III a V) e nas que vêm depois (operação contínua, evolução do portfólio, defesa em profundidade, descritas nas seções X e XI). A homologação atesta o cumprimento do mínimo regulatório. O restante deste documento descreve o que está acima do mínimo.

X. Operação segura​

Segurança não termina no design, continua na operação. A rede roda sob práticas formais de Site Reliability Engineering, com SLIs e SLOs definidos para os serviços críticos, error budgets explícitos, gestão de incidentes documentada e postmortem sem culpa após cada evento relevante. Não é improvisação. É uma infraestrutura que precisa atender SLA contratual de cliente regulado de grande porte.

A topologia é distribuída, com presença em mais de uma região, para resiliência geográfica e independência de provedor único. Backups são automáticos, criptografados e testados por restore real, não apenas declarados em planilha. A trilha de auditoria a nível de evento é mantida com retenção plurianual e indexada para investigação forense.

Hardening operacional inclui segregação de funções, princípio de privilégio mínimo, autenticação multifator obrigatória em qualquer acesso administrativo, e revisão periódica de acessos com revogação automática quando a função expira.

XI. Limites e responsabilidade compartilhada​

Há limites, e é importante explicitá-los. Manifestos de segurança que omitem limites perdem credibilidade técnica.

Não prometemos imunidade. Nenhuma rede é imune. Prometemos defesa em profundidade, contenção de raio de impacto e disclosure honesto.

Não prometemos que o sensor físico, entregue a adversário com tempo e laboratório completo, resista indefinidamente, mesmo com as proteções em silício descritas na seção III. Prometemos que comprometer um dispositivo isolado não compromete a Rede.

Não prometemos defender o smartphone de usuário sob controle total de adversário (root, jailbreak malicioso, malware com privilégio de sistema). Esse cenário, em qualquer arquitetura de SDK do mundo, está além do escopo defensável pela camada de aplicação. Prometemos que o aparelho comprometido seja contido, e não vire vetor de ataque contra a rede inteira.

Não prometemos zero vulnerabilidades. Vulnerabilidades vão aparecer, como aparecem em toda infraestrutura séria do mundo. Prometemos que a arquitetura tolera vulnerabilidade local sem colapso global, e que o processo de remediação é estruturado e auditável.

Por fim, a segurança da rede opera sob um modelo de responsabilidade compartilhada. A GL One® responde pelo design da rede, pelo código do SDK e do firmware, pela infraestrutura de ingestão e armazenamento, e pelos controles operacionais expostos no trust center. O operador do aplicativo parceiro responde pela integração do SDK no seu ciclo de build, pela proteção das credenciais que recebe e pela atualização do aplicativo distribuído aos seus usuários. O cliente operador responde pela configuração do seu tenant, pelo controle de acesso das suas equipes e pelo uso responsável dos dados que recebe da rede. Cada camada é necessária. Nenhuma das três sozinha é suficiente.

XII. Posição: Postura evolutiva​

Segurança não é estado. É processo.

A arquitetura descrita aqui é o ponto onde a rede está hoje, e não o ponto onde ela vai parar. Threat modeling (modelagem de ameaças) é exercício contínuo, revisitado a cada mudança relevante de superfície. Pen test externo é recorrente. O trust center em https://trust.grouplinkone.com expõe o estado vivo dos controles, e é atualizado conforme cada um é verificado, não conforme calendário comercial.

Segurança também não é propriedade de um time. É propriedade da engenharia inteira da GL One®. Decisões de design passam por revisão de ameaça antes de codificação. Código novo passa por análise estática e revisão de pares com checklist de segurança aplicado. Cada incidente, de qualquer severidade, gera postmortem sem culpa documentado e revisado, no mesmo padrão recomendado pelo Building Secure & Reliable Systems.

O engajamento externo é parte explícita dessa postura. Pesquisadores de segurança independentes têm canal direto de reporte, com SLA de resposta inicial publicado no trust center, e reconhecimento público quando aplicável. Clientes e parceiros têm acesso a evidências de controles, relatório de pen test mediante NDA e canal técnico para questionário de segurança. Esse fluxo aberto é o que separa um manifesto de uma operação de segurança real.

Anexo: Referências externas​

As referências reunidas a seguir são públicas e amplamente reconhecidas pelas comunidades técnicas de redes, criptografia, IoT, privacidade e engenharia de confiabilidade. Sustentam as decisões arquiteturais descritas neste documento e dão ao leitor o material para verificar, em fonte primária, cada uma das escolhas declaradas. Esta lista não constitui declaração de conformidade. É leitura recomendada para quem queira entender o estado da arte em IoT industrial, redes colaborativas BLE, transporte seguro e privacidade por desenho, e avaliar, com base própria, as decisões arquiteturais da Rede GL One®.

A. Padrões de segurança IoT, OT e mobile

B. Protocolos de transporte, criptografia e identidade (IETF e W3C)

C. Bluetooth Low Energy, mesh e privacidade de rádio

D. Modelagem de ameaça, engenharia de confiabilidade e privacidade por desenho

Footnotes​

  1. A GL One® contratou parecer jurídico independente da Laura Schertel Mendes Advocacia e Consultoria sobre a conformidade da Rede Utilities IoT com a Lei Geral de Proteção de Dados. A autora é Professora de Direito Civil da Universidade de Brasília (UnB) e do Instituto Brasileiro de Ensino, Desenvolvimento e Pesquisa (IDP), Pós-Doutora pela Universidade Goethe (Frankfurt am Main) e Doutora em Direito Privado pela Universidade Humboldt (Berlim). É autoridade reconhecida em proteção de dados pessoais no Brasil, e parte da literatura de referência sobre a LGPD em sua aplicação a tecnologias emergentes. Referido parecer é confidencial, podendo apenas ser disponibilizado para clientes e/ou parceiros mediante NDA ou contrato assinado e solicitação enviada para dpo@grouplinkone.com. ↩