Qasja e Deleguar

Jepni njerëzve saktësisht aksesin që u duhet — dhe asgjë më shumë

Sillni një zhvillues, dorëzojuni faturimin kontabilistit tuaj, jepini një klienti një dritare me akses vetëm për lexim në faqet e tij, ose lejoni ekipin tonë të mbështetjes të shqyrtojë një problem. Çdo dhënie qasjeje është një rol me leje të përcaktuara, të kufizuara në një organizatë, të zbatuara në databazë dhe të regjistruara në një regjistër auditimi vetëm për shkrim.

  • 94lejeve granulare
  • 12rolet e integruara
  • 8departamentet e stafit
  • 650,000+faqë të hostuara në mbarë botën

Qasja është anëtarësim, jo një fjalëkalim i ndarë

Ndajnë e njëjta hyrje është mënyra se si aksesi në llogari shkon keq. Në Zinn Digital® çdo person ka identitetin e tij, dhe aksesi është një anëtarësim — një përdorues, një organizatë dhe një rol — të cilin mund ta jepni, ndryshoni ose revokoni veçmas.

Identiteti yt, gjithmonë

Secili bashkëpunëtor identifikohet me kredencialet e veta përmes Keycloak, shtresa jonë e identitetit. Askush nuk shkruan fjalëkalimin tuaj, askush nuk ndan një sesion shfletuesi dhe heqja e dikujt është një veprim i vetëm në vend të ndryshimit të fjalëkalimit dhe një angazhimi për të kuptuar se kush tjetër e dinte atë.

Organizatat formojnë një pemë

Llogaritë janë hierarkike — një organizatë rishitëse mban organizatat e klientëve, dhe organizatat e klientëve mbajnë faqet. Një anëtarësim zbatohet për një organizatë dhe gjithçka poshtë saj, kështu që ju mund t'i jepni kontrollin e organizatës së tyre një klienti agjencie pa ekspozuar kurrë klientët tuaj të tjerë.

Izolimi u zbatua në bazën e të dhënave

Ndarja e qiramarrësve nuk është një filtër në kodin e aplikacionit që një gabim mund ta anashkalojë. Siguria e bazuar në rreshta e Postgres kufizon çdo pyetje në nëntpemën e organizatës së thirrësit, kështu që një kërkesë jashtë fushës tuaj nuk ka asgjë për të kthyer.

Mungesa është e padukshme

Kërkoni për një organizatë ose sajt jashtë fushës suaj dhe API përgjigjet me një përgjigje të thjeshtë nuk u gjet në vend të një gabimi leje. Një gabim leje do të konfirmonte se regjistrimi ekziston; nuk u gjet nuk i tregon një personi të jashtëm asgjë fare.

Katër role klientësh, tridhjetë e pesë leje

Lejet janë çelësa granularë — moduli plus veprimi, si sites.restart ose billing.refund — dhe rolet i grupojnë ato. Katër role mbulojnë format që u duhen ekipeve reale, dhe secili prej tyre është të dhënë që ne i ngarkojmë paraprakisht, jo logjikë e fshehur në kod.

Pronar

Kontroll i plotë: krijoni organizata bijë, ftoni dhe hiqni anëtarë, ndryshoni rolet, menaxhoni çelësat API, krijoni, rinisni, pastroni, pezulloni dhe fshini faqet, kryeni faturimin dhe faturat, ngritni kërkesa dhe lexoni regjistrin e auditimit. Rolin që e mbani për vete.

Menaxheri i faturimit

Shih organizatën, anëtarët e saj dhe katalogun e planeve, dhe menaxhon faturat, mënyrat e pagesës dhe pagesat e kryera. Asnjë akses për të krijuar, ndryshuar apo fshirë ndonjë sajt të vetëm — pikërisht forma që duhet të ketë një kontabilist i jashtëm.

Zhvilluesi

Shikon dhe krijon faqe, rinis shërbimet, pastron memorjen e fshehur (cache), menaxhon çelësat e API-së dhe trajton biletat e mbështetjes. Të përjashtuara qëllimisht: faturimi, faturat, mënyrat e pagesës, menaxhimi i anëtarëve, pezullimi i faqeve dhe fshirja e faqeve. Një kontraktor mund të ndërtojë pa qenë në gjendje t'ju faturojë apo të shkatërrojë diçka.

