Zespoły i dostęp
Cztery role klienta, subkonta odzwierciedlające rzeczywistą strukturę Państwa firmy, klucze API dla poszczególnych organizacji, logowanie jednokrotne oraz dziennik audytu każdej uprzywilejowanej operacji. Ten sam model dostępu działa w panelu, API, CLI, Terraformie oraz na naszym serwerze MCP. Dostępność: dostawca Terraform jest w trakcie aktywnego rozwoju i nie jest jeszcze dostępny. Wszystko inne opisane tutaj działa już od dziś.
Dostęp to nie jest pojedynczy przełącznik włącz/wyłącz. Każda organizacja klienta zawiera cztery role, z których każda stanowi stały pakiet szczegółowych uprawnień module.action — dzięki czemu osoba kontaktowa ds. finansów nigdy nie ma dostępu do serwera, a programista nigdy nie widzi faktury.
Pełna kontrola nad organizacją i jej subkontami: tworzenie organizacji podrzędnych, zapraszanie i usuwanie członków, zmiana ról, zarządzanie kluczami API, alokowanie, restartowanie, zawieszanie i usuwanie witryn, zarządzanie fakturami i metodami płatności oraz odczyt dziennika zdarzeń. Dwie rzeczy celowo pozostają poza tym zakresem — zamykanie organizacji i wystawianie zwrotów to działania pracowników, a nie rola klienta.
Wszystko, co finansowe, i nic więcej: faktury, subskrypcje, metody płatności i katalog planów, a także podgląd organizacji i listy jej członków. Całkowity brak dostępu do witryny — osoba kontaktowa ds. finansów ani zewnętrzny księgowy nie mogą niczego zrestartować, zawiesić ani usunąć.
Praca nad witrynami bez ingerencji w kwestie finansowe: wyświetlanie i wdrażanie witryn, restartowanie usług, czyszczenie pamięci podręcznej, zarządzanie kluczami API oraz zgłaszanie zgłoszeń do pomocy technicznej lub odpowiadanie na nie. Brak wglądu w rozliczenia, brak zarządzania członkami, brak zawieszania i brak usuwania — działania niszczące oraz komercyjne pozostają w rękach właściciela.
Pełny wgląd bez możliwości wprowadzania jakichkolwiek zmian — członkowie, witryny, rozliczenia, plany, zgłoszenia, stan tłumaczeń oraz dziennik audytu. Właściwa rola dla kluczowego interesariusza klienta, audytora wewnętrznego lub nowego pracownika, który dopiero wdraża się w obowiązki.
Dzierżawa (tenancy) to struktura drzewiasta, a nie płaska lista. Organizacja odsprzedawcy znajduje się powyżej organizacji swoich klientów, a witryny znajdują się pod nimi. Członek zespołu to członkostwo — jeden użytkownik, jedna organizacja, jedna rola — dzięki czemu ten sam element bazowy obsługuje dwuosobowy zespół, agencję zarządzającą setką kont klientów oraz odsprzedawcę prowadzącego subkonta pod własną marką.
Role są przydzielane dla poszczególnych organizacji, a ich egzekwowanie również odbywa się na poziomie organizacji. Rola w jednej organizacji nie daje żadnego dostępu w odrębnej, niepowiązanej organizacji — wykonawca może być Deweloperem na koncie jednego klienta i mieć uprawnienia tylko do odczytu na koncie drugiego, korzystając z tego samego loginu. Dostęp przechodzi jednak w dół Państwa hierarchii: rola w organizacji nadrzędnej dotyczy organizacji podrzędnych, co pozwala dystrybutorom i agencjom zarządzać swoimi klientami.
Izolacja jest wymuszana w bazie danych, a nie tylko w kodzie aplikacji. Zabezpieczenia na poziomie wierszy w bazie Postgres ograniczają zakres każdego zapytania najemcy do poddrzewa wywołującego, a wszystko poza tym poddrzewem zwraca błąd nieznalezienia zasobu zamiast błędu uprawnień — platforma nigdy więc nawet nie potwierdza istnienia organizacji lub witryny innego najemcy.
Role nie są jedynie udogodnieniem w panelu zarządzania. Każda droga dostępu do platformy odwołuje się do tych samych kluczy uprawnień, więc nie ma żadnych tylnych drzwi, które omijałyby Państwa reguły dostępu.
Witryny, rozliczenia, zgłoszenia, komunikaty, powiadomienia, klucze API i zarządzanie zespołem w jednym środowisku. Interfejs wyświetla tylko to, na co pozwala rola zalogowanego członka, dzięki czemu użytkownikom nie są pokazywane elementy sterujące, z których nie mogą korzystać.
Opublikowane API to to samo silnikowe API, z którego korzysta pulpit nawigacyjny. Klucze API są wydawane dla każdej organizacji ze szczegółowymi zakresami powiązanymi z uprawnieniami RBAC, a oddzielne tryby piaskownicy i produkcyjny oznaczają, że mogą Państwo testować integracje bez wpływu na rzeczywiste rozliczenia lub alokację zasobów.
Zarządzaj witrynami, domenami, DNS, skrzynkami pocztowymi i planami jako infrastrukturą jako kodem oraz uruchamiaj terraform apply, aby aprowizować hosting — zarządzany przez te same zakresy, co cała reszta.
Połącz Claude Code, Cursor, ChatGPT, Claude Desktop lub dowolne narzędzie obsługujące MCP. Tokeny są ograniczone do organizacji i jej uprawnień RBAC, z możliwością unieważnienia dla poszczególnych narzędzi, z potwierdzeniem działań destrukcyjnych, limitami wydatków i pełną ścieżką audytu.
Przechowywany jest wyłącznie skrót (hash) każdego klucza API — nigdy sam klucz w postaci pierwotnej. Klucze posiadają nazwę oraz widoczny prefiks, co pozwala na ich rozróżnienie, rejestrują datę ostatniego użycia i mogą być odwoływane pojedynczo bez wpływu na pozostałe.
Zarządzanie tożsamością opiera się na Keycloak, więc uwierzytelnianie to w pełni standardowe OIDC i SAML, a nie doraźny formularz logowania doczepiony do panelu hostingowego.
Każde działanie uprzywilejowane zapisuje rekord audytowy w trybie tylko do dołączania: kto je wykonał, co zrobił, na czym zostało wykonane, dowody potwierdzające oraz źródłowy adres IP. Dziennik działa w trybie tylko do dołączania — zdarzenia są dodawane, a nie edytowane na miejscu — a w środowisku produkcyjnym jest partycjonowany czasowo, dzięki czemu zachowuje wysoką wydajność w miarę wzrostu.
Odczyt tego dziennika jest sam w sobie uprawnieniem. Posiadają je właściciele oraz członkowie z prawem tylko do odczytu, dzięki czemu zarówno osoba odpowiedzialna za konto, jak i osoba je audytująca mogą przeglądać pełną historię bez konieczności posiadania podwyższonych uprawnień.
Wokół tego znajdują się mechanizmy kontroli, których oczekują większe zespoły: zasady sesji, opcjonalne listy dozwolonych adresów IP dla poszczególnych organizacji oraz uwierzytelnianie wielopoziomowe przy wrażliwych działaniach, dzięki czemu aktywna sesja nie wystarczy do wykonania poważnej operacji.
Katalog uprawnień to dane, a nie sztywno zakodowana logika — dlatego można go rozszerzać bez konieczności przebudowywania platformy.
Właściciel ma pełną kontrolę nad organizacją i jej subkontami, w tym nad członkami, kluczami API, witrynami i metodami płatności. Menedżer ds. rozliczeń widzi faktury, subskrypcje, metody płatności i plany, bez dostępu do witryn. Deweloper zarządza witrynami i kluczami API oraz obsługuje zgłoszenia, bez kontroli nad rozliczeniami ani członkami. Rola tylko do odczytu może przeglądać członków, witryny, rozliczenia, plany, zgłoszenia i dziennik audytu bez wprowadzania jakichkolwiek zmian.
Jeszcze nie jako ustawienie dla poszczególnych witryn — ograniczenie pojedynczego członkostwa do określonych witryn jest planowanym usprawnieniem. Obecnie taką samą separację można uzyskać za pomocą drzewa dzierżawy (tenancy tree): należy umieścić te witryny w organizacji podrzędnej i tam przypisać danej osobie rolę. Ponieważ role są przyznawane na poziomie organizacji, dostęp ten nie przenosi się na żadne inne elementy na Państwa koncie.
Nie — klucze API są wydawane dla poszczególnych organizacji, ze szczegółowymi zakresami powiązanymi z tymi samymi uprawnieniami RBAC oraz oddzielnymi trybami sandbox i live. Należy używać ich jako danych uwierzytelniających usługi dla integracji, CI lub Terraform, a dla osób stosować członkostwa. Przechowywany jest wyłącznie skrót każdego klucza, każdy klucz rejestruje czas jego ostatniego użycia, a dowolny klucz można unieważnić niezależnie.
Rola Dewelopera obejmuje przeglądanie i aprowizację witryn, ponowne uruchamianie usług, czyszczenie pamięci podręcznej, zarządzanie kluczami API oraz obsługę zgłoszeń. Nie daje ona uprawnień do publikowania w witrynie działającej na żywo, więc jeśli chcą Państwo, aby ktoś mógł wdrażać zmiany, taki dostęp musi posiadać właściciel. Role są przypisywane dla danej organizacji, więc na innym koncie mogą Państwo posiadać inną rolę.
Tak. Tożsamość działa w oparciu o Keycloak z obsługą OIDC i SAML, dzięki czemu pojedyncze logowanie (SSO) SAML jest dostępne dla klientów korporacyjnych i agencji wraz z logowaniem przez magic-link, adresem e-mail i hasłem, logowaniem przez serwisy społecznościowe, kluczami dostępu (passkeys) oraz uwierzytelnianiem dwuskładnikowym TOTP, które jest wymuszane przez zasady. Jedna sesja obejmuje pulpit nawigacyjny, publiczną stronę internetową, bazę wiedzy oraz zgłoszenia do pomocy technicznej.
Każde działanie uprzywilejowane jest zapisywane w dzienniku audytu z możliwością wyłącznie dopisywania, który rejestruje wykonawcę, działanie, cel, dowody potwierdzające oraz adres IP. Jego odczyt stanowi odrębne uprawnienie, przysługujące zarówno roli Właściciel, jak i Tylko do odczytu, dzięki czemu właściciel konta i audytor mogą przeglądać tę samą historię.
Ceny planów zależą od pojemności hostingu, a nie od liczby osób. Na przykład w linii Footprint-Free wszystkie 42 poziomy dzielą dokładnie ten sam zestaw uprawnień i różnią się jedynie liczbą dozwolonych witryn. Ceny są zawsze pobierane z aktualnego katalogu w Państwa walucie, więc kwota widoczna na stronie cennika jest tą, która zostanie faktycznie naliczona.
Tak. Okres próbny Footprint-Free trwa 14 dni, nie wymaga podawania danych karty i obejmuje do 5 witryn, dzięki czemu mogą Państwo skonfigurować swoją organizację, zaprosić zespół i przetestować role w rzeczywistych warunkach przed dokonaniem jakiejkolwiek płatności. Płatne plany są objęte 30-dniową gwarancją zwrotu pieniędzy.
Rozpocznij 14-dniowy okres próbny bez karty w linii Footprint-Free, zaproś swój zespół i zobacz, jak role sprawdzają się na rzeczywistych stronach, zanim cokolwiek zapłacisz.
Rozpocznij za darmo