Zona gris de la seguridad Cloud : a quién pertenece el riesgo de las identidades gestionadas
Se pueden dedicar incontables horas a aplicar la MFA y bloquear los permisos. Pero, ¿qué ocurre con las identidades que no gestiona? ¿Las que su proveedor cloud nube crea y gestiona por usted?
Estas "identidades no humanas gestionadas por CSP" son los robots automatizados que ejecutan servicios en segundo plano. Aunque son esenciales, la forma en que AWS, Google Cloud y Microsoft las han diseñado crea riesgos de seguridad únicos y no evidentes. Si crees que una configuración segura en AWS también lo es en Azure, podrías llevarte una sorpresa.
Dediquemos un momento a desglosar los riesgos exclusivos de cada cloud.
AWS: El problema del "diputado confundido" (la culpa es suya)
En AWS, los servicios son globales y compartidos por todos. Esto crea un riesgo clásico de "adjunto confundido" multiinquilino. Un atacante en su propia cuenta puede potencialmente engañar a un servicio de AWS para que utilice sus permisos para acceder a los recursos de su cuenta.
- El truco: Lo único que impide esto es una configuración especial en sus políticas de recursos IAM llamada clave de condición (es decir, aws:SourceArn).
- La realidad: Puede ser muy difícil utilizar correctamente las llaves de condiciones. Esto deja un enorme agujero que a menudo se pasa por alto y que hace que la carga de la prevención recaiga directamente sobre sus hombros.
Google Cloud: El problema de la "caja negra" (lo pagan ellos)
Google adopta el enfoque opuesto. Sus identidades no humanas gestionadas por CSP (agentes de servicio) son de un solo inquilino y están bloqueadas en proyectos controlados por Google. No se pueden tocar, lo que evita el abuso de credenciales que se observa en otras nubes.
- El problema: Esto crea un problema diferente: el abuso del acceso transitivo. Un servicio puede ser tan inherentemente poderoso que lo convierte en un objetivo jugoso. Un atacante puede engañarlo para que actúe en su nombre, eludiendo una comprobación de sus propios permisos.
- La realidad: Esto mismo ocurrió con el servicio Document AI. Aunque Google lo arregló, aquí no tienes ningún control directo. Debes confiar en que el proveedor ha diseñado todos sus servicios de forma segura.
Microsoft Entra ID: "Service Principal Hijacking" (Un riesgo de actualidad)
Microsoft utiliza un modelo híbrido en el que una entidad de seguridad local para la aplicación principal propiedad de Microsoft vive en su tenant. Históricamente, este diseño tenía un defecto crítico: un administrador (como Application Admin) podía añadir sus propias credenciales al Service Principal y escalar sus permisos.
- El truco: Microsoft tiene una solución llamada appInstancePropertyLock. Cuando se activa, evita este tipo de secuestro.
- La realidad: La solución no es retroactiva. Microsoft debe actualizar manualmente las más de 300 aplicaciones instaladas por defecto en los clientes. Aunque muchas se han redistribuido con esta propiedad activada, como los investigadores han demostrado recientemente, aplicaciones críticas como Office 365 Exchange Online siguen desprotegidas, lo que hace que este sea el riesgo más inmediato y de mayor impacto de los tres.
¿Para qué?
La seguridad no es única en la cloud. La amenaza con la que hay que obsesionarse en AWS no es un problema en Google, y el mayor riesgo en Entra ID tiene una causa completamente diferente.
- ¿En AWS? Audite sus políticas de IAM en busca de claves de condición faltantes. Los problemas de adjunto confundido son suyos para evitarlos.
- ¿En Google Cloud? La seguridad de los Agentes de Servicio está únicamente en manos de Google. Mantente actualizado sobre las vulnerabilidades, habilita sólo los servicios mínimamente necesarios y vigila la actividad inusual.
- En Microsoft Entra ID? Monitoree la adición de credenciales a Service Principals locales. Manténgase al día sobre el secuestro de Service Principal que se informa en la naturaleza.
Las amenazas no son uniformes. La amenaza más crítica en una cloud puede no ser un problema en otra. Los defensores e investigadores deben adaptar sus estrategias, reconociendo que no existe un enfoque "1 a 1" para los controles de seguridad en un entorno cloud .
Para profundizar en la investigación que hay detrás de cada uno de estos modelos de amenaza y de las distintas arquitecturas, consulte el informe técnico adjunto "A Comparative Threat Model of CSP-Managed Machine Identities".