System ERP i jego bezpieczeństwo: najczęstsze zagrożenia oraz plan ochrony

System ERP jest bezpieczny na poziomie wynikającym z jego konfiguracji, aktualizacji, uprawnień, hostingu i procedur użytkowników. Sama nazwa producenta ani lokalizacja systemu w chmurze nie potwierdza, że konkretne konto, kopia zapasowa czy integracja są dobrze zabezpieczone.

Odpowiedzialność zależy od modelu usługi i zapisów umowy. Dostawca może odpowiadać za utrzymanie infrastruktury, aktualizacje platformy i kopie po stronie usługi, a firma za konta użytkowników, nadawanie ról, urządzenia pracowników, dane wprowadzane do systemu oraz zgłaszanie incydentów. Zakres potwierdźcie w umowie, dokumentacji usługi i procedurach operacyjnych.

NIST Cybersecurity Framework 2.0 opisuje zarządzanie ryzykiem przez funkcje Govern, Identify, Protect, Detect, Respond i Recover, a kontrola dostępu powinna uwzględniać minimalne niezbędne uprawnienia. Sprawdziliśmy publikację NIST z lutego 2024 r.: NIST Cybersecurity Framework 2.0. W przypadku integracji sklepu z ERP i kanałami sprzedaży wdrożenie połączeń z BaseLinkerem warto objąć tym samym podziałem odpowiedzialności za dostęp, logi i obsługę awarii.

W ERP trzeba chronić dane klientów i pracowników, ceny, stany, zamówienia, dokumenty finansowe oraz dostępność procesów, które z nich korzystają. Skutek incydentu zależy od tego, czy dane zostały ujawnione, zmienione czy stały się niedostępne.

Tabela pomaga powiązać rodzaj informacji z możliwym skutkiem naruszenia. Ocena powinna uwzględniać konkretny proces i wymagania firmy, a nie zakładać, że wszystkie rekordy mają jednakową wagę.

Wybierzcie procesy, które muszą działać podczas awarii, oraz dane, których utrata lub ujawnienie wymaga natychmiastowej eskalacji. Zapiszcie właściciela procesu, dopuszczalny sposób pracy ręcznej i osobę zatwierdzającą powrót do pracy po incydencie.

Do częstych kategorii ryzyka ERP należą przejęte konta, nadmierne uprawnienia, nieaktualne komponenty, niesprawdzone kopie zapasowe, błędne integracje i niekontrolowany dostęp zdalny. Atak może zacząć się od wiadomości phishingowej, a następnie wykorzystać dostęp pracownika do systemu lub poczty.

MFA, czyli uwierzytelnianie wieloskładnikowe, wymaga potwierdzenia tożsamości więcej niż jednym czynnikiem. CISA zaleca MFA odporne na phishing dla usług, w szczególności poczty, VPN i kont z dostępem do systemów krytycznych; CISA wskazuje też na kopie offline oraz regularne testy ich dostępności i integralności. Sprawdziliśmy przewodnik CISA w październiku 2026 r.: CISA StopRansomware Guide.

Zalecamy przejrzeć ścieżkę dostępu od urządzenia pracownika przez VPN lub panel dostawcy do ERP. Dla każdego komponentu zapiszcie właściciela, aktualną wersję, metodę aktualizacji i sposób wycofania zmiany, jeśli aktualizacja zakłóci pracę.

Przed wdrożeniem poproście dostawcę o odpowiedzi dotyczące hostingu, szyfrowania, MFA, logów, aktualizacji, kopii, odtwarzania i obsługi incydentów. Odpowiedzi powinny wskazywać odpowiedzialną stronę i dowód działania, na przykład procedurę, opis usługi lub wynik ostatniego testu.

Do pytań dodajcie zakres testów bezpieczeństwa, obsługę podatności, kontrolę dostępu podwykonawców i warunki zakończenia umowy. Zapiszcie uzgodniony podział odpowiedzialności w umowie lub załączniku operacyjnym, a nie tylko w prezentacji handlowej.

Ryzyko nieuprawnionej zmiany ogranicza nadawanie użytkownikom tylko tych uprawnień, których potrzebują do swojej pracy. NIST definiuje zasadę najmniejszych uprawnień jako ograniczenie dostępu do minimum niezbędnego do wykonania przypisanych zadań. Sprawdziliśmy słownik NIST w październiku 2026 r.: NIST: least privilege.

Tabela przedstawia przykładowe role, które trzeba dostosować do używanego ERP i podziału obowiązków w firmie. Dostęp do zatwierdzania operacji oddzielcie od ich wprowadzania, gdy konsekwencje błędnej zmiany są istotne.

