W skrócie
Studio RMA.net chroni dane reklamacji na kilku poziomach: połączenie szyfruje protokół SSL, a konta pracowników mogą korzystać z Active Directory. Według starszej dokumentacji dostęp do danych ograniczają role i prawa, a menu Historia zawiera Dziennik ze śladem zmian. W chmurze prywatnej Cloud RMA dane są izolowane na infrastrukturze SoftwareStudio, a poprawki bezpieczeństwa są częścią Software Maintenance. Mechanizmy programu działają jednak tylko razem z zasadami firmy, np. kontami imiennymi i odbieraniem dostępu po odejściu pracownika.
Warstwy ochrony danych w programie do reklamacji
Dane reklamacji obejmują dane osobowe klientów, więc ich ochrona dotyczy każdego etapu pracy w programie. Zabezpieczenia Studio RMA.net układamy w warstwy, od połączenia z przeglądarką po serwer z bazą danych. Dotyczą one też osób wewnątrz firmy, bo nie każdy pracownik potrzebuje wglądu w dane wszystkich klientów. Każda warstwa ma inne źródło w dokumentacji, co zaznaczamy w tabeli:
| Warstwa | Mechanizm | Źródło informacji |
|---|---|---|
| Połączenie | Szyfrowanie protokołem SSL, adres https | Strona produktu i zrzuty |
| Logowanie | Konta użytkowników i Active Directory | Strona produktu |
| Uprawnienia | Role i prawa dostępu | Starsza dokumentacja |
| Ślad zmian | Menu Historia z pozycją Dziennik | Zrzuty i starsza dokumentacja |
| Serwer | Chmura prywatna z izolacją danych albo serwer firmy | Strona produktu |
| Aktualizacje | Poprawki bezpieczeństwa w Software Maintenance | Cennik |
Tabela pokazuje, że część mechanizmów potwierdza strona produktu, a część tylko starsza dokumentacja. Mechanizmy ze starszych opisów sprawdzamy w demo przed wdrożeniem. Przy wdrożeniu przechodzimy przez wszystkie warstwy, bo luka w jednej z nich osłabia pozostałe. Ochronę danych od strony prawa opisujemy przy danych osobowych reklamującego i RODO.
Szyfrowane połączenie z programem
Strona produktu podaje, że komunikację z programem szyfruje protokół SSL. Wszystkie zrzuty programu, od starszego interfejsu po demo z 2026 roku, pokazują adres zaczynający się od https. Dane przesyłane między przeglądarką a serwerem są więc chronione także w sieci publicznej, np. w hotelu albo u klienta. Przy instalacji na serwerze firmy certyfikat SSL utrzymuje dział IT, a jego wygaśnięcie blokuje bezpieczne połączenie. Pracownik rozpozna szyfrowane połączenie po ikonie kłódki w pasku adresu przeglądarki.
W chmurze prywatnej Cloud RMA połączenie i certyfikat utrzymuje SoftwareStudio. Chmurę prywatną opisujemy przy reklamacjach w chmurze prywatnej Cloud RMA, a serwer firmy przy instalacji programu RMA na własnym serwerze. Szyfrowanie chroni dane w drodze, ale nie chroni przed osobą, która zna hasło pracownika.
Logowanie i konta pracowników
Według starszej dokumentacji konta pracowników zakłada administrator programu, a dane logowania weryfikuje serwer aplikacji. Program integruje się z Active Directory, więc pracownicy logują się danymi z sieci firmowej, a konta są zarządzane centralnie. Ekran logowania w najnowszej wersji ma przycisk Odzyskaj dostęp, a starszy ekran angielski pozycję RESET PASSWORD. Logowanie opisujemy przy logowaniu do programu i odzyskiwaniu dostępu.
Według tych samych opisów brak plików cookies przekierowuje użytkownika do ekranu logowania. Konto imienne dla każdej osoby jest warunkiem, żeby dziennik wskazywał autora zmian. Wspólne konto działu oszczędza licencje tylko pozornie, bo licencje dostępowe i tak liczy się według osób zalogowanych jednocześnie. Hasła ustala firma według własnej polityki, a przy Active Directory obowiązują zasady sieci firmowej.
Role i prawa dostępu
Według starszej dokumentacji większość uprawnień wynika z roli, a jedno konto należy do jednej grupy funkcyjnej. Dzięki temu administrator nie nadaje praw każdej osobie osobno. Uprawnienia dzielą się na dwa rodzaje:
- Uprawnienia z roli - pracownik dostaje zakres pracy swojej grupy, np. przyjęć albo serwisu.
- Uprawnienia wyjątkowe - np. funkcję Anuluj według starszych opisów daje kierownik przez uprawnienie Koordynator.
Według starszej dokumentacji menu dla ról ustawia się w szablonie XML, a rola Partner ma zapisy ograniczone według analityki kontrahenta i towaru. Przy nadawaniu ról stosujemy zasadę najmniejszych uprawnień, czyli tylko prawa potrzebne do pracy. Role opisujemy przy rolach użytkowników w programie do reklamacji.
Lista Zamknięte nie ma na pasku przycisku Edycja, więc zamknięta sprawa zachowuje zapis decyzji. Po zamknięciu dokumentacja i załączniki zostają w archiwum. Anulowanie sprawy według starszych opisów przenosi ją do rejestru anulowanych, a nie usuwa jej z bazy. Zasady anulowania zapisujemy w procedurze, żeby funkcję Anuluj miały tylko wskazane osoby.
Dziennik i ślad zmian w sprawie
Menu Historia przy dokumencie ma pozycję Dziennik obok pozycji z wysłanymi wiadomościami. Według starszej dokumentacji dziennik zapisuje autora i czas każdej zmiany w sprawie, np. przyjęcia albo zmiany statusu. W rejestrze wersji 1.173.0 jest też przycisk Rewizja zmian, którego działania źródła nie opisują, więc sprawdzamy je w demo. Dziennik opisujemy przy dzienniku zdarzeń w programie do reklamacji.
Ślad zmian ma wartość tylko przy kontach imiennych, bo przy wspólnym koncie nie wiadomo, kto zmienił dane. Przy sporze z klientem dziennik pokazuje datę decyzji i osobę, która ją zapisała. Kierownik przegląda dziennik przy sprawach spornych, a nie codziennie przy każdej sprawie. Dziennik nie zastępuje notatek, bo zapisuje zmianę danych, a nie jej powód.
Serwer i poprawki bezpieczeństwa
W chmurze prywatnej Cloud RMA dane firmy są izolowane od danych innych klientów na własnej infrastrukturze SoftwareStudio. Poprawki bezpieczeństwa są częścią Software Maintenance, wliczonego w chmurze prywatnej od pierwszego dnia umowy. Przy instalacji na serwerze firmy Software Maintenance jest usługą dodatkową, a system serwera i bazę aktualizuje dział IT. Dział IT chroni też pliki konfiguracyjne, bo według starszej dokumentacji plik web.config zawiera połączenie z bazą i dane konta pocztowego.
Przy chmurze prywatnej dane osobowe klientów przetwarza dostawca, więc firma zawiera z nim umowę powierzenia przetwarzania. Kopie zapasowe są częścią bezpieczeństwa danych, ale cennik nie opisuje ich zasad. Przy serwerze firmy odpowiedzialność za kopie ustalamy w wycenie, a w chmurze wymagania firmy wpisujemy do specyfikacji. Aktualna przeglądarka na stanowiskach pracowników też należy do bezpieczeństwa, bo przez nią przechodzą dane klientów. Na komputerach, z których korzysta kilka osób, wyłączamy zapamiętywanie haseł w przeglądarce.
Zasady bezpieczeństwa po stronie firmy
Zabezpieczenia programu działają tylko razem z zasadami, które firma zapisuje w procedurze. Najważniejsze dotyczą czterech obszarów:
- Konta imienne - każdy pracownik loguje się własnym kontem, bez kont wspólnych dla działu.
- Odbieranie dostępu - konto osoby, która odchodzi albo zmienia stanowisko, zamykamy w dniu zmiany.
- Pliki z eksportu - arkusze z danymi klientów przechowujemy tak samo starannie jak bazę.
- Urządzenia mobilne - telefon z otwartą sprawą wymaga blokady ekranu.
Dziennik wskazuje autora zmian tylko przy kontach imiennych, więc mechanizm programu zależy tu od zasady firmy.
Eksport opisujemy przy eksporcie tabeli reklamacji do pliku, a pracę na telefonie przy reklamacjach na telefonie i tablecie. Procedurę przeglądamy po każdej zmianie w zespole albo w konfiguracji programu. Pracownicy poznają te zasady na szkoleniu, razem z obsługą programu. Zasady bezpieczeństwa ustalamy w analizie przedwdrożeniowej, co opisujemy przy etapach wdrożenia systemu reklamacyjnego. Szyfrowanie i role chronią dane w programie, ale o bezpieczeństwie decyduje też to, co pracownicy robią z danymi poza nim.