Seguridad IoT de extremo a extremo: del ESP32 a la nube, capa por capa

Publicado originalmente en iot.gripe.

La seguridad de un sistema IoT es tan fuerte como su capa más débil. Puedes tener la nube perfectamente configurada y que un certificado copiado en un repositorio público lo eche todo abajo; o un firmware impecable y un rol con "Resource": "*" que deja la puerta abierta a cualquiera.

Esta guía recorre las cinco capas de un sistema IoT, del chip a las personas que lo usan, con lo mínimo que conviene hacer en cada una. Los ejemplos usan las piezas de la serie de domótica de este blog: ESP32, ESP-NOW y AWS.

Las cinco capas

1. El dispositivo: el ESP32, su firmware y lo que guarda en memoria.
2. La red local: cómo se comunican los dispositivos entre sí y con el router.
3. La conexión con la nube: cómo se autentica cada dispositivo y qué puede hacer.
4. La nube y las APIs: los permisos de cada servicio y el aislamiento entre usuarios.
5. Los usuarios y la operación: el login, los permisos de cada persona y el día a día.

Capa 1: el dispositivo

• Una identidad por dispositivo. Cada ESP32 con su propio certificado X.509. Si uno se compromete, lo revocas sin afectar a los demás.
• Nada de credenciales en el código. Ni la contraseña del Wi-Fi ni la llave privada deben estar en el firmware ni en el repositorio. Con Fleet Provisioning, cada dispositivo obtiene su certificado después de instalar el firmware (parte 17).
• Protege lo que guardas. Por defecto, la memoria NVS del ESP32 no está cifrada: con acceso físico se puede leer. Para un producto, activa el cifrado de la flash y el arranque seguro (secure boot), que solo permite ejecutar firmware firmado por ti.
• Actualizaciones firmadas. Si actualizas el firmware a distancia, verifica la firma o al menos usa HTTPS con un certificado de confianza, y conserva la posibilidad de volver a la versión anterior si la nueva falla.
• La mejor opción para la llave: que el dispositivo genere su propio par de llaves y solo envíe una solicitud de firma (CSR). Así la llave privada nunca sale del chip.

Capa 2: la red local

• Separa los dispositivos IoT en su propia red o VLAN si tu router lo permite. Si uno se compromete, no ve tus computadores.
• Valida el origen de cada mensaje local. Una pasarela solo debería aceptar mensajes ESP-NOW de nodos conocidos, comprobando su MAC (parte 4). Y un dispositivo nuevo no debería aceptarse solo: que una persona lo confirme.
• Cifra si lo que viaja es sensible. ESP-NOW admite cifrado con clave compartida. Para órdenes simples el riesgo es bajo; con datos personales, cifra.
• Los portales de configuración, solo mientras hacen falta. La red Wi-Fi abierta que levanta un dispositivo para configurarse debe desaparecer en cuanto se configura.

Capa 3: la conexión con la nube

• TLS siempre, verificando el certificado del servidor (en un ESP32, con la CA raíz cargada; nunca desactives la verificación "para que funcione").
• Políticas de mínimo privilegio por dispositivo. Que solo pueda conectarse con su propio nombre y usar los tópicos de su propio Shadow. Un comodín convierte un certificado robado en acceso a toda la cuenta.
• Una política para toda la flota, con variables. ${iot:Connection.Thing.ThingName} limita cada dispositivo a lo suyo sin escribir una política por dispositivo (parte 13).
• Define las políticas como código, no a mano en la consola. Un permiso agregado a mano para probar no existe para el siguiente dispositivo, y nadie recuerda que está ahí (parte 12).

Capa 4: la nube y las APIs

• Nunca confíes en lo que envía el cliente para decidir sobre qué dispositivo o datos actúa. Sácalo de un token verificado o de un registro en tu base de datos.
• Aislamiento entre usuarios en IAM, no solo en el código. Si los usuarios acceden directamente a servicios de AWS, condiciones como dynamodb:LeadingKeys limitan a cada uno a sus propios datos. Si pasan por una API, la API decide con el token verificado.
• Un rol por función, con lo justo. Si una Lambda solo lee un índice y actualiza un Shadow, su rol no debe poder hacer nada más.
• APIs públicas que validan por dentro. Una Lambda Function URL sin autenticación de IAM es pública: toda la validación (token, firma) ocurre en el código.
• Guarda hashes, no secretos. Tokens propios y códigos de un solo uso se guardan como hash y se muestran una sola vez (parte 8).

Capa 5: los usuarios y la operación

• Registro solo por invitación si es un sistema privado: en Cognito, AllowAdminCreateUserOnly.
• Contraseña propia desde el primer login: la temporal solo sirve para entrar la primera vez (parte 11).
• Permisos aplicados en el servidor. Ocultar un botón en la app no es control de acceso.
• Revocación rápida: al quitar a alguien, cerrar sus sesiones, borrar sus credenciales (como sus tokens) y quitarle los permisos. Un JWT ya emitido no se puede revocar, así que acórtale la vida útil.
• Audita lo que existe, no lo que documentaste. En proyectos que nacieron como prototipo es común encontrar funciones públicas olvidadas y roles con comodines (parte 21).

Lista de comprobación

Preguntas frecuentes

¿Por dónde empiezo si mi proyecto ya existe?

Por buscar comodines: "Resource": "*", thing/*, identidades no autenticadas con permisos. Después, por cada endpoint público, comprueba qué valida. Son los dos agujeros más comunes en proyectos que nacieron como prototipo.

¿Cifrar ESP-NOW es obligatorio?

Depende de lo que envíes. Para órdenes simples entre dispositivos que se validan por MAC, el riesgo es bajo. Para cualquier dato personal o de seguridad, cifra.

¿Qué herramientas de AWS ayudan?

IAM Access Analyzer detecta recursos accesibles desde fuera de la cuenta; AWS IoT Device Defender audita la configuración de IoT Core; aws iam simulate-principal-policy prueba permisos concretos antes de desplegarlos.

Todos los artículos sobre seguridad, identidad y usuarios