Cómo las empresas de SaaS están cambiando su enfoque a la autorización

La autorización es una parte crítica, pero invisible, de la mayoría de las aplicaciones. La autorización define quién tiene acceso a qué datos.Quien puede entrar por la puerta delantera,La autorización se trata de¿Quién tiene las llaves de las habitaciones?

Históricamente, los equipos de desarrollo construyeron la lógica de la autorización en su código de aplicación. Pero la construcción y el mantenimiento de la lógica de la autorización se ha convertido en un trabajo agotador, y con el tiempo, nadie quiere tocar el código por temor a dar acceso a información sensible a la persona equivocada.

Recientemente ha surgido una nueva gama de herramientas de desarrollador para abordar este componente crítico del desarrollo de software. Como Twilio ha hecho para SMS o Stripe para pagos, vendedores como Oso tienen como objetivo resolverAutorizaciónpara que los desarrolladores puedan centrarse en su aplicación principal.

Types of Authorization

Hay varios patrones comunes de autorización. por lo general, las organizaciones comienzan conAutorización basada en roles(o RBAC), donde los usuarios tienen roles definidos que determinan los datos a los que pueden acceder.Editorial, deComentario, oespectador.

Parece simple, ¿verdad? Vamos a extender el ejemplo de Google Docs. Digamos que un usuario crea una carpeta entera de documentos.espectadorAcceso a la carpeta, debe tenerespectadorAhora necesitamos implementar el control de acceso basado en la relación (o ReBAC), lo que significa que no solo necesita roles, sino que también necesita organizar permisos basados en la relación entre los recursos.

Puede que desee introducir requisitos adicionales, como definir documentos públicos vs. privados, acceso temporal (esta persona puede tener acceso de editor al documento hasta el cierre del negocio), o acceso condicional (no se puede acceder a documentos de recursos humanos sensibles, incluso si su papel lo permitiría de otra manera).

Securing LLM Chatbots

Además de estos patrones tradicionales de autorización, la explosión deLLM Chatbotsintroduce nuevas formas de interactuar con los datos, así como nuevos desafíos. La flexibilidad y la escala de los LLM hacen que sea más difícil asegurarse de que no se lechen datos sensibles. Para ser exactos, estos modelos necesitan entrenar en un gran corpus de datos. Cuando se devuelven las respuestas, sin embargo, es imperativo que solo los usuarios finales vean los datos que se supone que deben ver. Por ejemplo, imagine a un empleado preguntando a un chatbot interno: "Por favor, resume los resultados de la reunión del personal ejecutivo durante los últimos 6 meses".

A continuación se muestra un ejemplo del flujo de datos para un chatbot RAG autorizado, que incorpora verificaciones de permisos antes de devolver una respuesta al usuario final:

Who is using authorization as a service?

Nuevas ofertas de vendedoresAutorización como serviciopermitir a las empresas entregar controles de acceso de grano fino, como el control de acceso basado en roles (RBAC), el control de acceso basado en relaciones (ReBAC) y el control de acceso basado en atributos (ABAC), así como casos de uso emergentes para proteger los chatbots de LLM.