Szyfrowanie w S3: SSE-S3, SSE-KMS i SSE-C

Blog WebDisk · kategoria: Bezpieczeństwo · czas czytania: ~12 minut

W skrócie:- SSE-S3 – kluczami zarządza magazyn obiektów; włączasz i zapominasz.- SSE-KMS – klucze żyją w zewnętrznym sejfie (KMS); zyskujesz audyt, rotację i separację uprawnień.- SSE-C – klucz podajesz przy każdym żądaniu, serwer go nie przechowuje; maksimum kontroli i pełna odpowiedzialność. >Nie pracujesz z terminalem? Możesz spokojnie pominąć przykłady kodu – tabela porównawcza i sekcja o WebDisk Files i Send dają pełny obraz.

Gdy wgrywasz plik do chmury, w tle dzieje się coś, o czym rzadko myślimy: Twoje dane lądują na fizycznych dyskach w czyjejś serwerowni. Co się stanie, jeśli taki dysk zostanie wymieniony w ramach serwisu i opuści serwerownię? Albo jeśli kopia zapasowa trafi w niepowołane ręce? Odpowiedzią na te pytania jest szyfrowanie danych w spoczynku (encryption at rest) – a w świecie protokołu S3, którym mówi także nasza platforma, ma ono trzy standardowe warianty: SSE-S3, SSE-KMS i SSE-C.

Różnią się one jednym, ale fundamentalnym szczegółem: tym, kto generuje, przechowuje i kontroluje klucz szyfrujący. W tym artykule wyjaśniamy, jak działa każdy z wariantów, pokazujemy na przykładach, jak użyć ich samodzielnie, i opisujemy, jak wykorzystujemy je w praktyce w usługach WebDisk Files i WebDisk Send.

Dwa różne problemy: dane w drodze i dane w spoczynku

Zanim przejdziemy do SSE, uporządkujmy pojęcia, bo „szyfrowanie” bywa workiem, do którego wrzuca się różne rzeczy:

Szyfrowanie w tranzycie chroni dane w drodze między Tobą a serwerem. To zadanie TLS – tej samej technologii, która stoi za kłódką w przeglądarce. Bez TLS ktoś podsłuchujący sieć (np. w otwartym Wi-Fi) mógłby przechwycić przesyłany plik.
Szyfrowanie w spoczynku chroni dane leżące na dyskach. Nawet jeśli ktoś fizycznie wejdzie w posiadanie nośnika lub surowych plików z serwera, zobaczy tylko kryptograficzny szum.

Te mechanizmy się uzupełniają, a nie zastępują. Cała komunikacja z usługami WebDisk zawsze idzie po TLS – to warstwa obowiązkowa. Szyfrowanie w spoczynku to warstwa druga i o niej jest ten artykuł.

Server-Side Encryption (SSE) oznacza, że szyfrowaniem zajmuje się serwer: dane przyjeżdżają po TLS, serwer szyfruje je przed zapisem na dysk, a przy pobieraniu odszyfrowuje. Alternatywą jest szyfrowanie po stronie klienta (client-side / end-to-end), gdzie serwer od początku do końca widzi wyłącznie szyfrogram — zaszyfrowaną, nieczytelną postać danych. Wrócimy do tego rozróżnienia w FAQ, bo jest ważne dla uczciwej oceny gwarancji.

Jak serwer szyfruje: koperta w kopercie

Wszystkie trzy warianty szyfrują dane tym samym, sprawdzonym algorytmem: AES-256 – symetrycznym szyfrem blokowym, który przy poprawnej implementacji jest poza zasięgiem jakiegokolwiek znanego ataku siłowego. Naprawdę ciekawe jest to, co dzieje się z kluczami.

Dwa pierwsze warianty – SSE-S3 i SSE-KMS – korzystają z tzw. szyfrowania kopertowego (envelope encryption):

Każdy obiekt (plik) jest szyfrowany własnym, jednorazowym kluczem danych (DEK – data encryption key).
Klucz danych jest z kolei zaszyfrowany kluczem nadrzędnym (KEK – key encryption key) i dopiero w tej zaszyfrowanej postaci zapisany w metadanych obiektu.
Klucz nadrzędny nigdy nie leży obok danych – a to, gdzie żyje i kto nim zarządza, odróżnia SSE-S3 od SSE-KMS.

Dzięki kopercie kompromitacja jednego klucza danych odsłania jeden plik, a nie całe archiwum; rotacja klucza nadrzędnego nie wymaga też ponownego szyfrowania petabajtów danych – wystarczy przeszyfrować małe klucze danych.

