Security+ — Arquitectura y Diseño de Seguridad: 60 preguntas de práctica

Step 1: Evaluar requisitos de seguridad y compatibilidad: RSA‑2048 sigue siendo considerado seguro para firmas digitales en muchos entornos y es ampliamente compatible; combinarlo con SHA‑256 (o superior) para hashing evita debilidades de funciones hash antiguas.

Step 2: Considerar alternativas basadas en curva elíptica: ECDSA con la curva P‑256 y SHA‑256 ofrece similar nivel de seguridad con claves más cortas y firmas más compactas, lo que beneficia rendimiento y ancho de banda en sistemas distribuidos y dispositivos con recursos limitados.

Step 3: Evitar algoritmos y parámetros obsoletos: SHA‑1 y MD5 tienen colisiones conocidas y no deben usarse para integridad/firmas; RSA‑1024 ya no se considera seguro para muchos casos de uso y no ofrece resistencia a ataques avanzados. Trap: elegir algoritmos sólo por compatibilidad con sistemas legacy sin considerar debilidades criptográficas; usar SHA‑1 o MD5 puede parecer necesario para interoperabilidad pero compromete la seguridad fundamentalmente. Por qué cada opción falla o procede: Opción 1 (correcta): RSA‑2048 + SHA‑256 es una combinación segura y ampliamente soportada para firmas digitales en entornos híbridos; proporciona integridad y no repudio cuando se manejan correctamente las claves privadas. Opción 2 (incorrecta): SHA‑1 y RSA‑1024 son inseguros: SHA‑1 tiene colisiones prácticas y RSA‑1024 tiene un nivel de seguridad insuficiente ante actores con capacidades moderadas; no debe usarse para nuevas implementaciones. Opción 3 (correcta): ECDSA P‑256 + SHA‑256 ofrece seguridad moderna con menor tamaño de clave y mejor rendimiento en recursos limitados, siendo adecuada para firmas en servicios distribuídos y móviles. Opción 4 (incorrecta): MD5 está roto con colisiones prácticas y no es apropiado para integridad o firmas, incluso si se combina con RSA‑2048; la presencia de MD5 anula la seguridad. En resumen, seleccione algoritmos actuales y robustos (RSA ≥ 2048 con SHA‑256 o ECDSA P‑256 con SHA‑256) y deje atrás MD5/SHA‑1/RSA‑1024.

Step 1: Identificar amenazas en tránsito — ataques de interceptación (MITM), degradación de cifrado, compromiso de claves a largo plazo y ataques de manipulación/poisoning.

Step 2: Seleccionar protocolo y propiedades criptográficas — TLS 1.3 incorpora mejoras clave: simplifica el handshake, habilita por defecto intercambio de claves efímero (ECDHE) para Perfect Forward Secrecy (PFS), y usa cifras AEAD que combinan confidencialidad e integridad en una sola construcción robusta (AES‑GCM o ChaCha20‑Poly1305). Estos elementos mitigan riesgos de recuperación de sesiones pasadas y ataques contra modos CBC o algoritmos obsoletos.

Step 3: Implementación y operaciones — forzar TLS 1.3 en ambos extremos, deshabilitar suites y protocolos obsoletos (TLS 1.0/1.1, SSL), usar certificados válidos y mecanismos como certificate pinning o mTLS si se requiere autenticación mutua, y monitorear renegociaciones y configuraciones en load balancers. Trap: asumir que cualquier 'TLS' es seguro; versiones y suites antiguas quedan vulnerables a ataques conocidos. Por qué cada respuesta incorrecta falla: - Opción 2 (TLS 1.0 con RSA y CBC SHA‑1): TLS 1.0 y SHA‑1 están obsoletos con vulnerabilidades conocidas (POODLE, ataques contra CBC y colisiones); RSA estático no ofrece PFS, de modo que la clave privada comprometida permite descifrar tráfico previo. - Opción 3 (SSL v3 con RC4): SSL v3 está completamente deprecado y RC4 es inseguro (sesgo y ataques de recuperación de plaintext); usarlo expone la API a compromisos inmediatos. - Opción 4 (TLS 1.2 con RSA estático y CBC SHA‑1): aunque TLS 1.2 puede ser seguro con las suites apropiadas, usar intercambio RSA estático elimina PFS y CBC+SHA‑1 es susceptible a ataques; además obliga a una configuración menos robusta que TLS 1.3 con AEAD. En resumen, TLS 1.3 con ECDHE y AEAD es la mejor práctica actual para asegurar comunicaciones API en entornos híbridos: provee confidencialidad, integridad, resistencia a futuros compromisos de claves y mejores garantías criptográficas.

