RBAC vs Aislamiento de Inquilinos: Dos Límites de Seguridad Diferentes
RBAC y el aislamiento de inquilinos resuelven dos problemas de seguridad diferentes en sistemas multiinquilino. El Control de Acceso Basado en Roles (RBAC) determina qué puede hacer un principal autenticado, como leer pedidos, editar productos o gestionar usuarios. El aislamiento de inquilinos determina a qué datos, recursos y contexto de ejecución de qué inquilino puede acceder ese principal. Un usuario puede estar correctamente autenticado y correctamente asignado a un rol RBAC y aun así experimentar una falla de seguridad si la aplicación permite que ese rol opere sobre los recursos de otro inquilino.
Qué controla realmente RBAC
RBAC es un modelo de autorización en el que los permisos se asocian con roles y los usuarios se asignan a esos roles. El rol actúa como una abstracción administrativa entre identidades y permisos.
El trabajo clásico de NIST sobre RBAC formaliza esto en torno a usuarios, roles, permisos, operaciones y objetos. El beneficio práctico es que una organización puede gestionar la autorización mediante roles relativamente estables de puesto o responsabilidad en lugar de adjuntar cada permiso directamente a cada usuario.
Un rol como EDITOR puede por lo tanto significar: puede leer contenido, escribir contenido y publicar contenido. Un rol como CONTADOR puede significar: puede leer datos de facturación, conciliar facturas y aprobar liquidaciones.
Qué controla realmente el aislamiento de inquilinos
El aislamiento de inquilinos es el conjunto de mecanismos que impide que un inquilino lea, modifique, influya o reciba accidentalmente los recursos de otro inquilino en un sistema compartido.
El límite protegido es más amplio que las filas de una base de datos. El estado específico de un inquilino puede existir en tablas relacionales, almacenamiento de objetos, índices vectoriales, cachés, índices de búsqueda, mensajes de cola, archivos, artefactos temporales, trabajos en segundo plano, analíticas, límites de velocidad y recursos de infraestructura.
La guía de AWS para SaaS hace explícita la distinción: la autorización otorga acceso a recursos, mientras que el aislamiento de inquilinos garantiza que esos recursos no crucen el límite de inquilino incorrecto incluso cuando la infraestructura es compartida.
El ejemplo más simple
Supongamos que Alice es administradora del Inquilino A y Bob es administrador del Inquilino B. Ambos usuarios tienen legítimamente el mismo rol ADMIN.
RBAC puede concluir correctamente que ambos usuarios pueden ejecutar una operación como users.read. Pero cuando Alice solicita el ID de usuario 847, la aplicación aún debe verificar que el usuario 847 pertenece al Inquilino A.
Si la API solo verifica “Alice tiene ADMIN” y luego ejecuta SELECT * FROM users WHERE id = 847, RBAC tuvo éxito mientras que el aislamiento de inquilinos falló.
Una decisión correcta de autorización multiinquilino
Dónde se detiene el ejemplo simple
Los sistemas reales a menudo contienen varias clases de identidad: usuarios de inquilinos, administradores de plataforma, trabajadores en segundo plano, integraciones, agentes y servicios operativos entre inquilinos. Algunos de estos cruzan legítimamente los límites de los inquilinos.
Eso no elimina la necesidad de aislamiento. Significa que la autoridad entre inquilinos debe ser explícita, estrecha y auditable por separado en lugar de surgir accidentalmente de un rol global o una conexión de base de datos sin alcance.
El aislamiento de inquilinos también puede variar según la capa. Un producto puede compartir servidores de aplicaciones mientras separa las bases de datos, o usar una base de datos compartida con políticas a nivel de fila mientras otorga a los inquilinos premium almacenamiento o cómputo aislado. No existe una única topología de aislamiento universal.
RBAC vs aislamiento de inquilinos
Dos dimensiones de seguridad diferentes
| RBAC | Aislamiento de inquilinos | |
|---|---|---|
| Pregunta principal | ||
| Unidad típica | ||
| Ejemplo | ||
| Fallo típico | ||
| Implementación típica | ||
| ¿Puede existir solo? |
Autenticación, autorización y aislamiento son tres verificaciones diferentes
| Capa | Pregunta | Fallo de ejemplo |
|---|---|---|
| Autenticación | ¿Quién es este principal? | El atacante se hace pasar por Alice |
| Autorización / RBAC | ¿Puede este principal realizar esta operación? | El visor puede eliminar usuarios |
| Aislamiento de inquilinos | ¿Puede esta operación alcanzar este límite de inquilino/recurso? | El administrador del inquilino A lee el pedido del inquilino B |
Estas verificaciones están relacionadas pero no son sustituibles. La autenticación puede ser perfecta mientras la autorización falla. La autorización puede ser correcta mientras el aislamiento de inquilinos falla. Una ruta de solicitud SaaS segura necesita todos los límites aplicables.
Los roles necesitan un alcance
La palabra ADMIN está incompleta sin alcance. Puede significar administrador de plataforma, administrador de inquilino, administrador de proyecto, administrador de espacio de trabajo o administrador de un subsistema.
En sistemas multiinquilino, la asignación de roles normalmente debe asociarse con la membresía del inquilino u otro alcance de recurso explícito. El mismo usuario puede ser legítimamente ADMIN en el inquilino A y VIEWER en el inquilino B.
Un modelo de rol global que ignora esta distinción puede crear fugas de privilegios incluso cuando el mapa de permisos en sí es correcto.
El contexto del inquilino debe provenir de una ruta confiable
Un ID de inquilino proporcionado por el cliente es útil como selector, pero no es prueba de autoridad. El servidor debe derivar o verificar la membresía del inquilino contra la identidad autenticada y los datos de autorización actuales.
La guía multiinquilino actual de OWASP recomienda establecer el contexto del inquilino temprano en el ciclo de vida de la solicitud y advierte explícitamente contra tratar los encabezados del cliente o los parámetros de solicitud como prueba de autorización.
Esto importa porque una modificación trivial de la solicitud de inquilino=A a inquilino=B no debe ser suficiente para cruzar el límite de aislamiento.
El alcance del inquilino pertenece a la búsqueda de recursos
Un patrón común de aislamiento a nivel de aplicación es incluir el alcance del inquilino en la misma consulta que resuelve el recurso.
| Búsqueda débil | Búsqueda con alcance de inquilino más fuerte |
|---|---|
| findFirst({ where: { id } }) | findFirst({ where: { id, tenantId } }) |
| UPDATE orders SET ... WHERE id = ? | UPDATE orders SET ... WHERE id = ? AND tenant_id = ? |
| cache.get('user:' + id) | cache.get('tenant:' + tenantId + ':user:' + id) |
Este patrón no es el único mecanismo de aislamiento posible, pero mantiene la propiedad del inquilino cerca de la operación de acceso a datos y evita que un ID de objeto se convierta en una capacidad entre inquilinos.
Las comprobaciones en la aplicación son útiles, pero el aislamiento no debería depender de un comportamiento perfecto del desarrollador
La guía de aislamiento de AWS advierte explícitamente contra dejar la aplicación del aislamiento solo en manos de los desarrolladores de servicios. En una base de código grande, eventualmente una consulta, clave de caché o ruta de trabajo puede omitir el alcance del inquilino.
La defensa en profundidad puede, por lo tanto, trasladar el aislamiento a middleware compartido, capas de repositorio/servicio, motores de políticas, seguridad a nivel de fila de la base de datos, credenciales dedicadas, esquemas separados o bases de datos separadas según el riesgo y la arquitectura.
Estrategias de aislamiento de bases de datos
| Estrategia | Límite | Fortaleza / compensación |
|---|---|---|
| Tablas compartidas + clave de inquilino | Política de fila/aplicación | Eficiente operativamente; requiere alcance de inquilino exhaustivo y pruebas sólidas |
| Tablas compartidas + RLS de base de datos | Límite de política de base de datos | Reduce la dependencia de cada consulta de la aplicación; requiere roles correctos, contexto de inquilino de sesión/transacción y cobertura de políticas |
| Esquemas separados | Límite de espacio de nombres / rol de BD | Separación lógica más fuerte; mayor complejidad operativa |
| Bases de datos separadas | Límite de base de datos / credenciales | Aislamiento fuerte y una historia de radio de impacto más simple; mayor costo de aprovisionamiento y operaciones |
| Infraestructura/cuenta separada | Límite de infraestructura | Separación de grano grueso más fuerte; mayor costo y sobrecarga operativa |
| Híbrido | Por carga de trabajo/clase de datos | Permite un aislamiento más fuerte solo donde el riesgo/cumplimiento lo justifica |
La hoja de referencia actual de seguridad multiinquilino de OWASP enumera bases de datos separadas, esquemas separados, tablas compartidas con controles a nivel de fila y modelos híbridos. El modelo correcto depende del nivel de amenaza, el cumplimiento, el rendimiento y el costo operativo.
La seguridad a nivel de fila de PostgreSQL puede proporcionar defensa en profundidad
Con tablas compartidas, la seguridad a nivel de fila de PostgreSQL puede aplicar un predicado de inquilino en la capa de base de datos para que las consultas ordinarias no puedan ver filas fuera de la política de inquilino activa.
Sin embargo, RLS no es mágico. Los superusuarios de PostgreSQL y los roles con BYPASSRLS pueden eludir las políticas de fila. Por lo tanto, OWASP recomienda usar un rol de ruta de solicitud con privilegios mínimos y probar el mismo modo de conexión/agrupación utilizado en producción.
La reutilización de conexiones es otro borde importante: el contexto del inquilino debe establecerse y restablecerse de forma segura para cada transacción/solicitud para que una conexión agrupada no pueda filtrar el estado previo del inquilino.
El aislamiento de inquilinos debe incluir cachés
Una consulta de base de datos puede tener un alcance perfecto y aún así filtrar datos a través de una clave de caché compartida.
Si user:42 existe tanto en el Inquilino A como en el Inquilino B, una clave de caché global puede devolver el valor del inquilino incorrecto. Las claves de caché sensibles al inquilino deben incluir cada atributo que cambie la visibilidad o la semántica del resultado, comúnmente inquilino, usuario, configuración regional, conjunto de características o versión de permisos.
La partición de caché es defensa en profundidad, no un reemplazo de la autorización. La solicitud aún debe autorizarse antes de que se devuelva el contenido protegido en caché.
Los archivos y el almacenamiento de objetos necesitan su propia frontera de inquilino
El almacenamiento de objetos debe distinguir entre objetos globales, con alcance de inquilino y con alcance de usuario. Un prefijo de carpeta por sí solo es únicamente una convención de nombres, a menos que la política de acceso realmente restrinja las lecturas y escrituras.
Los diseños más sólidos pueden usar claves de objeto con reconocimiento de inquilino, políticas de bucket, buckets/cuentas separados o claves de cifrado específicas del inquilino cuando el riesgo o el cumplimiento exijan un aislamiento más fuerte.
Las URL firmadas deben autorizarse antes de su emisión y limitarse al objeto y la operación exactos. La posesión de un identificador de objeto no debería por sí misma otorgar acceso entre inquilinos.
Los trabajos en segundo plano y las colas pueden romper el aislamiento
Los trabajos asíncronos a menudo abandonan el contexto de la solicitud HTTP original, lo que hace fácil manejar mal la propagación del inquilino. Un mensaje de cola que contiene tenantId no es prueba suficiente de que el productor estuviera autorizado.
El worker debe llevar una identidad de servicio/usuario verificada o un sobre de trabajo confiable, restablecer el contexto del inquilino y volver a autorizar las operaciones consecuentes en la frontera del consumidor.
El aislamiento de inquilinos también incluye la disponibilidad. Un inquilino no debería poder monopolizar workers, colas, pools de conexiones o cómputo compartidos de manera que degrade materialmente a otros inquilinos.
La búsqueda y RAG necesitan recuperación con reconocimiento de inquilino
La IA multiinquilino introduce otra copia del problema de aislamiento. Los documentos pueden dividirse en fragmentos, incrustarse y almacenarse en un índice vectorial después de la ingesta.
La guía actual de seguridad de RAG de OWASP establece que el control de acceso debe aplicarse en el momento de la recuperación y que los fragmentos del Inquilino A no deben ser recuperados por consultas del Inquilino B. No se puede simplemente asumir que los permisos a nivel de documento sobreviven automáticamente a la fragmentación.
Por lo tanto, el índice vectorial necesita metadatos de inquilino/acceso o colecciones física o lógicamente separadas según el diseño de aislamiento. Los filtros de recuperación deben aplicarse antes de que contenido no autorizado pueda entrar en el contexto del modelo.
Los datos derivados heredan la sensibilidad del inquilino
Las incrustaciones, los índices de búsqueda, las miniaturas, los resúmenes generados, las cachés, las filas de analítica y las respuestas de IA se derivan de los datos de origen. Su alcance de inquilino debe seguir a la fuente, a menos que una transformación explícita cree un artefacto compartido/global legítimo.
Por lo tanto, la eliminación y la baja deben propagarse más allá de la fila canónica. Eliminar un documento de inquilino mientras se dejan fragmentos buscables o resúmenes en caché puede mantener la exposición entre inquilinos o posterior a la retención.
No todo pertenece a un inquilino
Las plataformas multiinquilino a menudo tienen recursos intencionalmente globales: taxonomías de productos, plantillas públicas, permisos del sistema, definiciones de características o contenido público.
El modelo más seguro es la clasificación explícita: global, con alcance de inquilino, con alcance de usuario o explícitamente entre inquilinos. Los recursos ambiguos son donde comienza la fuga accidental.
Un objeto compartido intencionalmente debe tener una razón documentada para ser global en lugar de simplemente carecer de una asociación de inquilino.
Los administradores de plataforma requieren un modelo de autoridad diferente
Un operador de plataforma puede necesitar inspeccionar múltiples inquilinos para soporte, cumplimiento u operaciones de infraestructura. Modelar esto como un ADMIN de inquilino ordinario con acceso global accidental a la base de datos debilita tanto la seguridad como la auditabilidad.
Un mejor diseño utiliza una identidad de plataforma distinta o un permiso explícito entre inquilinos, autenticación más fuerte, limitación de propósito, auditoría detallada y, cuando corresponda, controles de aprobación o de acceso de emergencia.
Por lo tanto, el acceso entre inquilinos debe ser una capacidad nombrada, no la ausencia de un filtro de inquilino.
RBAC se puede combinar con atributos
Algunas decisiones dependen de más que el rol. La pertenencia al inquilino, la región, el propietario del recurso, el nivel de suscripción, el tiempo, la pertenencia al proyecto o la clasificación de datos pueden afectar el acceso.
RBAC y ABAC no son mutuamente excluyentes. La guía actual de autorización multiinquilino de AWS analiza modelos RBAC, ABAC e híbridos. Un rol puede definir una responsabilidad amplia mientras que los atributos restringen qué instancia de recurso concreta se puede acceder.
La regla clave de arquitectura sigue siendo: no codifique el aislamiento de inquilinos solo como un nombre de rol incidental si la identidad del inquilino es un límite de recurso de primera clase.
Las decisiones de autorización son al menos bidimensionales
| Principal | Permiso de rol | Relación de inquilino | Decisión |
|---|---|---|---|
| Alice | orders.read | El pedido pertenece al inquilino de Alice | Permitir |
| Alice | orders.read | El pedido pertenece a otro inquilino | Denegar |
| Alice | orders.write | El pedido pertenece al inquilino de Alice | Permitir si el rol incluye escritura |
| Alice | orders.write | El pedido pertenece a otro inquilino | Denegar |
| Soporte de plataforma | support.cross_tenant.read | Alcance de soporte explícito + inquilino objetivo auditado | Potencialmente permitir bajo política de plataforma |
| Trabajador en segundo plano | orders.process | Alcance de servicio confiable para el inquilino del trabajo | Permitir solo para el inquilino del trabajo verificado |
Evidencia de implementación original: Aaasaasa AI CMS
El servicio RBAC define códigos de permiso tipados como cms.content.read, shop.orders.write, billing.reconcile y users.roles. Los roles del sistema asignan esos permisos a conjuntos de responsabilidad nombrados.
Los registros de roles se crean y resuelven con un tenantId. Los roles del sistema se insertan o actualizan utilizando una identidad compuesta de inquilino/código, y el listado de roles se filtra por inquilino.
La actualización y eliminación de roles primero resuelven el rol utilizando tanto el ID del rol como el ID del inquilino. Las asignaciones de rol de usuario también se almacenan y reemplazan bajo el contexto del inquilino actual.
La resolución de permisos lee asignaciones explícitas de rol de usuario con alcance tanto de tenantId como de userId. Esto evita que la asignación de rol de un inquilino se convierta automáticamente en la asignación de rol de otro inquilino.
A nivel de API, las rutas administrativas de RBAC resuelven un contexto de inquilino antes de crear o modificar roles. Esta es la dirección correcta: la administración de permisos en sí misma debe respetar la multi-tenencia.
| Patrón de implementación observado | Significado de seguridad |
|---|---|
| Códigos de permiso tipados | El vocabulario de operaciones RBAC es explícito |
| Mapas de rol de sistema → permisos | Los roles agregan permisos en lugar de codificar usuarios de forma rígida |
| Identidad de rol tenantId_code | El mismo rol lógico puede existir por separado por inquilino |
| La búsqueda de roles usa id + tenantId | La mutación de roles está limitada al inquilino |
| La relación usuario-rol almacena tenantId | La pertenencia no se infiere globalmente solo del rol |
| La resolución de permisos usa tenantId + userId | La autorización se evalúa dentro del contexto del inquilino |
Por qué esta distinción importa aún más para los agentes de IA
Los agentes de IA pueden convertir un error de permisos en una secuencia de acciones. Si a un agente se le da una herramienta amplia orders.read sin aplicación con alcance de inquilino, una falla de razonamiento o de inyección de prompts puede causar lecturas entre inquilinos a velocidad de máquina.
Las descripciones de herramientas del agente pueden mencionar restricciones de inquilino, pero la aplicación aún debe ocurrir en la capa confiable de tiempo de ejecución/servicio/datos. Las instrucciones en lenguaje natural no son una frontera de autorización.
Lo mismo se aplica a RAG: un agente puede tener permiso para usar la herramienta de búsqueda mientras el backend de búsqueda aún debe evitar que la consulta del Inquilino A devuelva fragmentos del Inquilino B.
Probar RBAC y aislamiento de inquilinos por separado
| Familia de pruebas | Qué debería probar |
|---|---|
| Prueba de degradación de rol | Un usuario sin un permiso no puede realizar la operación incluso dentro de su propio inquilino |
| Prueba de objeto entre inquilinos | Un usuario con el rol correcto aún no puede acceder al mismo tipo de recurso en otro inquilino |
| Manipulación de identificadores | Cambiar los ID de objeto/inquilino no cruza el alcance |
| Prueba de endpoint de listado/masivo | Las consultas amplias devuelven solo datos de inquilinos autorizados |
| Prueba de reutilización de caché | Dos inquilinos que usan procesos/conexiones reutilizados nunca reciben el estado en caché del otro |
| Prueba de rol de solicitud RLS | El rol de solicitud de producción no puede eludir las políticas de fila |
| Prueba de trabajador asíncrono | El contexto del inquilino sobrevive al encolado y se revalida al consumirse |
| Prueba de recuperación vectorial | La consulta del Inquilino A nunca recupera fragmentos del Inquilino B |
| Prueba de administrador de plataforma | La capacidad entre inquilinos es explícita, limitada y auditable |
| Prueba de baja de servicio | Los datos del inquilino y los índices/cachés derivados se eliminan según la política |
La guía de regresión de autorización de OWASP señala específicamente las pruebas de frontera entre inquilinos porque los cambios de código en cachés, consultas o servicios compartidos pueden romper silenciosamente el aislamiento incluso cuando las pruebas de roles siguen pasando.
Modos de falla comunes
| Modo de falla | Por qué falla |
|---|---|
| Verificar el rol pero no el inquilino | Un rol válido se convierte en autoridad entre inquilinos |
| Confiar en el ID de inquilino de la solicitud | El cliente controla el selector de aislamiento |
| Delimitar la UI pero no la API | Los botones ocultos no protegen los recursos del backend |
| Endpoint de detalle con reconocimiento de inquilino, endpoint de listado sin alcance | Las lecturas masivas filtran otros inquilinos |
| Filtro de inquilino en la mayoría de las consultas | Una ruta olvidada rompe la frontera |
| Claves de caché globales | El aislamiento correcto de la base de datos se elude mediante datos en caché |
| Índice vectorial compartido sin filtros de metadatos aplicados | RAG recupera fragmentos de otro inquilino |
| ID de inquilino del mensaje de cola tratado como autorización | Un trabajo falsificado o producido incorrectamente puede cruzar la frontera de inquilino |
| Administrador de plataforma modelado como ADMIN ordinario | El poder entre inquilinos se vuelve implícito y difícil de auditar |
| Rol copiado globalmente entre pertenencias de inquilinos | El usuario recibe permisos en inquilinos donde nunca fue asignado |
| Bases de datos separadas pero credencial privilegiada compartida | La aplicación aún puede cruzar bases de datos si su credencial es demasiado amplia |
| RLS con rol de solicitud BYPASSRLS | La política de base de datos existe pero no protege la ruta de solicitud real |
| UUID aleatorios tratados como aislamiento | Los identificadores difíciles de adivinar reducen la enumeración pero no autorizan el acceso |
Conceptos erróneos comunes
| Concepto erróneo | Corrección |
|---|---|
| “RBAC proporciona aislamiento de inquilinos.” | RBAC controla permisos; el aislamiento también requiere alcance de inquilino/recurso. |
| “Si el usuario es administrador, las verificaciones de inquilino son innecesarias.” | La autoridad de administrador aún debe tener un alcance explícito. |
| “El ID de inquilino en el JWT es suficiente.” | Puede ser una entrada confiable solo si se valida y se aplica de manera consistente a cada ruta de recurso protegida. |
| “Bases de datos separadas eliminan los requisitos de autorización.” | Los usuarios aún necesitan permisos a nivel de operación dentro de su inquilino. |
| “Una columna tenant_id significa que el sistema está aislado.” | El campo solo ayuda si las rutas de acceso lo aplican. |
| “Los UUID previenen el acceso entre inquilinos.” | Los identificadores impredecibles son defensa en profundidad, no autorización. |
| “RLS significa que el código de la aplicación no necesita verificaciones de seguridad.” | La autorización de la aplicación, los roles de base de datos correctos y la cobertura de políticas aún importan. |
| “Una base de datos vectorial compartida es insegura.” | Puede ser segura si el aislamiento es aplicable y verificado; la separación física es una opción, no la única. |
| “El soporte de plataforma necesita ADMIN global.” | El soporte entre inquilinos debe ser una autoridad distinta, restringida y auditable. |
| “Los servicios internos pueden omitir las verificaciones de inquilino.” | Las rutas internas aún pueden verse comprometidas o mal configuradas y deben preservar el contexto del inquilino. |
Una secuencia de diseño práctica
Diseñar permisos y aislamiento como dimensiones separadas
Lista de verificación de RBAC + aislamiento de inquilinos
| Pregunta | Respuesta esperada |
|---|---|
| ¿Quién es el principal? | Identidad de usuario/servicio/agente autenticada |
| ¿Qué contexto de inquilino aplica? | Pertenencia verificada por el servidor o alcance del servicio |
| ¿Qué operación se solicita? | Permiso tipado o acción de política |
| ¿El principal tiene ese permiso? | Decisión de rol/política |
| ¿Quién es propietario del recurso objetivo? | Clasificación explícita de inquilino/global/usuario |
| ¿El alcance del recurso coincide con la autoridad? | Búsqueda/política con reconocimiento de inquilino |
| ¿El almacenamiento puede eludir las verificaciones de la aplicación? | Decisión de defensa en profundidad documentada |
| ¿Las cachés son seguras para inquilinos? | Las claves/espacios de nombres y la autorización preservan el alcance del inquilino |
| ¿Los archivos/blobs son seguros para inquilinos? | La política de objetos y la emisión de URL firmadas aplican el alcance |
| ¿Los trabajos asíncronos son seguros para inquilinos? | El contexto verificado se propaga y se revalida |
| ¿RAG/búsqueda es seguro para inquilinos? | Aislamiento de metadatos/colecciones aplicado antes del contexto del modelo |
| ¿Los administradores entre inquilinos son explícitos? | Autoridad, controles y auditoría separados |
| ¿Las credenciales ordinarias pueden eludir el aislamiento? | No, o una ruta excepcional estrictamente documentada |
| ¿Las pruebas negativas entre inquilinos están automatizadas? | Sí para cada capa de acceso relevante |
Casos límite y limitaciones
Un usuario puede pertenecer a múltiples inquilinos. Por lo tanto, el inquilino actual debe ser un contexto de ejecución explícito, no inferido permanentemente de la cuenta de usuario.
Algunos recursos se comparten intencionalmente entre inquilinos seleccionados, como espacios de colaboración o datos de consorcio. Esto requiere un modelo de compartición explícito; pretender que el recurso pertenece a un inquilino y añadir excepciones después suele crear autorización ambigua.
El aislamiento de vecinos ruidosos está relacionado pero es diferente del aislamiento de confidencialidad. Un inquilino puede nunca ver los datos de otro inquilino y aun así agotar la CPU compartida, la capacidad de cola o las conexiones de base de datos. Por lo tanto, los límites de velocidad y las cuotas de recursos pueden ser conscientes del inquilino como un límite de disponibilidad.
El aislamiento físico no es automáticamente seguro si las credenciales del plano de control o las rutas administrativas pueden cruzar límites. El aislamiento lógico no es automáticamente débil si las políticas se aplican centralmente, con privilegios mínimos y se prueban exhaustivamente.
Los requisitos de aislamiento de inquilinos pueden diferir según la clase de datos. Los datos de catálogo público, los registros de facturación y los documentos privados de IA pueden justificar diferentes límites de almacenamiento y cifrado dentro del mismo producto SaaS.
¿Qué cambiaría esta respuesta?
La implementación exacta cambia con la arquitectura: las API sin servidor, Kubernetes, PostgreSQL, el almacenamiento de objetos, las bases de datos vectoriales y los motores de políticas exponen diferentes primitivas de aislamiento.
La fuerza requerida también cambia con la regulación, los contratos de clientes, la sensibilidad de los datos, el modelo de amenaza y la escala operativa. Algunos inquilinos pueden justificar bases de datos o infraestructura en silos, mientras que otros comparten recursos agrupados.
La distinción conceptual no cambia: el permiso para realizar una operación no es lo mismo que el permiso para cruzar un límite de inquilino.
Conocimiento canónico relacionado
S01 es un requisito previo de límite de seguridad para la Arquitectura de IA Empresarial y la Gobernanza de IA. Una vez que las herramientas de IA, RAG o los agentes operan sobre datos multiinquilino, la identidad del inquilino debe viajar a través de la recuperación, la ejecución de herramientas, la memoria, las cachés y los rastros de auditoría.
También se conecta directamente con la IA Agéntica: la capacidad de la herramienta y el permiso de rol aún deben estar restringidos por la propiedad del inquilino antes de que un agente pueda leer o modificar recursos empresariales.
Para RAG, el aislamiento de inquilinos debe aplicarse antes de que los fragmentos protegidos lleguen al contexto del modelo.
Preguntas frecuentes
Preguntas frecuentes sobre RBAC vs aislamiento de inquilinos
¿Cuál es la diferencia entre RBAC y el aislamiento de inquilinos?
¿Un rol ADMIN permite automáticamente el acceso a todos los inquilinos?
¿Es suficiente la autenticación para el aislamiento de inquilinos?
¿Debería almacenarse tenantId en el JWT?
¿Necesito una base de datos separada por inquilino?
¿Puede PostgreSQL RLS reemplazar los filtros de inquilino en el código de la aplicación?
¿Cómo debería RAG aplicar el aislamiento de inquilinos?
¿Puede un usuario tener diferentes roles en diferentes inquilinos?
¿Cuál es la mejor prueba para el aislamiento de inquilinos?
Glosario
Términos clave de seguridad multiinquilino
- RBAC
- Control de acceso basado en roles: un modelo de autorización que asocia permisos con roles y asigna usuarios o principales a esos roles.
- Inquilino
- Un cliente, organización, espacio de trabajo u otro consumidor lógico aislado de un sistema multiinquilino compartido.
- Aislamiento de inquilinos
- Mecanismos que impiden que un inquilino acceda, modifique o reciba los recursos de otro inquilino en un sistema compartido.
- Autenticación
- Verificación de la identidad de un usuario, servicio u otro principal.
- Permiso
- Una operación o capacidad permitida definida, como orders.read o users.write.
- Rol
- Una agrupación nombrada de permisos asociada con una responsabilidad o función.
- ABAC
- Control de acceso basado en atributos: autorización basada en atributos del principal, recurso, acción o entorno.
- Seguridad a nivel de fila
- Mecanismo de política de base de datos que restringe qué filas puede leer o modificar un rol o sesión de base de datos.
- Acceso entre inquilinos
- Cualquier ruta de acceso en la que un principal que opera bajo el contexto de un inquilino alcanza recursos pertenecientes a otro inquilino.
- Administrador de plataforma
- Una identidad operativa privilegiada con autoridad modelada explícitamente que puede abarcar múltiples inquilinos.
- Contexto de inquilino
- El ámbito de inquilino verificado bajo el cual se ejecuta la solicitud, trabajo o operación de agente actual.
Conclusión
RBAC y el aislamiento de inquilinos son mecanismos de seguridad complementarios, no competidores. RBAC estructura el permiso operativo; el aislamiento de inquilinos restringe el límite de recursos dentro del cual ese permiso puede aplicarse.
Por lo tanto, una solicitud multiinquilino robusta necesita más que “el usuario tiene el rol ADMIN”. Necesita un principal verificado, un contexto de inquilino verificado, una operación permitida, un objetivo con alcance de inquilino y aplicación en cada capa de recursos que pueda contener datos propiedad del inquilino.
La regla confiable más corta es: autoriza la acción, luego aísla el alcance — y nunca asumas que uno prueba el otro.
Fuentes primarias y orientación actual
Las fuentes a continuación respaldan la definición de RBAC y la orientación actual sobre aislamiento de inquilinos. La sección de Aaasaasa AI CMS es evidencia de implementación original y está intencionalmente limitada a los patrones de código que fueron verificados.
NIST — Control de acceso basado en rolesDescripción general de NIST de los modelos RBAC y el estándar INCITS RBAC, incluidos usuarios, roles, permisos, operaciones y objetos.
NIST CSRC — Glosario RBACDefiniciones actuales del glosario de NIST sobre control de acceso basado en roles como asignación de permisos a través de roles.
AWS — La mentalidad de aislamientoOrientación de AWS SaaS que distingue explícitamente la autenticación/autorización del aislamiento de inquilinos y recomienda mecanismos de aislamiento compartidos.
AWS — Preguntas frecuentes sobre autorización multiinquilinoOrientación actual que explica la diferencia entre autorización y aislamiento de inquilinos en aplicaciones SaaS.
AWS — Consideraciones de diseño multiinquilinoOrientación actual de SaaS que distingue el aislamiento de inquilinos de la autorización y analiza modelos de políticas de autorización agrupados/aislados.
OWASP — Hoja de referencia de seguridad de aplicaciones multiinquilinoOrientación práctica actual para el contexto de inquilino, aislamiento de base de datos, cachés, almacenamiento, colas, pruebas y prevención de acceso entre inquilinos.
OWASP — Hoja de referencia de seguridad de RAGOrientación actual que exige control de acceso en el momento de la recuperación y aislamiento de inquilinos para almacenes vectoriales multiinquilino.
OWASP — Pruebas de regresión de autorizaciónOrientación actual de pruebas que incluye pruebas de degradación de roles y límites entre inquilinos.
Related Articles
Bases de datos vectoriales, embeddings y reranking: tres partes diferentes de la recuperación
Las incrustaciones representan el significado, las bases de datos vectoriales recuperan candidatos y los rerankers refinan los resultados. Aprende en qué se diferencian y cómo trabajan juntas estas tres capas de recuperación en RAG.
Cómo saber si un agente de IA realmente utilizó la evidencia correcta
Un agente de IA puede citar fuentes y aun así usar la evidencia incorrecta. Este artículo presenta un método práctico para verificar el respaldo de las afirmaciones, la autoridad de la fuente, la aplicabilidad, la procedencia y si la evidencia realmente influyó en la respuesta.
¿Qué debería recordar, olvidar, recalcular o volver a recuperar un agente de IA?
Los agentes de larga duración no deberían recordarlo todo. Este artículo proporciona un modelo práctico de ciclo de vida para decidir qué pertenece a la memoria duradera, qué se debería recuperar de nuevo, qué es más seguro recalcular y qué debería expirar o ser sustituido.
MCP vs A2A vs UCP vs AP2 vs A2UI: La pila de protocolos de agentes explicada
MCP, A2A, UCP, AP2 y A2UI a menudo se presentan como estándares de agentes competidores. En su mayoría, resuelven diferentes problemas de interoperabilidad. Esta guía mapea cada protocolo con el límite que realmente estandariza—y muestra cómo pueden funcionar juntos en un sistema de producción.
IA agéntica explicada: cuando un sistema de IA puede planificar, usar herramientas y actuar
La IA agéntica utiliza modelos dentro de bucles de ejecución de varios pasos, donde pueden elegir herramientas, observar resultados, actualizar el estado y adaptar su siguiente acción dentro de límites explícitos de tiempo de ejecución y permisos.
IA soberana: control de modelos, datos, infraestructura y dependencias
La IA soberana se trata del control efectivo sobre los modelos, los datos, la infraestructura, el software, las operaciones y las dependencias estratégicas, no simplemente de dónde está alojado un modelo de IA.
IA con aislamiento de red: cómo funcionan los sistemas de IA sin acceso a Internet ni a la nube
La IA con aislamiento de red ejecuta modelos, RAG y aplicaciones de IA dentro de un dominio de seguridad aislado sin dependencias de internet ni de la nube. Descubra cómo funcionan los modelos, los datos, las actualizaciones y las herramientas sin conexión.
¿Cuándo debería una IA dejar de confiar en su propio conocimiento? — El desencadenante de la recuperación
Un modelo de IA no necesita recuperación para cada pregunta. El problema importante es saber cuándo su conocimiento interno ya no es suficiente. El Disparador de Recuperación es un límite de decisión práctico que determina cuándo un sistema de IA debe dejar de depender únicamente del conocimiento del modelo y obtener evidencia externa antes de responder.
¿Qué es la ingeniería de contexto? Lo que el modelo recibe antes de responder
La ingeniería de contexto diseña qué información recibe un modelo de IA antes de la inferencia, incluidos los prompts, la recuperación, la memoria, el estado de la aplicación, los resultados de las herramientas y el historial de conversación.
Por qué más contexto puede empeorar las respuestas de la IA
Una ventana de contexto más grande no garantiza una mejor respuesta. Este artículo explica cómo la dilución de la señal, la evidencia contradictoria, el estado obsoleto, la sensibilidad a la posición y la compresión con pérdidas pueden reducir la fiabilidad de la IA—e introduce una práctica Prueba de Presión de Contexto.
La GPU no es el producto: arquitectura de IA privada a prueba de futuro
La infraestructura de IA privada no debe diseñarse en torno a una sola GPU o un solo modelo. Un enfoque más resiliente combina GPUs de inferencia rápida, sistemas de IA ricos en memoria, nodos de IA física y modelos en la nube frontier opcionales detrás de una capa de enrutamiento consciente de las capacidades.
La memoria del agente de IA no es RAG: cómo separar memoria, recuperación, estado y contexto
La memoria del agente, RAG, el estado y el contexto a menudo se usan como si fueran intercambiables. No lo son. Este modelo práctico de arquitectura separa las cuatro capas, muestra dónde pertenece cada una y explica qué se rompe cuando los sistemas las colapsan en una sola.