Zabezpečení účtu
Zabezpečení serveru chrání weby. Zabezpečení účtu chrání klíče k nim. Každé přihlášení do Zinn Digital® funguje na jediném identitním systému založeném na standardech – přístupové klíče a WebAuthn, dvoufázové ověřování pomocí TOTP, přihlášení pomocí magického odkazu, SAML SSO pro firemní a agenturní týmy – za nímž stojí granulární role, API klíče pro jednotlivé organizace a protokol auditu pouze pro čtení.
Většina hostingových účtů představuje heslo v databázi připojené k ovládacímu panelu. Náš systém je vyhrazená identita – Keycloak podporující OIDC a SAML –, která stojí přede vším: před zákaznickým panelem, administrátorskou konzolí pro zaměstnance, tímto veřejným webem a znalostní bází i před vašimi lístky podpory. Přihlaste se jednou a budete přihlášeni ve všech z nich.
Protože je postaveno na otevřených standardech namísto proprietárního přihlašování, identitní vrstva je vyměnitelná stejně jako každý jiný komponent platformy. Žádná část vašeho přístupového modelu není uvězněna v produktu dodavatele a autentizace vašeho týmu nijak nezávisí na tom, zda si udržíme jednoho dodavatele. To je stejný princip bez vendor lock-inu, jaký uplatňujeme u účtů CDN, DNS a platebních brán.
Přihlášení je lokalizované a předání z webu na přihlašovací obrazovku s sebou nese váš jazyk – takže tým v různých zemích není nucen procházet přihlášením pouze v angličtině.
Čtyři metody, všechny prvotřídní, všechny nastavitelné pro každou osobu. Nikdo není tlačen do nejslabší varianty jen proto, že je to jediná nabídka.
Zadejte svůj e-mail, klikněte na odkaz a jste tam. Žádné heslo, které by šlo ukrást phishingem, používat opakovaně nebo nechat uniknout při narušení bezpečnosti. Toto je výchozí cesta pro nové účty a pro většinu lidí je to jediná cesta, kterou kdy budou potřebovat.
Zaregistrujte si přístupový klíč – Touch ID, Face ID, Windows Hello nebo hardwarový klíč, jako je YubiKey – a přihlašujte se zcela bez hesla. Přístupové klíče jsou vázané na zdroj, takže podvržená přihlašovací stránka je nemůže získat. Platforma přijímá autentizátory ES256 a RS256 a upřednostňuje ověření uživatele.
Přihlaste se pomocí Google prostřednictvím standardního připojení poskytovatelem identity, takže účet přebírá veškerá řízení, která už váš Google Workspace vynucuje. Další poskytovatelé se připojují stejným způsobem – nejedná se o žádnou zakázkovou integraci.
Zachováno pro lidi a skripty, kteří to potřebují, a podléhající skutečné zásadě: minimálně dvanáct znaků, nikdy vaše uživatelské jméno ani e-mailová adresa, žádné použití posledních tří, hasováno pomocí Argon2. E-mailové adresy jsou před použitím účtu ověřeny.
Dvoufaktorové ověřování je součástí identitního systému, nikoliv doplňkem, který si kupujete, nebo pluginem, který si instalujete na vlastní web.
Pokud vaše organizace již používá poskytovatele identity – Okta, Entra ID, Google Workspace nebo jakýkoliv jiný systém podporující protokol SAML –, můžete jej propojit a vaši zaměstnanci se budou do platformy Zinn Digital® přihlašovat pomocí svých stávajících firemních přihlašovacích údajů. Váš tým tak nemusí spravovat druhé heslo ani zapomínat na druhý kontrolní seznam při odchodu zaměstnanců.
To je nejdůležitější na úrovni agentur a přeprodejců, kde je fluktuace zaměstnanců skutečným bezpečnostním incidentem. Když někdo odejde a vy ho deaktivujete ve svém adresáři, deaktivovali jste tím i jeho přístup k hostingu. Přístup se centrálně odvíjí od pracovního poměru, namísto abyste ho složitě řešili napříč deseti nástroji SaaS.
SAML funguje vedle všeho ostatního, místo aby to nahrazoval: dodavatelé mohou stále získat účet s kouzelným odkazem v rámci vymezené role, zatímco stálí zaměstnanci přicházejí přes SSO. Jedna organizace, jeden model oprávnění, dvoje vstupní dveře.
Přístup je omezen na strom organizace – od prodejce přes klienta až po web – a je vynucován přímo v databázi pomocí zabezpečení na úrovni řádků, nikoli pouze v aplikaci. Přístup mezi tenanty není pravidlem, které po lidech požadujeme, aby ho respektovali; je to dotaz, který nemůže vrátit žádné řádky. Čtyři zákaznické role pokrývají reálné rozdělení povinností.
Plná kontrola nad organizací a jejími podúčty: vytvářejte podřízené organizace, pozvěte a odstraňujte členy, přiřazujte role, spravujte každý web, vyřizujte fakturaci, spravujte klíče API a čtěte protokol auditu.
Fakturace, předplatné, platební metody a katalog tarifů – a nic jiného. Váš finanční ředitel nebo účetní může uhradit fakturu, aniž by kdy získal možnost upravit, pozastavit nebo smazat živý web.
Weby a přístup k API bez kontroly fakturace: zobrazení a zřizování webů, restartování služeb, vymazání mezipamětí, správa klíčů API a práce s tikety. Záměrně bez přístupu ke způsobům platby, fakturaci nebo změnám tarifu.
Pouze pro čtení v rámci celé organizace – weby, fakturace, plány, tikety, stav překladů a protokol auditu. Správná role pro auditora, klienta, který chce mít přehled, nebo nováčka během jeho prvního týdne.
Ovládací panel je jednou z bran. API, CLI, poskytovatel Terraformu a server MCP jsou dalšími – a podléhají stejnému modelu přístupu, protože klíč bez vymezeného rozsahu obchází každou roli, kterou jste právě nakonfigurovali.
API klíč je vydáván organizaci, nikoli jednotlivci, a nese si vlastní oprávnění. Zacházejte s ním jako s materiálem pro sdílené přihlašovací údaje: pojmenujte jej podle jeho účelu, udělte mu ta nejužší možná funkční oprávnění a obměňte jej, když osoba, která jej vytvořila, odejde.
Původní klíč se vám zobrazí pouze jednou, při vytvoření. Ukládáme pouze hash SHA-256 a krátký prefix pro vyhledávání. Klíč vám již nemůžeme znovu zobrazit a kompromitace databáze útočníkovi neposkytne funkční přihlašovací údaje.
Každý klíč nese granulární rozsahy navázané na stejný katalog oprávnění, jaký používají role, zaznamenává datum posledního použití a lze jej okamžitě zneplatnit, jakmile se cokoli nezdá v pořádku. Samostatné sandboxové klíče testují API bez reálné fakturace nebo zřizování služeb.
Server MCP umožňuje jakémukoli agentovi s podporou MCP spravovat váš hosting – a ověřuje se pomocí OAuth 2.1 s rozsahem omezeným na vaši organizaci a její oprávnění RBAC, s tokeny odvolatelnými pro jednotlivé nástroje, potvrzováním destruktivních akcí, limity útrat a úplným auditním záznamem. Připojení AI asistenta neznamená, že mu předáte klíče ke všemu.
Každá privilegovaná akce zapíše záznam pouze pro připojení – kdo ji provedl, co udělal, čeho se týkala, podpůrné důkazy a zdrojovou IP adresu s časovým razítkem. Není to pomůcka pro ladění, je to důkazní stopa.
Ne — a raději bychom, abyste to nedělali. Přihlášení e-mailem pomocí magického odkazu je výchozí možností a můžete si zaregistrovat přístupový klíč (Touch ID, Face ID, Windows Hello nebo hardwarový klíč) a přihlašovat se, aniž byste kdy nastavili heslo. E-mail a heslo zůstávají k dispozici jako záložní možnost s minimální délkou dvanácti znaků, zákaz použití posledních tří hesel a hašováním Argon2.
Dvoufázové ověřování pomocí TOTP je integrováno přímo v identitní vrstvě a lze jej vynutit pomocí pravidel v rámci celé organizace, namísto toho, aby záviselo na rozhodnutí každého člena. Přístupové klíče (passkeys) představují silnější variantu všude tam, kde je zařízení vašeho týmu podporují, protože zcela eliminují heslo, které by se útočník snažil získat phishingem.
Ano. Role Správce fakturace poskytuje přístup k fakturám, předplatným, platebním metodám a katalogu tarifů, a ničemu jinému – žádná možnost zobrazovat, zřizovat, restartovat, pozastavovat nebo mazat web. Platí to i obráceně: role Vývojář spravuje weby a přístup k API zcela bez kontroly nad fakturací. Role se přidělují na úrovni organizace, takže role v jedné organizaci neposkytuje žádný přístup v jiné, nesouvisející organizaci – ačkoli role v nadřazené organizaci platí pro organizace vnořené pod ní.
Odolejte ji v administraci a okamžitě přestane fungovat. Rozsah škody je omezen tím, co daný klíč vůbec mohl dělat, a proto mají klíče podrobné rozsahy oprávnění a zaznamenávají časové razítko posledního použití – úzká oprávnění a viditelná historie použití jsou to, co mění únik v omezený incident namísto úplného kompromitu účtu. Pamatujte, že klíče jsou vydávány organizaci, nikoli jednotlivci, takže s nimi zacházejte jako s sdílenými přihlašovacími údaji a obměňujte je, když lidé odcházejí. Na naší straně je uložena pouze hash klíče, takže únik z naší databáze nevede ke vzniku funkčního přihlašovacího údaje.
Ano. Každá oprávněná akce se zapisuje do auditního protokolu typu append-only, který obsahuje aktéra, akci, cíl, podpůrné důkazy, zdrojovou IP adresu a časové razítko. Vlastníci a role pouze pro čtení si jej mohou přímo přečíst. Akce personálu na vašem účtu se zaznamenávají do stejného protokolu a citlivé nebo destruktivní akce personálu mohou vyžadovat dodatečné ověření nebo schválení dvěma osobami.
Ano — jednotné přihlášení (SSO) přes protokol SAML je podporováno u firemních a agenturních účtů, takže vaši uživatelé se ověřují pomocí stávajících firemních přihlašovacích údajů a zrušením jejich účtu ve vašem adresáři se zruší i jejich přístup zde. Můžete kombinovat různé přístupy: SSO pro stálé zaměstnance a účty s omezeným magickým odkazem pro dodavatele, to vše v rámci stejného modelu oprávnění.
Ne — hesla se záměrně nemigrují. Váš účet je importován bez něj a při prvním přihlášení buď použijete magic-link, nebo si nastavíte nové heslo podle aktuálních zásad. Přenášení starých hashů hesel by do nového systému přeneslo staré slabiny, takže to neděláme.
Zkušební verze Footprint-Free trvá 14 dní, je bez nutnosti zadání karty a pokrývá až pět webů. Během zkušební doby získáte kompletní vrstvu identity – přístupové klíče, dvoufázové ověření, role, klíče API a protokol auditu nejsou uzamčeny za placeným tarifem.
Zaregistrujte si přístupový klíč (passkey), pozvěte svůj tým do správných rolí a vytvořte klíč API s omezenou platností – to vše v rámci 14denní zkušební verze bez nutnosti zadávat platební kartu.
Začít zdarma