Bezpieczeństwo danych w SugarAI on-premise vs Cloud: szyfrowanie, kopie zapasowe, plan disaster recovery

W skrócie: W SugarCloud szyfrowanie, codzienne kopie zapasowe i redundancję infrastruktury zapewnia producent – na AWS, w wybranym regionie, z certyfikatem ISO/IEC 27001:2022 i atestem SOC 2 Type II. W modelu on-premise wszystkie te warstwy projektuje, utrzymuje i testuje organizacja. Żaden model nie jest „bezpieczny z definicji”: o poziomie ochrony decyduje to, czy każda odpowiedzialność ma właściciela, a plan disaster recovery jest regularnie sprawdzany w praktyce.

CRM to dla wielu firm najbardziej wrażliwy system w organizacji: kontakty, historia rozmów, oferty, umowy, zgłoszenia serwisowe. Jego niedostępność zatrzymuje sprzedaż i obsługę klienta, a wyciek oznacza ryzyko prawne i wizerunkowe. Od 3 kwietnia 2026 roku obowiązuje w Polsce znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa wdrażająca dyrektywę NIS2, więc pytanie „gdzie trzymać CRM i jak go chronić” stało się też pytaniem o zgodność z prawem.

Poniżej porównujemy oba modele wdrożenia SugarAI (dawniej SugarCRM) w trzech obszarach: szyfrowanie, kopie zapasowe i disaster recovery.

Kto za co odpowiada w SugarAI on-premise, a kto w SugarCloud?

W SugarCloud producent odpowiada za infrastrukturę, szyfrowanie platformy, kopie zapasowe i dostępność, a klient za konfigurację uprawnień, użytkowników i własne procedury. W on-premise organizacja odpowiada za całość: serwery, sieć, bazę danych, szyfrowanie, backup, aktualizacje i odtwarzanie po awarii. To podstawowa różnica, od której zależą koszty, kompetencje zespołu IT i profil ryzyka.

Ostatnie dwa wiersze są wspólne dla obu modeli. Nawet najlepiej zabezpieczona chmura nie ochroni danych przed zbyt szerokimi uprawnieniami nadanymi użytkownikom ani przed przejęciem konta bez MFA.

Jak SugarAI szyfruje dane w SugarCloud?

Według SugarAI dane w SugarCloud są szyfrowane zarówno w tranzycie, jak i w spoczynku, z użyciem standardowych algorytmów branżowych, a dostęp do API wymaga uwierzytelnienia i szyfrowanego połączenia. Szyfrowane są także kopie zapasowe. Platforma działa na AWS, a klient wybiera jeden z czterech regionów: Australię, Niemcy, Wielką Brytanię lub USA. Dane i kopie pozostają w wybranym regionie.

Dla polskich firm ważne są tu trzy elementy:

• Rezydencja danych. Wybór regionu w Niemczech pozwala utrzymać dane w Unii Europejskiej, co upraszcza analizę przekazywania danych osobowych na gruncie RODO.
• Kontrola dostępu po stronie producenta. SugarAI deklaruje, że MFA obowiązuje na wszystkich systemach i punktach dostępu, a każdy dostęp do danych jest logowany i monitorowany.
• Środowiska testowe bez danych produkcyjnych. Dane w środowiskach deweloperskich, testowych i QA SugarCloud są anonimizowane, co ogranicza ryzyko wycieku z mniej chronionych systemów.

Po stronie klienta zostaje konfiguracja logowania: SugarCloud obsługuje LDAP, SAML i OIDC, więc można podłączyć firmowego dostawcę tożsamości i wymusić MFA zgodnie z polityką organizacji.

Jak zaszyfrować dane w SugarAI on-premise?

W modelu on-premise szyfrowanie trzeba zaprojektować na każdej warstwie środowiska, bo aplikacja CRM korzysta z kilku komponentów: serwera WWW, bazy danych, silnika wyszukiwania, katalogu z załącznikami oraz kopii zapasowych. Niezaszyfrowany choć jeden z nich staje się najsłabszym ogniwem, nawet jeśli pozostałe są dobrze chronione.

Minimalny zestaw zabezpieczeń dla instalacji on-premise obejmuje:

1. TLS na serwerze WWW – aktualny certyfikat i wyłączone przestarzałe wersje protokołu.
2. Szyfrowane połączenie aplikacji z bazą danych – szczególnie gdy baza działa na osobnym serwerze.
3. Szyfrowanie danych w spoczynku – na poziomie dysków lub wolumenów (np. mechanizmy systemu operacyjnego albo usług chmury, w której działa maszyna) dla bazy danych, indeksu wyszukiwania i katalogu z plikami.
4. Szyfrowanie kopii zapasowych – osobnym kluczem, przechowywanym poza serwerem, którego dotyczy kopia.
5. Zarządzanie kluczami – kto ma do nich dostęp, jak są rotowane i co się dzieje, gdy administrator odchodzi z firmy.

Przewagą on-premise jest pełna kontrola: firma sama wybiera algorytmy, sposób przechowywania kluczy i lokalizację serwerów. Wadą – każdą z tych decyzji trzeba udokumentować i utrzymywać przez cały cykl życia systemu.

Jak działają kopie zapasowe w SugarCloud?

Każda aktywna instancja SugarCloud jest codziennie objęta kopią zapasową, a każda kopia jest przechowywana przez 30 dni. Niezależnie od tego klient może zamówić w supporcie SugarAI kopie jednorazowe lub cykliczne (np. codzienne) i pobierać je z panelu SugarCloud Insights albo przez REST API. To ważne, bo pozwala trzymać własną kopię danych poza platformą dostawcy.

Przy planowaniu warto pamiętać o trzech szczegółach, które często umykają w trakcie wdrożenia:

• Załączniki nie są domyślnie w kopiach udostępnianych klientowi. Jeśli w CRM trzymacie umowy, oferty czy skany dokumentów, trzeba poprosić support o ich uwzględnienie.
• Kopie udostępnione do pobrania wygasają po 30 dniach i po tym czasie nie da się ich odtworzyć. Pobieranie powinno być zautomatyzowane, a nie zależne od pamięci administratora.
• Po zakończeniu subskrypcji dane są dostępne przez maksymalnie 120 dni, a następnie trwale usuwane. To istotne przy planowaniu migracji lub wyjścia z usługi.

Jak zaplanować kopie zapasowe SugarAI on-premise?

W on-premise kopia zapasowa CRM musi obejmować co najmniej bazę danych, system plików aplikacji (w tym katalog z przesłanymi plikami) oraz konfigurację, a jej harmonogram powinien wynikać z tego, ile danych firma może stracić bez szkody dla biznesu. Sprawdzoną praktyką jest zasada 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, z czego jedna poza główną lokalizacją.

Na co zwrócić uwagę:

• Spójność bazy i plików. Kopia bazy i katalogu z załącznikami powinna pochodzić z tego samego momentu, inaczej rekordy w CRM będą wskazywać na nieistniejące pliki.
• Kopia odporna na ransomware. Przynajmniej jedna kopia powinna być niezmienialna lub odłączona od sieci produkcyjnej, aby atakujący z uprawnieniami administratora nie mógł jej zaszyfrować ani usunąć.
• Retencja dopasowana do przepisów i ryzyka. Krótka retencja ogranicza możliwość cofnięcia się do stanu sprzed niezauważonego przez tygodnie incydentu; zbyt długa może kolidować z zasadą minimalizacji danych z RODO.
• Test odtworzenia. Kopia, której nikt nie odtworzył, jest tylko założeniem. Odtwarzanie na środowisku testowym powinno być cykliczne i dokumentowane.

Jak zbudować plan disaster recovery dla CRM?

Plan disaster recovery (DR) dla CRM zaczyna się od dwóch parametrów: RPO (Recovery Point Objective), czyli ile danych firma może maksymalnie stracić, oraz RTO (Recovery Time Objective), czyli jak długo system może być niedostępny. Dopiero znając te wartości, można dobrać częstotliwość kopii, architekturę i procedury. W SugarCloud wartości te wynikają z umowy z dostawcą, w on-premise – z decyzji i budżetu organizacji.

Jak wygląda disaster recovery w SugarCloud?

