Identidades y roles de servicios de modelos

Un servicio de modelos suele aceptar dos maneras de autenticarse. Una es la clave local del recurso: una cadena que se pega en la aplicación y que sirve a cualquiera que la tenga, desde donde sea, sin decir quién es. La otra es una identidad del directorio de la nube: una persona, un grupo o una identidad gestionada, que es la que la nube le da a una carga de trabajo para que se autentique sin guardar ningún secreto. Con identidades cada llamada lleva nombre, se puede limitar con un rol y se retira sin tocar a nadie más.

Por eso las líneas base piden apagar las claves locales en producción. En Azure, por ejemplo, los recursos de servicios de IA tienen una propiedad que, activada, rechaza las claves y obliga a usar identidades del directorio.

Una aplicación que solo necesita preguntar al modelo debe tener el rol de inferencia, limitado a su propio despliegue. Si en cambio tiene un rol de administración, quien comprometa esa aplicación —por un fallo en su código, por una dependencia o por una instrucción que el modelo obedeció— hereda la capacidad de bajar filtros, apagar el registro o crear despliegues nuevos. Es el mínimo privilegio de siempre, con una consecuencia nueva: en un servicio de modelos, administrar incluye desactivar los controles que vigilan al propio modelo.

Un permiso que no se usa no aporta nada a quien lo tiene y sí a quien le robe la cuenta. La revisión periódica de roles busca justo eso: personas que cambiaron de área, proyectos que terminaron, accesos dados «por si acaso». La regla de Coipo es revisar los roles de administración cada 90 días y retirar los que no se usaron en ese tiempo.

La regla de los 90 días tiene un punto ciego: un acceso usado hace poco pasa la revisión aunque ya no tenga razón de existir. Las cuentas invitadas de contratistas son el caso típico: se crean para un piloto, el contrato termina y la cuenta sigue ahí, con todos sus permisos y en uso. El uso reciente no la vuelve legítima; la vuelve más urgente.

Apagar las claves locales de golpe rompe a quien todavía las usa. El orden sano es saber quién las usa, pasar cada uso a una identidad con el rol justo, apagar las claves y comprobar que el cambio surtió efecto: en algunas nubes el corte no es instantáneo, porque la pasarela del servicio puede seguir aceptando claves viejas durante un tiempo. Por eso se verifica con una llamada de prueba autorizada, no se da por hecho.