ફિલ્ટર્સ અને વોલ્સ વચ્ચેનો તફાવત
તમે તમારા ડેટાને એક્સેસ કરી શકે તેવા એક AI એજન્ટ બનાવી રહ્યા છો. તમારી પાસે સુરક્ષા માટે બે વિકલ્પો છે. તમે ડેટાને ફિલ્ટર કરી શકો છો, અથવા તમે તેને વોલ (wall) કરી શકો છો.
ફિલ્ટરિંગનો અર્થ એ છે કે તમારી ક્વેરી ફક્ત ચોક્કસ રો (rows) જ રિટર્ન કરે છે. વોલિંગનો અર્થ એ છે કે એજન્ટ છુપાયેલા રો (rows) સુધી પહોંચી શકતું નથી.
જ્યાં સુધી કંઈક બગડે નહીં ત્યાં સુધી આ બંને સમાન લાગે છે.
મેં તાજેતરમાં 1.2 મિલિયન શબ્દોને નોલેજ બેઝમાં રૂપાંતરિત કરવા માટે એક સિસ્ટમ બનાવી છે. મેં ડેટા મેનેજ કરવા માટે Supabase નો ઉપયોગ કર્યો હતો. હું ઈચ્છતો હતો કે મારા AI એજન્ટ્સ ફક્ત પબ્લિક કન્ટેન્ટ જ જોઈ શકે.
મેં ડેટાને ફિલ્ટર કરવા માટે સ્ટાન્ડર્ડ Postgres view નો ઉપયોગ કર્યો:
CREATE VIEW public_seeds AS
SELECT * FROM moments
WHERE visibility = 'public'
AND is_canonical = true;
આ સાચું લાગે છે. પરંતુ તેમાં એક મોટી ખામી છે. ડિફોલ્ટ રીતે, એક Postgres view તેના માલિક (owner) તરીકે ચાલે છે, તેને કોલ કરનાર વ્યક્તિ તરીકે નહીં. વ્યુના માલિક પાસે અવારનવાર સંપૂર્ણ એક્સેસ હોય છે. આનો અર્થ એ છે કે તમારી Row Level Security (RLS) પોલિસીઓ વ્યુ પર લાગુ પડતી નથી.
તમે વોલ નથી બનાવી. તમે ફિલ્ટર બનાવ્યું છે.
જો ફિલ્ટર નિષ્ફળ જાય, તો AI એજન્ટ તેને નોંધશે નહીં. માણસ ભૂલ અથવા ખોટો ડેટા જોઈ શકે છે. એજન્ટ ફક્ત તેને જે મળે છે તે જ પ્રોસેસ કરે છે. જો તમારું ફિલ્ટર નિષ્ફળ જાય, તો તમારો એજન્ટ ચેતવણી વગર ખાનગી ડેટાનો ઉપયોગ કરવાનું શરૂ કરી દેશે.
Postgres 15 એ security_invoker વિકલ્પ સાથે આ સમસ્યાનું સમાધાન કર્યું છે.
જ્યારે તમે security_invoker ને true સેટ કરો છો, ત્યારે વ્યુ કોલિંગ રોલ (calling role) તરીકે ચાલે છે. આ વ્યુને તમારી RLS પોલિસીઓનું પાલન કરવા માટે મજબૂર કરે છે. વ્યુ એક સ્ટ્રક્ચરલ ગેટ (structural gate) બની જાય છે.
સાચી રીત:
CREATE VIEW public_seeds
WITH (security_invoker = true)
AS
SELECT * FROM moments
WHERE visibility = 'public'
AND is_canonical = true;
હવે વોલ સ્ટ્રક્ચરલ છે. જો કોઈ ડેવલપર ખરાબ ક્વેરી અથવા જોઈન (join) લખે તો પણ, RLS પોલિસી ટેબલનું રક્ષણ કરે છે.
"આ થવું જોઈએ નહીં" એ બધું બરાબર કામ કરે છે તેના પર આધાર રાખે છે. "આ થઈ શકતું નથી" એ તમારા આર્કિટેક્ચર પર આધાર રાખે છે.
જ્યારે તમે AI માટે બનાવો છો, ત્યારે તમારે એ બાબત માટે ડિઝાઇન કરવું જોઈએ જે થઈ શકતું નથી.
તમારા સેટઅપમાં તપાસવા જેવી ત્રણ બાબતો:
- ખાતરી કરો કે તમે એજન્ટ્સ માટે service role નો ઉપયોગ કરી રહ્યા નથી. Service role સંપૂર્ણપણે RLS ને બાયપાસ કરે છે.
- તમારું Postgres વર્ઝન તપાસો.
security_invokerમાટે તમારે વર્ઝન 15 અથવા તેનાથી વધુની જરૂર છે. - તમારા હાલના વ્યુનું ઓડિટ કરો. જૂના વ્યુ આપમેળે નવી RLS પોલિસીઓનું પાલન કરતા નથી.
Optional learning community: https://t.me/GyaanSetuAi