SugarAI deklaruje, że front-end, usługi i bazy danych każdej instancji są stale replikowane między wieloma centrami danych w obrębie regionu, aby system pozostał dostępny nawet przy awarii jednego z nich. Aktualny i historyczny stan dostępności usług jest publikowany na stronie statusowej SugarAI. Konkretne parametry RPO i RTO nie są publikowane na stronach producenta – należy je potwierdzić w umowie lub SLA przed podpisaniem kontraktu.

Odpowiedzialność klienta w chmurze nie znika. Plan DR powinien przewidywać m.in. scenariusz przejęcia konta administratora, masowego usunięcia danych przez użytkownika lub integrację, która nadpisała rekordy. W tych przypadkach kluczowa jest własna, regularnie pobierana kopia danych.

Jak wygląda disaster recovery w SugarAI on-premise?

W on-premise plan DR trzeba zbudować od zera. Obejmuje on zwykle:

1. Analizę wpływu na biznes – które procesy zależą od CRM i ile kosztuje każda godzina przestoju.
2. Wyznaczenie RPO i RTO – osobno dla różnych scenariuszy (awaria serwera, utrata serwerowni, atak ransomware).
3. Architekturę odtworzeniową – zapasowe środowisko (gotowe do przełączenia lub odtwarzane z kopii), replikację bazy, dokumentację konfiguracji.
4. Runbook – krok po kroku: kto ogłasza awarię, kto odtwarza system, w jakiej kolejności uruchamiane są komponenty, jak sprawdza się integralność danych i jak informuje się użytkowników.
5. Testy – co najmniej raz w roku pełne ćwiczenie odtworzenia, z pomiarem rzeczywistego czasu i zakresu utraconych danych.

Przykład hipotetyczny: firma dystrybucyjna ustala RPO na 4 godziny i RTO na 8 godzin. Oznacza to, że kopie bazy muszą powstawać co najmniej co 4 godziny (albo baza musi być replikowana w trybie ciągłym), a zapasowe środowisko musi dać się uruchomić w ciągu jednego dnia roboczego. Jeśli test odtworzenia trwa 14 godzin, plan nie spełnia założeń – i lepiej dowiedzieć się o tym podczas ćwiczenia niż w trakcie prawdziwej awarii.

W modelu on-premise trzeba też śledzić cykl życia wersji. Wydania on-site SugarAI mają określone daty końca wsparcia – np. linia 25.1.x do 30 kwietnia 2027 r., a 26.1.x do 30 kwietnia 2028 r. System działający na niewspieranej wersji przestaje otrzymywać poprawki bezpieczeństwa, co samo w sobie jest ryzykiem do ujęcia w planie. Dodatkowo część wydań SugarAI jest dostępna wyłącznie w chmurze i nie jest wspierana poza środowiskiem SugarCloud.

Co NIS2 i RODO oznaczają dla wyboru modelu wdrożenia?

Ani NIS2, ani RODO nie nakazują wyboru chmury lub on-premise, ale oba akty wymagają od organizacji udokumentowanego zarządzania ryzykiem, szyfrowania tam, gdzie jest uzasadnione, oraz zdolności do szybkiego przywrócenia dostępności danych po incydencie. Model wdrożenia zmienia jedynie to, które zabezpieczenia firma realizuje sama, a które weryfikuje u dostawcy.

NIS2 / znowelizowana ustawa o KSC. Nowelizacja obowiązuje od 3 kwietnia 2026 r. Podmioty kluczowe i ważne miały czas do 3 października 2026 r. na złożenie wniosku o wpis do wykazu, a na dostosowanie systemów, procedur i struktur organizacyjnych mają czas do 3 kwietnia 2027 r. Pierwszy audyt podmiotów kluczowych ma się odbyć do 3 kwietnia 2028 r. Wśród wymagań są m.in. ciągłość działania, zarządzanie kopiami zapasowymi i odtwarzanie po awarii oraz bezpieczeństwo łańcucha dostaw – w tym ocena dostawców usług chmurowych.

RODO, art. 32. Przepis wskazuje jako przykładowe środki bezpieczeństwa m.in. szyfrowanie danych osobowych, zdolność do szybkiego przywrócenia ich dostępności po incydencie fizycznym lub technicznym oraz regularne testowanie skuteczności zabezpieczeń. W praktyce oznacza to, że plan DR i testy odtworzenia są dowodem zgodności, a nie tylko dobrą praktyką IT.

