Cum își schimbă companiile SaaS abordarea autorităților

Autorizarea este o parte critică, dar invizibilă, a majorității aplicațiilor. Autorizarea definește cine are acces la ce date. Folosind o analogie de securitate fizică, dacă autentificarea este despreCine poate intra pe uşa din faţă,Autorizarea se referă laCine are cheile la ce camere?

Istoric, echipele de dezvoltare au construit logica de autorizare în codul aplicației lor. Dar construirea și menținerea logicii de autorizare a devenit o muncă agitată și, în timp, nimeni nu vrea să atingă codul din teama de a da persoanei greșite acces la informații sensibile. Această problemă este amplificată de explozia chatbot-urilor LLM, care trebuie să se antreneze folosind o mulțime de date, dintre care nu toate ar trebui expuse utilizatorului final.

Recent, a apărut o nouă gamă de instrumente pentru dezvoltatori pentru a aborda această componentă critică a dezvoltării software-ului. Ca Twilio a făcut pentru SMS sau Stripe pentru plăți, furnizorii precum Oso au ca scop rezolvarea problemelor.autorizaţieAstfel, dezvoltatorii se pot concentra pe aplicația lor de bază.

Types of Authorization

Există mai multe modele comune de autorizare. De obicei, organizaţiile încep cuAutorizare bazată pe roluri(sau RBAC), unde utilizatorii au definite roluri care determină datele la care pot accesa. Folosind Google Docs ca exemplu, un document dat ar putea avea oeditorului,ComentariisauVizualizare.

Să extindem exemplul Google Docs. Să presupunem că un utilizator creează un întreg folder de documente.VizualizarePentru a accesa fișierul, trebuie săVizualizareAcum trebuie să implementăm controlul accesului bazat pe relație (sau ReBAC), ceea ce înseamnă că nu numai că aveți nevoie de roluri, ci trebuie să organizați permisiunile pe baza relației dintre resurse.

Apoi, este posibil să doriți să introduceți cerințe suplimentare, cum ar fi definirea documentelor publice vs. private, accesul limitat la timp (această persoană poate avea acces la document până la închiderea activității) sau accesul condiționat (documentele HR sensibile nu pot fi accesate, chiar dacă rolul dvs. ar permite altfel).

Securing LLM Chatbots

În plus față de aceste modele tradiționale de autorizare, exploziaLLM chatbotsintroduce noi modalități de a interacționa cu datele – precum și noi provocări. Flexibilitatea și amploarea LLM-urilor fac mai dificilă asigurarea faptului că nu scurg date sensibile. Pentru a fi precise, aceste modele trebuie să se antreneze pe un corpus mare de date. Atunci când returnează răspunsuri, totuși, este imperativ ca numai utilizatorii finali să vadă numai datele pe care ar trebui să le vadă. De exemplu, imaginați-vă un angajat care cere unui chatbot intern: „Vă rugăm să rezumați rezultatele întâlnirii cu personalul executiv din ultimele 6 luni.”

Mai jos este un exemplu de flux de date pentru un chatbot RAG autorizat, care încorporează verificări de permisiune înainte de a returna un răspuns utilizatorului final:

Who is using authorization as a service?

Ofertă de vânzări noiAutorizarea ca serviciupermite companiilor să furnizeze controale de acces fine, cum ar fi controlul accesului bazat pe roluri (RBAC), controlul accesului bazat pe relații (ReBAC) și controlul accesului bazat pe atribute (ABAC), precum și cazuri de utilizare emergente pentru a asigura chatbots LLM. Un număr tot mai mare de organizații utilizează acum autorizarea ca serviciu pentru a-și asigura aplicațiile.