Blog
OXARI ITSM wspiera realizację wybranych zadań związanych z KSC i NIS2, porządkując informacje o zasobach, użytkownikach i dostępach oraz przebieg obsługi incydentów. Połączenie ewidencji IT, CMDB i Service Desk pomaga ustalić, czego dotyczy zdarzenie, kto odpowiada za reakcję i jakie działania zostały wykonane.
Wyobraźmy sobie, że pracownicy tracą dostęp do ważnej aplikacji. Zespół IT rozpoczyna diagnozę, a równolegle pojawia się podejrzenie naruszenia bezpieczeństwa. Trzeba sprawdzić, gdzie działa system, jakie dane przetwarza i z jakimi usługami jest powiązany.
Jeżeli odpowiedzi znajdują się w kilku arkuszach, wiadomościach i w pamięci jednego administratora, pierwsze minuty upływają na zbieraniu informacji. To właśnie w takich sytuacjach widać znaczenie uporządkowanego zarządzania IT.
Co łączy KSC i NIS2 z zarządzaniem usługami IT
KSC to Krajowy System Cyberbezpieczeństwa. Zasady jego funkcjonowania i obowiązki objętych nim podmiotów określa ustawa o krajowym systemie cyberbezpieczeństwa. NIS2 jest unijną dyrektywą dotyczącą cyberbezpieczeństwa, wdrażaną do polskiego prawa przez nowelizację tej ustawy.
Jak wyjaśnia Ministerstwo Cyfryzacji w materiale o nowelizacji KSC, wymagania dotyczą odpowiednich środków technicznych, operacyjnych i organizacyjnych służących zarządzaniu ryzykiem. W organizacji oznacza to potrzebę określenia odpowiedzialności, ustalenia przebiegu działań i dostępu do wiarygodnych informacji.
ITSM, czyli zarządzanie usługami IT, pomaga zorganizować tę codzienną pracę. Łączy obsługę zgłoszeń, zarządzanie zasobami i zmianami oraz informacje o zależnościach między systemami. W kontekście KSC jego rolą jest wspieranie procesów i dokumentowania ich realizacji.
OXARI nie jest systemem ochrony przed cyberatakami. Jego wdrożenie samo w sobie nie oznacza zgodności z ustawą. Potrzebne są także właściwe zabezpieczenia, procedury, kompetencje zespołu i ocena wymagań dotyczących konkretnej organizacji.
Użytkownicy i dostępy w kontekście konkretnego systemu
Przy analizie zdarzenia ważne jest ustalenie, kto korzysta z systemu i jakie uprawnienia ma dany użytkownik. Sam wykaz kont może nie wystarczyć. Przydatne są również informacje o roli pracownika, przypisanym sprzęcie i wcześniejszych zgłoszeniach.
W nagraniu o KSC pokazujemy profil użytkownika w OXARI, który łączy takie dane w jednym miejscu. Administrator może sprawdzić powiązania użytkownika z zasobami, systemami i zbiorami danych, zamiast odtwarzać je z rozproszonych źródeł.
Pomaga to również przy przeglądzie dostępów. Przykładowo: po zmianie stanowiska pracownika warto sprawdzić, czy jego dotychczasowe uprawnienia nadal są potrzebne, kto zatwierdził zmianę i czy zadania zostały wykonane. OXARI może wspierać organizację takiego procesu oraz zachowanie jego historii.
Zakres widocznych informacji zależy od danych wprowadzonych lub pozyskanych do systemu i konfiguracji wdrożenia. Ewidencja uprawnień wymaga regularnego uzgadniania ze stanem faktycznym.
Ewidencja zasobów IT jako punkt wyjścia do analizy ryzyka
Żeby ocenić znaczenie awarii lub incydentu, trzeba wiedzieć, którego zasobu dotyczy problem. Numer urządzenia jest przydatny, ale podczas reakcji potrzebny bywa szerszy kontekst: lokalizacja, użytkownik, przeznaczenie i osoba odpowiedzialna.
OXARI Asset Management wspiera ewidencję sprzętu i oprogramowania oraz przypisywanie zasobów do użytkowników, działów i lokalizacji. Dzięki temu zespół ma punkt odniesienia przy sprawdzaniu infrastruktury i wyjaśnianiu rozbieżności.
Na potrzeby zarządzania ryzykiem warto ustalić, które zasoby wspierają najważniejsze usługi. Awaria dwóch podobnych serwerów może mieć zupełnie inne konsekwencje: jeden obsługuje środowisko testowe, drugi aplikację potrzebną do realizacji zamówień.
Praktycznym początkiem jest wybranie jednej istotnej usługi i sprawdzenie, czy organizacja potrafi wskazać jej zasoby oraz właścicieli. Taki przegląd ujawnia konkretne braki: nieprzypisaną odpowiedzialność, nieaktualny wpis albo system, którego nie uwzględniono w ewidencji.
CMDB pomaga ustalić wpływ incydentu na usługi
CMDB, czyli baza danych zarządzania konfiguracją, przechowuje informacje o elementach środowiska IT i relacjach między nimi. Uzupełnia ewidencję o odpowiedź na pytanie, od czego zależy działanie usługi.
W OXARI CMDB można odwzorować powiązania aplikacji, serwerów, usług i osób odpowiedzialnych. To ułatwia analizę wpływu incydentu oraz planowanej zmiany.
Wróćmy do przykładu niedostępnej aplikacji. Jeśli jej zależności są opisane, zespół może sprawdzić, na jakiej maszynie działa, z jakiej bazy korzysta i czy te same komponenty obsługują inne usługi. Ma podstawę do ustalenia zakresu diagnozy i poinformowania właściwych osób.
Mapa powiązań wymaga aktualizacji po zmianach w środowisku. Nieaktualna relacja może skierować diagnozę w niewłaściwą stronę. Dlatego przy budowie bazy warto od razu ustalić odpowiedzialność za utrzymanie danych.
Więcej wskazówek znajdziesz w artykule: Jak zbudować CMDB, która pomaga w zarządzaniu incydentami i zmianami.
Zobacz wideo o KSC i NIS2 w praktyce OXARI
W krótkim nagraniu pokazujemy cztery powiązane obszary: informacje o użytkownikach i dostępach, zarządzanie zasobami, CMDB oraz obsługę incydentów. Zobacz, jak łączą się w codziennej pracy zespołu IT.
Obsługa incydentów od rejestracji do potwierdzenia wykonania działań
Kiedy wiadomo już, czego dotyczy zdarzenie, trzeba skoordynować pracę. Zgłoszenie powinno mieć właściciela, określony priorytet i widoczny status. Kolejne osoby potrzebują dostępu do dotychczasowych ustaleń.
OXARI Service Desk pomaga porządkować zgłoszenia, przypisywać zadania i zachowywać historię obsługi. Skonfigurowany proces może prowadzić zespół przez rejestrację, analizę, przekazanie do właściwych osób oraz dokumentowanie wyniku.
W procesie obsługi incydentu warto uwzględnić:
- czas zgłoszenia i opis objawów;
- usługę, zasoby oraz użytkowników, których dotyczy zdarzenie;
- ustalenia dotyczące wpływu i priorytetu;
- osoby odpowiedzialne za poszczególne działania;
- wykonane czynności i wyniki weryfikacji;
- decyzję o zamknięciu sprawy lub dalszej analizie.
Trzeba przy tym odróżnić incydent zakłócający usługę IT od zdarzenia wymagającego obsługi jako incydent cyberbezpieczeństwa. Nie każda niedostępność aplikacji oznacza naruszenie bezpieczeństwa. Ocenę przeprowadzają odpowiedzialne osoby zgodnie z przyjętą procedurą.
System ITSM może dostarczać informacje potrzebne do przygotowania zgłoszenia wymaganego przepisami. Sam zapis w Service Desk nie jest jednak zgłoszeniem do właściwego organu lub zespołu CSIRT. Również terminy wewnętrznego SLA należy odróżnić od terminów ustawowych.
Szerzej opisujemy tę pracę na stronie: Zarządzanie incydentami IT i ciągłość działania.
Audytowalność dzięki historii decyzji i wykonanych zadań
Podczas przeglądu lub audytu ważna jest możliwość odtworzenia przebiegu sprawy. Kto zaakceptował dostęp? Kiedy administrator wykonał zadanie? Na jakiej podstawie uznano, że usługę przywrócono?
OXARI pomaga łączyć zapisy obsługi z informacjami o zasobach, użytkownikach i odpowiedzialności. Przygotowanie materiałów do kontroli może dzięki temu rozpocząć się od wyszukania powiązanych spraw, decyzji i załączników.
Dobrym przykładem jest odebranie dostępu po zakończeniu współpracy. Warto zachować informację o uruchomieniu procesu, jego wykonawcy i potwierdzeniu realizacji. Status „zamknięte” ma ograniczoną wartość, jeśli nie wiadomo, co rzeczywiście sprawdzono.
Warunkiem użyteczności takiej historii jest ustalenie zasad dokumentowania: wymaganych informacji, sposobu potwierdzania wykonania i osób weryfikujących rezultat. Sam system nie rozstrzyga, czy dowody są wystarczające do oceny zgodności.
Zobacz, jak OXARI wspiera audytowalność i przygotowanie materiałów do oceny zgodności.
Jak sprawdzić gotowość procesów na przykładzie jednej usługi
Na początek wybierz usługę istotną dla działania organizacji, na przykład obsługę zamówień, system finansowy lub aplikację wykorzystywaną przez placówkę medyczną. Następnie sprawdź:
- Czy potrafisz wskazać zasoby, od których zależy ta usługa?
- Czy wiadomo, kto odpowiada za nią biznesowo i technicznie?
- Czy informacje o użytkownikach i dostępach są aktualne?
- Czy zespół wie, gdzie zarejestrować incydent i komu go przekazać?
- Czy po obsłudze zdarzenia można odtworzyć decyzje i wykonane czynności?
- Czy ktoś odpowiada za uzupełnienie braków wykrytych podczas przeglądu?
Taki przegląd nie jest pełną oceną zgodności z KSC. Pozwala jednak znaleźć problemy, które można przełożyć na konkretne zadania: uzupełnienie ewidencji, przypisanie właściciela albo dopracowanie procedury.
Jeżeli chcesz rozwinąć temat zależności usług i odtwarzania działania po awarii, zobacz webinar Od CMDB do Disaster Recovery. Nagranie jest dostępne w OXARI Account po rejestracji.
