RA5 de Programación de Servicios y Procesos · DAM

Protege las aplicaciones y los datos definiendo y aplicando criterios de seguridad en el acceso, almacenamiento y transmisión de la información.

Comprobar mi dominio con José →

Resumen Ejercicios Examen Flashcards

Contenido verificado asociado a este RA

Principios de Programación Segura y Ciclo de Vida del Desarrollo Seguro (SDLC)

Esta unidad introduce los principios fundamentales para desarrollar software seguro desde el diseño, identificando vulnerabilidades comunes y aplicando prácticas que previenen ataques. Se enfatiza la importancia de integrar la seguridad en cada fase del ciclo de vida del desarrollo de software.

Criptografía para la Protección de Datos Almacenados

Esta unidad explora las técnicas criptográficas fundamentales, diferenciando entre cifrado simétrico y asimétrico, y su aplicación práctica para proteger la confidencialidad e integridad de la información persistente. Se cubren los algoritmos más comunes y su uso adecuado para el almacenamiento seguro de datos.

Control de Acceso Basado en Roles (RBAC) y Políticas de Seguridad

Esta unidad aborda la implementación de políticas de seguridad para controlar el acceso de usuarios a las aplicaciones, centrándose en el modelo de Control de Acceso Basado en Roles (RBAC). Se explica cómo definir roles, asignar permisos y gestionar la autorización de forma eficiente y segura.

Seguridad en la Transmisión de Información con Sockets Seguros (TLS)

Esta unidad trabaja los métodos para asegurar la información transmitida por red (CE f) y el desarrollo de aplicaciones con sockets seguros (CE g). Se explica el protocolo TLS, su proceso de negociación (handshake), las diferencias entre TLS 1.2 y TLS 1.3, y cómo implementar clientes y servidores seguros en Java y Python, incluyendo errores frecuentes de configuración y su corrección.

Conceptos clave

Principios de seguridad (mínimo privilegio, defensa en profundidad, fail-safe)Validación de entradasGestión de sesionesSDLC seguroAnálisis estático y dinámico de códigoCifrado simétrico (AES)Cifrado asimétrico (RSA)Funciones hash criptográficas (SHA-256, bcrypt)Salt y PepperFirmas digitalesKey Management System (KMS)Autenticación vs. AutorizaciónPolíticas de seguridadControl de Acceso Basado en Roles (RBAC)Roles, Permisos, UsuariosGranularidad de permisosTLS y su relación con SSLHandshake TLS 1.2 (RSA) frente a TLS 1.3 (ECDHE)

Errores que conviene evitar

Asignar permisos excesivos: Causa: Facilidad de desarrollo o desconocimiento del principio de mínimo privilegio. Corrección: Auditar y restringir permisos a lo estrictamente necesario para cada componente o usuario.
Confiar solo en la validación del lado del cliente: Causa: Creencia errónea de que es suficiente o desconocimiento de cómo un atacante puede eludirla. Corrección: Implementar siempre validación robusta en el lado del servidor para todas las entradas.
Revelar información sensible en mensajes de error: Causa: Facilidad para la depuración durante el desarrollo. Corrección: Configurar la aplicación para mostrar mensajes de error genéricos al usuario final y registrar los detalles internamente.
Almacenar claves de cifrado junto con los datos cifrados: Causa: Simplificación del diseño o desconocimiento de la importancia de la separación de responsabilidades. Corrección: Utilizar un KMS o un almacén de secretos dedicado y seguro para las claves.
Usar algoritmos de hash débiles para contraseñas: Causa: Desconocimiento de las vulnerabilidades de MD5/SHA-1 o uso de librerías obsoletas. Corrección: Migrar a algoritmos modernos como bcrypt, scrypt o Argon2, que son más resistentes a ataques de fuerza bruta.
No usar 'salt' con los hashes de contraseñas: Causa: Desconocimiento del ataque de tablas arcoíris. Corrección: Generar un 'salt' aleatorio y único para cada contraseña y almacenarlo junto con el hash.
Hardcodear permisos por ID de usuario: Causa: Solución rápida y no escalable. Corrección: Implementar RBAC para gestionar permisos de forma flexible y escalable.
No separar autenticación de autorización: Causa: Confusión entre verificar quién es el usuario y qué puede hacer. Corrección: Asegurarse de que la autenticación se complete antes de que se evalúen las reglas de autorización.

Qué se evalúa en este RA

CE a

Se han identificado y aplicado principios y prácticas de programación segura.

CE b

Se han analizado las principales técnicas y prácticas criptográficas.

CE c

Se han definido e implantado políticas de seguridad para limitar y controlar el acceso de los usuarios a las aplicaciones desarrolladas.

CE d

Se han utilizado esquemas de seguridad basados en roles.

CE e

Se han empleado algoritmos criptográficos para proteger el acceso a la información almacenada.

CE f

Se han identificado métodos para asegurar la información transmitida.

CE g

Se han desarrollado aplicaciones que utilicen sockets seguros para la transmisión de información.

CE h

Se han depurado y documentado las aplicaciones desarrolladas.