Zgodność z RODO dla chmury: przewodnik po praktykach
Najlepsze praktyki zgodnej z RODO chmury: szyfrowanie, kontrola dostępu, wymagania dotyczące lokalizacji danych oraz kryteria oceny dostawców.
Chmura zgodna z RODO wymaga pięciu warstwowych mechanizmów kontrolnych: (1) szyfrowanie w spoczynku z AES-256 i w tranzycie z TLS 1.3, idealnie uzupełnione szyfrowaniem po stronie klienta dla danych wrażliwych; (2) umowa powierzenia przetwarzania danych (DPA) z dostawcą spełniająca wymogi art. 28 ust. 3; (3) udokumentowana rezydencja danych — zazwyczaj UE/EOG dla danych osobowych z UE — z przejrzystością dotyczącą podwykonawców; (4) szczegółowa kontrola dostępu z MFA, uprawnieniami opartymi na rolach i dziennikami audytu przechowywanymi przez co najmniej sześć miesięcy; (5) wykrywanie naruszeń umożliwiające zachowanie 72-godzinnego okna powiadomień z art. 33. Pominięcie któregokolwiek z tych elementów czyni warstwę przechowywania najsłabszym ogniwem stosu zgodności.
Wybór dostawcy zgodnego z art. 28
Rynek europejskich DPA segreguje dostawców na wyraźne poziomy. Hiperscalerzy (AWS, Azure, Google Cloud) oferują rozbudowane DPA i regiony europejskie, ale niosą ze sobą ekspozycję na CLOUD Act. Europejscy dostawcy suwerenni (OVHcloud, Scaleway, Infomaniak, Hetzner, IONOS) unikają jurysdykcji USA i często posiadają certyfikacje C5, SecNumCloud lub ISO 27001. Wyspecjalizowani dostawcy nastawieni na prywatność (Tresorit, Proton Drive, Internxt, Nextcloud) dodają architekturę zero-knowledge. Wybór należy oprzeć na wrażliwości danych: dokumentacja medyczna i dane obronne wymagają dostawców suwerennych lub zero-knowledge; zwykłe dokumenty firmowe można przechowywać u hiperscalerów przy właściwej konfiguracji.
Szyfrowanie po stronie serwera a szyfrowanie po stronie klienta
Szyfrowanie po stronie serwera — AWS S3 SSE-KMS, Azure Storage Service Encryption, Google Cloud z kluczami zarządzanymi przez klienta — chroni przed fizyczną kradzieżą dysków, ale nie przed pracownikami dostawcy z dostępem do kluczy i nie przed przymusem prawnym wobec dostawcy. Szyfrowanie po stronie klienta z kluczami niedostępnymi dla dostawcy (XChaCha20-Poly1305 w Tresorit, AES-256-GCM z wyprowadzaniem kluczy PBKDF2-SHA-256 w HexaTransfer) zapewnia ochronę zero-knowledge. Dla danych wysokiej wrażliwości na mocy art. 9 (zdrowie, biometria, poglądy polityczne) szyfrowanie po stronie klienta jest domyślnie właściwym podejściem; samo szyfrowanie po stronie serwera jest graniczne.
Konfiguracja AWS S3 dla RODO
S3 nie jest domyślnie zgodne z RODO. Dla danych osobowych z UE należy ustawić region zasobnika na eu-central-1 (Frankfurt), eu-west-1 (Irlandia), eu-west-3 (Paryż) lub eu-south-1 (Mediolan). Należy włączyć domyślne szyfrowanie przez SSE-KMS z CMK zarządzanym przez klienta i rotacją kluczy. Należy zablokować publiczny dostęp na poziomie konta. Ustawić Object Lock dla niezmiennego przechowywania danych wymagającego prawnie uzasadnionego czasu przechowywania. Włączyć dzienniki dostępu S3 i AWS CloudTrail dla celów audytu. Używać endpointów VPC, by ruch nie przechodził przez publiczny internet. Wyłączyć S3 Transfer Acceleration, chyba że można udowodnić, że edge caches CloudFront pozostają w UE.
Odpowiedniki Azure i Google Cloud
Azure: wybrać West Europe (Amsterdam) lub North Europe (Dublin), włączyć Storage Service Encryption z kluczami zarządzanymi przez klienta przez Key Vault, skonfigurować Private Endpoints, ustawić Azure Policy odrzucającą wdrożenia poza UE i włączyć Microsoft Defender for Storage. Google Cloud: wybrać europe-west1 (Belgia), europe-west3 (Frankfurt) lub europe-west9 (Paryż), włączyć Customer-Managed Encryption Keys przez Cloud KMS, użyć VPC Service Controls do zapobiegania eksfiltracji i włączyć Cloud Audit Logs. Obaj hiperscalerzy publikują przewodniki konfiguracji specyficzne dla RODO; należy postępować dokładnie według nich.
Kontrola dostępu na mocy art. 32 ust. 1 lit. b
Dostęp oparty na rolach to punkt wyjścia. Każda tożsamość — ludzka lub usługi — powinna mieć minimalne uprawnienia ograniczone do konkretnego zasobnika, prefiksu lub folderu. MFA jest obowiązkowe dla dostępu przez konsolę i zalecane dla kluczy API przez tokeny sesji. Przepływy pracy joiner-mover-leaver zintegrowane z dostawcą tożsamości (Okta, Azure AD, Google Workspace) zapobiegają zalegającym dostępom. Kwartalne przeglądy dostępu wykrywają nadmiernie rozrośnięte uprawnienia. Dla plików wysoce wrażliwych dostęp awaryjny z podwójnym zatwierdzeniem i automatycznym wygasaniem podwyższonych uprawnień po 4-8 godzinach ogranicza szkody wynikające z przejęcia kont administratorów.
Polityki przechowywania dopasowane do celu
Artykuł 5 ust. 1 lit. e (ograniczenie przechowywania) zmusza do usuwania danych po wygaśnięciu celu przetwarzania. Przechowywanie w chmurze czyni bezterminowe przechowywanie kuszącym — storage jest tani. Należy budować polityki cyklu życia wymuszające przechowywanie zgodne z celem: 30 dni dla stref przesyłania, 13 miesięcy dla załączników obsługi klienta, 7 lat dla faktur (prawo podatkowe), 10 lat dla dokumentacji medycznej w niektórych jurysdykcjach. Reguły S3 Lifecycle, Azure Blob Lifecycle Management i GCS Object Lifecycle automatyzują ten proces. Należy łączyć z Object Lock dla zgodności WORM tam, gdzie prawnie wymagane jest niezmienne przechowywanie.
Zarządzanie kluczami szyfrowania
Klucze są centrum ciężkości. Posiadacz klucza posiada dane. Zgodnie z RODO, custody kluczy decyduje, czy dostawca przechowywania jest podmiotem przetwarzającym (może odszyfrować) czy wyłącznie kanałem danych (przechowuje szyfrogramy). Dla scenariuszy zarządzanych przez serwer należy używać magazynów kluczy opartych na HSM (AWS KMS, Azure Key Vault Managed HSM, Google Cloud HSM). Dla zero-knowledge należy wyprowadzać klucze w przeglądarce przez Web Crypto API (PBKDF2 lub Argon2id z libsodium crypto_pwhash) i nigdy ich nie przesyłać. Klucze należy rotować rocznie lub gdy personel posiadający dostęp odchodzi z organizacji. Custody kluczy należy dokumentować w RoPA na mocy art. 30.
Szyfrowanie kopii zapasowych i rezydencja
Kopie zapasowe często psują narrację o rezydencji i szyfrowaniu. Zasobnik w eu-central-1 z regułą replikacji cross-region do us-east-1 „dla niezawodności" właśnie przeniósł każdy plik do USA bez aktualizacji DPA. Należy sprawdzić konfiguracje CRR i ustawiać miejsca docelowe w EOG — eu-west-1 (Irlandia) i eu-central-1 (Frankfurt) tworzą naturalna parę. Kopie zapasowe należy szyfrować osobnym kluczem niż główne przechowywanie, by naruszenie jednego klucza nie ujawniało obu kopii. Odtwarzanie należy testować kwartalnie; nieodtwarzalna kopia zapasowa jest gorsza niż jej brak.
Wykrywanie naruszeń mieszczące się w 72 godzinach
72-godzinny zegar z art. 33 startuje, gdy administrator „dowie się" o naruszeniu. Narzędzia detekcji skracają lukę między naruszeniem a świadomością. CloudTrail i GuardDuty na AWS, Microsoft Defender for Cloud na Azure i Security Command Center Premium na GCP sygnalizują nietypowe wzorce dostępu — masowe pobieranie, dostęp z nowych lokalizacji, klucze używane poza godzinami pracy. Alerty należy kierować do całodobowego SOC lub przynajmniej do dyżurującego on-call. Dla mniejszych organizacji zarządzane usługi wykrywania i reagowania (Arctic Wolf, Red Canary) wypełniają tę lukę. Należy udokumentować procedurę: kto powiadamia organ nadzorczy, kto sporządza formularz z art. 33, kto komunikuje się z podmiotami danych na mocy art. 34.
Lista kontrolna oceny dostawcy
Przed podpisaniem umowy z dostawcą chmury należy żądać: (1) DPA zgodnej z art. 28 obejmującej wszystkie osiem kwestii; (2) certyfikatu ISO 27001 z oświadczeniem o zakresie; (3) raportu SOC 2 Type 2 (SOC 2 Type 1 jest niewystarczający — testuje projekt, nie działanie); (4) zobowiązania do rezydencji danych w UE z wymienionymi centrami danych; (5) rejestru podwykonawców z jurysdykcjami; (6) opublikowanego terminu powiadomienia o naruszeniu (preferowane ≤24 godziny); (7) dokumentacji szyfrowania wraz z zarządzaniem kluczami; (8) praw do audytu na mocy art. 28 ust. 3 lit. h. HexaTransfer publikuje wszystkie osiem punktów na swojej stronie zaufania; renomowane alternatywy (Tresorit, Proton, Infomaniak) postępują podobnie.
Stronę zaufania dostawcy należy traktować jak umowę — jej brak oznacza, że dostawca nie podchodzi poważnie do tematu. Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.
Wysyłaj duże pliki bezpiecznie z szyfrowaniem end-to-end
Przesyłaj pliki do 10 GB za darmo z szyfrowaniem end-to-end. Bez rejestracji. Twoje pliki są szyfrowane w przeglądarce przed przesłaniem — nikt inny nie może ich odczytać.
Wyślij plik