Un proyecto IoT tiene más superficie de ataque que una app web normal: placas físicas que alguien puede abrir, radio que cualquiera cercano puede escuchar, una nube con permisos y una app en el navegador. Un descuido en cualquiera de esas capas puede dar acceso a las demás.
Esta lista reúne lo que conviene revisar antes de dar por terminado un proyecto como el de esta serie, ordenada por capa. Úsala como auditoría: recorre cada punto y marca lo que ya cumples.
Capa 1: los dispositivos
- Un certificado por dispositivo, nunca uno compartido. Si uno se filtra, lo revocas sin afectar a los demás (certificados X.509 explicados).
- Ninguna credencial en el código fuente. Wi-Fi, certificados y tokens van en NVS (parte 6) o se entregan con aprovisionamiento (parte 17).
- El archivo de secretos en
.gitignoredesde el primer commit. Si una llave llegó al historial, revócala: borrar el archivo no basta. - El dispositivo verifica al servidor (
setCACert). NuncasetInsecure()en producción. - Cifrado de flash y secure boot si el dispositivo es un producto que otros tendrán en sus manos.
- El portal de configuración no queda abierto para siempre (parte 16).
- Las actualizaciones de firmware se verifican antes de instalarse (firmas o, como mínimo, HTTPS desde un origen tuyo).
Capa 2: comunicación local
- Los nodos solo aceptan mensajes de MAC conocidas (parte 4). Cualquier ESP32 cercano puede enviar paquetes ESP-NOW.
- Cifrado de ESP-NOW si los mensajes llevan algo más que órdenes simples.
- Validación de cada mensaje: tamaño exacto, valores dentro de rango. Un paquete malformado no debe colgar al nodo.
- Una red Wi-Fi separada para IoT si tu router lo permite (red IoT separada en casa).
Capa 3: AWS IoT Core
- Políticas con variables, sin
*eniot:Connectni en los tópicos (parte 13). - El client ID atado al nombre del Thing con
iot:Connection.Thing.ThingName. - Prueba negativa: con
test-authorization, comprueba que un dispositivo no puede publicar en los tópicos de otro. - El certificado de claim (si usas Fleet Provisioning) solo puede aprovisionarse, y el hook valida quién se registra.
- Registros de AWS IoT activos en CloudWatch, al menos de errores.
- Auditoría de Device Defender activada para detectar políticas permisivas o certificados compartidos.
Capa 4: APIs y Lambdas
- Cada Lambda con su propio rol y solo los permisos que usa, sobre recursos concretos (parte 12).
- La identidad sale de un token verificado, nunca del cuerpo de la petición. Si la petición dice "soy la casa X", ignóralo; lo que vale es lo que dice el token firmado (parte 11).
- Listas blancas de valores aceptados (salidas, acciones), como en la API de la parte 8.
- Tokens comparados en tiempo constante y guardados como hash si son propios.
- Límite de abuso: concurrencia reservada o throttling en las APIs públicas.
- Errores sin detalles internos hacia el cliente; el detalle va a los registros.
- Sin secretos en variables de entorno en texto plano si puedes usar Secrets Manager o Parameter Store.
Capa 5: la web app
- Sin
dangerouslySetInnerHTMLcon datos que vienen de usuarios o de dispositivos (nombres de habitaciones, por ejemplo). - Cabeceras de seguridad:
Content-Security-Policy,X-Content-Type-Options,Referrer-Policy. - Los tokens no se registran en la consola ni viajan en la URL.
- La sesión se cierra al cerrar sesión: tokens borrados y conexión MQTT terminada.
- Dependencias al día:
npm auditperiódico y actualizaciones de seguridad. - Permisos de la Identity Pool (si la usas) limitados a lo que la app necesita y a los datos del propio usuario.
Capa 6: la cuenta de AWS
- MFA en el usuario raíz y sin claves de acceso para él.
- Alarma de facturación: un presupuesto con aviso por correo. Un error o un abuso se nota primero en la factura.
- CloudTrail activo para saber quién cambió qué.
- Sin claves de acceso de larga duración en tu computador si puedes usar IAM Identity Center.
Plan para cuando algo se filtra
Tenerlo escrito antes de necesitarlo:
| Si se filtra... | Haz esto |
|---|---|
| La llave privada de un dispositivo | Desactiva o revoca su certificado en AWS IoT; aprovisiona uno nuevo |
| El certificado de claim | Desactívalo, crea otro y actualiza el firmware de los dispositivos sin aprovisionar |
| Un token de API | Cámbialo en Parameter Store; actualiza los clientes legítimos |
| Una clave de acceso de AWS | Desactívala en IAM de inmediato y revisa CloudTrail |
| La contraseña de un usuario | Restablécela y cierra sus sesiones (AdminUserGlobalSignOut) |
Cómo hacer la revisión
- Recorre la lista con el código delante, no de memoria.
- Intenta romper tu propio sistema: desde las herramientas del navegador, cambia un identificador en una petición y comprueba que la API lo rechaza.
- Anota lo que no cumples con su riesgo y decide: corregir ya, corregir después o aceptar el riesgo con una razón escrita.
- Repite cuando agregues una función importante.
Para una visión de conjunto, está la guía de seguridad IoT de extremo a extremo.
Preguntas frecuentes
¿Necesito todo esto para un proyecto en mi casa?
Lo esencial sí: certificados por dispositivo, políticas sin comodines, secretos fuera del código y verificar los tokens en el backend. El cifrado de flash o el secure boot tienen más sentido cuando otras personas tienen tus dispositivos.
¿Cuál es el fallo más común?
Confiar en lo que envía el cliente: un identificador de casa, de usuario o de dispositivo en el cuerpo de la petición. Todo lo que decide permisos debe venir de algo firmado.
¿Cada cuánto conviene revisar?
Con cada cambio grande y, como mínimo, una vez al año. Las dependencias y los servicios cambian aunque tu código no.