Fiókbiztonság
A szerverbiztonság védi a webhelyeket. A fiókbiztonság védi a hozzájuk tartozó kulcsokat. Minden Zinn Digital®-bejelentkezés egyetlen, szabványokon alapuló személyazonossági rendszeren fut — jelkulcsok és WebAuthn, TOTP kétlépcsős azonosítás, varázshivatkozásos bejelentkezés, SAML SSO vállalati és ügynökségi csapatok számára —, mögötte részletes szerepkörökkel, szervezetenkénti API-kulcsokkal és egy csak hozzáfűzhető ellenőrzési naplóval.
A legtöbb tárhelyfiók csupán egy adatbázisban tárolt jelszó, amely egy vezérlőpulthoz kapcsolódik. A miénk egy dedikált azonosítórendszer — a Keycloak, amely támogatja az OIDC és SAML protokollokat —, amely minden előtt ott áll: az ügyféli irányítópult, a munkatársi adminisztrációs konzol, e nyilvános webhely és tudásbázis, valamint az Ön támogatási jegyei előtt. Jelentkezzen be egyszer, és máris bejelentkezett mindegyikbe.
Mivel nyílt szabványokra épül ahelyett, hogy zárt forráskódú bejelentkezést használna, az identitásréteg ugyanúgy kicserélhető, mint a platform bármely más összetevője. A hozzáférési modelljének egyetlen része sincs egyetlen szállító termékébe zárva, és a csapata hitelesítése sem függ attól, hogy mi egyetlen beszállítót tartunk-e meg. Ugyanezt a függőségmentességi elvet alkalmazzuk a CDN-fiókokra, a DNS-re és a fizetési szolgáltatókra is.
A bejelentkezés lokalizált, és az oldalról a bejelentkezési képernyőre történő átlépéskor megmarad az Ön által választott nyelv — így a különböző országokban működő csapatoknak sem kell a kizárólag angol nyelvű bejelentkezést használniuk.
Négy módszer, mindegyik elsőrangú, és mindegyik személyenként testreszabható. Senki sincs rákényszerítve a leggyengébb lehetőségre pusztán azért, mert csak az érhető el.
Adja meg e-mail-címét, kattintson a hivatkozásra, és már be is lépett. Nincs jelszó, amelyet adathalászattal megszerezhetnének, újra felhasználnának, vagy amely adatszivárgás során kikerülhetne. Ez az alapértelmezett eljárás az új fiókok esetében, és a legtöbb ember számára ez az egyetlen, amire valaha szüksége lesz.
Regisztráljon egy jelszókulcsot (passkey) — Touch ID-t, Face ID-t, Windows Hellót vagy egy hardveres kulcsot, például YubiKeyt —, és jelentkezzen be jelszó nélkül. A jelszókulcsok a forráshoz vannak kötve, így egy megtévesztő bejelentkezési oldal nem képes megszerezni őket. A platform támogatja az ES256 és RS256 hitelesítőket, és előnyben részesíti a felhasználó-ellenőrzést.
Jelentkezzen be a Google segítségével egy szabványos személyazonosság-szolgáltatói kapcsolaton keresztül, így a fiók átveszi mindazokat az ellenőrzéseket, amelyeket a Google Workspace már érvényesít. További szolgáltatók ugyanígy csatlakoznak — semmi sem egyedi integráció benne.
Megőrizve azon személyek és parancsfájlok számára, amelyeknek szükségük van rá, és valódi szabályzatnak megfelelően: legalább tizenkét karakter, soha nem az Ön felhasználóneve vagy e-mail-címe, a legutóbbi három jelszó újbóli használatának tilalma, Argon2 algoritmussal hashelve. Az e-mail-címek ellenőrzése megtörténik, mielőtt a fiók használhatóvá válna.
A második hitelesítési tényezők az azonossági rendszer részét képezik, nem pedig egy megvásárolható kiegészítő vagy egy saját webhelyére telepíthető beépülő modul.
Amennyiben szervezete már használ identitásszolgáltatót — az Okta, az Entra ID, a Google Workspace rendszert vagy bármi mást, amely támogatja a SAML protokollt —, csatlakoztassa azt, és munkatársai a meglévő vállalati hitelesítési adataikkal jelentkezhetnek be a Zinn Digital® felületére. Csapatának nem kell egy második jelszót kezelnie, és nincs második kiléptetési ellenőrzőlista sem, amelyet el lehetne felejteni.
Ez leginkább ügynökségi és viszonteladói szinten számít, ahol a munkatársak cserélődése valódi biztonsági eseménynek minősül. Amikor valaki távozik, és Ön letiltja őt a címtárában, egyúttal a tárhelyéhez vezető útját is letiltotta. A hozzáférés központilag követi a munkaviszonyt, ahelyett hogy egy tucat SaaS-eszközben kellene felkutatni.
A SAML mindemellett párhuzamosan működik, nem pedig felváltja azt: a külsős munkatársak továbbra is kaphatnak egy korlátozott szerepkörön belüli varázshivatkozásos (magic-link) fiókot, míg az állandó személyzet SSO-n keresztül lép be. Egy szervezet, egy engedélyezési modell, két bejárati ajtó.
A hozzáférés a szervezeti fára korlátozódik — a viszonteladótól az ügyfélig, majd a webhelyig —, és közvetlenül az adatbázisban, sorszintű biztonság révén érvényesül, nem csupán az alkalmazásban. A bérlők közötti hozzáférés nem egy olyan szabályzat, amelynek betartását kérjük; ez egy olyan lekérdezés, amely nem adhat vissza sorokat. Négy ügyfélszerepkör fedi le a feladatok reális megosztását.
Teljes ellenőrzés a szervezet és annak al-fiókjai felett: hozzon létre alszervezeteket, hívjon meg és távolítson el tagokat, rendeljen hozzá szerepköröket, kezeljen minden webhelyet, végezze el a számlázást, kezelje az API-kulcsokat, és tekintse meg az auditnaplót.
Számlák, előfizetések, fizetési módok és a csomagkatalógus — és semmi más. Pénzügyi munkatársa vagy könyvelője anélkül rendezheti a számlákat, hogy bármikor is lehetősége lenne egy éles webhely módosítására, felfüggesztésére vagy törlésére.
Webhely- és API-hozzáférés számlázási felügyelet nélkül: webhelyek megtekintése és kiépítése, szolgáltatások újraindítása, gyorsítótárak törlése, API-kulcsok és munkajegyek kezelése. Szándékosan nincs hozzáférés a fizetési módokhoz, a számlázáshoz vagy a díjcsomag-módosításokhoz.
Csak megtekintés a teljes szervezetben — webhelyek, számlázás, csomagok, hibajegyek, fordítási állapot és a naplóbejegyzések. Megfelelő szerepkör egy auditor, átláthatóságot igénylő ügyfél vagy az első hetét töltő új belépő számára.
A vezérlőpult egy lehetséges belépési pont. Az API, a CLI, a Terraform szolgáltató és az MCP kiszolgáló további lehetőségek — és ezekre ugyanaz a hozzáférési modell vonatkozik, mivel egy hatókör nélküli kulcs megkerüli az Ön által az imént konfigurált összes szerepkört.
Az API-kulcsot egy szervezetnek állítják ki, nem pedig egy magánszemélynek, és saját hatókörökkel rendelkezik. Kezelje megosztott hitelesítő adatként: nevezze el a céljának megfelelően, biztosítsa számára a legszűkebb működőképes hatóköröket, és cserélje le, amikor a létrehozó személy távozik.
A nyers kulcsot csak egyszer jelenítjük meg Önnek, a létrehozásakor. Amit tárolunk, az egy SHA-256 hash és egy rövid előtag a kereséshez. A kulcsot nem tudjuk újra megjeleníteni Önnek, és az adatbázis sérülése esetén a támadó nem jut működőképes hitelesítő adatokhoz.
Minden kulcs a szerepkörök által használt engedélykatalógushoz kapcsolódó, részletes hatókörökkel rendelkezik, rögzíti az utolsó használat idejét, és azonnal visszavonható, amint gyanúsnak tűnik. Különálló sandbox kulcsok tesztelik az API-t valódi számlázás vagy erőforrás-kiosztás nélkül.
Az MCP-kiszolgáló lehetővé teszi bármely MCP-képes ügynök számára az Ön tárhelyének kezelését — és az OAuth 2.1-en keresztül hitelesít, az Ön szervezetére és annak RBAC-jogosultságaira korlátozva, 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ű ellenőrzési naplózással. Egy AI-asszisztens csatlakoztatása nem jelenti azt, hogy átadja neki a kulcsot mindenhez.
Minden kiemelt jogosultságú művelet egy csak hozzáfűzhető bejegyzést rögzít — ki végezte, mit tett, min végezte el, a megerősítő bizonyítékokat és a forrás IP-címet, időbélyeggel ellátva. Ez nem hibakeresési kényelmi funkció; ez a bizonyítási lánc.
Nem — és inkább azt szeretnénk, ha nem tenné. Az e-mailben küldött varázshivatkozással (magic link) történő bejelentkezés az alapértelmezett, és regisztrálhat egy hozzáférési kulcsot (Touch ID, Face ID, Windows Hello vagy hardverkulcs), amellyel anélkül jelentkezhet be, hogy valaha is jelszót állított volna be. Az e-mail-cím és jelszó továbbra is elérhető tartalékként, legalább tizenkét karakteres hosszal, az utolsó három jelszó újrafelhasználásának tilalmával és Argon2 hash-eléssel.
A TOTP kétlépcsős azonosítás be van építve a személyazonossági rétegbe, és szervezeti szintű házirenddel kötelezővé tehető, ahelyett, hogy az egyes tagok egyéni döntésére lenne bízva. A hozzáférési kulcsok (passkeys) biztonságosabb lehetőséget jelentenek, amennyiben a csapata eszközei támogatják azokat, mivel megszüntetik azt a jelszót, amelyet egy támadó adathalászattal próbálna megszerezni.
Igen. A számlázási kezelő (Billing Manager) szerepkör hozzáférést biztosít a számlákhoz, előfizetésekhez, fizetési módokhoz és a csomagkatalógushoz, és semmi máshoz — nem teszi lehetővé a webhelyek megtekintését, létrehozását, újraindítását, felfüggesztését vagy törlését. Ez fordítva is érvényes: a fejlesztő (Developer) szerepkör kezeli a webhelyeket és az API-hozzáférést, mindennemű számlázási felügyelet nélkül. A szerepkörök kiosztása szervezetenként történik, így egy szervezetben betöltött szerepkör nem biztosít hozzáférést egy különálló, független szervezetben — bár a szülőszervezetben lévő szerepkör érvényes az alá beágyazott szervezetekre is.
Vonja vissza a vezérlőpultról, és azonnal megszűnik a működése. A kár mértékét az határozza meg, hogy a kulcs eleve mire adott jogosultságot, ezért a kulcsok részletes hatókörökkel rendelkeznek, és rögzítik az utolsó használat időbélyegét — a szűk hatókörök és a látható használati előzmények alakítják a szivárgást lokalizált incidenssé ahelyett, hogy a teljes fiók kompromittálódna. Vegye figyelembe, hogy a kulcsokat a szervezet, és nem egyéni felhasználók számára állítjuk ki, ezért kezelje őket megosztott hitelesítő adatokként, és forgassa őket, amikor a munkatársak távoznak. Nálunk csak a kulcs kivonata (hash) tárolódik, így az adatbázisunkból származó esetleges szivárgás nem hoz létre működőképes hitelesítő adatot.
Igen. Minden kiemelt jogosultságú művelet egy kizárólag hozzáfűzéssel bővíthető auditnaplóba kerül rögzítésre a végrehajtóval, a művelettel, a célponttal, az alátámasztó bizonyítékokkal, a forrás IP-címmel és az időbélyegzővel együtt. A tulajdonosi és a csak olvasható szerepkörök közvetlenül olvashatják azt. A személyzet fiókjában végzett műveletei ugyanabban a nyomkövetési naplóban kerülnek rögzítésre, és a személyzet érzékeny vagy destruktív műveletei előzetesen többlépcsős hitelesítést vagy két személy jóváhagyását tehetik szükségessé.
Igen — a SAML SSO támogatott a vállalati és ügynökségi fiókok esetében, így munkatársai a meglévő vállalati hitelesítő adataikkal azonosíthatják magukat, és a címtárból történő kiléptetésük itteni hozzáférésüket is megszünteti. A megközelítéseket kombinálhatja: SSO az állandó személyzet számára, meghatározott hatókörű magic-link fiókok a vállalkozók számára, mindez ugyanazon jogosultsági modellen belül.
Nem — a jelszavak szándékosan nem kerülnek áttelepítésre. Fiókját jelszó nélkül importáljuk, és az első bejelentkezéskor vagy egy varázshivatkozást használ, vagy új jelszót állít be a jelenlegi irányelveknek megfelelően. A régi jelszó-hashek átvitele régi gyengeségeket vinne át az új rendszerbe, ezért ezt nem tesszük meg.
A Footprint-Free próbaverziója 14 napos, nem igényel kártyát, és legfeljebb öt webhelyet fed le. A próbaidőszak alatt a teljes identitásréteget megkapja — a hozzáférési kulcsok, a kétlépcsős azonosítás, a szerepkörök, az API-kulcsok és az ellenőrzési napló nincsenek fizetős csomag mögé zárva.
Regisztráljon egy jelkulcsot, hívja meg csapatát a megfelelő szerepkörökbe, és hozzon létre egy meghatározott hatókörű API-kulcsot – mindezt egy 14 napos próbaidőszak keretében, bankkártyaadatok megadása nélkül.
Kezdés ingyen