Czy bezpieczeństwo musi być drogie?
Najbardziej podstawową kwestią związaną z zapewnieniem bezpieczeństwa systemów SAP jest przygotowanie odpowiedniej architektury (systemów i serwerów) dla środowiska SAP.
Planując architekturę dla SAP w pierwszej kolejności należy wziąć pod uwagę oczekiwany poziom dostępności systemu produkcyjnego. W dzisiejszych realiach, gdy poprawne i nieprzerwane działanie SAP jest warunkiem koniecznym działania firmy, kluczowa jest wysoka dostępność systemu. By to osiągnąć, stosuje się rozwiązania redundantne. Redundancja nie dotyczy jedynie serwera produktywnego, ale także pozostałych elementów, takich jak: macierz dyskowa, urządzenia sieciowe, podłączenie do internetu czy zapasowe centrum przetwarzania danych. Środowisko musi być oczywiście objęte systemem buckupowym wspierającym system i integrującym się z używaną bazą danych. Wszystkie elementy sprzętowe powinny być objęte kontraktem serwisowym gwarantującym szybką wymianę podzespołów w przypadku awarii.
A zatem zbudowanie bezpiecznej architektury zapewniającej wysoką dostępność SAP wymaga znacznych nakładów finansowych. Koszty są szczególnie dotkliwe w przypadku systemów SAP HANA, które mają one wysokie wymagania odnośnie do parametrów sprzętowych (ilość pamięci RAM, liczba rdzeni CPU, szybkość dysków SSD). To podnosi całkowite koszty utrzymania.
Czy koszty architektury dla SAP można jakoś zoptymalizować, przy zachowaniu wysokiej dostępności?
Przyjrzyjmy się możliwej optymalizacji kosztów systemu zapasowego. Jednym ze sposobów zapewnienia bezpiecznej architektury dla systemu buckupowego jest skorzystanie z usług chmury prywatnej (np. All for One Managed Cloud) lub chmury publicznej (np. Microsoft Azure, Amazon WebServices, Google Cloud).
Wykorzystanie możliwości usług chmurowych przedstawię na przykładzie architektury wysokiej dostępności dla bazy danych SAP HANA z wykorzystaniem systemu stand by. W naszym przykładzie produkcyjna baza danych jest umieszczona w podstawowym centrum przetwarzania danych, a zapasowa baza danych w drugim CPD. W standardowym podejścu on-premise serwer stand by musiał mieć dokładnie takie same parametry jak serwer podstawowy, by w przypadku awarii był w stanie przejąć cały ruch produkcyjny. Przy wysokich wymaganiach systemów SAP HANA (klasa procesorów, liczba rdzeni, RAM) utrzymywanie zapasowego serwera o wymaganych parametrach generowało dodatkowe wysokie koszty.
W modelu cloud dla infrastruktury zapasowej koszty można znacznie obniżyć. Jako serwer zapasowy można wykorzystać serwer HANA o minimalnych zasobach RAM i vCPU – znacznie zredukowanych w stosunku do serwera produktywnego. Serwer zapasowy ma jedynie umożliwić proces replikacji w czasie normalnej pracy.
Posłużmy się przykładem. Załóżmy, że produkcyjny system bazodanowy HANA posiada 512 GB RAM lub nawet 1 TB RAM. Przy tych parametrach wystarczający będzie system zapasowy zredukowany jedyne do ok. 90 GB RAM. Liczba procesorów z typowych dla HANA z 64 może zostać ograniczona do 8. To zasoby wystarczające do przeprowadzenia replikacji danych. Tym samym koszt zapewnienia bezpieczeństwa danych zostanie znacznie zredukowany.
W wypadku awarii, gdy konieczne będzie przełączenie przetwarzania danych na system stand by, parametry serwera zapasowego zostaną podniesione do niezbędnej ilości pamięci RAM i CPU, a następnie uruchomione i udostępnione do przetwarzania danych przez użytkowników. Proces zmiany parametrów sprzętowych jest zautomatyzowany za pomocą odpowiednich skryptów, tak by proces przełączenia był szybki i bezproblemowy.
W takim scenariuszu koszty utrzymania systemu stand by są znacznie zredukowane, a zgodnie z przyjętą zasadą klient płaci tylko za to, z czego rzeczywiście korzysta.
Ciągłość działania i monitoring
Nadrzędnym celem administratora IT jest niedopuszczenie do przestojów i awarii powierzonych mu systemów, a jeżeli już to nastąpi, dowiedzenie się o tym jak najszybciej. W tym celu duża część czasu i zasobów jest poświęcona na monitorowanie wszystkich warstwy odpowiedzialnych za dostępność systemu. Monitoring musi objąć warstwę techniczną (zasilanie, dostępność sieciowa data center), warstwę sieciową i dostępność serwerów fizycznych (monitoring wszelkich urządzeń znajdujących się pomiędzy użytkownikiem końcowym a serwerami fizycznymi: sieć, serwery, urządzenia storage’owe itp.), aż po monitoring systemu operacyjnego i bazy danych. Kolejnym poziomem jest monitoring warstwy aplikacyjnej (monitorowanie dostępności aplikacji, zadań w tle oraz kluczowych współczynników dla systemu). W dalszej kolejności należy zadbać o monitoring procesów biznesowych, czyli interfejsów między systemami, oraz przepływu danych (pomiar odpowiednich parametrów oraz tego, czy przepływ danych między systemami ma miejsce).
W stworzeniu i utrzymaniu tak szerokiego zakresu monitoringu pomocne są wielorakie narzędzia, np. do monitoringu warstwy technicznej usług All for One Managed Cloud wykorzystujemy rozwiązania Nagios Zabix, wspieramy się także Graylogiem jako agregatorem logów, umożliwiającym hurtowe przeglądanie dużej ilości logów. W zakresie monitoringu warstwy aplikacyjnej i procesów biznesowych wykorzystujemy SAP Solution Managera i Technical Monitoring i Business Process Monitoring.
Bezpieczeństwo SAP – aktualne wyzwania
Zapewnienie bezpieczeństwa systemu SAP nie jest jednorazowym zdarzeniem. Nawet zaimplementowanie kompletu zaleceń bezpieczeństwa podczas wdrożenia nie załatwia sprawy. Zalecenia zmieniają się i ewoluują podczas cyklu życia systemu. Tempo publikowanych przez firmę SAP poprawek bezpieczeństwa w ostatnim czasie znacznie wzrosło. Oprócz tego producent systemu ciągle zmienia także niektóre mechanizmy związane z bezpieczeństwem, np. niedawno zmieniono sposoby połączeń do sieci SAP (tzw. połączenia SAP Backbone). Nadążenie za tymi wyzwaniami wymaga przede wszystkim bieżącego monitorowania publikowanych zmian i komunikatów, co pochłania znaczną ilość czasu.
W sytuacji gdy na środowisko SAP składa się z dużej liczby serwerów (kilkadziesiąt, a nawet kilkaset), dużym wyzwaniem jest standaryzacja ich ustawień na poziomie systemu operacyjnego, baz danych czy SAP. Standaryzacja lub też hurtowa zmiana parametrów – w przypadku ręcznej pracy jest praktycznie niemożliwa, a z pewnością obarczona dużym ryzykiem błędów. Skuteczna standaryzacja środowiska wymaga wsparcia kolejnymi narzędziami – tym razem do automatyzacji, np. Ansible.
Poza ustawieniami związanymi z bezpieczeństwem kluczowe jest regularne aktualizowanie poziomu poprawek na każdej warstwie: systemu operacyjnego, bazy danych, kernela SAP i konfiguracji SAP. A także regularne aktualizowanie sprzętu, macierzy, sieci itp.
Regularne aktualizacje często prowadzą do zmiany wersji OS, DB. W tym miejscu warto zaznaczyć, że żeby utrzymać bezpieczne środowisko SAP, niezbędne jest także aktualizowanie wersji systemu, czyli przeprowadzenie projektu upgrade’u SAP (nie rzadziej niż co 3-6 lat), w którym wersja SAP zostanie podniesiona do najnowszej.
Zaniechanie aktualizacji wersji systemu powoduje, że poziom bezpieczeństwa znacząco się obniża. Po wygaśnięciu wsparcia dla systemu operacyjnego, bazy danych czy wersji SAP nie są publikowane nowe poprawki i z czasem poziom bezpieczeństwa zaczyna spadać.
Należy mieć także na uwadze zmieniające się wymagania biznesowe. Do systemu są dodawane nowe rozwiązania, zarówno standardowe produkty SAP, jak też związane z obsługą nowych procesów biznesowych (np. obsługa JPK), które również wymagają wysokiego poziomu bezpieczeństwa systemu.
Upgrade w chmurze
Uprgade’y SAP to projekty, na które firmy decydują się niechętnie, gdyż trwają zwykle dość długo, mocno angażują zasoby firmy i są kosztowne. Dodatkowo trwający projekt upgrade wprowadza duże zamieszanie w działającym systemie. Zgodnie z dobrymi praktykami wszelkie aktualizacje wersji SAP wymagają okresu zamrożenia prac rozwojowych, a przynajmniej ich ograniczenia do niezbędnego minimum. Przy trwającym od dwóch tygodni do nawet trzech miesięcy projekcie tak długi okres bez zmian w systemie dla wieli firm jest nie do zaakceptowania. Jednak upgrade’y są nieuniknione, jeśli chcemy być pewni, że system jest bezpieczny.
W rozwiązaniu tego problemu z pomocą przychodzą usługi chmurowe, które pozwalają na szybkie zbudowanie środowiska projektowego do prowadzenia upgrade’u. Takie równoległe środowisko umożliwia również wprowadzanie bieżących zmian w oryginalnym systemie. Powołanie takiego środowiska u dostawcy usług cloud znacznie obniża koszty upgrade’u, dodatkowo opłaty ponosi się tylko przez czas funkcjonowania środowiska projektowego.
Szare strefy środowiska SAP
Na środowisko systemu SAP składa się kilka warstw – od centrum przetwarzania danych, sieci, zasobów dyskowych, serwerów, poprzez wirtualizację, systemy operacyjne i bazy danych, aż po technologię SAP (Basis), aplikacje SAP i dane. SAP wymienia dane z innymi systemami poprzez interfejsy, a nad całym procesem powinien czuwać oficer bezpieczeństwa. Na styku każdej warstwy występują szare strefy zakresów odpowiedzialności. Mogą one powodować problemy komunikacyjne i wpływać na bezpieczeństwo, szczególnie, gdy kilka firm zajmuje się utrzymaniem i wsparciem systemu SAP (różni dostawcy hostingu, usług technicznych i usług aplikacyjnych). Niejednoznaczne zakresy odpowiedzialności i utrudniona komunikacja pomiędzy tymi podmiotami to czynniki ryzyka znacznie obniżające poziom bezpieczeństwa systemu.
Skutecznym sposobem eliminacji szarych stref jest wybór usług kompletnych, obejmujących wszystkie warstwy systemu. Im mniej podmiotów uczestniczy w komunikacji, tym jest ona łatwiejsza i skuteczniejsza. Decydując się na jak najmniejszą liczbę dostawców lub jednego, który przejmuje pełną odpowiedzialność za bezpieczeństwo systemu, unikamy problemów związanych z nieostrymi zakresami odpowiedzialności.
Usługi SAP Managed Services to rozwiązanie dla tych firm, których celem jest zapewnienie wysokiej dostępności i bezpieczeństwa systemów SAP, jednak bez angażowania zasobów w rozważania o technologiach i infrastrukturze. Zadaniem klienta jest zdefiniowanie wymagań biznesowych i parametrów SLA. Po stronie SNP (aktualnie All for One Poland) – jako dostawcy usług – leży dbałość o środowisko techniczne, monitoring i aktualizowanie wszystkich warstw systemu i wydajność aplikacji.