Як SaaS-компанії змінюють свій підхід до авторизації

Авторизація є критичною, але невидимою частиною більшості додатків. Авторизація визначає, хто має доступ до яких даних.Хто може увійти в двері,Дозвіл стосуєтьсяХто має ключі до яких кімнат?

Історично, команди розробників побудували логіку авторизації у свій код додатків. Але побудова і підтримка логіки авторизації стала м'язовою роботою, і з часом ніхто не хоче торкатися коду з побоюванням дати неправильній людині доступ до конфіденційної інформації.

Останнім часом з'явився новий набір інструментів для розробників, щоб вирішити цей критичний компонент розробки програмного забезпечення. Як Twilio зробив для SMS або Stripe для платежів, постачальники, такі як Oso, прагнуть вирішитидозвілТаким чином, розробники можуть зосередитися на своїй основній програмі.

Types of Authorization

Існує кілька загальних шаблонів авторизації. Як правило, організації починають зРольова авторизація(або RBAC), де користувачі мають визначені ролі, які визначають дані, до яких вони можуть отримати доступ.Редактор,Коментарабоглядач.

Звучить просто, чи не так? Давайте розширимо приклад Google Docs. Припустимо, що користувач створює цілу папку документів.глядачдоступу до папки, ви повинні матиглядачТепер нам потрібно впровадити контроль доступу на основі відносин (або ReBAC), що означає, що вам не тільки потрібні ролі, але і потрібно організувати дозволи на основі відносин між ресурсами.

Тоді ви можете запропонувати додаткові вимоги, такі як визначення публічних проти приватних документів, тимчасовий доступ (ця особа може мати редакторський доступ до документа до закриття бізнесу) або умовний доступ (чутливі документи HR не можуть бути доступні, навіть якщо ваша роль дозволить це інакше).

Securing LLM Chatbots

На додаток до цих традиційних моделей дозволу, вибухLLM чатботизапроваджує нові способи взаємодії з даними, а також нові виклики. Гнучкість та масштабність LLM ускладнюють забезпечення того, щоб ви не витікали конфіденційні дані. Щоб бути точними, ці моделі повинні навчатися на великій кількості даних. При поверненні відповідей, однак, необхідно, щоб тільки кінцеві користувачі бачили тільки ті дані, які вони повинні бачити. Наприклад, уявіть співробітника, який запитує внутрішнього чатбота: "Прошу підсумувати результати зустрічі виконавчого персоналу за останні 6 місяців".

Нижче наведено приклад потоку даних для авторизованого чат-бота RAG, який включає перевірки дозволів перед поверненням відповіді кінцевому користувачеві:

Who is using authorization as a service?

Нові пропозиції продавцівАвторизація як послугадозволяти компаніям надавати дрібні контролю доступу, такі як контроль доступу на основі ролей (RBAC), контроль доступу на основі відносин (ReBAC) і контроль доступу на основі атрибутів (ABAC), а також нові випадки використання для забезпечення чат-ботів LLM. Все більше організацій тепер використовують авторизацію як послугу для забезпечення своїх додатків.