Տողի-մակարդակի անվտանգություն
AiHummer-ը բազմավարձակալ է, և նրա ամենաուժեղ մեկուսացման սահմանը ապրում է հենց տվյալների բազայում. PostgreSQL Row-Level Security (RLS)։ RLS-ի միացված վիճակում տվյալների բազան — ոչ միայն հավելվածի կոդը — պարտադրում է, որ հարցումը երբևէ տեսնի միայն ընթացիկ վարձակալին պատկանող տողերը։
Ինչու RLS
Հավելվածի-մակարդակի զտումը (WHERE tenant_id = ...) անհրաժեշտ է, բայց փխրուն. մեկ
մոռացված դրույթը կարող է տվյալներ արտահոսեցնել վարձակալների միջև։ RLS-ը երաշխիքը
տեղափոխում է PostgreSQL, որպեսզի նույնիսկ չզտված հարցումը վերադարձնի միայն ընթացիկ
վարձակալի տողերը։ Սա խորությամբ-պաշտպանության շերտ է հավելվածի սեփական շրջանակման
տակ։ Ավելի լայն բազմավարձակալության մոդելի համար — և թե ինչպես է այն զուգակցվում
իդեմպոտենտ կողմնակի էֆեկտների հետ — տես
Բազմավարձակալություն և իդեմպոտենտություն։
Սահմանափակ դերը (ընտրովի)
RLS-ն ընտրովի է և ակտիվանում է 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/aihummeraihummer_app դերը չէ աղյուսակի սեփականատերը, այնպես որ PostgreSQL-ն այս
դերին կիրառում է RLS քաղաքականություններ։ Հավելվածի հարցումները հոսում են այս
սահմանափակ pool-ի միջով։ Հոսթ-բնիկ տեղադրումների համար տեղադրիչն ավտոմատ կերպով
միացնում է AIHUMMER_DB_APP_URL-ը։
[!NOTE] Առանց
AIHUMMER_DB_APP_URL-ի, gateway-ն օգտագործում է owner pool-ը ամեն ինչի համար, և RLS-ն փաստացի չի պարտադրվում։ Սահմանեք սահմանափակ pool-ը՝ տվյալների բազայի-մակարդակի մեկուսացումը միացնելու համար։
Ըստ-վարձակալի շրջանակում
Հարցման ներսում, հավելվածը կապի վրա հաստատում է ընթացիկ վարձակալին նախքան
վարձակալ-շրջանակված հարցումներ կատարելը — հայեցակարգորեն db.WithTenant։ Շրջանակվելուց
հետո սահմանափակ դերի վրա RLS քաղաքականությունները սահմանափակում են յուրաքանչյուր
կարդալ ու գրել այդ վարձակալի տողերով։ Շրջանակը կապված է աշխատանքի միավորին,
այնպես որ այն չի արտահոսում զուգահեռ հարցումների միջև։
request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenantՀամակարգային / շրջանցման ռեժիմ աշխատողների համար
Որոշ աշխատանք օրինաչափորեն խաչ-վարձակալ կամ վարձակալ-անկախ է — ֆոնային աշխատողներ, ժամանակացույցողներ, outbox-ը և նմանատիպ մեխանիզմ։ Սրանց համար gateway-ն օգտագործում է համակարգային (շրջանցման) ռեժիմ, որն աշխատում է owner pool-ի վրա, ըստ-վարձակալի RLS քաղաքականություններից դուրս, որպեսզի ենթակառուցվածքային առաջադրանքները կարողանան գործել տվյալների ամբողջ հավաքածուի միջով։
[!WARNING] Շրջանցման ռեժիմը միայն վստահելի ներքին աշխատողների համար է։ Հարցում-մշակող կոդի ուղիները, որ գործում են օգտատիրոջ անունից, պետք է միշտ անցնեն սահմանափակ, վարձակալ-շրջանակված pool-ի միջով — երբեք շրջանցման ուղով։
Միգրացիաներն աշխատում են owner pool-ի վրա
Սխեմայի փոփոխությունները պահանջում են արտոնություններ, որ սահմանափակ դերը չունի,
այնպես որ միգրացիաները միշտ աշխատում են owner pool-ի վրա (AIHUMMER_DATABASE_URL),
խորհրդատվական կողպեքի ներքո, գործարկման ժամանակ։ Սահմանափակ aihummer_app դերն
օգտագործվում է միայն սովորական հավելվածի թրաֆիկի համար։ Սա պահում է արտոնության
բաժանումը մաքուր. սխեմա-փոխող գործողություններն օգտագործում են սեփականատիրոջը,
վարձակալի տվյալների հասանելիությունն օգտագործում է սահմանափակ դերը՝ կիրառված
RLS-ով։
Ուր հաջորդ
- Բազմավարձակալություն և իդեմպոտենտություն — ամբողջական վարձակալի մոդելը և թե ինչպես են կողմնակի էֆեկտները մնում անվտանգ վերականգնման ժամանակ։
- Գաղտնիքների պահոց — ըստ-վարձակալի DEK-երն ուժեղացնում են նույն մեկուսացումը գաղտնիքների շերտում։
- RBAC և շրջանակված API բանալիներ — իրավասություն տվյալների շերտից վեր։