SSE-C działa inaczej: klucz dostarczony przez klienta szyfruje obiekt bezpośrednio. Serwer nie generuje klucza danych i nie zapisuje żadnego opakowanego klucza – przechowuje wyłącznie skrót klucza, by przy kolejnych żądaniach sprawdzić, że podano ten sam klucz.

Z perspektywy użytkownika S3 wybór wariantu sprowadza się do nagłówków HTTP wysyłanych przy zapisie obiektu (PUT). Odczyt – poza SSE-C – jest przezroczysty: serwer sam rozpoznaje, że obiekt jest zaszyfrowany, i odszyfrowuje go przy pobieraniu, jeśli tylko masz prawo dostępu do obiektu (a w wariancie SSE-KMS – także prawo użycia klucza w KMS).

Zanim zaczniesz: konfiguracja klienta. Przykłady używają oficjalnego klienta aws CLI, który działa z każdym magazynem zgodnym z S3. Potrzebujesz pary kluczy dostępowych (access key + secret key) od swojego dostawcy – w usługach WebDisk znajdziesz je w panelu. Skonfiguruj je raz: >

aws configure # podaj access key i secret key (region: np. us-east-1)

Jeśli Twój magazyn nie jest w AWS, każde polecenie uzupełnij o endpoint dostawcy: >

aws --endpoint-url https://s3.twoj-dostawca.example s3 ls

Dla czytelności w dalszych przykładach pomijamy --endpoint-url – pamiętaj o nim, jeśli nie korzystasz z AWS.

SSE-S3 – serwer zarządza wszystkim

To wariant „włącz i zapomnij”. Klucze danych i klucz nadrzędny generuje, przechowuje i rotuje sam magazyn obiektów. Użytkownik nie widzi żadnego klucza – deklaruje tylko chęć szyfrowania.

Technicznie wystarczy jeden nagłówek przy zapisie:

x-amz-server-side-encryption: AES256

W praktyce rzadko dodaje się go ręcznie do każdego żądania. Wygodniejsze jest domyślne szyfrowanie bucketa (bucket to kontener na obiekty w S3 – odpowiednik dysku czy udziału; w usługach WebDisk nazywamy go magazynem). Od momentu włączenia każdy nowo zapisany obiekt jest szyfrowany automatycznie, niezależnie od tego, czy klient o to poprosił. Tak zresztą działa dziś AWS – od stycznia 2023 wszystkie nowe obiekty w S3 są tam domyślnie szyfrowane SSE-S3. W Ceph RGW (silniku naszej platformy) domyślne szyfrowanie bucketa konfiguruje się identycznym wywołaniem API.

# pojedynczy plik z jawnym żądaniem szyfrowania
aws s3 cp raport.pdf s3://moj-bucket/ --sse AES256

# albo raz na zawsze: domyślne szyfrowanie całego bucketa
aws s3api put-bucket-encryption --bucket moj-bucket \
--server-side-encryption-configuration \
'{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

# weryfikacja: czy obiekt jest zaszyfrowany?
aws s3api head-object --bucket moj-bucket --key raport.pdf
# w odpowiedzi: "ServerSideEncryption": "AES256"

Co daje SSE-S3: ochronę przed scenariuszami „fizycznymi” – wyniesiony dysk, nośnik po awarii, surowe pliki skopiowane z systemu plików serwera są bezużyteczne.

Czego nie daje: ochrony przed kompromitacją konta. Kto ma prawo odczytu obiektu, ten dostaje go odszyfrowanego – serwer robi to automatycznie. Skradzione klucze API oznaczają dostęp do czytelnych danych, dokładnie tak samo jak bez szyfrowania. To nie wada implementacji, tylko granica modelu: SSE-S3 chroni nośniki, nie konto.

SSE-KMS – klucze wyprowadzone do sejfu

SSE-KMS działa jak SSE-S3, ale klucz nadrzędny nie należy już do magazynu obiektów, tylko do zewnętrznej usługi zarządzania kluczami (KMS – Key Management Service). Magazyn obiektów musi przy każdej operacji poprosić KMS o odszyfrowanie klucza danych – i tu pojawiają się trzy praktyczne korzyści:

Separacja uprawnień. Dostęp do obiektu i dostęp do klucza to dwie niezależne decyzje. Można odebrać prawo użycia klucza – i dane stają się nieczytelne, nawet dla kogoś, kto wciąż ma dostęp do bucketa.
Audyt. Każde użycie klucza zostawia ślad w logach KMS: kto, kiedy, do czego. Dla zgodności (RODO, ISO 27001) to często wymóg twardy.
Cykl życia klucza. Rotacja, wyłączenie, unieważnienie – zarządzane centralnie, per klucz, bez dotykania danych. Wiele wdrożeń KMS pozwala też przynieść własny materiał klucza (BYOK – bring your own key).

Przy zapisie deklaruje się wariant aws:kms i opcjonalnie identyfikator klucza:

x-amz-server-side-encryption: aws:kms
x-amz-server-side-encryption-aws-kms-key-id: <identyfikator-klucza>

# w AWS najpierw tworzysz klucz w usłudze KMS i nadajesz mu alias
aws kms create-key --description "Klucz do dokumentow firmowych"
aws kms create-alias --alias-name alias/moj-klucz-firmowy \
--target-key-id <KeyId-z-poprzedniego-polecenia>

# upload z SSE-KMS wskazujący konkretny klucz
aws s3 cp raport.pdf s3://moj-bucket/ \
--sse aws:kms --sse-kms-key-id alias/moj-klucz-firmowy

W AWS rolę KMS pełni usługa AWS KMS. W świecie Ceph RGW backendem KMS może być m.in. HashiCorp Vault lub jego otwarty fork OpenBao – i to jest droga, którą wybraliśmy w WebDisk: klucze szyfrujące żyją w osobnym, odseparowanym sejfie kryptograficznym, a serwery obiektowe pobierają je na żądanie, przez uwierzytelniony kanał, bez zapisywania ich na dysku obok danych. Identyfikator klucza z nagłówka odpowiada wtedy nazwie klucza w sejfie.

W usługach WebDisk SSE-KMS pracuje „pod maską” platformy – nie jest opcją, którą klikasz samodzielnie. Wybory, które oddajemy wprost w ręce użytkownika, to SSE-S3 (szyfrowane magazyny w Files) i SSE-C (klucz organizacji w Files) – więcej o obu za chwilę.

Kompromis: SSE-KMS to dodatkowa ruchoma część (KMS musi być dostępny, żeby dane dało się czytać) i narzut na komunikację z sejfem. W zamian dostajemy audyt, centralne zarządzanie i możliwość „odcięcia” danych jednym ruchem.

SSE-C – Ty przynosisz klucz

Trzeci wariant odwraca role: klucz generuje i przechowuje klient, a serwer tylko wykonuje szyfrowanie. Przy każdym żądaniu – zapisie i odczycie – klient przesyła swój 256-bitowy klucz w nagłówkach:

x-amz-server-side-encryption-customer-algorithm: AES256
x-amz-server-side-encryption-customer-key: <klucz zakodowany base64>
x-amz-server-side-encryption-customer-key-MD5: <suma MD5 klucza, base64>

Serwer używa klucza do zaszyfrowania obiektu, po czym klucz odrzuca – nie zapisuje go nigdzie. Zapamiętuje jedynie kryptograficzny odcisk klucza (AWS S3 — losowo solony HMAC, Ceph RGW – sumę MD5 klucza): wystarczający, by przy kolejnych żądaniach rozpoznać, że podano ten sam klucz, ale bezużyteczny do jego odtworzenia.

Konsekwencje są poważne i trzeba je rozumieć przed użyciem:

Utrata klucza = utrata danych. Nieodwołalnie. Dostawca nie ma żadnej kopii i żadnej procedury odzyskiwania – to nie deklaracja marketingowa, tylko właściwość konstrukcji.
TLS jest obowiązkowy. Klucz wędruje w nagłówku HTTP, więc serwer odrzuca żądania SSE-C przychodzące bez szyfrowanego połączenia (w Ceph RGW pilnuje tego opcja rgw_crypt_require_ssl, domyślnie włączona).
Zwykłe linki przestają wystarczać. Większość mechanizmów udostępniania plików z S3 opiera się na tzw. presigned URL – linku z wbudowanym, czasowo ograniczonym podpisem uprawnień, dzięki któremu można pobrać obiekt bez logowania. Presigned URL podpisuje żądanie, ale nagłówków z kluczem nie przemyci — pobierający i tak musi znać klucz. Przeglądarka, która dostała sam link, nie pobierze obiektu SSE-C. Aplikacje muszą ten przypadek obsłużyć osobno (za chwilę pokażemy, jak robi to Files).

Przykład od zera, z użyciem openssl i aws CLI:

