Gate Access Stack

Prosty i bezpieczny system dostępu do zasobów firmy

1. Wstęp

Dostęp do wewnętrznych systemów firmowych w dobie pracy zdalnej, biur rozproszonych geograficznie oraz VPN-ów to temat, który dotyka niemal każdej nowoczesnej organizacji. Z jednej strony chcemy, by nasi pracownicy, partnerzy czy zewnętrzni administratorzy mieli wygodny dostęp do kluczowych zasobów z drugiej strony bezpieczeństwo tych zasobów musi pozostać bezkompromisowe.

W Sparksome postanowiliśmy rozwiązać ten problem, tworząc Gate Access Stack – mikrousługowy system bramkowania dostępu. Jest to bramka przed systemami wewnętrznymi, która dopuszcza użytkownika na podstawie linku e-mail lub zaufanego IP. Naszym celem było zbudowanie dodatkowej warstwy bezpieczeństwa, która pozwala:

• nie wystawiać usług takich jak panele Zabbix, Grafana, Jenkins czy inne bezpośrednio do internetu,
• chronić zasoby bez konieczności wdrażania pełnego systemu logowania użytkowników,
• zastosować lekkie i elastyczne mechanizmy dopuszczania ruchu oparte na tokenach tymczasowych, wysyłanych e-mailem,
• w razie potrzeby dopuścić automatycznie użytkownika po adresie IP (np. z biura lub przez VPN).

Oczywiście można byłoby rozwiązać to klasycznie, przez zamknięcie wszystkiego za VPN-em lub ręczne definiowanie listy zaufanych adresów IP. W wielu przypadkach użytkownik nie potrzebuje jednak pełnego dostępu do całej sieci przez VPN, chce tylko na chwilę wejść do konkretnego systemu, by sprawdzić coś z prywatnego laptopa, telefonu komórkowego lub komputera w domu. Tworzenie konta VPN dla każdej takiej sytuacji może być przesadne, a zarządzanie dynamicznymi adresami IP bywa zawodne.

Dlatego powstał Gate Access Stack (w skrócie Gate) lekkie rozwiązanie, które pełni rolę logicznej bramy przed systemami docelowymi. Nie zastępuje ono docelowego logowania w aplikacjach, nie przechowuje haseł, nie zarządza kontami użytkowników. Gate jedynie autoryzuje dostęp do samej usługi (np. panelu monitoringu czy administracji), a właściwe logowanie, jeśli istnieje, odbywa się dalej, już wewnątrz danego systemu. System działa na bazie kontenerów Docker i może zostać wdrożony zarówno lokalnie, jak i w środowiskach chmurowych. Dzięki komponentom takim jak Nginx, Redis oraz lekkim mikrousługom w Go, Gate łączy w sobie prostotę, bezpieczeństwo i elastyczność, której często brakuje w rozwiązaniach typu „enterprise”.

Krótko mówiąc; prosto, bezpiecznie i bez loginów i haseł do momentu, gdy są naprawdę potrzebne.

2. Kluczowe wyzwania i potrzeby

W trakcie organizowania dostępu do systemów wewnętrznych zidentyfikowaliśmy kilka kluczowych wymagań, które musiały zostać spełnione:

Bezpieczny zdalny dostęp

Dostęp do takich systemów jak Zabbix, Grafana czy panele administracyjne musi być możliwy zdalnie, ale bez kompromisów bezpieczeństwa. Oczekiwaliśmy rozwiązania, które nie wymaga korzystania z VPN na każdym urządzeniu, ale jednocześnie zapewnia pełną kontrolę, zgodność z wewnętrzną polityką bezpieczeństwa i zasadami minimalizacji ekspozycji.

Dostęp tymczasowy

W wielu przypadkach użytkownik (administrator, partner, technik) potrzebuje dostępu jednorazowego lub tymczasowego. Zakładanie kont VPN dla takich sytuacji generuje niepotrzebną administrację i ryzyko utrzymania starych, nieużywanych tożsamości. Potrzebowaliśmy dostępu, który można przyznać ad hoc, bez formularzy, rejestracji i tworzenia trwałych danych w systemie.

