𝗧𝗵𝗲 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗕𝗲𝘁𝘄𝗲𝗲𝗻 𝗙𝗶𝗹𝘁𝗲𝗿𝘀 𝗮𝗻𝗱 𝗪𝗮𝗹𝗹𝘀

Різниця між фільтрами та стінами

Ви створюєте ШІ-агента, який має доступ до ваших даних. У вас є два варіанти забезпечення безпеки: ви можете фільтрувати дані або створювати для них «стіни».

Фільтрація означає, що ваш запит повертає лише певні рядки. Створення стін означає, що агент взагалі не може отримати доступ до прихованих рядків.

Вони здаються однаковими, доки щось не зламається.

Нещодавно я побудував систему, яка перетворює 1,2 мільйона слів на базу знань. Для керування даними я використовував Supabase. Я хотів, щоб мої ШІ-агенти бачили лише публічний контент.

Я використав стандартне Postgres view, щоб фільтрувати дані:

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

Це виглядає правильно. Але тут є величезний недолік. За замовчуванням Postgres view виконується від імені власника, а не того, хто його викликає. Власник view часто має повний доступ. Це означає, що ваші політики Row Level Security (RLS) не застосовуються до цього view.

Ви не побудували стіну. Ви побудували фільтр.

Якщо фільтр дасть збій, ШІ-агент цього не помітить. Людина побачить помилку або неправильні дані. Агент просто обробить те, що отримає. Якщо ваш фільтр не спрацює, ваш агент почне використовувати приватні дані без жодного попередження.

Postgres 15 вирішив цю проблему за допомогою опції security_invoker.

Коли ви встановлюєте security_invoker у значення true, view виконується від імені ролі, яка його викликає. Це змушує view дотримуватися ваших RLS-політик. View стає структурним шлюзом.

Правильний спосіб:

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

Тепер стіна є структурною. Навіть якщо розробник напише некоректний запит або join, політика RLS захистить таблицю.

"«Цього не має статися» покладається на те, що все працює ідеально." "«Цього не може статися» покладається на вашу архітектуру."

Коли ви розробляєте рішення для ШІ, ви повинні проектувати систему з урахуванням того, чого не може статися.

Три речі, які варто перевірити у вашій конфігурації:

• Переконайтеся, що ви не використовуєте service role для агентів. service role повністю обходить RLS.
• Перевірте версію Postgres. Для security_invoker потрібна версія 15 або вище.
• Проведіть аудит існуючих view. Старі view не підпорядковуються новим RLS-політикам автоматично.

Джерело: https://dev.to/chadtdyar/the-difference-between-this-shouldnt-happen-and-this-cannot-happen-in-ai-content-pipelines-1g0p

Додаткова спільнота для навчання: https://t.me/GyaanSetuAi