Պատվիրակված հասանելիություն
Ներգրավեք ծրագրավորողին, հանձնեք հաշվարկները հաշվապահին, տրամադրեք հաճախորդին իր սեփական կայքերը միայն կարդալու (read-only) հնարավորությամբ դիտելու հնարավորություն կամ թույլ տվեք մեր աջակցման թիմին ուսումնասիրել խնդիրը: Յուրաքանչյուր տրամադրված իրավունք որոշակի թույլտվություններով դեր է, որը սահմանափակված է կազմակերպությամբ, կիրառվում է տվյալների բազայում և գրանցվում է միայն ավելացման համար նախատեսված (append-only) աուդիտի մատյանում:
Մեկ մուտքանունով կիսվելն այն է, ինչը հանգեցնում է հաշվի հասանելիության հետ կապված խնդիրների: Zinn Digital®-ում յուրաքանչյուր անձ ունի իր սեփական նույնականացումը, և հասանելիությունը անդամակցություն է՝ օգտատեր, կազմակերպություն և դեր, որը կարող եք ինքնուրույն տրամադրել, փոխել կամ չեղարկել:
Յուրաքանչյուր աշխատակից մուտք է գործում իր անունից՝ Keycloak-ի՝ մեր նույնականացման շերտի միջոցով: Ոչ ոք չի մուտքագրում ձեր գաղտնաբառը, ոչ ոք չի օգտագործում դիտարկիչի ընդհանուր աշխատաշրջան, իսկ որևէ մեկին հեռացնելը կատարվում է մեկ գործողությամբ, այլ ոչ թե գաղտնաբառի փոփոխմամբ և այն բանի տենդագին պարզմամբ, թե ուրիշ ով գիտեր այն:
Հաշիվները հիերարխիկ են. վերավաճառողի կազմակերպությունը պարունակում է հաճախորդների կազմակերպություններ, իսկ հաճախորդների կազմակերպությունները՝ կայքեր: Անդամակցությունը վերաբերում է կազմակերպությանը և դրա տակ գտնվող ամեն ինչին, այնպես որ կարող եք գործակալության հաճախորդին տալ սեփական կազմակերպության նկատմամբ վերահսկողություն՝ երբեք չբացահայտելով ձեր մյուս հաճախորդներին:
Վարձակալների բաժանումը հավելվածի կոդի զտիչ չէ, որը սխալը կարող է շրջանցել: Postgres Row-Level Security-ն յուրաքանչյուր հարցում սահմանափակում է կանչողի կազմակերպության ենթածառով, ուստի ձեր շրջանակից դուրս հարցումը վերադարձնելու ոչինչ չունի:
Խնդրեք ձեր շրջանակից դուրս գտնվող կազմակերպություն կամ կայք, և API-ն թույլտվության սխալի փոխարեն կպատասխանի հասարակ «չի գտնվել» հաղորդագրությամբ: Թույլտվության սխալը կհաստատի գրառման գոյությունը, մինչդեռ «չի գտնվել»-ը դրսի մարդուն ոչինչ չի հայտնում:
Թույլտվությունները հատիկավոր բանալիներ են՝ մոդուլը գումարած գործողություն, ինչպես sites.restart-ը կամ billing.refund-ը, և դերերը միավորում են դրանք: Չորս դերերն ընդգրկում են իրական թիմերին անհրաժեշտ ձևերը, և դրանցից յուրաքանչյուրը մեր կողմից տեղադրվող տվյալ է, ոչ թե կոդում թաղված տրամաբանություն:
Լիարժեք վերահսկողություն. ստեղծել ենթակազմակերպություններ, հրավիրել և հեռացնել անդամների, փոխել դերերը, կառավարել API բանալիները, ստեղծել, վերագործարկել, մաքրել, կասեցնել և ջնջել կայքերը, կատարել վճարումներ և ստանալ հաշիվ-ապրանքագրեր, բացել տոմսեր և կարդալ աուդիտի մատյանը։ Դերը, որը դուք պահում եք ձեզ համար։
Տեսնում է կազմակերպությունը, նրա անդամներին և պլանների կատալոգը, ինչպես նաև կառավարում է հաշիվ-ապրանքագրերը, վճարման եղանակները և գանձումները: Ոչ մի հասանելիություն որևէ առանձին կայք ստեղծելու, փոփոխելու կամ ջնջելու համար. ճիշտ այնպես, ինչպես հարկավոր է արտաքին հաշվապահին:
Դիտում և ստեղծում է կայքեր, վերագործարկում է ծառայությունները, մաքրում է հիշողությունը (քեշը), կառավարում է API բանալիները և աշխատում տոմսերի հետ: Խնամքով բացառված են՝ հաշվետվությունները, հաշիվ-ապրանքագրերը, վճարման եղանակները, անդամների կառավարումը, կայքի կասեցումը և կայքի ջնջումը: Կապալառուն կարող է ստեղծել՝ առանց ձեզ հաշիվ ներկայացնելու կամ որևէ բան ոչնչացնելու հնարավորության:
Տեսնում է կազմակերպությունը, դրա անդամներին, կայքերը, հաշվարկային տվյալները, պլանների կատալոգը, տոմսերը, թարգմանության կարգավիճակը և աուդիտի մատյանը, սակայն ոչինչ փոխել չի կարող։ Հիանալի իրավունք այն հաճախորդի համար, ով ցանկանում է տեսանելիություն, աուդիտորի կամ շահագրգիռ կողմի համար, որը միայն դիտելու կարիք ունի։
Մուտքի լիազորումն անվտանգ է միայն այն դեպքում, եթե այն հաշիվները, որոնց տրամադրում եք լիազորությունը, դժվար է կոտրել: Նույնականացումն իրականացվում է Keycloak-ի միջոցով հաշվի վրայի յուրաքանչյուր անձի և յուրաքանչյուր միջավայրի համար:
Աջակցման աշխատանքը երեմն նշանակում է նայել ձեր հաշվի ներսը: Այդ հասանելիությունը կարգավորվում է նույն թույլտվությունների մոդելով, ինչ մնացած ամեն ինչ. աշխատակիցները պարզապես գտնվում են աշխատակազմի կազմակերպությունում, որոնք բաշխված են նեղ լիազորություններով բաժինների միջև:
Աշխատակիցները խմբավորված են հետևյալ կատեգորիաներում՝ Աջակցություն, Հաշվպահություն և Ֆինանսներ, Աբուզ և Վստահություն ու Անվտանգություն, Վաճառք, Ներդրում, Ճարտարագիտություն և Գործառնություններ, Մարքեթինգ և Ղեկավարություն: Յուրաքանչյուր դեր տրամադրում է որոշակի մոդուլներ և գործողություններ, որպեսզի գործակալը տեսնի ադմինիստրատորի վահանակի միայն այն մասը, որն անհրաժեշտ է իր աշխատանքի համար, և ոչ թե մնացածը:
Աջակցության գործակալի դերը տրամադրում է հենց սա՝ դիտել հաճախորդներին, դիտել և պատասխանել տոմսերին, դիտել կայքերը, վերագործարկել կայքը և մաքրել դրա շտեմարանը: Այն չի ներառում վճարումների կարգավորում, գումարի վերադարձ, պլանի խմբագրում և պարկի կառավարում: Ուղղման գործողությունները, որոնք գործակալը կարող է կատարել, սահմանափակված են դերով, այլ ոչ թե բարի մտադրություններով:
Customer.impersonate իրավունքը Manager դերի մաս այն չէ. այն պատկանում է միայն Super Admin-ին: Երբ ձեր անունից աշխատում է սեանս, վահանակն ունի մշտական օգտատիրոջ ներկայացման (impersonation) վահանակ, որպեսզի երբեք անորոշություն չլինի, թե ով է գործում:
Արտոնյալ և վարչական յուրաքանչյուր գործողություն գրանցվում է միայն ավելացման համար նախատեսված աուդիտի մատյանում, որը արձանագրում է գործողություն կատարողին, գործողությունը, թիրախը, հարակից մետատվյալները, IP հասցեն և ժամնիշը (production միջավայրում՝ ժամանակով բաժանված): Սեփականատերերը և միայն կարդալու իրավունքով անդամները կարող են իրենց կազմակերպության մատյանը կարդալ ինքնուրույն:
Անձնակազմի զգայուն և վնասակար գործողությունները կարող են պահանջել լրացուցիչ նույնականացում կամ երկու անձի հաստատում մինչև դրանց իրականացումը, իսկ նոր բաժիններն ու դերերը կազմաձևման արդյունք են, այլ ոչ թե կոդի փոփոխություն:
Սկրիպտները, CI փայփլայնները, CLI-ն, Terraform պրովայդերը և AI գործակալները նույնպես վավերացվում են թույլտվությունների միևնույն մոդելի միջոցով, ինչ մարդիկ. ոչ մի ընդհանուր մարդկային հավատարմագրեր, ոչ մի երկարակյաց գաղտնիքներ՝ տեղադրված կառուցման (build) մեջ:
Բանալիները պատկանում են կազմակերպությանը և ունեն նույն RBAC թույլտվություններին կապված հատկորոշման մակարդակներ՝ միայն ընթերցման, վճարման և մատակարարման: Խողովակաշարին տրամադրեք դրան անհրաժեշտ նեղ շրջանակ՝ անդամի ամբողջ հաշվի փոխարեն:
Թեստային ռեժիմի և աշխատանքային ռեժիմի բանալիները տարբեր են, հետևաբար մշակման փուլում գտնվող ինտեգրացիան չի կարող պատահմամբ կամ պատճենված միջավայրի փոփոխականի միջոցով մուտք գործել արտադրական տվյալներ:
Մենք պահպանում ենք գաղտնիքի SHA-256 հեշը և որոնման նախածանցը՝ երբեք հում բանալին: Դուք տեսնում եք բանալին միայն մեկ անգամ՝ ստեղծման պահին: Յուրաքանչյուր բանալի հետևում է, թե երբ է այն վերջին անգամ օգտագործվել, և կարող է հետ կանչվել առանձին՝ առանց որևէ այլ բան խախտելու:
Մեր MCP սերվերը թույլ է տալիս MCP ունակությամբ ցանկացած ագենտի կառավարել ձեր հոսթինգը բնական լեզվով, որն վավերացված է OAuth 2.1-ով և սահմանափակված է ձեր կազմակերպությամբ ու RBAC դերով, ունի ըստ գործիքի չեղարկվող թոքեններ, հաստատում կործանարար գործողությունների դեպքում, ծախսերի առավելագույն սահմանաչափեր և աուդիտի ամբողջական գրանցում:
Հաշվի հասանելիությունը և սերվերի հասանելիությունը տարբեր խնդիրներ են: Կայքի մակարդակի մուտքի տվյալները կառավարվում են կառավարման վահանակում, տրամադրվում են նվազագույն արտոնությունների սկզբունքով և մեկուսացվում են, որպեսզի մեկ աշխատակցի shell-ը լինի միայն մեկ կայքի shell:
Մենակատար օպերատորը պահպանում է մեկ կազմակերպություն և մեկ սեփականատիրոջ անդամակցություն, և ավելացնում է «Մշակող» (Developer) դեր, երբ կապալառուն միանում է նախագծին: Երբ նախագծին ավարտվում է, անդամակցությունը հեռացվում է, և նրա մուտքն անմիջապես դադարում է աշխատել․ չկա որևէ ընդհանուր հավատարմագիր, որը պետք է փոխվի:
Գործակալությունն օգտագործում է կազմակերպության ծառը: Յուրաքանչյուր հաճախորդ ստանում է սեփական դուստր կազմակերպությունը, որը պարունակում է այդ հաճախորդի կայքերը, և հաճախորդի սեփական անձնակազմն ստանում է անդամակցություններ այնտեղ՝ միայն կարդալու իրավունքով շահագրգիռ կողմի համար, ով ցանկանում է տեսանելիություն, և սեփականատիրոջ իրավունքով՝ ինքնասպասարկում ցանկացող հաճախորդի համար: Ձեր աշխատակիցներն անդամակցություններ ունեն ծառի ավելի բարձր մակարդակներում և տեսնում են պորտֆոլիոն. հաճախորդը տեսնում է միայն սեփական ճյուղը, և հենց տողային մակարդակի անվտանգությունն է (Row-Level Security) դա դարձնում իրականություն, այլ ոչ թե պարզապես խոստում:
Վերավաճառողն աշխատում է նույն կերպ, մեկ մակարդակով ավելի բարձր. վերավաճառող կազմակերպությունն իր մեջ ներառում է հաճախորդ կազմակերպություններ, որոնցից յուրաքանչյուրն ունի իր անդամները, վճարային տեսքը և կայքերը: Նույն հիմնական մեխանիզմն ապահովում է ենթահաշիվների, գործակալության թիմերի և վերավաճառողների հիերարխիաների աշխատանքը. դրանցից որևէ մեկի համար չկա առանձին, ավելի թույլ մեխանիզմ:
Ամեն ինչ հասանելի է առանց քարտի տվյալների 14-օրյա փորձաշրջանում: Գրանցվեք առանց վճարման մանրամասների, հրավիրեք գործընկերոջ, տեսեք, թե ինչին կարող է հասնել յուրաքանչյուր դեր և ինչին՝ ոչ, և ստուգեք ձեր սեփական աուդիտի մատյանը:
Այսօր անդամակցությունը տրամադրում է իր դերը ամբողջ կազմակերպությունում և դրա տակ գտնվող ամեն ինչում, ուստի կայքերի հավաքածուները առանձնացնելու միջոցը կազմակերպությունների առանձնացումն է. տեղադրեք այդ կայքերը իրենց սեփական ենթակազմակերպությունում և տրամադրեք անդամակցությունն այնտեղ: Սա մաքուր մոդել է գործակալությունների և վերավաճառողների համար, որտեղ յուրաքանչյուր հաճախորդ արդեն ցանկանում է ունենալ սեփական սահմանը: Յուրաքանչյուր անդամակցության համար ռեսուրսների սահմանափակումը, մեկ անդամակցության ամրացումը մեկ կազմակերպության ներսում գտնվող որոշակի կայքերին, նախատեսված բարելավում է, այլ ոչ թե ներկայումս հասանելի մի բան:
Developer դերը չի ներառում կայքի ջնջում կամ կայքի կասեցում. այդ իրավունքները պատկանում են Owner դերին: Այն տրամադրում է կայքեր դիտելու և ստեղծելու, ծառայությունները վերագործարկելու, քեշը մաքրելու, API բանալիները կառավարելու և տոմսերի հետ աշխատելու հնարավորություն: Տեղադրման և ուղիղ եթերում գործարկման թույլտվությունները նույնպես Developer արտոնության մաս չեն կազմում, ուստի արտադրական միջավայր հրելը մնում է հաշվի սեփականատիրոջը: Համադրեք դա staging-ի հետ, որպեսզի կառուցման աշխատանքները սկզբում կատարվեն ուղիղ կայքիցդուրս:
Այն կախված է անձնակազմի դերից, և յուրաքանչյուր դեր իրավասությունների բանալիների նեղ հավաքածու է: Աջակցման գործակալը, օրինակ, կարող է դիտել ձեր հաշիվը և կայքերը, դիտել և պատասխանել ձեր տոմսերին, վերագործարկել կայքը և մաքրել դրա շտեմարանը և չի կարող դիպչել վճարումների կարգավորումներին, գումարների վերադարձին, պլաններին կամ ֆլիթին: Որպես հաճախորդ մուտք գործելը առանձին թույլտվություն է, որը պատկանում է միայն Սուպեր Ադմինին, և երբ դա տեղի է ունենում, վահանակում ցուցադրվում է այլ անձի անունից հանդես գալու մշտական պաստառ: Յուրաքանչյուր արտոնյալ գործողություն գրանցվում է աուդիտի մատյանում՝ գործող անձի, գործողության, թիրախի, IP-ի և ժամնիշի հետ միասին, և դուք կարող եք ինքներդ կարդալ ձեր կազմակերպության մատյանը:
Հեռացրեք անդամության կարգավիճակը, և տվյալ կազմակերպությունում նրանց հասանելիությունը կավարտվի. նրանք դեռ կպահպանեն իրենց անհատական հաշիվը, սակայն ձեր հաշվում չեն ունենա որևէ դեր և, հետևաբար, որևէ թույլտվություն: API բանալիները չեղարկվում են անհատապես, ուստի pipeline-ի բանալին կարող է անջատվել՝ առանց մնացած որևէ բանի խանգարելու: Եթե օգտագործում եք SAML միասնական մուտքի համակարգ (SSO), ապա ձեր ինքնության մատակարարում (identity provider) ապաակտիվացումը կենտրոնացված կերպով կարգավորում է մուտքը: Կայքի մակարդակի հավատարմագրերը, ինչպիսիք են SSH բանալիները, չեղարկվում են կառավարման վահանակում, ხოლო հեռացման փաստն ինքնին գրանցվում է աուդիտի մատյանում:
Ոչ, բայց հարկավոր է հստակեցնել, թե ինչու։ API բանալիները պատկանում են կազմակերպությանը, այլ ոչ թե առանձին անդամի, և դրանք ունեն իրենց սեփական մանր հատկորոշված հասանելիության շրջանակները, որոնք կապված են նույն թույլտվությունների կատալոգի հետ: Այնպես որ, անձին բանալի տրամադրելու փոխարեն՝ դուք ստեղծում եք բանալի կատարվող աշխատանքի համար՝ ամենանեղ շրջանակով, որն անհրաժեշտ է այդ աշխատանքին, և չեղարկում եք այդ բանալին, երբ աշխատանքն ավարտվում է։ Պահպանվում է միայն գաղտնիքի հեշը, և յուրաքանչյուր բանալի գրանցում է վերջին օգտագործման պահը, որպեսզի չօգտագործվող բանալիները հեշտությամբ գտնվեն և հեռացվեն։
Այո՛։ Մեր MCP սերվերը նույնականացնում է գործակալներին OAuth 2.1-ի միջոցով և դրանց թույլտվությունները սահմանափակում ձեր կազմակերպությամբ ու RBAC դերով՝ յուրաքանչյուր գործիքի համար հետկանչելի թոքեններով, ինչի շնորհիվ դուք տրամադրում եք կոնկրետ հնարավորություն, այլ ոչ թե համընդհանուր հասանելիություն: Կործանարար գործողությունները պահանջում են հաստատում, գործում են ծախսերի սահմանաչափեր, և յուրաքանչյուր գործողություն գրանցվում է նույն աուդիտի մատյանում, ինչ մարդու կատարած գործունեությունը:
Postgres-ի տողի մակարդակի անվտանգությունը (Row-Level Security) հարցումների շրջանակը սահմանափակում է կանչողի կազմակերպության ենթածառով հենց տվյալների բազայում՝ հավելվածի մակարդակի ֆիլտրն օգտագործելով որպես խորացված պաշտպանություն, այլ ոչ թե միակ պաշտպանական գիծ: Տիրույթից դուրս գտնվող գրանցումների հարցումները թույլտվության սխալի փոխարեն վերադարձնում են «չի գտնվել» հաղորդագրությունը, որպեսզի ոչինչ չբացահայտվի գոյություն ունեցող տվյալների մասին: Սերվերի կողմում CageFS-ի միջոցով ըստ կայքերի մեկուսացումը պահպանում է յուրաքանչյուր վարձակալի shell-ը և ֆայլերը իրենց սեփական կայքում:
Այո։ 14-օրյա փորձաշրջանն առանց քարտի է՝ առանց վճարային տվյալների, առանց պարտավորության, և ներառում է Footprint-Free Hosting-ը՝ մինչև հինգ կայքով: Այն բավական է գործընկերոջը հրավիրելու, դեր նշանակելու և մինչև վճարելը ստուգելու համար, որ սահմանափակումներն աշխատում են այնպես, ինչպես ձեզ անհրաժեշտ է:
Սկսեք առանց քարտի պահանջի 14-օրյա փորձաշրջանը, հրավիրեք որևէ մեկին և հետևեք, թե ինչպես է թույլտվությունների մոդելն անում իր գործը. դերեր, որոնք կարող եք անվանափոխել, տիրույթներ, որոնք կարող եք չեղարկել, և աուդիտի մատյան, որը հստակ ցույց է տալիս, թե ով ինչ է արել:
Սկսեք անվճար