SaaS企業が認可へのアプローチをどのように変えているか

認証は、ほとんどのアプリケーションの重要な、しかし見えない部分です。認証は、誰がどのデータにアクセスできるかを定義します。玄関に入る人は、許可については、誰がどの部屋の鍵を持っているのか。

歴史的に、開発チームはアプリケーションコードに権限論理を構築しましたが、権限論理の構築と維持は心を揺さぶる作業となり、時間の経過とともに、間違った人に機密情報へのアクセスを与える恐れからコードに触れたい人はいません。

最近、ソフトウェア開発のこの重要な要素に対処するために、新しい開発ツールが生まれました. Twilio が SMS や Stripe で支払うように、Oso のようなベンダーは解決することを目指しています。許可開発者がコアアプリに集中できるようになります。

Types of Authorization

いくつかの一般的な認証パターンがあります。通常、組織は、ロールベースの認可(or RBAC), where users have defined roles that determine the data they can access. Using Google Docs as an example, a given document might have a set of編集者で、コメントあるいは視聴者.

単純に聞こえますよね? Google Docs の例を拡張してみましょう. ユーザーがドキュメントの完全なフォルダを作成しているとします。視聴者フォルダにアクセスすれば、あなたは視聴者現在、リレーションベースのアクセス制御(またはReBAC)を実装する必要があるため、役割を必要とするだけでなく、リソース間の関係に基づいて権限を組織することも必要です。

次に、パブリック ドキュメントとプライベート ドキュメントの定義、時間制限されたアクセスを含む追加の要件を導入する場合があります(このユーザーはビジネスの終了までドキュメントへのエディターアクセスを有することがあります)、または条件付きのアクセスを含む (機密性の高い HR ドキュメントにアクセスすることはできませんが、あなたの役割がそれを許可する場合でも)。

Securing LLM Chatbots

これらの伝統的な許可パターンに加えて、爆発的なLLMチャットボットデータと相互作用するための新しい方法と新たな課題を導入します。LLMの柔軟性と規模により、機密データを漏らさないようにするのが難しくなります。正確であるためには、これらのモデルは大規模なデータのトレーニングを必要とします。しかし、答えを返すときには、最終ユーザーのみが彼らが見るべきデータしか見ないことが不可欠です。例えば、社員が内部チャットボットに「過去6ヶ月間の幹部会議の結果を概要してください」と尋ねることを想像してください。

下記は、許可された RAG チャット ボットのデータ フローの例で、エンド ユーザに返信する前に許可チェックを組み込むものです。

Who is using authorization as a service?

新規販売者オファーサービスとしての許可役割ベースのアクセス制御(RBAC)、関係ベースのアクセス制御(ReBAC)、属性ベースのアクセス制御(ABAC)など、LLMチャットボットを保護するための新規の使用例を提供できるようにします。