Ապահովություն տողերի մակարդակով

# /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-ը բազմապրոֆիլ է, և նրա ամենաուժեղ մեկուսացման սահմանը գտնվում է հենց տվյալների բազայում: **Անվտանգություն մեջպետային մակարդակով PostgreSQL-ում (RLS)**. RLS-ով միացված տվյալների բազան՝ ոչ միայն հավելվածի կոդը, ապահովում է, որ հարցումը տեսնի միայն այն տողերը, որոնք պատկանում են ընթացիկ վարձակալին. **Շերտ։** Անվտանգությունը տպագրության մակարդակով սահմանափակված է վճարովի տարբերակով **ԱԿԸ** մակարդակը — դա անվճար/հասարակության հարթակին պատկանող մաս չի։ ## Ինչու՞ RLS Ֆիլտրման գործընթացը ծրագրավորման մակարդակում (`WHERE tenant_id = ...`) անհրաժեշտ է, բայց խոցելի. մեկ մոռացված կետը կարող է հանգեցնել տվյալների լ Leakage-ի վարձակալների միջև: RLS-ը փոխանցում է երաշխիքն PostgreSQL-ին, այնպես որ նույնիսկ ֆիլտր չարվող հարցումը վերադարձնում է միայն ընթացիկ վարձակալին պատկանող տողերը: Սա գործարկման շերտի մակարդակից ներքև խորքային պաշտպանություն: Բազմօգտագործող միջավայրի ավելի լայն մոդելի համար՝ և ինչպես այն համատեղվում է իդեմպոտենտ կողմնակի ազդեցությունների հետ՝ ծանուցման համար տես. [Բազմօգտագործողական ռեժիմ և idemպոտենտություն](/hy/v1.0/architecture/multitenancy-idempotency). ## Սահմանափակ դեր (համաձայն ցանկության) RLS դա **գնորդի ցանկությամբ անդամակցություն** և ակտիվացվում է, երբ գեյթքեյվին տրամադրում են երկրորդ տվյալների շտեմարանի համակցում, որը օգտագործում է *սահմանափակ* դեր, այլ ոչ թե սեփականատեր՝ ```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 ``` Այս `aihummer_app` պատվերի է **ոչ** որկե նշվում է աղյուսակի սեփականատերը, այնպես որ PostgreSQL-ը RLS քաղաքականություններ է կիրառում դրա վրա: Դիմումի հարցումները անցնում են այս սահմանափակված լճակի միջոցով: RLS-ն հնարավորություն տալը նշանակում է որոշել **`AIHUMMER_DB_APP_URL`** — և **տեղային/համակարգային (հյուրընկալ-մանրէական) տեղադրումները ավտոմատ կերպով կարգավորում են այդ փոփոխականը**, այնպես որ RLS-ը ակտիվ է անմիջապես տեղադրումից հետո։ Այն «ընտրովի» է միայն այն իմաստով, որ օգտագործողը կամ ձեռքով տեղադրումը պետք է այն ակտիվացնի `AIHUMMER_DB_APP_URL` ինքնուրույն > [!NOTE] > առանց `AIHUMMER_DB_APP_URL`, անցակետը օգտագործում է սեփականատերերի հավաքածուն ամեն ինչի համար > և RLS-ն գրեթե չի գործադրվում։ Կարգավորեք սահմանափակված պուլը (որը > պետական տեղադրողը դա անում է ձեր փոխարեն) ներառել տվյալների բազայի մակարդակում izolյացիա։ > [!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 քաղաքականության կիրառման ոլորտը սահմանելուց հետո սահմանափակ դերի համար սահմանափակվում է այդ վարձակալության յուրաքանչյուր տողի ընթերցումն ու գրությունը: Կիրառման ոլորտը կապված է աշխատանքային միավորի հետ, այն չի տարածվում զուգահեռ հարցումների մեջ: ```text request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant ``` ## Համակարգային / շրջանցող ռեժիմ աշխատողների համար Բացարձակապես որոշ աշխատանքներ նորմալ կերպով կարող են լինել համատեղելի տարբեր վարձակալների հետ կամ վարձակալության ամենաուղղվածությունը չպահանջող — ֆոնային աշխատողներ, ժամանակացույց կարգավորողներ, առաքման վերականգնում և նման պահպանման աշխատանքներ։ Հենց դրանց համար, շեմը օգտագործում է **համակարգային (կողմնակի) ռեժիմ** որը աշխատում է տիրոջ պուլում, յուրաքանչյուր վարձակալի համար RLS քաղաքականություններից դուրս, այնպես որ ենթակառուցվածքային առաջադրանքները կարող են աշխատել տվյալների ամբողջ հավաքածուով։ > [!WARNING] > Դիմումների շրջանցման ռեժիմը նախատեսված է միայն վստահելի ներքին աշխատակազմի համար։ Հարցումների մշակման ուղիներ > Օգտատիրոջ անունից գործողությունը միշտ պետք է կատարվի սահմանափակ պրոցեսի միջոցով, > Ծպտվածությունը վարձույթ վերցնողի գործողության տիրույթով երբեք չի հանդիսանում շրջանցման ճանապարհ։ ## Միգրացիաներն իրականացվում են սեփականատիրոջ պուլում Սքեմայի փոփոխությունները պահանջում են արտոնություններ, որոնք սահմանափակ դերակատարի համար չկա, այդ պատճառով **Միգրացիաները միշտ կատարվում են տիրոջ պուլում** (`AIHUMMER_DATABASE_URL`), խորհուրդ տվող ապակեպատ զանգվածով, գործարկման ժամանակ. Սահմանափակ `aihummer_app` պաշտոնը օգտագործվում է միայն սովորական կիրառական տրաֆիկի համար։ Սա պահպանում է լիազորությունների զտվածության մաքրությունը՝ սխեմայի փոփոխության գործողությունները կատարվում են սեփականատիրոջ միջոցով, իսկ վարձատուի տվյալների հասանելիությունը իրականացվում է սահմանափակեցված դերակատարությամբ՝ RLS կիրառելով։ ## Որտեղից հետո - [Բազմօգտագործողական ռեժիմ և idemպոտենտություն](/hy/v1.0/architecture/multitenancy-idempotency) — վարձառուի ամբողջական մոդելը և այն, թե ինչպես են կողմնակի ազդեցությունները մնալ անվտանգ վերականգնման ժամանակ։ - [Գաղտնիքների պահոց](/hy/v1.0/security/vault) — DEK-ի համար յուրաքանչյուր վարձակալ ուժեղացնում է նույնը մեկուսացում գաղտնիքների շերտի վրա։ - [RBAC և սահմանափակ API-կոճակներ](/hy/v1.0/security/rbac) — օգտագրման մակարդակը բարձր է տվյալների շերտ