Delegovaný přístup
Přizvěte vývojáře, předejte fakturaci svému účetnímu, umožněte klientovi nahlížet do jeho vlastních webů nebo nechte náš tým podpory podívat se na problém. Každé oprávnění představuje roli s definovanými právy, vymezenou pro konkrétní organizaci, vynucovanou na úrovni databáze a zaznamenanou v auditním logu, do kterého lze pouze přidávat záznamy.
Sdílení jednoho přihlašovacího údaje vede k problémům s přístupem k účtu. Na platformě Zinn Digital® má každý člověk svou vlastní identitu a přístup funguje jako členství – uživatel, organizace a role –, které můžete samostatně udělit, změnit nebo zrušit.
Každý spolupracovník se přihlašuje sám za sebe prostřednictvím systému Keycloak, naší identitní vrstvy. Nikdo nezadává vaše heslo, nikdo nesdílí relaci prohlížeče a odebrání někoho je otázkou jedné akce namísto výměny hesla a zmateného zjišťování, kdo další ho 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 svěřit správu klientské organizace přímo dané agentuře, aniž byste kdykoliv odhalili své ostatní klienty.
Oddělení tenantů není filtrem v aplikačním kódu, který by mohl nějaký bug přeskočit. RLS (Row-Level Security) v Postgresu omezuje každý dotaz na podstrom organizace volajícího, takže požadavek mimo váš rozsah nemá co vrátit.
Požádejte o organizaci nebo web mimo svůj rozsah a API odpoví prostou zprávou nenalezeno namísto chyby oprávnění. Chyba oprávnění by potvrdila, že záznam existuje; nenalezeno neprozradí outsiderovi vůbec nic.
Oprávnění jsou podrobné klíče – modul plus akce, jako sites.restart nebo billing.refund – a role je sdružují. Čtyři role pokrývají potřeby reálných týmů a každá z nich představuje data, která přednastavujeme, nikoli logiku skrytou v kódu.
Plná kontrola: vytvářejte podřízené organizace, pozvěte a odstraňte členy, měňte role, spravujte klíče API, vytvářejte, restartujte, pročišťujte, pozastavujte a mažte weby, spravujte fakturaci a faktury, zakládejte tikety a čtěte protokol auditů. Roli si ponecháte pro sebe.
Vidí organizaci, její členy a katalog tarifů a spravuje faktury, platební metody a poplatky. Žádný přístup k vytváření, úpravám ani mazání jednotlivých webů – přesně taková práva by měl mít externí účetní.
Zobrazuje a vytváří weby, restartuje služby, čistí mezipaměť, spravuje klíče API a řeší požadavky podpora. Záměrně vyloučeno: fakturace, faktury, platební metody, správa členů, pozastavení webu a smazání webu. Dodavatel může vytvářet, aniž by vám mohl vystavovat faktury nebo cokoliv zničit.
Vidí organizaci, její členy, weby, fakturaci, katalog tarifů, tikety, stav překladů a protokol auditu – a nemůže nic z toho mě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 v případě, že účty, na které delegujete, je obtížné napadnout. Autentizace probíhá přes Keycloak pro každou osobu na účtu a na každém rozhraní.
Práce na podpoře někdy znamená nahlédnout do vašeho účtu. Tento přístup se řídí stejným modelem oprávnění jako všechno ostatní – personál jednoduše působí v organizaci pro zaměstnance, která je uspořádána do oddělení s úzce vymezenými oprávněními.
Zaměstnanci jsou seskupeni do kategorií Podpora, Fakturace a finance, Zneužívání a důvěra a bezpečnost, Prodej, Onboarding, Vývoj a provoz, Marketing a Management. Každá role uděluje konkrétní moduly a akce, takže agent vidí tu část administrátorské konzole, kterou jeho práce vyžaduje, a zbytek ne.
Role Podpory přináší přesně toto: zobrazení zákazníků, zobrazení tiketů a odpovědi na ně, zobrazení webů, restartování webu a vymazání jeho mezipaměti. Neobsahuje žádnou konfigurację fakturace, žádné refundace, žádné úpravy plánů ani správu fleetu. Náprava, kterou může agent provést, je omezena rolí, nikoli dobrými úmysly.
Oprávnění customer.impersonate není součástí role Manager – disponuje jím pouze Super Admin. Když je spuštěna relace vaším jménem, řídicí panel obsahuje trvalý banner zastupování, takže je vždy zcela zřejmé, kdo jedná.
Každá oprávněná a administrativní akce se připisuje do protokolu auditního záznamu, který nelze přepsat a který zaznamenává subjekt, akci, cíl, podpůrná metadata, IP adresu a časové razítko – v produkčním prostředí časově partitionované. Vlastníci a členové s právem pouze pro čtení si mohou protokol své organizace číst sami.
Citlivé a destruktivní akce zaměstnanců mohou před svým spuštěním vyžadovat dodatečné ověření nebo schválení dvěma osobami a nová oddělení a role představují otázku konfigurace, nikoli změny kódu.
Skripty, CI pipelines, CLI, Terraform provider a AI agenti se autentizují prostřednictvím stejného model oprávnění jako lidé – žádné sdílené lidské přihlašovací údaje, žádná dlouhodobá hesla vkládaná do buildu.
Klíče náleží organizaci a mají podrobná oprávnění vázaná na stejná RBAC oprávnění – pouze pro čtení, fakturace, zřizování. Udělte pipeline úzký rozsah, který potřebuje, namísto celého účtu člena.
Klíče pro testovací a ostrý režim jsou oddělené, takže integrace ve vývoji nemůže omylem ani prostřednictvím zkopírované proměnné prostředí přistoupit k produkčním datům.
Ukládáme SHA-256 hash tajného klíče a vyhledávací předponu — nikdy ne samotný klíč. Klíč uvidíte pouze jednou při vytvoření. U každého klíče se sleduje, kdy byl naposledy použit, a lze jej samostatně zrušit, aniž by to ovlivnilo cokoli jiného.
Náš server MCP umožňuje jakémukoli agentovi s podporou MCP spravovat váš hosting v přirozeném jazyce, ověřenému pomocí OAuth 2.1 a s omezením na vaši organizaci a roli RBAC, s tokeny odvolatelnými pro každý nástroj zvlášť, potvrzováním destruktivních akcí, limity útraty a úplným protokolem auditu.
Přístup k účtu a přístup k serveru jsou dva různé problémy. Pověření na úrovni webu se spravují v ovládacím panelu, vydávají se v režimu nejnižších oprávnění a jsou izolována tak, že shell jednoho spolupracovníka odpovídá shellu jednoho webu.
Samostatný provozovatel udržuje jednu organizaci a jedno členství vlastníka a přidá roli Developer, když externista nastoupí na projekt. Po skončení projektu se členství odebere a jeho přihlášení okamžitě přestane fungovat – nezůstanou žádné sdílené přihlašovací údaje, které by bylo nutné měnit.
Agentura využívá organizační strom. Každý klient získá vlastní podřízenou organizaci, která obsahuje weby daného klienta, a příslušní lidé klienta v ní mají členství – pro zúčastněnou stranu, která chce mít přehled, je to čtení, pro klienta, který chce obsluhu sám sebe, je to vlastník. Vaši zaměstnanci mají členství výše ve stromu a vidí portfolio; klient vidí pouze vlastní větev a Row-Level Security zajišťuje, že je to skutečnost, a ne pouhý slib.
Reseller funguje úplně stejně, jen o úroveň výš: organizace prodejce (reselleru) obsahuje klientské organizace, z nichž každá má vlastní členy, fakturační přehled a weby. Stejný základní prvek pohání dílčí účty, agenturní týmy i hierarchie prodejců – pro žádný z nich neexistuje žádný samostatný, slabší mechanismus.
Všechno je k dispozici v rámci 14denní zkušební verze bez platební karty. Zaregistrujte se bez údajů o platbě, pozvěte kolegu, sledujte, kam má jednotlivá role přístup a kam ne, a prohlédněte si vlastní protokol událostí.
Dnes členství uděluje svou roli napříč celou organizací a vším pod ní ve stromě, takže způsobem, jak oddělit sady webů, je oddělení organizací – umístěte tyto weby do jejich vlastní podřazené organizace a udělte členství tam. Je to čistý model pro agentury a prodejce, kde každý klient již chce mít vlastní hranici. Omezení zdrojů na jedno členství, tedy připnutí jednoho členství ke konkrétním webům v rámci jedné organizace, je plánované vylepšení, které zatím není k dispozici.
Role Developer neumožňuje mazání ani pozastavení webu – tato oprávnění náleží pouze roli Owner. Poskytuje oprávnění k zobrazení a vytváření webů, restartování služeb, čištění mezipaměti, správě klíčů API a vyřizování tiketů. Oprávnění k nasazení a publikování na ostrou verzi (push-to-live) rovněž nejsou součástí role Developer, takže povýšení do produkčního prostředí zůstává v rukou vlastníka účtu. Propojte to se stagingovým prostředím, aby se vývojové práce prováděly primárně mimo ostrý web.
Záleží zcela na roli personálu a každá role představuje úzkou sadu klíčů oprávnění. Například podpora může prohlížet váš účet a weby, prohlížet vaše tikety a odpovídat na ně, restartovat web a vymazat jeho mezipaměť – nemůže však zasahovat do nastavení fakturace, vrácení peněz, tarifů ani infrastruktury. Přihlášení jako zákazník je samostatné oprávnění, které drží pouze Super Admin, a když k němu dojde, ovládací panel zobrazí trvalý banner zastupování. Každá oprávněná akce je zaznamenána v protokolu auditů spolu s aktérem, akcí, cílem, IP adresou a časovým razítkem a protokol své organizace si můžete sami přečíst.
Odstraněním členství skončí jejich přístup k této organizaci – stále si zachovávají svou vlastní identitu, ale v účtu již nemají žádnou roli, a tedy ani žádná oprávnění. Klíče API se odvolávají jednotlivě, takže klíč pro pipeline lze zrušit, aniž by se cokoli jiného narušilo. Pokud používáte jednotné přihlášení (SSO) přes SAML, deprovisioning ve vašem identity provideru zajistí správu přihlašování centrálně. Pověření na úrovni webu, jako jsou klíče SSH, se odvolávají v dashboardu a samotné odstranění se zaznamenává do protokolu auditů.
Ne — ale stojí za to mít jasno v tom proč. Klíče API patří organizaci, nikoli jednotlivým členům, a mají vlastní granulární rozsahy oprávnění svázané se stejným katalogem oprávnění. Místo abyste tedy někomu dali klíč, vytvoříte klíč pro konkrétní úkol s nejužším možným rozsahem, jaký daný úkol vyžaduje, a po skončení úkolu tento klíč odvolá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 zrušit.
Ano. Náš server MCP autentizuje agenty pomocí OAuth 2.1 a omezuje jejich oprávnění na vaši organizaci a vaši roli RBAC. Díky tokenům, které lze pro jednotlivé nástroje odvolat, udělujete konkrétní schopnost namísto plošného přístupu. Destrukční akce vyžadují potvrzení, platí limity útrat a každá akce se zapisuje do stejného protokolu auditu jako lidská aktivita.
Řádková bezpečnost (Row-Level Security) v Postgresu omezuje dotazy na podstrom organizace volajícího přímo v databázi, přičemž aplikační filtr slouží jako dodatečná vrstva zabezpečení namísto jediné obranné linie. Požadavky na záznamy mimo tento rozsah vracejí chybu nenalezeno namísto chyby oprávnění, takže se nic neprozradí o tom, co existuje. Na straně serveru zajišťuje izolace jednotlivých webů pomocí CageFS, že shell a soubory každého nájemníka zůstanou v rámci jeho vlastního webu.
Ano. Čtrnáctidenní zkušební doba nevyžaduje kartu – žádné platební údaje, žádný závazek – a pokrývá hosting Footprint-Free až pro pět webů. Stačí to k pozvání kolegy, přiřazení role a ověření, že hranice fungují tak, jak potřebujete, než se zavážete.
Začněte 14denní zkušební verzi bez platební karty, někoho pozvěte a sledujte, jak model oprávnění funguje – role, které můžete pojmenovat, rozsahy, které můžete zrušit, a protokol auditu, který přesně ukazuje, kdo co udělal.
Začít zdarma