Dość regularnie jestem pytany o to co trzeba zrobić aby zapewnić sobie zgodność z przepisami prawa i odpowiedni poziom bezpieczeństwa zgodnie z RODO. Dotyczy to różnych kwestii, od wydawania upoważnień (tak, ta wydawałoby się prosta kwestia może wzbudzać wątpliwości i to całkiem uzasadnione) poprzez umowy, dostępy do budynków, pomieszczeń, kończąc na nieco bardziej skomplikowanych kwestiach, takich jak np. korzystanie z chmury obliczeniowej. Właśnie ostatnio analizowałem tę kwestię w związku z przetwarzaniem danych w chmurze przez firmę z branży ubezpieczeniowej.
Dlatego dziś postanowiłem napisać „ambitny” artykuł o tym jak z chmury korzystają wielcy gracze, czyli firmy podlegające nadzorowi KNF. Organ ten wydał zresztą bardzo fajne wytyczne dotyczące chmury, z których mogą skorzystać także inne firmy, z którymi KNF nie ma wiele wspólnego. Ale od początku!
Prawo wymaga od banków, firm inwestycyjnych i ubezpieczycieli trochę więcej niż od zwykłych firm i nakłada na nie dodatkowe obowiązki, wynikające z całego szeregu aktów prawnych. Te „większe wymogi” dotyczą m.in. bezpieczeństwa i usług online, które powinny działać cały czas, być szybkie, sprawne i pewne. Dlatego właśnie istnieje instytucja powołana do tego aby nadzorować cały szereg różnych organizacji finansowych, ubezpieczeniowych itp. – czyli KNF.
Nie trzeba być natomiast bankiem, żeby mieć wysokie wymagania co do korzystania z chmury. Tzn. każdy, kto opiera na chmurze swój biznes wie, że od jej sprawności będzie zależał również jego sukces albo ew. porażka. Dlatego bezpieczeństwo chmury i jej niezawodność jest istotnym czynnikiem przy wyborze usługi – albo przynajmniej powinno być.
Trzeba tu wziąć też pod uwagę regulacje płynące z RODO, które wskazują na to, że w przypadku gdy korzystamy z usług podwykonawców (czyli tak zwanych podmiotów przetwarzających) w celu przetwarzania danych, to powinniśmy zadbać o to aby taki podwykonawca również był zgodny z RODO i spełniał odpowiednie standardy bezpieczeństwa. Oczywiście takie standardy muszą być adekwatne do ryzyka, potencjalnych zagrożeń, możliwości naruszania praw lub wolności osób, których dane dotyczą itp.
Nie ma jednak w RODO konkretnych wskazówek jak określić to, czy usługa chmurowa jest „adekwatna”. Tu z pomocą mogą właśnie przyjść wyjaśnienia KNF – są one przygotowane dla banków, firm inwestycyjnych, ubezpieczycieli itp. Siłą rzeczy więc, wymogi tam postawione są dość wysokie. Ale nie ma przeszkód abyś również ty przyjął lub przyjęła takie wysokie wymogi w swojej działalności.
To może mieć znaczenie jeśli w swojej pracy lub biznesie mocno polegasz na usługach chmurowych i nie możesz pozwolić sobie na żadną wpadkę – np. masz tam całą dokumentację dotyczącą klientów albo Twoja usługa/aplikacja na której zarabiasz działa właśnie w oparciu o taką chmurę. Analogiczna sytuacja dotyczy np. operatorów usług kluczowych lub dostawców usług cyfrowych zgodnie z ustawą o krajowym systemie cyberbezpieczeństwa. W tych przypadkach warto abyś również Ty zwrócił lub zwróciła uwagę na to co przygotował KNF – pomoże Ci to ocenić, czy usługa, którą zamierzasz wybrać albo już wybrałeś, jest odpowiednia pod kątem bezpieczeństwa.
Podejście KNF ma też o tyle dużą zaletę, że odbiega nieco od standardowych znanych z tysięcy poradników o RODO, jakże przydatnych uwag typu: wybierając dostawcę usługi chmurowej oceń ryzyko, sprawdź czy ISO, cykl Deminga, monitorowanie, audyt i tak w kółko. Nie unikniemy jednak ocen ryzyka, które w tej całej układance są bardzo ważne – ale dostaniemy kilka dodatkowych wskazówek.
Oczywistym jest bowiem, że duzi gracze jak banki czy ubezpieczyciele oceniają sobie ryzyko cały czas, a przynajmniej powinni to robić. Niemniej jednak, w ich przypadku wymagane były nieco większe konkrety – a KNF postanowił im je dać. Ja przeniosłem je na grunt tej notatki, wyrzucając to co niepotrzebne – np. w zakresie charakteru pojęcia outsourcingu (ważne z punktu widzenia tych regulowanych branż takich jak bankowa) czy też konieczności raportowania korzystania z chmury do KNF – to nas nie dotyczy. Zostawiłem tylko najważniejsze kwestie.
Jeszcze aby doprecyzować: KNF stworzył dwa dokumenty, które dotyczą tej tematyki – pierwsze to tzw. rekomendacja D – jest kilka wersji tej rekomendacji, np. banki mają swoją a ubezpieczyciele maja swoją – wiele elementów w ich treści dotyczy dokładnie tego samego. Rekomendacja D ma charakter bardziej ogólny i mówi o bezpieczeństwie IT.
Drugi dokument jest już bardziej szczegółowy i dotyczy właśnie korzystania z chmury – dodatkowo, ostatnio pojawiła się bardzo świeża wersja tego dokumentu, wydana przez KNF 23 stycznia 2020 r. To „Komunikat Urzędu Komisji Nadzoru Finansowego dotyczący przetwarzania przez podmioty nadzorowane informacji w chmurze obliczeniowej publicznej lub hybrydowej” – ten dokument jest tutaj.
Żeby nie było za mało źródeł, mamy też bardzo ciekawe rekomendacje EBA (European Banking Authority) dotyczące chmury, z których również korzystałem podczas przygotowywania tej notatki. Link tutaj.
I uwaga ważne zastrzeżenie – ten wpis jest o bezpiecznej chmurze dla wymagających. To bycie wymagającym polega na tym, że wymagamy wiele od dostawcy, ale także sporo od siebie. Nie unikniemy więc tworzenia dokumentacji dotyczącej korzystania z chmury i wdrażania niektórych zabezpieczeń, zarówno organizacyjnych, jak i technicznych, po naszej stronie. Przygotujcie się więc, o ambitni, na przykładne pisanie dokumentacji – wszystko w szczytnym celu osiągnięcia bezpieczeństwa.
I druga istotna kwestia: te rzeczy, które tu są opisane warto dokumentować – zresztą w dużej mierze o odpowiednia dokumentacje usługi chmurowej tu właśnie chodzi i we wpisie jest sporo wskazówek co w tej dokumentacji powinno się znaleźć. Jeżeli więc wykonujemy jakieś zawarte tu zalecenie, udokumentujmy, że to robimy i w jaki sposób to robimy. Dzięki temu spełniamy zasadę rozliczalności, o której mowa w przepisie art. 6 ust. 2 RODO. Od razu ostrzegam: to będzie sporo dokumentowania – ale w końcu to poradnik dla ambitnych.
Jeśli chcesz dowiedzieć się bardziej ogólnych informacji dot. tego jak zapewnić zgodność usługi chmurowej z RODO, kliknij w ten link: chmura zgodna z RODO - jak ją wdrożyć i korzystać?
Od czego zaczynamy?
Od sprecyzowania tego o czym w ogóle będziemy mówić, czyli od definicji! Komunikat KNF zawiera ich całkiem sporo, ale dla nas kluczowa będzie definicja samej chmury.
Chmura obliczeniowa wg. KNF to pula współdzielonych, dostępnych „na żądanie” przez sieci teleinformatyczne, konfigurowalnych zasobów obliczeniowych (np. sieci, serwerów, pamięci masowych, aplikacji, usług), które mogą być dynamicznie dostarczane lub zwalniane przy minimalnych nakładach pracy zarządczej i minimalnym udziale ich dostawcy. Mamy też definicję usługi chmurowej czyli gotowych do użycia, wystandaryzowanych zasobów chmury obliczeniowej służących przetwarzaniu informacji, wstępnie skonfigurowanych przez dostawcę usług chmury obliczeniowej i przez niego dostarczane.
Możemy to sobie porównać z definicją chmury np. z dyrektywy NIS, która mówi o tym, że usługa przetwarzania w chmurze” oznacza usługę cyfrową umożliwiającą dostęp do skalowalnego i elastycznego zbioru zasobów obliczeniowych do wspólnego wykorzystywania – nieco prościej niż w komunikacie KNF.
Tak czy siak, ważne w chmurze są następujące kwestie:
dostępność na żądanie
skalowalność
konfigurowalność
wspólne wykorzystanie przez grupę podmiotów.
Ta grupa podmiotów z ostatniego punktu zbliża nas do kolejnych dwóch definicji, czyli:
Chmury publicznej – to chmura dostępna do użytku publicznego, będąca w posiadaniu lub bezpośrednio zarządzana przez dostawcę usług chmury obliczeniowej;
Chmury prywatnej – to z kolei jest chmura dostępna do wyłącznego użytku jednego podmiotu, będąca w posiadaniu lub bezpośrednio zarządzana przez ten podmiot;
Miks tych dwóch chmur to tzw. „chmura hybrydowa”. Chmura dla jednej grupy kapitałowej lub grupy współpracujących podmiotów to z kolei chmura społecznościowa.
Czemu to w ogóle ważne? Bo jako klient musisz zdecydować z jakiej chmury możesz korzystać i jasno to określić w swojej dokumentacji – przy czym chmra publiczna siłą rzeczy wymusza odpowiednio wysoki środki bezpieczeństwa – tak przynajmniej wskazuje KNF.
Co trzeba zrobić na początku?
Zacząć trzeba od zdefiniowania wymogów dotyczących usługi chmurowej – zarówno biznesowe jak i prawne. Dwie kwestie, które szczególnie powinny Ci przyświecać to:
zapewnienie bezpieczeństwa Twoich danych,
zapewnienie Tobie zgodności z prawem.
Jeśli chodzi o wymogi biznesowe to trzeba odpowiedzieć sobie (między innymi) na następujące pytania:
Po co będzie wykorzystywana usługa chmurowa?
Jak istotne dla biznesu są procesy, które będą w chmurze?
Dotyczy to zwłaszcza sytuacji gdy są to procesy krytyczne dla nieprzerwanego prowadzenia biznesu, realizowania zobowiązań względem klientów itp.
Trzeba też ocenić jakie ryzyko wiąże się z outsourcowaniem tych procesów na zewnątrz, w tym jakie skutki będzie miało ewentualne wyłączenie/przerwa w dostawie usługi (np. prawne, wizerunkowe, finansowe).
Tak samo musimy ocenić skutki na wypadek ewentualnego ujawnienia informacji, wycieku danych lub naruszenia ich integralności (czyli właściwości, że dane mogą być zmieniane tylko przez upoważniona osobę i nie mogą ulec modyfikacji w inny sposób).
Analiza ryzyka to podstawa!
Tu przechodzimy do kolejnego kroku (dość płynnie zresztą, bo łączy się on z poprzednim) jakim jest właściwe szacowanie ryzyka. W komunikacie KNF nie odkryto ameryki jeśli chodzi o analizę ryzyka i zresztą chyba nikt tego od nich nie wymagał (bo po co zmieniać ustalone, przyjęte w branży standardy). KNF wskazuje, że ocena ryzyka powinna uwzględniać identyfikację zagrożeń, ich ocenę (analiza), ocenę ewentualnych skutków naruszenia bezpieczeństwa i wpływ na działalność organizacji. Tego rodzaju analiza powinna być przeprowadzona z uwzględnieniem powszechnie przyjętych metodyk, takich jak ISO 27005 czy np. metodyki NIST (które zresztą polecam, tu jest link: https://www.nist.gov/cyberframework).
Rzeczy, które warto wziąć pod uwagę w procesie szacowania ryzyka:
rozproszenie geograficzne dotyczące przetwarzania danych w chmurze, zwłaszcza w kontekście przepisów prawa i różnych jurysdykcji – czyli musimy wziąć pod uwagę gdzie dane mogą być przechowywane, np. czy chcemy aby były tylko w Polsce, na terenie Europejskiego Obszaru Gospodarczego czy mogą być przechowywane poza Europą, np. w USA – przy czym z perspektywy regulacyjnej to Polska albo EOG jest z reguły lepszym miejscem przechowywania danych niż USA,
dostęp do danych w chmurze przez pracowników oraz współpracowników dostawcy usługi chmurowej,
dostęp do przetwarzanych danych przez inne podmioty, np. organy ścigania w kraju, w którym odbywa się przetwarzanie – albo organom kraju, którym podlega dostawca usługi chmurowej – np. w związku z Cloud Act (więcej na ten temat tutaj),
Vendor lock-in czyli potencjalny brak zgodności technologicznej między naszym dostawcą usługi chmurowej a innymi dostawcami – co w praktyce powoduje związanie z tym jednym, wybranym dostawcą i niemożność zmiany dostawcy/charakteru usługi (na możliwość zmiany dostawcy i tworzenia exit planów położono w rekomendacjach duży nacisk),
kwestię izolacji naszych zasobów w ramach chmury względem innych zasobów innych klientów i ewentualne awarie z tym związane (od razu trzeba tu wskazać, że to trudne do oceny, albo nawet niemożliwe – często musimy tu polegać na zapewnieniach dostawcy),
ograniczone możliwości klienta dotyczące możliwości usuwania danych po zakończeniu okresu przetwarzania,
ograniczona możliwość kontrolowania dostawcy oraz jego poddostawców, w tym audyty, kontrole fizyczne (w przypadku chmury – mało efektywne), weryfikacja technicznych i organizacyjnych zabezpieczeń dostawcy chmurowego,
odpowiedzialność dostawcy usługi i jej ewentualne ograniczenia,
możliwość korzystania z usługi chmurowej w sposób niezgodny z intencjami organizacji, np. poprzez publiczne sieci wi-fi, prywatne urządzenia mobilne,
mechanizmy uwierzytelniania użytkowników oraz ewentualne podatności z nimi związane,
zgodność technologiczna posiadanej infrastruktury (tej dotychczas używanej) z wdrażaną infrastrukturą chmurową
sytuację finansową potencjalnego dostawcy/dostawców, renomę, ewentualne wcześniejsze incydenty w zakresie ochrony danych, wycieków itp.
Jeśli chcesz dowiedzieć się więcej na temat analizy ryzyka pod kątem bezpieczeństwa danych, kliknij tutaj: analiza ryzyka zgodna z RODO - jak ją przeprowadzić?
Kiedy dokonać oceny tych kwestii?
Ważna sprawa – nie napisałem dotąd o wyborze dostawcy usługi chmurowej. Uważam bowiem, że wstępne szacowanie ryzyka i minimalne wymogi dotyczące bezpieczeństwa usługi chmurowej powinny zostać ustalone przed wyborem dostawcy. Dopiero później wybieramy dostawcę, ustalamy warunki świadczenia usługi chmurowej i dostosowujemy do tego naszą analizę ryzyka. Wtedy też musimy już zdecydować się na konkretne środki bezpieczeństwa, tak aby były one wdrożone przed uruchomieniem produkcyjnym chmury, czyli rozpoczęciem bieżącego korzystania z niej.
Oczywiście niektóre elementy analizy ryzyka mogą powstać dopiero po wyborze usługi – stąd też konieczne jest pamiętanie o analizie ryzyka zarówno przed jak i po wyborze dostawcy. Dzięki temu unikniemy sytuacji, gdy po wyborze dostawcy, poniesieniu nakładów, zawarciu z nim umowy i uruchomieniu usługi nagle dochodzimy do wniosku, że jednak nie jest ona dość bezpieczna. Innymi słowy, spełniamy w ten sposób zasadę privacy by design – myślimy o bezpieczeństwie chmury od momentu projektowania usługi i wyboru dostawcy.
Mamy więc dwie analizy ryzyka:
jedną, wstępna, przed wyborem dostawcy, określającą minimalne wymagania w zakresie bezpieczeństwa
drugą finalna, wskazującą na konkretne zabezpieczenia, przeprowadzaną po wyborze dostawcy
Stworzenie dokumentacji dotyczącej usługi chmurowej
Wytyczna dotycząca tworzenia dokumentacji dot. usługi chmurowej znajduje się w rekomendacji EBA i uważam, że ma (wbrew pozorom) bardzo istotne znaczenie. Chodzi o to aby stworzyć odrębną, zebraną w jednym miejscu, dostępną na wypadek jakiegoś zdarzenia, dokumentację dotyczącą usługi chmurowej. Powinny znaleźć się w niej:
opis tego jakie informacje będą przetwarzane w chmurze i jakie czynności przetwarzania będą dokonywane w ramach infrastruktury chmurowej – czyli, innymi słowy, jaką część swojej działalności klient przenosi do chmury,
wskazanie z jakiego modelu usługi chmurowej korzystasz – prywatnej, publicznej, hybrydowej czy społecznościowej
sposób zabezpieczania informacji, w tym szyfrowania, informacje o zarządzaniu kluczami szyfrującymi,
informacje o tym kto ma dostęp do danych, zarówno ze strony klienta jak i dostawcy usługi
dane dotyczące samego dostawcy – nazwę, dane kontaktowe, jurysdykcja, której podlega itp.,
dane dotyczące umowy zawartej z usługodawcą – w tym to kiedy została zawarta, do kiedy obowiązuje, jakie są warunki jej przedłużenia, jakiej jurysdykcji podlega,
dane osób, które odpowiadają za usługę, jak również za cyberbezpieczeństwo – po stronie usługobiorcy,
opis architektury sieci i systemów, z uwzględnieniem usługi chmurowej
stosowane zasady bezpieczeństwa oraz zasady zarządzania ciągłością działania,
analizę ryzyka, wraz z wyjaśnieniem jak była stworzona oraz procedurą jej tworzenia i aktualizacji
procedury dotyczące zarządzania bezpieczeństwem IT, sieciami informatycznymi, kontrolowaniem logów, szyfrowania i ewentualnych audytów,
procedurę dot. exit-planu (o tym poniżej), w tym wskazanie alternatywnych dostawców usługi
decyzję organu zarządzającego organizacją (np. uchwałę zarządu) dotycząca skorzystania z usługi chmurowej.
Exit Plan
Organizacja korzystająca z chmury musi przygotować się na najgorsze. Takie przygotowanie obejmuje m.in stworzenie tzw. exit planu, czyli planu wycofania swojego zaangażowania w przetwarzanie informacji w usłudze chmurowej i przeniesienia jej na swoją infrastrukturę albo do innego dostawcy. Powinno to być przeprowadzone tak aby nie wpłynąć negatywnie na bieżącą działalność i nie zmniejszyć bezpieczeństwa danych.
Zabezpieczenia
Jeśli chodzi o konkretne zabezpieczenia to KNF nie rozwija tej kwestii (mało który urząd zresztą to robi), wskazując jednak, że:
Usługobiorca powinien mieć źródła informacji o zagrożeniach związanych z korzystaniem z chmury – innymi słowy, musimy mieć źródło wiedzy dotyczące bezpieczeństwa naszej usługi chmurowej – tu generalnie jest tak, że o ewentualnych wpadkach „większego dostawcy” częściej się dowiadujemy niż takiego mniejszego – bo z reguły o jego problemach dowiemy się jak usługa przestanie działać, albo nasze dane pojawią się gdzieś „na zewnątrz”,
Usługodawca powinien analizować wyniki audytu dostawcy, w tym również np. publikowane audyty wykonywane przez zewnętrznych ekspertów, podmioty certyfikujące itp.,
Usługobiorca powinien testować swoją usługę – również w sytuacji wystąpienia warunków skrajnych,
Weryfikacja zagrożeń powinna być prowadzona na bieżąco – i warto przyjąć mechanizmy (procedury), które to wymuszą, tak aby móc identyfikować nowe zagrożenia i wprowadzać ewentualne środki przeciwdziałające tym zagrożeniom – w trybie ciągłym, nie raz na jakiś czas albo jedynie w trakcie wdrożenia,
Usługobiorca powinien na bieżąco zbierać i mieć dostęp do logów, związanych z przetwarzaniem informacji w chmurze. Nie powinny one być zbierane dla samego zbierania, ale również analizowane pod katem ewentualnych naruszeń bezpieczeństwa, najlepiej za pomocą specjalistycznego oprogramowania. Logi również traktować należy jak dane poufne, które trzeba chronić.
Dodatkowo, w treści wytycznych wskazano, że centra przetwarzania danych dostawcy usługi chmurowej powinny spełniać określone standardy, np. ANSI/TIA-942 na poziomie Tier III albo wyższym. Więcej na ten temat tu.
Szyfrowanie
KNF sporo napisał w swoim komunikacie o szyfrowaniu i mocno naciska na jego stosowanie. Spójrzmy np. na to zdanie: „informacje przetwarzane w chmurze obliczeniowej powinny być szyfrowane zawsze, gdy to jest technologicznie możliwe i ekonomicznie zasadne”. Można by uznać, że jak to jest ekonomicznie niezasadne to nie trzeba szyfrować – ale naprawdę trzeba to traktować jako wyjątek. Szyfrowanie danych w chmurze ma być zasadą. W końcu to chmura dla wymagających – czyli szyfrowanie jest standardem.
A jakie to ma być szyfrowanie? Po pierwsze, szyfrowanie dotyczy zarówno danych, które są przesyłane (in transit) jak i po prostu zapisane w chmurze (at rest). Stosowany więc czasem argument „szyfrujemy bo tu jest SSL/TLS” nie będzie wystarczający.
Szyfrowanie samo w sobie nie zmniejsza wartości (ważności) informacji, która jest zaszyfrowana. KNF podkreśla tez ważność zarządzania kluczami szyfrującymi, przy czym najlepiej aby takie zarządzanie było po naszej stronie jako usługobiorcy, a nie po stronie dostawcy usługi chmurowej (chociaż KNF sam przyznaje, że mogą być od tej zasady wyjątki) – innymi słowy, mamy infrastrukturę w chmurze, ale to my szyfrujemy, ustalamy parametry i oczywiście wybieramy konkretne rozwiązania szyfrujące – KNF tu wskazuje rzecz, która w teorii jest oczywista, ale w praktyce już niekoniecznie – stosujemy te algorytmy szyfrujące, które nie uchodzą (wg. Przekazów medialnych, powszechnej wiedzy specjalistów w tym zakresie) za skompromitowane, tzn. takie, co do których istnieją znane luki bezpieczeństwa lub zostały wprost złamane.
Podwykonawcy
Dostawcy usług chmurowych korzystają z podwykonawców – to jest wiedza powszechnie znana. My jako organizacja korzystająca z chmury nie możemy przejść wobec tego obojętnie i dlatego ta kwestia została bardzo ładnie wyjaśniona w wytycznych EBA. Klient (usługobiorca) powinien o takich podwykonawcach wiedzieć – tzn. nie tylko wiedzieć, że istnieją, ale także mieć świadomość:
a) za jakie czynności przetwarzania odpowiadają,
b) kim są podwykonawcy i gdzie mają siedzibę,
c) gdzie dochodzi do operacji przetwarzania.
EBA mocno podkreśla, że nie musimy wyrażać zgody na dodanie/zmianę każdego z podwykonawców, bo jest to nieuzasadnione charakterem usługi (to w mojej ocenie bardzo rozsądne podejście i podoba mi się to). Wystarczy, że jako klienci będziemy dostaniemy odpowiednio wcześnie informację o takim podwykonawcy i będziemy mieli możliwość złożenia sprzeciwu wobec przekazania naszych danych podwykonawcy – i w skrajnym przypadku powinniśmy mieć przyznaną przez dostawcę możliwość rozwiązania umowy i przeniesienia się „gdzieś indziej”.
Prawo właściwe i umowa z dostawcą
Generalnie rzecz biorąc, umowa o dostarczanie usługi chmurowej powinna podlegać prawu polskiemu albo prawu innego pastwa członkowskiego UE. Ewentualne wyjątki wymagają dodatkowych analiz w zakresie prawa państwa trzeciego – co generalnie będzie pewnym utrudnieniem w zakresie możliwości zawarcia takiej umowy.
Sama umowa powinna jasno określać następujące kwestie:
odpowiedzialność dostawcy usługi za niedopełnienie warunków świadczenia usługi (tu zwracam uwagę, że dostawcy usług generalnie mocno ograniczają tę odpowiedzialność, np. finansowo do kwoty miesięcznego wynagrodzenia za korzystanie z chmury przez klienta – jeżeli my opieramy nasz biznes na chmurze to taka kwota może mieć się nijak do strat, które poniesiemy przez brak dostępności usługi),
kwestie ewentualnego serwisu, odpowiedzi na zgłoszenia o błędach (czas reakcji, czas naprawy lub obejścia),
wskazywać na deklarowany poziom SLA oraz konsekwencji jego niedochowania (np. kary umowne), a także na poziom RTO (recovery time objective - czas przywrócenia dostępności usługi) i RPO (recovery point objective - czas pomiędzy tworzeniem kopii zapasowych,
spełniać wymogi wynikające z przepisów prawa, postanowienia dot. powierzenia przetwarzania danych,
informacje o sposobie rozwiązania umowy, zwrotu lub usunięcia danych, wsparcia w przemienieniu ich do innego usługodawcy itp.,
kwestie dot. własności intelektualnej - np. licencja do wykorzystania oprogramowania dostarczanego przez dostawcę, jak również samej infrastruktury (ona też może być chroniona prawami autorskimi)
zasady wymiany informacji i współdziałania na wypadek incydentów bezpieczeństwa.
Audyty
O audytach trochę było już powyżej. Zarówno KNF jak i EBA mocno podkreślają, że prawo do audytowania dostawcy usługi chmurowej jest kluczowe dla zapewnienia zgodności korzystania z chmury z zasadami dotyczącymi odpowiedniego poziomu bezpieczeństwa. Nie ma więc opcji aby zrezygnować z audytu w umowie, albo znacznie te audyty ograniczać.
Taki audyt powinien obejmować zarówno możliwość fizycznego dostępu do centrów przetwarzania danych usługodawcy, wizytę w jego siedzibie (tu jednak EBA zastrzega, że w dzisiejszych czasach ma to ograniczone zastosowanie) jak również możliwość wglądu do dokumentacji bezpieczeństwa, sprawdzenia procedur itp. Audyt powinien obejmować również możliwość dostępu logicznego do zasobów, które są przetwarzane przez dostawcę, weryfikacji kwestii związanych z bezpieczeństwem technicznym, wykorzystywanym oprogramowaniem itp. Tym samym zakres audytu powinien być możliwie szeroki. EBA wskazuje także, że ewentualny audyt powinien obejmować szacowanie ryzyka związanego z ewentualnymi zagrożeniami dot. bezpieczeństwa, które mogą urzeczywistnić się po stronie usługodawcy. Audyt powinien móc obejmować także ewentualnych podwykonawców dostawcy.
Audyt może być prowadzony przez klienta, albo przez wskazany przez niego podmiot, np. zewnętrzną firmę zajmującą się audytami cyberbezpieczeństwa itp. Niezależnie od tego, usługobiorca powinien móc analizować także inne raporty z audytów, np. przygotowane przez niezależne organizacje certyfikujące.
Ograniczanie możliwości audytu np. do tego, że dostawca będzie audytowany wyłącznie przez wybrane przez siebie podmioty, które następnie opublikują informacje o audycie nie jest mile widziane i nie może być uznawane za prawidłowe. Oznacza to w praktyce, że klient sam nie może audytować samodzielnie dostawcy, a robi to tylko podmiot wybrany przez samego dostawcę. W konsekwencji to zaburza istotę audytu. Generalnie rzecz biorąc, umowne ograniczanie prawa do audytu powinno być wykorzystywane bardzo ostrożnie, jako że jest zawsze niekorzystne dla usługobiorcy.
Zespół, czyli ludzie "od chmury"
Podmiot, który korzysta z chmury nie może przenosić całej wiedzy dotyczącej infrastruktury IT na „zewnątrz”, tzn. do dostawcy. Powinien zatem współpracować z osobą lub grupą osób, które mają wiedzę na temat działania chmury i mogą podejmować takie czynność aby ją utrzymywać, testować i zapewniać ciągłość działania. Poleganie wyłącznie na dostawcy usługi jest błędem – musimy mieć w środku naszej organizacji kogoś kto odpowiada za kwestie techniczne, zna architekturę itp.
Podsumowanie
Organy nadzorcze, zajmujące się kwestiami związanymi z przetwarzaniem danych przez banki, ubezpieczycieli, instytucje finansowe czy firmy inwestycyjne ustaliły dość wysokie wymagania dotyczące bezpieczeństwa chmury. Zdaję sobie sprawę z tego, że większość działających na rynku organizacji nie potrzebuje aż takich zabezpieczeń, niesamowicie szczegółowej dokumentacji, a często także nie ma „siły gospodarczej” żeby sobie tak korzystne warunki wynegocjować z dostawcą.
Niemniej jednak, powyższe zalecenia mogą być przydatne również dla mniej krytycznych podmiotów, które po prostu chcą korzystać z bezpiecznej chmury i opierać na niej swój biznes bez konieczności martwienia się nagłym odcięciem od usługi, problemami z bezpieczeństwem, przerwami w działaniu czy też trudnościami w konfiguracji. Dlatego właśnie powstał ten wpis – niech każdy wybierze z niego to co jest dla niego odpowiednie, tak aby doprowadzić do korzystania z bezpiecznej i zgodnej z RODO chmury.
Spodobał Ci się ten wpis? Jeśli masz jakieś dodatkowe pytania, możesz śmiało się ze mną skontaktować, pisząc na kontakt@bytelaw.pl, albo korzystając z formularza kontaktowego tutaj.
