Control de acceso, identidad y gestión de secretos

Ganancias:

• Capacidad de separar autenticación y autorización y aplicar autorización mínima con RBAC/ABAC
• Capacidad para evitar riesgos de proxy mixto ejecutando el modelo en el contexto del usuario
• Capacidad para almacenar y rotar claves API con el sistema de gestión secreta

Una parte importante de los ataques a un sistema de IA no comienzan con "engañar" al modelo, sino con una clave API robada o una cuenta sobreautorizada. Esta capa de seguridad proviene de la seguridad de la información clásica, pero agrega nuevos riesgos en el contexto de la IA: un modelo solicita un viaje en nombre de otra persona, una cuenta de servicio accede a todos los datos, una clave se filtra a GitHub. En esta unidad, aprenderemos cómo limitar el acceso al sistema de IA con autenticación, autorización (RBAC/ABAC), autorización mínima y gestión de secretos.

Diferencia entre autenticación y autorización

A menudo se confunden ambos términos:

• Autenticación: "¿Quién eres?" — demostrar que el usuario/servicio es realmente quien dice ser (contraseña, token, certificado, MFA).
• Autorización: "¿Qué puedes hacer?" — determinar a qué recurso/acción puede acceder la parte autenticada.

La sutileza crítica en los sistemas de IA es la siguiente: cuando el modelo realiza un trabajo en nombre de un usuario, ¿está operando con la autoridad de ese usuario o con una cuenta de servicio amplia? Esto último es peligroso, porque el modelo engañado por la inyección obtiene acceso completo a la cuenta de servicio.

Precaución: Problema de "diputado confuso": un usuario con poca autoridad accede indirectamente a datos a los que no puede acceder mediante la subcontratación de un modelo de alta autoridad. El modelo siempre debe operar dentro del contexto de la autoridad del usuario, no de su propia autoridad amplia.

RBAC y ABAC

• RBAC (Control de acceso basado en roles): el acceso depende del rol del usuario. La función de "especialista en soporte" puede leer las notas de los clientes, pero no puede eliminarlas. Sencillo y común.
• ABAC (Control de Acceso Basado en Atributos): El acceso depende de atributos: el departamento del usuario, la etiqueta de privacidad de los datos, la hora del día, la red de donde proviene la solicitud. Más afinado pero más complejo.

La mayoría de las organizaciones comienzan con RBAC y profundizan hasta ABAC para datos confidenciales. Regla general para la IA: el modelo debe filtrar cada agente al que llama y todos los datos a los que accede en función del rol/atributos del usuario que realiza la solicitud.

Paso a paso: ejercer una autoridad mínima

1. Haga un inventario. ¿A qué herramientas llama el modelo, a qué datos accede? Enumérelos todos.
2. Justifique cada acceso. “¿Este asistente realmente necesita autorización de eliminación?” De lo contrario, retírelo.
3. Valor predeterminado de solo lectura. El modelo debería poder leer de forma predeterminada; Requiere escribir/eliminar un token separado y de alcance limitado.
4. Mover el contexto del usuario. Llame al vehículo con la autoridad del usuario, no con la cuenta de servicio.
5. Credencial de corta duración. Utilice tokens de corta duración y renovación automática en lugar de claves de larga duración.

Gestión Secreta

Un secreto son credenciales que deben permanecer secretas, como una clave API, una contraseña, un token o un certificado. El accidente más común en proyectos de IA es cuando la clave API del proveedor del modelo está incrustada en el código y se filtra al control de versiones (Git).

Aplicación correcta:

• Nunca incrustes claves en el código; Utilice una variable de entorno o un sistema de gestión de secretos (un servicio que almacena claves cifradas y controla el acceso).
• Rotación: renovar las claves a intervalos regulares (por ejemplo, cada 90 días); Si se sospecha una fuga, cancelar inmediatamente.
• Reducción del alcance: Cada conmutador tiene solo el servicio requerido y la autorización requerida.
• Auditoría: registre quién usó la clave, cuándo y dónde.

Cuatro plantillas copiables

Solicitud de control de revisión de acceso:

Para cada herramienta en la lista de herramientas a continuación, evalúe: - ¿Se REQUIERE esta herramienta para realizar el trabajo de este asistente? (sí/no) - ¿Es de sólo lectura o de escritura/borrado? - ¿Se llama a esta herramienta con la autoridad del usuario o la cuenta de servicio? Marque los innecesarios o excesivamente autorizados como "ELIMINAR/REDACTAR".<tools>{{ tool_list }}</tools>

Aviso de escaneo de fugas secretas:

Encuentre cualquier cosa que pueda ser un secreto codificado en el siguiente fragmento de código: clave API, contraseña, token, cadena de conexión, clave privada. Indica fila y tipo para cada uno. COPIAR valor en respuesta; máscara (primeros 4 caracteres + ***).<code>{{ source }}</code>

Regla de decisión de mínima autoridad:

Cuando llegue una nueva herramienta/solicitud de acceso, pregunte:1. ¿Se puede realizar la tarea sin este acceso? -> En caso afirmativo: RECHAZAR2. ¿Es suficiente solo lectura? -> En caso afirmativo: OTORGAR permiso de escritura3. ¿Se puede reducir el alcance a una sola fuente? -> En caso afirmativo: daratLa respuesta predeterminada es "no"; El acceso se obtiene por la razón.

Recordatorio del calendario de rotación:

Para cada secreto, registre: propietario, fecha de creación, vencimiento, alcance. Reporte cualquier clave que haya excedido los 90 días o que no haya sido utilizada durante 30 días como "CANDIDATO DE ROTACIÓN/CANCELACIÓN".

Aviso débil / Aviso fuerte

mal enfoque

Enfoque fuerte

Model accede a todos los datos con una única cuenta de servicio

El modelo accede con la autoridad del usuario que realiza la solicitud

La clave API está integrada en el código, nunca cambia

Rotación en administrador secreto de claves, 90 días.

Amplia autoridad para "hacer cualquier cosa" al asistente

Valor predeterminado de solo lectura, escritura limitada

Los accesos nunca se revisan

Revisión y revocación periódica del acceso

Tres mini estuches

Caso 1: datos de proxy mixtos filtrados. Un asistente interno trabajaba con una cuenta de servicio que tenía acceso a todos los registros de los empleados. Un usuario interno accedió a datos que normalmente no vería diciendo "resumir la tabla salarial de los ejecutivos"; porque el modelo lo cuestionó en el contexto de su propia autoridad amplia, no la del usuario. Una vez que el contexto del usuario se ajustó para ser movido, el pasante pudo extraer grabaciones que solo él o ella podía ver.

Caso 2: Clave filtrada, factura de 190.000 TL en 2 semanas. Un desarrollador incorporó la clave API del modelo en un script auxiliar y la envió a un repositorio público. Un robot encontró la clave en 40 minutos y la usó durante dos semanas; La factura alcanzó los 190.000 TL. Cuando la clave se movió al administrador secreto, se conectó a la rotación y se agregó el escaneo del repositorio, el incidente no volvió a ocurrir.

Caso 3: La interrupción predeterminada de solo lectura evitó. Un asistente de DevOps recibió un comando de "restablecer la base de datos de producción" mediante una inyección rápida. Sin embargo, al asistente solo se le dio un token de solo lectura; escribir/borrar estaba en un flujo aprobado separado. El comando fue rechazado con error de autorización y el evento se registró como alarma; No hubo pérdida de datos.

Consejo: haga de "no" su respuesta predeterminada a una nueva solicitud de acceso. El acceso es algo que se obtiene mediante la justificación; Dar a todo el mundo amplitud y luego recortar casi nunca se hace y el riesgo se acumula.

Errores comunes

• Ejecutar el modelo con una cuenta de servicio grande y perder el contexto del usuario (proxy mixto).
• Incrustar la clave API en el código y filtrarla al control de versiones.
• No girar las teclas en absoluto ("funcionando, no tocar").
• Otorgar al asistente permisos de escritura/eliminación de forma predeterminada.
• Otorgar acceso una vez y nunca reconsiderarlo.
• Confundir autenticación con autorización y asumir que "ha iniciado sesión, puede acceder a todo".

En resumen

• La autenticación es una cuestión de “quién eres tú”, la autorización es una cuestión de “qué puedes hacer”; En IA, ambos deben operar en el contexto del usuario.
• El modelo debe operar con la autoridad del usuario que realiza la solicitud, no con su propia autoridad amplia (evitando el riesgo de agencia mixta).
• Comience con RBAC, profundice con ABAC en datos confidenciales; Haga que la autoridad mínima sea la predeterminada.
• No entierres secretos en código; guárdelo en el administrador secreto, redúzcalo y póngalo en rotación regular.
• El valor predeterminado de solo lectura y la escritura limitada limitan en gran medida el impacto de la inyección.

Tarea de aplicación

Enumere todas las herramientas y datos a los que accede su asistente de IA. Responda tres preguntas para cada una: (1) ¿Es realmente necesario? (2) ¿Es suficiente solo lectura? (3) ¿Se ejecuta en el contexto del usuario? Luego busque todos los secretos codificados (a través del mensaje de escaneo anterior) y escriba un plan de rotación para cada clave que encuentre. Elimine al menos una autorización innecesaria.

lista de verificación

• [] El modelo se ejecuta en el contexto de autoridad del usuario que realiza la solicitud.
• [] El acceso a herramientas y datos se ha reducido al principio de privilegio mínimo.
• [] Escritura/borrado es independiente de solo lectura, autenticado y limitado.
• [] No hay secretos enterrados en el código; Se guarda en el administrador secreto.
• [ ] Existe un cronograma de rotación y procedimiento de cancelación de llaves.
• [ ] Los accesos se revisan periódicamente.