Fiókbiztonság
A szerverbiztonság védi a webhelyeket. A fiókbiztonság védi azok kulcsait. Minden Zinn Digital® bejelentkezés egyetlen szabványalapú identitásrendszeren fut – kulcsokon és WebAuthn technológián, TOTP kétlépcsős azonosítción, varázslinkes bejelentkezésen, valamint vállalati és ügynökségi csapatoknak szóló SAML SSO-n keresztül –, részletes szerepkörökkel, szervezetenkénti API-kulcsokkal és egy módosíthatatlan naplóval a háttérben.
A legtöbb tárhelyfiók egy adatbázisban lévő jelszó, egy vezérlőpulthoz csavarozva. A miénk egy dedikált identitásrendszer – Keycloak, OIDC és SAML protokollokat használva –, amely minden előtt ott van: az ügyféli irányítópult, a munkatársi adminisztrációs konzol, ez a nyilvános webhely és tudásbázis, valamint az Ön támogatási jegyai. Jelentkezzen be egyszer, és máris be van jelentkezve mindegyikbe.
Mivel nyílt szabványokon alapul, nem pedig egy zárt rendszerű bejelentkezésen, az identitásréteg ugyanúgy cserélhető, mint a platform minden más összetevője. Hozzáférési modelled egyetlen része sincs egy gyártó termékébe zárva, és a csapatod hitelesítése sem függ attól, hogy egyetlen beszállítót fenntartunk-e. Ez ugyanaz a zárolásmentességi elv, amelyet a CDN-fiókokra, a DNS-re és a fizetési szolgáltatókra is alkalmazunk.
A bejelentkezés lokalizált, és a webhelyről a bejelentkezési képernyőre való átlépés magával hozza az Ön nyelvét is – így a különböző országokban szétszórt csapatoknak nem kell egy kizárólag angol nyelvű bejelentkezésen keresztülmenniük.
Négy módszer, mind első osztályú, mindegyik személyre szabható. Senki sincs rákényszerítve a leggyengébb opcióra amiatt, mert az az egyetlen kínálatban.
Add meg az e-mail címed, kattints a linkre, és már bent vagy. Nincs adathalászatra csábító, újrahasznosított vagy adatbeszivárgás során kiszivárgó jelszó. Ez az alapértelmezett útvonal az új fiókok számára, és a legtöbb embernek ez az egyetlen, amire valaha szüksége lesz.
Regisztráljon egy jelkulcsot – Touch ID, Face ID, Windows Hello vagy egy hardverkulcs, például YubiKey –, és jelentkezzen be teljesen jelszó nélkül. A jelkulcsok az eredeti forráshoz vannak kötve, így egy adathalász bejelentkezési oldal nem tudja megszerezni azokat. A platform elfogadja az ES256 és RS256 hitelesítőket, és előnyben részesíti a felhasználói azonosítást.
Jelentkezzen be a Google fiókkal egy szabványos identitásszolgáltató-kapcsolaton keresztül, így a fiók örökli mindazokat a vezérlőket, amelyeket a Google Workspace már érvényesít. További szolgáltatók ugyanilyen módon csatlakoznak – ebben nincsen semmi egyedi integráció.
Megőrizve azoknak az embereknek és szkripteknek, akiknek szükségük van rá, és egy valós szabályhoz kötve: minimum tizenkét karakter, soha ne legyen a felhasználóneved vagy az e-mail címed, az utolsó három jelszavad nem használhatod újra, Argon2-vel hashelve. Az e-mail címek hitelesítésre kerülnek, mielőtt egy fiók használhatóvá válna.
A második tényezők az identitásrendszer részét képezik, nem pedig egy megvásárolható kiegészítő vagy egy önállóan a saját webhelyére telepíthető bővítmény.
Ha az szervezeted már használ egy identitásszolgáltatót – Okta, Entra ID, Google Workspace vagy bármi mást, amely SAML-alapú –, egyszerűen összekapcsolhatod vele, és a munkatársaid a meglévő vállalati adataikkal tudnak bejelentkezni a Zinn Digital® platformra. A csapatodnak nem kell újabb jelszót kezelnie, és nem marad ki egyetlen teendő sem a kilépési folyamatból sem.
Ez ügynökségi és viszonteladói szinten a legfontosabb, ahol a fluktuáció valódi biztonsági kockázatot jelent. Amikor valaki távozik, és letiltja a címtárában, ezzel a tárhelyhez vezető útját is letiltja. A hozzáférés központilag követi a munkaviszonyt, ahelyett hogy egy tucat SaaS-eszközben kellene utána menni.
A SAML nem váltja fel a többi bejelentkezési módot, hanem kiegészíti azokat: a külsős alvállalkozók továbbra is kaphatnak egyedi hatókörű varázslatos hivatkozással (magic link) elérhető fiókot, míg az állandó alkalmazottak az SSO-n keresztül lépnek be. Egy szervezet, egy engedélyezési modell, két bejárat.
A hozzáférés a szervezeti fán – a viszonteladótól az ügyfélen át a webhelyig – van hatókörre korlátozva, és nemcsak az alkalmazásban, hanem magában az adatbázisban is sor szintű biztonsággal van érvényesítve. A bérlők közötti hozzáférés nem egy olyan irányelv, amelynek betartását tiszteletben kell tartatni a felhasználókkal, hanem egy olyan lekérdezés, amely nem tud sorokat visszaadni. Négy ügyfélszerepkör fedi le a feladatok reális megosztását.
Teljes körű ellenőrzés a szervezet és al-fiókjai felett: gyermek szervezetek létrehozása, tagok meghívása és eltávolítása, szerepkörök hozzárendelése, minden webhely kezelése, számlázás és díjbekérők kezelése, API-kulcsok kezelése, valamint a naplófájlok olvasása.
Számlák, előfizetések, fizetési módok és a csomagkatalógus – és semmi más. A pénzügyes kollégája vagy könyvelője anélkül rendezheti a számlákat, hogy valaha is jogköre lenne egy éles webhely módosítására, felfüggesztésére vagy törlésére.
Webhelyek é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 kezelése és hibajegyek megválaszolása. Szándékosan nincs hozzáférés a fizetési módokhoz, a számlázáshoz vagy a csomagváltáshoz.
Csak megtekintés a szervezet egészén belül – webhelyek, számlázás, csomagok, jegyek, fordítási státusz és a naplózási adatok. A megfelelő szerepkör egy auditor, a rálátást igénylő ügyfél vagy egy első heti új belépő számára.
A vezérlőpult csak az egyik belépési pont. Az API, a CLI, a Terraform szolgáltató és az MCP-kiszolgáló a többi – és ezekre ugyanaz a hozzáférési modell vonatkozik, mert egy hatókör nélküli kulcs az összes újonnan konfigurált szerepkör megkerülését jelenti.
Az API-kulcsot egy szervezetnek, nem pedig egyéni személynek adják ki, és saját hatáskörökkel (scope) rendelkezik. Kezelje megosztott hitelesítési adatként: nevezze el a célja szerint, adja meg neki a legszűkebb működő hatásköröket, és cserélje le, amikor az azt létrehozó személy távozik.
A nyers kulcsot csak a létrehozás pillanatában mutatjuk meg. Amit tárolunk, az egy SHA-256-hash és egy rövid előtag a kereséshez. A kulcsot nem tudjuk újra megmutatni, és egy adatbázis-biztonsági rés sem ad a támadó kezébe működő hitelesítő adatokat.
Minden kulcs részletes hatókörökkel rendelkezik, amelyek ugyanahhoz a jogosultsági katalógushoz kapcsolódnak, amelyet a szerepkörök is használnak, rögzíti a legutóbbi használat időpontját, és azonnal visszavonható, amint gyanússá válik. A különálló tesztkulcsok valós számlázás vagy kiépítés nélkül hívják az API-t.
Az MCP szerver lehetővé teszi bármely MCP-képes ügynök számára a tárhelyed kezelését – és OAuth 2.1-en keresztül hitelesít, a szervezetedre és annak RBAC-jogosultságaira szűkítve, eszközönként visszavonható tokenekkel, a romboló műveletek előtti jóváhagyással, költségkeretekkel és teljes körű auditnaplózással. Egy AI-asszisztens csatlakoztatása nem jelenti azt, hogy mindent átadsz neki.
Minden emelt szintű művelet egy csak hozzáfűzhető bejegyzést hoz létre – ki csinálta, mit csinált, mihez csinálta, a háttérben álló bizonyítékot, valamint a forrás IP-címet, időbélyeggel ellátva. Ez nem egy hibakeresési kényelmi funkció; ez a bizonyítéklánc.
Nem — és inkább azt szeretnénk, ha nem tenné. A varázslinkes e-mailes bejelentkezés az alapértelmezett, és regisztrálhatsz egy hozzáférési kulcsot (Touch ID, Face ID, Windows Hello vagy hardverkulcs), amellyel jelszó beállítása nélkül jelentkezhetsz be. Az e-cím és jelszó opció tartalékként megmaradt, legalább tizenสอง karakteres minimummal, az utolsó három jelszó újrafelhasználásának tilalmával és Argon2 hasheléssel.
A TOTP alapú kétlépcsős azonosítás beépül az identitásrétegbe, és a szervezet egészére érvényesíthető szabályzattal, ahelyett hogy az egyes tagok döntésére lenné bízva. A kulcsok (passkeys) erősebb opciót jelentenek, ha a csapatod eszközei támogatják őket, mivel megszüntetik a jelszót, amelyre a támadó adathalászatot folytatna.
Igen. A Számlázási menedzser 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 – nincs lehetőség webhely megtekintésére, üzembe helyezésére, újraindítására, felfüggesztésére vagy törlésére. Ez fordítva is igaz: a Fejlesztő szerepkör a webhelyeket és az API-hozzáférést kezeli, számlázási felügyelet nélkül. A szerepkörök szervezetenként vannak hozzárendelve, így egy szervezetben betöltött szerepkör nem ad hozzáférést egy másik, független szervezethez – bár a szülőszervezetben lévő szerepkör érvényes az alá beágyazott szervezetekre is.
Vond vissza a irányítópultról, és azonnal leáll. A kár mértéke korlátozva van ahhoz, amire az a kulcs eredetileg képes volt; ezért rendelkeznek a kulcsok részletes hatókörökkel é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 teszik a szivárgást korlátozott incidenssé a teljes fiókkompromittálás helyett. Ne feledje, hogy a kulcsokat a szervezethez, nem pedig az egyes személyekhez adjuk ki, ezért kezelje őket megosztott hitelesítő adatokként, és cserélje le őket a személyzet változásakor. Nálunk csak a kulcs hash értéke van tárolva, így az adatbázisunkból történő szivárgás nem eredményez használható hitelesítő adatot.
Igen. Minden emelt szintű műveletet egy csak hozzáfűzhető auditnapló rögzít a végrehajtóval, a művelettel, a céllal, az alátámasztó bizonyítékkal, a forrás IP-címmel és egy időbélyeggel. A tulajdonosi és csak olvasható szerepkörök közvetlenül olvashatják. A munkatársak fiókján végzett műveletei ugyanebben a naplóban szerepelnek, az érzékeny vagy destruktív munkatársi műveletekhez pedig először emelt szintű hitelesítésre vagy kétemberes jóváhagyásra lehet szükség.
Igen – a SAML SSO támogatott a vállalati és ügynökségi fiókok esetében, így a munkatársai a meglévő vállalati hitelesítő adataikkal azonosíthatják magukat, és a címtárából való törlésük itt is megszünteti a hozzáférésüket. A megközelítéseket kombinálhatja is: SSO az állandó munkatársaknak, hatáskörhöz kötött varázslinkes fiókok a külsős alvállalkozóknak, mindez ugyanazon engedélyezési modellen belül.
Nem — a jelszavak szándékosan nincsenek migrálva. A fiókja jelszó nélkül kerül importálásra, és az első bejelentkezéskor vagy varázslinket használ, vagy új jelszaszt állít be az aktuális irányelv szerint. A régi jelszó-hash-ek átvitele régi gyengeségeket hozna át egy új rendszerbe, ezért ezt nem tesszük meg.
A Footprint-Free próbaidőszak 14 napos, kártya nélkül igénybe vehető, és legfeljebb öt webhelyet fed le. A próbaidőszak alatt a teljes identitásréteget megkapja – a passkey-kat, a kétlépcsős azonosítást, a szerepköröket, az API-kulcsokat és a auditálási naplót nem korlátozzák fizetős csomagra.
Regisztráljon egy jelkulcsot, hívja meg csapatát a megfelelő szerepkörökbe, és állítson ki egy korlátozott hatókörű API-kulcsot – mindezt egy 14 napos, kártya nélküli próbaidőszak alatt, bankkártyaadatok megadása nélkül.
Kezdje ingyen