Połączenie aplikacji działającej w chmurze (AWS, Azure, Hetzner) lub sklepu internetowego z lokalnym systemem ERP – takim jak Subiekt GT lub Subiekt nexo PRO – to jeden z najbardziej krytycznych punktów architektonicznych w projektach e-commerce i B2B.
Baza danych MS SQL z Subiektem zazwyczaj znajduje się na serwerze w magazynie lub biurze firmy, schowana za natywną zaporą sieciową (firewallem) oraz routerem z translacją adresów NAT.
Tradycyjne metody udostępniania tych danych zewnętrznym aplikacjom opierają się na niebezpiecznych kompromisach: otwieraniu portów bazy danych na świat, skomplikowanych konfiguracjach VPN lub powolnym odpytywaniu bazy w pętli.
W tym artykule przeanalizujemy, dlaczego klasyczne podejścia sieciowe stwarzają bezpośrednie zagrożenie dla bezpieczeństwa firmy oraz jak architektura SubiektBridge w oparciu o odwrócone tunelowanie gRPC (Reverse Tunneling) pozwala uzyskać bezpieczne połączenie z Subiektem bez otwartości portów i bez połączeń VPN.
Tradycyjne metody dostępu do bazy MS SQL – Ryzyko i słabe punkty
Inżynierowie i działy IT stojący przed zadaniem skomunikowania chmury z lokalnym Subiektem najczęściej sięgają po jedno z trzech rozwiązań legacy. Każde z nich generuje poważny dług technologiczny lub bezpośrednie ryzyko cybernetyczne.
1. Przekierowanie portu 1433 (Publiczny dostęp MS SQL)
Polega na ustawieniu reguły Port Forwarding na routerze w magazynie i otwarciu portu serwera SQL bezpośrednio do publicznego internetu.
- Ryzyko: Wystawienie portu
1433do sieci sprawia, że serwer produkcyjny w ciągu kilku minut staje się obiektem automatycznych ataków Brute-Force, skanowania luk oraz prób wstrzyknięcia złośliwego kodu. To najkrótsza droga do zaszyfrowania bazy przez oprogramowanie typu Ransomware.
2. Dedykowany tunel VPN (Site-to-Site / OpenVPN / IPsec)
Zestawienie stałego połączenia szyfrowanego pomiędzy serwerem chmurowym a siecią firmową.
- Wady: Wymaga posiadania stałego, publicznego adresu IP w magazynie, drogiej infrastruktury sieciowej oraz ciągłego nadzoru administratora. Przy łączach LTE lub awariach dostawcy internetu tunel VPN często ulega zerwaniu, blokując synchronizację zamówień do czasu ręcznego restartu urządzeń.
3. Klasyczny Polling (Pętla czasowa odpytywania)
Lokalny skrypt uruchamiany na serwerze co 10–15 minut odpytuje bazę SQL i wysyła zmienione pakiety do chmury.
- Wady: Brak pracy w czasie rzeczywistym, wysokie opóźnienia ($> 15\text{ min}$) oraz stałe obciążenie bazy zapytywanimi
SELECT, co prowadzi do zakleszczeń tabel (Deadlocks) podczas pracy magazynierów.
Architektura SubiektBridge: Odwrócone Tunelowanie gRPC (Outbound Only)
Aby całkowicie wyeliminować konieczność otwierania jakichkolwiek portów wejściowych (Inbound Ports) na routerze magazynu, usługa SubiektBridge zmienia paradygmat komunikacji sieciowej. System wykorzystuje technologię odwróconego tunelu (Reverse Tunneling) napędzaną przez protokół gRPC (HTTP/2).
Jak to działa krok po kroku?
- Inicjalizacja Wychodząca (Outbound Only): Usługa SubiektBridge zainstalowana na serwerze lokalnym nawiązuje szyfrowane połączenie TLS 1.3 przez port
443(HTTPS) do chmurowego węzła SubiektBridge Cloud Relay. - Brak Modyfikacji Firewalla: Dla firmowej zapory sieciowej jest to zwykły ruch wyjściowy (taki sam jak otwieranie stron WWW). Router nie musi posiadać otwartych portów ani publicznego, stałego adresu IP.
- Strumieniowanie gRPC (HTTP/2): Protokół gRPC umożliwia dwukierunkową, obustronną transmisję danych (Bi-directional Streaming) przy użyciu binarnej serializacji Protobuf.
- Egzekucja w Sferze: Zapytanie spływające z chmury trafia aktywowanym tunelem gRPC do usługi lokalnej, która bezpiecznie wykonuje operację w obiekcie Sfera dla Subiekta GT lub Sfera dla nexo PRO i zwraca wynik.
Zestawienie rozwiązań dostępu do bazy ERP
| Parametr / Wymóg | Otwarty Port MS SQL (1433) | Tunel VPN (IPsec / OpenVPN) | SubiektBridge (Odwrócone gRPC) |
| Otwieranie portów wejściowych (Inbound) | TAK (Skrajne ryzyko) | TAK (Dla bramki VPN) | NIE (100% Ruch Wychodzący) |
| Stałe IP w miejscu instalacji ERP | Wymagane | Wymagane (lub trudny DDNS) | Zbędne (Działa na dynamicznym IP / LTE) |
| Protokół i szyfrowanie | Zależne od konfiguracji SQL | TLS / IPsec | TLS 1.3 + gRPC + Tokeny Bearer |
| Narzut sieciowy (Payload Size) | Bardzo duży (Zapytania SQL) | Średni (Narzut nagłówków VPN) | Minimalny (Binarny Protobuf) |
| Czas odpowiedzi (Latency) | Niski | Średni | Ultra niski ($< 20\text{ ms}$) |
| Bezpieczeństwo bazy danych | Risk: Modyfikacja SQL | Zależne od aplikacji | 100% spójności (Wyłącznie Sfera) |
Dlaczego architekci oprogramowania wybierają gRPC w SubiektBridge?
Zastosowanie gRPC jako warstwy transportowej przynosi wymierne korzyści wydajnościowe i operacyjne:
- Pakiety binarne zamiast ciężkiego tekstu: Serializacja danych przy użyciu Protocol Buffers (Protobuf) zmniejsza rozmiar przesyłanych ładunków o $70\text{–}80\%$ w porównaniu do tradycyjnych formatów XML czy JSON.
- Autonomiczne odnawianie połączenia (Self-Healing): W przypadku chwilowego zaniku internetu w magazynie (np. przełączenie łącza na zapasowe LTE), tunel gRPC automatycznie wznawia pracę w tle bez konieczności restartowania usług.
- Buforowanie w chmurze (Message Queueing): Jeśli serwer lokalny zostanie wyłączony, zapytania przychodzące z chmury zostaną bezpiecznie zbuforowane i przekazane do Subiekta natychmiast po jego ponownym uruchomieniu.
Checklist: Jak przygotować infrastrukturę IT pod bezpieczne połączenie?
Wdrożenie technologii SubiektBridge w firmie nie wymaga rewolucji w serwerowni. Upewnij się, że spełniasz poniższe wymagania:
- Zezwolenie na ruch wyjściowy: Dostęp serwera lokalnego do portu
443(HTTPS) w sieci zewnętrznej. - Zainstalowana usługa lokalna: Uruchomiony proces tła SubiektBridge (.NET 8) na maszynie z bazą Subiekta.
- Licencja Sfery: Aktywna licencja Sfery dla Subiekta GT lub nexo PRO dla zachowania 100% spójności bazy MS SQL.
- Klucze autoryzacyjne API: Wygenerowane tokeny wywołania (Bearer Tokens) dla zewnętrznych aplikacji webowych lub mobilnych.
Najczęściej zadawane pytania (FAQ)
Czy SubiektBridge wymaga zakupu stałego adresu IP od dostawcy internetu?
Nie. Ponieważ połączenie gRPC jest inicjowane jako ruch wyjściowy z serwera lokalnego (Outbound), usługa działa bezawaryjnie na łączach z dynamicznym adresem IP (np. Neostrada, światłowody symetryczne, internet mobilny LTE/5G).
Czy ruch przechodzący przez tunel gRPC jest szyfrowany?
Tak. Całość komunikacji pomiędzy lokalną usługą a węzłem chmurowym jest szyfrowana przy użyciu protokołu TLS 1.3 z wykorzystaniem certyfikatów kryptograficznych. Dodatkowo każde zapytanie HTTP wymaga autoryzacji nagłówkiem API Key.
Czy poprzez bezpieczne połączenie gRPC mogę odbierać powiadomienia Webhook?
Tak. SubiektBridge działa dwukierunkowo. Jeśli na serwerze lokalnym wystąpi zdarzenie (np. wystawienie faktury FS lub zmiana stanu magazynowego), usługa błyskawicznie prześle powiadomienie Webhook HTTP POST do Twojej aplikacji w chmurze w czasie poniżej 200 ms.
Podsumowanie: Przejdź na nowoczesny standard bezpieczeństwa IT
Narażanie firmowej bazy MS SQL na ataki poprzez otwieranie portów czy walka z niestabilnymi połączeniami VPN to przeżytek, który generuje niepotrzebne koszty i ryzyko.
Wdrożenie bezpiecznego połączenia z Subiektem przy użyciu odwróconego tunelowania gRPC w usłudze SubiektBridge gwarantuje natychmiastowy czas reakcji, 100% ochrony firmowej sieci oraz pełną spójność danych dzięki wykorzystaniu oficjalnej Sfery InsERT.
Zabezpiecz swój system ERP i połącz go z chmurą bez barier sieciowych.