Vetëm për lexim

Shih organizatën, anëtarët e saj, faqet e saj, faturimin, katalogun e planeve, biletat, statusin e përkthimit dhe regjistrin e auditimit — dhe nuk mund të ndryshojë asnjë prej tyre. Leja e duhur për një klient që dëshiron dukshmëri, një auditor ose një palë të interesuar që duhet vetëm të shikojë.

Hyrja e ekipit tuaj nuk mund të dobësohet në heshtje

Delegimi i aksesit është i sigurt vetëm nëse llogaritë të cilave u delegoni janë të vështira për t'u marrë përsipër. Autentifikimi kalon përmes Keycloak për çdo person në llogari, në çdo ndërfaqe.

  • Fjalëkalimet dhe WebAuthn për hyrje të mbrojtur ndaj phishing-ut, plus vërtetimin me dy faktorë TOTP të detyruar për të gjithë me rregullore — jo një cilësim opsional që një anëtar i ekipit mund ta anashkalojë.
  • Identifikimi i paracaktuar me email përmes lidhjes magjike (magic-link), me email dhe fjalëkalim si mundësi rezervë, dhe identifikimi social përmes Google, Microsoft, GitHub dhe të tjerë.
  • Identifikimi i vetëm SAML (single sign-on) për klientët e ndërmarrjeve dhe agjencive, kështu që anëtarësimet dhe largimet menaxhohen nga ofruesi juaj i identitetit në vend të procesit manual.
  • Një sesion i vetëm në panelin e klientit, faqen publike, bazën e njohurive dhe biletat e mbështetjes — hyni një herë dhe revokojeni një herë.
  • Politikat e sesioneve, vërtetimi shtesë në veprimet e ndjeshme, dhe listat opsionale të lejuara të IP-ve për çdo organizatë për llogaritë që kërkojnë qasje të kufizuar në rrjete të njohura.
  • Çdo email regjistrimi vërtetohet para se të krijohet një llogari, kështu që adresat e pamundura për t'u dorëzuar, të disponueshme dhe të roleve kapen në hyrje në vend që të bëhen një anëtar i lënë pas dore më vonë.

Kur ekipit tonë i nevojitet qasje, ajo përcaktohet në kufijtë e duhura dhe regjistrohet

Puna e mbështetjes ndonjëherë nënkupton shikimin brenda llogarisë tuaj. Kjo qasje rregullohet nga i njëjti model lejesh si çdo gjë tjetër — stafi thjesht ndodhet në një organizatë stafi, e organizuar në departamente me autorizime të ngushta.

Departamente, jo administratë e përgjithshme

Stafi grupohet në Mbështetje, Faturim dhe Financa, Abuzim dhe Besueshmëri-dhe-Siguri, Shitje, Integrim, Inxhinieri dhe Operacione, Marketing dhe Menaxhim. Çdo rol jep module dhe veprime specifike, kështu që një agjent sheh vetëm atë pjesë të konsolës së administratorit që kërkon puna e tij dhe jo pjesën tjetër.

Tavanimi i vërtetë i një agjenti mbështetjeje

Roli i Agjentit të Mbështetjes ofron pikërisht këtë: shikimin e klientëve, shikimin dhe përgjigjen ndaj tiketeve, shikimin e siteve, rinisjen e një siti dhe pastrimin e cache-it të tij. Ai nuk përfshin asnjë konfigurim faturimi, asnjë rimbursim, asnjë redaktim plani dhe asnjë menaxhim flote. Riparimi që një agjent mund të kryejë kufizohet nga roli, jo nga qëllimet e mira.

Identifikimi si klient menaxhohet me rreptësi

Leja customer.impersonate nuk është pjesë e rolit Manager — ajo mbahet vetëm nga Super Admin. Kur një sesion është duke u ekzekutuar në emrin tuaj, paneli i kontrollit mban një baner të përhershëm imitimi, kështu që nuk ka asnjë paqartësi se kush po vepron.

