Row-Level Security — AiHummer Құжаттама

AiHummer көпжалгерлі, және оның ең мықты оқшаулау шекарасы дерекқордың өзінде орналасқан: PostgreSQL Row-Level Security (RLS). RLS қосылған кезде дерекқор — тек қосымша коды ғана емес — сұраныстың тек ағымдағы жалгерге тиесілі жолдарды ғана көретінін мәжбүрлейді.

RLS неге қажет

Қосымша деңгейіндегі сүзгілеу (WHERE tenant_id = ...) қажет, бірақ нәзік: бір ұмытылған сөйлем жалгерлер арасында деректердің ағуына әкелуі мүмкін. RLS кепілдікті PostgreSQL ішіне көшіреді, осылайша тіпті сүзгіленбеген сұраныс та тек ағымдағы жалгердің жолдарын ғана қайтарады. Бұл қосымшаның өзіндік scope-ынан төменде жатқан тереңдетілген қорғаныс қабаты. Кеңірек көпжалгерлік моделі — және оның идемпотентті жанама әсерлермен қалай үйлесетіні — туралы Көпжалгерлік және идемпотенттік бөлімін қараңыз.

Шектелген рөл (opt-in)

RLS — opt-in және ол 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 саясаттарын қолданады. Қосымша сұраныстары осы шектелген pool арқылы өтеді. Хост-нативті орнатулар үшін орнатушы AIHUMMER_DB_APP_URL мәнін автоматты түрде қосады.

[!NOTE] AIHUMMER_DB_APP_URL болмаса, gateway бәріне иесінің pool-ын пайдаланады және RLS іс жүзінде мәжбүрленбейді. Дерекқор деңгейіндегі оқшаулауды қосу үшін шектелген pool-ды орнатыңыз.

Әр-жалгер бойынша scope

Сұраныс ішінде қосымша жалгерге scope қойылған сұраныстарды орындамас бұрын қосылымда ағымдағы жалгерді орнатады — концептуалды түрде db.WithTenant. Scope қойылғаннан кейін шектелген рөлдегі RLS саясаттары әрбір оқу мен жазуды сол жалгердің жолдарымен шектейді. Scope жұмыс бірлігімен байланысты, сондықтан ол бір мезгілдегі сұраныстар арасында ағып кетпейді.

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

Worker-лер үшін жүйелік / айналып өту режимі

Кейбір жұмыс заңды түрде жалгерлер аралық немесе жалгерге тәуелсіз — фондық worker-лер, жоспарлағыштар, outbox және ұқсас механизмдер. Олар үшін gateway иесінің pool-ында, әр-жалгер RLS саясаттарының сыртында жұмыс істейтін жүйелік (айналып өту) режимін пайдаланады, осылайша инфрақұрылым тапсырмалары бүкіл деректер жиыны бойынша жұмыс істей алады.

[!WARNING] Айналып өту режимі тек сенімді ішкі worker-лер үшін. Пайдаланушының атынан әрекет ететін сұранысты өңдейтін код жолдары әрқашан шектелген, жалгерге scope қойылған pool арқылы жұмыс істеуі керек — ешқашан айналып өту жолы арқылы емес.

Миграциялар иесінің pool-ында орындалады

Схема өзгерістері шектелген рөлде жоқ артықшылықтарды талап етеді, сондықтан миграциялар әрқашан иесінің pool-ында (AIHUMMER_DATABASE_URL) advisory lock астында, іске қосылу кезінде орындалады. Шектелген aihummer_app рөлі тек қарапайым қосымша трафигі үшін пайдаланылады. Бұл артықшылықтардың бөлінуін таза ұстайды: схеманы өзгертетін операциялар иесін пайдаланады; жалгер деректеріне қол жеткізу RLS қолданылған шектелген рөлді пайдаланады.

Әрі қарай қайда

Көпжалгерлік және идемпотенттік — толық жалгер моделі және қалпына келтіру кезінде жанама әсерлердің қалай қауіпсіз болатыны.
Secrets vault — әр-жалгер DEK-тер құпиялар қабатында дәл сол оқшаулауды күшейтеді.
RBAC және scoped API кілттері — деректер қабатынан жоғары авторизация.