Huawei Cloud: un solo landing zone para gobernar cuentas de proyecto separadas
El proveedor chino detalla el patrón: cada proyecto mantiene su facturación, pero seguridad y auditoría cuelgan de una única cuenta de gobierno independiente.
Multi-cuenta es ya la norma en cualquier empresa de cierto tamaño. Lo que Huawei Cloud detalla en su documentación es cómo montarlo sin que cada proyecto acabe con su propio landing zone. La recomendación es tajante: un único landing zone empresarial levantado desde una cuenta de gestión independiente, y las cuentas maestras de proyecto invitadas dentro como miembros.
El anti-patrón que la compañía marca en rojo es el habitual en muchas organizaciones: que cada cuenta maestra de proyecto ejecute por su cuenta la configuración del landing zone. El resultado son líneas base de seguridad distintas por proyecto, rastros de auditoría repartidos en silos y ninguna detección de amenazas que vea el conjunto. Cada isla funciona, pero nadie tiene la foto completa.
Cuenta de gobierno aparte y auditoría delegada
El primer paso es no reciclar ninguna cuenta maestra existente como raíz. Se crea una cuenta de gestión nueva, con su propio correo corporativo, que solo gestiona el árbol de la organización, aplica las políticas de control de servicio (SCP) y delega privilegios de administrador. Ahí no corre carga de negocio ni se procesa la facturación de ningún proyecto.
Sobre esa cuenta se levanta el landing zone desde el centro de gobierno de recursos (RGC), siguiendo el procedimiento de configuración que publica Huawei. Durante el asistente se pide crear una cuenta de auditoría nueva. RGC la coloca en la OU de seguridad y la nombra administrador delegado de los servicios de auditoría centralizada: CTS para agregar los logs de API de todas las cuentas, Config para vigilar el cumplimiento de las líneas base y SecMaster para la detección de amenazas a nivel de organización.
Después, desde la cuenta de gestión se invita a las cuentas maestras de proyecto, que aceptan y quedan colgadas de la OU de cargas de trabajo. Aquí está el detalle que suele frenar este diseño en una empresa grande: unirse al árbol de la organización no toca las relaciones financieras. Cada cuenta maestra sigue liquidando sus propias facturas y conservando los descuentos negociados. Lo que cambia es el plano de control, no el del pago.
Una vez dentro, RGC configura los rastros a nivel de organización: los logs operativos de las cuentas de proyecto y de sus subcuentas se envían solos a los buckets OBS de la cuenta de auditoría, y las SCP impiden que un administrador de proyecto los modifique o los borre. El equipo de seguridad entra en una sola cuenta y ve inventario, cumplimiento y alertas de todos los proyectos a la vez. La separación de responsabilidades entre cuentas de seguridad y cargas de trabajo sigue el diseño de organización y cuentas del marco de adopción de cloud (CAF).
Qué implica operarlo
El diseño tiene sentido para quien lleva gobernanza en cloud y arrastra el problema clásico: seguridad quiere una vista única, finanzas quiere facturas separadas y los equipos de proyecto no quieren depender de nadie para desplegar. Las dos primeras se resuelven con cuentas separadas; la tercera se deja intacta.
El coste es organizativo. Hay que convencer a cada responsable de proyecto de ceder la gestión del árbol y de los logs a una cuenta que no controla, y asumir que la cuenta de gestión pasa a ser pieza crítica: si se pierde el acceso a ella, se pierde la capacidad de aplicar políticas y de gobernar el conjunto. La documentación cubre los pasos y los parámetros del asistente, pero no entra en qué ocurre cuando esa cuenta se ve comprometida.
