Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



07.04.2021

Lubelskie Dni Informatyki

Koło Naukowe Informatyków już po raz XIII zorganizuje Lubelskie Dni Informatyki.
07.04.2021

Bariery językowe przełamane

Cisco Webex
06.04.2021

Nowość w portfolio Bakotech

Progress Software
06.04.2021

Kontrola służbowych urządzeń

Hexnode MDM
02.04.2021

Red Hat Inc.

Firma Red Hat Inc. udostępniła Red Hat OpenShift 4.7 – najnowszą wersji czołowej...
02.04.2021

Rozpoznawanie twarzy

QNAP QVR
02.04.2021

Układy EPYC Serii 7003

Firma AMD zaprezentowała nowe wydajne procesory serwerowe, czyli układy EPYC Serii 7003,...
02.04.2021

Mobilna wydajność

Satellite Pro C50-G
01.04.2021

Nowa linia monitorów

AOC V4

OLA w usługach informatycznych

Data publikacji: 04-03-2021 Autor: Tomasz Cygan

O ile SLA jest często spotykana w świecie IT, o tyle rozwiązania z zakresu OLA (ang. Operational Level Agreement) są traktowane trochę w kategoriach Yeti. Z tą jednak różnicą, że o ile o Yeti wszyscy przynajmniej słyszeli, o tyle o OLA słyszeli nieliczni. Co jednak istotne, rzadko kiedy OLA nabiera praktycznego wymiaru jako konkretne zapisy w umowach zawieranych wewnątrz organizacji. Taka jest bowiem konstrukcja OLA – ma ona regulować współpracę pomiędzy wewnętrznymi grupami w ramach organizacji.

 

Definicje ITIL opisują OLA jako „umowę pomiędzy dostawcą usług informatycznych a inną częścią tej samej organizacji. Wspiera dostawcę usług informatycznych w świadczeniu usług klientom i definiuje dobra i usługi, które mają być dostarczone, oraz obowiązki obu stron. Na przykład:

 

  • umowa OLA może być zawarta pomiędzy dostawcą usług informatycznych a departamentem zakupów, aby dokonywać zakupów sprzętu w uzgodnionym czasie;
  • pomiędzy serwisdeskiem a grupą wsparcia, aby rozwiązywać incydenty w uzgodnionym czasie”.


> Wykorzystanie OLA


OLA w języku polskim oznacza umowę o gwarantowanym poziomie wsparcia i jest traktowana jako umowa wspierająca umowy o gwarantowanym poziomie świadczenia usług (SLA). W zasadzie można uznać OLA jako swoistą formę umowy podwykonawczej, której specyfiką jest charakter wewnątrzorganizacyjny. Rolą wewnętrznych podwykonawców jest w takim przypadku zapewnienie odpowiedniego poziomu wsparcia dla usług świadczonych przez organizację na rzecz klienta. Jak wynika z podanej definicji, OLA może dotyczyć wewnętrznych uzgodnień dotyczących zakupów sprzętu, jak również obsługi incydentów zgłaszanych poprzez serwisdesk. Nie wyczerpuje to pełnego zakresu możliwości wykorzystania OLA. Konstrukcja może bowiem okazać się przydatna także dla wsparcia w zakresie aktualizacji, konfiguracji, konserwacji, zarządzania kopiami czy – szerzej – ciągłością działania, a także dla wsparcia w zakresie programistycznym lub dotyczącym cyberbezpieczeństwa.


Istota OLA polega na założeniu, że wszystkie usługi świadczone na rzecz klienta korzystają z odpowiedniego poziomu wsparcia. Może to prowadzić do przyjęcia, że tak jak w przypadku SLA konieczne jest stworzenie katalogu usług, tak w ramach relacji wewnętrznych katalog usług powinien zostać rozszerzony o sposób wsparcia konkretnych usług prawidłowo zdefiniowanych i wspieranych. Oznaczać to może oddzielne OLA dla każdej usługi, zwłaszcza w przypadku indywidualizacji sposobów wsparcia poprzez dostosowanie ich do spersonalizowanych usług informatycznych świadczonych na rzecz klienta. Z OLA działy wsparcia mają dowiedzieć się, jakie SLA zostały uzgodnione dla usług, za których utrzymanie odpowiadają. Tytułem przykładu wskazać można przełożenie godzin wsparcia dla klienta na ustalenia wewnątrzorganizacyjne czy też dostosowane do potrzeb rozwiązania dotyczące konserwacji i aktualizacji w ramach zapewniania ciągłości działania. Jeszcze wyraźniej zasadność personalizacji OLA jest widoczna w przypadku dostaw sprzętu na podstawie specyficznych wymagań klienta. Aczkolwiek należy pamiętać, że OLA stanowi dokument operacyjny o charakterze technicznym, a nie biznesowym.

 