Gjithçka që gëzon privilegje është e shkruar

Çdo veprim i privilegjuar dhe administrativ shtohet në një regjistër auditimi vetëm për shtim që regjistron aktorin, veprimin, objektivin, metadatat mbështetëse, adresën IP dhe kohëvulosjen — të ndara sipas kohës në prodhim. Pronarët dhe anëtarët vetëm për lexim mund ta lexojnë vetë regjistrin e organizatës së tyre.

Portat e miratimit për punën shkatërruese

Veprimet e ndjeshme dhe shkatërruese të stafit mund të kërkojnë vërtetim shtesë ose miratim nga dy persona përpara se të ekzekutohen, dhe departamentet e rolet e reja përbëjnë konfigurim dhe jo ndryshim kodi.

Edhe makinerive i jepet qasje e deleguar

Skriptet, tubacionet CI, CLI, ofruesi i Terraform-it dhe agjentët e AI-së autentikohen të gjithë përmes të njëjtit model lejesh si njerëzit — pa kredenciale njerëzore të përbashkëta, pa sekrete afatgjata të ngjitura në një ndërtim.

Çelësat e API-së janë për çdo organizatë dhe me fushë veprimi të përcaktuar

Çelësat i përkasin një organizate dhe mbajnë fusha veprimi granulare të lidhura me të njëjta leje RBAC – vetëm për lexim, faturim, sigurim burimesh. Jepini një tubacioni fushën e ngushtë të veprimit që i nevojitet në vend të llogarisë së plotë të një anëtari.

Çelësat e sandbox janë të ndarë nga ata të prodhimit

Çelësat e modalitetit të testimit dhe atij aktiv janë të dallueshëm, kështu që një integrim në zhvillim nuk mund të ketë akses në të dhënat e prodhimit gabimisht ose përmes një variabli mjedisor të kopjuar.

Vetëm hash-i ruhet

Ne ruajmë një hash SHA-256 të fjalëkalimit dhe një prefiks kërkimi - kurrë çelësin e papërpunuar. Ju e shihni një çelës vetëm një herë gjatë krijimit. Secili çelës gjurmon se kur është përdorur për herë të fundit dhe mund të revokohet më vete pa prishur asgjë tjetër.

Mjetet e AI lidhen sipas lejeve tuaja

Serveri ynë MCP i lejon çdo agjenti të pajisur me MCP të menaxhojë hostimin tuaj në gjuhë natyrore, të vërtetuar me OAuth 2.1 dhe të kufizuar në organizatën tuaj dhe rolin RBAC, me tokenë të revokueshëm për çdo mjet, konfirmim për veprimet shkatërruese, kufizime shpenzimesh dhe regjistrim të plotë të auditimit.

Qasje në vetë faqet

Qasja në llogari dhe qasja në server janë probleme të ndryshme. Kredencialet në nivel faqeje menaxhohen në panelin e kontrollit, lëshohen me privilegjet minimale dhe izolohen në mënyrë që shell-i i një bashkëpunëtori të jetë shell-i i një faqeje të vetme.

  • SSH me një shell të izoluar, plus SFTP dhe FTP — izolimi CageFS do të thotë se çdo përdorues shikon vetëm skedarët e tij.
  • wp-cli nga terminali i panelit dhe përmes SSH, për operacionet që zhvilluesit në të vërtetë duan t'i skriptojnë.
  • Një editor i plotë VS Code në shfletues përmes code-server — shtojca, terminal i integruar dhe git, duke redaktuar skedarët e faqes drejtpërdrejt në panelin e kontrollit.
  • phpMyAdmin dhe Adminer të integruara për bazat e të dhënave, si dhe një menaxher skedarësh i integruar, të dyja me hyrje të vetme (single-sign-on) nga paneli i kontrollit në vend që të kërkojnë një grup të dytë kredencialesh.
  • Çelësat e aksesit dhe kredencialet krijohen, listohen, rrotullohen dhe revokohen në panelin e kontrollit, lëshohen me parimin e privilegjit minimal dhe përdorimi i tyre regjistrohet në auditim.
  • Krijimi i mjedisit paraprak (staging) me klonim dhe dërgim të drejtpërdrejtë (push-to-live) e mban punën me rrezik larg produksionit, kështu që ndryshimi i parë i një bashkëpunëtori të ri nuk del kurrë direkt në një faqe aktive.

