„Plik jest w chmurze” nie oznacza, że znajduje się w niematerialnej przestrzeni poza odpowiedzialnością użytkownika. Dane są przechowywane i przetwarzane na fizycznej infrastrukturze dostawcy, a dostęp do niej uzyskujemy przez sieć. Chmura może zapewniać skalę, współpracę i wysoką dostępność, ale nie usuwa ryzyka. Zmienia przede wszystkim to, kto odpowiada za poszczególne warstwy bezpieczeństwa.
Najważniejsza myśl
Chmura nie jest ani z definicji bezpieczna, ani z definicji niebezpieczna. Bezpieczeństwo zależy od modelu usługi, konfiguracji, tożsamości użytkowników, umowy, kopii zapasowych, urządzeń końcowych i rodzaju danych. Dostawca może bardzo dobrze chronić centrum danych, a uczelnia nadal może udostępnić cały folder publicznym linkiem!
Folder, który miał być kopią zapasową
Studentka pisze pracę magisterską na laptopie. Wszystkie pliki trzyma w folderze synchronizowanym z usługą chmurową. Widzi zielone oznaczenie i jest przekonana, że posiada bezpieczną kopię. Pewnego dnia omyłkowo usuwa katalog z danymi, a klient synchronizacji natychmiast odtwarza tę samą zmianę na innych urządzeniach. Później okazuje się, że kosz usługi był opróżniany automatycznie, a historia wersji nie obejmowała wszystkich plików.
To nie musi oznaczać, że usługa była wadliwa. Zadziałała zgodnie z przeznaczeniem: utrzymała ten sam stan folderu na wielu urządzeniach. Problem polegał na utożsamieniu synchronizacji z niezależną kopią zapasową. Podobne nieporozumienia dotyczą bezpieczeństwa całej chmury. Użytkownik widzi profesjonalny interfejs i zakłada, że dostawca odpowiada także za błędnie nadane uprawnienia, słabe hasło, przypadkowe usunięcie, ransomware albo przechowywanie danych, których regulamin zabrania wgrywać.
Bezpieczne korzystanie z chmury zaczyna się więc nie od wyboru logo, lecz od zrozumienia usługi. Trzeba wiedzieć, co jest przechowywane, kto ma dostęp, jaka wersja jest źródłowa, jak działa odzyskiwanie, co dzieje się po utracie konta i kto ponosi odpowiedzialność za poszczególne warstwy.
Czym jest chmura obliczeniowa?
NIST definiuje cloud computing jako model zapewniający powszechny, wygodny i realizowany na żądanie dostęp sieciowy do współdzielonej puli konfigurowalnych zasobów, takich jak sieci, serwery, pamięć, aplikacje i usługi. Zasoby mogą być szybko uruchamiane i zwalniane przy niewielkim nakładzie zarządzania lub bezpośredniej obsługi ze strony dostawcy.
W praktyce oznacza to, że uczelnia lub użytkownik nie musi samodzielnie kupować i utrzymywać całej infrastruktury. Może uruchomić skrzynkę pocztową, przestrzeń na pliki, serwer obliczeniowy, bazę danych albo środowisko do uczenia modeli i płacić za określony zakres. Fizyczne urządzenia nadal istnieją – znajdują się w centrach danych dostawcy lub jego podwykonawców.
Klasyczna definicja chmury wskazuje pięć cech:
- Samoobsługa na żądanie – zasób można uruchomić bez długiego procesu ręcznej obsługi przez dostawcę.
- Szeroki dostęp sieciowy – usługa jest dostępna przez standardowe mechanizmy z różnych urządzeń.
- Współdzielenie puli zasobów – infrastruktura obsługuje wielu klientów, a zasoby są przydzielane dynamicznie.
- Elastyczność – pojemność może szybko rosnąć lub maleć wraz z potrzebami.
- Mierzalność usługi – zużycie jest monitorowane i rozliczane według ustalonego modelu.
Nie każda strona internetowa z możliwością przesłania pliku jest pełnoprawną „chmurą” w technicznym znaczeniu. W języku codziennym pojęcie jest jednak używane szeroko: obejmuje pocztę, pakiety biurowe, dyski sieciowe, platformy edukacyjne, repozytoria, narzędzia obliczeniowe, systemy kadrowe i aplikacje dostępne przez przeglądarkę.
SaaS, PaaS i IaaS – trzy poziomy odpowiedzialności
Najważniejszym praktycznym podziałem są modele usług. Im więcej warstw obsługuje dostawca, tym mniej technicznych elementów konfiguruje klient. Nie oznacza to jednak, że odpowiedzialność klienta znika. Przesuwa się w stronę tożsamości, danych, konfiguracji, procesów i zachowań użytkowników.
| Model | Co otrzymuje użytkownik? | Przykład akademicki | Za co nadal odpowiada uczelnia lub użytkownik? |
|---|---|---|---|
| SaaS – oprogramowanie jako usługa | Gotową aplikację działającą przez przeglądarkę lub klienta. | Poczta, pakiet biurowy, dysk współdzielony, system wideokonferencji, platforma zajęć. | Konta, uprawnienia, udostępnianie, klasyfikacja danych, urządzenia, retencja, konfiguracja funkcji i zgodność użycia. |
| PaaS – platforma jako usługa | Środowisko do uruchamiania aplikacji bez zarządzania całą infrastrukturą bazową. | Platforma, na której zespół tworzy aplikację badawczą lub portal projektu. | Kod aplikacji, dane, tożsamości, sekrety, konfiguracja platformy, zależności i bezpieczny cykl wytwarzania. |
| IaaS – infrastruktura jako usługa | Wirtualne serwery, pamięć, sieci i inne zasoby infrastrukturalne. | Maszyny obliczeniowe do analiz, środowisko laboratoryjne, repozytorium danych projektu. | Systemy operacyjne, aktualizacje, konfiguracja sieci, aplikacje, konta, dane, monitoring i większość zabezpieczeń powyżej warstwy sprzętowej. |
Różnica ma znaczenie podczas incydentu. W SaaS użytkownik zwykle nie administruje serwerem, ale nadal może udostępnić dokument publicznie albo utracić konto. W IaaS dostawca może zabezpieczać budynek i hipernadzorcę, lecz uczelnia odpowiada za niezałatany system, otwarty port i domyślne hasło do aplikacji.
Chmura publiczna, prywatna, wspólnotowa i hybrydowa
Chmura publiczna jest oferowana wielu klientom przez zewnętrznego dostawcę. „Publiczna” nie oznacza, że dane są publicznie dostępne. Oznacza model własności i współdzielenia infrastruktury. Dostęp do danych nadal powinien być kontrolowany.
Chmura prywatna jest przeznaczona dla jednej organizacji. Może znajdować się w jej centrum danych albo być obsługiwana przez zewnętrznego dostawcę. Daje większą kontrolę, ale wymaga zasobów, kompetencji i utrzymania. Samo słowo „prywatna” nie gwarantuje wyższego bezpieczeństwa.
Chmura wspólnotowa służy grupie organizacji o podobnych wymaganiach, na przykład instytucjom publicznym lub jednostkom badawczym. Chmura hybrydowa łączy co najmniej dwa środowiska, umożliwiając przenoszenie danych i obciążeń między nimi. Uczelnia może przechowywać dane szczególnie chronione w jednym środowisku, a publiczny portal i obliczenia o zmiennym zapotrzebowaniu w innym.
Multi-cloud oznacza korzystanie z usług wielu dostawców. Może zmniejszać zależność od jednego podmiotu, ale zwiększa złożoność zarządzania tożsamością, logami, umowami i kompetencjami. Sama obecność dwóch dostawców nie tworzy odporności, jeżeli oba środowiska zależą od tego samego konta administracyjnego albo dane nie są rzeczywiście odtwarzalne.
Synchronizacja, kopia zapasowa i archiwum to nie to samo
Te pojęcia są często używane zamiennie, ale rozwiązują różne problemy. Bezpieczny system może potrzebować wszystkich trzech.
| Mechanizm | Główny cel | Czego nie gwarantuje? |
|---|---|---|
| Synchronizacja | Utrzymanie podobnego bieżącego stanu plików na wielu urządzeniach i ułatwienie współpracy. | Niezależnej kopii odpornej na usunięcie, ransomware, błąd uprawnień lub utratę konta. |
| Historia wersji | Powrót do wcześniejszych wersji w określonym okresie i zakresie. | Nieograniczonej retencji, zachowania każdego typu pliku ani ochrony po zamknięciu konta. |
| Kopia zapasowa | Odtworzenie danych po awarii, usunięciu, szyfrowaniu lub innym incydencie. | Skutecznego odtworzenia, jeżeli kopia nie jest testowana, jest dostępna tym samym kontem lub obejmuje zbyt mały zakres. |
| Archiwum | Długoterminowe zachowanie danych zgodnie z okresem retencji, wymogami naukowymi lub prawnymi. | Wygodnej bieżącej współpracy ani szybkiego odtworzenia całego środowiska. |
Kopia zapasowa powinna być logicznie lub technicznie oddzielona od zwykłego konta użytkownika, posiadać określony czas przechowywania i być regularnie testowana. Informacja „dostawca wykonuje backup” nie wystarcza. Trzeba wiedzieć, czego kopia dotyczy, kto może ją odtworzyć, jak długo trwa odzyskanie, czy obejmuje konfigurację i co dzieje się po przypadkowym usunięciu całego użytkownika.
Co chmura daje uczelni?
Dostępność i współpraca
Zespół może pracować nad dokumentem z różnych miejsc, udostępniać dane partnerom i utrzymywać wspólną wersję materiału. Jest to szczególnie ważne w projektach międzynarodowych, kształceniu hybrydowym i pracy rozproszonych zespołów. Centralne zarządzanie może być bezpieczniejsze niż przesyłanie wielu kopii załączników pocztą.
Skalowalność
Rekrutacja, sesja egzaminacyjna, obliczenia badawcze i duża konferencja generują okresowe skoki zapotrzebowania. Chmura pozwala uruchomić dodatkowe zasoby bez zakupu infrastruktury używanej tylko przez kilka tygodni. Zwiększa to elastyczność, ale wymaga limitów kosztów i ochrony przed niekontrolowanym zużyciem.
Profesjonalne mechanizmy bezpieczeństwa
Duży dostawca może utrzymywać całodobowy monitoring, redundancję, wyspecjalizowane zespoły, aktualizacje i certyfikowane procesy, których mała jednostka nie byłaby w stanie samodzielnie finansować. Korzyść pojawia się jednak tylko wtedy, gdy uczelnia prawidłowo konfiguruje usługę i rozumie zakres gwarancji.
Standaryzacja i centralna kontrola
Uczelnia może zarządzać tożsamością, wymuszać uwierzytelnianie wieloskładnikowe, stosować etykiety poufności, rejestrować udostępnienia i odbierać dostęp po zakończeniu współpracy. Centralny system może ograniczać chaos prywatnych dysków, ale nie zadziała, jeśli użytkownicy przeniosą pracę do niezatwierdzonych usług.
Odporność i odtwarzanie
Chmura może ułatwić geograficzne rozproszenie i odtworzenie usług po awarii. Nie należy jednak zakładać, że każda usługa domyślnie działa w wielu regionach albo że dostawca odtworzy dane po błędzie klienta. Odporność musi być zaprojektowana, zakontraktowana i przetestowana.
Najważniejsze ryzyka
1. Błędna konfiguracja i publiczne udostępnienie
Jeden publiczny link, otwarty zasób pamięci albo uprawnienie „każdy w internecie” może ujawnić tysiące plików. Dostawca może prawidłowo chronić infrastrukturę, a wyciek nastąpi z powodu decyzji klienta. Potrzebne są bezpieczne ustawienia domyślne, przeglądy i automatyczne wykrywanie nadmiernego udostępnienia.
2. Przejęcie tożsamości
W chmurze konto jest często kluczem do poczty, dokumentów, kalendarza i aplikacji. Przejęcie jednej tożsamości może dać szeroki dostęp. Szczególnie niebezpieczne są konta administracyjne, brak wieloskładnikowego uwierzytelniania, stare protokoły logowania i sesje pozostające aktywne po zmianie hasła.
3. Nadmierne uprawnienia
Uprawnienia narastają wraz ze zmianą ról. Były członek projektu może zachować dostęp, student może otrzymać link przeznaczony dla zespołu, a aplikacja zewnętrzna – prawo do całej skrzynki. Należy stosować zasadę najmniejszych uprawnień, daty wygaśnięcia i okresowe przeglądy.
4. Shadow IT
Pracownik lub student zakłada prywatny dysk, ponieważ oficjalna usługa ma zbyt mały limit albo współpraca z partnerem jest trudna. Dane opuszczają kontrolowane środowisko, a uczelnia nie zna warunków, miejsca przetwarzania ani sposobu odzyskania. Rozwiązaniem nie jest wyłącznie zakaz, lecz również zapewnienie użytecznych, zatwierdzonych narzędzi.
5. Ransomware i synchronizacja szkody
Złośliwe oprogramowanie może zaszyfrować lokalne pliki, a klient synchronizacji prześle zmiany do chmury. Historia wersji może pomóc, ale nie zawsze obejmuje cały zakres i okres. Kopie zapasowe powinny być oddzielone, a konta użytkowników nie powinny mieć możliwości usunięcia wszystkich wersji i backupów.
6. Awaria dostawcy i zależności
Nawet duża usługa może być niedostępna. Jedna awaria tożsamości, DNS lub wspólnej platformy może wpłynąć na wiele aplikacji równocześnie. Uczelnia powinna znać krytyczne zależności, mieć procedury pracy awaryjnej i ustalić, które usługi wymagają niezależnego kanału komunikacji.
7. Uzależnienie od dostawcy
Proprietarny format, koszt transferu, brak pełnego eksportu lub silne powiązanie aplikacji z jedną platformą utrudniają zmianę. Plan wyjścia powinien powstać przed zawarciem umowy: format danych, terminy, usuwanie kopii, migracja tożsamości, pomoc dostawcy i możliwość odtworzenia konfiguracji.
8. Lokalizacja, podwykonawcy i transfery danych
Uczelnia musi wiedzieć, kto przetwarza dane, w jakich państwach, na jakiej podstawie i z jakimi zabezpieczeniami. Zmiana podwykonawcy albo regionu może wpływać na obowiązki. Sam napis „serwery w UE” nie wyczerpuje analizy prawnej i technicznej.
9. Wielodostępność infrastruktury
Wiele usług korzysta ze współdzielonych zasobów. Dostawca odpowiada za izolację klientów, ale uczelnia powinna oceniać poziom zapewnienia, certyfikaty, historię incydentów i wymagania dla szczególnie wrażliwych danych. Współdzielenie może zwiększać efektywność i odporność, a jednocześnie tworzy złożone zależności.
10. Utrata kontroli po zakończeniu studiów lub projektu
Konto absolwenta może zostać wyłączone, a dane zespołu pozostać w prywatnym katalogu osoby, która odeszła. Projekty powinny mieć właścicieli instytucjonalnych, procedurę przekazania, terminy retencji i informację dla użytkownika, co stanie się z plikami po zmianie statusu.
Model współdzielonej odpowiedzialności
W chmurze bezpieczeństwo jest podzielone między dostawcę i klienta. Zakres zależy od modelu usługi. Dostawca zwykle odpowiada za fizyczne centra danych, sprzęt, podstawową warstwę wirtualizacji i dostępność zgodną z umową. W SaaS przejmuje także większą część aplikacji. Uczelnia nadal odpowiada za to, kto ma konto, jakie dane umieszcza, jak konfiguruje udostępnianie, jakie aplikacje integruje i jak reaguje na incydent.
W IaaS uczelnia przejmuje znacznie więcej: system operacyjny, aktualizacje, zaporę, aplikację, konta i konfigurację sieci. Zdanie „to jest w chmurze” nie zwalnia administratora z łatania serwera. Z kolei w SaaS zdanie „dostawca odpowiada za bezpieczeństwo” nie zwalnia z przeglądu uprawnień i ochrony kont.
Podział odpowiedzialności powinien być jawnie opisany w dokumentacji i umowie. Trzeba ustalić, kto wykrywa incydent, w jakim czasie informuje drugą stronę, kto zabezpiecza logi, kto kontaktuje się z osobami, których dane dotyczą, jak działa odtwarzanie i kto usuwa dane po zakończeniu umowy. Brak tych ustaleń staje się szczególnie widoczny dopiero podczas kryzysu.
Jak korzystać z chmury bezpiecznie?
1. Korzystaj z usługi zatwierdzonej przez uczelnię
Instytucjonalne konto umożliwia centralne zabezpieczenia, odzyskanie dostępu, przegląd logów i przekazanie danych. Prywatne konto może być wygodne, ale uczelnia nie odzyska z niego wyników projektu po odejściu pracownika. Wyjątki powinny być świadome i udokumentowane.
2. Klasyfikuj dane przed wysłaniem
Inaczej traktuje się publiczną prezentację, inaczej listę uczestników zajęć, a jeszcze inaczej dane zdrowotne respondentów, nieopublikowany patent czy dokumentację bezpieczeństwa. Uczelnia powinna mieć prostą klasyfikację i przypisane do niej dozwolone usługi. Gdy zasad brak, należy zapytać właściciela danych, inspektora ochrony danych lub dział bezpieczeństwa.
3. Zabezpiecz tożsamość
Włącz wieloskładnikowe uwierzytelnianie, używaj unikalnego hasła lub klucza dostępu, nie zatwierdzaj nieoczekiwanych powiadomień i sprawdzaj aktywne sesje. Administratorzy powinni korzystać z oddzielnych kont uprzywilejowanych i silniejszych metod uwierzytelniania.
4. Nadawaj najmniejsze potrzebne uprawnienia
Zamiast publicznego linku wybierz konkretne osoby lub grupę. Ustaw datę wygaśnięcia, ogranicz pobieranie, jeżeli ma to sens, i regularnie przeglądaj dostęp. Link przesłany do jednej osoby może zostać dalej przekazany, jeśli nie jest związany z tożsamością.
5. Zadbaj o szyfrowanie i klucze
Większość renomowanych usług szyfruje transmisję i dane przechowywane na infrastrukturze, ale zakres i zarządzanie kluczami mogą się różnić. Szyfrowanie „po stronie dostawcy” chroni przed częścią zagrożeń infrastrukturalnych, lecz dostawca może nadal mieć techniczną możliwość przetwarzania danych. Szyfrowanie po stronie klienta zwiększa poufność, ale komplikuje współpracę, wyszukiwanie, odzyskiwanie i zarządzanie kluczami. Utrata klucza może oznaczać trwałą utratę danych.
6. Zaprojektuj kopie i testuj odtwarzanie
Ustal wymagany czas odtworzenia, dopuszczalną utratę ostatnich zmian, zakres kopii i odpowiedzialną osobę. Regularnie wykonuj próbę odtworzenia, nie tylko sprawdzaj, czy zadanie backupu ma status „zielony”. Krytyczne dane mogą wymagać kopii w oddzielnym środowisku lub u innego dostawcy.
7. Włącz logowanie i alerty
Warto rejestrować logowania, udostępnienia, pobrania, zmiany uprawnień, tworzenie kluczy i działania administratorów. Logi muszą być przechowywane wystarczająco długo i dostępne podczas incydentu. Samo gromadzenie bez monitoringu i procedury reakcji daje ograniczoną wartość.
8. Zarządzaj cyklem życia
Dostęp powinien wygasać wraz z końcem zajęć, projektu, zatrudnienia lub współpracy. Dane muszą mieć właściciela, okres retencji i sposób usunięcia. Należy unikać sytuacji, w której jedynym administratorem repozytorium jest student kończący uczelnię albo pracownik na czasowej umowie.
9. Sprawdź dostawcę i umowę
W przypadku danych osobowych administrator powinien korzystać z podmiotu przetwarzającego zapewniającego wystarczające gwarancje. Trzeba przeanalizować środki bezpieczeństwa, podwykonawców, lokalizację, zgłaszanie incydentów, audyt, usuwanie, kopie, dostęp organów, plan wyjścia i zakres odpowiedzialności. Certyfikat może być ważnym dowodem, ale nie zastępuje analizy konfiguracji i celu użycia.
10. Przygotuj prostą ścieżkę zgłaszania
Użytkownik, który omyłkowo utworzył publiczny link lub przesłał plik na prywatne konto, powinien wiedzieć, do kogo natychmiast napisać. Kultura karania za każdy błąd opóźnia reakcję. Szybkie zgłoszenie pozwala odebrać dostęp, sprawdzić logi i ocenić, czy dane zostały pobrane.
Studium przypadku: publiczny link do danych badawczych
Zespół prowadzi badanie ankietowe. Koordynator chce przekazać partnerowi tabelę z wynikami zagregowanymi, ale omyłkowo udostępnia cały folder, w którym znajduje się także plik z adresami e-mail i odpowiedziami surowymi. Link ma ustawienie „każdy, kto go posiada”, a wiadomość zostaje przesłana na szeroką listę.
Po zauważeniu błędu koordynator nie ogranicza się do usunięcia e-maila z własnej skrzynki. Natychmiast odbiera publiczny dostęp, nie kasuje logów, zgłasza zdarzenie zespołowi bezpieczeństwa i inspektorowi ochrony danych oraz zapisuje czas, zakres i listę odbiorców. Administrator sprawdza, czy pliki były otwierane lub pobierane. Zespół ocenia ryzyko dla osób, których dane dotyczą, i realizuje obowiązki wynikające z procedur oraz przepisów.
Następnie uczelnia zmienia proces. Publiczne linki są domyślnie wyłączone dla przestrzeni badawczych, udostępnienie danych wrażliwych wymaga wskazania konkretnego konta, a foldery surowe i zagregowane są rozdzielone. Wprowadza się daty wygaśnięcia, automatyczne alerty o szerokim udostępnieniu i krótkie szkolenie dla zespołu.
Incydent nie wynikał z „włamania do chmury”. Wynikał z niebezpiecznego ustawienia i nieczytelnej struktury danych. Dostawca chronił usługę zgodnie z umową, ale bezpieczeństwo dostępu pozostawało po stronie uczelni.
Najczęstsze pytania
Czy chmura jest bezpieczniejsza niż własny serwer?
Nie ma uniwersalnej odpowiedzi. Duży dostawca może oferować lepszą redundancję i monitoring, ale usługa może być źle skonfigurowana albo niedostosowana do danych. Własny serwer daje kontrolę, lecz wymaga kompetencji, aktualizacji, fizycznego bezpieczeństwa i kopii. Należy porównać konkretne architektury i ryzyka. Czy popularny dysk chmurowy jest kopią zapasową?
Może zawierać historię wersji i funkcje odzyskiwania, ale zwykła synchronizacja nie jest niezależnym backupem. Trzeba sprawdzić retencję, zakres, możliwość masowego usunięcia, ochronę przed ransomware i przeprowadzić test odtworzenia. Czy dostawca może czytać moje dane?
Zależy to od architektury, szyfrowania, zarządzania kluczami, funkcji usługi i umowy. Szyfrowanie podczas przesyłania oraz na dysku nie zawsze oznacza, że dostawca technicznie nie może przetwarzać treści. Dla danych o wysokiej poufności potrzebna jest szczegółowa analiza. Czy dane osobowe mogą być przechowywane w chmurze?
Mogą, jeżeli przetwarzanie spełnia wymagania prawa, a usługa, umowa, środki bezpieczeństwa, podwykonawcy i transfery zostały odpowiednio ocenione. Nie każda usługa i nie każda konfiguracja nadaje się do każdego rodzaju danych. Co stanie się z plikami po ukończeniu studiów?
Zależy od polityki uczelni. Konto może zostać ograniczone lub usunięte po określonym czasie. Student powinien wcześniej przenieść własne materiały, ale nie wolno kopiować danych uczelni, uczestników badań lub projektów bez uprawnienia. Wyniki instytucjonalne powinny mieć właściciela i miejsce niezależne od konta odchodzącej osoby. Czy multi-cloud automatycznie chroni przed awarią?
Nie. Odporność powstaje dopiero wtedy, gdy dane i usługi można rzeczywiście odtworzyć w drugim środowisku, tożsamość i klucze nie mają wspólnego punktu awarii, a proces jest testowany. Korzystanie z dwóch usług bez planu może jedynie podwoić złożoność.
Checklista przed wysłaniem danych do chmury
- Czy usługa jest zatwierdzona do tego rodzaju danych?
- Kto jest właścicielem danych i kto ma prawo nadawać dostęp?
- Czy używam konta instytucjonalnego i silnego uwierzytelniania?
- Czy link jest ograniczony do konkretnych osób i ma termin wygaśnięcia?
- Czy dane wymagają pseudonimizacji, szyfrowania lub dodatkowej zgody?
- Czy istnieje niezależna kopia zapasowa i czy odtwarzanie było testowane?
- Czy logi pokażą, kto otwierał, pobierał lub zmieniał dane?
- Co stanie się po zakończeniu projektu, studiów lub umowy?
- Jak można wyeksportować i trwale usunąć dane?
- Komu i jak szybko zgłosić błędne udostępnienie albo utratę konta?
Źródła i dalsza lektura
- NIST SP 800-145: „The NIST Definition of Cloud Computing” – definicja, cechy, modele usług i wdrożeń.
- ENISA: EUCS – Cloud Services Scheme – podział odpowiedzialności między dostawcę i klienta chmury oraz informacje potrzebne do świadomego wyboru usługi.
- ENISA: Cloud Cybersecurity Market Analysis – rynek bezpieczeństwa chmurowego i znaczenie modelu współdzielonej odpowiedzialności.
- Europejska Rada Ochrony Danych: raport o korzystaniu z usług chmurowych przez sektor publiczny.
- Rozporządzenie (UE) 2016/679 – RODO, w szczególności zasady korzystania z podmiotów przetwarzających i bezpieczeństwa przetwarzania.