Step 1: Evaluar la función de la DMZ — la DMZ (zona desmilitarizada) es una red intermedia diseñada para exponer servicios públicos al Internet manteniendo segregados los sistemas internos sensibles. Su propósito es ralentizar y contener compromisos de servicios públicos sin exponer directamente la infraestructura interna.

Step 2: Analizar prácticas de diseño seguras — ubicar servidores públicos en la DMZ y aplicar reglas de firewall estrictas (mientras se minimizan los servicios y puertos expuestos) reduce la superficie de ataque. Una arquitectura con dos firewalls (uno perimetral y otro interno) crea una screened subnet que obliga a los atacantes a superar múltiples controles antes de alcanzar la red interna; además permite reglas diferentes en cada firewall (defensa en profundidad).

Step 3: Implementar controles complementarios — junto a la DMZ es recomendable aplicar detección/prevención (IDS/IPS), registros centralizados, hardsening de servidores, y segregación de funciones (administración por canales seguros). Trap: creer que colocar todo en la DMZ o abrir acceso facilita la operación sin riesgo; en realidad se incrementa la exposición y rompe la separación lógica. Por qué cada respuesta es correcta o falla: - Colocar servidores públicos (por ejemplo, servidor web) dentro de la DMZ y aplicar reglas de firewall estrictas y específicas para minimizar el acceso — Correcto: este es el uso clásico de la DMZ: exponer servicios públicos con reglas explícitas, limitando el alcance de cualquier compromiso y evitando acceso directo desde Internet a la red interna. - Situar la base de datos crítica que contiene información financiera directamente en la DMZ y permitir accesos desde Internet — Incorrecto: las bases de datos sensibles deben permanecer en la red interna protegida; exponer datos críticos en la DMZ incrementa el riesgo de exfiltración y suele violar requisitos de cumplimiento (p. ej., PCI-DSS). - Implementar una arquitectura con dos firewalls (screened subnet) dejando la DMZ entre el firewall perimetral y el interno — Correcto: la doble capa de firewalls ofrece separación adicional y permite políticas más estrictas hacia la red interna, aumentando la resiliencia ante un compromiso en la DMZ. - Permitir que sistemas en la DMZ tengan acceso irrestricto a la red interna para facilitar la gestión — Incorrecto: acceso irrestricto elimina el propósito de la DMZ y facilita el movimiento lateral hacia recursos internos tras un compromiso; la gestión debe realizarse mediante canales controlados y restringidos (p. ej., jump hosts, VPNs con controles). Además, aunque la implementación de IDS/IPS en la DMZ es una buena práctica, la pregunta pedía las prácticas de diseño más apropiadas: colocar servicios en DMZ con reglas restrictivas y usar arquitectura de dos firewalls son controles de diseño fundamentales; soluciones adicionales (IDS/IPS, WAF, registro) complementan pero no sustituyen la separación y el endurecimiento inicial. En resumen, las respuestas correctas reflejan principios de defensa en profundidad y segmentación adecuados para una DMZ segura.

Step 1: Evaluar el vector y el alcance. Cuando una máquina se compromete, el objetivo del atacante es moverse lateralmente hacia otros sistemas. La microsegmentación reduce la superficie al aplicar políticas estrictas entre cargas de trabajo individuales, no solo entre subredes.

Step 2: Aplicar controles a nivel de host y flujo. Host-based firewalls, agentes de microsegmentación y políticas basadas en identidad/servicio permiten bloquear conexiones no autorizadas entre VM/hosts, inspeccionar tráfico este-oeste y aplicar reglas dinámicas acorde con la postura de seguridad.

