Qué puede evaluarse
RA1: Desarrolla aplicaciones compuestas por varios procesos reconociendo y aplicando principios de programación paralela.
ConcurrenciaParalelismoDistribuciónMultitareaCambio de contextoRecursos compartidosEscalabilidadTolerancia a fallosProcesoHilo de ejecución (Thread)
RA2: Desarrolla aplicaciones compuestas por varios hilos de ejecución analizando y aplicando librerías específicas del lenguaje de programación.
ConcurrenciaParalelismoProcesoHilo (Thread)Método run()Método start()Interfaz RunnableClase ThreadRunnable vs Thread en una aplicación multihiloConcurrencia de tareas independientes
RA3: Programa mecanismos de comunicación en red empleando sockets y analizando el escenario de ejecución.
ClienteServidorComunicación en redAPI de redProtocoloIPPuertoSocketTCP (Transmission Control Protocol)UDP (User Datagram Protocol)
RA4: Desarrolla aplicaciones que ofrecen servicios en red, utilizando librerías de clases y aplicando criterios de eficiencia y disponibilidad.
Protocolo de redCapa de AplicaciónHTTPFTPSocketURLAPI RESTCliente de redLibrería de clasesServidor de red
RA5: Protege las aplicaciones y los datos definiendo y aplicando criterios de seguridad en el acceso, almacenamiento y transmisión de la información.
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 digitales
Trampas habituales antes del examen
- 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.
- Permisos demasiado amplios para roles: Causa: Simplificación excesiva. Corrección: Definir roles con el principio de mínimo privilegio, asignando solo los permisos estrictamente necesarios para la función del rol.
- Desactivar la verificación de certificados o el chequeo de hostname: causa habitual, evitar fallos con certificados autofirmados en desarrollo; corrección, validar siempre en producción y usar certificados de desarrollo correctamente confiados (OpenSSL/mkcert).
- Permitir TLS 1.0/1.1 en la configuración del socket: causa, compatibilidad heredada o falta de actualización; corrección, exigir como mínimo TLS 1.2 y preferir TLS 1.3.
- Usar ssl.wrap_socket() en Python en lugar de SSLContext: causa, seguir ejemplos desactualizados; corrección, emplear SSLContext.wrap_socket(), que permite mayor control y sigue mantenido.