Menor privilegio con proveedores de IA: qué permisos conceder
Aplicar el menor privilegio a un proveedor de IA es darle un rol de sólo lectura por tabla, destinos de red par a par y la lectura separada de la escritura.
En resumen
- Aplicar el principio de menor privilegio a un proveedor de IA significa conceder accesos enumerados uno por uno: un rol de base de datos de sólo lectura tabla por tabla, destinos de red par a par y alcances de lectura separados de los de escritura.
- Cuando un proveedor pide acceso amplio «para simplificar la integración», el trabajo de acotar el alcance no desaparece: se muda al lado del cliente en forma de riesgo.
- Un pedido de permisos bien hecho se verifica en treinta segundos: cada alcance trae su motivo, ningún alcance de la lista incluye a otro de la misma lista y la escritura se pide por separado de la lectura.
- Los controles más fuertes de una integración son los que aplica el cliente: acotar la delegación a las personas habilitadas, conceder vistas en lugar de tablas y declarar pares máquina–puerto en lugar de rangos.
- Pedir menos acceso hace más lenta la puesta en marcha y agrega un paso de coordinación cada vez que aparece un destino nuevo. Es el costo del modelo, y conviene conocerlo antes de empezar.
Aplicar el principio de menor privilegio a un proveedor de IA significa concederle sólo los accesos que su caso de uso necesita, enumerados uno por uno: un rol de base de datos de sólo lectura tabla por tabla, destinos de red declarados par a par y la lectura separada de la escritura. Lo demás es riesgo del cliente.
Hay una conversación que aparece en cada evaluación de una integración. El equipo de sistemas pregunta qué accesos hacen falta, recibe la lista y alguien dice, con buena intención: «¿no es más fácil darles un usuario con permisos amplios y listo?». Sí, es más fácil. Y es lo que Igniten no pide.
¿Por qué «acceso amplio para simplificar» es un mal argumento?
Porque esconde una transferencia de trabajo en forma de riesgo. «Pedimos acceso amplio para simplificar la integración» se escucha en muchas evaluaciones de proveedores y funciona porque parece un gesto de eficiencia: menos reuniones, menos tickets, arranque más rápido.
El trabajo de decidir qué necesita ver un sistema externo existe siempre. Alguien tiene que enumerar tablas, revisar columnas, definir a qué buzones se accede. La única variable es de qué lado del contrato se paga. Cuando el proveedor lo evita, ese trabajo se convierte en exposición del cliente, y la asimetría es completa: de las dos partes, la que pierde si el acceso amplio se usa mal —o si el proveedor sufre un incidente— es el cliente.
Eso es el principio de menor privilegio: el alcance de un daño no debería depender de la buena conducta de nadie. Es también el primer tema de cualquier gobernanza de datos que involucre a un tercero.
¿Qué permisos conceder a un proveedor de IA?
Los que Igniten pide, y los que conviene exigirle a cualquier proveedor que conecte un agente de IA a sus sistemas, se resumen en tres pedidos:
| Sistema | Qué conceder | Qué evitar |
|---|---|---|
| Base de datos | Un rol dedicado, de sólo lectura, tabla por tabla o vista por vista | El esquema completo, ALL PRIVILEGES, un rol compartido con personas o aplicaciones |
| Red interna | Pares máquina–puerto declarados en una lista que sólo el cliente edita | Rangos de direcciones, puertos entrantes abiertos |
| Suite corporativa | Alcances de lectura en un nivel base; escritura en un nivel aparte y opcional | Lectura y escritura en un solo paquete, delegación sobre todo el dominio |
Un rol de base de datos dedicado, de sólo lectura, tabla por tabla
El rol tiene que ser distinto de cualquier rol de persona o de aplicación que ya exista. Eso tiene una consecuencia práctica que suele convencer más que el argumento de seguridad: las consultas del proveedor son distinguibles en los registros del cliente. Si alguien quiere saber qué está haciendo Igniten contra su base, lo ve sin preguntar. Y revocar ese rol no afecta a nada más.
Después, GRANT USAGE sobre los esquemas necesarios y GRANT SELECT tabla por tabla o vista por vista. Nunca sobre el esquema completo.
Cuando haya columnas sensibles que no aportan al análisis, lo recomendable es conceder una vista en lugar de la tabla. Una vista sin la columna de salarios es más verificable que cualquier promesa de no consultarla. Conviene además acotar el tiempo máximo de sentencia y el número de conexiones de ese rol: protege a las dos partes de una consulta accidental en un cierre de mes. Si la política interna lo exige, la seguridad a nivel de fila también puede aplicarse del lado del cliente, sin cambios del lado de Igniten.
El recorrido para cada motor —PostgreSQL, SQL Server, Oracle, MySQL y los demás— está en las integraciones de Igniten, con el usuario de sólo lectura que hay que crear en cada caso.
Una lista explícita de destinos de red, que sólo el cliente edita
Cuando la base vive dentro de la red del cliente, la conexión la establece un conector que el cliente instala y que abre la sesión hacia afuera. Nunca al revés: no hay que abrir ningún puerto entrante.
Lo que importa es la lista de destinos. Es un archivo que vive en la infraestructura del cliente y que sólo el cliente edita. Contiene los pares máquina–puerto que su administrador declaró: pares, no rangos. Igniten puede solicitar un destino nuevo, y la solicitud queda registrada, pero no surte efecto hasta que alguien del equipo del cliente la incorpora al archivo.
Aunque el plano de control de Igniten estuviera comprometido, no existe un camino por el que pueda ampliar su alcance dentro de esa red. El equipo de seguridad del cliente puede confirmarlo revisando el código del conector, que está disponible para revisión a pedido y bajo acuerdo de confidencialidad.
Alcances de la suite corporativa en dos niveles
Las aplicaciones que conectan Igniten con Google Workspace, Microsoft 365 o Slack se registran en el directorio de la organización cliente y a su nombre. Los permisos se piden en dos niveles: el base es de sólo lectura y hace funcionar el producto entero; el de acción agrega escritura sobre correo, agenda y mensajería, y es opcional. Si una organización no lo concede, el asistente responde, analiza y redacta, pero no envía ni crea nada. Por qué esa decisión de registro importa se desarrolla en quién controla el acceso de una aplicación de terceros a Google Workspace.
¿Cómo se verifica un pedido de permisos en treinta segundos?
Con tres pruebas que no requieren ser especialista. Cualquiera de las tres, si falla, descalifica la lista entera:
- Cada alcance trae su motivo. No «necesitamos leer el directorio», sino «necesitamos leer los grupos del directorio porque de ahí sale quién tenía derecho a ver cada documento, y sin eso el control de acceso por elemento no funciona». Si el motivo no cabe en una frase, el permiso no está justificado.
- Ningún alcance de la lista incluye a otro de la misma lista. Es la prueba que más revela. Si un proveedor pide el permiso amplio de calendario y también los angostos que el amplio ya contiene, nadie revisó esa lista. En la lista de Igniten para Microsoft 365, por ejemplo, los permisos de lectura y escritura del nivel de acción reemplazan a sus equivalentes de sólo lectura del nivel base; no se piden ambos.
- La escritura viene separada de la lectura. Si vienen en un solo paquete, la organización no puede decidir.
La lista completa de alcances que pide Igniten está publicada, con el motivo de cada uno, para que cualquiera le aplique estas tres pruebas.
¿Qué controles tiene que aplicar el cliente de su lado?
Los que no dependen del proveedor, y por eso son los más fuertes. Son controles que limitan a Igniten y que el cliente verifica en su propia consola:
- Acotar la delegación al conjunto de personas habilitadas, no al dominio entero. En Microsoft, con una política de acceso a aplicaciones limitada a un grupo de buzones. Es la diferencia entre conceder la organización completa y conceder a las personas que usan el producto.
- Segundo factor obligatorio en el directorio. El acceso vale exactamente lo que valga la identidad corporativa.
- Atar las bajas al proceso de recursos humanos, para que el acceso y el consentimiento delegado caigan juntos.
- Empezar con treinta días de histórico y ampliar después. Reduce la exposición y el costo al mismo tiempo; ampliar más adelante es una operación de ingesta, no una migración.
- Revisar periódicamente los alcances autorizados en la propia consola. Es la vista de lo que un proveedor puede hacer que no depende de lo que ese proveedor declare.
¿Qué cuesta pedir el menor acceso posible?
Cuesta velocidad y capacidad, y conviene decirlo. Una puesta en marcha con acceso amplio es más corta que una que requiere coordinar un rol, una lista de destinos y un registro de aplicación con el equipo de sistemas. Cada destino nuevo agrega un correo y una espera. Cada permiso hay que saber justificarlo, y a veces la conclusión es que sobra y hay que sacarlo del producto.
También deja menos capacidad: hay análisis que no se pueden hacer porque la columna no está concedida, y consultas que no se resuelven porque el destino no está declarado. Es el mismo criterio que evita el vendor lock-in: un proveedor imprescindible, o con más acceso del necesario, es un riesgo del cliente y no una virtud del proveedor.
Menos acceso también reduce lo que puede hacer una instrucción maliciosa escondida en un documento; la otra mitad de esa defensa está en por qué el asistente no ejecuta nada sin confirmación humana. Si su empresa está evaluando a qué proveedor darle acceso, el inventario de uso y la elección de proveedor se trabajan en el diagnóstico de IA y proveedores. La documentación técnica de seguridad de Igniten está publicada entera, con el inventario de controles fila por fila; la plataforma está en beta privada y esa página describe sus controles en disponibilidad general. Más notas sobre el tema, en el tema de gobernanza de IA del blog.