Prostota użytkowania

Dostęp powinien być możliwy bez konieczności kontaktu z administratorem, pobierania aplikacji czy konfigurowania klienta VPN. Użytkownik musi być w stanie samodzielnie uruchomić sesję, korzystając jedynie z przeglądarki, niezależnie od systemu operacyjnego i urządzenia.

Zgodność z normami (np. ISO/IEC 27001)

Z perspektywy organizacyjnej ważne było, aby rozwiązanie wpisywało się w politykę bezpieczeństwa i mogło być argumentowane w ramach zgodności z normami, takimi jak ISO/IEC 27001. Potrzebowaliśmy logiki, która spełnia wymagania dotyczące ograniczania dostępu, kontroli punktów wejścia, sesji użytkowników i ich ograniczonej ważności.

Jedno miejsce kontroli

Zamiast rozproszonej kontroli dostępu w każdym z systemów, celem było ujednolicenie podejścia: jedno źródło decyzji o tym, kto może dostać się do środka – niezależnie od tego, czy chodzi o monitoring, panel CI/CD, czy serwis konfiguracyjny.

3. Jak to działa?

Gate Access Stack został zaprojektowany jako warstwa kontrolna/przejściowa między użytkownikiem a systemem wewnętrznym. System umożliwia bezpieczne i czasowe dopuszczenie do zasobu na podstawie tokenu otrzymanego e-mailem lub zaufanego adresu IP. Całość opiera się na prostym modelu: żądanie → weryfikacja → przekierowanie, przy pełnej izolacji logicznej systemów docelowych.

Przebieg autoryzacji

1. Użytkownik inicjuje żądanie logowania poprzez dedykowaną stronę (Gate).

2. Po podaniu loginu i domeny e-mail, generowany jest token UUID zapisywany w Redis z określonym czasem ważności. 3. Użytkownik otrzymuje e-mail z linkiem aktywacyjnym. Po kliknięciu, token zostaje zamieniony na sesję. 4. Przeglądarka zapisuje ciasteczko z identyfikatorem sesji, a użytkownik może kontynuować pracę. 5. Gdy następuje próba dostępu do chronionej aplikacji (np. systemu monitoringu), Nginx przekazuje zapytanie do usługi weryfikującej. 6. Weryfikacja może odbywać się poprzez ciasteczko (sesja) lub adres IP – zgodnie z zasadą zaufanego źródła. Cały proces został przedstawiony na diagramach z uwzględnieniem logiki tokenów, sesji oraz fallbacku IP.

Komponenty

Aplikacja składa się z następujących mikrousług:

• auth-service Obsługuje formularz logowania, generuje tokeny i odpowiada za wysyłkę wiadomości e-mail z linkiem aktywacyjnym. Odpowiada również za ustawianie ciasteczek sesyjnych w przeglądarce.

• jwt-checker Niezależna usługa HTTP wywoływana przez auth_request w Nginx. Odpowiada za weryfikację sesji lub adresu IP. Informacja o dostępie (lub jego braku) zwracana jest w formie kodu HTTP.

• ip-checker Prosty mechanizm służący do cyklicznego rozwiązywania domen (np. DDNS) i aktualizowania listy zaufanych IP w Redis.

• Nginx (reverse proxy) Pośredniczy w komunikacji użytkownika z systemami wewnętrznymi. Odpowiada za uwierzytelnienie żądania i przekierowanie tylko tych, które zostały pozytywnie zweryfikowane.

  

Przykład zastosowania

Firma udostępnia system monitoringu wewnętrznego (np. Zabbix) wyłącznie dla administratorów i partnerów. Pracownik z biura uzyskuje dostęp bezpośrednio, jego adres IP znajduje się na liście zaufanych. Osoba z zewnątrz (np. inżynier serwisu) korzysta z linku aktywacyjnego przesłanego na adres e-mail. W obu przypadkach ad system docelowy pozostaje niewidoczny publicznie, a decyzja o dopuszczeniu zapada centralnie, w obrębie Gate Access Stack.

4. Architektura rozwiązania

