El agente de autenticación de un proveedor de servicios puede funcionar para muchos clientes, pero cada operación debe tener un contexto de cliente verificado. Un nombre de cliente en un mensaje no es una decisión de control de acceso. Vincule la sesión y el trabajo al inquilino identificado por la aplicación confiable y luego lleve esa identidad a través de la recuperación, propuesta, aprobación, ejecución y almacenamiento de evidencia.
Establecer el límite del cliente
Durante la incorporación, obtenga el inventario de dominio aprobado y la autoridad del administrador del cliente para el servicio solicitado. Registre identificadores de inquilinos que sean estables y únicos, en lugar de depender de nombres para mostrar similares. Verifique que las zonas DNS y los destinos de los informes pertenezcan al alcance previsto antes de otorgar acceso.
Utilice credenciales específicas del cliente o un mecanismo de autorización posterior igualmente ejecutable. Una identidad de servicio central con amplio acceso necesita controles sólidos en cada búsqueda de recursos. OWASP describe el riesgo de que identidades privilegiadas genéricas accedan a recursos más allá del contexto del usuario relevante. OWASPLLM06.
Mantenga la evidencia separada
Aplique el alcance del inquilino al almacenamiento de informes, índices de búsqueda, cachés, contexto de conversación y archivos exportados. Restrinja la recuperación antes de que la evidencia llegue al modelo. Filtrar el material de otro cliente de la respuesta final es demasiado tarde si ya entró en el contexto de trabajo. Los registros también necesitan controles de acceso; un panel de depuración compartido puede anular una separación que de otro modo sería cuidadosa.
Una IP o un nombre de proveedor compartido por dos clientes no constituye un permiso para unir su evidencia privada. Registre los datos de la infraestructura pública por separado de la propiedad de la cuenta, la actividad del servicio y los contactos específicos del cliente. Un sufijo de dominio similar o un revendedor común no convierte a dos inquilinos en un límite de autorización.
Seguimiento de un trabajo en cola a través de una concesión revocada
Supongamos que se crea un trabajo con la concesión válida del cliente A, luego el administrador de acceso revoca esa concesión antes de la ejecución. El ejecutor debe volver a verificar la autoridad actual en lugar de confiar en la sesión anterior. Si un caché también contiene el registro del cliente B con el mismo nombre corto, la búsqueda debe permanecer en el ámbito A; la infraestructura compartida y nombres similares no pueden justificar la recuperación de la evidencia privada de B.
Estos son casos límite hipotéticos, no un conector probado ni un runbook suministrado. Asigne responsabilidades distintas para la aprobación del alcance, cambios operativos, revisión de acceso independiente y baja. Defina condiciones de aceptación mensurables para la implementación real, incluida una solicitud A permitida y una solicitud B denegada, trabajos en cola revocados y recuperación de caché con el alcance adecuado. No reclame exposición cero entre inquilinos hasta que se hayan probado las rutas relevantes.
Consulta trabajos y sesiones.
Vincular la aprobación al inquilino y verificar la misma identidad en el momento de la ejecución. No permita que el modelo elija qué credencial usar de un nombre de cliente de texto libre. Vuelva a verificar la autorización cuando se ejecute un trabajo en cola; Es posible que una subvención haya sido revocada después de que se creó el trabajo. Las relaciones con clientes vencidas o transferidas necesitan un manejo explícito en lugar de un acceso heredado.
Pruebe con nombres de clientes deliberadamente similares, IP de proveedores superpuestas, nombres de registros reutilizados y una respuesta almacenada en caché de un inquilino diferente. Incluya una lectura de cliente permitida para que la prueba demuestre un acceso con alcance, no un conector deshabilitado globalmente. Los ejemplos hipotéticos anteriores no ejecutan ninguna de estas pruebas de implementación. Conserve el contexto real de la solicitud, las decisiones de autorización y los efectos observados al evaluarlos.
Cerrar la relación limpiamente
La baja debe detener nuevos trabajos, revocar el acceso, gestionar los trabajos en cola y aplicar el proceso de retención de pruebas acordado. Confirmar cada acción a través del sistema responsable. Conservar el historial de auditoría mínimo necesario para explicar el trabajo previo según el acuerdo aplicable. No borre la evidencia automáticamente ni mantenga el acceso indefinido simplemente porque el agente pueda necesitar responder una pregunta posterior.