Delegált hozzáférés
Vonjon be egy fejlesztőt, adja át a számlázást a könyvelőjének, biztosítson az ügyfélnek csak olvasható hozzáférést a saját webhelyeihez, vagy engedje meg ügyfélszolgálati csapatunknak egy probléma kivizsgálását. Minden jogosultságkiosztás meghatározott engedélyekkel rendelkező szerepkör, amely egy szervezetre korlátozódik, az adatbázisban érvényesül, és egy kizárólag hozzáfűzéssel bővíthető auditnaplóba kerül rögzítésre.
Egyetlen bejelentkezési adat megosztása a fiókhozzáférés meghiúsulásához vezet. A Zinn Digital® felületén minden személy saját identitással rendelkezik, a hozzáférés pedig egy tagság — egy felhasználó, egy szervezet és egy szerepkör —, amelyet Ön önállóan megadhat, módosíthat vagy visszavonhat.
Minden munkatárs önállóan jelentkezik be a Keycloak-on, a személyazonossági rétegünkön keresztül. Senki sem gépeli be az Ön jelszavát, senki sem oszt meg böngésző-munkamenetet, és valakinek az eltávolítása egyetlen művelet a jelszócserék és a fejtörés helyett, hogy még ki tudhatja azt.
A fiókok hierarchikusak — a viszonteladói szervezet ügyfélszervezeteket tartalmaz, az ügyfélszervezetek pedig webhelyeket tartalmaznak. A tagság egy szervezetre és a hozzá tartozó minden alatta lévő elemre vonatkozik, így átadhatja egy ügynökségi ügyfélnek a saját szervezete feletti irányítást anélkül, hogy valaha is felfedné a többi ügyfelét.
A bérlők elkülönítése nem egy olyan szűrő az alkalmazáskódban, amelyet egy hiba kikerülhetne. A Postgres sorszintű biztonsága (Row-Level Security) minden lekérdezést a hívó szervezeti részfájára korlátoz, így a hatókörén kívül eső kérések nem adnak vissza semmit.
Ha a hatáskörén kívül eső szervezetet vagy webhelyet kér le, az API jogosultsági hiba helyett egyszerű „nem található” választ ad. A jogosultsági hiba megerősítené a rekord létezését; a „nem található” viszont egyáltalán semmit sem árul el egy kívülállónak.
Az engedélyek részletes kulcsok — modul plusz művelet, mint például a sites.restart vagy a billing.refund —, a szerepkörök pedig ezeket fogják össze. Négy szerepkör fedi le a valós csapatok által igényelt struktúrákat, és mindegyik általunk feltöltött adat, nem pedig a kódban elrejtett logika.
Teljes ellenőrzés: hozzon létre alszervezeteket, hívjon meg és távolítson el tagokat, módosítsa a szerepköröket, kezelje az API-kulcsokat, hozzon létre, indítson újra, ürítsen ki, függesszen fel és töröljön webhelyeket, kezelje a számlázást és a számlákat, nyisson hibajegyeket, és tekintse meg a vizsgálati naplót. A szerepkör, amelyet megtart magának.
Látja a szervezetet, annak tagjait és a csomagkatalógust, valamint kezeli a számlákat, a fizetési módokat és a díjakat. Egyetlen webhely létrehozására, módosítására vagy törlésére sincs hozzáférése — pontosan olyan felépítés, amilyennel egy külső könyvelőnek rendelkeznie kell.
Webhelyeket tekint meg és hoz létre, szolgáltatásokat indít újra, kiüríti a gyorsítótárat, API-kulcsokat kezel és hibajegyeket dolgoz fel. Szándékosan kizárva: számlázás, számlák, fizetési módok, tagkezelés, webhelyfelfüggesztés és webhelytörlés. A vállalkozó anélkül építhet, hogy számlázhatna Önnek vagy bármit megsemmisíthetne.
Látja a szervezetet, annak tagjait, webhelyeit, számlázását, a csomagkatalógust, a hibajegyeket, a fordítás állapotát és az auditnaplót – és ezek közül semmit sem módosíthat. A megfelelő jogosultság olyan ügyfelek számára, akik rálátást szeretnének, auditoroknak vagy olyan érintetteknek, akiknek csak megtekintésre van szükségük.
A hozzáférés delegálása csak akkor biztonságos, ha a delegált fiókokat nehéz feltörni. A hitelesítés a Keycloak rendszeren keresztül történik a fiók minden felhasználója számára, minden felületen.
A támogatási munka néha megköveteli a fiókjába való betekintést. Erre a hozzáférésre ugyanaz az engedélyezési modell vonatkozik, mint minden másra — a munkatársak egyszerűen egy személyzeti szervezetben helyezkednek el, szűk jogosultságokkal rendelkező részlegekbe szervezve.
A munkatársak a Támogatás, Számlázás és pénzügy, Visszaélések és megbízhatóság, Értékesítés, Bevezetés, Mérnökség és üzemeltetés, Marketing, valamint Vezetőség csoportokba vannak sorolva. Mindegyik szerepkör meghatározott modulokhoz és műveletekhez biztosít hozzáférést, így a munkatárs csak az adminisztrátori felület azon részét látja, amelyre a munkájához szükség van, a többit nem.
A Támogatási ügynök szerepkör pontosan a következőket biztosítja: ügyfelek megtekintése, hibajegyek megtekintése és megválaszolása, webhelyek megtekintése, webhely újraindítása és a gyorsítótárának kiürítése. Nem tartalmaz számlázási konfigurációt, visszatérítést, csomag módosítását és flottakezelést. A hibaelhárítási intézkedéseket, amelyeket egy ügynök végrehajthat, a szerepkör korlátozza, nem pedig a jó szándék.
A(z) customer.impersonate engedély nem képezi a(z) Manager szerepkör részét — kizárólag a(z) Super Admin jogosultsággal rendelkezik vele. Amikor egy munkamenet az Ön nevében fut, a vezérlőpulton egy állandó megszemélyesítési szalaghirdetés jelenik meg, így soha nem kétséges, hogy ki jár el.
Minden jogosultsággal rendelkező és adminisztratív művelet egy csak hozzáfűzhető ellenőrzési naplóhoz adódik hozzá, amely rögzíti a cselekvőt, a műveletet, a célt, a kiegészítő metaadatokat, az IP-címet és az időbélyeget — éles környezetben idő szerint particionálva. A tulajdonosok és a csak olvasható jogosultsággal rendelkező tagok maguk is elolvashatják szervezetük naplóját.
A személyzet kényes és destruktív műveletei fokozott hitelesítést vagy két személy általi jóváhagyást igényelhetnek a futtatásuk előtt, az új részlegek és szerepkörök pedig konfiguráció, nem pedig kódmódosítás kérdései.
A parancsfájlok, a CI-folyamatok, a CLI, a Terraform szolgáltató és az AI-ügynökök mind ugyanazon engedélyezési modellen keresztül hitelesítenek, mint az emberek — nincsenek megosztott emberi hitelesítő adatok, nincsenek a buildbe illesztett, hosszú élettartamú titkok.
A kulcsok egy szervezethez tartoznak, és ugyanazokhoz az RBAC-jogosultságokhoz kötött részletes hatókörökkel rendelkeznek — csak olvasható, számlázás, kiépítés. Csak azt a szűk hatókört adja meg egy csővezetéknek, amelyre szüksége van, ne a tag teljes fiókját.
A tesztelési mód és az éles mód kulcsai elkülönülnek, így a fejlesztés alatt álló integráció véletlenül vagy másolt környezeti változó révén sem érheti el az éles adatokat.
A titkos kulcs SHA-256 hash-ét és egy keresési előtagot tárolunk — a nyers kulcsot soha. A kulcsot csak egyszer, a létrehozásakor láthatja. Minden kulcs nyomon követi, mikor használták utoljára, és önmagában visszavonható anélkül, hogy bármi mást érintene.
Az MCP-kiszolgálónk lehetővé teszi bármely MCP-képes ügynök számára, hogy természetes nyelven kezelje az Ön tárhelyét, OAuth 2.1 hitelesítéssel, a szervezetéhez és RBAC-szerepköréhez igazítva, eszközönként visszavonható tokenekkel, a destruktív műveletek megerősítésével, költési korlátokkal és teljes körű auditnaplózással.
A fiókhozzáférés és a szerverhozzáférés különböző kérdések. A webhelyszintű hitelesítő adatokat a vezérlőpulton kezelik, a legkisebb jogosultság elve alapján adják ki őket, és el vannak zárva, így egy közreműködő rendszerhéja kizárólag egyetlen webhelyhez tartozik.
Az egyéni üzemeltető egyetlen szervezetet és egyetlen tulajdonosi tagságot tart fenn, és Fejlesztő szerepkört ad hozzá, amikor egy alvállalkozó érkezik egy projektre. Amikor a projekt véget ér, a tagság törlésre kerül, és a bejelentkezésük azonnal megszűnik — nem marad hátra semmilyen megosztott hitelesítési adat, amelyet rotálni kellene.
Egy ügynökség a szervezeti fát használja. Minden ügyfél saját alszervezetet kap, amely az adott ügyfél webhelyeit tartalmazza, és az ügyfél saját munkatársai ott kapnak tagságot — csak olvasható jogosultságot a rálátást igénylő érdekelt felek számára, tulajdonosi jogosultságot az önkiszolgálást választó ügyfél számára. Az Ön munkatársai a fa felsőbb szintjein rendelkeznek tagsággal, és látják a teljes portfóliót; az ügyfél kizárólag a saját ágát látja, és a Row-Level Security biztosítja, hogy ez ne csupán ígéret, hanem valóság legyen.
A viszonteladó ugyanúgy működik, egy szinttel feljebb: a viszonteladói szervezet ügyfélszervezeteket tartalmaz, amelyek mindegyike saját tagokkal, számlázási nézettel és webhelyekkel rendelkezik. Ugyanaz az alapelem működteti az alfiókokat, az ügynökségi csapatokat és a viszonteladói hierarchiákat — egyikhez sincs külön, gyengébb mechanizmus.
Minden elérhető a bankkártya nélküli 14 napos próbaverzióban. Regisztráljon fizetési adatok megadása nélkül, hívjon meg egy kollégát, figyelje meg, hogy az egyes szerepkörök mihez férhetnek hozzá és mihez nem, valamint tekintse át saját ellenőrzési naplóját.
Jelenleg a tagság a szerepkörét a szervezetre és a hierarchiában alatta lévő minden elemre kiterjeszti, így a webhelycsoportok elkülönítésének módja a szervezetek szétválasztása — helyezze ezeket a webhelyeket a saját alszervezetükbe, és ott adja meg a tagságot. Ez egy átlátható modell az ügynökségek és a viszonteladók számára, ahol minden ügyfél már eleve külön elhatárolást igényel. A tagságonkénti erőforrás-hatókör megadása, vagyis egyetlen tagság hozzárendelése megnevezett webhelyekhez egy szervezeten belül, egy tervezett fejlesztés, nem pedig jelenleg elérhető funkció.
A Developer szerepkör nem tartalmazza a webhely törlését vagy felfüggesztését – ezek a jogosultságok az Owner szerepkörhöz tartoznak. Lehetővé teszi a webhelyek megtekintését és létrehozását, a szolgáltatások újraindítását, a gyorsítótár kiürítését, az API-kulcsok kezelését és a hibajegyek feldolgozását. A telepítési és a push-to-live engedélyek szintén nem képezik a Developer jogosultság részét, így az éles környezetbe történő közzététel a fiók tulajdonosánál marad. Párosítsa ezt staging környezettel, hogy a fejlesztési munka eleve az éles webhelyen kívül történjen.
Ez teljes mértékben a munkatársi szerepkörtől függ, és mindegyik szerepkör az engedélykulcsok szűk halmaza. Egy ügyfélszolgálati munkatárs például megtekintheti az Ön fiókját és webhelyeit, megtekintheti a hibajegyeit és válaszolhat rájuk, újraindíthat egy webhelyet és kiürítheti a gyorsítótárát – a számlázási beállításokhoz, a visszatérítésekhez, a csomagokhoz vagy a flottához azonban nem nyúlhat hozzá. Az ügyfélként történő bejelentkezés egy különálló jogosultság, amellyel csak a Super Admin rendelkezik, és amikor ez megtörténik, a vezérlőpulton egy állandó megszemélyesítési sáv jelenik meg. Minden kiemelt művelet rögzítésre kerül az auditnaplóban a végrehajtóval, a művelettel, a célponttal, az IP-címmel és az időbélyeggel együtt, és szervezete naplóját Ön is elolvashatja.
Távolítsa el a tagságot, és a hozzáférésük az adott szervezethez megszűnik — a saját identitásuk megmarad, de szerepkörük és így jogosultságaik sem lesznek a fiókjában. Az API-kulcsok visszavonása egyenként történik, így a folyamatkulcsok anélkül vonhatók vissza, hogy bármi mást zavarnának. Ha SAML egyszeri bejelentkezést használ, a személyazonosság-szolgáltatójában történő megszüntetés központilag kezeli a bejelentkezést. A webhelyszintű hitelesítő adatok, mint például az SSH-kulcsok, a vezérlőpulton vonhatók vissza, és maga az eltávolítás bekerül a naplóba.
Nem — de érdemes pontosítani, hogy miért. Az API-kulcsok a szervezethez tartoznak, nem egy adott taghoz, és a saját részletes hatóköreiket hordozzák, amelyek ugyanahhoz az engedélykatalógushoz kapcsolódnak. Így ahelyett, hogy egy személynek adna kulcsot, a feladathoz hoz létre egy kulcsot a feladat által megkövetelt legszűkebb hatókörrel, és visszavonja azt a feladat végeztével. A titkos kulcsnak csak a hash-értéke kerül tárolásra, és minden kulcs rögzíti az utolsó használat idejét, így a használaton kívüli kulcsok könnyen megtalálhatók és visszavonhatók.
Igen. Az MCP-kiszolgálónk az OAuth 2.1 segítségével hitelesíti az ügynököket, és az Ön szervezetére, valamint RBAC-szerepkörére korlátozza őket eszközönként visszavonható tokenekkel, így átfogó hozzáférés helyett egy adott jogosultságot biztosít. A destruktív műveletek megerősítést igényelnek, költési korlátok érvényesek, és minden művelet ugyanabba az ellenőrzési naplóba kerül, mint az emberi tevékenység.
A Postgres sorszintű biztonsága magában az adatbázisban a hívó szervezeti részfájára korlátozza a lekérdezéseket, ahol az alkalmazásszintű szűrő mélységi védelemként szolgál, nem pedig az egyetlen vonalként. A hatókörön kívüli rekordokra vonatkozó kérések engedélyezési hiba helyett „nem található” választ adnak vissza, így semmi sem derül ki arról, hogy mi létezik. Kiszolgálóoldalon a CageFS általi webhelyenkénti elkülönítés minden bérlő parancsértelmezőjét és fájljait a saját webhelyére korlátozza.
Igen. A 14 napos próbaverzió bankkártya nélkül igénybe vehető — fizetési adatok és kötelezettség nélkül —, és legfeljebb öt webhelyig kiterjed a Footprint-Free tárhelyre. Ez elegendő arra, hogy elköteleződés előtt meghívjon egy kollégát, kiosztson egy szerepkört, és megbizonyosodjon arról, hogy a határok az Ön igényeinek megfelelően működnek.
Kezdje a bankkártya nélkül igénybe vehető 14 napos próbaverzióval, hívjon meg valakit, és figyelje, ahogy a jogosultsági modell elvégzi a feladatát — elnevezhető szerepkörök, visszavonható hatókörök és egy auditnapló, amely pontosan rögzíti, ki mit tett.
Kezdés ingyen