Gate Access Stack został zaprojektowany jako zestaw lekkich, niezależnych komponentów. Każdy z nich realizuje ściśle określoną funkcję, co przekłada się na modularność, prostotę utrzymania i elastyczność wdrożeniową.

Stack technologiczny

• Język programowania: Go (dla wszystkich usług backendowych),
• Baza danych: Redis (pamięć klucz-wartość, działająca jako magazyn sesji i tokenów),
• Proxy sieciowe: Nginx z wykorzystaniem auth_request,
• Orkiestracja: Docker Compose (całość systemu uruchamiana jako lokalny stack).

Zastosowanie Redis jako wspólnego magazynu umożliwia bardzo szybkie operacje odczytu i TTL per wpis (np. token 20 min, sesja 24h, IP 5 min).

Funkcja auth_request w Nginx – niewidoczna, ale kluczowa

Nginx to popularny serwer webowy i reverse proxy, ale niewiele osób wie, że posiada on natywną funkcję o nazwie auth_request, która umożliwia weryfikację autoryzacji użytkownika przed dopuszczeniem do aplikacji. W praktyce oznacza to, że zanim jakiekolwiek żądanie HTTP (np. próba wejścia na zabbix.domena.pl) trafi do systemu docelowego, Nginx najpierw kieruje je do osobnej usługi sprawdzającej tzw. weryfikatora dostępu. W przypadku Gate Access Stack takim weryfikatorem jest jwt-checker. To prosta usługa napisana w Go, która sprawdza dwie rzeczy:

1. Czy w ciasteczku przeglądarki znajduje się aktywna sesja (session:<UUID> w Redis),
2. Albo czy adres IP użytkownika jest zaufany (trusted_ip:<IP> również w Redis).

W odpowiedzi jwt-checker zwraca tylko kod HTTP – 200, jeśli dostęp jest dozwolony, lub 401, jeśli nie. Nginx, na podstawie tego kodu, automatycznie podejmuje decyzję: przepuszcza ruch dalej lub przekierowuje użytkownika na stronę logowania. Co istotne ta funkcjonalność działa całkowicie poza aplikacją docelową. Nie wymaga żadnych zmian po stronie systemów, które chronimy. Dzięki temu można błyskawicznie włączyć dodatkową warstwę zabezpieczeń bez modyfikacji kodu aplikacji.

To właśnie auth_request sprawia, że Gate może być wdrożony jako uniwersalna bramka, niezależnie od rodzaju systemu za nią umieszczonego; aplikacja webowa, dashboard, API itp.

Wydajność i bezpieczeństwo dzięki Go

Wszystkie komponenty backendowe Gate zostały napisane w języku Go. Zapewnia to bardzo niskie zużycie zasobów, krótki czas uruchamiania i wysoką stabilność. Usługi nie wymagają zewnętrznych środowisk uruchomieniowych (jak PHP, Python czy Node.js), co znacząco upraszcza wdrożenie i ogranicza powierzchnię potencjalnych błędów.

auth-service jest usługą, z którą użytkownik końcowy ma bezpośredni kontakt. Obsługuje:

• stronę logowania,
• generowanie tokenów,
• wysyłanie wiadomości e-mail z linkiem aktywacyjnym,
• oraz potwierdzanie tokenu i ustawianie sesji.

Z tego powodu auth-service posiada publiczne endpointy, ale ich zakres został ograniczony do absolutnego minimum, tylko do tego, co niezbędne do przeprowadzenia procesu logowania. Dodatkowo komponent ten nie udostępnia żadnego zewnętrznego API ani danych wrażliwych, a wszystkie działania związane z przetwarzaniem tokenów i ciasteczek są wykonywane wewnątrz aplikacji, bez pośredników.

W przeciwieństwie do tego, jwt-checker działa wyłącznie jako wewnętrzny punkt weryfikacji, nie komunikuje się bezpośrednio z użytkownikiem. To ten komponent odpowiada na zapytania z Nginx (auth_request) i ocenia, czy dane żądanie powinno zostać dopuszczone. Jego endpoint (/validate) jest dostępny jedynie lokalnie, w ramach sieci kontenerów, co zwiększa bezpieczeństwo rozwiązania. Dzięki temu system nie wystawia żadnej warstwy logicznej walidacji sesji do świata zewnętrznego.