> OLA w świetle prawa


Przepisy prawa nie posługują się bezpośrednio pojęciem OLA, brak jest w nich także odniesień do nich wprost. Skoro jednak OLA ma charakter wspierający, to pomocniczo można oprzeć się na rozwiązaniach wynikających z aktów prawnych. Mogą one dotyczyć wewnątrzorganizacyjnego ułożenia relacji gwarantujących odpowiedni poziom cyberbezpieczeństwa czy też ochrony danych osobowych. W przypadku cyberbezpieczeństwa pewnych wskazówek dla OLA dostarczają regulacje dotyczące obowiązków wewnętrznej struktury odpowiedzialnej za cyberbezpieczeństwo lub, podążając za propozycją nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa, wewnętrznego SOC. Punkt wyjścia stanowi zakres obowiązków przypisany wewnętrznej strukturze organizacyjnej odpowiedzialnej za cyberbezpieczeństwo. Zgodnie z treścią art. 14 ustawy o krajowym systemie cyberbezpieczeństwa wewnętrzną strukturę organizacyjną odpowiedzialną za cyberbezpieczeństwo powołuje się do realizacji zadań, o których mowa w art. 8–13.

 

Zgodnie z art. 8 ustawy w celu wdrożenia systemu zarządzania bezpieczeństwem w systemie informacyjnym wykorzystywanym do świadczenia usługi kluczowej, zapewniającego:

 

  1. prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu oraz zarządzanie tym ryzykiem;
  2. wdrożenie odpowiednich i proporcjonalnych do oszacowanego ryzyka środków technicznych i organizacyjnych, uwzględniających najnowszy stan wiedzy, w tym:
    • utrzymanie i bezpieczną eksploatację systemu informacyjnego,
    • bezpieczeństwo fizyczne i środowiskowe, uwzględniające kontrolę dostępu,
    • bezpieczeństwo i ciągłość dostaw usług, od których zależy świadczenie usługi kluczowej,
    • wdrażanie, dokumentowanie i utrzymywanie planów działania umożliwiających ciągłe i niezakłócone świadczenie usługi kluczowej oraz zapewniających poufność, integralność, dostępność i autentyczność informacji,
    • objęcie systemu informacyjnego wykorzystywanego do świadczenia usługi kluczowej systemem monitorowania w trybie ciągłym;
  3. zbieranie informacji o zagrożeniach cyberbezpieczeństwa i podatnościach na incydenty systemu informacyjnego wykorzystywanego do świadczenia usługi kluczowej;
  4. zarządzanie incydentami;
  5. stosowanie środków zapobiegających i ograniczających wpływ incydentów na bezpieczeństwo systemu informacyjnego wykorzystywanego do świadczenia usługi kluczowej, w tym:
    • stosowanie mechanizmów zapewniających poufność, integralność, dostępność i autentyczność danych przetwarzanych w systemie informacyjnym,
    • dbałość o aktualizację oprogramowania,
    • ochronę przed nieuprawnioną modyfikacją w systemie informacyjnym,
    • niezwłoczne podejmowanie działań po dostrzeżeniu podatności lub zagrożeń cyberbezpieczeństwa;
  6. stosowanie środków łączności umożliwiających prawidłową i bezpieczną komunikację w ramach krajowego systemu cyberbezpieczeństwa.

 

Zgodnie z art. 9 ustawy w celu:

 

  1. wyznaczenia osoby odpowiedzialnej za utrzymywanie kontaktów z podmiotami krajowego systemu cyberbezpieczeństwa;
  2. zapewnienia użytkownikowi usługi kluczowej dostępu do wiedzy pozwalającej na zrozumienie zagrożeń cyberbezpieczeństwa i stosowanie skutecznych sposobów zabezpieczania się przed tymi zagrożeniami w zakresie związanym ze świadczoną usługą kluczową, w szczególności przez publikowanie informacji na ten temat na swojej stronie internetowej;
  3. przekazania organowi właściwemu do spraw cyberbezpieczeństwa danych, o których mowa w art. 7 ust. 2 pkt 8 i 9 ustawy, nie później niż w terminie 3 miesięcy od zmiany tych danych.

 