Step 3: Integrar con orquestación y detección. La microsegmentación se integra con herramientas de orquestación y SIEM para adaptar políticas automáticamente cuando cambian cargas de trabajo, y para bloquear inmediatamente comportamientos anómalos. Trap: Creer que VLANs o subredes tradicionales ofrecen el mismo nivel; la segmentación lógica de capa 2/3 no controla conexiones entre procesos dentro de la misma máquina o entre hosts en la misma VLAN tan finamente como la microsegmentación. Why each wrong answer fails: - Opción 2 (VLANs tradicionales con ACLs simples): VLANs segmentan por dominio lógico, pero las ACLs simples suelen ser demasiado permisivas y no acompañan la movilidad de las cargas (por ejemplo, VMs moviéndose entre hosts), además no controlan procesos individuales ni comunicación intra-host. - Opción 3 (Subredes independientes sin filtrado adicional): Simplemente poner sistemas en subredes separadas sin controles de filtrado o políticas adicionales deja rutas e interfaces abiertas y no previene conexiones maliciosas si un atacante controla un gateway o explota servicios permitidos. - Opción 4 (Red plana con firewall perimetral): Una red plana depende de la inspección solo en el perímetro; una vez inside, el atacante tiene libertad. Esto no limita el movimiento lateral ni protege las comunicaciones entre cargas de trabajo internas. Conclusión: en entornos empresariales modernos, especialmente con cargas dinámicas (VMs, contenedores, cloud híbrido), la microsegmentación basada en políticas a nivel de host proporciona el control más granular y adaptable para minimizar movimiento lateral tras un compromiso.

Step 1: Requerimientos técnicos — proteger data at rest requiere confidencialidad y verificación de integridad/tamper; además los servicios automatizados necesitan rendimiento y manejo de IV/nonce y claves.

Step 2: Evaluación de opciones criptográficas — AES en modo GCM proporciona cifrado simétrico con cifrado autenticado (AEAD) que integra confidencialidad y tag de autenticación; evita la necesidad de construir manualmente un esquema Encrypt‑then‑MAC y reduce errores de implementación.

Step 3: Implementación y gestión — use AES‑GCM con una correcta gestión de claves (KMS/HSM), rotación de claves, control de accesos y no reutilizar nonces; esto protege confidencialidad y detecta alteraciones. Trap: asumir que usar solo SHA‑256 o RSA resuelve el problema; SHA‑256 no cifra y RSA no es eficiente ni indicado para cifrar grandes volúmenes directamente. Por qué fallan las opciones incorrectas: AES‑CBC con HMAC separado (opción 1) puede proporcionar confidencialidad e integridad si se implementa correctamente (Encrypt‑then‑MAC), pero CBC es más propenso a errores de padding oracle, requiere coordinación separada de modos y es menos eficiente que AEAD; la gente a menudo implementa mal el orden MAC/ENC y provoca vulnerabilidades. RSA sin relleno (opción 3) es inseguro y no debe utilizarse para cifrado directo de archivos; RSA es ineficiente para grandes datos y requiere padding seguro (OAEP) cuando se usa para cifrado de claves o datos pequeños. SHA‑256 (opción 4) es una función hash que solo garantiza integridad/huella y no ofrece confidencialidad; además, para integridad autenticada es necesario uso de MAC o firmas. Resumen: AES‑GCM proporciona confidencialidad e integridad de forma eficiente y estandarizada; su uso combinado con una solución de gestión de claves robusta satisface los requisitos de acceso por múltiples servicios y reduce la probabilidad de errores criptográficos operacionales.

Step 1: Establecer federación SAML/OIDC entre el Active Directory on‑premises y el proveedor de identidad en la nube permite autenticación delegada: las credenciales se validan por el IdP corporativo y se emiten tokens (SAML, OIDC) para el acceso al servicio cloud sin sincronizar contraseñas ni almacenar hashes en múltiples lugares. Esto reduce la superficie de ataque frente a exfiltración de contraseñas y facilita auditoría centralizada.