W chmurze ciężar dowodowy przesuwa się w stronę oceny dostawcy: certyfikat ISO/IEC 27001:2022, raport SOC 2 Type II, umowa powierzenia przetwarzania danych i lokalizacja regionu. W on-premise organizacja musi wykazać, że sama wdrożyła i utrzymuje równoważne środki.

Kiedy wybrać SugarAI on-premise, a kiedy SugarCloud?

SugarCloud jest zwykle lepszym wyborem dla organizacji, które chcą przenieść utrzymanie infrastruktury, aktualizacje i podstawowy DR na certyfikowanego dostawcę. On-premise sprawdza się tam, gdzie wymagania prawne, kontraktowe lub architektoniczne wymuszają pełną kontrolę nad lokalizacją danych i kluczami, a firma ma zespół zdolny utrzymać takie środowisko.

Rozważ SugarCloud, jeśli:

• nie masz zespołu, który przez lata będzie utrzymywał serwery, bazę danych i aktualizacje,
• zależy Ci na automatycznych aktualizacjach i dostępie do najnowszych funkcji,
• certyfikaty ISO/IEC 27001 i SOC 2 Type II dostawcy oraz region w UE spełniają wymagania Twoich audytorów.

Rozważ on-premise, jeśli:

• przepisy sektorowe, umowy z klientami lub polityka wewnętrzna wymagają przechowywania danych we własnej infrastrukturze,
• potrzebujesz pełnej kontroli nad kluczami szyfrującymi i parametrami RPO/RTO,
• masz kompetencje i budżet na utrzymanie, testy DR oraz regularne aktualizacje wersji.

Niezależnie od wyboru warto przed wdrożeniem odpowiedzieć na pięć pytań: jakie są nasze RPO i RTO, gdzie trzymamy własną kopię danych, kto ma dostęp do kluczy i kont administratora, kiedy ostatnio testowaliśmy odtworzenie oraz jak udokumentujemy to przed audytorem.

FAQ – bezpieczeństwo danych w SugarAI

Czy dane w SugarCloud są szyfrowane?

Tak. Według SugarAI dane w SugarCloud są szyfrowane zarówno w tranzycie, jak i w spoczynku, z użyciem standardowych algorytmów branżowych. Szyfrowane są także kopie zapasowe.

Gdzie fizycznie przechowywane są dane SugarCloud?

SugarCloud działa na AWS. Klient wybiera region (Australia, Niemcy, Wielka Brytania lub USA), a dane i kopie zapasowe pozostają w tym regionie. Dla firm z Polski naturalnym wyborem jest region w Niemczech.

Jak długo SugarCloud przechowuje kopie zapasowe?

Każda aktywna instancja SugarCloud ma codzienną kopię zapasową przechowywaną przez 30 dni. Kopie udostępnione do pobrania wygasają po 30 dniach i po tym czasie nie da się ich odtworzyć.

Czy kopie zapasowe SugarCloud obejmują załączniki?

Domyślnie nie. Pliki przesłane do systemu nie są włączane do kopii udostępnianych klientowi – trzeba o to poprosić w zgłoszeniu do supportu SugarAI.

Kto odpowiada za disaster recovery w SugarAI on-premise?

W modelu on-premise za szyfrowanie, kopie zapasowe, replikację i plan disaster recovery odpowiada w całości organizacja (lub jej partner wdrożeniowy). Producent dostarcza oprogramowanie i poprawki, ale nie infrastrukturę.

Czy wybór chmury zwalnia z obowiązków NIS2 i RODO?

Nie. Chmura przenosi część zabezpieczeń technicznych na dostawcę, ale organizacja nadal odpowiada za zarządzanie ryzykiem, kontrolę dostępu, ocenę dostawcy i własny plan ciągłości działania.

Wybór między SugarAI on-premise a SugarCloud rzadko rozstrzyga się na poziomie technologii – częściej na poziomie odpowiedzialności. Warto więc zadać sobie pytanie: gdyby jutro CRM przestał działać, czy w Twojej organizacji wiadomo, kto, w jakiej kolejności i w jakim czasie przywróci dane – i kiedy ktoś to ostatnio sprawdził?