Chmura dla systemu ERP enova365

Chmura dla systemu ERP enova365

Co znajdziesz w artykule:

• Definicje i podstawowe założenia chmury obliczeniowej
• Zalety migracji do chmury
• Potencjalne wady i zagrożenia chmury
• Przypadki nieuczciwego użycia terminu „chmura”
• Kluczowe czynniki bezpieczeństwa w chmurze
• Typowe błędy w ofertach „chmury” pod systemy ERP
• Architektura enova365 i sposoby pracy z programem enova365
• Infrastrukturę referencyjną dla enova365
• Dopasowanie infrastruktury referencyjnej do modeli

System enova365 jest jednym z kilu najbardziej popularnych systemów ERP w Polsce. Z każdym rokiem ta popularność rośnie a sam system zdobywa zadowolonych użytkowników. Rosnącą popularność enova365 zawdzięcza szerokiemu zakresowi funkcjonalnemu obejmującemu praktycznie każdy aspekt firmy, ale również nowoczesności technologicznej.

W poniższych rozważaniach skupimy się na aspekcie technologicznym i w tym kontekście zastanowić się nad optymalnym a jednocześnie bezpiecznym wariantem umieszczenia enova365 w chmurze.

Chmura wady i zalety

Zatrzymajmy się na chwile nad samą chmurą obliczeniową i wadami oraz zaletami jej użycia. Z definicji infrastruktura w chmurze polega na wykorzystaniu zasobów dostawcy do umieszczenia w nich i przetwarzania swoich systemów IT.

Po stronie dostawcy zostaje dbanie o dostępność i bezpieczeństwo infrastruktury umieszczonej zwykle w profesjonalnym centrum danych, Klient zaś w zależności od modelu skupia się na systemach operacyjnych, bazach danych lub aplikacjach.

Główna zaleta chmury wynika właśnie z tej relacji Dostawca - Klient. Przechodząc do chmury nie musimy już kupować serwerów, urządzeń sieciowych, macierzy i zatrudniać specjalistów od infrastruktury oraz inwestować z góry setek tysięcy PLN. Skupiamy się na naszych systemach branżowych płacąc tylko za tyle zasobów, ile w danym momencie potrzebujemy.

Jednocześnie, jeśli dobrze wybierzemy dostawcę chmury i jest ona oraz przygotowane w niej dla nas systemy, zbudowana zostaną zgodnie z najlepszymi dostępnymi na rynku praktykami, osiągniemy bezpieczeństwo znacznie wyższe niżeli mała czy średnia firma jest w stanie osiągnąć budując infrastrukturę samodzielnie.

Jak wszystko chmura ma też swoje czarne strony, które najczęściej wynikają z nieodpowiedniego wyboru dostawcy, braku projektu infrastruktury pod aplikacje, problemami z Internetem pod stronie Klienta czy zbyt dużą skalą projektu.

Na rynku mamy wielu dostawców usług chmurowych, lecz tylko niewielki odsetek z nich dostarcza profesjonalne, bezpieczne i wiarygodne usługi chmurowe.

Spotkać możemy podmioty oferujące chmurę pod dany system np. ERP, ale mające z realną chmurą obliczeniową tyle wspólnego co nazwa na ulotce. Rozważmy klika przypadków.

Częste manipulacje

Jeśli dostawca nazywa swoje usługi IaaS (Infrastructure as a Service) a nie udostępnia portalu do zarządzania, gdzie Klient samodzielnie tworzy maszyny wirtualne sieci i zabezpieczania to jest to zwykła manipulacja.

Jeśli chcemy wykorzystywać model IaaS, dostawca powinien dbać o jak najlepsze zbudowanie wydajnej i bezpiecznej infrastruktury serwerowej, sieciowej i przechowywania danych a konfigurację maszyn wirtualnych (systemów operacyjnych) pozostawić Klientowi.

Dla Klienta infrastruktura fizyczna jest ukryta pod pojęciem „chmura”, ale już wykorzystywane przez niego serwery Windows czy Linux powinny być w pełni niezależne od dostawcy.

Trudny do zrozumienia jest bowiem model, w którym dostawca niby oferuje IaaS, ale każdą nową maszynę wirtualną lub rekonfigurację istniejących nalezy zgłosić do dostawcy i pozostawić to w jego gestii. Tworzy to niepotrzebne krzyżowanie odpowiedzialności i zabiera elastyczności modelu IaaS, nie wspominając aspekcie bezpieczeństwa, gdzie de facto nie wiemy jak zbudowane jest nasze środowisko, ale bierzemy za niego odpowiedzialność.

Opisany wyżej sposób udostępniania usług, w którym to dostawca tworzy i konfiguruje systemy operacyjne, bazy danych etc.  i udostępnia je Klientowi do wykorzystania bardziej przypomina model PaaS (Platform as a Service), jednak i tu kryją się pułapki.

