تفاوت بین فیلترها و دیوارها
شما در حال ساخت یک عامل هوش مصنوعی (AI agent) با دسترسی به دادههای خود هستید. برای امنیت، دو انتخاب دارید: میتوانید دادهها را فیلتر کنید یا برای آنها دیوار بکشید.
فیلتر کردن یعنی پرسوجوی (query) شما فقط ردیفهای خاصی را برمیگرداند. دیوار کشیدن یعنی عامل هوش مصنوعی اصلاً نمیتواند به ردیفهای پنهان دسترسی پیدا کند.
این دو تا زمانی که مشکلی پیش نمیآید، یکسان به نظر میرسند.
من اخیراً سیستمی ساختم تا ۱.۲ میلیون کلمه را به یک پایگاه دانش تبدیل کنم. برای مدیریت دادهها از Supabase استفاده کردم. میخواستم عاملهای هوش مصنوعی من فقط محتوای عمومی را ببینند.
من از یک Postgres view استاندارد برای فیلتر کردن دادهها استفاده کردم:
CREATE VIEW public_seeds AS
SELECT * FROM moments
WHERE visibility = 'public'
AND is_canonical = true;
این درست به نظر میرسد، اما یک نقص بزرگ دارد. بهصورت پیشفرض، یک Postgres view با دسترسی مالک (owner) اجرا میشود، نه شخصی که آن را فراخوانی میکند. مالک view اغلب دسترسی کامل دارد. این یعنی سیاستهای Row Level Security (RLS) شما روی view اعمال نمیشوند.
شما یک دیوار نساختهاید؛ بلکه یک فیلتر ساختهاید.
اگر یک فیلتر با شکست مواجه شود، عامل هوش مصنوعی متوجه آن نخواهد شد. یک انسان خطا یا دادههای اشتباه را میبیند، اما یک عامل فقط هر آنچه را که دریافت میکند پردازش میکند. اگر فیلتر شما از کار بیفتد، عامل شما بدون هیچ هشداری شروع به استفاده از دادههای خصوصی میکند.
Postgres 15 این مشکل را با گزینه security_invoker حل کرد.
وقتی security_invoker را روی true تنظیم میکنید، view با نقشِ فراخواننده (calling role) اجرا میشود. این کار view را مجبور میکند تا از سیاستهای RLS شما پیروی کند. در این حالت، view به یک دروازه ساختاری تبدیل میشود.
روش صحیح:
CREATE VIEW public_seeds
WITH (security_invoker = true)
AS
SELECT * FROM moments
WHERE visibility = 'public'
AND is_canonical = true;
حالا دیوار، ساختاری است. حتی اگر یک توسعهدهنده یک query یا join اشتباه بنویسد، سیاست RLS از جدول محافظت میکند.
عبارت «این نباید اتفاق بیفتد» به این بستگی دارد که همه چیز بینقص کار کند. عبارت «این نمیتواند اتفاق بیفتد» به معماری شما بستگی دارد.
وقتی برای هوش مصنوعی میسازید، باید برای آنچه «نمیتواند» اتفاق بیفتد، طراحی کنید.
سه مورد که باید در تنظیمات خود بررسی کنید:
- مطمئن شوید که از service role برای عاملها استفاده نمیکنید. service role کاملاً RLS را دور میزند.
- نسخه Postgres خود را بررسی کنید. برای استفاده از
security_invokerبه نسخه ۱۵ یا بالاتر نیاز دارید. - viewهای موجود خود را بازرسی (audit) کنید. viewهای قدیمی بهطور خودکار از سیاستهای جدید RLS پیروی نمیکنند.
انجمن یادگیری اختیاری: https://t.me/GyaanSetuAi