Row-Level Security

# /home/.aihummer/etc/gateway.env
# Owner pool — runs migrations, used for system/bypass operations
AIHUMMER_DATABASE_URL=postgres://owner:...@localhost/aihummer

# Restricted application pool — RLS policies apply (aihummer_app role)
AIHUMMER_DB_APP_URL=postgres://aihummer_app:...@localhost/aihummer

request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant

AiHummer მრავალმოიჯარეა, და მისი ყველაზე ძლიერი იზოლაციის საზღვარი ცხოვრობს თავად ბაზაში: **PostgreSQL Row-Level Security (RLS)**. ჩართული RLS-ით ბაზა — და არა მხოლოდ აპლიკაციის კოდი — უზრუნველყოფს, რომ მოთხოვნა ოდესმე ხედავდეს მხოლოდ მიმდინარე მოიჯარის კუთვნილ სტრიქონებს. ## რატომ RLS აპლიკაციის-დონის ფილტრაცია (`WHERE tenant_id = ...`) აუცილებელია, მაგრამ მყიფე: ერთი დავიწყებული პირობა შეიძლება გაჟონავდეს მონაცემებს მოიჯარეებს შორის. RLS გადააქვს გარანტია PostgreSQL-ში ისე, რომ გაუფილტრავი მოთხოვნაც კი აბრუნებს მხოლოდ მიმდინარე მოიჯარის სტრიქონებს. ეს არის სიღრმისეული-დაცვის ფენა აპლიკაციის საკუთარი არეალირების ქვემოთ. უფრო ფართო მრავალმოიჯარეობის მოდელისთვის — და როგორ წყვილდება ის იდემპოტენტურ გვერდით-ეფექტებთან — იხ. [მრავალმოიჯარეობა და იდემპოტენტობა](/ka/v1.0/architecture/multitenancy-idempotency). ## შეზღუდული როლი (opt-in) RLS არის **opt-in** და ააქტიურდება gateway-ისთვის მეორე ბაზის კავშირის მიცემით, რომელიც იყენებს *შეზღუდულ* როლს მფლობელის ნაცვლად: ```ini # /home/.aihummer/etc/gateway.env # Owner pool — runs migrations, used for system/bypass operations AIHUMMER_DATABASE_URL=postgres://owner:...@localhost/aihummer # Restricted application pool — RLS policies apply (aihummer_app role) AIHUMMER_DB_APP_URL=postgres://aihummer_app:...@localhost/aihummer ``` `aihummer_app` როლი **არ** არის ცხრილის მფლობელი, ასე რომ PostgreSQL ამ როლს RLS პოლიტიკებს ადებს. აპლიკაციის მოთხოვნები მიედინება ამ შეზღუდული pool-ით. ჰოსტ-მშობლიური ინსტალაციებისთვის ინსტალატორი ავტომატურად აერთებს `AIHUMMER_DB_APP_URL`-ს. > [!NOTE] > `AIHUMMER_DB_APP_URL`-ის გარეშე, gateway ყველაფრისთვის იყენებს მფლობელის pool-ს და RLS > ფაქტობრივად არ ხორციელდება. დააყენე შეზღუდული pool, რათა ჩართო ბაზის-დონის იზოლაცია. ## თითო-მოიჯარის არეალირება მოთხოვნის შიგნით, აპლიკაცია ადგენს მიმდინარე მოიჯარეს კავშირზე მოიჯარე-არეალირებული მოთხოვნების გაშვებამდე — კონცეპტუალურად `db.WithTenant`. არეალირების შემდეგ, შეზღუდულ როლზე არსებული RLS პოლიტიკები ზღუდავენ ყველა კითხვასა და ჩაწერას ამ მოიჯარის სტრიქონებამდე. არეალი მიბმულია სამუშაოს ერთეულზე, ასე რომ ის არ ჟონავს თანმხვედრ მოთხოვნებს შორის. ```text request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant ``` ## სისტემური / bypass რეჟიმი worker-ებისთვის ზოგი სამუშაო ლეგიტიმურად ჯვარედინ-მოიჯარეა ან მოიჯარე-აგნოსტიკურია — ფონური worker-ები, განრიგების მმართველები, outbox და მსგავსი მექანიზმი. მათთვის gateway იყენებს **სისტემურ (bypass) რეჟიმს**, რომელიც მუშაობს მფლობელის pool-ზე, თითო-მოიჯარის RLS პოლიტიკების მიღმა, ისე, რომ ინფრასტრუქტურის დავალებებმა შეძლონ მთელ მონაცემთა ნაკრებზე ოპერირება. > [!WARNING] > bypass რეჟიმი მხოლოდ სანდო შიდა worker-ებისთვისაა. მოთხოვნა-დამმუშავებელი კოდის გზებმა, > რომლებიც მოქმედებენ მომხმარებლის სახელით, ყოველთვის უნდა გაიარონ შეზღუდული, > მოიჯარე-არეალირებული pool-ით — არასოდეს bypass გზით. ## მიგრაციები მუშაობს მფლობელის pool-ზე სქემის ცვლილებებს სჭირდება პრივილეგიები, რომლებიც შეზღუდულ როლს არ აქვს, ასე რომ **მიგრაციები ყოველთვის მუშაობს მფლობელის pool-ზე** (`AIHUMMER_DATABASE_URL`), საკონსულტაციო ბლოკირების ქვეშ, გაშვებისას. შეზღუდული `aihummer_app` როლი გამოიყენება მხოლოდ ჩვეულებრივი აპლიკაციის ტრაფიკისთვის. ეს ინარჩუნებს პრივილეგიების გამიჯვნას სუფთად: სქემის-მცვლელი ოპერაციები იყენებენ მფლობელს; მოიჯარის მონაცემებზე წვდომა იყენებს შეზღუდულ როლს RLS-ით. ## სად შემდეგ - [მრავალმოიჯარეობა და იდემპოტენტობა](/ka/v1.0/architecture/multitenancy-idempotency) — სრული მოიჯარის მოდელი და როგორ რჩება გვერდითი-ეფექტები უსაფრთხო აღდგენისას. - [საიდუმლოების საცავი](/ka/v1.0/security/vault) — თითო-მოიჯარის DEK-ები აძლიერებენ იმავე იზოლაციას საიდუმლოების ფენაზე. - [RBAC და არეალირებული API გასაღებები](/ka/v1.0/security/rbac) — ავტორიზაცია მონაცემთა ფენის ზემოთ.