Dynamics 365 i integracja z NBP

Wdrożenia ERP i WMS coraz częściej nie kończą się na jednym systemie. Dochodzą integracje z e-commerce, przewoźnikami, platformami BI, mobilną pracą magazynu i zdalnym dostępem dla zespołów, partnerów oraz serwisu. W wyżej wspomnianych układach temat IT Security w chmurze wraca regularnie, bo rośnie liczba połączeń, punktów dostępu i danych, które krążą między środowiskami, a jeden błąd w konfiguracji potrafi przełożyć się na realne ryzyko operacyjne. Najczęstszy błąd mentalny jest zaskakująco prosty: „dostawca chmury odpowiada za wszystko”. W rzeczywistości to przekonanie usypia czujność w najbardziej wrażliwych obszarach: uprawnieniach, rolach, integracjach i zasadach dostępu. W chmurze dostawca odpowiada za bezpieczeństwo infrastruktury, a firma za bezpieczeństwo tego, co konfiguruje, uruchamia i komu daje dostęp. Czym jest IT Security w chmurze? IT Security, czyli bezpieczeństwo w chmurze, to kompleksowy zestaw zasad i praktyk, których celem jest ochrona biznesu, systemów i danych również wtedy, gdy działają na usługach chmurowych. W praktyce chodzi o to, aby tylko uprawnione osoby miały właściwy dostęp, dane były zabezpieczone na każdym etapie, a konfiguracja środowiska nie zostawiała otwartej furtki dla atakujących. Najczęstsze obszary zagrożeń w chmurze można sprowadzić do trzech kategorii: Tożsamość i dostęp: przejęcia kont, spowodowane głównie przez brak MFA (uwierzytelniania wieloskładnikowego) i brak odpowiedniej kontroli. Dane: nieautoryzowany dostęp, wycieki danych przez niewystarczająco zabezpieczone integracje. Konfiguracja: błędne ustawienia usług, publicznie dostępne zasoby, otwarte porty, brak polityk i monitoringu zmian. Shared responsibility, czyli kto za co odpowiada w chmurze? Odpowiedzialność za bezpieczeństwo w chmurze jest zawsze dzielona między dostawcę usług cloud a organizację, która z nich korzysta. Żeby to dobrze zrozumieć, warto spojrzeć na zakres odpowiedzialności w zależności od modelu chmurowego.   SaaS (Oprogramowanie jako usługa) – polega na dostarczeniu gotowej aplikacji, co świadczy o odpowiedzialności dostawcy za bezpieczeństwo i prawidłowość działania samej usługi, jak i warstwy infrastruktury, na której działa. Po stronie firmy pozostaje przede wszystkim właściwe zarządzanie dostępem, rolami użytkowników i konfiguracją ustawień bezpieczeństwa w ramach oprogramowania. PaaS (Platforma jako usługa) – dostawca odpowiada nie tylko za infrastrukturę chmurową, lecz także system operacyjny oraz całe środowisko uruchomieniowe aplikacji. Organizacja odpowiada za bezpieczeństwo oprogramowania, konfigurację usług, ochronę danych oraz nadawanie uprawnień użytkownikom.   IaaS (Infrastruktura jako usługa) – dostawca zapewnia podstawową infrastrukturę oraz warstwę wizualizacji pozwalającą na uruchamianie maszyn wirtualnych. Ten model gwarantuje firmie największą elastyczność – i jednocześnie odpowiedzialność – w zakresie oprogramowania, systemu operacyjnego, zabezpieczeń, polityki i sposobu działania środowiska. Niezależnie od tego, czy firma korzysta z SaaS, PaaS czy IaaS, jedna zasada pozostaje niezmienna: po stronie organizacji zawsze leży odpowiedzialność za tożsamość i dostęp (kto ma uprawnienia) oraz za bezpieczeństwo danych w zakresie ich udostępniania, eksportu i właściwej konfiguracji. 7 filarów bezpieczeństwa chmury w firmie wdrożeniowej Poniższe filary warto traktować jak checklistę wdrożeniową. W projektach ERP, WMS i integracjach to właśnie one decydują, czy bezpieczeństwo jest „wbudowane” w architekturę chmurową, czy zostaje dopięte dopiero po incydencie. Identity and Access Management (IAM) – zasady zarządzania tożsamością użytkowników i dostępem do systemów, usług oraz danych. W chmurze IAM jest pierwszą linią obrony, bo większość ataków zaczyna się od przejęcia konta lub błędnie nadanych uprawnień. Warto pamiętać o unikaniu kont współdzielonych w organizacji, jeśli jest to możliwe, a także wymuszeniu co najmniej dwuetapowej weryfikacji kont użytkowników. Uzupełnieniem MFA powinny być polityki dostępu warunkowego, które ograniczają logowanie z nieautoryzowanych lokalizacji i urządzeń. Zasada minimalnych uprawnień – użytkownik powinien mieć dokładnie taki dostęp, jaki jest potrzebny do jego stanowiska pracy, ani więcej, ani mniej. Należy budować role pod procesy, a nie pod osoby. Pomocne jest udzielanie dostępu czasowego do zadań administracyjnych. Ochrona danych i klasyfikacja – dane powinny być zabezpieczone na poziomie przechowywania, przetwarzania i udostępniania. Skuteczne będzie sklasyfikowanie danych na poszczególne kategorie (np. finansowe, operacyjne, personalne), aby ustalić ich zasady eksportu, retencji i dostępu. Bezpieczna integracja API (ERP, e-commerce, WMS, BI) – ochrona kanałów wymiany danych między systemami. Integracje to jeden z najczęstszych wektorów ryzyka, bo działają całodobowo i często używają kont technicznych. W związku z tym rekomendujemy uwierzytelnianie oparte o tokeny oraz monitoring występujących anomalii. Monitoring i logowanie zdarzeń – bez odpowiedniego monitoringu nie ma realnej kontroli potencjalnych nieprawidłowości, jest tylko deklaracja. Trzeba pamiętać o zbieraniu logów z kluczowych komponentów, a także ustawić alerty na zdarzenia krytyczne i określić procedurę eskalacji. Backup i odtwarzanie po incydencie – strategia kopii zapasowych, co pozwoli na odtworzenie działania po awarii lub innej sytuacji krytycznej. Backup bez testów wdrożeniowych bywa fałszywym poczuciem bezpieczeństwa, dlatego należy wykonywać regularne próby i zaplanować scenariusze awaryjne. Governance i zgodność (polityki, audyt, dokumentacja) – zestaw reguł i procesów, które utrzymują bezpieczeństwo po zakończeniu projektu. Dzięki temu standardy nie kończą się na go live. MS POS pracuje przy wdrożeniach w ekosystemach Microsoft Dynamics 365 oraz POS Cegid Retail Y2, co daje naturalne spojrzenie na bezpieczeństwo zarówno od strony działania firmy, jak i od strony tego, jak zaprojektować środowisko oraz integracje, aby ryzyko nie rosło wraz z rozwojem systemu. Bezpieczeństwo w praktyce projektów ERP i retail W projektach ERP oraz środowiskach retail bezpieczeństwo nie rozgrywa się w jednym miejscu. To nie jest temat „modułu” ani pojedynczej konfiguracji. Jeśli firma pracuje na rozwiązaniach takich jak Microsoft Dynamics 365, które obejmują wiele obszarów działalności, od finansów i sprzedaży po logistykę i obsługę klienta, to security dotyczy całego łańcucha procesów i wszystkich punktów styku z innymi systemami. Innymi słowy: wystarczy jeden słaby element, by ryzyko przeniosło się na resztę organizacji. Co istotne, tym słabym elementem nie musi być wyłącznie system czy integracja. Równie często jest nim człowiek: błędnie nadane uprawnienia, nieświadome kliknięcie w złośliwy link czy pominięcie procedury mogą uruchomić łańcuch konsekwencji w całej organizacji. Pierwszym obszarem, który wymaga dyscypliny, są konta administracyjne i role projektowe. W trakcie wdrożenia naturalnie pojawia się potrzeba szerokich uprawnień: konfiguracji, migracji danych, testów, integracji. Problem zaczyna się wtedy, gdy dostęp „na czas projektu” nie ma terminu wygaśnięcia, a role wdrożeniowe zaczynają funkcjonować jak stałe role operacyjne. Bez jasnej granicy między administracją, zespołem projektowym i użytkownikami biznesowymi łatwo o sytuację, w której audyt dostępu staje się formalnością, a nie realnym narzędziem kontroli. Integracje to drugi, bardzo typowy wektor ryzyka. W sprzedaży detalicznej praktycznie zawsze mamy cały ekosystem: e-commerce, POS, WMS, platformy lojalnościowe, systemy płatności, integracje z przewoźnikami i raportowanie. Każda integracja korzysta z kont technicznych, kluczy, tokenów, uprawnień i często działa non stop. Jeśli nie ma rotacji sekretów, ograniczeń uprawnień kont technicznych oraz monitoringu anomalii, integracja potrafi stać się „cichym kanałem”, który działa długo, zanim ktokolwiek zauważy problem. Co istotne, większość incydentów w takich środowiskach nie wynika z zaawansowanej „magii hakerskiej”, tylko z prostych zaniedbań w kontroli dostępu i w konfiguracji. Szczególnie ryzykownym obszarem są środowiska deweloperskie, testowe i produkcyjne. W projektach ERP presja czasu sprzyja skrótom: kopiowaniu danych z produkcji do testów, tworzeniu wspólnych kont, tymczasowych eksportów i plików, które krążą między zespołami. Ryzyko „przecieków” nie musi oznaczać celowego działania, często jest efektem braku zasad: kto może pracować na danych realnych, czy dane są anonimizowane, gdzie i jak długo są przechowywane. Jeśli do tego dołożymy wiele podmiotów w projekcie – dostawców, integratorów, partnerów – to temat przestaje być poboczny. MS POS wspiera transformację cyfrową poprzez wdrożenia aplikacji biznesowych ekosystemu Microsoft Dynamics 365 oraz rozwiązań retail, takich jak Cegid Retail Y2, opartych o architekturę chmurową. Kluczową rolę odgrywa geo-replikacja usług i danych, uzupełniona o kopie zapasowe, monitoring, testy i aktualizacje, co gwarantuje wysoką dostępność i ciągłość pracy nawet w razie awarii systemu. W obszarze bezpieczeństwa zapewniane są procedury ochrony danych oraz mechanizmy bezpieczeństwa oparte o role i uprawnienia użytkowników.