Awaria dostawcy chmury pod NIS 2
Awaria waszego dostawcy to test waszego planu ciągłości, a nie zwolnienie z niego.
Czym jest ta strona
Duży dostawca chmury ulega awarii. Produkcja staje. Pytanie w pokoju brzmi, czy obowiązki NIS 2 spoczywają na dostawcy, czy na waszym podmiocie. Odpowiedź dyrektywy jest taka, że obie warstwy niosą własne obowiązki i jedna nie zwalnia drugiej. Wasze obowiązki zgodnie z artykułem 21(2)(c) NIS 2 utrzymania ciągłości działania, kopii zapasowych i odtwarzania oraz zgodnie z artykułem 23 zgłaszania istotnych incydentów stosują się do waszego podmiotu niezależnie od tego, co wasz dostawca robi na własnym zegarze.
Ta strona jest napisana dla kierownika IT lub dyrektora zarządzającego w firmie liczącej 50 do 250 osób, która prowadzi większość produkcji na hiperskalerze lub chmurze regionalnej. To nie jest porada prawna. To mechanika tego, która klauzula ma zastosowanie do kogo, gdy strona statusu dostawcy robi się czerwona.
Jedno najbardziej użyteczne zdanie: awaria chmury to żywy test waszego planu odtwarzania z artykułu 21(2)(c). Jeśli plan działa, w waszym podmiocie nie doszło do żadnego istotnego incydentu. Jeśli plan nie działa, artykuł 23 zaczyna biec na waszym zegarze, a nie dostawcy.
Dyrektywa (UE) 2022/2555 (NIS 2)
Artykuł 21(2)(c): polityki i procedury dotyczące ciągłości działania, takie jak zarządzanie kopiami zapasowymi i odtwarzanie po awarii, oraz zarządzanie kryzysowe. Artykuł 21(2)(d): bezpieczeństwo łańcucha dostaw, w tym aspekty związane z bezpieczeństwem dotyczące relacji między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami.
Artykuł 21(2)(c) nakłada obowiązek ciągłości, kopii zapasowych i odtwarzania na podmiot. Dyrektywa nie pozwala delegować tego obowiązku na dostawcę chmury poprzez umowę. Artykuł 21(2)(d) to noga ryzyka dostawcy: jesteście zobowiązani ocenić i zarządzać bezpieczeństwem waszych bezpośrednich dostawców, co obejmuje umowne klauzule powiadomień o awariach i incydentach u dostawcy. Artykuł 23 ustanawia następnie kaskadę zgłaszania z 24-godzinnym wczesnym ostrzeżeniem, 72-godzinnym zgłoszeniem incydentu, pośrednią aktualizacją na żądanie oraz raportem końcowym w ciągu jednego miesiąca.
Rozporządzenie wykonawcze Komisji (UE) 2024/2690
Artykuł 23(3) NIS 2: Incydent uznaje się za istotny, jeżeli spowodował lub może spowodować poważne zakłócenie operacyjne usług lub straty finansowe dla danego podmiotu, lub jeżeli wpłynął lub może wpłynąć na inne osoby fizyczne lub prawne, powodując znaczne szkody materialne lub niematerialne.
CIR kwantyfikuje, co liczy się jako istotne dla 11 kategorii infrastruktury cyfrowej i usług cyfrowych, które obejmuje, w tym dostawców usług przetwarzania w chmurze zgodnie z sektorem 8 załącznika I NIS 2. Sekcja 11 załącznika CIR wymienia scenariusze, które stanowią istotny incydent na warstwie dostawcy. Dla podmiotów poza zakresem CIR ma zastosowanie test istotności z artykułu 23(3), a kaskadowa awaria, która zatrzymuje produkcję, niemal zawsze go spełnia.
BSIG (Niemcy)
§30 BSIG: środki techniczne i organizacyjne odpowiednie do ryzyka. §32 BSIG: zgłaszanie istotnych incydentów do BSI poprzez Meldeportal pod adresem bsi.bund.de. §31 BSIG: obowiązki bezpieczeństwa łańcucha dostaw dla podmiotu.
BSIG to przykład niemieckiej transpozycji. Holandia (Cyberbeveiligingswet) i Austria (NISG 2024) mają własne. Kaskada 24 / 72 godziny / pośrednia / jeden miesiąc jest na poziomie dyrektywy i identyczna we wszystkich państwach członkowskich. Dostawca chmury, który sam jest podmiotem NIS 2 w UE, ma własny obowiązek zgłaszania zgodnie z §32 BSIG lub równoważny obowiązek krajowy. Ten obowiązek nie wygasza waszego.
Oceńcie względem swojego planu z artykułu 21(2)(c)
Otwórzcie plan ciągłości działania i odtwarzania po awarii i uruchomcie go. Pytanie nie brzmi, czy dostawca jest niedostępny. Pytanie brzmi, czy wasze usługi mogą nadal działać zgodnie z planem, który napisaliście. Przełączcie na region zapasowy, przejdźcie na udokumentowany przepływ pracy offline lub odtwórzcie z kopii zapasowej utrzymywanej poza dotkniętym dostawcą. Artykuł 21(2)(c) NIS 2 nakłada obowiązek ciągłości na wasz podmiot. Jeśli awaria ujawnia, że nie było planu, to jest pierwsze ustalenie, a nie awaria.
Uruchomcie swój proces dostawcy z artykułu 21(2)(d)
Artykuł 21(2)(d) NIS 2 wymaga od was zarządzania bezpieczeństwem waszych bezpośrednich dostawców. W praktyce oznacza to trzy rzeczy podczas awarii: otwórzcie umowę i przeczytajcie klauzule powiadomień i SLA, zarejestrujcie numer referencyjny incydentu dostawcy i każdy harmonogram, który publikuje, oraz ujmijcie dowody w swoim śladzie audytowym. Jeśli umowa nie wymaga od dostawcy powiadamiania o incydentach, które was dotyczą, to jest drugie ustalenie, odrębne od samej awarii.
Zgłoście, jeśli wasz podmiot ma istotny incydent
Test z artykułu 23(3) stosuje się do waszego podmiotu, a nie do dostawcy. Jeśli awaria powoduje poważne zakłócenie operacyjne waszych usług, straty finansowe dla was lub znaczne szkody dla innych, którzy są od was zależni, wówczas artykuł 23 NIS 2 zaczyna biec na waszym zegarze. Wczesne ostrzeżenie do krajowego CSIRT lub właściwego organu w ciągu 24 godzin od powzięcia wiedzy, zgłoszenie incydentu w ciągu 72 godzin, raport pośredni na żądanie, raport końcowy w ciągu jednego miesiąca. W Niemczech idzie to przez BSI Meldeportal zgodnie z §32 BSIG. Własny raport dostawcy zgodnie z jego własnym statusem NIS 2 jest odrębny i nie składa go za was.
Ciągłość to obowiązek podmiotu, a nie dostawcy
Artykuł 21(2)(c) NIS 2 nakłada obowiązek ciągłości, kopii zapasowych i odtwarzania na podmiot. Umowa z hiperskalerem obiecująca cel dostępności 99,99 procent nie jest planem ciągłości w sensie dyrektywy. Plan musi opisywać, co robi wasz podmiot, gdy dostawca jest niedostępny. Audytor w przyszłym roku testuje, czy taki plan istnieje i czy był przećwiczony, a nie czy SLA był dotrzymany.
Kopie zapasowe muszą być odtwarzalne, a nie tylko obecne
Stanowisko BSI jest takie, że istnienie kopii zapasowej nie jest testem. Odtwarzalność w warunkach faktycznego incydentu jest. Kopia zapasowa utrzymywana w tym samym regionie chmury co system produkcyjny, względem tego samego dostawcy tożsamości, nie jest kopią zapasową w sensie artykułu 21(2)(c), gdy to region lub warstwa tożsamości jest tym, co ulega awarii. Obowiązek odtwarzalnej kopii zapasowej wymaga oddzielenia w obrębie domeny awarii, którą próbujecie przetrwać.
BSI Meldeportal (Niemcy), krajowy CSIRT (inne państwa członkowskie)
Jeśli awaria powoduje istotny incydent w waszym podmiocie zgodnie z artykułem 23(3), raport idzie przez wasz kanał krajowy. W Niemczech jest to BSI Meldeportal zgodnie z §32 BSIG. W Holandii National Cyber Security Centre, w Austrii GovCERT. Raport jest wasz do złożenia, nawet jeśli przyczyna źródłowa tkwi u dostawcy. Strona statusu dostawcy nie jest zgłoszeniem.
Dostawca chmury jako podmiot NIS 2, sektor 8 załącznika I
Dostawca usług przetwarzania w chmurze z siedzibą w UE jest podmiotem kluczowym lub ważnym zgodnie z sektorem 8 załącznika I NIS 2 (infrastruktura cyfrowa). Jest winien własne zgłaszanie zgodnie z artykułem 23 na własnym zegarze do własnego właściwego organu lub CSIRT. CIR 2024/2690 określa progi istotności dla dostawców infrastruktury cyfrowej. Raport dostawcy nie jest waszym raportem. Dostawca spoza UE jest poza zakresem dyrektywy, w którym to przypadku zarządzanie ryzykiem dostawcy z artykułu 21(2)(d) jest waszym jedynym uchwytem na niego.
ENISA i sieć CSIRT
Transgraniczne awarie dużych dostawców chmury są koordynowane przez sieć CSIRT koordynowaną przez ENISA zgodnie z artykułem 15 NIS 2. ENISA publikuje świadomość sytuacyjną w państwach członkowskich. Dla pojedynczego podmiotu jest to materiał referencyjny, a nie kanał zgłaszania. Kanał zgłaszania jest krajowy. ENISA to miejsce, gdzie czytacie, co się dzieje na poziomie UE, gdy dostawca jest niedostępny w kilku krajach.
Chmura to problem dostawcy. NIS 2 spoczywa na nim.
Artykuł 21(2)(c) NIS 2 nakłada obowiązek ciągłości, kopii zapasowych i odtwarzania na wasz podmiot. Artykuł 21(2)(d) nakłada obowiązek ryzyka dostawcy na wasz podmiot. Dostawca ma własne obowiązki zgodnie z dyrektywą, jeśli jest dostawcą chmury z siedzibą w UE zgodnie z sektorem 8 załącznika I, ale te obowiązki biegną równolegle z waszymi i nie zwalniają z nich. Audyt w przyszłym roku testuje wasz plan, a nie SLA dostawcy.
Poczekajcie na poincydentowy raport SLA dostawcy przed złożeniem lub przeglądem.
Artykuł 23(4) NIS 2 wymaga wczesnego ostrzeżenia w ciągu 24 godzin od powzięcia wiedzy o istotnym incydencie w waszym podmiocie. Raport dostawcy może zająć tygodnie. Jeśli awaria spowodowała poważne zakłócenie operacyjne w waszym podmiocie, 24-godzinny zegar biegnie przeciwko wam niezależnie od tego, czy dostawca cokolwiek wydał. Czekanie na raport SLA to najczęstszy powód, dla którego podmioty przekraczają termin w przypadkach awarii chmury.
Dostawca wrócił, wszystko znów działa, incydent jest zamknięty.
Artykuł 21(2)(c) NIS 2 oczekuje, że plan ciągłości i odtwarzania będzie ćwiczony i ulepszany. Awaria chmury to żywe ćwiczenie tego planu, a przegląd poincydentowy to to, co zasila następną iterację. Audytor zapyta, co zmieniło się w planie odtwarzania po ostatniej awarii. Jeśli nic się nie zmieniło i ta sama luka nadal tam jest, to jest ustalenie. Powrót do normalnych operacji nie jest zamkniętym incydentem w sensie dyrektywy.
110-osobowa firma logistyczna w Nadrenii Północnej-Westfalii, klasyfikowana jako wichtige Einrichtung zgodnie z NIS 2, ponieważ sektor i liczba pracowników umieszczają ją w zakresie. Wtorek 09:14: region centralny UE hiperskalera ulega degradacji i system zarządzania transportem firmy, dostawca tożsamości oraz współdzielony magazyn plików stają się nieosiągalne. 09:20: kierownik IT otwiera plan ciągłości, przełącza dyspozycję na udokumentowany przepływ pracy offline na lokalnych laptopach i informuje dyrektora zarządzającego. 09:35: organ zarządzający poinformowany, decyzja zarejestrowana w śladzie audytowym, by traktować to jako zdarzenie ciągłości zgodnie z artykułem 21(2)(c) i monitorować względem testu istotności z artykułu 23(3). Strona statusu dostawcy jest zrzucona jako zrzut ekranu i dołączona do rekordu incydentu.
11:50: awaria trwa ponad dwie godziny i wpływa teraz na zobowiązania dostawcze wobec klientów. Test z artykułu 23(3) jest ponownie oceniany: poważne zakłócenie operacyjne usług jest spełnione. 24-godzinne wczesne ostrzeżenie jest składane przez BSI Meldeportal zgodnie z §32 BSIG, powołując numer referencyjny incydentu dostawcy oraz własny wpływ firmy. 14:30: dostawca odtwarza region. Firma przeprowadza przegląd poincydentowy następnego ranka. Ustalenie: zapasowy dostawca tożsamości był na papierze, ale nigdy nie przećwiczony, więc przełączenie zajęło 40 minut dłużej, niż zakładał plan. Dwie pisemne zmiany trafiają do planu: comiesięczne ćwiczenie zapasowego dostawcy tożsamości oraz aneks do umowy z dostawcą chmury wymagający powiadomienia o incydentach regionalnych w ciągu 30 minut. Raport pośredni i jednomiesięczny raport końcowy zgodnie z artykułem 23 są składane ze śladu audytowego, a nie z pamięci.
Platforma przechowuje cztery pisemne rzeczy, których potrzebujecie przed następną awarią dostawcy: plan ciągłości powiązany z artykułem 21(2)(c), konfigurację odtwarzalnej kopii zapasowej z dowodem jej oddzielenia od pierwotnej domeny awarii, rejestr dostawców z klauzulami powiadomień i SLA powiązany z artykułem 21(2)(d) oraz szablony zgłaszania i listę kontaktów dla kaskady z artykułu 23. Każda zmiana i każde ćwiczenie jest ujęte w śladzie audytowym ze znacznikami czasu, więc audytor w przyszłym roku widzi plan, który faktycznie uruchomiono, a nie dokument, który kiedyś napisano.
Platforma jest darmowa i open source. Nie ma płatnego poziomu ani lock-in. Celem tej strony nie jest sprzedaż czegokolwiek. Chodzi o to, by upewnić się, że gdy strona statusu dostawcy robi się czerwona, wasz organ zarządzający wie, czy zegar dyrektywy tyka na was i jaki jest następny pisemny krok.
- Dyrektywa (UE) 2022/2555 (NIS 2): artykuł 21(2)(c) (ciągłość działania, kopie zapasowe, odtwarzanie, zarządzanie kryzysowe), artykuł 21(2)(d) (bezpieczeństwo łańcucha dostaw), artykuł 23 (kaskada zgłaszania) oraz artykuł 23(3) (test istotności). Sektor 8 załącznika I (infrastruktura cyfrowa, w tym dostawcy usług przetwarzania w chmurze). EUR-Lex.
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690: wymagania techniczne i metodologiczne oraz progi istotności dla dostawców infrastruktury cyfrowej i usług cyfrowych, w tym dostawców chmury. Sekcja 11 załącznika. EUR-Lex.
- BSIG (Niemcy): §30 (środki zarządzania ryzykiem), §31 (bezpieczeństwo łańcucha dostaw), §32 (BSI Meldeportal). Gesetze im Internet.
- BSI: pakiety informacyjne NIS 2 w sprawie ciągłości, odtwarzalnych kopii zapasowych oraz stanowiska, że istnienie kopii zapasowej nie jest testem. bsi.bund.de.
- ENISA: koordynacja sieci CSIRT zgodnie z artykułem 15 NIS 2 dla incydentów transgranicznych. enisa.europa.eu.