Dane w chmurze: szyfrowanie, posiadacze kluczy i linki do udostępniania

Dostawca chmury niemal zawsze powie ci, że twoje dane są szyfrowane, i zwykle jest to prawda. Samo w sobie jest to jednak dość słabe stwierdzenie, ponieważ pomija szczegół, który decyduje o tym, kto faktycznie może odczytać te dane, jeśli zostanie do tego zmuszony, zaatakowany albo po prostu będzie ciekawy: kto posiada klucz.

Szyfrowanie w spoczynku i w tranzycie, domyślnie

Dokumentacja Google Cloud opisuje to, co domyślnie robi większość większych dostawców: „Wszystkie dane przechowywane przez Google są szyfrowane na warstwie magazynu przy użyciu algorytmu Advanced Encryption Standard (AES), AES-256”, stosowanego automatycznie, bez wymaganej konfiguracji ze strony klienta. Dane w tranzycie między twoim urządzeniem a dostawcą są osobno chronione przez TLS, omówione w kursie o kryptografii w tym uniwersytecie. Ten podstawowy poziom jest naprawdę użyteczny — chroni na przykład przed fizyczną kradzieżą dysku twardego z centrum danych — ale odpowiada tylko na część pytania.

To, kto posiada klucz, zmienia sens ochrony

Domyślnie Google Cloud stwierdza wprost: „posiadamy i zarządzamy kluczami używanymi w domyślnym szyfrowaniu w spoczynku”. To standardowa praktyka w całej branży i właśnie dlatego to domyślne ustawienie chroni cię przed fizyczną kradzieżą lub zewnętrznym atakującym, ale nie przed samym dostawcą: jeśli dostawca posiada klucz, technicznie może uzyskać dostęp do danych, podobnie jak każdy, kto prawnie zmusi go do tego. Dostawcy oferują też opcje kluczy zarządzanych przez klienta, dla organizacji, które muszą posiadać własne klucze, choć wiąże się to z realną złożonością operacyjną — utrata własnego klucza bez zapasowego rozwiązania po stronie dostawcy może oznaczać trwałą utratę danych.

Opcje szyfrowania end-to-end: tylko klient posiada klucz

Mniejsza liczba funkcji skierowanych do konsumentów idzie dalej niż szyfrowanie w spoczynku zarządzane przez dostawcę, rozciągając prawdziwe szyfrowanie end-to-end (gwarancję omówioną w kursie o kryptografii) na samo przechowywanie w chmurze. Udokumentowanym przykładem jest funkcja Advanced Data Protection dla iCloud od Apple: gdy jest włączona, rozciąga szyfrowanie end-to-end na iCloud Backup, Zdjęcia, Notatki, iCloud Drive i więcej, a Apple stwierdza, że „twoje zaufane urządzenia zachowują wyłączny dostęp do kluczy szyfrujących dla większości twoich danych iCloud” — co oznacza, że sam Apple nie może ich odszyfrować, nawet pod przymusem prawnym, i mówi to wprost: „Nikt inny nie ma dostępu do twoich danych zaszyfrowanych end-to-end — nawet Apple”. Kompromis, który Apple opisuje obok tego, jest realny: ponieważ Apple nie posiada klucza, nie może też pomóc odzyskać tych danych, jeśli stracisz dostęp i wcześniej nie ustawiłeś osoby kontaktowej do odzyskiwania ani klucza odzyskiwania. Silna ochrona i łatwe odzyskiwanie konta ciągną w przeciwnych kierunkach, a Advanced Data Protection prosi cię o wybór.

Linki do udostępniania: cichy sposób, w jaki dane opuszczają powyższy model

Wszystko powyższe może zostać cofnięte przez jedno nieostrożne udostępnienie. Ustawienie „każdy z linkiem może zobaczyć” w dokumencie w chmurze zamienia silne szyfrowanie w spoczynku w coś bliższego publicznej stronie internetowej: sam link staje się jedyną rzeczą stojącą między twoimi danymi a każdym, kto go otrzyma, prześle dalej albo odgadnie. Ma to większe znaczenie, niż mogłoby się wydawać, ponieważ takie linki są trywialnie łatwe do przesłania dalej poza zamierzonego odbiorcę, często trafiają do indeksów lub pamięci podręcznej w nieoczekiwanych miejscach i rzadko wygasają same. Zanim udostępnisz cokolwiek wrażliwego, warto sprawdzić, czy link można ograniczyć do konkretnych osób, które muszą być już zalogowane, nadać mu datę wygaśnięcia i cofnąć go, gdy nie jest już potrzebny — opcje, które oferuje większość większych dostawców, ale nie włącza ich domyślnie.