Czy uKSC, NIS2 i DORA pozwalają na chmurę publiczną?
Wszystkie trzy regulacje opisują skutki, które organizacja ma osiągnąć, a nie architekturę, którą ma wdrożyć.
uKSC w art. 8 ust. 1 zobowiązuje podmioty kluczowe i ważne do wdrożenia systemu zarządzania bezpieczeństwem informacji: systematycznego szacowania ryzyka oraz środków technicznych i organizacyjnych odpowiednich i proporcjonalnych do oszacowanego ryzyka. W katalogu tych środków jest między innymi bezpieczeństwo i ciągłość łańcucha dostaw produktów, usług i procesów ICT (art. 8 ust. 1 pkt 2 lit. e). Ustawa dopowiada też, jak oceniać dostawcę: przez podatności z nim związane i ogólną jakość jego produktów i usług (art. 8 ust. 2). Chmura Atlassiana jest w tym ujęciu dostawcą usługi ICT, którego się ocenia, nadzoruje i dokumentuje, a nie opcją zakazaną.
NIS2 mówi to samo językiem dyrektywy. Art. 21 ust. 2 wylicza minimalny katalog środków zarządzania ryzykiem, w tym bezpieczeństwo łańcucha dostaw (lit. d) oraz ciągłość działania z zarządzaniem kopiami zapasowymi i przywracaniem normalnego działania (lit. c). Ust. 3 nakazuje uwzględniać ogólną jakość produktów i praktyk cyberbezpieczeństwa dostawców i usługodawców.
DORA dotyczy sektora finansowego i stawia poprzeczkę podobnie: cyfrowa odporność operacyjna instytucji oraz kontrola nad ryzykiem ze strony zewnętrznych dostawców usług ICT. Instytucja finansowa może korzystać z usług chmurowych. Musi jednak rozumieć związane z tym ryzyko, kontrolować je umownie i operacyjnie oraz umieć wykazać nadzór nad dostawcą.
W rozmowach o zgodności opłaca się rozdzielać trzy poziomy, bo często się zlewają: co przepis wymaga (skutek: zarządzone ryzyko, ciągłość, kontrola dostępu, nadzór nad dostawcą), co jest uznanym standardem realizacji tego skutku (na przykład SSO i uwierzytelnianie wieloskładnikowe dla kontroli dostępu), a co jest już rekomendacją wdrożeniową konkretnego doradcy. Żaden z trzech aktów nie wymienia Jiry, chmury ani konkretnego mechanizmu technicznego. Wybór narzędzi należy do organizacji – do wykazania pozostaje skutek.
Gdzie naprawdę leżą dane w Atlassian Cloud?
W dwóch różnych miejscach, i to rozróżnienie potrafi przesądzić o wyniku audytu. Dane produktów (Jira, Confluence, Jira Service Management) można przenieść do wybranego regionu, w tym Unii Europejskiej: to standardowa funkcja data residency, dostępna w konfiguracji organizacji. Dane aplikacji z Marketplace żyją osobno. Większość aplikacji przechowuje je na infrastrukturze swojego producenta, chyba że działa w całości w infrastrukturze Atlassiana (oznaczenie „Runs on Atlassian”, oparte na platformie Forge) albo sama pozwala przenieść dane do wybranego regionu.
W praktyce: instancja przypisana do UE z dziesięcioma aplikacjami to jedenaście odrębnych odpowiedzi na pytanie „gdzie leżą dane”. Można mieć Jirę we Frankfurcie i aplikację raportową przetwarzającą dane poza Europejskim Obszarem Gospodarczym.
Dla podmiotu regulowanego wniosek jest jeden: lokalizację danych sprawdza się per aplikacja i spisuje w rejestrze. Źródłem jest deklaracja producenta w dokumentacji aplikacji, status „Runs on Atlassian” albo zadeklarowane wsparcie residency. Brak deklaracji też jest informacją: podstawą do rozmowy z producentem albo do zastąpienia aplikacji. Rejestr warto opatrzyć datą następnej weryfikacji, bo producenci zmieniają infrastrukturę i lokalizacja danych to informacja z terminem ważności. Ten sam mechanizm rozpisaliśmy szerzej w artykule o czterech rzeczach, które zaskakują przy migracji.
Od wymogu do dowodu: jakie artefakty chce zobaczyć audytor?
- lokalizacja danych → rejestr lokalizacji per produkt i per aplikacja, z datą weryfikacji i źródłem każdej pozycji,
- kontrola dostępu → raport uprawnień (kto, do czego, na jakiej podstawie) oraz logi dostępu,
- ciągłość działania → plan ciągłości i udokumentowany wynik testu odtworzenia danych,
- rozliczalność → ścieżka audytowa zmian: kto i kiedy zmienił konfigurację lub uprawnienia,
- nadzór nad dostawcą → dokumentacja bezpieczeństwa Atlassiana: certyfikaty i raporty zgodności dostępne do wglądu oraz odpowiedzi zespołu Atlassiana na pytania o bezpieczeństwo, które zbieramy i interpretujemy pod wymagania Waszej organizacji.
Uczciwe informujemy jednak, że powyższa lista to nasza praktyka projektowa, a nie katalog przepisany z ustawy. Przepisy definiują skutki i obszary, zaś forma dowodu pozostaje po stronie organizacji.
Jak domknąć kontrolę dostępu?
Punktem wyjścia są przepisy, które ten obszar nazywają wprost. uKSC wymienia wśród środków polityki kontroli dostępu (art. 8 ust. 1 pkt 2 lit. n), zarządzanie aktywami (lit. m) oraz bezpieczne środki komunikacji uwzględniające uwierzytelnianie wieloskładnikowe w stosownych przypadkach (lit. l). NIS2 analogicznie: polityka kontroli dostępu i zarządzanie aktywami (art. 21 ust. 2 lit. i) oraz stosowanie, w stosownych przypadkach, uwierzytelniania wieloskładnikowego (lit. j).
Żaden z tych przepisów nie mówi wprost „użyj SSO”. Uznanym standardem realizacji jest jednak logowanie przez firmowy katalog tożsamości, wymuszone uwierzytelnianie wieloskładnikowe i automatyczne odbieranie dostępu wraz z odejściem pracownika. Powód jest praktyczny: ręczne zarządzanie kontami w kilkusetosobowej organizacji nie przechodzi testu rozliczalności. Rzadko która organizacja umie wykazać, że były pracownik stracił dostęp w dniu odejścia.
Nasza rekomendacja na projekt migracji: przegląd kont i uprawnień przed migracją, nie po niej, podpięcie środowiska Cloud pod katalog firmowy, wymuszenie uwierzytelniania wieloskładnikowego, raport uprawnień na koniec etapu. Porządek w kontach ma też skutek uboczny, który pion finansowy doceni: subskrypcja chmurowa zależy od liczby użytkowników z dostępem.
Do tego dochodzi rytm. Przegląd uprawnień to nie jednorazowe ćwiczenie przy migracji, lecz powtarzalny proces z właścicielem i kalendarzem. Audytor zapyta nie tylko o to, czy przegląd się odbył, ale również kiedy odbędzie się następny. Jeśli zarządzanie tożsamością i dostępami to obszar, w którym potrzebujecie wsparcia, opisujemy go osobno TUTAJ.
Co z ciągłością działania i kopiami?
Przepisy wymagają planów i ich testowania, nie samych intencji. uKSC mówi o wdrażaniu, dokumentowaniu, testowaniu i utrzymywaniu planów ciągłości działania oraz planów odtworzenia działalności (art. 8 ust. 1 pkt 2 lit. f). NIS2 o ciągłości działania, takiej jak zarządzanie kopiami zapasowymi i przywracanie normalnego działania po sytuacji nadzwyczajnej (art. 21 ust. 2 lit. c).
W chmurze łatwo o skrót myślowy: „backup robi Atlassian”. Odpowiedzialność jest współdzielona: Atlassian odpowiada za dostępność i odporność platformy, natomiast własne kopie danych i plan ich odtworzenia pozostają po stronie klienta. W praktyce oznacza to własny harmonogram kopii danych z Cloud, miejsce ich przechowywania zgodne z polityką lokalizacji danych oraz procedurę odtworzenia, którą ktoś faktycznie przećwiczył. Przy okazji trzeba rozstrzygnąć dwie rzeczy, o które audyt pyta zaskakująco często: gdzie fizycznie leżą kopie (tak, żeby rejestr lokalizacji danych obejmował również je) i jak długo są przechowywane.
Sam plan ciągłości to papier. Dowodem jest wynik testu odtworzenia: z datą, zakresem i osobą odpowiedzialną. Test wykonuje się przed przełączeniem produkcji na chmurę, a potem powtarza w ustalonym rytmie, bo uKSC wprost wymaga testowania planów, nie ich posiadania. Backup i testowane odtwarzania warstwy DevOps oraz Atlassiana to temat, który rozwiązujemy osobnym narzędziem.
Jak wygląda taka migracja w praktyce?
Jak zwykła migracja z dodatkową warstwą dowodową, budowaną w trakcie, a nie po fakcie. Kolejność, którą stosujemy u klientów z sektorów regulowanych:
- Rejestr lokalizacji danych, zanim zapadnie decyzja o zakresie.
- Konfiguracja regionu i weryfikacja komponentów.
- Kontrola dostępu: katalog firmowy, SSO, MFA, przegląd uprawnień.
- Plan ciągłości z testem odtworzenia.
- Migracja próbna i testy odbiorcze z użytkownikami.
- Przełączenie poza godzinami pracy i wsparcie po starcie.
Po stronie klienta od początku uczestniczy osoba odpowiedzialna za bezpieczeństwo, jako współautor wymagań, a nie recenzent na końcu.
Jedno pytanie, które opłaca się zadać każdemu rozważanemu dostawcy migracji: co dostaniecie do ręki dla audytora? Jeśli odpowiedź sprowadza się do „przeniesione dane”, to dla podmiotu regulowanego za mało.
Funkcje bezpieczeństwa i analityki w poszczególnych planach porównujemy osobno. [link: artykuł #11]
Jeśli działacie pod uKSC, NIS2 albo DORA i rozważacie chmurę Atlassiana, umówcie bezpłatną konsultację. Przejdziemy przez Wasze środowisko i pokażemy ścieżkę od wymogu do dowodu dla Waszej instancji.
