En los últimos tres años, el panorama de la IA ha experimentado una enorme transformación. Hemos pasado de modelos lingüísticos básicos a modelos completos. Agentes de IA que puedan actuar en nuestro nombre en unos pocos años. La IA es la nueva palabra de moda en todas partes. Todos bromeamos sobre ella, pero en realidad ha tenido un auge increíble y es extremadamente poderosa. Y, como puede ver, la IA no es nueva. Existe desde hace tiempo, pero desde la introducción de los LLM y la IA Generativa en 2023, se ha producido un repunte en su uso.
Aunque el potencial de productividad que ofrece el uso de la IA es enorme, existen problemas de seguridad que deben abordarse cuando se trabaja con sistemas autónomos como los agentes de IA. Una mala configuración de las políticas de acceso a los datos podría llevar a la IA a recuperar documentos internos sensibles o a exponer datos confidenciales. Por lo tanto, en este blog exploramos cómo los enfoques tradicionales de control de acceso se quedan cortos cuando los sistemas de IA necesitan permisos contextuales a nivel de documento a escala y velocidad. Y cubrimos cómo la Autorización de Granularidad Fina (Fine-Grained Authorization, FGA) proporciona una seguridad robusta para la Generación de Recuperación-Aumentada (Retrieval-Augmented Generation, RAG) y los sistemas de IA agéntica. Así pues, aprenda a implantar modelos de permisos que protejan la información sensible al tiempo que permiten a la IA acceder únicamente a los datos autorizados.
El cambiante panorama de la IA y las lagunas de seguridad
Los agentes de IA realizan tareas para los humanos llamando a API, aprendiendo de los errores y, a veces, trabajando sin supervisión humana. Pero, por supuesto, hay riesgos asociados a este rápido crecimiento y uno de esos grandes riesgos es la seguridad. Hemos visto varios tuits y hemos oído a mucha gente del sector hablar de la importancia de la seguridad y la autenticación cuando se aprovechan la IA y los agentes de IA. En la actualidad, no existe un plan universal para integrar la IA de forma segura en las aplicaciones.
OWASP comenzó a definir el Top 10 para solicitudes de LLM en 2023 como un esfuerzo impulsado por la comunidad para destacar y abordar los problemas de seguridad específicos de las aplicaciones de IA, y ahí están los 10 puntos principales para 2025. Uno de ellos es la revelación de información sensible. Los agentes de IA pueden ser autónomos, por lo que sin el manejo adecuado podrían revelar información sensible o datos confidenciales de la empresa, y esto puede ocurrir como resultado de un ataque deliberado o accidentalmente.
La IA debe tener en cuenta los permisos de los usuarios al acceder a los datos. ¿Cómo podemos garantizar que un agente no pueda modificar registros existentes o acceder a documentos restringidos a otros empleados en tiempo de ejecución?
La respuesta es con autorización. Nosotros necesitamos asegurarnos de que nuestra IA Los sistemas sólo muestran la información correcta al usuario adecuado.
Por qué la autorización tradicional se queda corta
Control de acceso basado en roles: RBAC es la forma más común en que la gente implementa la autorización en sus aplicaciones y sitios web. Cuando usamos RBAC, estamos comprobando los roles. Si el usuario tiene un cierto rol asignado o no antes de tomar decisiones de acceso. Si tienen el rol obtienen acceso, si no lo tienen obtienen un error 403 Forbidden. El principal inconveniente de RBAC es principalmente la escalabilidad. No escala bien cuando hay múltiples roles.
Control de acceso basado en atributos (ABAC): ABAC es un paso más allá de RBAC para el acceso de grano fino, lo que nos permite conceder a algunos usuarios acceso a documentos individuales, y a otros acceso a otros.
Sin embargo, sigue siendo insuficiente cuando el documento está en carpetas anidadas, ya que tendría que recuperar todas las carpetas de forma recursiva en la cadena. Cuando el usuario está en grupos anidados, hay que hacer lo mismo. Y tiene que hacer todo esto para autorizar la solicitud.
Veamos cuál es la mejor forma de autorizar. Aquí es donde entra ReBAC (Relationship-Based Access Control). ReBAC permite expresar reglas de autorización basadas en las relaciones que los usuarios y objetos de un sistema mantienen entre sí. Los servicios ReBAC utilizan su conocimiento de las relaciones entre las distintas entidades del sistema para tomar una decisión de autorización. Lo bueno de RebAC es que puede hacer tanto RBAC como ABAC dependiendo de cómo definas esas relaciones.
Autorización detallada: la capa que falta
Autorización de Grano Fino (FGA) aplica dinámicamente las normas de acceso en el nivel de recursos. En lugar de conceder permisos generales, FGA determina en el momento de la consulta exactamente qué documentos puede ver un usuario.
FGA consiste en controlar quién puede hacer qué con qué tipo de recursos, hasta un nivel individual. En un escenario típico que muestre un sistema basado en roles, se podría decir: “Los administradores pueden verlo todo, pero los usuarios normales sólo pueden ver un subconjunto”. Pero en una aplicación del mundo real, especialmente una que trate con muchos documentos, esto podría no ser lo suficientemente flexible. Aquí es donde entra OpenFGA.
OpenFGA es un proyecto de código abierto alojado en el CNCF y mantenido por Okta. Se inspiró en el sistema Zanzibar de Google, que describe cómo se construyó la autorización para todos los servicios de Google. OpenFGA aborda lo anterior permitiendo definir relaciones de autorización. Las relaciones definidas en el modelo de autorización pueden ser directas o indirectas. En pocas palabras, las relaciones directas se asignan directamente entre un usuario y un objeto y se almacenan en una base de datos. Las relaciones indirectas son las relaciones que podemos inferir basándonos en los datos y en el modelo de autorización.
Configuración de OpenFGA ReBAC
Existen 4 conceptos principales sobre OpenFGA y su funcionamiento:
-
- Tienda: Un almacén es una entidad OpenFGA utilizada para organizar modelos de autorización y tuplas. Literalmente, es donde se almacenan los datos
- Modelo de autorización: En un modelo de autorización se define quién puede hacer qué y en qué condiciones. Estas serán sus políticas de autorización expresadas en un modelo. En el modelo, tenemos que definir las entidades que van a ser relevantes a la hora de tomar decisiones de autorización.
- Tuplas de relación: Una tupla de relación es una tupla base o tripleta formada por un usuario, una relación y un objeto. Puede pensar en las tuplas como los “hechos” de su sistema de autorización. Tenemos una forma de relación usuario-objeto. Los datos presentes en las tuplas de relación definen esencialmente el estado del sistema, y las tuplas se modifican a medida que evoluciona el estado del sistema.
- Consultas: Por último, para utilizar esto para comprobar la autorización tenemos que poder consultar el sistema. Y lo que hace el sistema OpenFGA para responder a esta pregunta es recorrer el gráfico. Así, el sistema FGA comienza en el recurso (el informe de gastos) y, de arriba abajo, pregunta
En resumen, los datos de las tuplas de relación definen el grafo. El modelo de autorización define las reglas para recorrer el grafo. Y cuando se consulta al sistema, la consulta recorre el grafo de acuerdo con las reglas y devuelve “Sí, está autorizado” o “No, no lo está” en función del resultado.
Control de acceso basado en relaciones OpenFGA
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# Model definition type user type team relations define member: [user] type document relations define viewer: [team#member] # Relationship tuples team:finance#member@user:kate document:forecast.pdf#viewer@team:finance |
Significado: Kate puede ver forecast.pdf porque es miembro del equipo de Finanzas, que tiene derechos de visualización sobre ese documento.
Implantación de FGA en un canal de IA RAG
El GAR es un marco diseñado para superar las limitaciones de los LLM y ofrecer respuestas más precisas y detalladas. Aunque los LLM se entrenan con vastos conjuntos de datos, a menudo tienen problemas con los conocimientos especializados, la información actualizada y la generación de resultados incorrectos en cuanto a los hechos, también conocidos como “alucinaciones”. El GAR mitiga estos problemas recuperando dinámicamente datos relevantes de fuentes externas en tiempo real.
En lugar de basarse exclusivamente en conocimientos preformados, un sistema RAG recupera datos específicos del dominio. Esto es estupendo cuando los datos son públicos o se pueden compartir libremente. Pero, ¿qué hacer si algunos de esos datos son restringidos o confidenciales? Esto plantea un reto importante: garantizar que cada usuario sólo accede a la información que está autorizado a ver. Un sistema RAG seguro debe aplicar un control de acceso preciso sin sacrificar la velocidad ni la escalabilidad. Los roles pueden cambiar, los proyectos pueden reasignarse y los permisos pueden evolucionar con el tiempo. Manejar todo esto de manera eficiente es clave para construir una aplicación RAG verdaderamente segura y robusta.
Y aquí es exactamente donde entra OpenFGA. Integrando OpenFGA con un canal RAG, podemos desacoplar la lógica de control de acceso del núcleo de la aplicación RAG. Podemos aplicar modelos de autorización en tiempo real y garantizar que el contexto recuperado siempre se filtra de acuerdo con los permisos del usuario antes de enviarlo al LLM para generar una respuesta.
Cuando se integra con una base de datos vectorial como Couchbase, Existen dos estrategias principales para implantar OpenFGA en el GAR:
1. Postfiltrado
-
- Recuperar documentos de Couchbase Vector Search
- Pasar los resultados a OpenFGA para eliminar los documentos no autorizados
- Enviar los resultados filtrados al modelo de IA
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
def search_authorized_documents(self, query: str, user_id: str, top_k: int = 5) -> List[Dict[str, Any]]: """Search for documents using the pre-query filtering pattern""" try: # Step 1: Get authorized document IDs from OpenFGA authorized_docs = self.get_authorized_documents(user_id) if not authorized_docs: print(f"No authorized documents found for user: {user_id}") return [] # Step 2: Generate embedding for search query query_embedding = self.generate_embeddings(query, "text-embedding-ada-002") # Step 3: Perform vector search with metadata filter for authorized documents search_req = SearchRequest.create(MatchNoneQuery()).with_vector_search( VectorSearch.from_vector_query( VectorQuery("embedding", query_embedding, num_candidates=top_k * 2) ) ) # Execute search result = self.scope.search(self.search_index_name, search_req) rows = list(result.rows()) # Step 4: Filter results to only include authorized documents authorized_results = [] for row in rows: try: # Get the full document doc = self.collection.get(row.id) if doc and doc.value: doc_content = doc.value doc_source = doc_content.get("source", "") # Check if this document is in the authorized list if doc_source in authorized_docs: authorized_results.append({ "id": row.id, "text": doc_content.get("text", ""), "source": doc_source, "score": row.score, "metadata": doc_content.get("metadata", {}) }) # Stop if we have enough results if len(authorized_results) >= top_k: break except Exception as doc_error: print(f"Could not fetch document {row.id}: {doc_error}") return authorized_results |
2. Prefiltrado
-
- Llama a OpenFGA para eliminar los documentos no autorizados
- Añadir un prefiltro a la consulta de búsqueda vectorial para limitar el ámbito de búsqueda
- Recuperar sólo las incrustaciones de los documentos a los que el usuario puede acceder
Ejemplo de FGA con RAG
Supongamos que usted, como desarrollador, desea utilizar un asistente de IA para obtener las previsiones de la empresa. El sistema debe asegurarse de que sólo ve los datos de previsión públicos y no los informes financieros privados que están restringidos al equipo de Finanzas. Sin las salvaguardas adecuadas, esto se convierte en un riesgo de Divulgación de Información Sensible, exactamente el tipo de problema destacado por el Top 10 de OWASP para aplicaciones LLM.
He aquí cómo lo resuelve la Autorización de Granularidad Fina (FGA):
Paso 1 - Comprobación de permisos: OpenFGA comprueba los derechos de acceso. Si el acceso no pertenece al equipo de Finanzas, se excluyen los documentos financieros privados.
Paso 2 – Filtrado: OpenFGA (a través de su SDK) filtra cualquier resultado que el usuario no deba ver.
Paso 3 – Recuperación de documentos: Realiza una búsqueda vectorial con el filtro aplicado para recuperar únicamente los documentos que el usuario puede ver.
Paso 4 – Generación de respuestas: LLM genera una respuesta sólo a partir del subconjunto de documentos autorizado.
Aplicaciones en el mundo real
La aplicación de la Autorización de Granularidad Fina en las aplicaciones de IA tiene muchas ventajas. Exploremos algunos de los casos de uso más populares:
-
- SaaS multiusuario: Las consultas de inteligencia artificial de un inquilino nunca recuperan los datos de otro.
- Sanidad: Recuperación de historiales de pacientes restringida únicamente a los médicos autorizados
- Finanzas: Previsiones sensibles y datos reglamentarios accesibles sólo a los equipos pertinentes.
- Legal: Documentos de casos restringidos en función de las asignaciones cliente-abogado
Reflexiones finales: seguridad sin sacrificar la velocidad
Sin la seguridad adecuada, se arriesga a añadir toda una nueva superficie de ataque a su aplicación con IA agéntica. Las aplicaciones de IA manejan ahora datos sensibles de los usuarios y no se limitan a procesar la información, sino que interactúan con las API, automatizan decisiones y actúan en nombre de los usuarios.
Los agentes deben tener un acceso mínimo a los datos de los usuarios, credenciales de acceso no estáticas y un control de acceso detallado. OpenFGA ofrece una forma de proteger la IA en las aplicaciones y, al mismo tiempo, permite que estas escalen a cientos de millones de usuarios activos sin problemas a medida que crece el ecosistema de agentes.
Así, Fine-Grained Authorization, impulsado por OpenFGA e integrado con Couchbase Vector Search, garantiza que los sistemas de IA sean a la vez potentes y seguros, ofreciendo así innovación en IA sin comprometer la seguridad.