Si të strukturoni qasjen për mënyrën se si punoni në të vërtetë

Një operator i vetëm mban një organizatë të vetme dhe një anëtarësim pronari, dhe shton një rol Zhvilluesi kur një kontraktor vjen për një projekt. Kur projekti përfundon, anëtarësimi hiqet dhe hyrja e tyre ndalon së funksruari menjëherë — nuk mbetet asnjë kredenciale e përbashkët për t'u rrotulluar.

Një agjenci përdor pemën e organizatës. Çdo klient merr organizatën e vet bijë, e cila strehon faqet e atij klienti, dhe vetë personat e klientit marrin anëtarësimet atje – vetëm për lexim për një palë të interesuar që dëshiron dukshmëri, ose pronar për një klient që dëshiron të vetëshërbehet. Stafi juaj mban anëtarësime më lart në pemë dhe sheh portofolin; një klient sheh vetëm degën e vet, dhe Siguria në Nivel Rreshti është ajo që e bën këtë të vërtetë e jo thjesht një premtim.

Një rishitës funksionon në të njëjtën mënyrë, një nivel më lart: një organizatë rishitësi përmban organizata klientësh, secila me anëtarët, pamjen e faturimit dhe faqet e veta. I njëjti element bazë fuqizon nënllogaritë, ekipet e agjencive dhe hierarkitë e rishitësve — nuk ka asnjë mekanizëm të veçantë apo më të dobët për asnjërin prej tyre.

Gjithçha është e disponueshme në provën 14-ditore pa kartë. Regjistrohuni pa detaje pagese, ftoni një koleg, shikoni se çfarë mund dhe nuk mund të arrijë secili rol dhe lexoni përsëri regjistrin tuaj të auditimit.

Pyetjet e shpeshta

A mund t'i jep dikujt akses vetëm në një sajt?

Sot një anëtarësim jep rolin e tij në të gjithë organizatën dhe çdo gjë poshtë saj në strukturë, kështu që mënyra për të ndarë grupet e faqeve është ndarë organizatat — vendosni ato faqe në organizatën e tyre bijë dhe jepni anëtarësimin atje. Është një model i pastër për agjencitë dhe rishitësit, ku çdo klient tashmë dëshiron kufirin e tij. Përcaktimi i fushëveprimit të burimeve për çdo anëtarësim, lidhja e një anëtarësimi të vetëm me faqe të emërtuara brenda një organizate, është një përmirësim i planifikuar dhe jo diçka e disponueshme tani.

A mund të fshijë një zhvillues që ftoj një faqe interneti apo ta hedhë atë në gjendje live?

Roli i Zhvilluesit nuk përfshin fshirjen ose pezullimin e faqeve — këto çelësa i përkasin rolit të Pronarit. Ai jep mundësinë e shikimit dhe krijimit të faqeve, rinisjes së shërbimeve, pastrimit të cache-it, menaxhimit të çelësave të API-së dhe trajtimit të biletave. Lejet e vendosjes në prodhim (deployment) dhe dërgimit direkt në faqe nuk janë pjesë e autorizimit të Zhvilluesit, kështu që promovimi në prodhim mbetet te pronari i llogarisë. Përputheni këtë me mjedisin e testimit (staging), që puna e ndërtimit të kryhet larg faqes kryesore që në fillim.

Çfarë mund të shohë stafi i Zinn Digital® në llogarinë time?

