Bezpieczeństwo konta
Bezpieczeństwo serwera chroni strony. Bezpieczeństwo konta chroni klucze do nich. Każde logowanie do Zinn Digital® opiera się na jednym standardowym systemie tożsamości — kluczach dostępu i WebAuthn, uwierzytelnianiu dwuskładnikowym TOTP, logowaniu za pomocą łącza magicznego, SAML SSO dla zespołów korporacyjnych i agencyjnych — z granularnymi rolami, kluczami API dla poszczególnych organizacji oraz niezmiennym dziennikiem audytu.
Większość kont hostingowych to po prostu hasło w bazie danych połączone z panelem sterowania. Nasze rozwiązanie to dedykowany system tożsamości — Keycloak, obsługujący OIDC i SAML — który znajduje się przed wszystkimi elementami: panelem klienta, konsolą administracyjną personelu, tą publiczną stroną i bazą wiedzy oraz Państwa zgłoszeniami pomocy technicznej. Wystarczy zalogować się raz, aby uzyskać dostęp do nich wszystkich.
Dzięki temu, że opiera się na otwartych standardach, a nicht na zastrzeżonym logowaniu, warstwa tożsamości jest wymienna w taki sam sposób, jak każdy inny komponent platformy. Żadna część Państwa modelu dostępu nie jest uwięziona w produkcie dostawcy, a uwierzytelnianie Państwa zespołu nie zależy od utrzymywania przez nas jednego dostawcy. To ta sama zasada braku blokady technologicznej (no-lock-in), którą stosujemy do kont CDN, DNS i dostawców płatności.
Logowanie jest zlokalizowane, a przejście z witryny do ekranu logowania zachowuje wybrany język — dzięki temu zespół rozproszony w różnych krajach nie jest zmuszony do korzystania z 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 jedyną dostępną.
Wpisz swój adres e-mail, kliknij link i gotowe. Brak hasła, które można by wyłudzić, użyć ponownie lub ujawnić w wyniku wycieku danych. Jest to domyślna ścieżka dla nowych kont i dla większości osób 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ą źródłową, więc podszywająca się strona logowania nie może ich przechwycić. Platforma obsługuje moduły uwierzytelniające ES256 i RS256 oraz preferuje weryfikację użytkownika.
Zaloguj się przez Google za pomocą standardowego połączenia z dostawcą tożsamości, dzięki czemu konto przejmuje wszelkie mechanizmy kontroli wymuszane już przez Google Workspace. Kolejni dostawcy łączą się w ten sam sposób — nie ma w tym nic z dedykowanej integracji.
Zachowane dla osób i skryptów, które tego potrzebują, oraz objęte rzeczywistymi zasadami: co najmniej dwanaście znaków, nigdy Państwa nazwa użytkownika ani adres e-mail, brak możliwości ponownego użycia trzech ostatnich, haszowane za pomocą Argon2. Adresy e-mail są weryfikowane, zanim konto stanie się zdatne do użytku.
Drugie składniki są częścią systemu tożsamości, a nie dodatkiem, który Państwo kupują, ani wtyczką instalowaną na własnej stronie.
Jeśli twoja organizacja korzysta już z dostawcy tożsamości — takiego jak Okta, Entra ID, Google Workspace lub dowolnego innego obsługującego SAML — po prostu go podłączasz, a twoi pracownicy logują się do Zinn Digital® za pomocą swoich dotychczasowych danych firmowych. Zespół nie musi zarządzać drugim hasłem ani pamiętać o kolejnej liście kontrolnej offboardingu.
Ma to największe znaczenie na poziomie agencji i resellerów, gdzie rotacja personelu stanowi realne zdarzenie związane z bezpieczeństwem. Gdy ktoś odchodzi i wyłączają Państwo jego konto w swoim katalogu, blokują Państwo również jego dostęp do swojego hostingu. Uprawnienia dostępu podążają centralnie za statusem zatrudnienia, zamiast wymagać ręcznego odbierania ich w kilkunastu narzędziach SaaS.
SAML działa równolegle ze wszystkim innym, zamiast to zastępować: kontrahentom można nadal przypisać konto z magicznym linkiem w ramach określonej roli, podczas gdy pracownicy etatowi logują się przez SSO. Jedna organizacja, jeden model uprawnień, dwoje drzwi wejściowych.
Dostęp jest ograniczony do drzewa organizacji — od resellera, przez klienta, po witrynę — i egzekwowany bezpośrednio w bazie danych za pomocą zabezpieczeń na poziomie wierszy, a nie tylko w aplikacji. Dostęp między dzierżawcami nie jest zasadą, o której przestrzeganie prosimy użytkowników; to zapytanie, które nie może zwrócić wierszy. Cztery role klienta pokrywają realistyczny podział obowiązków.
Pełna kontrola nad organizacją i jej kontami podrzędnymi: tworzenie organizacji podrzędnych, zapraszanie i usuwanie członków, przypisywanie ról, zarządzanie każdą witryną, obsługa rozliczeń i fakturowania, zarządzanie kluczami API oraz odczytywanie dziennika audytu.
Faktury, subskrypcje, metody płatności i katalog planów — i nic więcej. Państwa pracownik działu finansowego lub księgowy może opłacić fakturę, nie mając nigdy możliwości modyfikowania, zawieszania ani usuwania działającej witryny.
Dostęp do witryn i interfejsu API bez zarządzania rozliczeniami: przeglądanie i aprowizowanie witryn, ponowne uruchamianie usług, czyszczenie pamięci podręcznej, zarządzanie kluczami API oraz zgłoszeniami serwisowymi. Świadomy brak dostępu do metod płatności, fakturowania lub zmiany planów.
Tylko do odczytu w całej organizacji — witryny, rozliczenia, plany, zgłoszenia, stan tłumaczenia i dziennik audytu. Właściwa rola dla audytora, klienta oczekującego wglądu lub nowego pracownika w jego pierwszym tygodniu.
Pulpit nawigacyjny to jeden ze sposobów uzyskania dostępu. Interfejs API, CLI, dostawca Terraform oraz serwer MCP to inne — i podlegają one temu samemu modelowi dostępu, ponieważ klucz bez określonego zakresu stanowi obejście każdej roli, którą przed chwilą Państwo skonfigurowali.
Klucz API jest wydawany organizacji, a nie osobie fizycznej, i ma własne zakresy uprawnień. Należy go traktować jako współdzielone dane uwierzytelniające: nadać mu nazwę odpowiadającą jego celowi, przyznać najwęższy wystarczający zakres uprawnień oraz dokonać jego rotacji, gdy osoba, która go utworzyła, opuści organizację.
Klucz w postaci nieprzetworzonej jest pokazywany użytkownikowi tylko raz, podczas tworzenia. Przechowujemy jedynie skrót SHA-256 oraz krótki prefiks do wyszukiwania. Nie możemy ponownie wyświetlić klucza, a naruszenie bazy danych nie zapewnia atakującemu działających danych uwierzytelniających.
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. Osobne klucze piaskownicy testują interfejs API bez faktycznego naliczania opłat ani aprowizacji.
Serwer MCP pozwala dowolnemu agentowi obsługującemu MCP zarządzać Państwa hostingiem — a uwierzytelnianie odbywa się za pośrednictwem OAuth 2.1, w zakresie ograniczonym do Państwa organizacji i jej uprawnień RBAC, z tokenami odwoływalnymi dla każdego narzędzia, potwierdzaniem działań destrukcyjnych, limitami wydatków oraz pełnym rejestrowaniem audytu. Podłączenie asystenta AI nie oznacza przekazania mu kluczy do wszystkiego.
Każda czynność uprzywilejowana zapisuje rekord z możliwością wyłącznie dopisywania — informację o tym, kto ją wykonał, co zrobił, na czym ją wykonał, dowody pomocnicze oraz źródłowy adres IP, wraz ze znacznikiem czasu. Nie jest to udogodnienie ułatwiające debugowanie; to ślad dowodowy.
Nie — i wolelibyśmy, aby Państwo tego nie robili. Domyślną metodą jest logowanie za pomocą wiadomości e-mail z linkiem logującym (magic link), a ponadto mogą Państwo zarejestrować klucz dostępu (Touch ID, Face ID, Windows Hello lub klucz sprzętowy) i logować się bez konieczności ustawiania hasła. Logowanie za pomocą adresu e-mail i hasła pozostaje dostępne jako rozwiązanie zapasowe, przy czym wymagane jest minimum dwanaście znaków, zakaz ponownego użycia trzech ostatnich haseł oraz funkcja skrótu Argon2.
Uwierzytelnianie dwuskładnikowe TOTP jest wbudowane w warstwę tożsamości i może być egzekwowane za pomocą zasad w całej organizacji, zamiast pozostawiać decyzję o jego włączeniu poszczególnym członkom. Klucze dostępu (passkeys) są bezpieczniejszą opcją, jeśli urządzenia Państwa zespołu je obsługują, ponieważ eliminują hasło, które osoba atakująca próbowałaby wyłudzić.
Tak. Rola Menedżera ds. rozliczeń (Billing Manager) zapewnia dostęp do faktur, subskrypcji, metod płatności oraz katalogu planów i do niczego więcej — brak możliwości przeglądania, aprowizowania, restartowania, zawieszania lub usuwania witryny. Odwrotna zasada również ma zastosowanie: rola Dewelopera zarządza witrynami i dostępem do interfejsu API bez jakiejkolwiek kontroli nad rozliczeniami. Role są przypisywane dla poszczególnych organizacji, więc rola w jednej organizacji nie daje dostępu w osobnej, niepowiązanej organizacji — chociaż rola w organizacji nadrzędnej ma zastosowanie do organizacji podrzędnych.
Proszę unieważnić go w panelu nawigacyjnym, a natychmiast przestanie działać. Zakres szkód jest ograniczony do tego, na co dany klucz pozwalał od samego początku, dlatego klucze posiadają szczegółowe uprawnienia i rejestrują znacznik czasu ostatniego użycia — wąskie uprawnienia oraz widoczna ścieżka użycia sprawiają, że wyciek staje się kontrolowanym incydentem, a nie całkowitym przejęciem konta. Należy pamiętać, że klucze są wydawane organizacji, a nie osobie fizycznej, dlatego należy traktować je jako współdzielone dane uwierzytelniające i zmieniać je w przypadku rotacji pracowników. Po naszej stronie przechowywany jest jedynie skrót klucza, więc wyciek z naszej bazy danych nie ujawni działających danych uwierzytelniających.
Tak. Każda operacja uprzywilejowana jest zapisywana w dzienniku audytu z możliwością wyłącznie dopisywania, wraz z wykonawcą, działaniem, celem, dowodami pomocniczymi, źródłowym adresem IP oraz znacznikiem czasu. Role właściciela i z prawem tylko do odczytu mogą przeglądać go bezpośrednio. Działania personelu na Państwa koncie są rejestrowane w tym samym rejestrze, a wrażliwe lub destrukcyjne działania personelu mogą wymagać wcześniejszego uwierzytelnienia wielopoziomowego lub zatwierdzenia przez dwie osoby.
Tak — SAML SSO jest obsługiwane dla kont enterprise i agencji, dzięki czemu pracownicy uwierzytelniają się za pomocą istniejących danych logowania firmowego, a ich wyrejestrowanie w katalogu powoduje usunięcie dostępu również tutaj. Mogą Państwo łączyć podejścia: SSO dla stałego personelu, konta z ograniczonym dostępem typu magic-link dla wykonawców, a wszystko w ramach tego samego modelu uprawnień.
Nie — hasła celowo nie są migrowane. Twoje konto jest importowane bez hasła, a przy pierwszym logowaniu używasz magic-link lub ustawiasz nowe hasło zgodnie z obowiązującymi zasadami. Przeniesienie starych skrótów haseł przeniosłoby stare luki w zabezpieczeniach do nowego systemu, dlatego tego nie robimy.
Okres próbny Footprint-Free trwa 14 dni, nie wymaga karty i obejmuje do pięciu witryn. W trakcie okresu próbnego otrzymują Państwo pełną warstwę tożsamości — klucze dostępu, uwierzytelnianie dwuskładnikowe, role, klucze API oraz dziennik audytu nie są zablokowane za płatnym planem.
Zarejestruj klucz dostępu (passkey), zaproś swój zespół do odpowiednich ról i wygeneruj klucz API o określonym zakresie — wszystko w ramach 14-dniowego okresu próbnego bez konieczności podawania danych karty.
Rozpocznij za darmo