# 1. wygeneruj 32-bajtowy (256-bitowy) klucz i schowaj go w bezpiecznym miejscu
openssl rand -out sse-c.key 32

# 2. upload z SSE-C
aws s3 cp tajne.pdf s3://moj-bucket/tajne.pdf \
--sse-c AES256 --sse-c-key fileb://sse-c.key

# 3. download — wymaga TEGO SAMEGO klucza
aws s3 cp s3://moj-bucket/tajne.pdf pobrane.pdf \
--sse-c AES256 --sse-c-key fileb://sse-c.key

# 4. próba pobrania bez klucza kończy się błędem 400
aws s3 cp s3://moj-bucket/tajne.pdf test.pdf

Uwaga dla użytkowników AWS S3: od kwietnia 2026 nowe buckety (oraz istniejące na kontach, które nie miały obiektów SSE-C) mają zapis SSE-C domyślnie zablokowany – upload z nagłówkami SSE-C zwróci błąd 403 AccessDenied. Odblokujesz go jednorazowo: >

aws s3api put-bucket-encryption --bucket moj-bucket \
--server-side-encryption-configuration \
'{"Rules":[{"BlockedEncryptionTypes":{"EncryptionType":["NONE"]}}]}'

Odczyt wcześniej zapisanych obiektów SSE-C działa bez zmian. Na magazynach Ceph RGW – w tym w usługach WebDisk – SSE-C działa od razu, bez tego kroku.

To samo programistycznie w Pythonie (boto3 samo zakoduje klucz w base64 i doliczy sumę MD5):

import boto3, os

s3 = boto3.client("s3", endpoint_url="https://s3.twoj-dostawca.example")

key = os.urandom(32) # 256-bitowy klucz — zapisz go bezpiecznie!

with open("tajne.pdf", "rb") as f:
    s3.put_object(
        Bucket="moj-bucket", Key="tajne.pdf", Body=f,
        SSECustomerAlgorithm="AES256",
        SSECustomerKey=key,
    )

obj = s3.get_object(
    Bucket="moj-bucket", Key="tajne.pdf",
    SSECustomerAlgorithm="AES256",
    SSECustomerKey=key,
)

Ważny niuans dla pełnej uczciwości: przy SSE-C serwer widzi klucz i treść pliku w trakcie obsługi żądania (w pamięci, na czas operacji) – nie widzi ich natomiast nigdy po jej zakończeniu. Jeśli wymaganiem jest, by serwer nie widział treści w żadnym momencie, potrzebne jest szyfrowanie po stronie klienta, nie SSE.

Trzy warianty w pigułce

Kto generuje klucz nadrzędny – SSE-S3: magazyn obiektów · SSE-KMS: usługa KMS · SSE-C: klient
Gdzie jest przechowywany – SSE-S3: wewnątrz magazynu · SSE-KMS: w KMS (sejf poza magazynem) · SSE-C: wyłącznie u klienta
Co przechowuje serwer – SSE-S3: wszystko · SSE-KMS: zaszyfrowane klucze danych · SSE-C: szyfrogram + skrót klucza
Utrata klucza po stronie klienta – SSE-S3: niemożliwa · SSE-KMS: niemożliwa · SSE-C: utrata danych
Audyt i rotacja kluczy – SSE-S3: wewnętrzna, automatyczna · SSE-KMS: centralna, widoczna, per klucz · SSE-C: w całości po stronie klienta
Wysiłek użytkownika – SSE-S3: zerowy · SSE-KMS: mały (zarządzanie kluczem w KMS) · SSE-C: duży (pełna odpowiedzialność)
Typowy scenariusz – SSE-S3: rozsądny domyślny standard · SSE-KMS: compliance, audyt, BYOK · SSE-C: maksimum kontroli nad kluczem Prosta zasada wyboru: SSE-S3, gdy chcesz po prostu mieć zaszyfrowane dane w spoczynku i nie zarządzać niczym; SSE-KMS, gdy audytor pyta „kto i kiedy użył klucza” albo polityka firmy wymaga kontroli cyklu życia kluczy; SSE-C, gdy klucz ma być wyłącznie w Twoich rękach – i jesteś gotów ponieść tego konsekwencje.

Jak to robimy w WebDisk: Files i Send

Teoria nabiera sensu, gdy widać ją w działającym produkcie. Nasze dwie usługi plikowe świadomie plasują się na dwóch końcach spektrum „prostota ↔ kontrola”.

WebDisk Files – warstwy do wyboru