Step 2: Implementar políticas de acceso condicional en el IdP en la nube (por ejemplo, requerir MFA en bases de riesgo como acceso desde fuera de la red, dispositivos no gestionados, o comportamientos anómalos) añade controles contextuales que mitigan el uso de credenciales comprometidas. MFA y evaluación de riesgo del dispositivo forman una capa adicional que bloquea el acceso incluso si la contraseña es robada.

Step 3: Combinar ambos (federación + políticas condicionales/MFA) ofrece SSO seguro y controles dinámicos que funcionan en entornos híbridos, permitiendo aplicar reglas uniformes para usuarios on‑prem y en cloud. Trap: pensar que sincronizar contraseñas (password sync) sin MFA es suficiente — aunque conveniente, replica credenciales y aumenta la blast radius si el repositorio es comprometido. Por qué cada opción falla o procede: Opción 1 (correcta): federación SAML/OIDC delega autenticación y reduce duplicación de credenciales; es la base para SSO seguro. Opción 2 (incorrecta): password sync sin MFA simplifica inicio de sesión pero duplica hashes/credenciales en la nube, amplifica riesgo y no satisface controles modernos de acceso condicional. Opción 3 (correcta): políticas de acceso condicional con MFA implementadas en el IdP protegen contra credenciales robadas y accesos anómalos; es una práctica recomendada para entornos híbridos. Opción 4 (incorrecta): exponer LDAP directamente a Internet es una mala práctica que expone el servicio a bruteforce, exploits y robo de credenciales; carece de controles contextuales y escala el riesgo. En conjunto, la federación más controles condicionales/MFA proporciona compatibilidad con SSO, seguridad y cumplimiento en entornos híbridos.

Step 1: Identificar requisitos técnicos y de cumplimiento — la organización necesita mantener control sobre las claves maestras (custodia, rotación y auditoría) mientras almacena datos en la nube; por tanto se requiere una solución que permita gestión local o bajo control del cliente.

Step 2: Evaluar opciones técnicas — usar un HSM y BYOK (Bring Your Own Key) integrado con el KMS del proveedor permite que el cliente posea las claves maestras, las guarde/gestione en un HSM certificado (FIPS 140-2/3) y las utilice para desencriptar/reencriptar datos en la nube sin exponer las claves al proveedor.

Step 3: Implementación y operaciones — integrar el HSM con el servicio KMS del proveedor, configurar políticas de rotación y acceso, habilitar registro y lectura de auditoría, y aplicar separación de funciones para la gestión de claves. Trap: creer que cualquier cifrado en la nube ofrece la misma gobernanza; la diferencia crítica es quién controla las claves y cómo se audita su uso. Por qué cada respuesta incorrecta falla: - Opción 2 (cifrado gestionado por el proveedor): falla porque el proveedor controla las claves maestras; no satisface requisitos de custodia ni cumplimiento cuando el cliente debe controlar la llave. - Opción 3 (cifrado a nivel de aplicación con clave en servidor on‑premise): aunque da control, centralizar la clave en un servidor de aplicación introduce un único punto de fallo, mayor superficie de ataque y complica escalado/alta disponibilidad en la nube; además no aprovecha HSM ni KMS. - Opción 4 (clave simétrica compartida sin rotación): inseguro por diseño: compartir una sola clave entre múltiples VMs sin rotación periódica o separación de acceso viola prácticas de seguridad (compromiso de clave compromete todo) y no cumple requisitos de auditoría/rotación. En resumen, BYOK con HSM permite control y cumplimiento, mantiene separación de funciones, soporta rotación y auditoría, y se integra técnicamente con servicios de cifrado en reposo del proveedor, por lo que es la opción apropiada para entornos híbridos que exigen custodia de claves del cliente.

Step 1: Evaluar requisitos de seguridad y operativos — la organización necesita SSO consistente hacia aplicaciones SaaS, MFA centralizado en la nube, y reducción de complejidad operativa.

