Usuarios repartidos por todas partes
Cuando cada nube y cada cuenta tiene sus propios usuarios, pasa siempre lo mismo: alguien deja la organización y su acceso se elimina en dos de las cinco cuentas donde lo tenía. Otro tiene permisos de administrador "temporales" desde hace un año. Nadie puede responder con certeza a la pregunta más básica de seguridad: ¿quién puede entrar dónde?
Un origen, muchos destinos
La solución es federar: un único proveedor de identidad de la organización, conectado a todas las nubes. Las personas entran siempre con su cuenta corporativa, y cada nube confía en ese origen para saber quién es quién.
Con eso:
- Dar de alta y de baja ocurre en un solo sitio. Cuando alguien se va, pierde el acceso a todo a la vez.
- Los permisos se asignan por grupos y roles, no persona a persona.
- La autenticación fuerte (segundo factor) se exige una vez, en el origen.
Roles definidos una vez
Los roles se definen en la norma, con nombres comunes para todas las nubes: lectura, operador de una aplicación, administrador de plataforma, auditor. Cada nube traduce ese rol a sus permisos concretos, pero la organización piensa en un solo conjunto de roles, ligado al mapa de responsabilidades.
Lo delicado, temporal
Los permisos amplios (administrar producción, cambiar la red, acceder a datos sensibles) no se asignan de forma permanente. Se solicitan cuando hacen falta, con motivo, y caducan solos al cabo de unas horas. Cada uso queda registrado. Es el mismo principio de las excepciones con fecha, aplicado al acceso.
Las identidades que no son personas
Aplicaciones, procesos automáticos y agentes también necesitan identidad. Para ellos rige la misma lógica: identidades propias, permisos mínimos, credenciales que no viven en el código y que se rotan (como en secretos con nombre, nunca con valor).
Cuentas ordenadas e identidad unificada son la base. Sobre ellas se apoyan las reglas que se aplican solas en toda la jerarquía.
Cómo lo aplicamos: Gobierno Multicloud.