Files to nasza platforma bezpiecznego przechowywania plików dla firm. Szyfrowanie jest w niej ułożone warstwowo, a dwa mechanizmy SSE z tego artykułu występują w rolach, do których pasują najlepiej:

SSE-S3 na poziomie magazynu. Przy zakładaniu dodatkowego magazynu (bucketa) można jednym przełącznikiem włączyć jego trwałe szyfrowanie. Od tej chwili każdy plik – wgrany z panelu, przez aplikację desktopową czy w ramach udostępniania – jest szyfrowany automatycznie, u źródła, przez domyślne szyfrowanie bucketa. Decyzja jest jednokierunkowa (magazynu nie da się „odszyfrować” przełącznikiem), użytkownik nie zarządza żadnym kluczem, a klucze nadrzędne nie leżą obok danych – żyją w wydzielonym sejfie kryptograficznym (OpenBao), z osobnym kluczem dla każdego magazynu.
SSE-C na poziomie organizacji. Organizacja może włączyć dodatkowe szyfrowanie wybranych plików i folderów mechanizmem SSE-C. Ważna różnica wobec samodzielnego SSE-C opisanego wyżej: kluczem nie zarządza tu użytkownik, lecz aplikacja Files w imieniu organizacji – przy włączeniu funkcji generowany jest 256-bitowy klucz organizacji, przechowywany przez aplikację w postaci zaszyfrowanej, poza warstwą magazynu obiektów. Dzięki temu magazyn obiektów nigdy nie utrwala klucza — wyniesiony nośnik ani kompromitacja samej warstwy przechowywania nie odsłaniają tych plików – a jednocześnie organizacja nie ponosi ryzyka nieodwracalnej utraty danych: scenariusz „zgubiłem klucz – dane stracone” dotyczy samodzielnego użycia SSE-C po API, nie tej funkcji. Uczciwie trzeba dodać: w tym modelu dostęp do klucza ma aplikacja – a więc technicznie także dostawca; jeśli wymaganiem jest, by dostawca nie mógł odczytać treści w żadnym momencie, właściwym narzędziem jest szyfrowanie po stronie klienta (patrz FAQ). Konsekwencje protokołu SSE-C aplikacja obsługuje sama: plików zaszyfrowanych nie da się pobrać zwykłym presigned URL (ten nie przenosi nagłówków z kluczem), więc Files serwuje je przez aplikację, strumieniując dane po zweryfikowaniu uprawnień. Obsługę SSE-C ma też nasza aplikacja desktopowa do synchronizacji folderów.
Warstwy komplementarne. Szyfrowanie chroni poufność, ale nie chroni przed nadpisaniem czy zaszyfrowaniem plików przez ransomware na komputerze użytkownika. Dlatego obok SSE Files oferuje wersjonowanie oraz tryb Anty-Ransomware oparty na S3 Object Lock w trybie Compliance – blokadę niemodyfikowalności egzekwowaną przez warstwę magazynu obiektów, odporną nawet na kompromitację samej aplikacji. Pełen obraz bezpieczeństwa to zawsze suma warstw, nie jeden mechanizm.

WebDisk Send – bezpieczeństwo bez instrukcji obsługi

Send rozwiązuje inny problem: „mam duży plik, chcę go komuś wysłać, już”. Projektując go, celowo nie przenieśliśmy opcji szyfrowania per plik z Files – bo usługa, której siłą jest brak konfiguracji, nie powinna zaczynać rozmowy od pytania o klucze.

Bezpieczeństwo Send opiera się na mechanizmach dopasowanych do scenariusza: transfer wyłącznie po TLS, opcjonalne hasło na link (kontroluje dostęp do pobrania – nie jest kluczem szyfrującym treść), limit pobrań i data wygaśnięcia, a przede wszystkim retencja – pliki żyją tyle, ile przewiduje plan, po czym są automatycznie i trwale usuwane. Najbezpieczniejszy plik to taki, którego już nie ma. Dane leżą przy tym na tej samej platformie obiektowej Ceph, którą opisaliśmy wyżej – z tym samym zapleczem operacyjnym.

Jeśli potrzebujesz szyfrowania sterowanego przez siebie – szyfrowanych magazynów, klucza organizacji, polityk retencji i blokad – to sygnał, że Twoim narzędziem jest Files, nie Send. Ten podział jest zamierzony.

Częste pytania

