Dostęp delegowany
Dodaj programistę, przekaż rozliczenia swojej księgowej, zapewnij klientowi dostęp w trybie tylko do odczytu do jego własnych stron lub pozwól naszemu zespołowi wsparcia przyjrzeć się problemowi. Każde nadanie uprawnień to rola ze zdefiniowanymi uprawnieniami, przypisana do organizacji, egzekwowana w bazie danych i zapisywana w dzienniku audytu z możliwością wyłącznie dopisywania.
Współdzielenie jednego loginu to prosta droga do problemów z dostępem do konta. W Zinn Digital® każda osoba ma własną tożsamość, a dostęp ma formę członkostwa — użytkownika, organizacji i roli — które można samodzielnie przyznać, zmienić lub odebrać.
Każdy współpracownik loguje się jako on sam za pośrednictwem Keycloak, naszej warstwy tożsamości. Nikt nie wpisuje Państwa hasła, nikt nie udostępnia sesji przeglądarki, a usunięcie kogoś to pojedyncza czynność, a nie zmiana hasła i gorączkowe ustalanie, kto jeszcze je znał.
Konta mają strukturę hierarchiczną — organizacja odsprzedawcy obejmuje organizacje klientów, a organizacje klientów obejmują witryny. Członkostwo dotyczy organizacji i wszystkiego, co się pod nią znajduje, dzięki czemu mogą Państwo przekazać klientowi agencyjnemu kontrolę nad jego własną organizacją bez ujawniania innych swoich klientów.
Separacja najemców nie jest filtrem w kodzie aplikacji, który mógłby zostać pominięty przez błąd. Zabezpieczenie na poziomie wiersza (Row-Level Security) w Postgres ogranicza zakres każdego zapytania do poddrzewa organizacji wywołującego, więc żądanie spoza Państwa zakresu nie ma nic do zwrócenia.
Jeśli poprosisz o organizację lub witrynę spoza twojego zakresu uprawnień, interfejs API odpowie zwykłym błędem braku zasobu zamiast błędem uprawnień. Błąd uprawnień potwierdziłby istnienie rekordu; brak zasobu nie ujawnia osobie z zewnątrz absolutnie niczego.
Uprawnienia to precyzyjne klucze — moduł plus działanie, takie jak sites.restart lub billing.refund — a role łączą je w pakiety. Cztery role odpowiadają potrzebom rzeczywistych zespołów, a każda z nich to wstępnie wprowadzone przez nas dane, a nie logika zaszyta w kodzie.
Pełna kontrola: twórz organizacje podrzędne, zapraszaj i usuwaj członków, zmieniaj role, zarządzaj kluczami API, twórz, restartuj, czyść, zawieszaj i usuwaj witryny, obsługuj rozliczenia i faktury, zgłaszaj zgłoszenia oraz czytaj dziennik audytu. Rola, którą zachowujesz dla siebie.
Widzi organizację, jej członków oraz katalog planów, a także zarządza fakturami, metodami płatności i opłatami. Brak uprawnień do tworzenia, modyfikowania lub usuwania jakiejkolwiek witryny — dokładnie taki zakres, jaki powinien mieć zewnętrzny księgowy.
Przegląda i tworzy witryny, restartuje usługi, czyści pamięć podręczną, zarządza kluczami API i obsługuje zgłoszenia. Celowo wykluczone: rozliczenia, faktury, metody płatności, zarządzanie członkami, zawieszanie witryn oraz usuwanie witryn. Wykonawca może tworzyć projekty bez możliwości obciążenia Państwa kosztami ani zniszczenia czegokolwiek.
Widzi organizację, jej członków, jej witryny, jej rozliczenia, katalog planów, zgłoszenia, stan tłumaczeń oraz dziennik audytu — i nie może niczego zmienić. Odpowiednie uprawnienie dla klienta oczekującego wglądu, audytora lub interesariusza, który potrzebuje jedynie podglądu.
Delegowanie dostępu jest bezpieczne tylko wtedy, gdy konta, na które delegujesz uprawnienia, są trudne do przejęcia. Uwierzytelnianie odbywa się za pośrednictwem Keycloak dla każdej osoby na koncie, w każdym punkcie kontaktu.
Prace wsparcia technicznego czasami wymagają wglądu do Państwa konta. Dostęp ten podlega temu samemu modelowi uprawnień, co wszystko inne — pracownicy po prostu należą do organizacji pracowniczej, podzielonej na działy z wąsko określonymi uprawnieniami.
Pracownicy są podzieleni na działy: Wsparcie, Rozliczenia i finanse, Nadużycia i zaufanie oraz bezpieczeństwo, Sprzedaż, Wdrażanie, Inżynieria i operacje, Marketing oraz Zarządzanie. Każda rola zapewnia dostęp do określonych modułów i działań, dzięki czemu agent widzi tylko tę część konsoli administracyjnej, która jest wymagana do wykonywania jego pracy, a nie resztę.
Rola Support Agent zapewnia dokładnie następujące uprawnienia: przeglądanie klientów, przeglądanie zgłoszeń i odpowiadanie na nie, przeglądanie witryn, restartowanie witryny oraz czyszczenie jej pamięci podręcznej. Nie obejmuje ona konfiguracji rozliczeń, zwrotów środków, edycji planów ani zarządzania flotą. Działania naprawcze, jakie może podjąć konsultant, są ograniczone jego rolą, a nie dobrymi intencjami.
Uprawnienie customer.impersonate nie jest częścią roli Manager — posiada je wyłącznie Super Admin. Gdy sesja jest uruchomiona w Państwa imieniu, pulpit nawigacyjny wyświetla stały baner podszywania się, dzięki czemu nigdy nie ma wątpliwości, kto podejmuje działania.
Każde działanie uprzywilejowane i administracyjne jest dopisywane do dziennika audytu typu append-only, który rejestruje wykonawcę, działanie, cel, pomocnicze metadane, adres IP oraz znacznik czasu — partycjonowanego według czasu w środowisku produkcyjnym. Właściciele oraz członkowie z uprawnieniami tylko do odczytu mogą samodzielnie przeglądać dziennik swojej organizacji.
Poufne i destrukcyjne działania personelu mogą wymagać uwierzytelniania wielopoziomowego lub zatwierdzenia przez dwie osoby przed ich wykonaniem, a nowe działy i role są kwestią konfiguracji, a nie zmiany w kodzie.
Skrypty, potoki CI, interfejs CLI, dostawca Terraform i agenci AI uwierzytelniają się za pomocą tego samego modelu uprawnień co ludzie — bez współdzielonych danych uwierzytelniających ludzi, bez długoterminowych sekretów wklejonych do kompilacji.
Klucze należą do organizacji i mają szczegółowe zakresy powiązane z tymi samymi uprawnieniami RBAC — tylko do odczytu, rozliczenia, aprowizacja. Należy przyznać potokowi tylko wąski zakres, którego potrzebuje, zamiast całego konta członka.
Klucze trybu testowego i trybu produkcyjnego różnią się od siebie, dzięki czemu opracowywana integracja nie może uzyskać dostępu do danych produkcyjnych przypadkowo ani za pośrednictwem skopiowanej zmiennej środowiskowej.
Przechowujemy skrót SHA-256 klucza tajnego oraz prefiks wyszukiwania — nigdy surowy klucz. Klucz widoczny jest tylko raz, podczas jego tworzenia. Każdy klucz rejestruje, kiedy został użyty po raz ostatni, i może zostać unieważniony oddzielnie, bez wpływu na pozostałe elementy.
Nasz serwer MCP pozwala dowolnemu agentowi obsługującemu MCP zarządzać Państwa hostingiem w języku naturalnym, z uwierzytelnianiem za pomocą OAuth 2.1 i zakresem ograniczonym do Państwa organizacji oraz roli RBAC, z unieważnialnymi tokenami dla poszczególnych narzędzi, potwierdzeniem czynności destrukcyjnych, limitami wydatków i pełnym rejestrowaniem audytowym.
Dostęp do konta i dostęp do serwera to dwie różne kwestie. Poświadczenia na poziomie witryny są zarządzane w panelu, wydawane z minimalnymi uprawnieniami i izolowane w taki sposób, aby powłoka jednego współpracownika była powłoką tylko jednej witryny.
Samodzielny operator zachowuje pojedynczą organizację i jedno członkostwo właściciela, a gdy wykonawca dołącza do projektu, dodaje rolę programisty. Po zakończeniu projektu członkostwo zostaje usunięte, a jego dane logowania natychmiast przestają działać — nie pozostają żadne udostępnione dane uwierzytelniające, które należałoby zmienić.
Agencja korzysta z drzewa organizacji. Każdy klient otrzymuje własną organizację podrzędną, zawierającą jego witryny, a jego pracownicy uzyskują w niej członkostwo — tylko do odczytu dla interesariusza oczekującego wglądu, właściciela dla klienta chcącego zarządzać samodzielnie. Państwa personel posiada członkostwo na wyższych poziomach drzewa i widzi całe portfolio; klient widzi wyłącznie własną gałąź, a zabezpieczenie na poziomie wierszy (Row-Level Security) sprawia, że jest to fakt, a nie tylko obietnica.
Reseller działa w ten sam sposób, jeden poziom wyżej: organizacja resellera zawiera organizacje klientów, z których każda ma własnych członków, widok rozliczeń i witryny. Ten sam element podstawowy obsługuje subkonta, zespoły agencyjne oraz hierarchie resellerów — dla żadnego z nich nie ma oddzielnego, słabszego mechanizmu.
Wszystko jest dostępne w ramach 14-dniowego okresu próbnego bez konieczności podawania karty. Zarejestruj się bez podawania danych płatniczych, zaproś współpracownika, sprawdź, do czego poszczególne role mają i nie mają dostępu, oraz przejrzyj własny dziennik audytu.
Obecnie członkostwo przyznaje uprawnienia w całej organizacji i wszystkim elementom znajdującym się poniżej w strukturze drzewa, dlatego sposobem na rozdzielenie zestawów witryn jest rozdzielenie organizacji — należy umieścić te witryny we własnej organizacji podrzędnej i tam przyznać członkostwo. Jest to przejrzysty model dla agencji i sprzedawców, gdzie każdy klient potrzebuje własnej odrębnej przestrzeni. Określanie zakresu zasobów na poziomie członkostwa, czyli przypisywanie pojedynczego członkostwa do wskazanych witryn w ramach jednej organizacji, to planowane ulepszenie, a nie funkcja dostępna obecnie.
Rola Programisty nie obejmuje usuwania ani zawieszania witryny — te uprawnienia należą do roli Właściciela. Umożliwia ona przeglądanie i tworzenie witryn, restartowanie usług, czyszczenie pamięci podręcznej, zarządzanie kluczami API oraz obsługę zgłoszeń. Uprawnienia do wdrażania i publikacji na środowisku produkcyjnym również nie wchodzą w zakres roli Programisty, więc przenoszenie zmian do środowiska produkcyjnego pozostaje w rękach właściciela konta. Połącz to ze środowiskiem stagingowym, aby prace programistyczne odbywały się przede wszystkim poza działającą witryną.
Zależy to całkowicie od roli pracownika, a każda rola stanowi wąski zestaw kluczy uprawnień. Na przykład Support Agent może przeglądać Państwa konto i witryny, wyświetlać zgłoszenia i odpowiadać na nie, restartować witrynę oraz czyścić jej pamięć podręczną — nie ma jednak dostępu do konfiguracji rozliczeń, zwrotów środków, planów ani floty. Logowanie się jako klient to odrębne uprawnienie przysługujące wyłącznie roli Super Admin, a w takim przypadku panel kontrolny wyświetla stały baner personifikacji. Każde działanie uprzywilejowane jest rejestrowane w dzienniku audytu wraz z wykonawcą, działaniem, celem, adresem IP oraz znacznikiem czasu, a Państwo mogą samodzielnie przeglądać dziennik swojej organizacji.
Usunięcie członkostwa powoduje zakończenie dostępu do danej organizacji — użytkownik zachowuje swoją tożsamość, ale nie ma przypisanej roli, a co za tym idzie, uprawnień na Państwa koncie. Klucze API są unieważniane indywidualnie, dzięki czemu klucz potoku można wycofać bez zakłócania działania innych elementów. W przypadku korzystania z logowania jednokrotnego SAML anulowanie aprowizacji u Państwa dostawcy tożsamości zarządza logowaniem centralnie. Dane uwierzytelniające na poziomie witryny, takie jak klucze SSH, są unieważniane w pulpicie nawigacyjnym, a samo usunięcie jest rejestrowane w dzienniku audytu.
Nie — warto jednak precyzyjnie wyjaśnić, dlaczego. Klucze API należą do organizacji, a nie do pojedynczego członka, i posiadają własne, szczegółowe zakresy powiązane z tym samym katalogiem uprawnień. Zamiast więc przekazywać klucz danej osobie, tworzą Państwo klucz do konkretnego zadania z możliwie najwęższym zakresem, jakiego to zadanie wymaga, i unieważniają ten klucz po jego zakończeniu. Przechowywany jest wyłącznie skrót (hash) klucza tajnego, a każdy klucz rejestruje czas swojego ostatniego użycia, dzięki czemu nieużywane klucze można łatwo znaleźć i wycofać.
Tak. Nasz serwer MCP uwierzytelnia agentów za pomocą protokołu OAuth 2.1 i ogranicza ich zakres do Państwa organizacji oraz roli RBAC za pomocą odwoływalnych tokenów przypisanych do poszczególnych narzędzi, dzięki czemu przyznają Państwo określone uprawnienie zamiast pełnego dostępu. Działania destrukcyjne wymagają potwierdzenia, obowiązują limity wydatków, a każde działanie trafia do tego samego dziennika audytu, co aktywność ludzka.
Funkcja Postgres Row-Level Security ogranicza zapytania do poddrzewa organizacji wywołującego w samej bazie danych, dzięki czemu filtr na poziomie aplikacji stanowi wielowarstwową ochronę, a nie jedyną linię obrony. Żądania dotyczące rekordów spoza zakresu zwracają informację o ich nieodnalezieniu zamiast błędu uprawnień, dzięki czemu nic nie zdradza ich istnienia. Po stronie serwera izolacja poszczególnych witryn za pomocą CageFS ogranicza powłokę i pliki każdego dzierżawcy wyłącznie do jego własnej witryny.
Tak. 14-dniowy okres próbny nie wymaga podawania danych karty — bez szczegółów płatności, bez zobowiązań — i obejmuje hosting Footprint-Free dla maksymalnie pięciu stron. Wystarczy to, aby zaprosić współpracownika, przypisać rolę i upewnić się, że ograniczenia działają zgodnie z Państwa potrzebami, zanim podejmą Państwo decyzję o zakupie.
Rozpocznij 14-dniowy okres próbny bez podawania danych karty, zaproś kogoś i zobacz, jak model uprawnień sprawdza się w praktyce — role, które można samodzielnie nazwać, zakresy, które można cofnąć, oraz dziennik audytu, który dokładnie wskazuje, kto i co zrobił.
Rozpocznij za darmo