Step 2: Comparar arquitecturas de identidad híbrida — Password Hash Sync (PHS) sincroniza un hash seguro de la contraseña on‑premise a Azure AD, permitiendo que Azure autentique directamente y aplique políticas como MFA, sin la complejidad de mantener infraestructura federada (AD FS) ni dependencias de disponibilidad. PHS reduce la carga de operación porque evita servidores de federación adicionales y facilita la integración con MFA en la nube.

Step 3: Implementación segura — habilitar PHS con sincronización segura, exigir MFA en Azure AD Conditional Access, monitorizar sign‑ins y compromisos de credenciales; complementar con mitigaciones como bloqueo de cuenta y detección de identidad comprometida. Trap: creer que cualquier federación es más segura por ser on‑premise; a menudo federación añade complejidad y puntos de fallo operativo si no se administra correctamente. Por qué cada respuesta incorrecta falla: - Opción 2 (AD FS con MFA on‑premise): aunque federación viene con control total, requiere infraestructura adicional (balanceadores, servidores de federación, certificados), alta disponibilidad y mantenimiento continuo; aumenta complejidad y coste, y contradice la exigencia de centralizar MFA en la nube. - Opción 3 (cuentas separadas y SSO manual): introduce mala experiencia de usuario, aumento de contraseñas y gestión de identidades duplicadas; incrementa riesgo de errores y soporte, además de incumplir SSO centralizado. - Opción 4 (sin sincronización y solo VPN): no es práctico para aplicaciones SaaS públicas; obligar a usuarios a estar en red corporativa reduce disponibilidad y no permite MFA en la nube ni SSO para usuarios remotos. En resumen, Password Hash Sync con MFA en la nube provee el equilibrio adecuado entre seguridad, cumplimiento y operaciones simplificadas en un entorno híbrido corporativo que consume aplicaciones SaaS.

Step 1: Seleccionar métodos de cifrado adecuados para datos en reposo. El cifrado simétrico como AES (Advanced Encryption Standard) en modos autenticados como GCM (Galois/Counter Mode) es la opción estándar para cifrar grandes volúmenes de datos en reposo porque ofrece confidencialidad y autenticidad/integridad a alta eficiencia. AES-GCM maneja vectores de inicialización (IV/nonce) y produce un tag de autenticación que detecta manipulaciones del ciphertext.

Step 2: Gestionar claves de forma segura. La protección del cifrado depende en gran medida de la gestión de claves: deben almacenarse y rotarse con seguridad, restringiendo acceso mediante políticas y roles. Un KMS (Key Management Service) o HSM (Hardware Security Module) proporciona almacenamiento seguro de claves, generación de claves fuerte, operaciones criptográficas sin exponer material de clave y capacidades de rotación/retirada automatizada. Integrar el KMS con la aplicación reduce la superficie de ataques y facilita auditorías.

Step 3: Evitar prácticas obsoletas o riesgosas. RSA-1024 se considera inseguros frente a capacidades modernas de cómputo y ataques criptográficos; además, RSA (cifrado asimétrico) no está optimizado para cifrar grandes volúmenes de datos—se usa típicamente para intercambio de claves y firmas. Guardar claves en archivos locales (incluso cifrados) en el servidor de aplicaciones es riesgoso: si el servidor se compromete, el atacante puede obtener las claves y descifrar los datos. Por tanto, el uso combinado de AES-GCM y KMS/HSM es la práctica recomendada. Trap: Una trampa común es confundir algoritmos asimétricos con simétricos como intercambiables para todas las cargas. Aunque RSA puede usarse para proteger claves (envolver claves), no es adecuado ni eficiente para cifrar volúmenes grandes, y usar claves pequeñas (RSA-1024) es vulnerable a factorización. Por qué fallan las opciones incorrectas: - Usar RSA-1024 para el cifrado de archivos grandes: RSA-1024 tiene dos problemas: seguridad insuficiente (1024-bit RSA está cerca o en el umbral de obsolescencia para muchas aplicaciones) y rendimiento inadecuado para datos en reposo. Las prácticas modernas recomiendan RSA-2048 o curvas elípticas para asimétrico, y cifrado simétrico (AES) para los datos. - Sustituir protección con HSMs/KMS por almacenamiento de claves en archivos de texto cifrados en el servidor: aunque parezca fácil, almacenar claves en el mismo servidor que las aplicaciones crea un punto único de fallo; si el host es comprometido, el atacante puede recuperar las claves y descifrar datos. Los HSM/KMS aíslan las claves y ofrecen controles de acceso, registros y operaciones seguras. Conclusión: Cifrar los datos en reposo con AES-GCM y administrar claves con un KMS/HSM (con rotación y políticas RBAC) ofrece confidencialidad, integridad y mejores garantías operacionales frente a soluciones caseras o algoritmos obsoletos.

