Ibinigay na Access
Magdagdag ng developer, ipagkatiwala ang pagsingil sa iyong accountant, bigyan ang kliyente ng read-only na access sa kanilang sariling mga site, o hayaan ang aming team ng suporta na suriin ang isang problema. Ang bawat paggawad ay isang tungkuling may mga tinukoy na pahintulot, nakatuon sa isang organisasyon, ipinapatupad sa database, at nakasulat sa isang audit log na pampadagdag lamang.
Ang pagbabahagi ng iisang login ay kung paano nagkakaroon ng problema ang access sa account. Sa Zinn Digital®, ang bawat tao ay may sariling pagkakakilanlan, at ang access ay isang membership — isang user, isang organisasyon, at isang role — na maaari ninyong ibigay, baguhin, o bawiin nang mag-isa.
Ang bawat collaborator ay nagsa-sign in bilang kanilang sarili sa pamamagitan ng Keycloak, ang aming identity layer. Walang nagta-type ng inyong password, walang nagbabahagi ng session sa browser, at ang pag-alis ng isang tao ay isang aksyon lamang sa halip na pagpapalit ng password at pagmamadaling alamin kung sino pa ang nakakaalam nito.
Hierarchical ang mga account — ang reseller na organisasyon ay naglalaman ng mga organisasyon ng kliyente, at ang mga organisasyon ng kliyente ay naglalaman ng mga site. Ang pagiging miyembro ay nalalapat sa isang organisasyon at sa lahat ng nasa ilalim nito, kaya maaari ninyong ibigay sa isang kliyente ng ahensya ang kontrol sa kanilang sariling organisasyon nang hindi kailanman inilalantad ang iba pa ninyong mga kliyente.
Ang paghihiwalay ng tenant ay hindi isang filter sa code ng application na maaaring malaktawan ng isang bug. Nililimitahan ng Postgres Row-Level Security ang bawat query sa subtree ng organisasyon ng tumatawag, kaya walang maibabalik ang isang kahilingan sa labas ng inyong saklaw.
Humingi ng organisasyon o site na labas sa iyong saklaw at sasagot ang API ng simpleng not-found sa halip na error sa pahintulot. Kukumpirmahin ng error sa pahintulot na umiiral ang tala; walang sinasabi ang not-found sa isang tagalabas.
Ang mga pahintulot ay mga detalyadong key — module kasama ang aksyon, tulad ng sites.restart o billing.refund — at pinagsasama-sama ang mga ito ng mga tungkulin. Sinasaklaw ng apat na tungkulin ang mga kaayusang kailangan ng mga totoong koponan, at ang bawat isa ay datos na inilalagay namin, hindi lohikang nakabaon sa code.
Ganap na kontrol: gumawa ng mga child organization, mag-imbita at mag-alis ng mga miyembro, magbago ng mga tungkulin, pamahalaan ang mga API key, gumawa, mag-restart, mag-purge, mag-suspend, at magbura ng mga site, magpatakbo ng pagsingil at mga invoice, magsumite ng mga ticket, at basahin ang audit log. Ang tungkuling itinatabi ninyo para sa inyong sarili.
Nakikita ang organisasyon, ang mga miyembro nito, at ang katalogo ng mga plano, at namamahala ng mga invoice, paraan ng pagbabayad, at mga singilin. Walang access upang gumawa, magbago, o magbura ng kahit isang site — eksaktong angkop para sa isang panlabas na bookkeeper.
Tinitingnan at lumilikha ng mga site, nagre-restart ng mga serbisyo, naglilinis ng cache, namamahala ng mga API key, at nag-aasikaso ng mga ticket. Sadyang hindi isinama: pagsingil, mga invoice, mga paraan ng pagbabayad, pamamahala ng miyembro, pagsuspinde ng site, at pagtanggal ng site. Ang isang kontratista ay maaaring magtayo nang hindi kayo masisingil o walang masisirang anuman.
Nakikita ang organisasyon, ang mga miyembro nito, ang mga site nito, ang pagsingil nito, ang katalogo ng plano, mga tiket, katayuan ng pagsasalin at ang log ng pag-audit — at walang mababago sa alinman dito. Ang tamang pahintulot para sa isang kliyenteng nagnanais ng visibility, isang auditor, o isang stakeholder na kailangan lamang tumingin.
Ligtas lamang ang pag-delegate ng access kung ang mga account na pinag-delegate-an mo ay mahirap ma-take over. Tumatakbo ang pagpapatotoo sa pamamagitan ng Keycloak para sa bawat tao sa account, sa bawat surface.
Ang gawain sa suporta ay minsan nangangahulugang pagsuri sa loob ng inyong account. Ang access na iyon ay pinamamahalaan ng parehong modelo ng pahintulot tulad ng iba pa — ang mga kawani ay kabilang lamang sa isang organisasyon ng kawani, na nakaayos sa mga departamento na may partikular at limitadong mga pahintulot.
Ang mga tauhan ay pinapangkat sa Suporta, Pagsingil at Pananalapi, Pang-aabuso at Tiwala-at-Kaligtasan, Benta, Onboarding, Inhinyerya at Operasyon, Pemasaran, at Pamamahala. Ang bawat tungkulin ay nagbibigay ng mga partikular na module at pagkilos, upang makita lamang ng isang ahente ang bahagi ng admin console na kailangan ng kanyang trabaho at hindi ang iba pa.
Ipinagkakaloob ng tungkulin ng Support Agent ang eksaktong ito: tingnan ang mga customer, tingnan at sagutin ang mga ticket, tingnan ang mga site, i-restart ang isang site at i-purge ang cache nito. Wala itong dalang pagsasaayos ng billing, walang mga refund, walang pag-edit ng plano, at walang pamamahala ng fleet. Ang remediation na maaaring isagawa ng isang ahente ay nalilimitahan ng tungkulin, hindi ng magagandang intensyon.
Ang pahintulot na customer.impersonate ay hindi bahagi ng tungkulin ng Manager — hawak lamang ito ng Super Admin. Kapag may sesyong tumatakbo sa ngalan ninyo, nagpapakita ang dashboard ng isang permanenteng impersonation banner upang hindi maging malabo kung sino ang kumikilos.
Ang bawat may pribilehiyo at administratibong pagkilos ay idinaragdag sa isang append-only na audit log na nagtatala sa nagsagawa, sa pagkilos, sa target, sa pansuportang metadata, sa IP address, at sa timestamp — naka-partition ayon sa oras sa produksyon. Ang mga may-ari at mga miyembrong read-only ay maaaring magbasa mismo ng log ng kanilang organisasyon.
Maaaring mangailangan ang mga sensitibo at mapanirang pagkilos ng kawani ng pinalakas na pagpapatotoo o pag-apruba ng dalawang tao bago isagawa ang mga ito, at ang mga bagong departamento at tungkulin ay sa pamamagitan ng pagsasaayos sa halip na pagbabago sa code.
Ang mga script, CI pipeline, ang CLI, ang Terraform provider, at mga AI agent ay nagpapatunay lahat sa pamamagitan ng parehong modelo ng pahintulot tulad ng mga tao — walang ibinahaging kredensyal ng tao, walang pangmatagalang lihim na naka-paste sa isang build.
Ang mga key ay pagmamay-ari ng isang organisasyon at may mga detalyadong saklaw na nakatali sa parehong mga pahintulot ng RBAC — read-only, pagsingil, paglalaan. Bigyan ang isang pipeline ng limitadong saklaw na kailangan nito sa halip na ang buong account ng isang miyembro.
Magkaiba ang mga key para sa test-mode at live-mode, kaya hindi sinasadyang makaka-access ang isang integrasyong kasalukuyang binubuo sa data ng produksyon nang hindi sinasadya o sa pamamagitan ng nakopyang environment variable.
Nag-iimbak kami ng SHA-256 hash ng sikreto at isang lookup prefix — hinding-hindi ang raw key. Makikita mo ang susi nang isang beses lang sa paggawa nito. Sinusubaybayan ng bawat susi kung kailan ito huling ginamit at maaari itong bawiin nang mag-isa nang hindi naaabala ang anupaman.
Nagbibigay-daan ang aming MCP server sa anumang MCP-capable na agent na pamahalaan ang inyong hosting sa natural na wika, na napatotohanan gamit ang OAuth 2.1 at nakasaklaw sa inyong organisasyon at tungkulin sa RBAC, na may mga bawat-tool na mababawing token, kumpirmasyon sa mga mapanirang aksyon, mga limitasyon sa paggastos, at buong audit logging.
Magkaibang usapin ang access sa account at access sa server. Pinamamahalaan sa dashboard ang mga kredensyal sa antas ng site, ibinibigay nang may pinakamababang pribilehiyo, at naka-jail upang ang shell ng isang collaborator ay maging shell lamang ng isang site.
Ang isang solong operator ay nagpapanatili ng isang organisasyon at isang membership ng may-ari, at nagdaragdag ng tungkulin ng Developer kapag pumasok ang isang contractor para sa isang proyekto. Kapag natapos ang proyekto, aalisin ang membership at agad na hihinto sa paggana ang kanilang pag-sign in — walang naiiwang nakabahaging kredensyal na kailangang palitan.
Gumagamit ang isang ahensya ng organization tree. Bawat kliyente ay nakakakuha ng sarili nitong child organization na naglalaman ng mga site ng kliyenteng iyon, at ang sariling mga tauhan ng kliyente ay nagkakaroon ng mga membership doon — read-only para sa isang stakeholder na nais ng visibility, owner para sa isang kliyenteng nais mag-self-serve. Ang inyong mga tauhan ay may mga membership sa mas mataas na bahagi ng tree at nakikita ang portfolio; ang isang kliyente ay nakikita lamang ang sarili nilang branch, at ang Row-Level Security ang gumagawa ritong totoo sa halip na isang pangako lamang.
Gumagana ang isang reseller sa parehong paraan, isang antas na mas mataas: naglalaman ang isang reseller organization ng mga organisasyon ng kliyente, bawat isa ay may sariling mga miyembro, view ng pagsingil, at mga site. Ang parehong primitive ang nagpapatakbo sa mga sub-account, koponan ng ahensya, at hierarchy ng reseller — walang hiwalay at mas mahinang mekanismo para sa alinman sa mga ito.
Available ang lahat sa walang-kard na 14-araw na trial. Mag-sign up nang walang mga detalye ng pagbabayad, mag-imbita ng kasamahan sa trabaho, tingnan kung ano ang maaari at hindi ma-access ng bawat tungkulin, at basahin ang sarili ninyong audit log.
Sa kasalukuyan, ipinagkakaloob ng isang membership ang tungkulin nito sa buong organisasyon at sa lahat ng nasa ilalim nito sa hierarchy, kaya ang paraan upang paghiwalayin ang mga hanay ng site ay ang paghiwalayin ang mga organisasyon — ilagay ang mga site na iyon sa kanilang sariling subsidiary na organisasyon at igawad ang membership doon. Ito ay isang maayos na modelo para sa mga ahensya at reseller, kung saan nais na ng bawat kliyente ang kanilang sariling hangganan. Ang pagtatakda ng saklaw ng mapagkukunan bawat membership, na nag-uugnay ng iisang membership sa mga partikular na site sa loob ng isang organisasyon, ay isang planadong pagpapahusay sa halip na isang bagay na magagamit na ngayon.
Hindi sakop ng tungkuling Developer ang pagbura ng site o pagsuspinde ng site — ang mga susi na iyon ay pag-aari ng tungkuling Owner. Nagbibigay ito ng pagtingin at paggawa ng mga site, pag-restart ng mga serbisyo, pag-purge ng cache, pamamahala ng mga API key, at pagtatrabaho sa mga ticket. Ang mga pahintulot sa pag-deploy at push-to-live ay hindi rin bahagi ng ipinagkaloob sa Developer, kaya ang pag-promote sa produksyon ay nananatili sa may-ari ng account. Ipares iyon sa staging upang ang gawaing pagbuo ay mangyari nang hiwalay sa live site.
Depende ito nang buo sa tungkulin ng kawani, at ang bawat tungkulin ay isang limitadong hanay ng mga susi ng pahintulot. Ang isang Ahente ng Suporta, halimbawa, ay maaaring tumingin sa inyong account at mga site, tingnan at sagutin ang inyong mga ticket, i-restart ang isang site at i-purge ang cache nito — at hindi maaaring galawin ang configuration ng pagsingil, mga refund, mga plano, o ang fleet. Ang pag-sign in bilang isang customer ay isang hiwalay na pahintulot na hawak lamang ng Super Admin, at kapag nangyari ito ay nagpapakita ang dashboard ng isang permanenteng banner ng pagpapanggap. Ang bawat may pribilehiyong pagkilos ay naitatala sa audit log kasama ang gumawa, pagkilos, target, IP, at timestamp, at maaari ninyong basahin mismo ang log ng inyong organisasyon.
Alisin ang membership at magwawakas ang kanilang access sa organisasyong iyon — taglay pa rin nila ang kanilang sariling pagkakakilanlan, ngunit walang tungkulin at samakatuwid ay walang mga pahintulot sa iyong account. Ang mga API key ay binabawi nang isa-isa, kaya maaaring putulin ang isang pipeline key nang hindi naaabala ang anupaman. Kung gumagamit ka ng SAML single sign-on, ang deprovisioning sa iyong identity provider ang sentral na namamahala sa pag-sign-in. Ang mga kredensyal sa antas ng site tulad ng mga SSH key ay binabawi sa dashboard, at ang mismong pag-alis ay naka-audit-log.
Hindi — ngunit kapaki-pakinabang na maging tumpak kung bakit. Ang mga API key ay pag-aari ng organisasyon, hindi ng isang indibidwal na miyembro, at mayroon silang sariling mga butil-butil na saklaw na nakatali sa parehong katalogo ng pahintulot. Kaya sa halip na mag-abot ng key sa isang tao, lumilikha kayo ng key para sa gawaing ginagawa nito na may pinakamakitid na saklaw na kailangan ng gawaing iyon, at binabawi ang key na iyon kapag natapos ang gawain. Hash lang ng lihim ang nakaimbak kailanman, at itinatala ng bawat key kung kailan ito huling ginamit upang madaling mahanap at maalis ang mga hindi nagagamit na key.
Oo. Pinapatotohanan ng aming MCP server ang mga agent gamit ang OAuth 2.1 at nililimitahan ang saklaw ng mga ito sa iyong organisasyon at sa iyong tungkulin sa RBAC, na may mga bawiing token bawat tool, upang makapagbigay ka ng partikular na kakayahan sa halip na malawakang access. Ang mga mapanirang pagkilos ay nangangailangan ng kumpirmasyon, may mga limitasyon sa paggastos na ipinapatupad, at ang bawat pagkilos ay napupunta sa parehong audit log gaya ng aktibidad ng tao.
Nililimitahan ng Postgres Row-Level Security ang mga query sa subtree ng organisasyon ng tumatawag sa mismong database, kung saan ang filter sa antas ng application ay nagsisilbing karagdagang depensa sa halip na nag-iisang linya. Ang mga kahilingan para sa mga talaang nasa labas ng saklaw ay nagbabalik ng hindi nahanap sa halip na error sa pahintulot, kaya walang nabubunyag tungkol sa kung ano ang umiiral. Sa panig ng server, pinapanatili ng paghihiwalay bawat site sa pamamagitan ng CageFS ang shell at mga file ng bawat nangungupahan sa kanilang sariling site.
Oo. Ang 14-na-araw na pagsubok ay walang kailangang kard — walang mga detalye ng pagbabayad, walang obligasyon — at sumasaklaw sa Footprint-Free hosting na may hanggang limang site. Sapat na ito upang mag-imbita ng kasamahan, magtalaga ng tungkulin, at tiyaking gumagana ang mga hangganan ayon sa kailangan ninyo bago kayo magpasyang magpatuloy.
Magsimula sa walang-kard na 14-araw na pagsubok, mag-imbita ng sinuman, at panoorin kung paano ginagawa ng modelo ng pahintulot ang trabaho nito — mga tungkulin na maaari ninyong pangalanan, mga saklaw na maaari ninyong bawiin, at isang log ng pag-audit na eksaktong nagsasaad kung sino ang gumawa ng ano.
Magsimula nang libre