Qator darajasidagi xavfsizlik — AiHummer Hujjatlar

AiHummer koʻp ijarachili boʻlib, uning eng kuchli izolyatsiya chegarasi maʼlumotlar bazasining oʻzida yashaydi: PostgreSQL Qator darajasidagi xavfsizlik (RLS). RLS yoqilganda maʼlumotlar bazasi — faqat ilova kodi emas — soʻrov faqat joriy ijarachiga tegishli qatorlarni koʻrishini majburlaydi.

Nima uchun RLS

Ilova darajasidagi filtrlash (WHERE tenant_id = ...) zarur, lekin moʻrt: bitta unutilgan band ijarachilar oʻrtasida maʼlumotlarni sizdirishi mumkin. RLS kafolatni PostgreSQL’ga koʻchiradi, shunda hatto filtrlanmagan soʻrov ham faqat joriy ijarachining qatorlarini qaytaradi. Bu ilovaning oʻz koʻlamlashidan pastdagi chuqurlikdagi himoya qatlamidir. Kengroq koʻp ijarachilik modeli — va u idempotent yon taʼsirlar bilan qanday juftlashishi — uchun Koʻp ijarachilik va idempotentlik ga qarang.

Cheklangan rol (ixtiyoriy)

RLS ixtiyoriy boʻlib, shlyuzga egasi emas, cheklangan roldan foydalanadigan ikkinchi maʼlumotlar bazasi ulanishini berish orqali faollashtiriladi:

# /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 roli jadval egasi emas, shuning uchun PostgreSQL unga RLS siyosatlarini qoʻllaydi. Ilova soʻrovlari ushbu cheklangan pul orqali oqadi. Xost-mahalliy oʻrnatishlar uchun oʻrnatuvchi AIHUMMER_DB_APP_URL ni avtomatik ulaydi.

[!NOTE] AIHUMMER_DB_APP_URL boʻlmasa, shlyuz hamma narsa uchun egasi pulidan foydalanadi va RLS amalda majburlanmaydi. Maʼlumotlar bazasi darajasidagi izolyatsiyani yoqish uchun cheklangan pulni oʻrnating.

Har bir ijarachi uchun koʻlamlash

Soʻrov ichida ilova ijarachiga koʻlamlangan soʻrovlarni ishga tushirishdan oldin ulanishda joriy ijarachini oʻrnatadi — kontseptual jihatdan db.WithTenant. Koʻlamlangandan keyin cheklangan roldagi RLS siyosatlari har bir oʻqish va yozishni shu ijarachining qatorlari bilan cheklaydi. Koʻlam ish birligiga bogʻlangan, shuning uchun u bir vaqtning oʻzida boʻladigan soʻrovlar oʻrtasida sizib chiqmaydi.

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

Ishchilar uchun tizim / chetlab oʻtish rejimi

Baʼzi ishlar qonuniy ravishda ijarachilararo yoki ijarachidan mustaqil — fon ishchilari, rejalashtiruvchilar, outbox va shunga oʻxshash mexanizmlar. Ular uchun shlyuz har bir ijarachi RLS siyosatlaridan tashqarida, egasi pulida ishlaydigan tizim (chetlab oʻtish) rejimini ishlatadi, shunda infratuzilma vazifalari butun maʼlumotlar toʻplami boʻylab ishlay oladi.

[!WARNING] Chetlab oʻtish rejimi faqat ishonchli ichki ishchilar uchun. Foydalanuvchi nomidan harakat qiladigan soʻrovni qayta ishlash kod yoʻllari har doim cheklangan, ijarachiga koʻlamlangan pul orqali ishlashi kerak — hech qachon chetlab oʻtish yoʻli orqali emas.

Migratsiyalar egasi pulida ishlaydi

Sxema oʻzgarishlari cheklangan rol ega boʻlmagan imtiyozlarni talab qiladi, shuning uchun migratsiyalar har doim egasi pulida (AIHUMMER_DATABASE_URL), maslahat qulfi ostida, ishga tushishda ishlaydi. Cheklangan aihummer_app roli faqat oddiy ilova trafigi uchun ishlatiladi. Bu imtiyozlarni ajratishni toza saqlaydi: sxemani oʻzgartiruvchi operatsiyalar egasini ishlatadi; ijarachi maʼlumotlariga kirish RLS qoʻllanilgan cheklangan rolni ishlatadi.

Keyingisi qayerda

Koʻp ijarachilik va idempotentlik — toʻliq ijarachi modeli va yon taʼsirlar tiklash ostida qanday xavfsiz qolishi.
Maxfiy maʼlumotlar ombori — har bir ijarachi uchun DEK’lar bir xil izolyatsiyani maxfiy maʼlumotlar qatlamida mustahkamlaydi.
RBAC va koʻlamli API kalitlari — maʼlumotlar qatlami ustidagi avtorizatsiya.