Z architektonicznego punktu widzenia takie rozdzielenie: publiczny auth-service i niewidoczny jwt-checker, umożliwia bezpieczne skalowanie, łatwe aktualizacje oraz możliwość izolowania ryzyka na poziomie infrastruktury (np. przez reguły firewall lub konfigurację reverse proxy).

Redis – ultralekka baza sesji i uprawnień

Redis to szybka baza typu key-value, zaprojektowana do przechowywania danych tymczasowych. W Gate pełni kluczową rolę, to tu trafiają:

• tokeny logowania (auth_token:<UUID>), generowane przy pierwszym kontakcie,
• aktywnie trwające sesje użytkowników (session:<UUID>),
• lista zaufanych IP (trusted_ip:<IP>), np. z biura, VPN lub DNS.

Największą zaletą Redis jest wbudowany mechanizm TTL (time-to-live), czyli automatycznego wygaszania wpisów. Dzięki temu nie trzeba sprzątać danych ręcznie, tokeny logowania wygasają po 20 minutach, sesje po 24 godzinach, a IP zaufane dodane przez ip-checker mają żywotność 5 minut (i są co jakiś czas odświeżane).

Redis działa w pamięci (RAM), więc wszystkie operacje są bardzo szybkie: odczyt sesji czy tokenu trwa zwykle ułamki milisekund. Co ważne, w sytuacjach bardziej wymagających Redis może pracować w trybie klastrowym lub replikowanym, zapewniając wysoką dostępność i odporność na awarie.

Z punktu widzenia administratora Redis w tym zastosowaniu nie wymaga żadnej konfiguracji relacyjnej, schematów danych ani skomplikowanego zarządzania. Wpisy mają prosty format: klucz → wartość, i są obsługiwane przez klienta Redis w każdej mikrousłudze.

Modularność

Każdy komponent może zostać zastąpiony, zintegrowany lub rozszerzony niezależnie:

• Możliwość podmiany auth-service na własny interfejs (np. React + backend w Pythonie),
• Wymiana Redis na alternatywne magazyny (przy zachowaniu prostego interfejsu klucz-wartość),
• Integracja z zewnętrznymi usługami e-mail (SMTP, API),
• Opcjonalna rozbudowa o federację tożsamości (LDAP, SAML, SSO) zamist lub równolegle z email.

Dzięki temu system można łatwo dostosować do polityki bezpieczeństwa, procesów DevOps lub wymagań klienta końcowego.

Tryby wdrożenia

Rozwiązanie może być z powodzeniem uruchomione w dwóch modelach:

• on-premise – jako lokalna instancja (np. w sieci klienta), z własnymi certyfikatami SSL i infrastrukturą,
• chmurowo – z dostępem za pośrednictwem usług typu CDN/WAF (np. Cloudflare), z dynamicznym IP (rozpoznawanym po DNS) i opcjonalnym wsparciem dla kilku domen.

W obu przypadkach rozwiązanie nie wymaga stałego klienta VPN, nie przechowuje haseł i działa w pełni przeglądarkowo, zgodnie z zasadą ograniczonego i świadomego dostępu.

5. Funkcje bezpieczeństwa

Gate Access Stack został zaprojektowany z myślą o wzmacnianiu bezpieczeństwa dostępu do systemów wewnętrznych. Rozwiązanie opiera się na zasadzie separacji warstw i pełni funkcję pierwszej bramki kontrolnej, która działa przed właściwym logowaniem użytkownika w aplikacji docelowej.

Celem Gate nie jest zastąpienie mechanizmów autoryzacji w systemach takich jak Zabbix, Grafana czy Jenkins, lecz stworzenie niezależnej warstwy weryfikacyjnej, która ogranicza dostęp do tych usług wyłącznie dla użytkowników wcześniej zatwierdzonych na podstawie tokenu, sesji lub adresu IP.

Dwuwartstwowy model dostępu

