வடிகட்டிகளுக்கும் சுவர்களுக்கும் இடையிலான வேறுபாடு

ஃபில்டர்கள் (Filters) மற்றும் சுவர்கள் (Walls) இடையிலான வேறுபாடு

உங்கள் தரவை அணுகக்கூடிய ஒரு AI ஏஜென்ட்டை (AI agent) நீங்கள் உருவாக்குகிறீர்கள். பாதுகாப்பிற்கு உங்களிடம் இரண்டு தேர்வுகள் உள்ளன. நீங்கள் தரவை ஃபில்டர் (filter) செய்யலாம் அல்லது அதை ஒரு சுவருக்குப் பின்னால் (wall) வைக்கலாம்.

ஃபில்டரிங் (Filtering) என்பது உங்கள் வினவல் (query) குறிப்பிட்ட வரிசைகளை (rows) மட்டுமே வழங்கும் என்பதைக் குறிக்கிறது. வாலிங் (Walling) என்பது மறைக்கப்பட்ட வரிசைகளை ஏஜென்ட்டால் எட்டவே முடியாது என்பதைக் குறிக்கிறது.

ஏதேனும் ஒன்று முறியும் வரை இவை இரண்டும் ஒரே மாதிரியாகத் தோன்றும்.

நான் சமீபத்தில் 1.2 மில்லியன் சொற்களை ஒரு அறிவுத் தளமாக (knowledge base) மாற்றும் அமைப்பை உருவாக்கினேன். தரவை நிர்வகிக்க நான் Supabase ஐப் பயன்படுத்தினேன். எனது AI ஏஜென்ட்கள் பொதுவான உள்ளடக்கத்தை (public content) மட்டுமே பார்க்க வேண்டும் என்று நான் விரும்பினேன்.

தரவை ஃபில்டர் செய்ய நான் ஒரு நிலையான Postgres view-வைப் பயன்படுத்தினேன்:

CREATE VIEW public_seeds AS
  SELECT * FROM moments
  WHERE visibility = 'public'
    AND is_canonical = true;

இது சரியாகத் தோன்றலாம். ஆனால் இதில் ஒரு மிகப்பெரிய குறை உள்ளது. இயல்பாகவே (By default), ஒரு Postgres view அதன் உரிமையாளராகவே (owner) இயங்கும், அதை அழைப்பவராக (caller) அல்ல. View உரிமையாளருக்கு பெரும்பாலும் முழு அணுகல் இருக்கும். இதன் பொருள் உங்கள் Row Level Security (RLS) கொள்கைகள் (policies) இந்த view-விற்குப் பொருந்தாது.

நீங்கள் ஒரு சுவரைக் கட்டவில்லை. நீங்கள் ஒரு ஃபில்டரை மட்டுமே உருவாக்கியுள்ளீர்கள்.

ஒரு ஃபில்டர் தோல்வியடைந்தால், ஒரு AI ஏஜென்ட் அதை கவனிக்காது. ஒரு மனிதன் பிழையையோ அல்லது தவறான தரவையோ கவனிப்பார். ஆனால் ஒரு ஏஜென்ட் தான் எதைப் பெறுகிறதோ அதை அப்படியே செயலாக்கும் (process). உங்கள் ஃபில்டர் தோல்வியடைந்தால், உங்கள் ஏஜென்ட் எந்த எச்சரிக்கையும் இன்றித் தனிப்பட்ட தரவைப் (private data) பயன்படுத்தத் தொடங்கும்.

Postgres 15 இதை security_invoker விருப்பத்தின் மூலம் தீர்த்துள்ளது.

நீங்கள் security_invoker-ஐ true என்று அமைக்கும்போது, view அழைக்கும் ரோல் (calling role) போலவே இயங்கும். இது view உங்கள் RLS கொள்கைகளுக்குக் கீழ்ப்படியக் கட்டாயப்படுத்துகிறது. இதன் மூலம் view ஒரு கட்டமைப்பு வாயிலாக (structural gate) மாறுகிறது.

சரியான முறை:

CREATE VIEW public_seeds
  WITH (security_invoker = true)
AS
  SELECT * FROM moments
  WHERE visibility = 'public'
    AND is_canonical = true;

இப்போது சுவர் ஒரு கட்டமைப்பாக உள்ளது. ஒரு டெவலப்பர் தவறான வினவல் (query) அல்லது join எழுதினாலும், RLS கொள்கை அட்டவணையைப் (table) பாதுகாக்கிறது.

"இது நடக்கக்கூடாது" என்பது அனைத்தும் சரியாகச் செயல்படுவதைச் சார்ந்துள்ளது. "இது நடக்கவே முடியாது" என்பது உங்கள் கட்டமைப்பைச் (architecture) சார்ந்துள்ளது.

நீங்கள் AI-க்காக உருவாக்கும்போது, நடக்கவே முடியாத விஷயங்களுக்காக வடிவமைக்க வேண்டும்.

உங்கள் அமைப்பில் (setup) சரிபார்க்க வேண்டிய மூன்று விஷயங்கள்:

• ஏஜென்ட்களுக்கு service role-ஐப் பயன்படுத்தவில்லை என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். Service role முழுமையாக RLS-ஐத் தவிர்க்கும் (bypass).
• உங்கள் Postgres பதிப்பைச் சரிபார்க்கவும். security_invoker-க்கு பதிப்பு 15 அல்லது அதற்கு மேல் தேவை.
• உங்கள் தற்போதைய views-களை ஆய்வு (audit) செய்யுங்கள். பழைய views தானாகவே புதிய RLS கொள்கைகளைப் பின்பற்றுவதில்லை.

Source: https://dev.to/chadtdyar/the-difference-between-this-shouldnt-happen-and-this-cannot-happen-in-ai-content-pipelines-1g0p

Optional learning community: https://t.me/GyaanSetuAi