Delegált hozzáférés
Hívjon be egy fejlesztőt, bízza a számlázást a könyvelőjére, biztosítson az ügyfélnek csak olvasható hozzáférést a saját webhelyeihez, vagy engedje meg a támogatási csapatunknak, hogy megvizsgáljon egy problémát. Minden egyes jogosultság egy meghatározott engedélyekkel rendelkező szerepkör, amely egy szervezetre vonatkozik, az adatbázisban érvényesül, és egy módosíthatatlan (append-only) naplóba kerül rögzítésre.
Egyetlen belépési adatok megosztása a legbiztosabb út a fiókhozzáférési problémákhoz. A Zinn Digital® platformon mindenki saját azonosítóval rendelkezik, és a hozzáférés egy tagság – egy felhasználó, egy szervezet és egy szerepkör –, amelyet külön-külön adhat meg, módosíthat vagy vonhat vissza.
Minden egyes munkatárs a saját nevében jelentkezik be a Keycloak révén, amely az azonosítási rétegünk. Senki sem gépeli be a jelszavadat, senki sem oszt meg böngészőmunkamenetet, és valakinek a eltávolítása egyetlen műveletből áll a jelszócsere és a kapkodás helyett, hogy kiderüljön, mégis ki más ismerte azt.
A fiókok hierarchikusak: egy viszonteladói szervezet ügyfélszervezeteket, az ügyfélszervezetek pedig webhelyeket tartalmaznak. A tagság egy szervezetre és az alatta lévő összes elemre vonatkozik, így átadhatja egy ügynökségi ügyfélnek a saját szervezete feletti irányítást anélkül, hogy a többi ügyfelét valaha is felfedné.
A bérlőalapú szétválasztás nem az alkalmazáskód egyik szűrője, amelyet egy hiba átugorhat. A Postgres sorszintű biztonsága (Row-Level Security) minden lekérdezést a hívó szervezetének részfájára korlátoz, így a hatókörödön kívüli kérésnek nincs mit visszaadnia.
Ha olyan szervezetet vagy webhelyet kér le, amely kívül esik az Ön hatáskörén, az API jogosultsági hiba helyett egy egyszerű nem található választ ad vissza. A jogosultsági hiba megerősítené a rekord létezését, míg a nem található válasz semmit sem árul el egy kívülállónak.
Az jogosultságok részletes kulcsok – modul és művelet, mint a sites.restart vagy a billing.refund –, és a szerepkörök összefogják őket. Négy szerepkör lefedi azokat a formákat, amelyekre a valós csapatoknak szükségük van, és mindegyik az általunk betöltött adat, nem pedig a kódba temetett logika.
Teljes körű irányítás: alárendelt szervezetek létrehozása, tagok meghívása és eltávolítása, szerepkörök módosítása, API-kulcsok kezelése, webhelyek létrehozása, újraindítása, kiürítése, felfüggesztése és törlése, számlázás és számlák kezelése, hibajegyek beküldése és az auditnapló olvasása. A szerepkört pedig önmagadnak tartod meg.
Látja a szervezetet, annak tagjait és a csomagkatalógust, emellett számlákat, fizetési módokat és terheléseket kezel. Nincs hozzáférése egyetlen webhely létrehozásához, módosításához vagy törléséhez sem – pontosan olyan jogosultságokkal bír, amilyenekkel egy külsős könyvelőnek rendelkeznie kell.
Webhelyeket tekint meg és hoz létre, újraindítja a szolgáltatásokat, törli a gyorsítótárat, kezeli az API-kulcsokat és jegyekkel dolgozik. Szándékosan kizárva: számlázás, számlák, fizetési módok, tagkezelés, webhely felfüggesztése és webhely törlése. Egy külsős szakember anélkül építhet, hogy számlázhatna Önnek vagy bármit is tönkretehetne.
Látja a szervezetet, annak tagjait, webhelyeit, számlázását, a csomagkatalógust, a jegyeket, a fordítási státuszt és a naplófájlt – de semmit sem tud módosítani. Megfelelő jogosultság egy ügyfél számára, aki rálátást szeretne, egy auditor számára, vagy egy érintett fél számára, akinek csak megtekintésre van szüksége.
A hozzáférés átruházása csak akkor biztonságos, ha azokat a fiókokat, amelyekre delegál, nehéz feltörni. A Keycloak minden egyes személy hitelesítését kezeli a fiókban, minden felületen.
Az ügyfélszolgálati munka néha azt jelenti, hogy be kell néznünk az fiókjába. Ezt a hozzáférést ugyanaz a jogosultsági modell szabályozza, mint minden mást – a munkatársak egyszerűen egy munkatársi szervezetben, szűk körű engedélyekkel rendelkező departamentumokba szervezve dolgoznak.
A munkatársak Támogatási, Számlázási és Pénzügyi, Visszaélések elleni, valamint Biztonsági és Megbízhatósági, Értékesítési, Bevezetési, Mérnöki és Üzemeltetési, Marketing, valamint Vezetési csoportokba vannak sorolva. Mindegyik szerepkör specifikus modulokat és műveleteket biztosít, így az ügyintéző a feladatához szükséges adminisztrációs konzolt látja, a többit pedig nem.
Az Ügyfélszolgálati Munkatárs szerepkör pontosan ezt biztosítja: ügyfelek megtekintése, jegyek megtekintése és megválaszolása, webhelyek megtekintése, webhely újraindítása és a gyorsítótár ürítése. Nem tartalmaz számlázási beállításokat, visszatérítési jogot, csomagok szerkesztését és flottakezelést. Az a kármentesítés, amelyet egy ügyfélszolgálati munkatárs elvégezhet, a szerepkör korlátai közé van utalva, nem pedig a jó szándékon múlik.
A customer.impersonate jogosultság nem része a Menedzser szerepkörnek – azt kizárólag a Szuperadminisztrátor birtokolja. Ha az Ön nevében fut egy munkamenet, a vezérlőpulton egy állandó megszemélyesítési szalagcím jelenik meg, így soha nem lehet kétséges, hogy ki jár el.
Minden emelt szintű és adminisztratív művelet egy kizárólag hozzáfűzhető auditálási naplóhoz adódik hozzá, amely rögzíti a végrehajtó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őalapú partícionálással. A tulajdonosok és az olvasási jogú tagok maguk is olvashatják szervezetük naplóját.
Az érzékeny és romboló jellegű munkatársi műveletek végrehajtása előtt emelt szintű hitelesítésre vagy kétfős jóváhagyásra lehet szükség, az új részlegek és szerepkörök pedig kódmódosítás helyett konfigurációval hozhatók létre.
A szkriptek, a CI-folyamatok, a CLI, a Terraform-szolgáltató és az AI-ügynökök ugyanazon engedélyezési modellen keresztül hitelesítik magukat, mint az emberek – nincsenek megosztott emberi hitelesítő adatok, és nincsenek buildbe beillesztett, hosszú élettartamú titkok.
A kulcsok szervezetekhez tartoznak, és az azonos RBAC-engedélyekhez kötött részletes hatáskörökkel – csak olvasási, számlázási, kiépítési – rendelkeznek. Adjon egy folyamatnak a teljesfokú fiókhozzáférés helyett a szükséges szűk hatáskört.
A teszt és az éles módú kulcsok különállnak, így a fejlesztés alatt álló integráció véletlenül vagy átmásolt környezeti változó révén sem érheti el az éles adatokat.
A titok SHA-256-os hash-ét és egy keresési előtagot tárolunk – a nyers kulcsot soha. A kulcsot a létrehozásakor egyszer láthatja. Minden kulcs nyomon követi az utolsó használat idejét, és bármi más megzavarása nélkül külön visszavonható.
Az MCP szerverünk lehetővé teszi, hogy bármilyen MCP-képes ágens természetes nyelven kezelje a tárhelyét. A hitelesítés OAuth 2.1-gyel történik, az engedélyek pedig az Ön szervezetére és RBAC-szerepkörére szólnak, eszközönként visszavonható tokenekkel, a romboló műveletek előtti jóváhagyással, költségkeretekkel és teljes körű naplózással.
A fiókhozzáférés és a szerverhozzáférés két különböző probléma. A webhely szintű hitelesítő adatok a vezérlőpultról kezelhetők, a legkisebb jogosultság elve alapján kerülnek kiadásra, és el vannak különítve, így egy munkatárs shellje pontosan egy webhely shellje.
Az egyszemélyes üzemeltető egyetlen szervezettel és egyetlen tulajdonosi tagsággal rendelkezik, és egy fejlesztői szerepkört ad hozzá, amikor egy külsős szakember érkezik egy projekthez. Amikor a projekt véget ér, a tagság megszűnik, és a bejelentkezésük azonnal leáll – nem marad hátra megosztott hitelesítő adat, amelyet le kellene cserélni.
Egy ügynökség a szervezeti fát használja. Minden ügyfél saját al-szervezetet kap, amely az adott ügyfél webhelyeit tartalmazza, és magának az ügyfélnek a munkatársai ott kapnak tagságot – írásvédettet az érdekelt számára, aki rálátást szeretne, és tulajdonost az ügyfél számára, aki önkiszolgálást akar. Az ön személyzete feljebb rendelkezik tagsággal a fában, és látja a portfóliót; az ügyfél csak a saját ágát látja, és a sorszintű biztonság az, ami ezt valósággá teszi egy ígéret helyett.
Egy viszonteladó ugyanúgy működik, csak egy szinttel feljebb: egy viszonteladói szervezet ügyfélszervezeteket foglal magában, amelyek mindegyike saját tagokkal, számlázási nézettel és webhelyekkel rendelkezik. Ugyanez az alapvető mechanizmus hajtja az aliókonkst, az ügynökségi csapatokat és a viszonteladói hierarchiákat – egyikükhöz sincsen különálló, gyengébb megoldás.
Minden elérhető a kártya nélkül igénybe vehető 14 napos próbaidőszak alatt. Regisztráljon fizetési adatok nélkül, hívjon meg egy kollégát, nézze meg, hogy az egyes szerepkörök mit érhetnek el és mit nem, és olvassa vissza saját auditnaplóját.
Ma egy tagság szerepkört biztosít egy szervezetben és mindenben, ami alatta van a fában, így a webhelycsoportok szétválasztásának módja a szervezetek különválasztása – helyezze el ezeket a webhelyeket a saját al-szervezetükben, és ott adja meg a tagságot. Ez egy tiszta modell ügynökségek és viszonteladók számára, ahol minden ügyfél eleve a saját határvonalát akarja. A tagságonkénti erőforrás-határolás, vagyis egyetlen tagság rögzítése egy szervezeten belüli elnevezett webhelyekhez, egy tervezett finomítás, és nem valami, ami jelenleg elérhető.
A Fejlesztő szerepkörhöz nem tartozik webhelytörlés vagy -felfüggesztés – ezek a kulcsok a Tulajdonos szerepkörhöz tartoznak. Lehetőséget biztosít webhelyek megtekintésére és létrehozására, szolgáltatások újraindítására, gyorsítótár-ürítésre, API-kulcsok kezelésére és a hibajegyekkel való munkára. A központi kiszolgálásra (deployment) és az éles környezetbe küldésre vonatkozó engedélyek szintén nem része a Fejlesztő jogosultságcsomagjának, így a termelési környezetbe való léptetés a fióktulajdonosnál marad. Párosítsa ezt a tesztkörnyezettel, hogy az építési munkálatok eleve az éles webhelyen kívül történjenek.
Ez teljesen a munkatársi szerepkörtől függ, és minden szerepkör a engedélykulcsok szűk halmaza. Egy ügyfélszolgálati munkatárs például megtekintheti az fiókját és webhelyeit, megtekintheti és megválaszolhatja a jegyeit, újraindíthat egy webhelyet, és kiürítheti annak gyorsítótárát – de nem nyúlhat a számlázási konfigurációhoz, a visszatérítésekhez, a csomagokhoz vagy a flottához. Az ügyfélként való bejelentkezés egy külön engedély, amellyel csak a Szuperadminisztrátor rendelkezik, és amikor ez megtörténik, a vezérlőpult egy folyamatos megszemélyesítési szalagot jelenít meg. Minden emelt szintű műveletet rögzítenek a naplóban a végrehajtóval, a művelettel, a céllal, az IP-címmel és az időbélyeggel együtt, és a szervezet naplóját saját maga is olvashatja.
Távolítsa el a tagságot, és ezzel megszűnik a hozzáférésük ahhoz a szervezethez – továbbra is megvan a saját identitásuk, de nincs szerepkörük, így semmilyen jogosultságuk sincs az Ön fiókjában. Az API-kulcsok visszavonása egyenként történik, így egy pipeline kulcs anélkül eltávolítható, hogy az bármi mást megzavarna. Ha SAML egyszeri bejelentkezést használ, a központi identitásszolgáltatóban végzett megszüntetés központilag kezeli a bejelentkezést. A webhelyszintű hitelesítő adatok, például az SSH-kulcsok a irányítópulton vonhatók vissza, és magáról a eltávolításról naplózott auditálás készül.
Nem — de érdemes pontosan megérteni, hogy miért. Az API-kulcsok a szervezethez tartoznak, nem egy-egy taghoz, és saját, a jogosultsági katalógushoz kötött, részletes hatáskörökkel rendelkeznek. Így ahelyett, hogy valakinek átadnának egy kulcsot, létre kell hozni egy kulcsot az elvégzendő feladathoz a feladat által megkövetelt legszűkebb hatáskörrel, és visszavonni azt a feladat végén. 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 nem használt kulcsok könnyen azonosíthatók és visszavonhatók.
Igen. Az MCP szerverünk OAuth 2.1-gyel hitelesíti az ügynököket, és a szervezetéhez, valamint az RBAC-szerepköréhez rendeli őket eszközönként visszavonható tokenekkel, így átfogó hozzáférés helyett egyedi képességeket engedélyezhet. A romboló műveletek jóváhagyást igényelnek, kiadási limitek érvényesülnek, és minden egyes művelet ugyanabba az auditnaplóba kerül, mint az emberi tevékenység.
A Postgres sor szintű biztonsága (Row-Level Security) az adatbázisban közvetlenül a hívó szervezet részfájára korlátozza a lekérdezéseket, így az alkalmazásszintű szűrő csak mélységi védelemként szolgál az első vonal helyett. A hatáskörön kívüli rekordokra vonatkozó kérések jogosultsági hiba helyett „nem található” választ adnak, így semmi sem derül ki arról, hogy mi létezik. Szerver oldalon a CageFS-en keresztül megvalósított webhelyenkénti elszigetelés minden bérlő shelljét és fájljait a saját webhelyén tartja.
Igen. A 14 napos próbaidőszak kártya nélkül vehető igénybe – nincs szükség fizetési adatokra, sem elköteleződésre –, és a Footprint-Free Hosting szolgáltatást fedi le legfeljebb öt webhelyhez. Ez elegendő ahhoz, hogy meghívjon egy kollégát, hozzárendeljen egy szerepkört, és megbizonyosodjon arról, hogy a határok az elvárásoknak megfelelően működnek, mielőtt elkötelezné magát.
Kezdje meg a kártyamentes, 14 napos próbaidőszakot, hívjon meg valakit, és figyelje, ahogy a jogosultságkezelési modell teszi a dolgát – elnevezhető szerepkörök, visszavonható hatókörök és egy naplófájl, amely pontosan megmutatja, ki mit csinált.
Kezdje ingyen