Deuda técnica y riesgos
Lo que se sabe que está mal, por qué sigue así y qué haría falta para corregirlo.
Registrarlo no es una confesión: es la diferencia entre un riesgo que se administra y una sorpresa que estalla. Lo que nadie documentó es lo que explota en el peor momento.
Cómo se clasifica
| Tipo | Qué significa | Cómo se trata |
|---|---|---|
| 🔓 Seguridad | Explotable hoy. No es deuda: es una puerta abierta | Se corrige, no se prioriza |
| ⚙️ Operación | Procesos manuales, frágiles o no repetibles | Automatizar o documentar |
| 🏗️ Arquitectura | Decisiones de diseño que hoy cuestan caro | Requiere análisis y plan |
| 👥 Organización | Riesgos que no están en el código: bus factor, dependencias de personas | Distribuir conocimiento |
Impacto: 🔴 alto (riesgo operativo o de seguridad real) · 🟡 medio (molesta, hay workaround) · 🟢 bajo.
Registro
| # | Qué | Tipo | Impacto | Estado |
|---|---|---|---|---|
| 1 | INTERNAL_API_KEY con valor por defecto en producción | 🔓 Seguridad | 🔴 | Sin corregir |
| 2 | Secretos compartidos entre todos los clientes | 🔓 Seguridad | 🔴 | Sin corregir |
| 3 | Aprovisionamiento de clientes de m-system 100 % manual | ⚙️ Operación | 🔴 | Propuesta por presentar a gerencia |
| 4 | Ninguna aplicación tiene backup | 👥 Organización | 🔴 | Owners asignados · backups pendientes |
1 · INTERNAL_API_KEY con valor por defecto en producción
Qué está mal
La variable de entorno INTERNAL_API_KEY de las Lambdas de m-system tiene como
valor el placeholder por defecto que viene en el código fuente
(your-secret-api-key-here-change-in-production). Nunca se reemplazó por un
valor real.
Por qué importa
Ese valor está en el repositorio. Cualquiera con acceso al código —hoy o en el futuro, incluido alguien que ya no trabaje en la compañía— conoce la API key interna que está en uso en producción.
Qué haría falta
- Generar un valor real y aleatorio.
- Actualizarlo en todas las Lambdas afectadas.
- Quitar el placeholder del código fuente y hacer que la aplicación falle al arrancar si la variable no está definida, en vez de caer a un valor por defecto.
Verificar
Confirmar en qué llamadas se usa realmente esta clave y qué permite hacer quien la tenga. De eso depende cuánto se ha expuesto.
Owner y fecha de corrección.
2 · Secretos compartidos entre todos los clientes
Qué está mal
INFLUXDB_TOKEN, INTERNAL_API_KEY y SERVICE_JWT_TOKEN son los mismos para
todos los clientes. Cada Lambda de cliente los hereda al replicarse.
Ver Habilitar cuenta de m-system.
Por qué está así
Es la consecuencia de aprovisionar replicando una Lambda existente: los valores viajan con la copia.
Qué duele hoy
- Sin aislamiento entre clientes. Un token filtrado no compromete a un cliente: los compromete a todos.
- Rotación prácticamente imposible. Cambiar un token obliga a actualizar todas las Lambdas a la vez. En la práctica esto significa que no se rotan nunca, ni siquiera cuando alguien sale del equipo.
- Los valores viven solo como variables de entorno en la consola de AWS: no hay gestor de secretos, ni rotación automática, ni registro de quién los consultó. Cualquiera con permiso de lectura sobre las Lambdas los ve completos.
Qué haría falta
- Mover los secretos a un gestor (AWS Secrets Manager o SSM Parameter Store) y que la Lambda los lea en tiempo de ejecución.
- Evaluar tokens por cliente donde tenga sentido, para acotar el radio de impacto.
- Definir una política de rotación que sea ejecutable.
Owner y plan de migración.
3 · Aprovisionamiento de clientes de m-system 100 % manual
Qué está mal
Habilitar un cliente nuevo exige ejecutar a mano una secuencia larga de pasos repartidos entre un configurador, un repositorio, un equipo físico, la plataforma m-system y tres servicios de AWS. Ver Habilitar cuenta de m-system.
Por qué está así
Es como funciona hoy la aplicación. El proceso creció con el producto y nunca se automatizó.
Qué duele hoy
- Riesgo de error humano en cada alta. El mismo UUID se escribe en seis lugares, y en uno de ellos con un formato distinto (guiones bajos en el nombre de la regla de IoT Core). Un carácter mal puesto deja el cliente creado pero sin recibir datos.
- Tiempo: 1 hora sin pruebas, unas 3 horas haciéndolo bien.
- Cada alta puede quedar distinta, porque el estándar de recursos por servicio no está fijado en ninguna parte.
- No hay estándar de despliegue en el equipo de campo. La copia se hace con
rsyncsobre SSH, decidiendo en el momento el usuario, la ruta de destino y el nombre del proceso de PM2. Cada equipo puede haber quedado distinto, y exige estar físicamente en la misma red que el hardware. - Conocimiento no distribuido: hasta ahora el procedimiento vivía únicamente en la cabeza de una persona.
Qué haría falta
Automatizar el aprovisionamiento. El criterio de éxito es reducir errores humanos, no solo ahorrar tiempo.
Alcance mínimo de la mejora:
- Definir el estándar de despliegue: usuario, ruta,
entrypointy nombre de proceso de PM2 iguales en todos los equipos. Es el paso más barato y ya elimina una fuente de variación. - Fijar el estándar de recursos por servicio de AWS, para que replicar no dependa de mirar qué tenía el cliente anterior.
- Automatizar el aprovisionamiento de AWS y el alta en m-system.
T-Monitor mantiene el repositorio
custom-rpi-images con
imágenes personalizadas de Raspberry Pi. M-System instala hoy el sistema
operativo y las dependencias a mano en cada equipo.
Vale evaluar si esas imágenes se pueden reutilizar o adaptar: eliminaría el paso 5.1 completo del runbook y una fuente entera de variación entre equipos, sin desarrollar nada nuevo.
Siguiente paso — prioritario
Hablar con gerencia y presentar una propuesta para abrir una etapa de mejora dedicada a este aspecto.
Owner de la propuesta y fecha objetivo para presentarla.
4 · Ninguna aplicación tiene backup
Qué está mal
Con la estructura de células, todas las aplicaciones tienen owner (Responsabilidades y ownership). Lo que no tiene ninguna es backup: cada aplicación depende hoy de una sola persona.
Las células 2 y 3 son las más expuestas: una persona cada una, sosteniendo entre ambas cinco aplicaciones.
Qué duele hoy
- Si la persona que sostiene una aplicación se ausenta —vacaciones, enfermedad, salida— esa aplicación queda sin nadie que la atienda.
- No hay a quién escalar cuando algo falla fuera del horario de esa persona.
Qué haría falta
- Asignar un backup a cada aplicación, aunque sea con conocimiento parcial. Un backup que sabe dónde está el repositorio y cómo desplegar ya evita la parálisis total.
- Documentar cada aplicación en el mapa de sistemas: qué hace, dónde vive, cómo se despliega. Sin eso, nombrar un backup es simbólico.
- Cubrir las cinco posiciones abiertas. Hasta entonces, las células 2 y 3 no tienen con quién repartir.
Las otras entradas de esta lista cuestan tiempo o dinero. Esta cuesta continuidad: es la que convierte una salida planificada en una interrupción del servicio.
Falta registrar el resto de prácticas y riesgos conocidos. Para cada uno: qué está mal, por qué está así, qué duele hoy y qué haría falta para corregirlo.