Step 1: Evaluar requisitos y trade-offs. La organización necesita confidencialidad fuerte, control de claves (por razones de cumplimiento) y baja latencia. Eso apunta a un esquema donde las claves de datos se usan para el cifrado real (rápido) y las claves maestras están protegidas por un KMS/HSM (seguro), es decir envelope encryption. También se prioriza una variante de cifrado autenticada (GCM) para evitar problemas de integridad y autenticidad.

Step 2: Seleccionar controles criptográficos adecuados y situarlos correctamente. Usar AES-GCM como algoritmo de datos es eficiente y ofrece confidencialidad+autenticidad; cuando se emplea con aceleración hardware (AES-NI, motores AES en HSM), el impacto en latencia y CPU es bajo. Colocar la gestión de claves en un HSM o un servicio KMS con módulo de hardware proporciona control y separación de funciones. Implementar client-side encryption con claves por archivo/data key (envelope encryption) incrementa la protección ante compromisos de la nube y brinda granularidad de acceso.

Step 3: Concretar trade-offs y mitigaciones. Coste: HSM/KMS y desarrollo de client-side encryption implican mayor coste y complejidad operacional. Rendimiento: usar AES-GCM con aceleración reduce latencia; sin aceleración, el cifrado a gran escala puede afectar CPU. Seguridad: envelope encryption + HSM proporciona un fuerte modelo de seguridad y cumplimiento. Operación: rotación de claves y gestión de backups de claves maestras requieren procedimientos. Trap: Un error común es asumir que usar un algoritmo "fuerte" en software (por ejemplo AES-CBC) es suficiente y barato; CBC sin autenticación es propenso a ataques de padding y requiere manejo complejo de IV/AEAD, y el coste de CPU a gran escala puede ser mayor que pagar por aceleración hardware. Por qué cada respuesta falla o es correcta: - Opción 1 (AES-256-CBC en software): Incorrecta. Aunque AES es seguro, CBC no proporciona autenticidad (no es AEAD) y requiere manejo cuidadoso de IV y padding, lo que aumenta la complejidad y riesgo de errores. Además, la implementación en software a gran escala puede causar latencia y carga CPU significativa frente a soluciones con aceleración hardware. - Opción 2 (HSM + AES-GCM hardware, envelope encryption): Correcta. Combina control de claves (HSM/KMS) y rendimiento (AES-GCM con aceleración), y el patrón de envelope encryption permite cifrar datos con claves rápidas y proteger esas claves con la clave maestra en HSM; equilibra seguridad, rendimiento y control. - Opción 3 (RSA-4096 para cifrar archivos directamente): Incorrecta. Los algoritmos asimétricos como RSA no están diseñados para cifrar grandes volúmenes de datos directamente por razones de rendimiento y limitaciones de tamaño; además, el uso directo incrementa latencia y coste computacional. El patrón correcto es usar RSA/ECC solo para cifrar claves de sesión (envelope encryption) o autenticación, no para cifrar archivos enteros. - Opción 4 (Client-side encryption + KMS envelope): Correcta. El cifrado del lado cliente con claves de datos por archivo y protección de esas claves por KMS/HSM ofrece control sobre quién puede descifrar y reduce la exposición ante breaches en la nube. Combina bien con AES-GCM y permite cumplimiento más estricto, aunque con coste y complejidad operativa añadida. En resumen, las opciones 2 y 4 forman un conjunto práctico: protección y control de claves (HSM/KMS) más cifrado granular y local (client-side) usando patrones de envelope encryption y algoritmos AEAD acelerados para minimizar impacto en rendimiento.