Zalecamy przegląd kont przy odejściu pracownika, zmianie zakresu obowiązków i zakończeniu współpracy z podwykonawcą. Konto integracji przypiszcie do procesu, a nie do prywatnego konta pracownika, i dokumentujcie właściciela klucza oraz procedurę jego unieważnienia.

Bezpieczna integracja ERP ze sklepem ogranicza zakres danych, używa osobnych poświadczeń i pozwala unieważnić dostęp bez blokowania pozostałych systemów. Klucz API to poświadczenie, które upoważnia program do wywoływania określonych operacji; nadajcie mu wyłącznie uprawnienia wymagane przez integrację.

Przed uruchomieniem uzgodnijcie, jakie dane przepływają w każdym kierunku, które systemy mogą je zmieniać i jak długo przechowujecie logi. Testujcie połączenie na środowisku odseparowanym od produkcji, a w logach zapisujcie identyfikator operacji i wynik bez ujawniania sekretów ani pełnych danych klienta. OWASP zaleca spójne logowanie zdarzeń aplikacyjnych i ochronę logów, a także wskazuje ryzyko ujawnienia sekretów. Sprawdziliśmy dokumentację w październiku 2026 r.: OWASP Logging Cheat Sheet.

Jeśli integracja obejmuje sklep i kanały sprzedaży obsługiwane przez Base, wdrożenie integracji BaseLinker z ERP i sklepem może pomóc zaplanować zakres połączeń i przekazywanie danych. Dostęp ograniczcie do konkretnych procesów, ustalcie procedurę rotacji klucza i przetestujcie unieważnienie poświadczeń bez utraty dostępu do ERP przez uprawnionych pracowników.

Sama kopia zapasowa nie potwierdza możliwości odtworzenia ERP, dopóki firma nie sprawdzi jej integralności i nie przećwiczy przywrócenia. Kopia powinna obejmować dane, konfigurację oraz elementy potrzebne do uruchomienia systemu, a co najmniej jedna jej wersja powinna być oddzielona od środowiska produkcyjnego.

Procedura testu odtwarzania powinna ustalać właściciela, zakres, kolejność przywracania i kryteria akceptacji. Po odtworzeniu porównajcie liczbę oraz spójność rekordów, sprawdźcie logowanie, integracje i kluczowe raporty, a następnie zapiszcie czas potrzebny na powrót do działania. Ustalcie także akceptowalną utratę danych i maksymalny czas niedostępności dla każdego procesu.

Zalecamy przeprowadzać test w środowisku odizolowanym od produkcji, aby nie nadpisać aktualnych danych. Jeśli dostawca wykonuje kopie, poproście o opis częstotliwości, retencji, lokalizacji, ochrony przed usunięciem oraz ostatniego testu przywracania.

Po podejrzeniu incydentu ograniczcie dalszy dostęp, zabezpieczcie logi i powiadomcie osoby odpowiedzialne za ERP, infrastrukturę oraz ochronę danych. Nie usuwajcie podejrzanych kont, plików ani śladów przed udokumentowaniem zdarzenia i uzgodnieniem działań z zespołem technicznym.

Kolejność reakcji powinna być znana przed incydentem:

1. Zgłosić zdarzenie właścicielowi systemu i osobie koordynującej reakcję.
2. Ograniczyć podejrzane konta, klucze API i dostępy zdalne zgodnie z procedurą.
3. Zabezpieczyć logi, czas zdarzeń, identyfikatory kont i zakres dotkniętych systemów.
4. Skontaktować się z dostawcą i ocenić wpływ na sklep, magazyn oraz klientów.
5. Odtworzyć działanie dopiero po usunięciu przyczyny i zatwierdzeniu przez właściciela procesu.
6. Udokumentować decyzje, skutki i zmiany zapobiegające powtórzeniu zdarzenia.

Właściciel danych powinien ocenić, czy incydent dotyczył danych osobowych i czy uruchamia obowiązki wynikające z właściwych przepisów. Zespół techniczny powinien odnotować, które integracje zatrzymał, jakie klucze unieważnił i kiedy bezpiecznie wznowił wymianę danych.

• Migracja danych do ERP: plan, etapy i kontrola poprawności
• Jak zaprojektować przenoszenie i aktualizację zamówień między ERP a sklepem
• Zmiana systemu ERP: symptomy, które wskazują, że firma wyrosła z obecnego systemu
• 7 najczęstszych błędów we wdrożeniach ERP i jak im zapobiec