Nos blocos anteriores, fizemos dispositivos perceberem o ambiente, agirem e trocarem informações. Agora surge uma responsabilidade nova: decidir quais dados realmente precisam existir e quem pode acessar dados, dispositivos e comandos.
Quanto mais dados e acessos adicionamos, maior a responsabilidade de projetar o sistema com critérios.
No Bloco 6, um ESP32 pôde receber comandos por rede e até ser acessado por um túnel. No Bloco 7, vimos que sistemas IoT podem monitorar ambientes, pessoas, máquinas e ativos. No Bloco 8, entendemos como diferentes partes se comunicam. Agora imagine que o sistema registre nomes, horários, localização ou medições ligadas a uma pessoa. Conectar passou a envolver também proteção.
Precisamos mesmo deste dado? Antes de armazenar qualquer informação, defina a finalidade e verifique se o projeto pode funcionar com menos dados.
Quem pode acessar ou comandar? Um sistema disponível na rede não deve tratar qualquer pessoa como usuário autorizado.
| Proteção de dados pessoais | Segurança de sistemas e informações |
|---|---|
| Cuida do tratamento responsável de informações relacionadas a pessoas. | Cuida da proteção de sistemas, redes, dispositivos e informações contra eventos indevidos. |
| Pergunta finalidade, necessidade, transparência e direitos das pessoas. | Pergunta quem pode acessar, alterar, interromper ou obter informações. |
Antes de falar de senhas, redes e ataques, precisamos reconhecer quando uma informação do nosso projeto passa a ser um dado relacionado a uma pessoa.
A LGPD protege dados pessoais de pessoas naturais. Em IoT, sensores e registros podem produzir esses dados mesmo quando o projeto parece apenas “técnico”.
Um sensor mede a temperatura de uma sala. Isso, isoladamente e sem vínculo com uma pessoa identificada ou identificável, não descreve alguém. Mas o projeto muda se passarmos a registrar quem entrou, em que horário, onde estava ou qual medição pertence a determinada pessoa.
Para a LGPD, dado pessoal é a informação relacionada a uma pessoa natural identificada ou identificável. Nome é um exemplo óbvio, mas outros dados podem permitir identificar ou individualizar alguém quando analisados no contexto.
A lei dá proteção especial a categorias como dados de saúde, biométricos e genéticos, além de outras categorias definidas pela LGPD. Em IoT de saúde, portanto, a atenção precisa ser maior.
| Situação | Leitura para o projeto |
|---|---|
| Temperatura ambiente sem vínculo com pessoa | É um dado do ambiente; sozinho, não identifica uma pessoa. |
| Registro “Ronaldo entrou às 19:02” | Relaciona uma ação a uma pessoa identificada: é dado pessoal. |
| Batimento cardíaco associado ao usuário de um dispositivo | É dado relacionado à saúde e exige cuidado especial. |
| Localização de um rastreador associado a uma pessoa | Pode revelar onde aquela pessoa está ou esteve e deve ser tratada com proteção adequada. |
Uma boa pergunta de projeto é: qual resultado queremos obter e qual é o menor conjunto de dados necessário para isso? A LGPD inclui os princípios da finalidade e da necessidade. Portanto, “talvez seja útil um dia” não é uma boa razão para coletar tudo.
Em uma aplicação comum de contagem de uso, provavelmente não. Se a finalidade é saber quantas aberturas ocorreram, associar cada abertura a uma pessoa acrescentaria dado sem necessidade para esse objetivo.
Pode haver uma finalidade legítima para esse registro, mas o dado passa a estar relacionado a pessoas. O projeto deve definir finalidade, acesso, retenção e demais requisitos aplicáveis, em vez de tratar o log como um detalhe técnico sem consequências.
É principalmente uma questão de segurança do sistema e das credenciais. Proteção de dados e segurança se relacionam, mas não são sinônimos.
| Informação | Precisamos para o protótipo de iluminação? | Decisão |
|---|---|---|
| Valor de luminosidade | Sim, para decidir se o ambiente está claro ou escuro. | Usar somente enquanto necessário ao funcionamento e aos testes. |
| Estado do LED | Sim, para mostrar se a iluminação está ligada ou desligada. | Manter como estado do sistema. |
| Nome da pessoa que apertou o botão | Não, no protótipo atual. | Não coletar. |
| Senha real do Wi-Fi | É necessária para a conexão, mas é uma credencial, não um dado que devemos publicar. | Usar de forma protegida e nunca deixar exposta no repositório. |
Mesmo coletando apenas o necessário, ainda existe outro problema: como impedir acesso, alteração, perda ou controle indevido do sistema e das informações?
Um projeto IoT não é apenas a placa. Dispositivo, rede, aplicação, credenciais e dados formam uma cadeia.
No Bloco 6, um túnel pôde tornar um serviço local acessível de fora da rede. Isso foi útil para compreender conectividade, mas também revelou uma pergunta de segurança: se alguém obtiver o endereço, essa pessoa deve conseguir controlar o dispositivo? Em um sistema real, a resposta não pode ser “sim, porque conhece a URL”.
No nosso protótipo: confidencialidade aparece quando protegemos credenciais; integridade aparece quando queremos impedir comandos indevidos ou alterados; disponibilidade aparece quando pensamos no que o sistema deve fazer se a rede falhar.
É verificar quem está tentando acessar. Senha, chave, certificado ou outro mecanismo pode participar dessa verificação conforme o sistema.
Depois de saber quem é o usuário ou sistema, ainda precisamos decidir o que ele pode fazer. Ler um sensor e acionar uma porta podem exigir permissões diferentes.
Em sistemas que exigem rastreabilidade, registros podem ajudar a saber que operação ocorreu e quando. Mas logs também podem conter dados pessoais e precisam ser protegidos.
| O que existe | Risco que percebemos | Como tratar em um sistema real |
|---|---|---|
| SSID e senha escritos no código | Publicar o arquivo pode expor a credencial da rede. | Separar segredos do código publicado e controlar quem pode obtê-los. |
| Servidor HTTP local sem login | Quem alcançar o ESP32 na rede pode tentar acionar as rotas. | Adicionar autenticação e autorização compatíveis com o risco da aplicação. |
| HTTP sem criptografia | O conteúdo trafega sem a proteção oferecida por TLS. | Quando houver dados ou comandos sensíveis, projetar transporte protegido, normalmente com HTTPS/TLS ou uma arquitetura segura equivalente. |
| Túnel com URL pública temporária | A superfície de acesso deixa de ficar restrita à rede local. | Expor apenas quando necessário, encerrar após o teste e não depender do segredo da URL como mecanismo de segurança. |
| Queda do Wi-Fi | A interface Web deixa de responder. | Definir comportamento seguro para funções que devem continuar localmente. |
HTTP organiza pedidos e respostas. HTTPS usa TLS (Transport Layer Security) para proteger a comunicação em trânsito. Autenticação verifica quem está acessando e autorização decide o que essa identidade pode fazer.
Uma conexão HTTPS não transforma automaticamente qualquer usuário em usuário autorizado. Da mesma forma, colocar uma senha na aplicação não substitui a proteção do tráfego quando ela é necessária. São camadas diferentes do projeto.
| Parte | Risco simples | Decisão de projeto |
|---|---|---|
| Dispositivo | Configuração padrão ou software desatualizado. | Manter configuração controlada e atualizar componentes quando necessário. |
| Credenciais | Senha fraca, repetida ou publicada no código. | Usar credenciais adequadas e não expor segredos em repositórios ou páginas. |
| Rede | Serviço exposto além do necessário. | Limitar exposição e permitir somente os acessos necessários. |
| Aplicação | Comandos aceitos sem verificar autorização. | Implementar autenticação e autorização compatíveis com o risco. |
| Dados | Coleta, armazenamento ou compartilhamento excessivo. | Coletar o necessário, controlar acesso e definir proteção e retenção. |
A LGPD determina que medidas de segurança relacionadas a dados pessoais sejam observadas desde a fase de concepção do produto ou serviço até sua execução. Em termos de projeto, isso significa que segurança não deve ser uma “última tela” acrescentada depois.
Não. Credenciais reais não devem ser expostas em código público. No material didático usamos valores como NOME_DA_REDE e SENHA_DA_REDE justamente para separar exemplo de segredo real.
Não. Esconder o endereço não substitui um mecanismo de autenticação e autorização.
Não. Um atuador controlado sem autorização, um dispositivo indisponível ou um comando alterado podem causar problemas mesmo sem dados pessoais.
Agora temos sensores, atuadores, programação, conectividade, IoT, RTOS, interfaces, protocolos e critérios de proteção. O próximo passo deixa de ser estudar partes isoladas: vamos integrá-las em um projeto IoT completo, com problema, requisitos, implementação, testes e entrega.