Jeśli bowiem nasz dostawca tworzy dla nas systemy, ale nie bierze odpowiedzialności za odpowiednie zaprojektowanie całości architektury aplikacji, bieżące utrzymanie systemów czy ich bezpieczeństwo w każdym aspekcie (z wyłączeniem samej aplikacji merytorycznej), zostajemy jako Klient w sytuacji, gdzie zrzekamy się prawa do samodzielnej kreacji infrastruktury przekazując ją dostawcy jednocześnie pozostając z całą odpowiedzialnością za jej działanie niezależnie od błędów dostawcy i organizacji jego pracy. Jeśli bowiem nasze systemy nie będą funkcjonować dostatecznie dobrze nie będziemy mieć narzędzi do weryfikacji problemu a pozostaniemy na łasce dostawcy, który nie biorąc pełnej odpowiedzialności za utrzymanie systemów może zasłaniać się powszechnie znanym zwrotem „u nas wszystko działa poprawnie”. Model taki jest swojego rodzaju hostingiem maszyn wirtualnych i nie wpisuje się w najlepsze praktyki budowy i dostarczania rozwiązań chmurowych.

Teoretycznie najprostszym jest model SaaS (Software as a Service) gdzie dostawca dostarcza gotową do użycia aplikację lub kompletny system pod jej wdrożenie np. enova365 lub gotowy przygotowany do działania i w pełni funkcjonalny system terminalowy pod enova365.Jednak tu też mogą pojawić się pewne problemy. Często jako Klient nie jesteśmy w stanie zweryfikować jak przygotowana jest infrastruktura, czy jest odpowiednio separowana od innych Klientów, czy jest odpowiedni zabezpieczona etc.

Aspekty bezpieczeństwa

W każdym z modeli kluczem jest przejrzystość, zaufanie do dostawcy i jego doświadczenie.

Nie bez znaczenia są też kompetencje dostawcy zakresie projektowania i bezpieczeństwa infrastruktury. Często można spotkać oferty typu „Bezpieczna chmura dla enova365”, etc.

Klient jest małą lub średnią firmą, bez wyspecjalizowanej kadry IT, zamawia taką chmurę w dobrej wierze i otrzymuje np. przygotowany dla niego serwer Windows opublikowany w Internecie z wykorzystaniem protokołu RDP, na którym instalowana jest zarówno baza danych jak i sam program.

Taka topologia nie spełnia żadnych podstawowych standardów bezpieczeństwa, sama publikacja serwera Windows w Internecie z wykorzystaniem protokołu RDP już jest bardzo dużą luką, nie wspominając już nawet o umieszczeniu na tym samym opublikowanym serwerze baz danych zawierających całość firmowego ERP.

Kompromitacja pojedynczego użytkownika daje atakującemu dostęp do całości danych w bazach danych. Ściągniecie przez użytkownika wirusa szyfrującego podczas pracy na terminalu, szyfruje cały serwer wraz z bazami.

Chwila zastanowienia i wady takiej topologii są oczywiste nawet dla laika, często jednak sama topologia nie jest jasno komunikowana a specjalizujący się w innych aspektach życia Klienci czy ich doradcy mogący być wybitnymi księgowymi, czy specjalistami od biznesu, nie są wstanie precyzyjnie ocenić czy proponowana oferta jest poprawna i przygotowana przez uczciwych specjalistów czy nastawionych na sprzedaż marketingowców.

Architektura enova365

Powróćmy do tematu, doboru chmury pod system enova365.  Wcześniejsza analiza powinna już zwrócić w dość stanowczy sposób na jakie aspekty należy patrzeć wybierając dostawce. Pokazała nam również jakie mamy modele samej chmury. Zastanówmy się więc jak odnieść dostępne modele do architektury niezbędnej dla systemu enova365.

enova365 jest w pewien sposób unikatowym systemem. Większość dostawców systemów ERP oferuje swoje programy w starym klasycznym modelu klient serwer. gdzie mamy zainstalowany na komputerze (terminalu) program, który łączy się bezpośrednio do bazy danych. enova idzie krok do przodu i dostarcza program zarówno w modelu klient serwer jak i w modelu pełnej aplikacji webowej, gdzie do korzystania z programu nie potrzeba instalacji klienta na stacji robaczej a jedynie uruchomienie systemu w przeglądarce internetowej.

Co więcej w przypadku enova zarówno wersja Desktop jak i multi jest praktycznie w 99% zgodna funkcjonalnie. Interfejs w przeglądarce nie dostarcza tylko wycinka funkcjonalności a całość rozbudowanego systemu ERP.

Sposoby pracy z programem

