30. Seguridad, privacidad y confiabilidad desde el diseño

30.1 Introducción

En la Ingeniería de Software moderna, no alcanza con que un sistema funcione en condiciones ideales. El software también debe proteger la información, respetar la privacidad de las personas y mantenerse disponible y correcto frente a fallas, errores o usos inesperados.

Seguridad, privacidad y confiabilidad son atributos de calidad que deben considerarse desde el inicio del proyecto. Si se intentan agregar al final, suelen aparecer soluciones incompletas, costosas o difíciles de integrar.

30.2 Seguridad de software

La seguridad de software consiste en proteger un sistema contra accesos no autorizados, uso indebido, alteración de datos, interrupciones del servicio y otras amenazas que puedan afectar a la organización o a sus usuarios.

Un sistema seguro reduce la probabilidad de incidentes y limita el impacto cuando ocurre un problema. Para lograrlo, la seguridad debe estar presente en los requerimientos, el diseño, la construcción, las pruebas, el despliegue y la operación.

30.3 Privacidad

La privacidad se relaciona con el tratamiento responsable de los datos personales. Implica definir qué información se recolecta, por qué se necesita, quién puede acceder a ella, durante cuánto tiempo se conserva y cómo se protege.

Un sistema puede ser técnicamente seguro y, aun así, tener problemas de privacidad si recolecta datos innecesarios, los usa para fines no informados o los expone a personas que no deberían acceder a ellos.

30.4 Confiabilidad

La confiabilidad es la capacidad de un sistema para funcionar correctamente durante un período de tiempo y bajo condiciones definidas. Un sistema confiable responde de manera previsible, maneja errores adecuadamente y evita perder información ante fallas.

La confiabilidad no significa que nunca ocurrirán problemas. Significa que el sistema está diseñado para reducir fallas, detectarlas, recuperarse y mantener un comportamiento aceptable.

30.5 Diferencias y relación entre los tres conceptos

Concepto Pregunta principal Ejemplo
Seguridad ¿El sistema está protegido contra accesos, ataques o usos indebidos? Solo usuarios autorizados pueden modificar datos sensibles.
Privacidad ¿Los datos personales se tratan de forma responsable y limitada? El sistema no solicita datos que no necesita para brindar el servicio.
Confiabilidad ¿El sistema funciona de forma estable y se recupera ante fallas? Una operación interrumpida no deja datos inconsistentes.

30.6 Diseñar desde el inicio

Diseñar desde el inicio significa tomar decisiones tempranas que reduzcan riesgos. Por ejemplo, definir roles de usuario, proteger datos sensibles, registrar eventos importantes, validar entradas y preparar mecanismos de recuperación.

Cuando estos aspectos se dejan para el final, el equipo puede descubrir que la arquitectura, los flujos de datos o los componentes elegidos no permiten cumplir los objetivos de seguridad, privacidad o confiabilidad sin cambios profundos.

Principio clave: la seguridad, la privacidad y la confiabilidad no son accesorios. Son decisiones de diseño que afectan a todo el ciclo de vida del software.

30.7 Amenazas y riesgos

Una amenaza es una situación que puede causar daño al sistema. Un riesgo combina la probabilidad de que esa amenaza ocurra con el impacto que tendría si se materializa.

  • Acceso no autorizado a cuentas de usuario.
  • Robo, pérdida o exposición de datos personales.
  • Manipulación de información crítica.
  • Interrupción del servicio por fallas o ataques.
  • Errores de configuración en ambientes productivos.
  • Uso indebido de privilegios por parte de usuarios internos.

30.8 Principios básicos de diseño seguro

  • Mínimo privilegio: cada usuario o componente debe tener solo los permisos necesarios.
  • Defensa en profundidad: combinar varias capas de protección.
  • Validación de entradas: no confiar automáticamente en datos recibidos desde formularios, archivos o servicios externos.
  • Fallas seguras: ante un error, el sistema debe evitar exponer datos o conceder permisos indebidos.
  • Registro y auditoría: guardar eventos relevantes para investigar incidentes y detectar comportamientos anómalos.
  • Simplicidad: diseños innecesariamente complejos suelen ser más difíciles de proteger y revisar.

30.9 Autenticación y autorización

La autenticación verifica quién es el usuario. La autorización define qué acciones puede realizar una vez identificado. Confundir estos conceptos puede producir fallas graves.

Por ejemplo, iniciar sesión correctamente no significa que el usuario pueda acceder a cualquier pantalla o modificar cualquier dato. El sistema debe comprobar permisos en cada operación sensible, no solo al ingresar.

30.10 Protección de datos

Los datos deben protegerse durante su captura, almacenamiento, procesamiento y transmisión. Esto incluye datos personales, credenciales, información financiera, registros médicos, documentos internos y cualquier información cuyo acceso indebido pueda causar daño.

  • Recolectar solo los datos necesarios.
  • Restringir el acceso según roles y responsabilidades.
  • Proteger credenciales y datos sensibles.
  • Usar canales seguros para transmitir información.
  • Definir políticas de retención y eliminación de datos.
  • Evitar mostrar información sensible en mensajes de error o registros públicos.