Step 1: Entender el objetivo — amenazas avanzadas y malware polimórfico suelen evadir detecciones basadas en firmas; se necesita visibilidad continua y capacidad de respuesta en el endpoint.

Step 2: Comparar tecnologías — EDR recopila eventos, aplica análisis de comportamiento y correlación para detectar anomalías en procesos, persistencia y comunicaciones; además permite contención, remediación y forense.

Step 3: Resultado operativo — implementando EDR se obtiene detección temprana, aislamiento de equipos comprometidos y pistas de ataque para respuestas posteriores, complementando otros controles perimetrales. Trap: creer que un antivirus tradicional es suficiente; los antivirus firmados detectan amenazas conocidas pero fallan ante técnicas de living‑off‑the‑land y variants sin firmas. Por qué fallan las opciones incorrectas: Antivirus basado en firmas (opción 1) sólo detecta muestras conocidas y no provee telemetría forense profunda ni respuesta automatizada. IDS de red pasivo (opción 3) monitorea tráfico pero no puede ver actividad interna del proceso en el endpoint ni ejecutar acciones de contención sobre un host comprometido. HIDS basado en firmas (opción 4) puede detectar cambios conocidos en archivos o firmas de ataques, pero similar al antivirus, su enfoque basado en reglas/firmas limita detección de comportamientos noveles y carece de capacidades avanzadas de respuesta que ofrece EDR. En una estrategia de defensa en profundidad, EDR complementa red‑IDS, firewalls y controles preventivos proporcionando detección basada en comportamiento, análisis de telemetría y acciones de contención específicas en los endpoints.

Step 1: Determinar requisitos de seguridad para microservicios — autenticación mutua, mínima exposición por compromiso de credenciales, rotación frecuente y automatización para escalabilidad.

Step 2: Comparar mecanismos de distribución y revocación — una PKI interna permite controlar la emisión de certificados, definir políticas (vida útil corta, EKU, SANs), y cuando se combina con sistemas de automatización (ACME, HashiCorp Vault, cert‑manager) permite enrollar y renovar certificados sin intervención humana. El uso de certificados efímeros favorece mTLS entre servicios, ofreciendo autenticación mutua y confidencialidad, además de facilitar revocación y renovación continua.

Step 3: Implementación operativa — desplegar una CA raíz y CA intermedia con protección HSM, automatizar el flujo de inscripción en ambos entornos (on‑prem y nube), instrumentar rotación periódica, monitorizar expiraciones y gestionar revocación/OCSP/CRL; asegurar que los controles de acceso y registro (auditoría) estén activos. Trap: creer que la simplicidad operacional justifica claves largas y estáticas; en microservicios, eso aumenta riesgo. Por qué cada respuesta incorrecta falla: - Opción 2 (clave simétrica única y sin rotación): compartir una única clave simétrica crea un único punto de fallo; si se compromete, todo el sistema queda expuesto; además no soporta autenticación mutua granular ni separación de roles. - Opción 3 (certificados de varios años y renovación manual): aunque reduce carga administrativa momentáneamente, alarga la ventana de exposición en caso de compromiso, hace la gestión y revocación poco práctica y no es acorde a prácticas modernas de seguridad que favorecen certificados de corta vida. - Opción 4 (almacenar claves/certs en archivos planos en contenedores): expone secretos en imágenes que pueden ser duplicadas y persistentes; no permite rotación segura ni separación de funciones y aumenta la superficie de ataque (imágenes almacenadas en repositorios, copias locales). En síntesis, para una arquitectura de microservicios híbrida y escalable, una PKI interna con emisión automática de certificados de corta duración y uso de mTLS ofrece autenticación fuerte, facilita rotación y minimiza impacto de compromisos; es la opción arquitectónica que cumple requisitos de seguridad y operación.