🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónEl modelo vive en el repositorio
4 tareas · 35 min · Principiante
Un modelo de amenazas que vive en una presentación envejece el día que se guarda. La cuarta pregunta —si lo hecho fue suficiente— solo se contesta si el modelo sigue siendo el del sistema, y eso pasa cuando vive donde vive el código: en el repositorio, versionado, revisado con los mismos cambios que lo alteran. En esta sala abres el repositorio de Farolito Reservas, lees cómo guarda su modelo, cuándo dice que se revisa, y detectas un cambio fusionado que el modelo no recoge.
Objetivo de la sala
Un modelo de amenazas que vive en una presentación envejece el día que se guarda. La cuarta pregunta —si lo hecho fue suficiente— solo se contesta si el modelo sigue siendo el del sistema, y eso pasa cuando vive donde vive el código: en el repositorio, versionado, revisado con los mismos cambios que lo alteran. En esta sala abres el repositorio de Farolito Reservas, lees cómo guarda su modelo, cuándo dice que se revisa, y detectas un cambio fusionado que el modelo no recoge.Guardar el modelo junto al código tiene tres ventajas que ninguna otra ubicación da a la vez. Se versiona: cada cambio queda con fecha y autor, y se puede ver qué se pensaba hace seis meses. Se revisa: quien propone un cambio de diseño puede tocar el modelo en la misma propuesta, y quien la revisa lo ve junto. Y está a mano: nadie tiene que pedir permiso a otro equipo para consultarlo.
Los archivos son de texto sencillo —listas y tablas en un formato legible— para que una diferencia entre dos versiones se lea sin herramientas especiales.
Responde para continuar
¿Qué gana un modelo de amenazas al vivir en el repositorio, junto al código?
Ver pista de ayuda
Piensa en lo que ya hace el repositorio con cualquier archivo: guardar versiones y revisar cambios.
No hace falta revisar el modelo con cada propuesta de cambio: corregir un redondeo o cambiar un texto no toca la arquitectura. Sí obliga a revisarlo cualquier cambio que altere lo que el diagrama dice: un flujo nuevo, un almacén nuevo, un tercero nuevo, una forma distinta de autenticar o una frontera que se mueve. Son los cuatro o cinco disparadores que conviene dejar escritos en el propio modelo, para que quien abra un cambio los reconozca sin ser experto.
Además de esos disparadores, una revisión programada —cada seis meses, por ejemplo— cubre lo que se movió poco a poco sin que nadie lo notara.
Responde para continuar
¿Cuál de estos cambios obliga a revisar el modelo de amenazas?
Ver pista de ayuda
Busca el que altera lo que dice el diagrama: un flujo, un almacén o un tercero nuevo.
Abre el repositorio de Farolito con la terminal. Hay una carpeta con el modelo y otra con el historial de cambios fusionados desde su última revisión. Lee primero qué terceros y qué flujos documenta el diagrama del modelo y compara con el historial. Un cambio que añade comunicación con alguien que el modelo no nombra es justo lo que el modelo está para frenar.
El historial se compara con el modelo igual que se compara un inventario con lo que hay en la estantería.
Responde para continuar
¿Qué cambio fusionado añade un flujo hacia un tercero que el diagrama del modelo no documenta? Escribe su identificador.
Formato esperado: FUS-___
Ver pista de ayuda
Con la terminal, `cat modelo-de-amenazas/dfd.md` y `cat historial/cambios-fusionados.txt`. Compara los terceros de uno con los del otro.
Un modelo dice de sí mismo cuándo se revisó por última vez. Ese dato, junto con el historial, es lo que permite saber cuánta deriva hay entre el diagrama y el sistema. El LEEME del modelo de Farolito lo recoge junto con las reglas de cuándo se revisa. Léelo y anota la fecha de la última revisión completa.
Sin fecha de última revisión no hay forma de saber si el modelo está al día o solo parece que sí.
Responde para continuar
¿En qué fecha fue la última revisión completa del modelo de Farolito? Escribe la fecha como figura en el archivo.
Ver pista de ayuda
Con la terminal, `cat modelo-de-amenazas/LEEME.md`. La fecha está en la línea «Ultima revision completa».
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.