Kjo varet plotësisht nga roli i stafit, dhe çdo rol përbëhet nga një grup i ngushtë çelësash lejesh. Për shembull, një Agjent Mbështetjeje mund të shohë llogarinë dhe faqet tuaja, të shikojë dhe t'u përgjigjet biletave tuaja, të rinisë një faqe dhe të pastrojë memorien e saj të fshehtë — dhe nuk mund të prekë konfigurimin e faturimit, rimbursimet, planet ose grupin e serverëve. Hyrja si klient është një leje e veçantë që mbahet vetëm nga Super Administratori, dhe kur kjo ndodh, paneli shfaq një banderolë të përhershme keqpersonifikimi. Çdo veprim i privilegjuar regjistrohet në regjistrin e auditimit me aktor, veprim, shënjestër, IP dhe vulë kohore, dhe ju mund ta lexoni vetë regjistrin e organizatës suaj.

Si ta revokoj aksesin shpejt nëse dikush largohet?

Hiqni anëtarësimin dhe aksesi i tyre në atë organizatë përfundon — ata kanë ende identitetin e tyre, por nuk kanë asnjë rol dhe për rrjedhojë asnjë leje në llogarinë tuaj. Çelësat e API-së revokohen individualisht, kështu që një çelës tubacioni mund të ndërpritet pa shqetësuar asgjë tjetër. Nëse përdorni hyrjen e vetme SAML, zhvillimi i provizionit te identiteti juaj trajton hyrjen në mënyrë qendrore. Kredencialet në nivel faqeje, si çelësat SSH, revokohen në panelin e kontrollit, dhe vetë heqja regjistrohet në auditim.

A ndajnë anëtarët e ekipit çelësat e mi të API-së?

Jo — por ia vlen të jemi të saktë se pse. Çelësat e API-së i përkasin organizatës, jo një anëtari individual, dhe ata mbajnë fushat e tyre grushtore të lidhura me të njëjtin katalog lejesh. Kështu që në vend që t'i jepni dikujt një çelës, ju krijoni një çelës për punën që bën, me fushën më të ngushtë që i nevojitet asaj pune, dhe e revokoni atë çelës kur puna përfundon. Vetëm një hash i sekretit ruhet ndonjëherë, dhe çdo çelës regjistron se kur është përdorur për herë të fundit, kështu që çelësat e papërdorur janë të lehtë për t'u gjetur dhe hequr nga përdorimi.

A mund të lidh një agjent AI pa i dhënë çelësat e çdo gjëje?

Po. Serveri ynë MCP vërteton agjentët me OAuth 2.1 dhe i kufizon ata në organizatën tuaj dhe rolin tuaj RBAC, me çelësa të revokueshëm për çdo mjet, kështu që ju jepni një aftësi specifike në vend të aksesit të plotë. Veprimet shkatërruese kërkojnë konfirmim, zbatohen kufizimet e shpenzimeve dhe çdo veprim përfundon në të njëjtin regjistër auditimi si aktiviteti njerëzor.

Çfarë e ndalon një qiramarrës të ketë akses në të dhënat e një qiramarrësi tjetër?

Siguria në nivel rreshti në Postgres kufizon kërkesat në nëndegën e organizatës së thirrësit brenda vetë databazës, ku filtri në nivel aplikacioni shërben si mbrojtje në thellësi e jo si linja e vetme. Kërkesat për regjistra jashtë fushëveprimit kthejnë "nuk u gjet" në vend të një gabimi lejeje, kështu që nuk zbulohet asgjë rreth asaj që ekziston. Në anën e serverit, izolimi për çdo sajt përmes CageFS mban guaskën dhe skedarët e çdo qiramarrësi në sajtin e tyre.

A mund ta provoj këtë para se të paguaj?

Po. Prova 14-ditore nuk kërkon kartë — as të dhëna pagese, as detyrim — dhe mbulon Footprint-Free Hosting me deri në pesë faqe interneti. Mjafton për të ftuar një koleg, për të caktuar një rol dhe për të konfirmuar se kufijtë sillen ashtu siç ju duhet para se të angazhoheni.

Delegoni me një kufi që mund ta tregoni me gisht

Fillo provën 14-ditore pa pasur nevojë për kartë, fto dikë dhe shiko modelin e lejeve të bëjë punën e tij — role që mund t'i emërtosh, fusha veprimi që mund t'i revokosh dhe një regjistër auditimi që tregon saktësisht se kush ka bërë çfarë.

Fillo falas