AiHummer
Беларуская▾
УвайсціАсабісты кабінет
v1.0.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Бяспека/Бяспека на ўзроўні радкоў

Бяспека на ўзроўні радкоў

v1.0.x · абноўлена 2026-06-26

AiHummer падтрымлівае некалькі арандатароў, і яго наймацнейшая мяжовая ізаляцыя знаходзіцца непасрэдна ў базе даных: **Бяспека радкоў на ўзроўні PostgreSQL (RLS)**З уключанай функцыяй RLS база дадзеных — а не толькі код прыкладання — забяспечвае, што запыт бачыць толькі радкі, якія належаць бягучаму арандатару.

Узровень: Роўнельная бяспека кіруецца праз аплату Прадпрыемства ўзровень — гэта не частка бясплатнай/Супольнаснай платформы.

Чаму RLS

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

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

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

# /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] Без 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 для абмежаванай ролі абмяжоўваюць усе аперацыі чытання і запісу толькі радкамі гэтага арандатара. Вобласць звязана з адзініцай працы, таму яна не распаўсюджваецца на суседнія запыты.

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

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

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

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

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

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

Куды далей