Trade‐offs y Riesgos - SebaUSM/GRUPO02-2025-PROYINF GitHub Wiki
En esta sección se presentan los principales trade-offs y riesgos identificados a partir de los concerns tratados.
Availability: Notificaciones de actualizaciones
Trade-offs
-
Disponibilidad vs. Complejidad del sistema
Implementar mecanismos como colas persistentes, lógica de reintento, balanceo de carga y control de idempotencia mejora la disponibilidad, pero añade complejidad arquitectónica, tanto en su técnica como operatividad. -
Entrega garantizada vs. Latencia
Asegurar la entrega de todas las notificaciones, incluso en caso de fallos, requiere confirmaciones (ACKs), almacenamiento temporal y reintentos, lo que puede aumentar la latencia promedio de entrega. -
Observabilidad vs. Rendimiento
Integrar herramientas como Prometheus o Elastic Stack para monitorear el estado de entrega permite detectar fallos, pero puede generar sobrecarga si el volumen de eventos es alto y no se optimiza el logging y sus métricas correspondientes. -
Alta disponibilidad vs. Costos de infraestructura
Ejecutar servicios como RabbitMQ en clúster o balanceo de carga en WebSocket requiere de más recursos, lo cual aumenta los costos operacionales y puede demandar personal adicional para su mantenimiento.
Riesgos
-
Riesgo 1: Pérdida de mensajes si el destinatario está desconectado y no existen colas persistentes ni lógica de reintento implementada correctamente.
-
Riesgo 2: Duplicación de notificaciones en escenarios con múltiples reintentos sin mecanismos de idempotencia, lo que puede generar errores funcionales en el receptor.
-
Riesgo 3: Cuellos de botella causados por colas saturadas, errores en la configuración de reintentos o caídas de nodos de mensajería.
-
Riesgo 4: Dependencia excesiva en sistemas de observabilidad (como Prometheus o Kibana) que, si no están bien configurados o replicados, podrían dejar sin trazabilidad al sistema en momentos críticos.
-
Riesgo 5: Entregas fuera de orden o inconsistentes si el balanceo de carga o la persistencia de sesión no están bien manejadas en WebSocket o mensajería distribuida.
Security: Sistema de encriptación de contraseñas
Trade-offs
-
Seguridad vs. Rendimiento
Algoritmos de hashing robustos como bcrypt, scrypt o Argon2 aumentan significativamente la seguridad, pero requieren mayor tiempo y recursos de CPU en comparación con algoritmos más simples. -
Seguridad vs. Experiencia del usuario
Forzar HTTPS, redireccionamientos y validaciones estrictas puede introducir una pequeña latencia adicional y complejidad para usuarios con configuraciones antiguas o dispositivos no actualizados. -
Modularidad de autenticación vs. Complejidad arquitectónica
Separar el módulo de autenticación del resto del sistema mejora la mantenibilidad y el aislamiento de fallos, pero implica más componentes que coordinar y asegurar correctamente. -
Autenticación vs. Privacidad y almacenamiento
Registrar intentos fallidos de autenticación es esencial para detectar ataques, pero debe hacerse con cuidado para no almacenar datos sensibles ni violar principios de minimización de datos o privacidad.
Riesgos
-
Riesgo 1: Almacenamiento inseguro de contraseñas si no se aplica un algoritmo de hashing actualizado y con salting, exponiendo al sistema a ataques de fuerza bruta u obtención de hashes.
-
Riesgo 2: Interceptación de credenciales si no se usa HTTPS de forma obligatoria en todas las rutas, incluyendo APIs y formularios.
-
Riesgo 3: Ataques de fuerza bruta o repetidos sin detección si no se implementa un módulo de auditoría con registros de intentos fallidos y alertas.
-
Riesgo 4: Acoplamiento indebido del módulo de autenticación con otras partes del sistema, lo cual puede generar dependencias circulares o vulnerabilidades al escalar o actualizar.
-
Riesgo 5: Logs mal gestionados pueden almacenar datos sensibles o habilitar accesos indebidos si no se protegen adecuadamente.
Availability: Respaldo de datos y boletines
Trade-offs
-
Frecuencia de respaldos vs. Consumo de recursos
Respaldos frecuentes aseguran mayor protección ante fallos, pero pueden generar alta carga en disco, CPU y red, especialmente en sistemas con grandes volúmenes de datos. -
Seguridad de almacenamiento vs. Accesibilidad
Almacenar los respaldos en ubicaciones cifradas y replicadas aumenta la seguridad, pero puede dificultar la recuperación rápida si no se configuran correctamente los accesos o si hay problemas de sincronización. -
Automatización vs. Control manual
Automatizar completamente el respaldo reduce el riesgo de error humano, pero puede ocultar fallos si no se implementa monitoreo y validación de los procesos de backup. -
Pruebas de restauración vs. Disponibilidad en tiempo real
Ejecutar pruebas de recuperación de datos es esencial para validar los respaldos, pero estas pruebas pueden requerir entornos adicionales o incluso causar interrupciones si se ejecutan en producción.
Riesgos
-
Riesgo 1: Pérdida irreversible de información si el sistema de respaldos falla y no existen validaciones ni redundancia.
-
Riesgo 2: Fallas en la recuperación de datos si los respaldos no son consistentes, están incompletos o se encuentran corruptos al momento de usarse.
-
Riesgo 3: Brechas de seguridad si los respaldos no están cifrados o se almacenan en ubicaciones no seguras o accesibles por terceros no autorizados.
-
Riesgo 4: Retrasos en la restauración que afectan la disponibilidad del sistema si no existen procedimientos documentados o pruebas previas de recuperación.
-
Riesgo 5: Sobrecarga del sistema durante el proceso de respaldo, lo que puede generar lentitud o interrupciones si no se realiza en horarios planificados.