Mapa de dependencias de los servicios esenciales

4 tareas · 38 min · Principiante

DNS, tiempo, correo y directorio son los cimientos invisibles sobre los que reposa toda la seguridad corporativa. Lees el mapa de dependencias de Transportes Caracolí para entender cómo la caída de un servicio raíz paraliza el negocio.

0 de 4 · 0%

Objetivo de la sala

Los servicios esenciales rara vez figuran en los diagramas de arquitectura de aplicaciones, pero son dependencias críticas de casi cualquier protocolo de seguridad. Kerberos requiere sincronización horaria precisa; las validaciones de certificados TLS dependen de resolución de nombres hacia servicios OCSP; y la autenticación de usuarios colapsa si el directorio activo no responde. Mapear explícitamente estas dependencias permite diseñar mecanismos de desacoplamiento y tolerancia a fallos.

Responde para continuar

¿Por qué es indispensable que el arquitecto documente las dependencias de DNS, tiempo y directorio?

Para permitir que los usuarios configuren manualmente sus propios servidores DNS Para eliminar la necesidad de contar con servidores de base de datos Para prever efectos de cascada y diseñar mecanismos de contingencia antes de que ocurra una caída

Ver pista de ayuda

Analiza el impacto sistémico cuando un servicio raíz deja de responder a las aplicaciones.

El protocolo de autenticación Kerberos utiliza marcas de tiempo en sus boletos (tickets) para prevenir ataques de repetición. Un desfase superior a cinco minutos bloquea el inicio de sesión en todo el dominio.

Abre el laboratorio y lee mapa-dependencias.txt. Identifica qué servicio esencial raíz provoca fallos de tokens y rechazo de logins ante una desviación horaria.

Esta tarea se hace en el laboratorio

Un escritorio Linux con terminal, aquí en la página. No instalas nada y no puedes romper nada.

Preparando el escritorio…

Responde para continuar

¿Qué servicio esencial raíz figura como causante directo de fallos en autenticación Kerberos ante desfases? Escribe su nombre.

Ver pista de ayuda

Consulta la primera fila del mapa de dependencias.

Analizar fallos del pasado permite identificar qué componentes carecen de aislamiento o redundancia suficiente.

Examina analisis-cascada.txt y localiza el código del incidente histórico originado por la caída del servidor DNS interno.

Esta tarea se hace en el laboratorio

Un escritorio Linux con terminal, aquí en la página. No instalas nada y no puedes romper nada.

Preparando el escritorio…

Responde para continuar

¿Qué código de incidente corresponde a la caída de DNS interno que arrastró al Directorio Activo y Oracle? Escribe el código.

Ver pista de ayuda

Revisa la primera columna en la tabla de análisis de cascada.

El principio de economía de mecanismo y fallo seguro exige que las aplicaciones cuenten con cachés locales y modos degradados para no detenerse de forma inmediata ante una intermitencia de red.

Responde para continuar

¿Qué patrón de arquitectura evita que una interrupción breve de DNS paralice los servicios transaccionales?

Configurar todas las conexiones de base de datos mediante direcciones IP fijas sin nombres de host Implementación de resolutores DNS locales en caché (sidecar/local resolver) con TTLs adecuados Conectar los servidores de aplicaciones directamente a servidores DNS públicos no filtrados

Ver pista de ayuda

Considera una solución que mantenga resolución local rápida y resiliente.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

Preparando el escritorio…

Objetivo: arquitectura.caracoli-transporte.local

16:24

Terminal (user@whoami)

Tab Autocompletar ↑/↓ Historial

bash 5.2.21

Whoami-Labs OS v3.0.1 LTS · build 733482

1 La fragilidad de los servicios de infraestructura base

2 Servicios raíz que comprometen Kerberos Lab

3 Incidentes históricos en cascada Lab

4 Estrategia de desacoplamiento

Whoami-Labs Pro utiliza cookies