1. ¿Cómo abordas el diseño de políticas de control de acceso en la nube?
Empezás desde el principio de menor privilegio: cada identidad recibe solo los permisos que necesita para su función. Organizás los accesos por roles (RBAC), definís políticas en código (IaC), y las revisás periódicamente. En AWS, por ejemplo, usás políticas IAM + SCPs para límites organizacionales.
2. ¿Diferencia entre autenticación y autorización?
- AuthN = verificar quién sos (login, MFA).
- AuthZ = verificar qué podés hacer (permisos, políticas).
Primero se autentica, después se autoriza. Un 401 es fallo de AuthN; un 403 es fallo de AuthZ.
3. ¿Cómo solucionarías problemas con permisos IAM que no se aplican correctamente?
- Revisar qué políticas tiene asignadas la identidad (directas, por grupo, por rol).
- Verificar si hay un Deny explícito que sobreescriba el Allow.
- En AWS: usar el IAM Policy Simulator o revisar los logs de CloudTrail.
- Confirmar que el recurso no tiene su propia resource-based policy que deniegue.
- Verificar SCPs si estás en AWS Organizations.
4. ¿Experiencia implementando MFA?
MFA se implementa habilitando un segundo factor después del login. Las opciones más comunes son TOTP (Google Authenticator, Authy), SMS (menos seguro), push notifications, y hardware keys (YubiKey). Para mayor seguridad se usa FIDO2/passkeys, resistente a phishing. En entornos enterprise se integra con el IdP (Azure AD, Okta).
5. ¿Cómo integrarías IAM con pipelines CI/CD?
- Cada pipeline tiene una cuenta de servicio (no credenciales humanas) con permisos mínimos.
- Las credenciales no se hardcodean: se usan variables de entorno, Secrets Manager o OIDC federation (GitHub Actions → AWS IAM Role sin secret keys).
- Se revisan los permisos del pipeline como parte del code review.
6. ¿Experiencia con IAM en entornos híbridos (on-prem + cloud)?
En entornos híbridos se federa el directorio on-prem (Active Directory) con el IdP cloud (Azure AD, AWS IAM Identity Center). Los usuarios se autentican una sola vez en AD y esa identidad se propaga a la nube vía SAML o OIDC. Esto evita tener dos silos de identidades.
7. ¿Cómo te mantenés actualizado en IAM?
Blogs oficiales (AWS Security, Microsoft Entra), publicaciones de NIST y Cloud Security Alliance, certificaciones (AWS Security Specialty, SC-300), comunidades como IDPro, y seguir vulnerabilidades relevantes en CVE relacionadas con identity.
8. ¿Experiencia con RBAC? Ejemplo.
RBAC significa asignar permisos a roles, y usuarios a roles. Ejemplo: en un sistema de tickets, creás tres roles: viewer (solo lectura), agent (puede editar), admin (puede todo). Cada empleado recibe el rol según su función. Si alguien cambia de equipo, solo cambiás su rol.
9. ¿Cómo asegurás cumplimiento regulatorio en IAM?
- Aplicar PoLP y SoD desde el diseño.
- Activar logging completo (CloudTrail, Azure Monitor).
- Hacer access reviews periódicas.
- Automatizar con IGA para generar reportes de compliance.
- Mapear controles IAM a cada regulación (SOX, GDPR, HIPAA, PCI DSS).
10. ¿Qué es least privilege y cómo lo aplicás?
Cada identidad tiene solo los permisos mínimos para hacer su trabajo. En práctica: no dar AdministratorAccess cuando alcanza s3:GetObject. Se revisan los permisos regularmente y se revocan los que no se usan. En AWS se puede usar IAM Access Analyzer para detectar accesos no utilizados.
11. ¿Cómo manejás provisioning y deprovisioning?
Provisioning: al ingresar alguien, se crea su identidad y se asignan roles según su función (idealmente automatizado desde RRHH vía SCIM). Deprovisioning: al salir, se deshabilita la cuenta de inmediato y se revocan todos los tokens activos. La automatización es clave; el deprovisioning manual genera orphan accounts.
12. ¿Qué es SSO y sus beneficios?
SSO (Single Sign-On) = autenticarse una vez y acceder a múltiples aplicaciones sin volver a ingresar credenciales. El usuario se autentica ante el IdP; el IdP emite un token/assertion que las apps aceptan.
Beneficios: mejor UX, menos contraseñas que gestionar, menor superficie de ataque, control centralizado de accesos.
13. ¿Cómo asegurás datos de identidad sensibles en un sistema IAM?
- Cifrado en reposo y en tránsito (TLS).
- Acceso al directorio de identidades solo para roles administrativos específicos.
- Hashing de contraseñas con algoritmos fuertes (bcrypt, Argon2).
- No almacenar más datos de los necesarios (minimización de datos, GDPR).
- Auditoría de acceso a los datos del directorio.
14. ¿Estrategias para gestionar acceso de terceros y contratistas?
- Identidades separadas de las de empleados (no usar cuentas internas para externos).
- Acceso limitado por tiempo (fecha de expiración automática).
- Permisos mínimos y bien acotados al scope del trabajo.
- Revisión antes de cualquier renovación de acceso.
- JIT Access para tareas puntuales.
15. ¿Cómo manejás access reviews y certificaciones?
Periódicamente (mensual, trimestral) se genera un reporte de todos los accesos activos. Los managers deben aprobar o revocar cada acceso. Los no certificados se revocan automáticamente. Las plataformas IGA (SailPoint, Saviynt) automatizan este proceso y generan evidencia para auditorías.
16. ¿Experiencia con SAML, OAuth y OIDC?
- SAML 2.0: SSO empresarial, basado en XML, flujo redirecta al IdP que devuelve una assertion firmada. Muy usado con AD FS, Okta.
- OAuth 2.0: framework de autorización. Delegar acceso a recursos sin compartir contraseñas. Emite access tokens.
- OIDC: capa de autenticación sobre OAuth. Agrega un ID Token (JWT) con info del usuario. Usado en "Login con Google".
17. ¿Cómo integrás IAM con Active Directory o LDAP?
Se configura el IdP (Azure AD, Okta) para sincronizar usuarios y grupos desde AD vía LDAP o AD Connect. Las apps consultan al IdP en vez de ir directamente a AD. Para autenticación cloud se federa AD con el IdP usando SAML o OIDC, manteniendo AD como fuente de verdad de identidades.
18. ¿Cómo auditás y monitoreás actividades IAM?
- Habilitar logging completo: CloudTrail (AWS), Azure Monitor, Okta System Log.
- Centralizar logs en un SIEM (Splunk, Sentinel).
- Crear alertas para eventos críticos: login fuera de horario, AssumeRole anómalo, cambios de políticas, accesos denegados masivos.
- Revisar periódicamente accesos privilegiados.
19. ¿Cómo manejás IGA a gran escala?
Con una plataforma IGA (SailPoint, Saviynt, One Identity) que automatiza: provisioning desde el HR system, access reviews, detección de SoD violations, role mining, y generación de reportes de compliance. A escala, todo debe ser automatizado; lo manual no escala.
20. ¿Rol del PAM en una estrategia IAM?
PAM gestiona las cuentas más riesgosas: admins, cuentas de servicio, root. Funciones clave: password vaulting (contraseñas rotadas automáticamente, nadie las conoce en texto plano), grabación de sesiones privilegiadas, JIT access (acceso solo cuando se necesita), y alertas ante uso anómalo de cuentas privilegiadas.
21. ¿Cómo manejás acceso de emergencia ("break-glass")?
Las cuentas break-glass son cuentas de emergencia con acceso total, guardadas en un PAM vault, selladas. Se usan solo cuando los sistemas normales fallen. Cada uso genera una alerta inmediata y se audita en detalle. Después del incidente, se rotan las credenciales y se documenta el uso.
22. ¿Qué es ABAC?
Attribute-Based Access Control. El acceso se decide evaluando atributos del usuario, del recurso y del contexto en tiempo real. Más flexible que RBAC. Ejemplo: "permitir acceso si departamento=legal AND clasificacion_doc=interno AND horario=laboral". Ideal cuando RBAC se vuelve demasiado granular para manejar.
23. ¿Cómo asegurás APIs con IAM?
- Requerir autenticación en todos los endpoints (no endpoints públicos sin razón).
- Usar tokens de corta duración (JWT/OAuth access tokens).
- Validar scopes: cada app solo puede hacer lo que declaró en su scope.
- Rate limiting y detección de abuso.
- En AWS: usar IAM auth + API Gateway, o Cognito para usuarios finales.
24. ¿Experiencia con herramientas IGA?
Las herramientas IGA más comunes son SailPoint IdentityIQ/IdentityNow, Saviynt, One Identity y Microsoft Identity Governance. Permiten automatizar el ciclo de vida completo, hacer role mining, detectar SoD violations y generar evidencia de cumplimiento para auditorías externas.
25. ¿Cómo migrás identidades de sistemas legacy a IAM moderno?
- Inventariar todas las identidades existentes (usuarios, cuentas de servicio, apps).
- Mapear roles actuales a un modelo RBAC/ABAC moderno.
- Migrar en fases, empezando por apps menos críticas.
- Federar el sistema legacy con el nuevo IdP antes de cortar.
- Validar accesos después de migrar y deprovisionar lo viejo.
26. ¿Desafío técnico complejo en IAM que resolviste?
Respuesta modelo (adaptala a tu experiencia): "Detectamos cuentas de servicio en producción con permisos de administrador global porque históricamente era más fácil darles todo. Hicimos un análisis de permisos efectivos, identificamos qué usaba realmente cada cuenta con los logs de los últimos 90 días, y reemplazamos los permisos excesivos por políticas mínimas. Redujimos el blast radius significativamente sin interrumpir operaciones."
27. ¿Cómo manejás conflictos de identidad en fusiones de empresas?
- Inventariar los directorios de ambas organizaciones.
- Detectar conflictos de usernames o roles duplicados.
- Decidir qué IdP será la fuente de verdad (o crear uno nuevo).
- Federar temporalmente ambos directorios durante la transición.
- Migrar usuarios gradualmente y deprovisionar el directorio antiguo.
28. ¿Rol del Machine Learning en detección de anomalías en IAM?
ML analiza el comportamiento histórico de cada usuario o entidad y detecta desviaciones (UEBA). Ejemplos: login a una hora inusual, acceso a recursos nunca tocados antes, volumen de descarga anormal. Reduce falsos positivos vs. reglas estáticas y detecta amenazas que las reglas no cubren.
29. ¿Cómo mantenés políticas IAM consistentes en multi-cloud?
- Definir políticas en código (IaC: Terraform, Pulumi) para que sean reproducibles.
- Usar un Identity Broker centralizado (Azure AD, Okta) que federe con cada cloud.
- Normalizar los nombres de roles entre clouds.
- Auditar con herramientas multi-cloud (Wiz, Prisma Cloud, CIEM).
30. ¿Qué es identidad federada y cómo funciona?
Federación = establecer confianza entre dos dominios para que una identidad autenticada en uno sea reconocida en el otro. El IdP de Empresa A emite un token/assertion firmado. Empresa B lo valida usando el certificado público del IdP de A y da acceso sin pedir credenciales propias. Protocolos: SAML, OIDC.
31. ¿Cómo manejás el ciclo de vida de identidades no humanas?
Las cuentas de servicio, bots y apps también necesitan: creación con permisos mínimos, rotación periódica de credenciales (o uso de credenciales temporales/OIDC), revisión de uso real, y deprovisioning cuando la app o servicio ya no existe. Un secreto hardcodeado que nadie sabe dónde está es una de las mayores vulnerabilidades reales.
32. ¿Qué es Identity-First Security?
La identidad es el nuevo perímetro de seguridad. En vez de confiar en la red (VPN, firewall), todo acceso se verifica por identidad, sin importar desde dónde se conecta el usuario. Es el principio base de Zero Trust: no confiar en la red, confiar (y verificar) la identidad.
33. ¿Cómo implementás políticas de acceso condicional basadas en contexto?
Conditional Access evalúa en tiempo real: ¿quién es el usuario?, ¿desde qué dispositivo?, ¿desde dónde?, ¿a qué app intenta acceder? Según la combinación, puede: permitir, bloquear, o pedir MFA. Ejemplo en Azure AD: si el dispositivo no está en el MDM corporativo, pedir MFA y bloquear descargas.
34. ¿Estrategias para reducir MFA fatigue?
- Usar FIDO2/passkeys (no genera notificaciones push).
- Number matching en notificaciones push (el usuario debe tipear un número que ve en pantalla, no solo aprobar).
- Limitar la cantidad de notificaciones por período.
- Usar sesiones más largas para usuarios en dispositivos de confianza.
- Educación: que los usuarios rechacen y reporten cualquier MFA que no iniciaron.
35. ¿Cómo manejás rotación de secretos y claves?
- Usar un gestor de secretos (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault).
- Configurar rotación automática (cada 30, 60 o 90 días según sensibilidad).
- Las apps obtienen los secretos en tiempo de ejecución, nunca los almacenan localmente.
- Para claves criptográficas, usar KMS y no dejar que las apps toquen la clave directamente.
36. ¿Impacto de Zero Trust en la arquitectura IAM?
Zero Trust eleva a IAM al centro de toda la seguridad. Cada acceso requiere: autenticación fuerte (MFA), autorización granular (PoLP), verificación del dispositivo (device trust), y evaluación continua del contexto (risk-based). Nada es confiable por defecto. IAM pasa de ser una herramienta administrativa a ser el control de seguridad principal.
37. ¿Cómo manejás IAM en entornos Kubernetes?
- Usar Service Accounts de Kubernetes para identidades de pods.
- Integrar con un IdP externo para autenticación de usuarios (OIDC).
- Usar RBAC de Kubernetes para controlar qué puede hacer cada service account.
- Para acceso a recursos cloud desde pods: usar IRSA (AWS) o Workload Identity (GCP) en vez de credenciales estáticas.
38. ¿Qué métricas usás para medir la eficacia de un programa IAM?
- % de cuentas con MFA habilitado.
- Tiempo promedio de deprovisioning al salir un empleado.
- Cantidad de orphan accounts detectadas.
- % de accesos certificados en las últimas access reviews.
- Cantidad de SoD violations activas.
- Tiempo de respuesta ante un compromiso de credenciales.
39. ¿Cómo resolvés conflictos entre políticas globales y locales de IAM?
La política global define el baseline mínimo de seguridad (ej: MFA obligatorio, no acceso sin endpoint registrado). Las políticas locales pueden ser más restrictivas, nunca menos. En AWS, los SCPs actúan como techo: las políticas locales no pueden superar lo que el SCP permite.
40. ¿Cómo funciona el aprovisionamiento Just-In-Time?
JIT Provisioning = el usuario se crea en la aplicación destino la primera vez que intenta acceder mediante SSO, usando los atributos enviados por el IdP (nombre, email, rol). No requiere que IT cree la cuenta manualmente con anticipación. Cuando el usuario accede, la app la crea automáticamente en ese momento.
41. ¿Cómo gestionás privilege creep?
Privilege creep = acumulación de permisos que el usuario ya no necesita por cambios de rol. Se combate con: access reviews periódicas, deprovisioning automático de permisos no usados (usar logs de actividad), y herramientas IGA que detecten permisos huérfanos. El principio de menor privilegio aplicado continuamente.
42. ¿Diferencia entre CIAM y IAM de empleados?
- Employee IAM: usuarios internos conocidos, alta seguridad, menos UX friction, integrado con RRHH.
- CIAM (Customer IAM): usuarios externos millones, prioridad en UX y self-service, social login, privacidad (GDPR), resistencia a fraude y bots.
CIAM maneja escala y fricción muy diferente al IAM interno.
43. ¿Cómo manejás autenticación sin contraseña (passwordless)?
Las opciones son: passkeys (FIDO2, la más segura), magic links (email con link de un uso), OTP por email/SMS (menos seguro), biometría en dispositivo. Se implementa configurando el IdP para soportar WebAuthn/FIDO2 y registrando el dispositivo del usuario. Reduce phishing y elimina el riesgo de contraseñas débiles.
44. ¿Importancia de UEBA en IAM?
UEBA detecta comportamientos anómalos que las reglas estáticas no pueden. Establece una línea base de comportamiento normal (horario, ubicación, recursos accedidos) y alerta cuando algo se desvía significativamente. Es clave para detectar cuentas comprometidas que usan credenciales legítimas, insider threats y movimientos laterales.
45. ¿Cómo diseñás IAM para alta disponibilidad?
- Usar IdPs con redundancia multi-región (Okta, Azure AD ya lo tienen).
- Si es on-prem: múltiples Domain Controllers en zonas distintas.
- Definir cuentas break-glass para emergencias si el IdP cae.
- Replicación de políticas y configuraciones como código (IaC).
- Testear regularmente los escenarios de failover.
46. ¿Cómo integrás IAM con SIEM para respuesta a incidentes?
Los logs del IdP (logins, cambios de políticas, accesos denegados) se envían al SIEM en tiempo real. Se crean alertas para eventos críticos: múltiples fallos de MFA, AssumeRole desde IP desconocida, cambio de privilegios sin ticket de cambio. Cuando el SIEM detecta una amenaza, puede triggear respuestas automatizadas: deshabilitar cuenta, revocar sesiones, notificar al equipo.
47. ¿Desafíos de las identidades efímeras en la nube?
Las identidades efímeras (funciones Lambda, contenedores, pods) duran segundos o minutos y se crean/destruyen constantemente. Desafíos: no pueden usar credenciales estáticas, los logs son más difíciles de correlacionar, y los permisos deben estar bien definidos desde el inicio. Solución: roles con credenciales temporales (STS en AWS), IRSA, Workload Identity.
48. ¿Cómo manejás la delegación de administración?
Se divide la administración en scopes: el admin de ventas puede gestionar accesos de su equipo al CRM, pero no puede tocar otros sistemas. Esto se logra con unidades organizacionales en AD, scoped roles en Okta, o Delegated Administration en plataformas IGA. Reduce el blast radius si una cuenta admin es comprometida.
49. ¿Protocolos para comunicación segura entre microservicios?
- mTLS (mutual TLS): ambos lados presentan certificado. Es el estándar en service meshes (Istio, Linkerd).
- SPIFFE/SPIRE: framework para identidades criptográficas de workloads. Emite SVIDs (certificados de corta duración) a cada servicio.
- OAuth 2.0 con client credentials: el servicio obtiene un token para llamar a otro servicio.
50. ¿Cómo educás a usuarios finales sobre seguridad de identidad?
- Capacitaciones cortas y frecuentes (mejor que una anual larga).
- Simulaciones de phishing para medir y mejorar.
- Comunicar con ejemplos reales y consecuencias concretas.
- Hacer que la seguridad sea fácil: SSO reduce la fatiga de contraseñas, MFA con passkeys es más rápido que una contraseña.
- Métricas: tasa de click en phishing simulado como KPI del programa.
51. ¿Cómo manejás SoD en IAM?
Se definen pares de roles/permisos que no pueden coexistir en la misma persona (ej: crear y aprobar pagos). La plataforma IGA detecta violaciones automáticamente. Cuando se detecta una, se genera una alerta y se requiere justificación de negocio o se revoca uno de los accesos. Es un control clave para auditorías SOX.
52. ¿Herramientas para automatización de flujos IAM?
- SailPoint / Saviynt: automatización completa del ciclo de vida e IGA.
- Okta Workflows: automatización sin código para eventos de identidad.
- Microsoft Logic Apps + Entra ID: flujos automatizados en ecosistema Microsoft.
- Scripts Python/PowerShell: para tareas específicas (bulk provisioning, limpieza de cuentas).
- Terraform: para IAM as Code (políticas, roles, grupos en cloud).
53. ¿Cómo asegurás identidades en dispositivos IoT?
- Cada dispositivo tiene una identidad única (certificado digital o hardware key).
- Usar PKI para gestionar los certificados con rotación automática.
- Principio de menor privilegio: el dispositivo solo se comunica con lo que necesita.
- Segmentar la red de IoT del resto.
- Monitorear comportamiento anómalo (un termostato que intenta acceder a una base de datos es una alerta).
54. ¿Qué es Identity Fabric?
Es un enfoque arquitectural que unifica la gestión de identidades de múltiples fuentes (empleados, clientes, partners, máquinas) en una capa coherente. En vez de silos separados para cada tipo de identidad, hay servicios compartidos de autenticación, autorización, governance y auditoría. Gartner lo describe como la evolución natural hacia un IAM unificado.
55. ¿Cómo manejás revocación de acceso en tiempo real ante una amenaza?
Al detectar una cuenta comprometida: revocar sesiones activas inmediatamente (invalidar tokens), deshabilitar la cuenta, rotar credenciales y tokens de larga duración. En Azure AD se puede forzar re-autenticación con Conditional Access en segundos. En AWS se puede agregar una deny policy al rol comprometido instantáneamente.
56. ¿Impacto de GDPR en el diseño de IAM?
- Minimización de datos: no guardar más datos de identidad de los necesarios.
- Derecho al olvido: capacidad de eliminar completamente una identidad.
- Acceso a los propios datos: los usuarios deben poder ver qué datos se guardan de ellos.
- Auditoría: registro de quién accedió a datos personales.
- Consentimiento: para identity federation, el usuario debe consentir qué se comparte.
57. ¿Cómo abordás el problema de cuentas huérfanas?
- Integrar el sistema IAM con el HR system para deprovisioning automático.
- Escanear periódicamente cuentas sin actividad (90+ días = dormant, candidata a revisar).
- Herramientas IGA pueden identificar y reportar orphan accounts automáticamente.
- Definir un proceso: cuenta sin dueño identificable → deshabilitar → eliminar después de un período de gracia.
58. ¿Rol de los certificados digitales en IAM?
Los certificados se usan para: autenticar dispositivos y servicios (mTLS), firmar assertions SAML, establecer confianza en federación (el SP valida la firma del IdP con su certificado público), autenticación de usuarios sin contraseña (smart cards, passkeys). La gestión del ciclo de vida de los certificados (renovación, revocación) es parte crítica del IAM.
59. ¿Cómo gestionás acceso a datos no estructurados?
Los datos no estructurados (archivos en SharePoint, S3, NAS) son los más difíciles de controlar. Estrategia: clasificar los datos primero (¿qué es sensible?), aplicar RBAC o ABAC sobre los repositorios, integrar con una plataforma DSPM (Data Security Posture Management) o DAG (Data Access Governance) que mapee quién accede a qué datos y detecte accesos excesivos.
60. ¿Cómo evaluás la madurez de un programa IAM?
Se usan modelos de madurez como el de Gartner o IDPro. Niveles típicos:
- Nivel 1: manual, reactivo, sin automatización.
- Nivel 2: procesos definidos, algo de automatización básica.
- Nivel 3: automatización del ciclo de vida, reviews periódicas.
- Nivel 4: governance avanzado, IGA, detección de anomalías.
- Nivel 5: predictivo, Zero Trust maduro, identidades como control principal.
61. ¿Cómo manejás acceso para aplicaciones móviles?
Las apps mobile son clientes públicos (no pueden guardar secretos de forma segura). Se usa OAuth 2.0 con PKCE para el flujo de autorización. Los tokens se almacenan en el keystore seguro del dispositivo (Keychain en iOS, Keystore en Android). Se implementa re-autenticación biométrica para acciones sensibles. MFA con passkeys es la opción más segura.
62. ¿Importancia del autoservicio en un portal IAM?
El autoservicio reduce la carga en IT y acelera los procesos. Los usuarios pueden: resetear su propia contraseña, solicitar acceso a recursos (que va a aprobación del manager), revisar sus propios accesos. Esto libera al equipo IAM para tareas de mayor valor y mejora la experiencia del usuario.
63. ¿Cómo integrás IAM con CIEM?
CIEM (Cloud Infrastructure Entitlement Management) analiza los permisos en cloud y detecta entitlements excesivos o no utilizados. Se integra leyendo los permisos efectivos de todas las identidades (humanas y no humanas) en AWS/Azure/GCP y comparándolos contra el uso real. Herramientas: Wiz, Ermetic, Prisma Cloud. El output alimenta al equipo IAM para remediar permisos excesivos.
64. ¿Cómo manejás gobernanza de acceso a nivel de datos?
Data Access Governance (DAG) va más allá del acceso a sistemas: controla el acceso a datos específicos dentro de esos sistemas. Implica: clasificar los datos, mapear quién accede a qué, detectar acceso excesivo o anómalo a datos sensibles, y aplicar controles granulares. Herramientas: Varonis, Microsoft Purview.
65. ¿Estrategias para limpieza de datos de identidad?
Con el tiempo los directorios acumulan datos sucios: usuarios duplicados, atributos desactualizados, grupos vacíos. Estrategia: integrar el directorio con el HR system como fuente de verdad, hacer reconciliaciones periódicas automáticas, identificar y merging de identidades duplicadas (especialmente en fusiones), y purgar datos de identidades que ya no existen.
66. ¿Cómo asegurás acceso a consolas de administración cloud?
- Nunca usar el root account o cuenta global admin para tareas cotidianas.
- MFA obligatorio para todos los accesos a consolas de administración.
- Acceso JIT: el acceso admin se otorga temporalmente, no es permanente.
- Restricciones por IP o dispositivo confiable.
- Session recording para todas las sesiones administrativas.
- Alertas inmediatas ante cualquier uso de cuentas privilegiadas.
67. ¿Qué es Risk-Based Authentication y cómo lo implementás?
El sistema evalúa el riesgo de cada intento de login en tiempo real (ubicación, dispositivo, horario, comportamiento) y ajusta el nivel de autenticación requerido dinámicamente. Bajo riesgo: acceso directo. Riesgo medio: pide MFA. Alto riesgo: bloquea o requiere verificación adicional. Se implementa con el motor de Conditional Access del IdP (Azure AD, Okta, Ping).
68. ¿Cómo manejás identidades en arquitecturas serverless?
Las funciones serverless (Lambda, Cloud Functions) no tienen un servidor persistente. Se les asigna un execution role con los permisos mínimos necesarios. Las credenciales son temporales y las provee el runtime automáticamente (no se hardcodea nada). Se revisan los permisos del execution role como parte del despliegue y se audita con CIEM.
69. ¿Cómo hacés pentesting enfocado en IAM?
Se evalúan: configuraciones incorrectas de políticas (over-permissive), privilege escalation paths (¿puede un usuario con permisos bajos asumir un rol de admin?), tokens expuestos (en repos, variables de entorno), misconfiguraciones de OAuth (redirect URI abiertos), y cuentas con MFA deshabilitado. Herramientas: ScoutSuite, Pacu (AWS), AADInternals (Azure AD), PMapper.
70. ¿Importancia de UX en la adopción de IAM?
Si las herramientas de seguridad son difíciles de usar, los usuarios buscan formas de saltearlas (shadow IT, contraseñas compartidas). SSO mejora la UX reduciendo logins. Passwordless elimina la fricción de recordar contraseñas. MFA con passkeys es más rápido que escribir un código. Buena UX = mayor adopción = mayor seguridad real.
71. ¿Cómo manejás identidades en entornos multi-cloud?
Usar un IdP centralizado (Azure AD, Okta) que federe con cada cloud provider vía OIDC o SAML. Definir roles equivalentes en cada cloud y mapearlos al mismo rol del IdP. Gestionar políticas como código para mantener consistencia. Usar herramientas CIEM que tengan visibilidad cross-cloud. Evitar identidades nativas de cada cloud que no pasen por el IdP central.
72. ¿Qué es SCIM y por qué es útil?
SCIM es un protocolo REST estándar para automatizar el provisioning y deprovisioning de usuarios entre sistemas. Define endpoints comunes (POST /Users, DELETE /Users/{id}) y un schema estándar para representar usuarios y grupos. Es útil porque elimina el provisioning manual, reduce orphan accounts y mantiene los sistemas sincronizados automáticamente cuando hay cambios en RRHH.
73. ¿Seguridad de identidades en Edge Computing?
En el edge (dispositivos distribuidos geográficamente), los desafíos son: conectividad intermitente, no siempre hay acceso al IdP central para validar tokens. Solución: usar tokens con validación local (JWT con verificación de firma offline), certificados de dispositivo con PKI, y sincronización periódica de políticas. Cada nodo edge tiene su propia identidad verificable.
74. ¿Cómo manejás el ciclo de vida de certificados SSL/TLS?
- Inventariar todos los certificados con una herramienta de certificate management.
- Automatizar la renovación (Let's Encrypt + cert-manager en Kubernetes, AWS ACM).
- Alertar con 30/60 días de anticipación al vencimiento.
- Usar CRL (Certificate Revocation List) o OCSP para revocación.
- Corto tiempo de vida para certificados internos (reducir blast radius si se comprometen).
75. ¿Qué es Sovereign Identity?
Es el concepto de que los usuarios controlan sus propias identidades digitales sin depender de un proveedor centralizado (Google, Facebook, gobierno). Se basa en tecnologías como DID (Decentralized Identifiers) y Verifiable Credentials (W3C). El usuario guarda sus credenciales en un wallet digital y las presenta cuando es necesario. Es una tendencia emergente relevante en contextos de privacidad y regulaciones de datos.
76. ¿Cómo validás la identidad de un usuario en el registro inicial?
Para empleados: provisionamiento desde RRHH (la identidad viene de un proceso de onboarding verificado). Para clientes (CIAM): verificación de email, verificación de teléfono (SMS), documentos de identidad (con servicios de identity proofing como Jumio, Onfido), o verificación biométrica. El nivel de rigor depende del valor del recurso protegido.
77. ¿Cómo manejás excepciones a políticas globales de IAM?
Las excepciones deben ser: documentadas (con justificación de negocio), aprobadas formalmente (por un comité o el CISO), de tiempo limitado (con fecha de expiración), monitoreadas activamente, y revisadas en el próximo ciclo de access review. Las excepciones permanentes son un riesgo; deben ser la última opción y siempre compensadas con controles adicionales.
78. ¿Cómo asegurás que los admins IAM no abusen de sus privilegios?
- Separar funciones: quien administra el IdP no debería poder auditarse a sí mismo.
- Logs de todas las acciones administrativas, revisados por un tercero o un SIEM.
- Aplicar 4-eyes principle para cambios críticos en configuración IAM.
- PAM con session recording para acciones de admins de identidad.
- Rotación de roles admin (que no sea siempre la misma persona).
79. ¿Desafíos al integrar IAM con apps SaaS?
- No todas soportan SCIM o SAML estándar (requieren conectores custom).
- Algunas apps tienen su propio sistema de roles que no mapea 1:1 con el IdP.
- El shadow IT: apps SaaS adoptadas sin pasar por IT no están integradas.
- Sincronización de grupos puede ser lenta o parcial.
- Dificultad para revocar acceso si la app no soporta SCIM (hay que hacerlo manualmente).
80. ¿Cómo usás logs IAM para análisis forense?
Después de un incidente, los logs de IAM permiten reconstruir: qué identidad fue comprometida, cuándo empezó la actividad anómala, qué recursos accedió, qué cambios hizo (¿creó usuarios? ¿modificó políticas?), y desde dónde operó. En AWS, CloudTrail es la fuente principal. La clave es que los logs sean inmutables (S3 con Object Lock), centralizados, y con retención suficiente (mínimo 1 año).
81. ¿Cómo manejás acceso basado en ubicación geográfica?
Con Conditional Access se definen Named Locations (países o rangos de IP de confianza). Acceso desde ubicaciones desconocidas puede requerir MFA adicional o bloquearse directamente. Ejemplo: bloquear logins desde países donde la empresa no opera salvo con aprobación explícita. Es un control simple y efectivo que reduce mucho el blast radius de credenciales robadas.
82. ¿Importancia de estandarizar roles en una empresa global?
Sin estandarización, cada región o equipo crea sus propios roles con nombres distintos para la misma función, lo que hace imposible auditar, comparar o automatizar. Un modelo de roles global define un catálogo común: mismo nombre, mismos permisos base, con extensiones regionales si es necesario. Facilita IGA, access reviews y compliance.
83. ¿Cómo integrás IAM con DLP?
IAM controla quién puede acceder. DLP controla qué puede hacer con los datos. La integración permite: si un usuario baja un archivo sensible, DLP puede verificar con IAM si ese usuario tiene entitlement para ese dato y bloquear si no. También se puede alimentar al motor de Conditional Access con el contexto del usuario para ajustar los controles DLP dinámicamente.
84. ¿Cómo manejás autenticación biométrica en IAM?
La biometría se usa como factor de posesión/inherencia. En dispositivos: el sistema operativo gestiona la biometría (FaceID, fingerprint) y el resultado se usa para desbloquear una clave local (FIDO2). La plantilla biométrica nunca sale del dispositivo: el servidor solo ve la firma criptográfica. Esto es importante: los sistemas biométricos seguros no almacenan la biometría en servidores centrales.
85. ¿Rol de Infrastructure as Code (IaC) en IAM?
IaC permite definir roles, políticas, grupos y permisos en código (Terraform, CloudFormation, Bicep). Beneficios: las políticas IAM se versionan en Git (audit trail completo de cambios), son reproducibles en múltiples entornos, se pueden hacer code review antes de aplicar, y se integran en pipelines CI/CD con validaciones automáticas de seguridad.
86. ¿Cómo asegurás acceso a backups y almacenamiento?
- Los backups deben tener acceso aún más restringido que producción (si los comprometés, perdés la capacidad de recuperación).
- Cuentas separadas para backups (en AWS: cuenta dedicada con acceso mínimo).
- Inmutabilidad: S3 Object Lock, Azure Immutable Blob para que nadie pueda borrar backups.
- MFA Delete: requerir MFA para eliminar backups.
- Alertas ante cualquier acceso inusual a los sistemas de backup.
87. ¿Cómo manejás identidades de clientes en B2B?
En B2B los "clientes" son otras empresas. Se usa federación: la empresa cliente tiene su propio IdP y se establece una relación de confianza. Los usuarios de la empresa cliente se autentican con sus propias credenciales (no crean cuentas en tu sistema). Se gestiona el acceso a nivel de organización/tenant, no de usuario individual.
88. ¿Qué es Entra ID y sus componentes principales?
Microsoft Entra ID (antes Azure Active Directory) es el IdP cloud de Microsoft. Componentes principales:
- Entra ID: directorio de identidades y gestión de accesos.
- Conditional Access: control de acceso basado en contexto.
- PIM (Privileged Identity Management): PAM integrado, JIT access para roles privilegiados.
- Identity Protection: detección de riesgos con ML (logins anómalos, credential leak detection).
- Entra ID Governance: IGA integrado (access reviews, entitlement management).
89. ¿Cómo respondés ante un compromiso masivo de credenciales?
- Contener: deshabilitar cuentas afectadas, revocar sesiones y tokens activos.
- Evaluar: determinar el alcance (¿cuántas cuentas?, ¿qué accedieron?).
- Resetear: forzar cambio de contraseña para todas las cuentas afectadas.
- Investigar: analizar logs para determinar qué datos/sistemas fueron accedidos.
- Remediar: corregir la causa raíz (¿cómo se comprometieron?).
- Notificar: según regulaciones (GDPR, etc.) puede requerir notificación a autoridades.
- Hardening: MFA obligatorio, revisión de políticas, mejoras en detección.
90. ¿Cómo garantizás que el sistema IAM sea escalable?
- Usar un IdP SaaS (Okta, Azure AD) que ya tiene infraestructura escalable.
- Tokens stateless (JWT): no requieren consultar una base de datos central en cada request.
- Cachear decisiones de autorización donde sea seguro hacerlo.
- Separar el plano de control (gestión) del plano de datos (autenticación en tiempo real).
- Testear performance bajo carga antes de eventos de alto tráfico.
91. ¿Cómo manejás autenticación para trabajadores remotos permanentes?
- SSO con MFA fuerte (FIDO2 preferiblemente) desde cualquier red.
- Conditional Access que evalúe el dispositivo (¿está en el MDM?, ¿tiene disco cifrado?).
- No depender de VPN como único control de seguridad (Zero Trust reemplaza ese modelo).
- Acceso JIT para recursos sensibles incluso para empleados remotos.
- Gestión del dispositivo como parte de la identidad (device trust).
92. ¿Importancia de la limpieza de privilegios automatizada?
Sin automatización, los permisos solo crecen. Nadie los revoca activamente porque "por si acaso". La automatización analiza los logs de uso real de permisos y puede: alertar sobre permisos no usados en X días, proponer su revocación, o revocarlos automáticamente. Herramientas: IAM Access Analyzer (AWS), Entra ID Permissions Management, CIEM solutions.
93. ¿Cómo integrás IAM con NGFW?
Los NGFW modernos pueden consumir información de identidad del IdP para hacer políticas de red basadas en usuario, no solo en IP. Ejemplo: Palo Alto con User-ID agent consume grupos de AD y aplica políticas de firewall por grupo. Así, "el equipo de marketing no puede acceder a servidores de desarrollo" se define por identidad, no por rangos de IP que cambian.
94. ¿Cómo manejás identidades en dev vs producción?
- Ambientes separados, con políticas IAM separadas. Los desarrolladores no tienen acceso a producción directamente.
- En dev/staging: permisos más amplios para facilitar el trabajo.
- En producción: acceso mínimo, JIT, aprobación requerida para cambios.
- Las cuentas de servicio de cada ambiente son distintas y tienen permisos distintos.
- CI/CD usa roles con permisos específicos para desplegar, pero no para administrar.
95. ¿Qué es Identity Correlation?
Es el proceso de relacionar múltiples representaciones de la misma identidad en diferentes sistemas. Una persona puede tener: cuenta de AD, cuenta de Salesforce, cuenta de GitHub, cuenta de AWS. Identity Correlation las vincula como la misma identidad real para tener una vista unificada de todos sus accesos, facilitar governance y detectar inconsistencias.
96. ¿Cómo asegurás herramientas KMS (Key Management Service)?
- Acceso al KMS con permisos mínimos: solo las apps que necesitan cifrar/descifrar tienen acceso.
- Separación de claves por ambiente (dev, staging, prod) y por tipo de dato.
- Audit logging de todo uso de claves.
- Rotación automática de claves.
- Key policies que limitan qué roles/servicios pueden usar cada clave.
- Los admins de KMS ≠ los que usan las claves (separación de funciones).
97. ¿Cómo manejás acceso a sistemas industriales/OT?
Los sistemas OT (SCADA, PLCs) históricamente no fueron diseñados con seguridad en mente. Estrategia: segmentación de red estricta entre IT y OT, acceso remoto solo a través de PAM con grabación de sesión, MFA para todo acceso, inventario de todas las identidades (incluyendo cuentas de vendors), y monitoreo de comportamiento anómalo. El principio de menor privilegio es aún más crítico aquí.
98. ¿Impacto de la computación cuántica en encriptación IAM?
Las computadoras cuánticas podrán romper los algoritmos criptográficos actuales (RSA, ECDSA) que protegen los certificados, firmas JWT y comunicaciones TLS. El plan es migrar a algoritmos post-cuánticos (NIST ya estandarizó los primeros en 2024: ML-KEM, ML-DSA). Las organizaciones deben inventariar dónde usan criptografía vulnerable y planificar la migración. No es urgente hoy, pero hay que planificarlo.
99. ¿Cómo diseñás una política de contraseñas efectiva sin afectar productividad?
Siguiendo las guías actuales de NIST (SP 800-63B):
- Contraseñas largas (mínimo 15 caracteres) pero sin exigir cambio periódico obligatorio (solo si hay evidencia de compromiso).
- Sin reglas de complejidad artificiosas que llevan a patrones predecibles (
Empresa2024!). - Verificar contra listas de contraseñas comprometidas conocidas (Have I Been Pwned).
- MFA como segunda capa más importante que la complejidad de la contraseña.
- Gestor de contraseñas recomendado o provisto por la empresa.
100. ¿Cuál es tu visión del futuro de la gestión de identidades en los próximos 5 años?
- Passwordless generalizado: passkeys reemplazarán contraseñas en la mayoría de sistemas.
- Non-Human Identities como prioridad: con más automación y AI, habrá más identidades de máquinas que humanas. Su gestión será el nuevo desafío principal.
- Zero Trust como baseline: dejará de ser "el objetivo" para ser el estándar mínimo.
- AI en UEBA e ITDR: detección de amenazas de identidad cada vez más automatizada y precisa.
- Decentralized Identity: DID y Verifiable Credentials ganarán adopción para casos B2C.
- Post-quantum IAM: migración gradual a criptografía resistente a computación cuántica.
Respuestas basadas en estándares de la industria y mejores prácticas actuales.