Architektura z klientem Desktop ma sporo istotnych wad. W klasycznej topologii wewnątrz firmy każda aktualizacja wymaga wykonania procesu aktualizacji na każdej stacji końcowej. Jeśli zaś chcemy udostępnić system zdalnie, konieczne jest wykorzystanie serwerów terminali tj. serwerów mający połączenie do bazy danych, na które logują się użytkownicy końcowi, aby uruchomić na nich program.

Praca na kliencie Desktop poprzez Internet nawet jeśli udostępnimy bazę danych po VPN jest bardzo nie efektywna ze względu na dużą wrażliwość systemów w tej architekturze na opóźnienia sieciowe, które nawet przy najlepszym Internecie nie będą mniejsze niż 8-10ms co jest wartością ponad 8 krotnie większą niż w sieci LAN.

Model oparty o interfejs Web pozbawiony jest ww. wad. Serwer interfejsu webowego umieszczony jest blisko (w tej samej sieci LAN) co baza danych przez co opóźnienia nie stanowią problemu. W Internecie czy po VPN publikujemy tylko aplikację Web. Użytkownik w swojej przeglądarce wymienia z aplikacją tylko dane tekstowe całość przetwarzania odbywa się w serwerze webowym.  Dodatkowo, interfejs webowy działa w ten sam efektywny sposób na każdym urządzeni czy to notebook-u czy też urządzeniu mobilnym jak telefon z IOS czy Android.

Nowoczesna technologia

Drugim ciekawym aspektem systemu enova jest wykorzystanie przez producenta nowoczesnych technologii programistycznych na światowym poziomie. Obecnie całość aplikacji zarówno w wersji webowej jak i Desktop napisana jest w technologii. netCore. Dla interfejsu webowego wynikają z tego faktu istotne implikacje. Technologia. netCore jest agnostyczna w zakresie systemu operacyjnego, co oznacza, że serwer logiki biznesowej i interfejs webowy, możemy uruchomić na 100% na serwerach opartych o Linux.

Wykorzystanie Linux nie tylko drastycznie podnosi bezpieczeństwo infrastruktury, ale niweluje również konieczność zakupu licencji Microsoft.

Producent dostarcza aplikację również w postaci obrazów docker co czyni enovę w wersji multi pełnoprawną aplikację „cloud native” gotową do wdrożenie np. z wykorzystaniem konteneryzacji K8S (kubernetes).

Jeśli połączmy enova365 na kontenerach z wspieranym przez Microsoft serwerem MS SQL w wersji na kontener Linux, otrzymamy pełną aplikację gotową pod dowolną chmurę bez konieczność jakichkolwiek licencji Microsoft (przy założeniu wykorzystania wersji Express).

Bezpieczeństwo dostępu

W przypadku pracy na serwerach terminali elementy bezpieczeństwa skupiają się na dwóch sprawach. Izolacji dostępu i separacji przepływów i bezpiecznym uwierzytelnieniu. W żadnym wypadku nie powinno być mowy o publikacji serwera terminali bezpośrednio w Internecie.Dostęp do terminali powinien być zamknięty za VPN, zrealizowanym w odpowiedniej dla Klienta wygodnej formie uwzględniającym wykorzystania uwierzytelniania wieloskładnikowego.

Interfejs web należy również albo zamknąć za VPN jak ww. lub też, jeśli publikowany w Internecie bezwzględnie powinien być chroniony za pomocą rozwiązania WAF (Web Application Firewall), aktywnie chroniącym przed atakami na aplikację webowe. Dodatkowo, dostęp z Internetu powinien uwzględniać wykorzystanie wielu składników uwierzytelnienia.

Infrastruktura referencyjna

Odpowiedni kształt infrastruktury, zależy oczywiście od wielu aspektów w takich jak specyficzne wymogi klienta, integracje zewnętrzne, czy wielkość środowiska w tym ilość użytkowników końcowych. Możemy jednak wyróżnić pewne elementy wspólne które bezwzględnie powinny znaleźć się w dobrze zaprojektowanej infrastrukturze pod system enova. Przyjmujemy, na początek założenie, że przygotowujemy infrastrukturę pod pełen dostęp zdalnym tj. również umieszczenie jej w chmurze obliczeniowej.

Zaczynając od wersji desktop. Nasi użytkownicy pracować będą na serwerze terminali. Jeśli jest ich mniej niż 25-30 jednocześnie z powodzeniem wystarczy pojedynczy terminal nazwijmy go TS1. Przygotowane zgodnie ze sztuką usługi terminalowe Microsoft bazują na serwerach wpiętych do Active Directory stąd nasz drugi serwer nazwijmy go AD. Sama enova365 potrzebuje serwera bazodanowego MSSQL, co daje nam kolejny serwer DB1.

