Segunda entrega de proyecto
En esta entrega expandes el informe que comenzaste en la primera entrega incorporando los conceptos del Bloque 2. Entregas una nueva versión del mismo documento PDF, ahora con cuatro capítulos adicionales que cubren cómo protegerás técnicamente tu sistema.
Qué entregas
Un documento PDF actualizado que contiene:
- Los capítulos de la primera entrega, revisados si recibiste retroalimentación
- Cuatro capítulos nuevos correspondientes al Bloque 2 (clases 05 a 08)
No es un documento nuevo ni un resumen de lo anterior: es el mismo informe, ampliado.
Estructura del documento
Capítulos que ya existen (de la primera entrega)
Revísalos e incorpora la retroalimentación recibida. Si algo cambió en tu comprensión del proyecto, actualízalo.
- Capítulo 1: Descripción del proyecto
- Capítulo 2: Contexto de ciberseguridad (activos, amenazas, actores, principios CIAAN)
- Capítulo 3: Riesgos identificados y consecuencias
Capítulos nuevos (Bloque 2)
Capítulo 4: Criptografía y protección de datos
Aplica los conceptos de la clase 08. Parte de los datos, no de las herramientas: la pregunta no es «¿qué algoritmos conozco?», sino «¿qué dato es este, qué le puede pasar y qué lo protege?».
- ¿Qué datos de tu sistema son sensibles? Parte de los activos que identificaste en el capítulo 2 y di, para cada dato, dónde está: viajando por una red o guardado (en la base de datos, en un disco, en una copia de seguridad).
- Para cada dato sensible: ¿qué le puede pasar (que alguien lo lea, lo cambie o se haga pasar por quien lo envió), qué principio de CIAAN está en juego y qué mecanismo lo sostiene? Especifica el algoritmo cuando aplique (por ejemplo, AES-256 para datos guardados).
- ¿Cómo se almacenarán las contraseñas de los usuarios? Especifica el algoritmo y explica qué problema resuelve el salt y qué problema resuelve la lentitud del algoritmo.
- Si cifras datos guardados, ¿dónde vive la clave? Explica por qué ese lugar no cae en el mismo robo que los datos que protege.
- ¿Todas las comunicaciones de tu sistema van por HTTPS (TLS)? Si tu sistema se conecta a servicios externos (una API de terceros, un servicio de IA), ¿verifica sus certificados?
- ¿Hay algún documento o dato cuyo autor o integridad deba poder demostrarse después (un comprobante, una constancia, un registro)? Si lo hay, explica si necesita firma digital; si no lo hay, dilo y justifica por qué.
- Para cada mecanismo que propones, ¿qué no protege? Usa la columna «lo que no da» de la tabla que completamos en la clase.
Capítulo 5: Seguridad en la aplicación
Aplica los conceptos de la clase 05.
- ¿Qué vulnerabilidades del OWASP Top 10 son relevantes para tu proyecto? Justifica cuáles y por qué.
- ¿Cómo aplicas validación de entradas, autenticación segura y autorización correcta?
- ¿Cómo integras la seguridad en el ciclo de desarrollo (DevSecOps)?
- ¿Qué tipo de pruebas de seguridad realizarías antes de lanzar el sistema?
Capítulo 6: Control de acceso
Aplica los conceptos de la clase 06.
- ¿Qué roles existen en tu sistema y qué puede hacer cada uno?
- ¿Qué modelo de control de acceso elegiste (DAC, MAC, RBAC)? Justifica la elección.
- Presenta la matriz de permisos completa (roles × recursos con operaciones CRUD).
- ¿Cómo aplicas el principio de privilegio mínimo? Da ejemplos concretos.
- ¿Qué riesgos introduce una configuración incorrecta de permisos en tu caso específico?
Capítulo 7: Arquitectura e infraestructura
Aplica los conceptos de la clase 07. Este capítulo se construye hablando con tus compañeros de Ingeniería de Software e IA: describe lo que tu equipo va a construir, no una aplicación web cualquiera.
- Incluye un diagrama de arquitectura de tu sistema: frontend, backend/API, base de datos, servicios externos (si los hay) y dónde correrá (un servidor propio, la nube). Indica en el diagrama por dónde viaja cada comunicación y qué protección criptográfica del capítulo 4 aplica en cada punto.
- Identifica las superficies de ataque: ¿por dónde puede intentar entrar un atacante? Justifica cuál es la más importante en tu sistema.
- Lista al menos cuatro endpoints principales de tu API. Para cada uno: la URL, el método (GET, POST, etc.), qué dato recibe o devuelve y qué verificación de autorización necesita para que un usuario no pueda ver ni modificar datos que no le corresponden.
- Para al menos uno de esos endpoints, describe qué pasaría si el backend no hiciera esa verificación (qué dato de otra persona quedaría expuesto, o qué acción quedaría disponible sin permiso) y qué cambio de diseño lo evita.
- Responde, para tu sistema, la pregunta de seguridad central de cada capa: ¿qué información sensible guarda el frontend en el navegador?, ¿cada endpoint verifica que quien pide algo tiene permiso para pedir justamente eso?, ¿quién tiene acceso a la base de datos además del backend?
Criterios de evaluación
1. Revisión y evolución desde la primera entrega (10 puntos)
| Nivel | Descripción | Puntos |
|---|---|---|
| Excelente | Los capítulos anteriores fueron revisados incorporando retroalimentación con evidencia de mejora | 9–10 |
| Bueno | Se incorporaron algunos ajustes; la evolución es visible | 7–8 |
| Suficiente | Los capítulos anteriores no cambiaron, sin justificación | 5–6 |
| Insuficiente | Se ignoran los capítulos anteriores o el documento parece empezar de cero | 0–4 |
2. Criptografía y protección de datos (20 puntos)
| Nivel | Descripción | Puntos |
|---|---|---|
| Excelente | Identifica los datos sensibles del sistema a partir de sus activos, y para cada uno justifica el mecanismo desde lo que le puede pasar y el principio de CIAAN en juego; especifica algoritmo, dónde aplica, dónde vive la clave y qué no protege cada mecanismo | 18–20 |
| Bueno | Cubre la mayoría de los datos sensibles con mecanismos apropiados y contraseñas con un hash lento con salt; alguna decisión carece de justificación o no dice dónde vive la clave | 14–17 |
| Suficiente | Menciona cifrado o hashing de forma genérica sin especificar cómo ni dónde | 9–13 |
| Insuficiente | No considera protección criptográfica o propone mecanismos incorrectos para el contexto | 0–8 |
3. Seguridad en la aplicación (25 puntos)
| Nivel | Descripción | Puntos |
|---|---|---|
| Excelente | Identifica vulnerabilidades OWASP relevantes al proyecto, propone controles técnicos específicos y muestra comprensión del ciclo DevSecOps | 23–25 |
| Bueno | Cubre las principales vulnerabilidades con controles pertinentes; profundidad mejorable en algunos puntos | 18–22 |
| Suficiente | Vulnerabilidades mencionadas de forma genérica; controles vagos o no aplicados al contexto | 12–17 |
| Insuficiente | Análisis superficial o vulnerabilidades irrelevantes para el sistema | 0–11 |
4. Control de acceso (25 puntos)
| Nivel | Descripción | Puntos |
|---|---|---|
| Excelente | Modelo justificado, roles completos, matriz de permisos detallada, privilegio mínimo aplicado consistentemente, riesgos de mala configuración analizados | 23–25 |
| Bueno | Modelo aplicado, roles definidos, matriz presente, privilegio mínimo en la mayoría de casos | 18–22 |
| Suficiente | Roles básicos, matriz incompleta, aplicación inconsistente del privilegio mínimo | 12–17 |
| Insuficiente | Sin modelo coherente o sin matriz | 0–11 |
5. Arquitectura e infraestructura (20 puntos)
| Nivel | Descripción | Puntos |
|---|---|---|
| Excelente | Diagrama propio del sistema con todos sus componentes y comunicaciones; superficies de ataque identificadas y priorizadas; endpoints con su verificación de autorización y un caso de falla analizado; preguntas de seguridad por capa respondidas para el sistema concreto | 18–20 |
| Bueno | Diagrama presente, la mayoría de superficies de ataque cubiertas, endpoints listados con autorización; el análisis de falla o alguna capa queda superficial | 14–17 |
| Suficiente | Diagrama genérico (válido para cualquier aplicación web) o solo descripción textual; superficies de ataque generales; endpoints sin verificación de autorización | 9–13 |
| Insuficiente | Sin diagrama, sin endpoints o sin análisis de superficies de ataque | 0–8 |
Formato sugerido para la matriz de permisos
| Recurso / Rol | Administrador | Usuario registrado | Usuario invitado | Sistema externo |
|---|---|---|---|---|
| Base de datos de usuarios | CRUD | R (solo sus datos) | — | — |
| API principal | CRUD | CR | R | R |
| Panel de administración | CRUD | — | — | — |
| Logs del sistema | R | — | — | — |
C = Crear, R = Leer, U = Actualizar, D = Eliminar
Checklist antes de entregar
- Los capítulos 1–3 de la primera entrega están revisados e incorporan retroalimentación
- El capítulo 4 especifica qué datos se protegen, con qué mecanismo y algoritmo, y si viajan o están guardados
- Las contraseñas de usuarios se almacenan con un hash lento con salt (bcrypt o Argon2), no con SHA-256 ni MD5
- El capítulo 4 dice dónde vive cada clave y qué no protege cada mecanismo
- El capítulo 5 menciona al menos 3 vulnerabilidades OWASP relevantes con controles concretos
- El capítulo 6 incluye una matriz de permisos completa con todos los roles y recursos del sistema
- El capítulo 6 justifica el modelo de control de acceso elegido
- El capítulo 7 incluye un diagrama de arquitectura de tu sistema (no genérico)
- El capítulo 7 lista al menos cuatro endpoints con su verificación de autorización
- Todos los capítulos nuevos hacen referencia al proyecto específico, no a sistemas genéricos
Errores comunes a evitar
-
Proponer cifrado sin especificarlo: «Cifraremos los datos sensibles» no es suficiente. ¿Cuáles datos? ¿Con qué algoritmo? ¿Dónde se guarda la clave?
-
Copiar las tablas de la clase: La tabla «qué proteger» de la clase 08 es cierta para cualquier aplicación web, y por eso no dice nada de la tuya. Tus datos, y lo que les puede pasar, son los de tu proyecto.
-
Copiar la matriz de permisos del ejemplo: La matriz debe reflejar los roles reales de tu proyecto. Un sistema de salud tiene roles distintos a un e-commerce.
-
Diagrama de arquitectura genérico: «Cliente → Servidor → BD» describe cualquier sistema web. El tuyo debe mostrar sus componentes específicos, sus servicios externos y dónde aplica cada protección.
-
Confiar en el frontend: Ocultar un botón o validar un formulario en el navegador no protege nada. Toda verificación que importa ocurre en el backend.
-
Ignorar la primera entrega: Esta entrega la incluye y mejora. Si los capítulos 1–3 tienen los mismos errores que antes, ese criterio se evaluará negativamente.
-
Tratar los capítulos como secciones independientes: Los datos sensibles del capítulo 4 salen de los activos del capítulo 2. El análisis de riesgos del capítulo 3 debe conectarse con las vulnerabilidades y controles del capítulo 5. Los roles y la matriz de permisos del capítulo 6 deben ser consistentes con lo que el capítulo 5 identificó como puntos débiles de control de acceso, y con la verificación de autorización de cada endpoint del capítulo 7.
Extensión recomendada
10–14 páginas en total (sin contar portada y referencias). Los capítulos nuevos deberían sumar aproximadamente 6–8 páginas.
Recursos útiles
- 05-seguridad-en-aplicaciones — Vulnerabilidades y ciclo DevSecOps
- 06-control-de-acceso — Modelos DAC, MAC, RBAC y matrices de permisos
- 07-panorama-tecnologico — Capas de una aplicación, APIs, endpoints y preguntas de seguridad por capa
- 08-criptografia-aplicada — Qué herramienta criptográfica para qué problema, y qué no da cada una
- 01-primera-entrega-de-proyecto — Revisa los criterios de la primera entrega
Navegación: ← Anterior | Inicio | Siguiente: Ética y legislación →