Czy szyfrowanie w spoczynku spowalnia upload i download? W praktyce nie. Współczesne procesory mają sprzętową obsługę AES (AES-NI), a szyfrowanie odbywa się strumieniowo. Przy SSE-KMS dochodzi krótka komunikacja z sejfem kluczy, pomijalna na tle transferu pliku.

Czy SSE-S3 chroni mnie, jeśli ktoś ukradnie moje hasło albo klucze API? Nie – i żaden wariant SSE nie ma takiego zadania. Serwer odszyfrowuje dane każdemu, kto ma ważne uprawnienia. Przed kradzieżą poświadczeń chronią silne hasła, MFA i higiena kluczy API; przed skutkami – wersjonowanie i Object Lock.

Zgubiłem klucz SSE-C. Co teraz? Nic. To nie jest scenariusz „skontaktuj się z pomocą techniczną” – serwer nie ma klucza, nie ma go dostawca, nie ma go nikt. Dane są kryptograficznie nie do odzyskania. Dlatego klucze SSE-C przechowuje się w menedżerze sekretów i obejmuje firmowymi procedurami (kopie, depozyt, sukcesja). Powyższe dotyczy samodzielnego użycia SSE-C przez API S3 – w usłudze Files kluczem SSE-C zarządza aplikacja w imieniu organizacji, więc ten scenariusz tam nie występuje.

Czym SSE różni się od szyfrowania end-to-end? W SSE szyfruje serwer – więc w chwili zapisu i odczytu widzi treść (a przy SSE-C także klucz) w pamięci operacyjnej. W szyfrowaniu klienckim (end-to-end) plik jest szyfrowany jeszcze na Twoim urządzeniu i serwer nigdy nie widzi ani treści, ani klucza – za cenę utraty funkcji wymagających treści po stronie serwera (podglądy, wyszukiwanie, ZIP folderu). To dwa różne punkty na osi zaufania; SSE-C jest najdalej wysuniętym wariantem po stronie serwerowej.

Po czym poznam, że obiekt jest zaszyfrowany? aws s3api head-object zwraca nagłówek x-amz-server-side-encryption (AES256 lub aws:kms) – to dobry, szybki audyt własnych bucketów. Uwaga na SSE-C: head-object na takim obiekcie bez podania klucza zwróci błąd 400 Bad Request — i właśnie ten błąd jest sygnałem, że obiekt jest zaszyfrowany kluczem klienta; nagłówek x-amz-server-side-encryption-customer-algorithm zobaczysz dopiero w odpowiedzi na żądanie z kluczem.

Używam rclone, nie aws CLI. Da się? Tak – rclone obsługuje wszystkie trzy warianty w konfiguracji zdalnego S3: server_side_encryption = AES256 (SSE-S3), server_side_encryption = aws:kms + sse_kms_key_id (SSE-KMS) albo sse_customer_algorithm = AES256 + sse_customer_key_base64 (SSE-C).

Podsumowanie

Szyfrowanie w spoczynku w S3 to nie jedna funkcja, tylko spektrum modeli zaufania:

SSE-S3 – serwer zarządza kluczami; zero wysiłku, ochrona nośników i kopii.
SSE-KMS – klucze w zewnętrznym sejfie; audyt, rotacja, separacja uprawnień.
SSE-C – klucz wyłącznie u Ciebie; maksimum kontroli, pełna odpowiedzialność.

W WebDisk używamy tych mechanizmów tam, gdzie mają sens: Files oddaje wybór w ręce administratora organizacji (szyfrowane magazyny SSE-S3, opcjonalne szyfrowanie SSE-C z kluczem organizacji zarządzanym przez aplikację), Send zdejmuje ten wybór z użytkownika i domyka bezpieczeństwo retencją i hasłami na linkach, a tam, gdzie szyfrowanie jest włączone, klucze żyją w osobnym sejfie – nie obok danych.

Chcesz sprawdzić to w praktyce? Załóż darmowe konto w WebDisk Send albo przetestuj WebDisk Files – a jeśli masz pytania o szyfrowanie w swojej organizacji, napisz do nas.

Artykuł jest częścią cyklu o bezpieczeństwie danych w usługach WebDisk. Wszystkie przykłady wykonasz na dowolnym magazynie zgodnym z S3 (na AWS S3 przykład SSE-C wymaga jednorazowego odblokowania – patrz ramka w sekcji o SSE-C); parametr --endpoint-url w aws CLI wskazuje na endpoint Twojego dostawcy.

Szyfrowanie w S3: SSE-S3, SSE-KMS i SSE-C – kto trzyma klucz do Twoich plików?