SYS-ADR-005 — Chequeos del Cloud hacia el Edge sin autenticación¶

Contexto¶

El flujo de datos va de la planta a la nube, y ese sentido está autenticado con una clave de API por dispositivo: ver SYS-ADR-002.

Pero la interfaz necesita mostrar el estado de cada Raspberry Pi —si está viva, si alcanza al PLC, cómo está de recursos—, y para eso el Cloud tiene que preguntarle en sentido inverso. Ese sentido no tiene un mecanismo de autenticación establecido.

Complica el cuadro que el mecanismo previsto para saber el estado sin preguntar —que la Pi avise por su cuenta— no está implementado en ninguno de los dos extremos. Preguntar es hoy la única forma de saber.

Decisión¶

Las consultas de estado del Cloud hacia el Edge viajan sin credenciales. El control compensatorio declarado es el aislamiento de red: se asume que la Pi solo es alcanzable desde el Cloud a través de una red privada o una VPN.

El Edge soporta un secreto compartido opcional por cabecera, que cuando está configurado rechaza toda consulta que no lo traiga. El Cloud no lo envía, así que en la práctica está desactivado.

La decisión de componente del Edge ya lo planteaba así, y dejaba anotado que activarlo requiere un cambio del lado del Cloud que no se hizo.

Alternativas consideradas¶

Consecuencias¶

El riesgo asumido, enunciado sin rodeos:

1. La seguridad de este sentido depende por completo de un control que no está en ningún repositorio. No hay configuración de red privada versionada, ni documentada, ni verificable desde el código. Es un supuesto, no un control comprobado.
2. Quien alcance la Pi por la red puede leer su estado operativo sin credenciales: disponibilidad, salud del enlace con el PLC y métricas de recursos. Es información de reconocimiento, no de control.
3. La superficie es de solo lectura. No hay ningún camino que permita escribir por esta vía: ni en el PLC —ver SYS-ADR-007—, ni en la configuración del Edge, ni en los datos en tránsito.
4. Hay además un endpoint de telemetría que queda deliberadamente fuera del secreto compartido, incluso cuando éste se activa, para que pueda ser consultado por un recolector de métricas. Endurecer el resto no lo cubre.

Lo que acota el daño:

• El sentido que transporta los datos —planta a nube— sí está autenticado, y el tenant lo resuelve el servidor, no el cliente.
• La configuración por defecto del empaquetado publica el servicio en todas las interfaces de red de la Pi, así que el aislamiento tiene que darlo la red. Si la red no lo da, no lo da nadie.

Condiciones para revisar esta decisión —cualquiera de las tres la invalida—:

• Que la Pi quede alcanzable desde una red que no sea la privada prevista.
• Que la superficie inbound del Edge deje de ser de solo lectura.
• Que se implemente el aviso por iniciativa de la Pi, que vuelve innecesaria la consulta inversa.

Evidencia¶

• Decisión de componente, con el control compensatorio y el cambio pendiente del lado del Cloud: EDGE-ADR-005
• Secreto compartido aplicado por ruta, y la excepción deliberada del endpoint de métricas: internal/routes/url_mappings.go del Edge
• El Cloud no envía el secreto: su cliente hacia dispositivos Edge
• Ausencia del aviso por iniciativa de la Pi: el Cloud responde 501 en ese endpoint y el paquete correspondiente del Edge contiene solo documentación
• Exposición en todas las interfaces por defecto: docker-compose.yml
• Ausencia de configuración de red privada: búsqueda en los cinco repositorios