სტრიქონების დონეზე უსაფრთხოება

# /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-ში (RLS)**. RLS ჩართვისას მონაცემთა ბაზა — არა მხოლოდ პროგრამის კოდი — უზრუნველყოფს, რომ შეკითხვა ხედავს მხოლოდ იმ სტრიქონებს, რომლებიც მიეკუთვნება მიმდინარე აჩენატორს. **საფეხური:** სტრიქონების დონეზე უსაფრთხოება შეზღუდულია ფასიანი ვერსიით **წარმოება** დონე — ეს არ არის უფასო/საზოგადოებრივი პლატფორმის ნაწილი. ## რატომ RLS ფილტრაცია აპლიკაციის დონეზე (`WHERE tenant_id = ...`) აუცილებელია, მაგრამ ფაქიზი: ერთი მიტოვებული პუნქტი შეიძლება გამოიწვიოს მონაცემების გაჟონვა ქირავნებს შორის. RLS ამ კონტროლს PostgreSQL-ში გადაიტანს, ასე რომ, ფილტრის გარეშე მოთხოვნაც მხოლოდ მიმდინარე ქირავნის სტრიქონებს გამოიტანს. ეს არის სიღრმისეული დაცვა აპლიკაციის მოქმედების ზონის ქვემოთ. მრავალმომხმარებლური გარემოს უფრო ფართო მოდელისათვის — და იმისთვის, თუ როგორ ერწყმის ეს იდემპოტენტურ გვერდით ეფექტებს — იხილეთ [მრავალმომხმარებლური რეჟიმი და იდემპოტენტობა](/ka/v1.0/architecture/multitenancy-idempotency). ## შეზღუდული როლი ( სურვილის მიხედვით ) RLS არის **abonementi სურვილისამებრ** და აქტიურდება გატანით გეითვეის მეორე კავშირის მიწოდებით მონაცემთა ბაზასთან, რომელიც იყენებს *შეზღუდულ* როლს მფლობელის როლის ნაცვლად: ```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 პოლიტიკას მასზე. აპლიკაციის მოთხოვნები გადის ამ შეზღუდულ აუზში. RLS-ის ჩართვა დამოკიდებულია დაყენებაზე **`AIHUMMER_DB_APP_URL`** — და **ლოკალური/სტანდარტული (ჰოსტზე) ინსტალაციები ავტომატურად ეს აპარატურა აწესრიგებს**, ასე რომ RLS აქტიურია ინსტალაციისთანავე. ის არის „აპტიკური“ მხოლოდ იმ გაგებით, რომ მომხმარებლის ან ხელით ინსტალაციამ უნდა აამოქმედოს იგი `AIHUMMER_DB_APP_URL` თავისი. > [!NOTE] > Without `AIHUMMER_DB_APP_URL`, ხიდი იყენებს მეპატივგანთა აუზს ყველაფრისთვის > და RLS ფაქტობრივად არ გამოიყენება. დააყენეთ შეზღუდული აუზი (რომელი > სტანდარტული ინსტალერი ახდენს თქვენთვის) გააქტიუროს იზოლაცია მონაცემთა ბაზის დონეზე. > [!IMPORTANT] > **RLS ტარიფზე არ არის დამოკიდებული.** ის ერთნაირად მუშაობს ყველა ტარიფზე, > Community-ის ჩათვლით. თუ ლიცენზიის ეკრანზე «მწკრივის დონის დაცვა» ნაჩვენებია > როგორც მიუწვდომელი, ეს თავად იმ ეკრანის უზუსტობაა და არა თქვენი ბაზის > მდგომარეობა. ### სად არის RLS უკვე აქტიური და სად უნდა ჩართოთ თავად | როგორ დააყენეთ | RLS დაყენების შემდეგ | |---|---| | ჩვეულებრივი დაყენება, PostgreSQL-ს ამზადებს ინსტალატორი | **აქტიურია.** შეზღუდული როლი და `AIHUMMER_DB_APP_URL` იქმნება ავტომატურად | | საკუთარი ან მართვადი PostgreSQL (ბაზის მისამართი წინასწარაა მითითებული) | **არ არის აქტიური.** როლს და `AIHUMMER_DB_APP_URL`-ს ქმნის ოპერატორი | | დაყენება ადმინისტრატორის უფლებების გარეშე (rootless) | **არ არის აქტიური.** იგივე | > [!WARNING] > **ორი შეცდომა, რის შემდეგაც RLS «ჩართულია», მაგრამ არაფერს იცავს.** > **პირველი:** `AIHUMMER_DB_APP_URL` მიუთითებს ცხრილების მფლობელზე ან > სუპერმომხმარებელზე — PostgreSQL ასეთ როლებს პოლიტიკებისგან ათავისუფლებს, > კარიბჭე კი მაინც შეატყობინებს, რომ RLS აქტიურია. გამოიყენეთ ცალკე შეზღუდული > როლი. **მეორე:** საკუთარ PostgreSQL-ზე შეზღუდული როლი შეიძლება ავტომატურად > შეიქმნას წინასწარ განჭვრეტადი პაროლით — მიეცით მას თქვენი პაროლი, სანამ ბაზა > ქსელიდან ხელმისაწვდომი გახდება. ## შეკვეთილის მიხედვით მასშტაბირება შეკითხვის შიგნით აპლიკაცია განსაზღვრავს მიმდინარე გაქირავებულს კავშირის მიხედვით, სანამ შესრულდება შეკითხვები გაქირავებულის შეზღუდვით — კონცეპტუალურად `db.WithTenant`. RLS პოლიტიკის განცხადების შემდეგ, შეზღუდული როლისთვის შეზღუდავს ამ დეველოპერის ყოველ წაკითხვასა და წერას. განცხადების სფერო დაკავშირებულია სამუშაო ერთეულთან, ამიტომ ის არ ვრცელდება პარალელურ მოთხოვნებში. ```text request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant ``` ## სისტემური / შემოვლის რეჟიმი თანამშრომლებისთვის ზოგი სამუშაო კანონიერად წარმოადგენს არასაკრედიტო ან მეკარე-დამატებითი — ფონის პროცესები, დაგეგმილები, მიწოდების აღდგენა და მსგავსი მომსახურება. ამ სამუშაოებისთვის გალია იყენებს **სისტემური (ხრიკვითი) რეჟიმი** რომელიც მუშაობს მფლობელის პულზე, RLS პოლიტიკების ფარგლებს გარეთ თითოეული ინკუბატორისთვის, ამიტომ ინფრასტრუქტურული დავალებები შეუძლია იმუშაოს მთლიანი მონაცემთა ნაკრებით. > [!WARNING] > ჩამოსვლის რეჟიმი განკუთვნილია მხოლოდ ნდობით აღჭურვილი შიდა თანამშრომლებისთვის. მოთხოვნების დამუშავების გზები > მოქმედება მომხმარებლის სახელით ყოველთვის უნდა შესრულდეს შეზღუდული პროცესის მეშვეობით, > ბაზა ქირავნობის სფეროთი — არასოდეს არის მანევრი გზა. ## მიგრაციები შესრულდება მფლობელის აუზში სქემის ცვლილებისთვის საჭიროა პრივილეგიები, რომელიც შეზღუდულ როლს არ აქვს, ამიტომ **მიგრაციები ყოველთვის ხდება მფლობელის აუზზე** (`AIHUMMER_DATABASE_URL`), სხრილინად ჩაკეტილ ზღვარზე, სტარტზე. შეზღუდული `aihummer_app` როლი გამოიყენება მხოლოდ ჩვეულებრივი აპლიკაციის ტრაფიკისთვის. ეს ინარჩუნებს პრივილეგიების განცალკევებას სუფთად: სკემის შეცვლის ოპერაციები იყენებს მფლობელს; ქირისწილის მონაცემებთან წვდომა იყენებს შეზღუდულ როლს, RLS-თან ერთად. ## სად შემდეგ? - [მრავალმომხმარებლური რეჟიმი და idemპოტენტობა](/ka/v1.0/architecture/multitenancy-idempotency) — სრულყოფილი მობინადრეს მოდელი და ის, როგორი გვერდითი ეფექტები რჩება უსაფრთხო აღდგენის დროს. - [საიდუმლოებების საცავი](/ka/v1.0/security/vault) — DEK თითოეული მყიდველი ზუსტად იგივე მიდგომას აძლიერებს იზოლაცია საიდუმლოებების საფენზე. - [RBAC და შეზღუდული API გასაღებები](/ka/v1.0/security/rbac) — ავტორიზაცია ზემოთ მონაცემთა ფენა.