Zgodnie z art. 10 ust. 1–3 ustawy w celu opracowania, stosowania i aktualizowania dokumentacji dotyczącej cyberbezpieczeństwa systemu informacyjnego wykorzystywanego do świadczenia usługi kluczowej, a także sprawowania nadzoru nad dokumentacją dotyczącą cyberbezpieczeństwa systemu informacyjnego wykorzystywanego do świadczenia usługi kluczowej, zapewniającego:

 

  1. dostępność dokumentów wyłącznie dla osób upoważnionych zgodnie z realizowanymi przez nie zadaniami;
  2. ochronę dokumentów przed niewłaściwym użyciem lub utratą integralności;
  3. oznaczanie kolejnych wersji dokumentów umożliwiające określenie zmian dokonanych w tych dokumentach; oraz przechowywanie dokumentacji dotyczącej cyberbezpieczeństwa systemu informacyjnego wykorzystywanego do świadczenia usługi kluczowej przez co najmniej dwa lata od dnia jej wycofania z użytkowania lub zakończenia świadczenia usługi kluczowej, z uwzględnieniem przepisów ustawy z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (DzU z 2018 r., poz. 217, 357, 398 i 650).

 

Zgodnie z art. 11 ust. 1–3 ustawy w celu:

 

  1. zapewnienia obsługi incydentu;
  2. zapewnienia dostępu do informacji o rejestrowanych incydentach właściwemu CSIRT MON, CSIRT NASK lub CSIRT GOV w zakresie niezbędnym do realizacji jego zadań;
  3. klasyfikowania incydentu jako poważnego na podstawie progów uznawania incydentu za poważny określonych w rozporządzeniu Rady Ministrów z dnia 31 października 2018 r. w sprawie progów uznania incydentu za poważny (DzU z 2018 r. poz. 2180).


Zgodnie z art. 12 ustawy w celu dokonywania zgłoszeń incydentu poważnego niezwłocznie, nie później niż w ciągu 24 godzin od momentu jego wykrycia, do właściwego CSIRT MON, CSIRT NASK lub CSIRT GOV.
Zgodnie z art. 13 ustawy w celu przekazywania do właściwego CSIRT MON, CSIRT NASK lub CSIRT GOV informacji:

 

  1. o innych incydentach;
  2. o zagrożeniach cyberbezpieczeństwa;
  3. dotyczących szacowania ryzyka;
  4. o podatnościach;
  5. o wykorzystywanych technologiach.


Dodatkowo wesprzeć się można o pewne rozwiązania zawarte w rozporządzeniu Ministra Cyfryzacji z dnia 4 grudnia 2019 r. w sprawie warunków organizacyjnych i technicznych dla podmiotów świadczących usługi z zakresu cyberbezpieczeństwa oraz wewnętrznych struktur organizacyjnych operatorów usług kluczowych odpowiedzialnych za cyberbezpieczeństwo. Co prawda opisuje ono pewne obowiązki operatorów usług kluczowych, niemniej można z niego skorzystać dla cyberbezpiecznego ułożenia relacji wewnątrz organizacji. Skoro bowiem usługa informatyczna ma być świadczona na gwarantowanym poziomie, to także wsparcie w jej realizacji powinno zapewniać odpowiedni poziom, a jednym z parametrów w tym zakresie powinno być bezpieczeństwo. Przy takim założeniu przydatne mogą okazać się elementy wskazanego rozporządzenia Ministra Cyfryzacji, dotyczące warunków technicznych świadczenia usług oraz stosowanych zabezpieczeń pomieszczeń oraz zabezpieczeń mających na celu skuteczne zarządzanie incydentami.

 

[...]

 

Adwokat, inspektor ochrony danych, wykładowca, publicysta, audytor wewnętrzny normy PN-ISO/IEC 27001:2014-12. Ukończył kurs „Data Protection and Privacy Rights” organizowany przez Radę Europy Help Programme, kurs „Cybersecurity for Critical Urban Infrastructure” prowadzony przez Massachusetts Institute of Technology oraz kurs „Cybersecurity Risk Management” prowadzony przez Rochester Institute of Technology.

 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"