Bezpieczna integracja ERP: Dlaczego nie powinieneś wystawiać bazy SQL Subiekta na publiczne IP?

W dobie rosnącej liczby cyberataków typu ransomware i wycieków danych osobowych, bezpieczeństwo systemów ERP takich jak Subiekt GT czy nexo PRO staje się priorytetem. Wielu przedsiębiorców, chcąc szybko połączyć swój sklep internetowy z bazą danych, decyduje się na najprostsze, ale zarazem najniebezpieczniejsze rozwiązanie: otwarcie portu SQL (domyślnie 1433) na publicznym adresie IP. Zakładamy, że czytałeś nasz artykuł o podstawach bezpieczeństwa: API do Subiekt GT i nexo PRO

W tym artykule wyjaśnimy, dlaczego takie podejście to prosta droga do katastrofy i jak zbudować bezpieczną integrację ERP zgodnie ze standardami na rok 2026.

1. Port 1433 – Ulubiony cel botów i hakerów

Otwarcie portu bazy danych MS SQL na świat jest jak zostawienie otwartego sejfu na środku ulicy z tabliczką „zapraszam”. Boty skanujące internet w poszukiwaniu otwartych portów 1433 działają 24/7.

Co ryzykujesz, wystawiając SQL na publiczne IP?

  • Ataki Brute Force: Automatyczne systemy będą próbować tysięcy kombinacji haseł do użytkownika sa (System Administrator), aż do skutku.
  • Exploity 0-day: Nawet jeśli masz silne hasło, luka w samym silniku MS SQL może pozwolić na przejęcie kontroli nad serwerem.
  • Ransomware: Po uzyskaniu dostępu do bazy, hakerzy szyfrują Twoje dane (faktury, stany, historię klientów) i żądają ogromnego okupu za ich odblokowanie.

2. RODO i ochrona danych kontrahentów

Pamiętaj, że w bazie Subiekta przechowujesz dane osobowe: imiona, nazwiska, adresy, numery telefonów oraz NIP-y Twoich klientów. Zgodnie z przepisami RODO, jako administrator danych masz obowiązek zapewnić im należytą ochronę.

Wystawienie bazy na publiczne IP bez dodatkowych zabezpieczeń (jak VPN czy Proxy) może zostać uznane za rażące zaniedbanie w przypadku wycieku danych, co wiąże się z ogromnymi karami finansowymi i utratą reputacji.

3. Bezpieczna alternatywa: Architektura Bridge API i Reverse Proxy

Jak więc połączyć Subiekta z chmurą, nie ryzykując bezpieczeństwa? Rozwiązaniem jest zastosowanie warstwy pośredniej (Middleware) działającej wewnątrz Twojej sieci lokalnej.

Jak wygląda bezpieczny model integracji?

  1. Baza SQL: Jest całkowicie odcięta od internetu (nasłuchuje tylko na localhost lub w sieci LAN).
  2. Bridge API (Docker): Działa na tym samym serwerze lub w tej samej sieci. Łączy się z SQL lokalnie.
  3. Traefik / Nginx (Reverse Proxy): Tylko ten element jest widoczny na zewnątrz, ale nie udostępnia bazy, lecz jedynie szyfrowane (SSL) i autoryzowane punkty końcowe API (endpoints).
  4. Autoryzacja Bearer Token: Każde zapytanie ze sklepu musi posiadać unikalny klucz. Bez niego serwer natychmiast odrzuca połączenie, zanim w ogóle dotknie ono bazy Subiekta.

4. Dlaczego VPN to nie zawsze idealne rozwiązanie?

Częstym pomysłem jest spięcie sklepu z Subiektem przez tunel VPN. Choć jest to bezpieczniejsze niż otwarty port, posiada swoje wady w e-commerce:

  • Wydajność: Tunele VPN wprowadzają narzut (latency), co spowalnia synchronizację stanów.
  • Stabilność: Jeśli połączenie VPN zostanie przerwane, integracja przestaje działać.
  • Skomplikowanie: Wymaga konfiguracji po stronie serwera sklepu (co w systemach SaaS jak Shopify jest niemożliwe).

REST API (JSON) przez HTTPS jest standardem, który łączy bezpieczeństwo VPN-a z lekkością i uniwersalnością internetu.

5. Backup – Twoja ostatnia linia obrony

Niezależnie od tego, jak bezpieczne jest Twoje API, musisz posiadać strategię kopii zapasowych. W bezpiecznej integracji backup powinien:

  • Odbywać się automatycznie (np. co 6-12 godzin).
  • Być przechowywany w innej lokalizacji fizycznej (zasada 3-2-1).
  • Być regularnie testowany pod kątem możliwości przywrócenia danych.

6. Checklist: Jak sprawdzić, czy Twoja integracja jest bezpieczna?

  1. Czy port 1433 jest zamknięty na firewallu dla ruchu z zewnątrz? (Sprawdź narzędziem typu nmap).
  2. Czy komunikacja między sklepem a API odbywa się przez HTTPS (SSL)?
  3. Czy każde zapytanie do API wymaga nagłówka Authorization?
  4. Czy logi API rejestrują każdą nieudaną próbę logowania?
  5. Czy baza SQL działa na dedykowanym użytkowniku z ograniczonymi uprawnieniami? (API nie powinno korzystać z konta sa!).

Podsumowanie: Bezpieczeństwo to proces, nie produkt

Budowa integracji Subiekta z chmurą to proces, w którym bezpieczeństwo powinno być fundamentem, a nie dodatkiem. Rezygnacja z wystawiania bazy SQL na publiczne IP i zastąpienie jej nowoczesnym Bridge API to najlepsza inwestycja w stabilność Twojej firmy. Chronisz nie tylko swoje dane, ale przede wszystkim zaufanie swoich klientów.

FAQ – Najczęściej zadawane pytania

Czy certyfikat SSL wystarczy, aby bezpiecznie połączyć Subiekta?

Nie. SSL szyfruje dane w locie (chroni przed podsłuchem), ale nie chroni samej bazy przed atakiem, jeśli port SQL jest otwarty. SSL to tylko jeden z elementów „pancerza” Twojej integracji.

Co jeśli mój integrator twierdzi, że musi mieć otwarty port SQL?

To sygnał alarmowy. Nowoczesne systemy integracyjne potrafią działać przez lekkie API wystawione na porcie 80/443 lub przez dedykowane agenty instalowane na serwerze. Jeśli dostawca wymusza otwarcie portu 1433, rozważ zmianę rozwiązania na bezpieczniejsze.

Jakie są koszty wdrożenia bezpiecznego API Bridge?

Koszt wdrożenia bezpiecznej warstwy API jest zazwyczaj porównywalny z tradycyjnymi metodami, ale oszczędności wynikające z uniknięcia potencjalnego ataku hakerskiego i kar RODO są niewspółmierne.