Model współodpowiedzialności za bezpieczeństwo danych. Za co odpowiada dostawca, a za co klient?
Czy przeniesienie zasobów do zewnętrznego data center zdejmuje z menedżerów ciężar ochrony informacji? Nie do końca, ponieważ bezpieczeństwa nie da się w pełni outsourcować. Warto poznać model współodpowiedzialności, aby dobrze podzielić role między organizację a partnera technologicznego.
Dlaczego bezpieczeństwa nie oddasz w całości zewnętrznej firmie?
Sama umowa na hosting chroni wyłącznie fizyczny sprzęt, ale nie zawsze tyczy się to wrażliwych zbiorów danych. Jednak menedżerowie często zakładają, że podpisana umowa zdejmuje z nich cały obowiązek dbania o zasoby. W ten sposób powstaje ryzyko biznesowe, operacyjne oraz prawne.
Kiedy hakerzy włamują się do systemu i kradną dane użytkowników, firma ponosi kary za naruszenie RODO, traci zaufanie klientów i musi płacić za naprawę szkód - a to wszystko dlatego, że umowa z dostawcą hostingu chroniła tylko budynek i serwer, a nie dane, które były na serwerze.
Dlatego branża stosuje model współodpowiedzialności (shared responsibility). Oddziela on procesy realizowane przez zewnętrzne data center od zadań samej organizacji. Dzięki temu w sytuacji kryzysowej każda ze stron zna swoje obowiązki.
Za co odpowiada dostawca infrastruktury?
Dostawca infrastruktury bierze na siebie poprawne funkcjonowanie fizycznego sprzętu i ciągłość działania całego ośrodka. To oznacza, że:
- pilnuje budynków serwerowni;
- kontroluje dostęp do pomieszczeń;
- utrzymuje przemysłowe systemy zasilania awaryjnego;
- dba o to, by środowiska chmurowe były w odpowiednim stanie technicznym;
- nadzoruje ruch w sieci szkieletowej;
- wymienia uszkodzone podzespoły;
- monitoruje stan środowiska.
Jeśli w serwerze padnie zasilacz, technik natychmiast wymienia uszkodzony element. W ten sposób sprzęt pracuje bez przerwy, a usterki wychodzą na jaw jeszcze zanim wyrządzą poważniejsze szkody.
Co zawsze pozostaje po stronie klienta?
Klient nadzoruje dane, ustala sposób konfiguracji narzędzi oraz wyznacza reguły, na jakich użytkownicy wchodzą do systemów. Zewnętrzny operator nie wie, kto powinien mieć wgląd w pliki finansowe, dlatego nie nadaje uprawnień użytkownikom. To po stronie organizacji leży zarządzanie tożsamością, zbieranie logów i decyzja, kiedy wykonać backup, aby zabezpieczyć się przed utratą danych.
Zbiera ona także logi z systemów takich jak ERP, aby móc analizować zdarzenia i wykrywać nieprawidłowości. W środowiskach chmurowych o architekturze multi-tenant oznacza to konieczność samodzielnego pilnowania konfiguracji i dostępu na poziomie aplikacji.
Zespół IT instaluje też aplikacje i odpowiada za ich aktualizacje. Jeśli źle skonfiguruje on bazę danych lub nie załata podatności, jest ryzyko, że pojawi się nieautoryzowany dostęp. Właśnie na tym poziomie najczęściej dochodzi do incydentów.
Gdzie najczęściej pojawiają się luki w ochronie?
Czasem nie wiadomo gdzie kończą się zadania operatora, a zaczynają obowiązki klienta. Szczególnie, gdy zarząd opłaca usługę i zakłada, że dostawca sam odeprze złośliwy ruch na stronie internetowej, podczas gdy inżynierowie data center widzą atak w warstwie logicznej i czekają na reakcję administratorów klienta.
Czytaj więcej: Ćwiczenia incydentowe w firmie - scenariusz 90 minut dla zarządu
Firma i dostawca muszą ustalić, kto odpowiada za dane, konfigurację i to, co robić po ataku. Jeśli tego nie zrobią, atakujący będą mogli szybko skopiować pliki z bazy danych. Trzeba więc ustalić:
- kto aktualizuje firewalla na poziomie aplikacji biznesowej;
- który zespół wgrywa poprawki do systemów operacyjnych;
- kto odpowiada za zgłoszenie wycieku danych;
- gdzie trafiają alerty bezpieczeństwa.
Gdy przypiszesz te zadania do konkretnych osób, łatwiej będzie zorganizować reakcję na incydent i ocenić, czy zespół ma odpowiednie kompetencje. Więcej na ten temat dowiedz się z naszego artykułu: Jaka jest różnica między SIEM i SOC?.
Przejrzysty podział ról chroni budżet firmy przed karami regulacyjnymi za wyciek danych. Zarząd musi wiedzieć, kto w organizacji odpowiada za dostęp, konfigurację i reakcję na incydent. Sprawdź, czy w Twojej organizacji naprawdę wiadomo, kto odpowiada za dane, konfigurację, dostęp i reakcję na incydent.
