HTTP, HTTPS e APIs REST em automação: métodos, estados e segurança
Leia uma transação HTTP, diferencie HTTPS de HTTP, entenda métodos, códigos, headers, sessão, API REST, proxy e os testes necessários em interfaces de automação.
Leitura de uma falha HTTP/HTTPS
| Camada | Evidência | Foco |
|---|---|---|
| DNS | nome não resolve ou IP errado | registro, cache e servidor |
| TCP | timeout, reset ou refused | rota, ACL e listener |
| TLS | alerta ou certificado inválido | nome, cadeia, data e algoritmo |
| HTTP 4xx | request chegou e foi recusado | credencial, privilégio, URL e payload |
| HTTP 5xx | servidor/proxy falhou | backend, dependência e capacidade |
| 2xx sem efeito | resposta não representa estado esperado | contrato, log e processo |
HTTPS resolve proteção do transporte; autorização e segurança da função permanecem responsabilidade da aplicação.
HTTP transporta mensagens; HTTPS protege o transporte
HTTP organiza request e response com método, alvo, campos e conteúdo. HTTPS é HTTP sobre uma conexão protegida por TLS. O TLS autentica o servidor por certificado e protege sigilo e integridade; não torna a aplicação correta nem concede autorização. Uma API pode responder por HTTPS e ainda aceitar ação excessiva de um usuário privilegiado.
Interfaces web de IEDs, gateways, PLCs, NMS e aplicações usam esses mecanismos para configuração, consulta e integração. Como uma requisição pode mudar parâmetro ou emitir comando, o fluxo precisa de identidade, autorização, registro e proteção contra uso automatizado indevido.
Método expressa intenção, mas implementação decide efeito
GET normalmente recupera representação; HEAD retorna metadados; POST processa conteúdo; PUT substitui ou cria estado no alvo; PATCH altera parcialmente; DELETE remove. Propriedades como segurança e idempotência orientam retries e caches. Um cliente não deve repetir POST de comando cegamente após timeout, porque a ação pode ter ocorrido sem resposta.
Documente o contrato da API e identifique chave idempotente ou consulta de estado quando disponível. Em automação, timeout não significa “não executado”. O teste precisa correlacionar request, resposta, log e estado físico ou lógico.
Códigos de estado delimitam a camada que respondeu
2xx indica processamento bem-sucedido conforme a semântica; 3xx redireciona; 4xx aponta condição da solicitação, autenticação ou autorização; 5xx indica falha do servidor ou gateway. 401 e 403 não são equivalentes: o primeiro se relaciona a autenticação necessária ou inválida; o segundo a recusa de uma identidade reconhecida.
Um 404 pode esconder recurso por política ou indicar URL incorreta; 429 indica limitação de taxa; 502/503/504 sugerem proxy ou serviço posterior. Preserve body e headers sem expor tokens. “HTTPS não funciona” é descrição pobre quando o servidor retornou um código específico.
Headers, conteúdo e sessão carregam contexto
Host seleciona o serviço virtual e participa da validação de nome; Content-Type informa formato; Authorization transporta credencial ou token; Cookie pode manter sessão; Cache-Control orienta armazenamento; Location indica redirecionamento. Proxy reverso pode acrescentar ou remover campos. Compare o que o cliente enviou e o que a aplicação recebeu.
JSON bem formado não garante unidade, qualidade ou timestamp corretos. Esquema e versão da API precisam definir tipos, campos opcionais, enumerações e erros. Mudança de firmware pode manter URL e alterar contrato, quebrando integração sem falha de rede.
Autenticação e sessão devem caber no risco OT
Senha em formulário só está protegida em trânsito quando TLS é validado. Tokens precisam de escopo, validade, armazenamento e revogação. Sessões devem expirar e cookies usar atributos adequados. Contas compartilhadas e tokens permanentes tornam ações difíceis de atribuir.
Automação máquina a máquina deve usar identidade de serviço com privilégio mínimo, não credencial pessoal embutida em script. Segredo não deve aparecer em URL, log ou repositório. Rotação precisa ser ensaiada sem interromper coleta ou controle.
Proxy e redirecionamento criam novas fronteiras
Um proxy pode terminar TLS, aplicar autenticação e encaminhar HTTP internamente. Nesse caso, o trecho interno precisa de análise própria; o cadeado do navegador protege somente até o terminador. Hostname, certificado e headers forwarded devem ser controlados para evitar destino ou origem falsos.
Redirecionar HTTP para HTTPS reduz uso acidental, mas a porta HTTP continua exposta e a primeira requisição pode levar dados se o cliente enviar credencial prematuramente. Prefira URLs HTTPS configuradas e desabilite HTTP quando suportado e testado.
Diagnóstico da transação completa
Separe DNS, TCP, TLS e HTTP. Se DNS falha, não há IP; se TCP é recusado, o processo não escuta ou a política rejeita; se TLS alerta, leia certificado e negociação; se HTTP responde, interprete método, URL, estado e corpo. Ferramentas de linha de comando ajudam, mas não use opções que ignoram certificado como solução permanente.
Em captura, HTTPS protege conteúdo. Use logs de cliente, proxy e servidor com correlation ID quando disponível. Sincronize horários e preserve request sem segredos. Compare uma chamada bem-sucedida e outra com falha.
Comissionamento e recuperação
Teste leitura, escrita autorizada, operação negada, sessão expirada, token revogado, payload inválido, repetição e timeout. Confirme que ações críticas exigem controle adequado e aparecem em log com identidade. Meça comportamento durante reinício e indisponibilidade do backend.
Depois de restaurar, valide reconexão sem tempestade, estado coerente e ausência de ação duplicada. O aceite deve ligar resposta HTTP ao efeito real e à trilha de auditoria, mantendo método de rollback para configurações.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- IEC 62443-3-3:2013 — System security requirements and security levels — IEC. Requisitos técnicos de segurança para sistemas de automação e controle industrial.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security — NIST. Arquiteturas, ameaças e controles aplicáveis a ambientes OT.
- RFC 1122 — Requirements for Internet Hosts — Communication Layers — RFC Editor / IETF. Requisitos de IP, ICMP e camadas de comunicação em hosts.
- RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification — RFC Editor / IETF. Especificação vigente do IPv6.
- RFC 9110 — HTTP Semantics — RFC Editor / IETF. Semântica atual de métodos, campos e códigos HTTP.
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — RFC Editor / IETF. TLS 1.3, handshake, autenticação e proteção do transporte.
- RFC 9325 — Recommendations for Secure Use of TLS and DTLS — RFC Editor / IETF. Recomendações atuais para versões, algoritmos e configuração TLS.
- RFC 4251 — The Secure Shell (SSH) Protocol Architecture — RFC Editor / IETF. Arquitetura SSH e separação entre transporte, autenticação e conexão.
- RFC 5424 — The Syslog Protocol — RFC Editor / IETF. Formato, facility, severity, timestamp e dados estruturados de Syslog.
- RFC 3411 — Architecture for Describing SNMP Management Frameworks — RFC Editor / IETF. Arquitetura do framework SNMP.
- RFC 3414 — User-based Security Model (USM) for SNMPv3 — RFC Editor / IETF. Autenticação e privacidade do SNMPv3 USM.
- IEEE 802.1AB-2016 — Station and Media Access Control Connectivity Discovery — IEEE Standards Association. LLDP e descoberta de conectividade em camada 2.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.