Faza 1: Weryfikacja na poziomie Gate (sieć / kontekst / sesja) Użytkownik musi potwierdzić dostęp poprzez link aktywacyjny wysłany na e-mail lub pochodzenie żądania z zaufanego adresu IP (np. biura, VPN). Gate weryfikuje sesję na podstawie tokenu lub IP, zanim żądanie dotrze do aplikacji.

Faza 2: Logowanie aplikacyjne (rola / konto / 2FA) Po dopuszczeniu przez Gate, użytkownik trafia do systemu docelowego, który może wymagać pełnego uwierzytelnienia: hasła, logowania federacyjnego (SSO), uwierzytelniania wieloskładnikowego itd.

Takie rozdzielenie umożliwia wdrożenie modelu obrony warstwowej (defense-in-depth), zgodnego z dobrymi praktykami architektury bezpieczeństwa.

Kontrola czasu i sesji

• Token logowania (auth_token:<UUID>) ważny jest domyślnie 20 minut, po użyciu lub wygaśnięciu jest usuwany.
• Sesja użytkownika (session:<UUID>) aktywna jest przez 24 godziny, po czym wygasa automatycznie.
• Zaufane IP (np. dynamiczne IP biura) są rejestrowane przez ip-checker z TTL 5 minut i odświeżane cyklicznie.

Mechanizm ten pozwala ograniczyć dostęp czasowo i kontekstowo, zmniejszając ryzyko nadużyć i zapewniając pełną kontrolę nad aktywnymi połączeniami.

Ciasteczka zabezpieczające sesję

W aplikacji Gate sesje są przechowywane w przeglądarce w postaci ciasteczek HTTP, wyposażonych w komplet wymaganych flag bezpieczeństwa:

• Secure – przesyłane wyłącznie przez HTTPS,
• HttpOnly – niedostępne z poziomu JavaScript,
• SameSite=Strict – chronione przed żądaniami typu cross-origin.

Dzięki temu minimalizowane jest ryzyko przejęcia sesji przez skrypty trzecie (XSS) czy nieautoryzowane żądania (CSRF).

Obsługa X-Forwarded-For i proxy

Weryfikacja adresów IP użytkownika odbywa się z uwzględnieniem nagłówka X-Forwarded-For, co zapewnia zgodność z architekturą reverse proxy i usługami typu CDN/WAF (np. Cloudflare). Konfiguracja Nginx uwzględnia pełną listę zakresów IP Cloudflare, umożliwiając bezpieczne przetwarzanie danych nawet przy złożonym łańcuchu pośredników sieciowych.

Minimalizacja danych

System nie przechowuje kont użytkowników, haseł ani danych trwałych. Adres e-mail użytkownika wykorzystywany jest wyłącznie do wysyłki linku logowania, a jego obecność w systemie ograniczona jest czasowo (20 minut w Redis). To podejście pozwala spełnić wymogi dotyczące minimalizacji danych i ogranicza obowiązki związane z RODO czy audytami dostępu.

Gate nie zastępuje procedur bezpieczeństwa aplikacji, stanowi natomiast uzupełniający, niezależny komponent, który podnosi poziom ochrony bez zwiększania złożoności systemu docelowego.

6. Zgodność z normami bezpieczeństwa

Zgodność z ISO/IEC 27001:2022

Zgodność z ISO/IEC 27002:2022

Zgodność z CIS Controls v8

Wsparcie dla RODO i ochrony danych osobowych

Gate Access Stack wpisuje się w zasady privacy by design i privacy by default poprzez:

• minimalizację przetwarzanych danych (brak kont użytkowników, brak haseł),
• ograniczenie czasu przechowywania informacji (krótkie TTL dla tokenów i sesji),
• eliminację ryzyka niekontrolowanego dostępu do usług z zewnątrz,
• wspieranie kontroli audytowych i zgodności z politykami bezpieczeństwa.

7. Możliwości rozwoju

Gate Access Stack został zaprojektowany z myślą o elastycznym dopasowaniu do zróżnicowanych środowisk organizacyjnych i polityk bezpieczeństwa. Jego architektura umożliwia zarówno rozbudowę o zaawansowane mechanizmy tożsamości, jak i integrację z istniejącą infrastrukturą klienta.