Dodajmy do naszej infrastruktury interfejs webowy enova i Web API. Ponieważ mamy już bazę danych wystarczy kolejny serwer enovaWeb1.

W ten sposób zbudowaliśmy prostą infrastrukturę pod enova365 z oboma dostępnymi interfejsami Web I Desktop oraz APi do integracji. W tym momencie należy skupić się na zabezpieczeniu dostępu do samej aplikacji.

Serwery terminali możemy zabezpieczyć za pomocą np. dedykowanego przez Microsoft rozwiązania RD Gateway, lub alternatywnie z wykorzystaniem dowolnego NG-Firewall z funkcją VPN czy też VPN dostępnego w modelu Cloud np. dowolnego dostawcę usług SASE.

Serwer webowy należy zabezpieczyć albo za pomocą WAF albo VPN. Jeśli decydujemy się na WAF możemy jak w przypadku VPN albo zdecydować się na rozwiązanie dedykowane lub też skorzystać z usług chmurowych. Kompetentny dostawca, powinien rzetelnie poradzić w każdym z wymienionych aspektów.

Na koniec otrzymujemy infrastrukturę zbliżoną do poniższej. Należy pamiętać, iż jeśli nasze środowisko jest bardzo krytyczne i nie akceptuje nawet najkrótszych przerw (np. okno serwisowe na aktualizację) serwery należałoby podwoić zarówno w zakresie AD, DB jak i enova365 i Terminal a samą enova365 wystawić za pomocą load balancera.

Infrastruktura referencyjna a modele chmurowe

Jak odnieść wskazaną infrastrukturę niezbędną do prawidłowego przygotowania bezpiecznego systemu enova, do oferowanych przez dostawców modeli chmury.

IaaS

W modelu IaaS otrzymuje od dostawcy dostęp do puli zasobów CPU, RAM, przestrzeni dyskowej, sieci czy elementów bezpieczeństwa. Przez dedykowany portal tworzymy odpowiednie maszyny wirtualne zgodne z opisaną infrastruktura a parametrami adekwatne do wymagań.Następnie, budujemy odpowiednie sieci i przepływy sieciowe, wybieramy i przygotowujemy system bezpieczeństwa firewall, VPN, WAF etc.

W kolejnym etapie instalujemy i konfigurujemy systemy operacyjne Windows/Linux czyli system pod terminal, AD, enova i bazę danych. Następnie konfigurujemy same usługi tj. infrastrukturę terminali, AD, bazę i serwer aplikacyjno webowy.

Po wykonaniu ww. zadań możemy przejść do instalacji enova oraz konfiguracji samego programu a następnie udostepnienia go użytkownikom z wykorzystaniem wybranych zabezpieczeń.

Po zakończeniu wdrożenia, pozostają nam czynności administracyjne jak monitorowanie serwerów, dbanie o kopie zapasowe, zarządzanie bezpieczeństwem czy aktualizacjami. Dostawca chmur odpowiada za dostępność i jakość zasobów, na których chodzą nasze maszyny wirtualne pozostałe aspekty są po naszej stronie.

PaaS

W modelu PaaS, dostawca przygotuje dla nas dedykowane  usługi terminalowe, AD, bazę danych i serwer enova365. Odpowiada za konfigurację całości systemów operacyjnych, połączeń sieciowych i zabezpieczeń. Przygotowuje odpowiedni system bezpieczeństwa i zapewnia monitorowanie serwerów, dbanie o kopie zapasowe, zarządzanie bezpieczeństwem czy aktualizacjami.

My jako Klient na tak otrzymanej platformie wdrażamy system enova365 i udostępniamy ją użytkownikom.

Po zakończeniu wdrożenia, pozostają nam czynności administracyjne związane z programem, jak aktualizacja samej aplikacji czy zmiany wewnątrz programu.

SaaS

W przypadku enova365 w SaaS niewiele różni się od wersji PaaS, z tym, że infrastruktura terminali czy serwerów webowych jest dla nas całkowicie transparentna.

Dostawca dba o jej odpowiednie przygotowanie, przypisane wymaganych zasobów, bezpieczeństwo, kopie zapasowe etc.

My otrzymujemy dedykowane terminale i system enova oraz cały ekosystem zabezpieczeń. Dbamy tylko konfigurację samego programu, przekazanie dostępu użytkownikom jak zgłaszanie dostawcy z jakiej wersji enova chcemy w danym momencie korzystać.

Infrastruktura w usługach SaaS jest ścisłe kontrolowana przez dostawcę więc, nasza architektura programu musi się do niej dostosować, co przy bardziej złożonych wdrożeniach czy integracjach zewnętrznych może być ograniczeniem.

To również może Cię zainteresować: