Delegovaný přístup
Zapojte vývojáře, předejte fakturaci své účetní, poskytněte klientovi přístup pouze pro čtení k jeho vlastním webům nebo nechte náš tým podpory prověřit problém. Každé udělení přístupu představuje roli s definovanými oprávněními, s rozsahem pro danou organizaci, vynucenou v databázi a zapsanou do protokolu auditních záznamů typu append-only.
Sdílení jednoho přihlašovacího údaje je způsob, jak přístup k účtu selhává. Na platformě Zinn Digital® má každá osoba svou vlastní identitu a přístup je členstvím — uživatel, organizace a role — které můžete samostatně udělit, změnit nebo odebrat.
Každý spolupracovník se přihlašuje pod svou vlastní identitou prostřednictvím naší vrstvy identit Keycloak. Nikdo nezadává Vaše heslo, nikdo nesdílí relaci prohlížeče a odebrání uživatele představuje jedinou akci namísto obměny hesel a shonu při zjišťování, kdo další heslo znal.
Účty jsou hierarchické — organizace prodejce obsahuje klientské organizace a klientské organizace obsahují weby. Členství se vztahuje na organizaci a vše pod ní, takže můžete klientovi agentury předat kontrolu nad jeho vlastní organizací, aniž byste kdykoli odhalili své ostatní klienty.
Oddělení nájemců není filtrem v kódu aplikace, který by chyba mohla obejít. Postgres Row-Level Security omezuje rozsah každého dotazu na podstrom organizace volajícího, takže požadavek mimo váš rozsah nemá co vrátit.
Pokud požádáte o organizaci nebo web mimo svůj rozsah, rozhraní API odpoví prostou chybou „nenalezeno“ namísto chyby oprávnění. Chyba oprávnění by potvrdila, že záznam existuje; informace o nenalezení neprozradí nepovolané osobě vůbec nic.
Oprávnění jsou podrobné klíče — modul plus akce, jako je sites.restart nebo billing.refund — a role je sdružují. Čtyři role pokrývají struktury, které skutečné týmy potřebují, a každá z nich představuje námi předem naplněná data, nikoli logiku skrytou v kódu.
Úplná kontrola: vytvářejte podřízené organizace, zvěte a odebírejte členy, měňte role, spravujte klíče API, vytvářejte, restartujte, pročišťujte, pozastavujte a mažte weby, provádějte fakturaci a spravujte faktury, zadávejte požadavky na podporu a čtěte protokol auditu. Role, kterou si ponecháte pro sebe.
Zobrazuje organizaci, její členy a katalog tarifů a spravuje faktury, platební metody a poplatky. Nemá žádný přístup k vytvoření, úpravě ani smazání jakéhokoli webu — přesně takové nastavení, jaké by měl externí účetní mít.
Zobrazuje a vytváří weby, restartuje služby, promazává mezipaměť, spravuje klíče API a zpracovává tikety. Záměrně vyloučeno: fakturace, faktury, platební metody, správa členů, pozastavení webů a mazání webů. Dodavatel může stavět, aniž by Vám mohl cokoli účtovat nebo cokoli zničit.
Vidí organizaci, její členy, její weby, její fakturaci, katalog plánů, požadavky, stav překladu a protokol auditu — a nemůže z toho nic změnit. Správné oprávnění pro klienta, který chce mít přehled, auditora nebo zainteresovanou stranu, která potřebuje pouze nahlížet.
Delegování přístupu je bezpečné pouze tehdy, pokud je obtížné převzít účty, na které přístup delegujete. Ověřování probíhá přes Keycloak pro každou osobu na účtu, na každém rozhraní.
Práce podpory někdy vyžaduje nahlédnutí do Vašeho účtu. Tento přístup se řídí stejným modelem oprávnění jako vše ostatní — zaměstnanci jsou jednoduše začleněni do personální organizace a rozděleni do oddělení s úzce vymezenými oprávněními.
Zaměstnanci jsou rozděleni do skupin Podpora, Fakturace a finance, Zneužití a důvěra a bezpečnost, Prodej, Onboarding, Inženýring a provoz, Marketing a Vedení. Každá role uděluje přístup ke konkrétním modulům a akcím, takže pracovník vidí pouze tu část administrátorské konzole, kterou vyžaduje jeho práce, a zbytek nikoli.
Role agenta podpory uděluje přesně toto: zobrazení zákazníků, zobrazení a odpovídání na požadavky, zobrazení webů, restartování webu a promazání jeho mezipaměti. Nezahrnuje žádnou konfiguraci fakturace, refundace, úpravu plánů ani správu flotily. Nápravná opatření, která může agent provést, jsou omezena rolí, nikoli dobrými úmysly.
Oprávnění customer.impersonate není součástí role Manager — má jej pouze Super Admin. Pokud jménem Vašeho účtu běží relace, na ovládacím panelu se zobrazuje trvalý banner o zosobnění, takže je vždy zcela jasné, kdo právě jedná.
Každá privilegovaná a administrativní akce se přidává do auditního záznamu určeného pouze pro zápis, který zaznamenává původce, akci, cíl, podpůrná metadata, IP adresu a časové razítko — v produkčním prostředí rozděleného podle času. Vlastníci a členové s oprávněním pouze pro čtení mohou záznamy své organizace číst sami.
Citlivé a destruktivní akce zaměstnanců mohou před spuštěním vyžadovat stupňované ověření nebo schválení dvěma osobami a nová oddělení a role jsou otázkou konfigurace, nikoli změny kódu.
Skripty, kanály CI, CLI, poskytovatel Terraform a agenti AI se autentizují prostřednictvím stejného modelu oprávnění jako lidé — žádné sdílené lidské přihlašovací údaje, žádná dlouhodobá tajemství vložená do sestavení.
Klíče patří organizaci a nesou podrobné rozsahy vázané na stejná oprávnění RBAC — pouze pro čtení, fakturace, zřizování. Udělte pipeline pouze úzký rozsah, který potřebuje, namísto celého účtu člena.
Klíče pro testovací a ostrý režim jsou odlišné, takže integrace ve vývoji nemůže omylem nebo kvůli zkopírované proměnné prostředí přistupovat k produkčním datům.
Ukládáme hash SHA-256 tajného klíče a vyhledávací předponu — nikdy ne nezpracovaný klíč. Klíč uvidíte pouze jednou při jeho vytvoření. Každý klíč sleduje, kdy byl naposledy použit, a lze jej samostatně odvolat, aniž by došlo k narušení čehokoli jiného.
Náš MCP server umožňuje libovolnému agentovi s podporou MCP spravovat Váš hosting v přirozeném jazyce, s ověřením pomocí OAuth 2.1 a rozsahem omezeným na Vaši organizaci a roli RBAC, s odvolatelnými tokeny pro jednotlivé nástroje, potvrzením u destruktivních akcí, limity výdajů a kompletními záznamy auditu.
Přístup k účtu a přístup k serveru jsou dva odlišné problémy. Přihlašovací údaje na úrovni webu se spravují v ovládacím panelu, udělují se podle zásady nejnižších oprávnění a jsou izolovány tak, aby shell jednoho spolupracovníka byl shellem pouze jednoho webu.
Samostatný provozovatel si ponechává jednu organizaci a jedno vlastnické členství a při příchodu externího dodavatele na projekt přidá roli Vývojář. Po skončení projektu je členství odebráno a jeho přihlášení okamžitě přestane fungovat — nezůstanou žádné sdílené přihlašovací údaje, které by bylo nutné obměňovat.
Agentura využívá organizační strom. Každý klient získá svou vlastní podřízenou organizaci, která spravuje jeho weby, a jeho lidé v ní získají členství – s přístupem pouze pro čtení pro zainteresované osoby požadující přehled, nebo jako vlastník pro klienta, který chce vše spravovat samostatně. Vaši zaměstnanci mají členství na vyšších úrovních stromu a vidí celé portfolio; klient vidí pouze svou vlastní větev a Row-Level Security je zárukou, že to není pouhý slib, nýbrž realita.
Prodejce funguje stejným způsobem, o jednu úroveň výše: organizace prodejce obsahuje organizace klientů, z nichž každá má své vlastní členy, zobrazení fakturace a weby. Stejný základní prvek pohání dílčí účty, týmy agentur i hierarchie prodejců — pro žádnou z těchto možností neexistuje samostatný, slabší mechanismus.
Vše je k dispozici ve 14denní zkušební verzi bez nutnosti zadávat platební kartu. Zaregistrujte se bez platebních údajů, pozvěte kolegu, sledujte, k čemu jednotlivé role mají a nemají přístup, a projděte si vlastní záznamy auditu.
V současné době členství uděluje svou roli v rámci celé organizace a všeho, co se v hierarchickém stromu nachází pod ní, takže způsobem, jak oddělit sady webů, je oddělit organizace — umístěte tyto weby do jejich vlastní dceřiné organizace a udělte členství tam. Je to čistý model pro agentury a prodejce, kde každý klient již vyžaduje vlastní hranice. Vymezení rozsahu zdrojů pro jednotlivá členství, tedy přiřazení jediného členství ke konkrétním webům v rámci jedné organizace, představuje plánované vylepšení, nikoli funkci dostupnou v současnosti.
Role Developer nezahrnuje mazání ani pozastavení webu — tato oprávnění náleží roli Owner. Umožňuje prohlížení a vytváření webů, restartování služeb, promazávání mezipaměti, správu klíčů API a práci s tickety. Oprávnění k nasazení a funkci push-to-live rovněž nejsou součástí oprávnění Developer, takže přechod do produkce zůstává na vlastníkovi účtu. Zkombinujte to se stagingem, aby vývojové práce probíhaly především mimo živý web.
Záleží zcela na roli zaměstnance a každá role představuje úzkou sadu oprávnění. Pracovník podpory může například zobrazit váš účet a weby, prohlížet a odpovídat na vaše požadavky, restartovat web a vymazat jeho mezipaměť – a nemůže upravovat konfiguraci fakturace, refundace, tarify ani flotilu. Přihlášení jako zákazník je samostatné oprávnění, které má pouze Super Admin, a když k němu dojde, řídicí panel zobrazuje trvalý banner o zosobnění. Každá privilegovaná akce se zaznamenává do protokolu auditu společně s původcem, akcí, cílem, IP adresou a časovým razítkem a protokol své organizace si můžete sami přečíst.
Odeberte členství a jejich přístup k dané organizaci skončí — stále si zachovávají svou vlastní identitu, ale ve vašem účtu již nemají žádnou roli a tudíž ani žádná oprávnění. Klíče API se odvolávají jednotlivě, takže klíč pipeline lze zrušit bez narušení čehokoli jiného. Pokud používáte jednotné přihlašování SAML, zrušení zřízení (deprovisioning) u vašeho poskytovatele identity řeší přihlašování centrálně. Přihlašovací údaje na úrovni webu, jako jsou klíče SSH, se odvolávají na ovládacím panelu a samotné odebrání je zaznamenáno v protokolu auditu.
Ne — stojí však za to přesně vysvětlit proč. Klíče API patří organizaci, nikoli jednotlivému členovi, a nesou své vlastní granulární rozsahy vázané na stejný katalog oprávnění. Místo toho, abyste někomu předali klíč, vytvoříte klíč pro konkrétní úkol s nejužším rozsahem, který daný úkol vyžaduje, a po dokončení úkolu tento klíč zneplatníte. Ukládá se pouze hash tajného klíče a každý klíč zaznamenává, kdy byl naposledy použit, takže nepoužívané klíče lze snadno najít a vyřadit.
Ano. Náš server MCP ověřuje agenty pomocí OAuth 2.1 a vymezuje jejich rozsah pro Vaši organizaci a Vaši roli RBAC s odvolatelnými tokeny pro jednotlivé nástroje, takže udělujete konkrétní schopnost namísto plošného přístupu. Destruktivní akce vyžadují potvrzení, platí limity výdajů a každá akce se zaznamenává do stejného protokolu auditu jako lidská činnost.
Zabezpečení na úrovni řádků v Postgresu (Row-Level Security) omezuje dotazy na podstrom organizace volajícího přímo v samotné databázi, přičemž filtr na úrovni aplikace slouží jako hloubková obrana, nikoli jako jediná linie. Požadavky na záznamy mimo rozsah vracejí stav „nenalezeno“ namísto chyby oprávnění, takže se neodhalí nic o tom, co existuje. Na straně serveru izolace jednotlivých webů prostřednictvím CageFS udržuje shell a soubory každého nájemce pouze na jeho vlastním webu.
Ano. 14denní zkušební verze je bez nutnosti zadávat kartu – žádné platební údaje, žádný závazek – a zahrnuje Footprint-Free hosting až pro pět webů. To plně stačí na to, abyste pozvali kolegu, přiřadili roli a před přijetím závazku ověřili, že vymezené hranice fungují přesně tak, jak potřebujete.
Začněte se 14denní zkušební verzí bez nutnosti zadávat kartu, pozvěte kolegu a sledujte, jak model oprávnění plní svou funkci — role, které můžete sami pojmenovat, rozsahy, které můžete odvolat, a auditní záznam, který přesně uvádí, kdo co udělal.
Začněte zdarma