30.11 Privacidad por diseño

La privacidad por diseño propone considerar la protección de datos desde la concepción del sistema. Esto implica pensar la privacidad como un requisito básico, no como una corrección posterior.

Algunas prácticas son minimizar datos, informar claramente el uso de la información, separar datos sensibles, limitar accesos y permitir que las personas comprendan qué ocurre con sus datos.

30.12 Confiabilidad y manejo de fallas

Todo sistema puede fallar: una base de datos puede no responder, una red puede interrumpirse, un servicio externo puede demorar demasiado o una operación puede recibir datos inesperados. La confiabilidad depende de cómo se anticipan y manejan esas situaciones.

  • Validar datos antes de procesarlos.
  • Evitar estados inconsistentes ante interrupciones.
  • Registrar errores con información suficiente para analizarlos.
  • Mostrar mensajes comprensibles al usuario.
  • Definir mecanismos de reintento cuando tenga sentido.
  • Preparar copias de seguridad y planes de recuperación.

30.13 Disponibilidad y recuperación

La disponibilidad indica que el sistema está operativo cuando los usuarios lo necesitan. La recuperación se relaciona con la capacidad de volver a un estado funcional después de una falla.

En sistemas críticos, estas decisiones deben planificarse explícitamente: respaldos, monitoreo, redundancia, procedimientos de restauración, pruebas de recuperación y comunicación ante incidentes.

30.14 Registro, monitoreo y auditoría

Los registros permiten analizar qué ocurrió en el sistema. El monitoreo ayuda a detectar problemas en tiempo real. La auditoría permite revisar acciones relevantes, especialmente cuando se trabaja con información sensible o procesos críticos.

Estos mecanismos deben diseñarse con cuidado: registrar demasiado puede generar ruido o exponer datos sensibles; registrar muy poco puede impedir investigar fallas o incidentes.

30.15 Seguridad y confiabilidad en el ciclo de vida

Actividad Cómo se incorpora
Requerimientos Definir restricciones de acceso, protección de datos, disponibilidad y recuperación.
Diseño Elegir arquitectura, roles, flujos de datos y mecanismos de protección.
Construcción Validar entradas, manejar errores, proteger credenciales y revisar código.
Pruebas Verificar permisos, fallas, recuperación, límites, datos inválidos y escenarios de abuso.
Operación Monitorear, actualizar, responder incidentes, respaldar y revisar eventos.

30.16 Ejemplo práctico

Supongamos una aplicación para gestionar turnos médicos. Además de permitir reservar y cancelar turnos, el sistema debe proteger información personal y médica, mostrar datos solo a usuarios autorizados y mantener disponibilidad razonable para pacientes y personal administrativo.

  • Un paciente solo puede ver sus propios turnos.
  • Un profesional accede únicamente a la información necesaria para la atención.
  • Los cambios importantes quedan registrados para auditoría.
  • Si falla el envío de una notificación, el turno confirmado no debe perderse.
  • Los datos sensibles no se muestran en mensajes de error.
  • Existen respaldos y procedimientos de recuperación.

30.17 Errores comunes

  • Agregar controles de seguridad solo al final del proyecto.
  • Confiar en que la interfaz ocultará acciones no permitidas.
  • Guardar o mostrar más datos personales de los necesarios.
  • No revisar permisos en operaciones internas o servicios.
  • No probar escenarios de falla, cortes o datos inválidos.
  • No tener registros suficientes para investigar incidentes.
  • No actualizar dependencias, servidores o componentes utilizados.

30.18 Buenas prácticas

  • Incluir seguridad, privacidad y confiabilidad en los requerimientos.
  • Identificar amenazas y riesgos desde etapas tempranas.
  • Aplicar mínimo privilegio en usuarios, servicios y componentes.
  • Proteger datos sensibles durante todo su ciclo de vida.
  • Diseñar mecanismos de recuperación ante fallas.
  • Revisar código, configuraciones y dependencias.
  • Monitorear el sistema en operación y responder incidentes con procedimientos definidos.

30.19 Qué debes recordar

  • La seguridad protege el sistema frente a accesos, ataques y usos indebidos.
  • La privacidad se centra en el tratamiento responsable de los datos personales.
  • La confiabilidad busca que el sistema funcione correctamente y se recupere ante fallas.
  • Estos atributos deben diseñarse desde el inicio del proyecto.
  • Un sistema útil también debe ser seguro, respetuoso de los datos y estable en operación.

30.20 Conclusión

Seguridad, privacidad y confiabilidad son responsabilidades centrales de la Ingeniería de Software. No dependen solo de herramientas o configuraciones, sino de decisiones conscientes durante todo el ciclo de vida del producto.

En el próximo tema veremos documentación técnica y comunicación del conocimiento, dos elementos fundamentales para que el software pueda comprenderse, mantenerse, evolucionar y ser usado por distintos actores.

Volver al índice