Row-Level Security — AiHummer Дакументацыя

AiHummer з’яўляецца мультытэнантным, і яго самая моцная мяжа ізаляцыі знаходзіцца ў самой базе даных: PostgreSQL Row-Level Security (RLS). З уключаным RLS база даных — а не толькі код дадатку — гарантуе, што запыт заўсёды бачыць толькі радкі, якія належаць бягучаму тэнанту.

Навошта RLS

Фільтрацыя на ўзроўні дадатку (WHERE tenant_id = ...) неабходная, але далікатная: адзін забыты выраз можа выцекчы дадзеныя паміж тэнантамі. RLS пераносіць гарантыю у PostgreSQL, так што нават нефільтраваны запыт вяртае толькі радкі бягучага тэнанта. Гэта пласт абароны ў глыбіню пад уласным скоупінгам дадатку. Аб больш шырокай мадэлі мультытэнантнасці — і аб тым, як яна спалучаецца з ідэмпатэнтнымі пабочнымі эфектамі — глядзіце Мультытэнантнасць і ідэмпатэнтнасць.

Абмежаваная роля (апцыянальна)

RLS апцыянальны і актывуецца праз даванне gateway другога злучэння з базай даных, якое выкарыстоўвае абмежаваную ролю замест уладальніка:

# /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-палітыкі. Запыты дадатку праходзяць праз гэты абмежаваны пул. Для хост-натыўных усталёвак усталёўшчык падключае AIHUMMER_DB_APP_URL аўтаматычна.

[!NOTE] Без AIHUMMER_DB_APP_URL gateway выкарыстоўвае пул уладальніка для ўсяго, і RLS фактычна не прымяняецца. Усталюйце абмежаваны пул, каб уключыць ізаляцыю на ўзроўні базы даных.

Скоупінг па тэнантах

Унутры запыту дадатак усталёўвае бягучага тэнанта на злучэнні перад выкананнем запытаў, абмежаваных тэнантам — канцэптуальна db.WithTenant. Пасля скоупінгу RLS-палітыкі на абмежаванай ролі абмяжоўваюць кожнае чытанне і запіс радкамі гэтага тэнанта. Скоуп прывязаны да адзінкі працы, таму ён не выцякае паміж паралельнымі запытамі.

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

Сістэмны рэжым / рэжым абыходу для воркераў

Некаторая праца легітымна крос-тэнантная або тэнант-агнастычная — фонавыя воркеры, планіроўшчыкі, outbox і падобная механіка. Для іх gateway выкарыстоўвае сістэмны рэжым (абыходу), які працуе на пуле ўладальніка, па-за RLS-палітыкамі па тэнантах, так што інфраструктурныя задачы могуць працаваць праз увесь набор дадзеных.

[!WARNING] Рэжым абыходу прызначаны толькі для давераных унутраных воркераў. Шляхі кода, якія апрацоўваюць запыты і дзейнічаюць ад імя карыстальніка, заўсёды павінны праходзіць праз абмежаваны, прывязаны да тэнанта пул — ніколі праз шлях абыходу.

Міграцыі выконваюцца на пуле ўладальніка

Змены схемы патрабуюць прывілеяў, якіх абмежаваная роля не мае, таму міграцыі заўсёды выконваюцца на пуле ўладальніка (AIHUMMER_DATABASE_URL), пад advisory lock, пры запуску. Абмежаваная роля aihummer_app выкарыстоўваецца толькі для звычайнага трафіку дадатку. Гэта захоўвае раздзяленне прывілеяў чыстым: аперацыі, якія мяняюць схему, выкарыстоўваюць уладальніка; доступ да дадзеных тэнанта выкарыстоўвае абмежаваную ролю з прымененым RLS.

Куды далей

Мультытэнантнасць і ідэмпатэнтнасць — поўная мадэль тэнантаў і тое, як пабочныя эфекты застаюцца бяспечнымі пры аднаўленні.
Сховішча сакрэтаў — DEK па тэнантах узмацняюць тую самую ізаляцыю на ўзроўні сакрэтаў.
RBAC і абмежаваныя API-ключы — аўтарызацыя над пластом дадзеных.