Delegadong Pag-access
Magpasok ng developer, ipagkatiwala ang pagsingil sa iyong accountant, bigyan ang kliyente ng read-only na access sa kanilang sariling mga site, o hayaang tingnan ng aming support team ang isang problema. Ang bawat pagbibigay ay isang tungkulin na may mga tinukoy na pahintulot, nakatutok sa isang organisasyon, ipinapatupad sa database, at nakasulat sa isang append-only na audit log.
Ang paggamit ng iisang login ang simula ng problema sa pag-access sa account. Sa Zinn Digital® ang bawat tao ay may sariling pagkakakilanlan, at ang pag-access ay isang membership — isang user, isang organisasyon, at isang role — na maaari mong ibigay, baguhin, o bawiin nang hiwalay.
Ang bawat collaborator ay nag-sign in gamit ang sarili nilang account sa pamamagitan ng Keycloak, ang aming identity layer. Walang nagta-type ng password mo, walang nagbabahagi ng browser session, at ang pag-alis sa isang tao ay isang aksyon lamang sa halip na pagpapalit ng password at pag-aalala kung sino pa ang nakakaalam nito.
Ang mga account ay hirarkikal — ang isang organisasyon ng reseller ay naglalaman ng mga organisasyon ng kliyente, at ang mga organisasyon ng kliyente ay naglalaman ng mga site. Ang membership ay nalalapat sa isang organisasyon at sa lahat ng nakapaloob dito, kaya maaari mong ibigay sa isang kliyente ng ahensya ang kontrol sa kanilang sariling organisasyon nang hindi kailanman inilalantad ang iyong iba pang mga kliyente.
Ang paghihiwalay ng tenant ay hindi isang filter sa application code na maaaring laktawan ng isang bug. Sakop ng Postgres Row-Level Security ang bawat query sa organizational subtree ng tumatawag, kaya walang maibabalik ang isang kahilingan na nasa labas ng iyong saklaw.
Humiling ng organisasyon o site na wala sa iyong saklaw at ang API ay tutugon ng plain not-found sa halip na permission error. Ang permission error ay magpapatunay na umiiral ang rekord; ang not-found ay walang sinasabi sa isang tagalabas.
Ang mga pahintulot ay mga granular key — module at aksyon, tulad ng sites.restart o billing.refund — at ang mga tungkulin ang nag-uugnay sa mga ito. Sinasaklaw ng apat na tungkulin ang mga hugis na kailangan ng mga totoong team, at ang bawat isa ay data na nilalagay namin, hindi logic na nakatago sa code.
Buong kontrol: lumikha ng mga organisasyong pambata, mag-imbita at mag-alis ng mga miyembro, magbago ng mga papel, mamahala ng mga API key, lumikha, mag-restart, mag-purge, mag-suspend at mag-delete ng mga site, magpatakbo ng billing at mga invoice, magtaasa ng mga tiket at magbasa ng log ng audit. Ang papel na itinatago mo para sa iyong sarili.
Nakikita ang organisasyon, ang mga miyembro nito at ang katalogo ng plano, at pinamamahalaan ang mga invoice, paraan ng pagbabayad at mga singil. Walang access para gumawa, magbago o mag-delete ng kahit isang site — eksaktong angkop para sa isang panlabas na bookkeeper.
Tumitingin at gumagawa ng mga site, nag-a-restart ng mga serbisyo, naglilinis ng cache, nag-aayos ng mga API key, at tumutugon sa mga tiket. Sadyang hindi kasama: pagsingil, mga invoice, mga paraan ng pagbabayad, pamamahala ng miyembro, pagsuspinde ng site, at pagtanggal ng site. Ang isang kontratista ay makakapag-build nang hindi ka masisingil o masisira ang anuman.
Nakikita ang organisasyon, ang mga miyembro nito, ang mga site nito, ang pagsingil nito, ang katalogo ng plano, ang mga tiket, ang estado ng pagsasalin at ang log ng audit — at walang mababago sa mga ito. Ang tamang pahintulot para sa isang kliyente na gustong magkaroon ng visibility, isang auditor, o isang stakeholder na kailangan lang tumingin.
Ang pagpapasa ng access ay ligtas lamang kung ang mga account na pinagpapasahan mo ay mahirap agawin. Dumadaan sa Keycloak ang pag-authenticate para sa bawat tao sa account, sa bawat surface.
Kung minsan, ang trabaho sa suporta ay nangangahulugang pagsusuri sa loob ng iyong account. Ang access na iyon ay pinamamahalaan ng parehong modelo ng pahintulot tulad ng iba pa — ang mga tauhan ay nakaupo lamang sa isang organisasyon ng tauhan, na nakaayos sa mga departamento na may makitid na mga pahintulot.
Ang mga tauhan ay naka-grupo sa Support, Billing and Finance, Abuse and Trust-and-Safety, Sales, Onboarding, Engineering and Ops, Marketing, at Management. Ang bawat tungkulin ay nagbibigay ng mga partikular na module at aksyon, kaya nakikita ng isang ahente ang bahagi ng admin console na kinakailangan ng kanilang trabaho at hindi ang iba.
Ang tungkulin ng Support Agent ay nagbibigay ng eksaktong ito: pagtingin sa mga customer, pagtingin at pagsagot sa mga tiket, pagtingin sa mga site, pag-restart ng site, at pag-purge ng cache nito. Wala itong kasamang pagsasaayos ng billing, mga refund, pag-edit ng plan, at pamamahala ng fleet. Ang lunas na maaaring isagawa ng isang ahente ay nakatakda sa tungkulin, at hindi sa mabuting layunin.
Ang pahintulot na customer.impersonate ay hindi bahagi ng tungkulin ng Manager — hawak ito ng Super Admin lamang. Kapag tumatakbo ang isang sesyon sa ngalan mo, nagdadala ang dashboard ng patuloy na banner ng pagpapanggap upang hindi kailanman maging malabo kung sino ang kumikilos.
Ang bawat may pribilehiyo at administratibong aksyon ay idinaragdag sa isang append-only na audit log na nagtatala sa aktor, aksyon, target, sumusuportang metadata, IP address, at timestamp — na nakabahagi sa oras (time-partitioned) sa produksyon. Ang mga may-ari at read-only na miyembro ay maaaring magbasa mismo ng log ng kanilang organisasyon.
Ang mga sensitibo at mapaminsalang aksyon ng staff ay maaaring mangailangan ng step-up authentication o pag-apruba ng dalawang tao bago ito isagawa, at ang mga bagong departamento at tungkulin ay configuration sa halip na pagbabago sa code.
Ang mga script, CI pipeline, CLI, Terraform provider, at AI agent ay nag-a-authenticate sa pamamagitan ng parehong modelo ng pahintulot tulad ng sa mga tao — walang ibinahaging kredensyal ng tao, walang pangmatagalang lihim na naka-paste sa isang build.
Ang mga susi ay nabibilang sa isang organisasyon at may mga tiyak na saklaw na nakaugnay sa parehong mga pahintulot ng RBAC — read-only, billing, provisioning. Bigyan ang isang pipeline ng limitadong saklaw na kailangan nito sa halip na ang buong account ng isang miyembro.
Magkaiba ang mga key ng test-mode at live-mode, kaya ang isang integration na ginagawa pa lamang ay hindi makakapasok sa production data nang hindi sinasadya o sa pamamagitan ng nakopyang environment variable.
Nag-iimbak kami ng SHA-256 hash ng sikreto at isang lookup prefix — hindi kailanman ang raw key. Makikita mo ang isang key nang isang beses sa paglikha. Sinusubaybayan ng bawat key kung kailan ito huling ginamit at maaari itong bawiin nang mag-isa nang hindi naaistorbo ang iba pa.
Binibigyang-daan ng aming MCP server ang anumang MCP-capable agent na pamahalaan ang iyong hosting sa pamamagitan ng natural na wika, na may awtentikasyon sa pamamagitan ng OAuth 2.1 at naka-scope sa iyong organisasyon at RBAC role, kasama ang mga per-tool na puwedeng bawiing token, kumpirmasyon sa mga mapanirang aksyon, mga cap sa gastusin, at buong audit logging.
Magkaibang problema ang pag-access sa account at pag-access sa server. Ang mga kredensyal sa antas ng site ay pinamamahalaan sa dashboard, ibinibigay nang may pinakamababang pribilehiyo, at nakakulong upang ang shell ng isang collaborator ay shell din ng isang site.
Ang isang solong operator ay nagpapanatili ng iisang organisasyon at isang membership ng may-ari, at nagdaragdag ng tungkulin na Developer kapag pumasok ang isang kontratista para sa isang proyekto. Kapag nagtapos ang proyekto, tinatanggal ang membership at agad na tumitigil sa paggana ang kanilang pag-sign-in — walang natitirang nakabahaging kredensyal na kailangang palitan.
Gumagamit ang isang ahensya ng punong organisasyon. Ang bawat kliyente ay nakakakuha ng sarili nitong child organisation, na naglalaman ng mga site ng kliyenteng iyon, at ang sariling mga tao ng kliyente ay nakakakuha ng mga membership doon — read-only para sa isang stakeholder na gustong magkaroon ng visibility, owner para sa isang kliyente na gustong mag-self-serve. Ang iyong mga staff ay may mga membership sa itaas ng puno at nakikita ang portfolio; ang kliyente ay nakikita lamang ang kanilang sariling sangay, at Row-Level Security ang nagiging dahilan para maging totoo iyon sa halip na isang pangako lamang.
Gayundin ang takbo ng isang reseller, isang antas pataas: ang isang organisasyon ng reseller ay nagtataglay ng mga organisasyon ng kliyente, na bawat isa ay may sariling mga miyembro, view ng pagsingil, at mga site. Ang parehong pangunahing kapangyarihan ang sumusuporta sa mga sub-account, mga koponan ng ahensya, at mga hierarchy ng reseller — walang hiwalay at mas mahinang mekanismo para sa alinman sa kanila.
Available ang lahat sa libreng 14-araw na pagsubok. Mag-sign up nang walang detalye sa pagbabayad, mag-imbita ng kasamahan, tingnan kung ano ang maaari at hindi maabot ng bawat tungkulin, at basahin muli ang sarili mong audit log.
Sa kasalukuyan, ang isang membership ay nagbibigay ng papel nito sa buong organisasyon at sa lahat ng nasa ilalim nito sa hierarchy, kaya ang paraan para paghiwalayin ang mga set ng site ay ang paghiwalayin ang mga organisasyon — ilagay ang mga site na iyon sa kanilang sariling child organisation at doon ibigay ang membership. Ito ay isang malinis na modelo para sa mga ahensya at reseller, kung saan ang bawat kliyente ay gusto na ng kanilang sariling hangganan. Ang per-membership resource scoping, na naglalagay ng iisang membership sa mga tinukoy na site sa loob ng isang organisasyon, ay isang planong pagpapabuti sa halip na isang bagay na magagamit na ngayon.
Ang tungkuling Developer ay hindi nagtataglay ng pagtanggal ng site o pagsuspinde ng site — ang mga pahintulot na iyon ay pagmamay-ari ng tungkulin ng Owner. Nagbibigay ito ng karapatang tumingin at gumawa ng mga site, mag-restart ng mga serbisyo, mag-purge ng cache, mamahala ng mga API key, at mag-asikaso ng mga tiket. Ang mga pahintulot para sa Deployment at push-to-live ay hindi rin bahagi ng ibinigay sa Developer, kaya ang pag-promote sa production ay nananatili sa may-ari ng account. Ipares iyon sa staging para mangyari muna ang gawain sa build malayo sa live site.
Nakasalalay ito nang lubusan sa tungkulin ng kawani, at ang bawat tungkulin ay may limitadong hanay ng mga key ng pahintulot. Ang isang Support Agent, halimbawa, ay maaaring tumingin sa iyong account at mga site, tumingin at sumagot sa iyong mga tiket, mag-restart ng site at mag-purge ng cache nito — at hindi maaaring galawin ang configuration ng pagsingil, mga refund, mga plan, o ang fleet. Ang pag-sign in bilang isang customer ay hiwalay na pahintulot na hawak lamang ng Super Admin, at kapag nangyari ito, nagpapakita ang dashboard ng isang patuloy na banner ng pagpapanggap. Ang bawat pribilehiyadong aksyon ay nire-record sa audit log kasama ang aktor, aksyon, target, IP, at timestamp, at maaari mong basahin nang mag-isa ang log ng iyong organisasyon.
Alisin ang membership at ang kanilang access sa organisasyong iyon ay matatapos — mayroon pa rin silang sariling pagkakakilanlan, ngunit wala nang papel at samakatuwid ay wala nang mga pahintulot sa iyong account. Ang mga API key ay indibidwal na binabawi, kaya ang isang pipeline key ay maaaring putulin nang hindi ginagambala ang anupaman. Kung gagamit ka ng SAML single sign-on, ang deprovisioning sa iyong identity provider ang hahawak sa pag-sign-in nang sentralisado. Ang mga kredensyal sa antas ng site tulad ng mga SSH key ay binabawi sa dashboard, at ang pagtanggal mismo ay naka-audit-log.
Hindi — ngunit nararapat na maging tumpak sa dahilan. Pag-ari ng organisasyon ang mga API key, hindi ng indibidwal na miyembro, at mayroon silang sariling tiyak na saklaw na nakaugnay sa parehong katalogo ng pahintulot. Kaya sa halip na magbigay ng key sa isang tao, lumikha ng key para sa gawaing gagawin nito na may pinakamakipot na saklaw na kailangan para sa gawaing iyon, at bawiin ang key na iyon kapag natapos ang gawain. Hash lamang ng sikreto ang kailanman nakaimbak, at itinatala ng bawat key kung kailan ito huling ginamit kaya madaling matuklasan at alisin ang mga hindi nagamit na key.
Oo. Nagpapatunay ang aming MCP server ng mga agent gamit ang OAuth 2.1 at nililimitahan ang mga ito sa iyong organisasyon at iyong RBAC role, gamit ang mga token na maaaring bawiin sa bawat tool, kaya nagbibigay ka ng partikular na kakayahan sa halip na pangkalahatang access. Nangangailangan ng kumpirmasyon ang mga mapanirang aksyon, nalalapat ang mga spend cap, at napupunta ang bawat aksyon sa parehong audit log tulad ng aktibidad ng tao.
Ang Postgres Row-Level Security ay naglilimita sa mga query sa sub-tree ng organisasyon ng tumatawag sa mismong database, kung saan ang filter sa antas ng aplikasyon ay nagsisilbing panlaban nang may lalim sa halip na nag-iisang linya lamang. Ang mga kahilingan para sa mga rekord na nasa labas ng saklaw ay nagbabalik ng hindi nahanap sa halip na error sa pahintulot, kaya walang nahahayag tungkol sa kung ano ang umiiral. Sa panig ng server, ang paghihiwalay sa bawat site sa pamamagitan ng CageFS ay nagpapanatili sa shell at mga file ng bawat tenant na nakatuon lamang sa kanilang sariling site.
Oo. Ang 14-araw na pagsubok ay walang card — walang mga detalye ng pagbabayad, walang obligasyon — at sumasaklaw sa Footprint-Free Hosting na may hanggang limang site. Sapat na ito para mag-imbita ng kasamahan, magatalaga ng tungkulin, at kumpirmahing gumagana ang mga hangganan sa paraang kailangan mo bago ka mangako.
Simulan ang 14-araw na pagsubok nang walang card, mag-imbita ng isang tao, at panoorin ang modelo ng pahintulot na gawin ang trabaho nito — mga titulong maaari mong pangalanan, mga saklaw na maaari mong bawiin, at isang audit log na nagsasabi kung eksaktong sino ang gumawa ng ano.
Magsimula nang libre