Integracja z systemami uwierzytelniania

W zależności od potrzeb, możliwa jest integracja z:

• SSO (Single Sign-On) – na podstawie protokołów federacyjnych, takich jak SAML czy OpenID Connect,
• OAuth 2.0 – z uwierzytelnieniem przez zewnętrznego dostawcę tożsamości (np. Google Workspace, Azure AD),
• LDAP lub Active Directory – w celu weryfikacji tożsamości użytkowników na podstawie lokalnej struktury katalogowej,
• RADIUS – jako warstwa kontrolna przy uwierzytelnianiu dostępu do infrastruktury systemowej.

Dziedziczenie tokenu Gate przez systemy docelowe

Alternatywnie, możliwa jest integracja docelowych aplikacji z Gate w sposób umożliwiający dziedziczenie tokenu sesyjnego. W takim przypadku, system znajdujący się „za bramką” może rozpoznać użytkownika na podstawie sesji Gate (ciasteczka) i kontynuować autoryzację bez konieczności ponownego logowania.

Taka integracja umożliwia:

• uproszczenie ścieżki użytkownika – pojedynczy dostęp do wielu systemów,
• synchronizację z wewnętrznymi systemami uprawnień,
• wykorzystanie Gate jako komponentu federacyjnego w większym ekosystemie bezpieczeństwa.

8. Wnioski i korzyści biznesowe

Gate Access Stack to lekkie, niezależne rozwiązanie, które pozwala wprowadzić skuteczną kontrolę dostępu bez konieczności budowy pełnej infrastruktury tożsamości. Sprawdza się tam, gdzie liczy się szybkie wdrożenie, zgodność z normami bezpieczeństwa oraz ograniczenie ekspozycji systemów na świat zewnętrzny bez komplikowania środowiska IT.

Spójne bezpieczeństwo bez obciążania systemów

Rozwiązanie działa zgodnie z zasadami defense-in-depth i spełnia kluczowe wymagania ISO/IEC 27001 oraz 27002. Izoluje warstwę autoryzacji od aplikacji, dzięki czemu można ją wdrożyć bez ingerencji w ich kod. Gate:

• weryfikuje kontekst (czas, IP, sesja),
• nie przechowuje haseł ani danych trwałych,
• działa jako dodatkowa warstwa ochronna przed właściwym logowaniem.

Skalowalność i elastyczność wdrożeniowa

Architektura mikrousług i kontenerowa forma wdrożenia sprawiają, że Gate może funkcjonować jako:

• punktowy komponent zabezpieczający pojedynczy system,
• brama centralna dla wielu usług wewnętrznych w większym środowisku.

Stack można łatwo dostosować do istniejących procesów DevOps, polityk bezpieczeństwa oraz infrastruktury sieciowej (on-premise i chmurowej).

Dopasowanie do różnych organizacji

Gate został zaprojektowany z myślą o wszechstronności od małych zespołów IT, po działy infrastruktury w dużych firmach. Może współpracować z innymi systemami dostępowymi (VPN, SSO), działać równolegle lub pełnić funkcję bramki wstępnej w środowiskach o podwyższonych wymaganiach bezpieczeństwa.

9. Kontakt i demo

Gate Access Stack jest dostępny jako gotowy zestaw kontenerów, gotowych do uruchomienia w Twoim środowisku lokalnym lub chmurowym.

Jeśli chcesz:

• sprawdzić, jak Gate może zabezpieczyć Twoje panele administracyjne, dashboardy lub API,
• skonsultować integrację z istniejącą infrastrukturą (np. VPN, Cloudflare, LDAP),
• przetestować działanie systemu w praktyce,

napisz do nas – chętnie pokażemy demo, omówimy możliwe scenariusze wdrożenia i podzielimy się doświadczeniem z faktycznych implementacji.

Gate Access Stack nie jest kolejnym „frameworkiem” – to działający produkt, który możesz wdrożyć w ciągu godziny. Skontaktuj się i przekonaj się, jak prosta może być kontrola dostępu.

FAQ – Najczęściej zadawane pytania o Gate Access Stack