Sətir Səviyyəli Təhlükəsizlik

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

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

AiHummer çoxmüştərilidir və onun ən güclü izolyasiya sərhədi verilənlər bazasının özündə yerləşir: **PostgreSQL Sətri-Səviyyəli Təhlükəsizlik (RLS)**. RLS aktiv olduqda, verilənlər bazası — yalnız tətbiq kodu deyil — bir sorğunun yalnız cari tenant-a aid sətirləri görməsini təmin edir. **Səviyyə:** Sətir Səviyyəli Təhlükəsizlik ödənişli ilə məhdudlaşdırılır **Müəssisə** səviyyə — bu pulsuz/İcma platformasının bir hissəsi deyil. ## Niyə RLS Tətbiq səviyyəli filtrasiya (`WHERE tenant_id = ...`) vacibdir, lakin həssasdır: unudulmuş bir bənd məlumatları tenantlar arasında sızdıra bilər. RLS zəmanəti PostgreSQL-ə köçürür, beləliklə, hətta filtrlənməmiş sorğu yalnız cari tenantın sətirlərini qaytarır. Bu, tətbiqin öz miqyaslama mexanizminin altında dərin qorunma qatıdır. Daha geniş çoxtenantlılıq modeli və onun idempotent yan təsirlərlə necə uyğunlaşdığı haqqında baxın [Çoxtenantlilik və idempotentlik](/az/v1.0/architecture/multitenancy-idempotency). ## Məhdud rol (istəyə əsasən) RLS-dir **qoşulmaq** və sahibi əvəzinə *məhdudlaşdırılmış* roldan istifadə edən ikinci verilənlər bazası bağlantısı verərək qapını aktivləşdirir: ```ini # /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 ``` O `aihummer_app` roludur **yox** cədvəl sahibi, beləliklə PostgreSQL ona RLS siyasətlərini tətbiq edir. Tətbiq sorğuları bu məhdudlaşdırılmış hovuzdan keçir. RLS-i aktivləşdirmək, sadəcə bir parametri təyin etmək məsələsidir **`AIHUMMER_DB_APP_URL`** — və **yerli/standart (ev sahibi-yerli) quraşdırmalar bu dəyişəni avtomatik olaraq təyin edir**, beləliklə RLS hazır şəkildə aktivdir. O yalnız o mənada “seçimlə”dir ki, xüsusi və ya əl ilə yerləşdirmə təyin etməlidir `AIHUMMER_DB_APP_URL` özünü. > [!NOTE] > Siz `AIHUMMER_DB_APP_URL`, portal hər şey üçün sahib hovuzundan istifadə edir > və RLS faktiki olaraq tətbiq olunmur. Məhdudlaşdırılmış hovuzu təyin edin (hansı ki > standart quraşdırıcı sizin üçün edir) verilənlər bazası səviyyəsində təcridi aktivləşdirmək üçün. > [!IMPORTANT] > **RLS tarifdən asılı deyil.** O, Community daxil olmaqla bütün tariflərdə eyni > işləyir. Lisenziya ekranında «Sətir səviyyəsində təhlükəsizlik» əlçatmaz kimi > görünürsə, bu həmin ekranın qeyri-dəqiqliyidir, verilənlər bazanızın vəziyyəti > deyil. ### RLS harada dərhal aktivdir, harada isə onu özünüz açmalısınız | Necə quraşdırmısınız | Quraşdırmadan sonra RLS | |---|---| | Standart quraşdırma, PostgreSQL-i quraşdırıcı qurur | **Aktivdir.** Məhdud rol və `AIHUMMER_DB_APP_URL` avtomatik yaradılır | | Öz və ya idarə olunan PostgreSQL (bazanın ünvanı əvvəlcədən verilib) | **Aktiv deyil.** Rolu və `AIHUMMER_DB_APP_URL` dəyərini operator yaradır | | İnzibatçı hüquqları olmadan quraşdırma (rootless) | **Aktiv deyil.** Eyni ilə | > [!WARNING] > **RLS-i «açıq» göstərib heç nəyi qorumayan iki səhv.** > **Birincisi:** `AIHUMMER_DB_APP_URL` cədvəllərin sahibini və ya superistifadəçini > göstərir — PostgreSQL belə rolları siyasətlərdən azad edir, şlüz isə RLS-i yenə də > aktiv kimi bildirir. Ayrıca məhdud roldan istifadə edin. **İkincisi:** öz > PostgreSQL-inizdə məhdud rol avtomatik olaraq proqnozlaşdırıla bilən parolla > yarana bilər — baza şəbəkədən əlçatan olmazdan əvvəl ona öz parolunuzu verin. ## Hər kirayəçiyə görə istiqamətləndirmə Sorğu daxilində tətbiq, tenant sahəsinə aid sorğuları işlətmədən əvvəl əlaqədə cari tenantı müəyyənləşdirir — anlayış baxımından `db.WithTenant`. Məhdudlaşdırılmış rolda RLS siyasətləri təyin olunduqda, hər bir oxu və yazma yalnız həmin kirayəçinin sətirləri ilə məhdudlaşır. Scope iş vahidi ilə bağlıdır, buna görə də eyni zamanda həyata keçirilən sorğular arasında yayılmır. ```text request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant ``` ## İşçilər üçün sistem / keçid rejimi Bəzi işlər qanuni olaraq tenantlar arasında və ya tenantdan asılı olmayan ola bilər — arxa plan işçiləri, cədvəlləndiricilər, çatdırılma bərpası və oxşar texniki xidmətlər. Bunlar üçün gateway istifadə edir **sistem (dolanmaq) rejimi** bu, sahiblər hovuzunda işləyir, hər kirayədarın RLS siyasətlərinin xaricində, beləliklə infrastruktur vəzifələri məlumat dəsti üzrə işləyə bilər. > [!WARNING] > Bypass rejimi yalnız etibarlı daxili işçilər üçündür. Sorğu işləmə kod yolları > istifadəçi adından hərəkət edən hər bir əməliyyat həmişə məhdudlaşdırılmış vasitəsilə keçirilməlidir, > icarəçi üzrə məhdudlaşdırılmış hovuz — heç vaxt keçid yolu deyil. ## Köçürmələr sahib hovuzunda işləyir Skema dəyişikliyi məhdudlaşdırılmış rolun sahib olmadığı üstünlükləri tələb edir, buna görə **miqrasiyalar həmişə sahib hovuzunda işləyir** (`AIHUMMER_DATABASE_URL`), məsləhətçi kilidi altında, işə salınma zamanı. Məhdudlaşdırılmış `aihummer_app` rol yalnız adi tətbiq trafiki üçün istifadə olunur. Bu üstünlük ayrı-seçkiliyini təmiz saxlayır: sxeməni dəyişdirən əməliyyatlar sahib tərəfindən istifadə olunur; tenant məlumatlarına giriş RLS tətbiq olunmuş məhdudlaşdırılmış rol tərəfindən istifadə olunur. ## Növbəti haradır - [Çoxtenantlilik və idempotentlik](/az/v1.0/architecture/multitenancy-idempotency) — tam kirayəçi modeli və yan təsirlərin bərpa zamanı necə təhlükəsiz qalması. - [Sirrlər anbarı](/az/v1.0/security/vault) — icarədar başına DEK-lər eyni şeyi gücləndirir gizli təbəqədə izolasiya. - [RBAC və sahələndirilmiş API açarları](/az/v1.0/security/rbac) — yuxarıda icazə məlumat təbəqəsi.