Bezpieczeństwo konta
Bezpieczeństwo serwera chroni witryny. Bezpieczeństwo konta chroni klucze do nich. Każde logowanie w Zinn Digital® opiera się na jednym systemie tożsamości opartym na standardach — kluczach dostępu i WebAuthn, dwuskładnikowym uwierzytelnianiu TOTP, logowaniu za pomocą magicznego linku, jednokrotnym logowaniu SAML dla zespołów korporacyjnych i agencji — z szczegółowymi rolami, kluczami API dla organizacji oraz rejestrem audytu typu append-only.
Większość kont hostingowych to hasło w bazie danych połączone z panelem sterowania. Nasze to dedykowany system tożsamości — Keycloak, obsługujący OIDC i SAML — który znajduje się przed wszystkim: panelem klienta, konsolą administracyjną pracownika, tą publiczną stroną i bazą wiedzy oraz Twoimi zgłoszeniami do pomocy technicznej. Zaloguj się raz, a masz dostęp do wszystkich tych elementów.
Ponieważ został zbudowany na otwartych standardach zamiast na zastrzeżonym systemie logowania, warstwa tożsamości jest wymienialna w taki sam sposób jak każdy inny komponent platformy. Żaden element Twojego modelu dostępu nie jest uwięziony w produkcie dostawcy, a uwierzytelnianie Twojego zespołu nie zależy od tego, czy utrzymamy jednego dostawcę. To ta sama zasada braku blokady dostawcy, którą stosujemy do kont CDN, DNS i dostawców płatności.
Logowanie jest zlokalizowane, a przekierowanie z witryny do ekranu logowania przenosi ze sobą Twój język – dzięki temu zespół rozsiany po różnych krajach nie jest zmuszony do korzystania z panelu logowania wyłącznie w języku angielskim.
Cztery metody, wszystkie najwyższej klasy, wszystkie konfigurowalne dla każdej osoby. Nikt nie jest zmuszany do korzystania z najsłabszej opcji tylko dlatego, że jest ona jedyną dostępną.
Wpisz swój adres e-mail, kliknij link i jesteś w środku. Żadnego hasła do wyudzenia, ponownego użycia ani wycieku w bazie danych. To domyślna ścieżka dla nowych kont i dla większości ludzi jedyna, jakiej kiedykolwiek będą potrzebować.
Zarejestruj klucz dostępu — Touch ID, Face ID, Windows Hello lub klucz sprzętowy, taki jak YubiKey — i loguj się całkowicie bez hasła. Klucze dostępu są powiązane z domeną, więc fałszywa strona logowania nie może ich przejąć. Platforma obsługuje uwierzytelniacze ES256 i RS256 oraz preferuje weryfikację użytkownika.
Zaloguj się za pomocą Google przez standardowe połączenie dostawcy tożsamości, dzięki czemu konto dziedziczy wszelkie zabezpieczenia, które Twoje Google Workspace już wymusza. Kolejni dostawcy łączą się w ten sam sposób – nie jest to w żaden sposób dedykowana integracja.
Zachowane dla osób i skryptów, które tego potrzebują, oraz objęte realną zasadą: minimum dwanaście znaków, nigdy Twoja nazwa użytkownika lub adres e-mail, brak ponownego użycia ostatnich trzech, hashowane za pomocą Argon2. Adresy e-mail są weryfikowane przed aktywacją konta.
Drugie składniki są częścią systemu tożsamości, a nie dodatkiem, który kupujesz lub wtyczką, którą instalujesz na własnej stronie.
Jeśli Twoja organizacja korzysta już z dostawcy tożsamości – Okta, Entra ID, Google Workspace lub innego obsługującego protokół SAML – możesz go połączyć, a Twoi pracownicy będą logować się do Zinn Digital® za pomocą swoich dotychczasowych poświadczeń firmowych. Twój zespół nie musi zarządzać drugim hasłem ani pamiętać o kolejnej liście kontrolnej przy odchodzeniu z firmy.
Ma to największe znaczenie w skali agencji i odsprzedawców, gdzie rotacja pracowników stanowi rzeczywiste zdarzenie związane z bezpieczeństwem. Kiedy ktoś odchodzi i wyłączasz go w swoim katalogu, wyłączasz również jego drogę do hostingu. Dostęp podąża za zatrudnieniem, centralnie, zamiast być gonionym w kilkunastu narzędziach SaaS.
SAML funkcjonuje obok wszystkiego innego, zamiast to zastępować: kontrahency nadal mogą otrzymać konto z magicznym linkiem w ramach ograniczonej roli, podczas gdy stały personel loguje się przez SSO. Jedna organizacja, jeden model uprawnień, dwoje drzwi wejściowych.
Dostęp jest ograniczony do drzewa organizacji — od odsprzedawcy przez klienta do witryny — i egzekumowany bezpośrednio w bazie danych za pomocą zabezpieczeń na poziomie wierszy, a nie tylko w aplikacji. Dostęp między dzierżawcami to nie zasada, o której przestrzeganie prosimy użytkowników, lecz zapytanie, które nie może zwrócić wierszy. Cztery role klientów pokrywają realistyczny podział obowiązków.
Pełna kontrola nad organizacją i jej subkontami: tworzenie organizacji podrzędnych, zapraszanie i usuwanie członków, przypisywanie ról, zarządzanie każdą stroną, obsługa płatności i faktur, zarządzanie kluczami API oraz odczyt dziennika audytu.
Faktury, subskrypcje, metody płatności i katalog planów — i nic więcej. Twój pracownik ds. finansów lub księgowy może opłacić fakturę bez uzyskiwania jakiejkolwiek możliwości dotknięcia, zawieszenia czy usunięcia aktywnej strony.
Witryny i dostęp do API bez kontroli rozliczeń: przeglądanie i wdrażanie witryn, restartowanie usług, czyszczenie pamięci podręcznej, zarządzanie kluczami API oraz obsługa zgłoszeń. Celowo brak dostępu do metod płatności, fakturowania i zmian planu.
Tylko do odczytu w całej organizacji – witryny, rozliczenia, plany, zgłoszenia, status tłumaczeń i dziennik zdarzeń. Odpowiednia rola dla audytora, klienta potrzebującego wglądu lub nowego pracownika w pierwszym tygodniu pracy.
Panel sterowania to tylko jeden ze sposobów dostępu. API, CLI, dostawca Terraform oraz serwer MCP to kolejne — i obowiązuje je ten sam model dostępu, ponieważ klucz bez ograniczeń omija każdą skonfigurowaną przez Ciebie rolę.
Klucz API jest wydawany organizacji, a nie konkretnej osobie, i posiada własne zakresy uprawnień. Należy traktować go jak współdzielone dane uwierzytelniające: nazwij go zgodnie z jego przeznaczeniem, nadaj mu najwęższe działające zakresy i rotuj nim, gdy osoba, która go utworzyła, odchodzi.
Surowy klucz jest pokazywany tylko raz, podczas tworzenia. Przechowujemy jedynie skrót SHA-256 oraz krótki prefiks do wyszukiwania. Nie możemy ponownie pokazać klucza, a naruszenie zabezpieczeń bazy danych nie zapewnia atakującemu działających poświadczeń.
Każdy klucz posiada szczegółowe zakresy powiązane z tym samym katalogiem uprawnień, z którego korzystają role, rejestruje czas ostatniego użycia i może zostać natychmiast unieważniony, gdy tylko wzbudzi podejrzenia. Oddzielne klucze środowiska testowego (sandbox) pozwalają testować interfejs API bez faktycznych rozliczeń i prowizjonowania.
Serwer MCP pozwala każdemu agentowi obsługującemu protokół MCP zarządzać Twoim hostingiem – uwierzytelnia się on poprzez OAuth 2.1 w zakresie organizacji i jej uprawnień RBAC, oferując tokeny z możliwością odwołania dla każdego narzędzia, potwierdzenie destrukcyjnych akcji, limity wydatków oraz pełne logowanie audytowe. Podłączenie asystenta AI nie oznacza przekazania mu kluczy do wszystkiego.
Każda uprzywilejowana akcja zapisuje rekord typu append-only — kto ją wykonał, co zrobił, czego to dotyczyło, dowody uzupełniające oraz źródłowy adres IP wraz z znacznikiem czasu. To nie jest udogodnienie do debugowania; to jest ślad dowodowy.
Nie — i wolelibyśmy, abyś tego nie robił. Logowanie za pomocą wiadomości e-mail z linkiem magicznym jest domyślną metodą, a ponadto możesz zarejestrować klucz dostępu (Touch ID, Face ID, Windows Hello lub klucz sprzętowy) i logować się bez ustawiania hasła. Opcja logowania za pomocą adresu e-mail i hasła pozostaje dostępna jako metoda zapasowa, wymagająca minimum dwunastu znaków, zakazu ponownego używania ostatnich trzech haseł oraz uwzględniająca szyfrowanie Argon2.
Uwierzytelnianie dwuskładnikowe TOTP jest wbudowane w warstwę tożsamości i może być wymuszane za pomocą zasad w całej organizacji, zamiast pozostawiać tę decyzję poszczególnym członkom zespołu. Klucze dostępu (passkeys) są silniejszą opcją, jeśli urządzenia Twojego zespołu je obsługują, ponieważ eliminują hasło, na które poluje atakujący.
Tak. Rola Menedżera rozliczeń zapewnia dostęp do faktur, subskrypcji, metod płatności oraz katalogu planów i niczego więcej – brak uprawnień do przeglądania, tworzenia, restartowania, zawieszania czy usuwania witryny. Zasada ta działa w obie strony: rola Dewelopera zarządza witrynami i dostępem do API bez jakiejkolwiek kontroli nad rozliczeniami. Role są przypisywane w ramach organizacji, więc rola w jednej organizacji nie daje dostępu do innej, niezwiązanej z nią organizacji – choć rola w organizacji nadrzędnej dotyczy organizacji zagnieżdżonych poniżej niej.
Cofnij go w panelu, a natychmiast przestanie działać. Okres podatności na zagrożenia jest ograniczony do tego, do czego ten klucz w ogóle miał uprawnienia, dlatego klucze mają szczegółowe zakresy i rejestrują znacznik czasu ostatniego użycia — wąskie zakresy i widoczny ślad użycia zamieniają wyciek w opanowany incydent zamiast w naruszenie całego konta. Pamiętaj, że klucze są wydawane organizacji, a nie konkretnej osobie, więc traktuj je jak poświadczenia współdzielone i wymieniaj je, gdy pracownicy odchodzą. Po naszej stronie przechowywany jest tylko skrót klucza, więc wyciek z naszej bazy danych nie prowadzi do uzyskania działającego poświadczenia.
Tak. Każda uprzywilejowana akcja jest zapisywana w dzienniku audytu typu append-only, zawierającym informację o wykonawcy, akcji, obiekcie docelowym, dowodach wspierających, adresie IP źródła oraz sygnaturze czasowej. Właściciele oraz użytkownicy z rolami tylko do odczytu mogą go czytać bezpośrednio. Działania personelu na Twoim koncie są rejestrowane w tym samym śladzie, a wrażliwe lub destrukcyjne działania personelu mogą wymagać wcześniejszego uwierzytelnienia podwyższonego stopnia lub zatwierdzenia przez dwie osoby.
Tak — logowanie jednokrotne SAML jest obsługiwane w kontach dla firm i agencji, dzięki czemu użytkownicy uwierzytelniają się za pomocą istniejących poświadczeń firmowych, a usunięcie ich z katalogu usuwa również ich dostęp tutaj. Możesz łączyć podejścia: SSO dla stałego personelu i ograniczone konta z magicznym linkiem dla podwykonawców, wszystko w ramach tego samego modelu uprawnień.
Nie — hasła celowo nie są migrowane. Twoje konto zostaje zaimportowane bez hasła, a podczas pierwszego logowania możesz skorzystać z linku magicznego lub ustawić nowe hasło zgodnie z obecną polityką. Przenoszenie starych hashy haseł mogłoby przenieść dawne słabości do nowego systemu, dlatego tego nie robimy.
14-dniowy okres próbny Footprint-Free nie wymaga podawania karty i obejmuje do pięciu witryn. Podczas okresu próbnego otrzymujesz pełną warstwę tożsamości – klucze dostępu, uwierzytelnianie dwuskładnikowe, role, klucze API oraz dziennik zdarzeń nie są blokowane za płatnym planem.
Zarejestruj klucz dostępu, zaproś swój zespół do odpowiednich ról i wygeneruj ograniczony klucz API – a wszystko to w ramach 14-dniowego okresu próbnego bez konieczności podawania karty.
Rozpocznij za darmo