Nos últimos três anos, o cenário da IA passou por uma enorme transformação. Passamos de modelos básicos de linguagem para modelos completos de Agentes de IA que podem agir em nosso nome em apenas alguns anos. A IA é a nova palavra da moda em todos os lugares. Todos nós brincamos com ela, mas, na realidade, ela teve um crescimento incrível e é extremamente poderosa. E, como você pode ver, a IA não é nova. Ela já existe há algum tempo, mas desde a introdução dos LLMs e da IA geradora em 2023, houve um aumento em seu uso.
Embora o potencial de produtividade com o uso da IA seja enorme, há preocupações de segurança que devem ser abordadas ao trabalhar com sistemas autônomos, como os agentes de IA. Políticas de acesso aos dados mal configuradas podem fazer com que a IA recupere documentos internos sensíveis ou exponha dados confidenciais. Portanto, neste blog, exploramos como as abordagens tradicionais de controle de acesso são insuficientes quando os sistemas de IA precisam de permissões contextuais em nível de documento em escala e velocidade. Além disso, abordamos como a FGA (Fine-Grained Authorization, autorização refinada) oferece segurança robusta para a RAG (Retrieval-Augmented Generation, geração aumentada por recuperação) e sistemas de IA agêntica. Assim, saiba como implementar modelos de permissão que protegem informações confidenciais e, ao mesmo tempo, permitem que a IA acesse somente dados autorizados.
O cenário de IA em constante mudança - e as lacunas de segurança
Os agentes de IA executam tarefas para o ser humano chamando APIs, aprendendo com os erros e, às vezes, trabalhando sem supervisão humana. Mas, é claro, há riscos associados a esse rápido crescimento e um desses grandes riscos é a segurança. Vimos vários tweets e ouvimos muitas pessoas do setor discutirem a importância da segurança e da autenticação ao aproveitar a IA e os agentes de IA. Atualmente, não há um modelo universal para a criação de IA com segurança nos aplicativos.
A OWASP começou a definir o As 10 principais candidaturas para LLM em 2023 como um esforço orientado pela comunidade para destacar e abordar problemas de segurança específicos dos aplicativos de IA, e há os 10 principais pontos para 2025. Um deles é a divulgação de informações confidenciais. Os agentes de IA podem ser autônomos, portanto, sem o tratamento adequado, eles podem revelar informações confidenciais ou dados corporativos confidenciais, e isso pode acontecer como resultado de um ataque deliberado ou acidentalmente.
A IA deve considerar as permissões do usuário ao acessar os dados. Como podemos garantir que um agente não possa modificar registros existentes ou acessar documentos restritos a outros funcionários em tempo de execução?
A resposta é com autorização. Nós precisamos garantir que nossa IA Os sistemas mostram apenas as informações certas para o usuário certo.
Por que a autorização tradicional é insuficiente
Controle de acesso baseado em função: O RBAC é a maneira mais comum de as pessoas implementarem autorização em seus aplicativos e sites. Quando usamos o RBAC, estamos verificando as funções. Se o usuário tem uma determinada função atribuída a ele ou não, antes de tomar decisões de acesso. Se ele tiver a função, terá acesso; se não tiver, receberá um erro 403 Forbidden. A principal desvantagem do RBAC é principalmente a escalabilidade. Ele não é bem dimensionado quando há várias funções.
Controle de acesso baseado em atributos (ABAC): O ABAC é um avanço em relação ao RBAC para acesso refinado, permitindo que concedamos a alguns usuários acesso a documentos individuais e a outros acesso a outros.
No entanto, isso ainda é insuficiente quando o documento está em pastas aninhadas, pois você precisaria recuperar todas as pastas recursivamente na cadeia. Quando o usuário estiver em grupos aninhados, você precisará fazer a mesma coisa. E você precisa fazer tudo isso para autorizar a solicitação.
Então, vamos ver qual é uma maneira ainda melhor de fazer a autorização. É aqui que entra o ReBAC (Controle de Acesso Baseado em Relacionamento). O ReBAC permite expressar regras de autorização com base nas relações que os usuários e objetos em um sistema têm entre si. Os serviços ReBAC usam seu conhecimento das relações entre as diferentes entidades no sistema para chegar a uma decisão de autorização. A vantagem do RebAC é que ele pode fazer tanto RBAC quanto ABAC, dependendo de como você define esses relacionamentos.
Autorização detalhada - a camada que faltava
Autorização detalhada (FGA) impõe dinamicamente as regras de acesso no nível de recursos. Em vez de conceder permissões gerais, o FGA determina, no momento da consulta, exatamente quais documentos um usuário tem permissão para ver.
A FGA tem tudo a ver com o controle de quem pode fazer o quê com que tipo de recursos, até o nível individual. Em um cenário típico que mostra um sistema baseado em funções, pode-se dizer: “Os administradores podem ver tudo, mas os usuários comuns podem ver apenas um subconjunto”. Mas em um aplicativo do mundo real, especialmente um que lida com muitos documentos, isso pode não ser flexível o suficiente. É aí que entra o OpenFGA.
OpenFGA é um projeto de código aberto hospedado no CNCF e mantido pela Okta. Ele foi inspirado no sistema Zanzibar do Google, que descreve como foi criada a autorização para todos os serviços do Google. O OpenFGA aborda o acima exposto, permitindo que você defina relações de autorização. Os relacionamentos definidos no modelo de autorização podem ser diretos ou indiretos. Em termos simples, as relações diretas são atribuídas diretamente entre um usuário e um objeto e armazenadas em um banco de dados. As relações indiretas são as relações que podemos inferir com base nos dados e no modelo de autorização.
Configuração do OpenFGA ReBAC
Há quatro conceitos principais sobre o OpenFGA e como ele funciona:
-
- Loja: Um armazenamento é uma entidade OpenFGA usada para organizar modelos de autorização e tuplas. Literalmente, é onde você armazena seus dados
- Modelo de autorização: Um modelo de autorização é onde você define quem pode fazer o quê e sob quais condições. Essas serão suas políticas de autorização expressas em um modelo. No modelo, temos de definir as entidades que serão relevantes ao tomar decisões de autorização.
- Tuplas de relacionamento: Uma tupla de relacionamento é uma tupla ou tripla de base que consiste em um usuário, uma relação e um objeto. Você pode pensar nas tuplas como os “fatos” do seu sistema de autorização. Temos uma forma de relação usuário-objeto. Os dados presentes nas tuplas de relacionamento definem essencialmente o estado do seu sistema, e você modifica as tuplas à medida que o estado do sistema evolui
- Consultas: Por último, para usar isso para verificar a autorização, temos que ser capazes de consultar o sistema. E o que o sistema OpenFGA faz para responder a essa pergunta é percorrer o gráfico. Portanto, o sistema FGA começa no recurso (o relatório de despesas) e, de cima para baixo, pergunta
Em resumo, os dados nas tuplas de relacionamento definem o gráfico. O modelo de autorização define regras para percorrer o gráfico. E quando você consulta o sistema, a consulta percorre o gráfico de acordo com as regras e retorna “Sim, você está autorizado” ou “Não, você não está”, dependendo do resultado.
Controle de acesso baseado em relacionamento 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 pode visualizar forecast.pdf porque ela é membro da equipe de Finanças, que tem direitos de visualização nesse documento.
Implementação de FGA em um pipeline de IA RAG
O RAG é uma estrutura projetada para superar as limitações dos LLMs e fornecer respostas mais precisas e detalhadas. Embora os LLMs sejam treinados em vastos conjuntos de dados, eles geralmente têm dificuldades com conhecimento especializado, informações atualizadas e geração de resultados factualmente incorretos, também conhecidos como “alucinações”. O RAG atenua esses problemas recuperando dinamicamente dados relevantes de fontes externas em tempo real.
Em vez de depender exclusivamente do conhecimento pré-treinado, um sistema RAG recupera dados específicos do domínio. Isso é ótimo quando os dados são públicos ou podem ser compartilhados livremente. Mas o que fazer se alguns desses dados forem restritos ou confidenciais? Isso gera um desafio significativo: garantir que cada usuário acesse somente as informações que está autorizado a ver. Um sistema RAG seguro precisa impor um controle de acesso refinado sem sacrificar a velocidade ou a escalabilidade. As funções podem mudar, os projetos podem ser reatribuídos e as permissões podem evoluir com o tempo. Lidar com tudo isso de forma eficiente é fundamental para a criação de um aplicativo RAG realmente seguro e robusto.
E é exatamente aí que entra o OpenFGA. Ao integrar o OpenFGA a um pipeline RAG, podemos desacoplar a lógica de controle de acesso do aplicativo RAG principal. Podemos aplicar modelos de autorização em tempo real e garantir que o contexto recuperado seja sempre filtrado de acordo com as permissões do usuário antes de ser enviado ao LLM para gerar uma resposta.
Ao fazer a integração com um banco de dados vetorial como o Couchbase, De acordo com a análise do OpenFGA, há duas estratégias principais para implementar o OpenFGA para RAG:
1. Pós-filtragem
-
- Recuperar documentos do Couchbase Vector Search
- Passe os resultados para o OpenFGA para remover documentos não autorizados
- Enviar resultados filtrados para o 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. Pré-filtragem
-
- Chame o OpenFGA para remover os documentos não autorizados
- Adicione um pré-filtro para a consulta de pesquisa de vetor para limitar o escopo da pesquisa
- Recupere apenas os embeddings dos documentos que o usuário pode acessar
Exemplo de FGA com RAG
Digamos que você, como desenvolvedor, queira usar um assistente de IA para obter a previsão da empresa. O sistema deve garantir que você veja apenas os dados públicos da previsão e não os relatórios financeiros privados restritos à equipe de finanças. Sem as proteções corretas, isso se torna um risco de divulgação de informações confidenciais, exatamente o tipo de problema destacado pelo OWASP Top 10 para aplicativos LLM.
Veja como a FGA (Fine-Grained Authorization) resolve esse problema:
Etapa 1 - Verificação de permissões: O OpenFGA verifica os direitos de acesso. Se o acesso não pertencer à equipe de finanças, os documentos financeiros privados serão excluídos.
Etapa 2 – Filtragem: O OpenFGA (por meio de seu SDK) filtra todos os resultados que o usuário não deve ver.
Etapa 3 – Recuperação de documentos: Execute a pesquisa vetorial com o filtro aplicado para recuperar apenas os documentos permitidos para serem vistos pelo usuário.
Etapa 4 – Geração de respostas: O LLM gera uma resposta somente a partir do subconjunto autorizado de documentos.
Aplicativos do mundo real
Há muitos benefícios em aplicar a autorização refinada em aplicativos de IA. Vamos explorar alguns dos casos de uso mais populares:
-
- SaaS multiusuário: As consultas de IA de um locatário nunca recuperam os dados de outro locatário
- Assistência médica: Recuperação de registros de pacientes que é restrita apenas a profissionais autorizados
- Finanças: Previsões confidenciais e dados regulatórios acessíveis apenas às equipes relevantes
- Legal: Documentos de casos restritos com base em atribuições de cliente-advogado
Considerações finais: segurança sem sacrificar a velocidade
Sem a segurança correta, você corre o risco de adicionar uma superfície de ataque totalmente nova ao seu aplicativo com IA agêntica. Os aplicativos de IA agora lidam com dados confidenciais do usuário e não estão apenas processando as informações; eles estão interagindo com APIs, automatizando decisões e agindo em nome dos usuários
Os agentes precisam ter acesso menos privilegiado aos dados do usuário, credenciais de acesso não estáticas e controle de acesso refinado. O OpenFGA oferece uma maneira de proteger a IA em aplicativos e, ao mesmo tempo, permite que os aplicativos escalem centenas de milhões de usuários ativos sem problemas à medida que o ecossistema de agentes cresce.
Assim, a Autorização refinada, desenvolvida pelo OpenFGA e integrada ao Couchbase Vector Search, garante que os sistemas de IA sejam eficientes e seguros, proporcionando inovação em IA sem comprometer a segurança.
