Control de Acceso Granular en RAG Multi-Departamento con Amazon Verified Permissions

La proliferación de aplicaciones de Generative AI (GenAI) en entornos empresariales presenta un desafío fundamental en la computación distribuida: cómo gestionar el acceso a la información sensible de manera granular y escalable en un contexto multi-inquilino o multi-departamento. Específicamente, en arquitecturas de Retrieval Augmented Generation (RAG), donde los Large Language Models (LLMs) acceden a bases de conocimiento propietarias, es crítico asegurar que los usuarios solo recuperen documentos a los que están autorizados. Este problema se agrava cuando las reglas de acceso son dinámicas y requieren actualizaciones frecuentes, lo que tradicionalmente implicaría ciclos de desarrollo y despliegue. La solución propuesta aborda esto externalizando la lógica de autorización a un sistema de políticas centralizado, desacoplando la decisión de acceso del código de la aplicación y permitiendo una gestión ágil y auditable.

Históricamente, la gestión de permisos ha evolucionado desde listas de control de acceso (ACLs) estáticas hasta modelos de Role-Based Access Control (RBAC) y, más recientemente, Attribute-Based Access Control (ABAC). Este patrón se alinea con ABAC al evaluar atributos del usuario (grupos de departamento) y del recurso (documentos con metadatos) en tiempo de ejecución. La necesidad de un control de acceso dinámico y de bajo costo para RAG surge de la complejidad operacional y económica de provisionar infraestructuras de RAG aisladas para cada grupo o departamento, un problema que se intensifica con el crecimiento de la adopción de GenAI en la empresa.

Arquitectura del Sistema

La arquitectura propuesta implementa un patrón de autorización de defensa en profundidad con dos capas independientes. La primera capa (Layer 1) es un Lambda Authorizer en Amazon API Gateway que valida el JSON Web Token (JWT) del usuario (emitido por Amazon Cognito) y consulta Amazon Verified Permissions para determinar si el usuario tiene permiso para invocar la API. Esta es una verificación de acceso a nivel de API.

La segunda capa (Layer 2) es una AWS Lambda function de middleware que, tras la autorización de la Layer 1, realiza una segunda consulta a Amazon Verified Permissions. Esta consulta determina a qué recursos de Amazon Bedrock Knowledge Bases (identificados por metadatos de departamento) el usuario está autorizado a acceder. Basándose en esta decisión, la Lambda construye un filtro de metadatos que se pasa a la API RetrieveAndGenerate de Amazon Bedrock. Este filtro asegura que Amazon Bedrock Knowledge Bases solo realice la búsqueda de similitud vectorial y la recuperación de documentos sobre un subconjunto autorizado de la base de conocimiento. La ingesta de documentos se realiza a través de un pipeline event-driven: los documentos subidos a Amazon S3 bajo prefijos de departamento (ej. docs/dept-a/) disparan eventos de Amazon EventBridge, que a través de Amazon SQS, invocan una Lambda que crea un archivo sidecar .metadata.json con el tag de departamento. Una Lambda programada periódicamente inicia el trabajo de ingestión en Amazon Bedrock Knowledge Bases, que indexa los documentos y sus metadatos. Amazon Verified Permissions utiliza Cedar, un lenguaje de políticas declarativo, para definir las reglas de autorización, que son evaluadas en tiempo real. Guardrails for Amazon Bedrock actúa como una capa de seguridad de salida, validando la respuesta del FM para asegurar que se mantenga fiel al contexto recuperado y filtre contenido inapropiado.

import os
import json
import jwt
import requests
from botocore.exceptions import ClientError
import boto3

# ... (JWKS caching, helper functions for JWT validation and Verified Permissions call)

def lambda_handler(event, context):
    token = event['authorizationToken'].split(' ')[1]
    try:
        # 1. Validate JWT signature and claims (e.g., cognito:groups)
        # 2. Extract user groups from JWT
        # 3. Call Verified Permissions IsAuthorized API
        #    principal = GenAIApp::UserGroup::"dept-a"
        #    action = GenAIApp::Action::"invokeApi"
        #    resource = GenAIApp::Resource::"GenAIRAGApp"
        # 4. If authorized, return IAM policy allowing access
        # 5. Else, raise exception for 403
        pass # Placeholder for actual implementation
    except Exception as e:
        print(f"Authorization failed: {e}")
        raise Exception('Unauthorized') # API Gateway returns 403

import os
import json
import boto3

# ... (helper functions for Verified Permissions call)

def lambda_handler(event, context):
    user_groups = event['requestContext']['authorizer']['claims']['cognito:groups'] # From Layer 1
    policy_store_id = os.environ['POLICY_STORE_ID']
    kb_id = os.environ['KB_ID']

    permitted_departments = []
    # 1. For each user_group, call Verified Permissions IsAuthorized
    #    action = GenAIApp::Action::"query"
    #    resource = GenAIApp::KnowledgeBase::"dept-X"
    # 2. Collect all 'dept-X' resources for which the user_group is permitted
    # 3. Construct metadata filter
    if not permitted_departments:
        raise PermissionError("No authorized departments found.")

    metadata_filter = {
        "or": [
            {"equals": {"key": "department", "value": dept}} 
            for dept in permitted_departments
        ]
    }

    # 4. Call Bedrock RetrieveAndGenerate with metadata_filter and guardrailConfiguration
    #    response = bedrock_runtime.retrieve_and_generate(
    #        input={'text': event['body']['query']},
    #        retrieveAndGenerateConfiguration={
    #            'type': 'KNOWLEDGE_BASE',
    #            'knowledgeBaseConfiguration': {
    #                'knowledgeBaseId': kb_id,
    #                'modelArn': '...', # Determined by Verified Permissions for invokeModel
    #                'retrievalConfiguration': {'vectorSearchConfiguration': {'filter': metadata_filter}}
    #            }
    #        },
    #        guardrailConfiguration={'guardrailId': '...', 'guardrailVersion': 'DRAFT'}
    #    )
    # 5. Return response
    pass # Placeholder for actual implementation

Fundamentos Teóricos

El concepto de externalización de la lógica de autorización, como se implementa con Amazon Verified Permissions y Cedar, tiene sus raíces en los sistemas de gestión de políticas y los motores de decisión de políticas (PDP - Policy Decision Point) que han sido objeto de estudio en la seguridad informática durante décadas. Este enfoque se alinea con el principio de separación de preocupaciones (Separation of Concerns), donde la lógica de negocio se desacopla de la lógica de seguridad. La formalización de políticas de acceso mediante lenguajes declarativos como Cedar se inspira en trabajos sobre lenguajes de políticas de seguridad como XACML (eXtensible Access Control Markup Language), que buscan proporcionar una forma estructurada y auditable de definir y aplicar reglas de acceso complejas.

La estrategia de "defensa en profundidad" (Defense in Depth) es un principio de seguridad bien establecido, popularizado por el NIST (National Institute of Standards and Technology) y otras organizaciones de seguridad, que aboga por múltiples capas de controles de seguridad independientes. Este patrón aplica este principio al tener capas de autorización a nivel de API y a nivel de documento, asegurando que un fallo o una configuración errónea en una capa no comprometa la seguridad general. La aplicación de filtros de metadatos antes de la búsqueda vectorial en RAG es una adaptación de las técnicas de pre-filtrado y post-filtrado en sistemas de recuperación de información, donde los criterios de acceso se aplican para reducir el espacio de búsqueda o para refinar los resultados antes de su presentación al usuario.