Bezpieczeństwo na poziomie wiersza

AiHummer jest wielodostępny, a jego najsilniejsza granica izolacji znajduje się w samej bazie danych: **Bezpieczeństwo na poziomie wiersza w PostgreSQL (RLS)**Z włączonym RLS baza danych — a nie tylko kod aplikacji — zapewnia, że zapytanie widzi jedynie wiersze należące do bieżącego najemcy.

Poziom: Bezpieczeństwo na poziomie wiersza jest ograniczone przez płatną wersję Przedsiębiorstwo poziom — nie jest częścią darmowej/platformy społecznościowej.

Dlaczego RLS

Filtrowanie na poziomie aplikacji (WHERE tenant_id = ...) jest konieczne, ale kruche: jedno zapomniane wyrażenie może spowodować wyciek danych między najemcami. RLS przenosi gwarancję do PostgreSQL, tak że nawet nieprzefiltrowane zapytanie zwraca tylko wiersze bieżącego najemcy. Jest to warstwa obrony w głąb pod zakresem aplikacji. Dla szerszego modelu wielu najemców — i tego, jak współpracuje on z idempotentnymi efektami ubocznymi — zobacz Wielodostępność i niezmienność.

Ograniczona rola (dobrowolna)

RLS jest dobrowolny udział i jest aktywowany przez podanie bramce drugiego połączenia z bazą danych, które używa ograniczonej roli zamiast właściciela:

# /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

Ten aihummer_app rola jest nie właściciel tabeli, więc PostgreSQL stosuje do niej polityki RLS. Zapytania aplikacji przepływają przez ten ograniczony zbiór. Włączenie RLS polega na ustawieniu AIHUMMER_DB_APP_URL — i lokalne/standardowe (rodzime dla hosta) instalacje ustawiają tę zmienną automatycznie, więc RLS jest aktywne od razu po wyjęciu z pudełka. Jest „opcjonalne” tylko w tym sensie, że niestandardowe lub ręczne wdrożenie musi je ustawić AIHUMMER_DB_APP_URL samo.

[!NOTE] Bez AIHUMMER_DB_APP_URL, bramka używa puli właściciela do wszystkiego a RLS jest w praktyce niewymuszany. Ustaw ograniczony zbiór (który standardowy instalator robi to za ciebie), aby włączyć izolację na poziomie bazy danych.

[!IMPORTANT] RLS nie zależy od planu. Działa tak samo na wszystkich planach, łącznie z Community. Jeśli ekran licencji pokazuje „Bezpieczeństwo na poziomie wiersza” jako niedostępne, to nieścisłość samego ekranu, a nie stan Twojej bazy danych.

Gdzie RLS działa od razu, a gdzie trzeba go włączyć

Sposób instalacji	Stan RLS po instalacji
Instalacja standardowa, PostgreSQL stawia instalator	Aktywny. Ograniczona rola i `AIHUMMER_DB_APP_URL` powstają automatycznie
Własny lub zarządzany PostgreSQL (adres bazy podany z góry)	Nieaktywny. Rolę i `AIHUMMER_DB_APP_URL` zakłada operator
Instalacja bez uprawnień administratora (rootless)	Nieaktywny. Tak samo

[!WARNING] Dwa błędy, po których RLS jest „włączony”, ale niczego nie chroni. Pierwszy: AIHUMMER_DB_APP_URL wskazuje właściciela tabel albo superużytkownika — PostgreSQL zwalnia takie role z polityk, a brama i tak zgłosi RLS jako aktywny. Użyj osobnej roli ograniczonej. Drugi: na własnym PostgreSQL rola ograniczona może powstać automatycznie z przewidywalnym hasłem — nadaj jej własne hasło, zanim baza stanie się dostępna przez sieć.

Zakres dla poszczególnych najemców

Wewnątrz żądania aplikacja ustala bieżącego najemcę na połączeniu przed uruchomieniem zapytań ograniczonych do najemcy — konceptualnie db.WithTenant. Po określeniu zakresu, polityki RLS dotyczące ograniczonej roli ograniczają każde odczytywanie i zapisywanie do wierszy tego najemcy. Zakres jest powiązany z jednostką pracy, więc nie przenika między równoczesnymi żądaniami.

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

Tryb systemu / obejścia dla pracowników

Niektóre prace są legalnie między-najemcowe lub niezależne od najemcy — pracownicy w tle, harmonogramy, odzyskiwanie dostaw i podobne czynności konserwacyjne. Dla tych brama używa tryb systemowy (obejście) który działa na puli właściciela, poza politykami RLS dla poszczególnych najemców, aby zadania infrastrukturalne mogły działać w całym zestawie danych.

[!WARNING] Tryb obejścia przeznaczony jest wyłącznie dla zaufanych pracowników wewnętrznych. Ścieżki obsługi żądań które działają w imieniu użytkownika, muszą zawsze przechodzić przez ograniczone, pulę ograniczoną do najemcy — nigdy ścieżką obejścia.

Migracje uruchamiane są na pulach właściciela

Zmiany schematu wymagają uprawnień, których ograniczona rola nie posiada, więc migracje zawsze uruchamiają się na pulii właściciela (AIHUMMER_DATABASE_URL), pod blokadą doradczą, podczas uruchamiania. Ograniczony aihummer_app rola jest używana tylko do zwykłego ruchu aplikacyjnego. Utrzymuje to czyste rozdzielenie uprawnień: operacje zmieniające schemat używają właściciela; dostęp do danych najemcy używa ograniczonej roli z zastosowanym RLS.

Dokąd dalej

Wielodostępność i niezmienność — pełny model najemcy i jak skutki uboczne pozostają bezpieczne podczas odzyskiwania.
Skarbiec sekretów — per-stan DEK wzmacniają te same izolacja na warstwie sekretów.
RBAC i klucze API o ograniczonym zakresie — autoryzacja powyżej warstwa danych.