Szyfrowanie Rest

Szyfrowanie podczas odpoczynku

1) Dlaczego jest potrzebny i co dokładnie chronimy

Definicja. Szyfrowanie w spoczynku to ochrona danych zapisanych na nośnikach (dyski, migawki, kopie zapasowe, obiekty, dzienniki, porzucanie pamięci), tak aby nieautoryzowany dostęp do mediów fizycznych lub do „surowego” przechowywania nie ujawniał treści.

• Woluminy bloków/plików, magazynów obiektów, baz danych, kolejek/caveles, dumps cache, logs/trails, backups, export/import, VM/container snapshots, kernel/process dumps, swap/swap.
• Scenariusze wielopoziomowe: izolacja klientów/projektów/środowisk.

To, co nie w pełni pokrywamy: kradzież sesji w pamięci, ataki na żywo, luki w aplikacji, kompromis poświadczeń. Wymaga to szyfrowania podczas lotu, silnego uwierzytelniania/autoryzacji, minimalizacji praw i monitorowania (patrz artykuły powiązane: „Uwierzytelnianie i autoryzowanie”, „Podpisywanie i weryfikacja żądań”).

2) Model zagrożenia i cele kontroli

• Utrata/kradzież nośnika (dysk, taśma, USB, urządzenie programistyczne).
• Nieautoryzowany dostęp do kopii zapasowych/migawek/dzienników.
• Nadużywanie uprawnień na poziomie platformy/hipervisor/węzła pamięci masowej.
• Przekraczanie lokatorów za błędy konfiguracyjne.
• „Zaśmiecone” tymczasowe pliki i porzucenia, które wpadają w artefakty i obrazy.

1. Poufność danych na nośniku.

2. Izolacja kryptograficzna najemców/środowisk.

3. Możliwość zarządzania kluczami (tworzenie, przechowywanie, rotacja, odwołanie).

4. Auditability (kto użył klucza i kiedy).

5. Minimalizacja ryzyka operacyjnego w przypadku incydentów.

3) Podstawy architektury

Wszystko szyfrujemy domyślnie. Opt-out nie jest dozwolony bez wyjątków na poziomie ryzyka.
Hierarchia kluczy (szyfrowanie koperty). Root/KEK → DEK (klucze szyfrowania danych) → obiekty bazy danych/pliki/strony.
KMS/HSM jako źródło zaufania. Generowanie i przechowywanie KEK w KMS/HSM, tam wykonywane są kluczowe operacje pakowania/wdrażania.
Klucze per-najemca/per-dataset. Ziarnistość dla potrzeb izolacji i rotacji.
Rozdzielenie obowiązków. Platforma poleca kluczem do właścicieli; uprawnienia minimalne (PoLP).
Kryptowaluta. Możliwość bezpiecznej migracji algorytmów/długości kluczy.
Rotacja jako proces, a nie wydarzenie. Klucze i dane muszą obsługiwać wymianę „toczenia”.

4) Algorytmy i tryby szyfrowania

Dla obiektów/plików/rekordów: AES-256-GCM lub AES-256-SIV (AEAD z uwierzytelnieniem).
Dla urządzeń/woluminów blokowych: AES-XTS-256/512 (ochrona przed permutacjami bloków; nie AEAD - używać ponad formatów plików z MAC, gdzie integralność jest ważna).

• TDE (Przezroczyste Szyfrowanie Danych) двивка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE ма.
• Kryptografia pola/linii (FPE/szyfrowanie deterministyczne) - funkcje wyszukiwania/joynes na szyfrowanych polach; nakładać ostrożnie.
• Generowanie i przechowywanie kluczy: KEK - w KMS/HSM; DEK - w pamięci aplikacji krótkotrwałe, podczas przechowywania - tylko owinięte.

5) Kluczowa hierarchia i KMS/HSM

1. Klucz główny (ustawowy, w HSM/KMS). Nie opuszczać obwodu HSM/KMS.

2. KEK (Key Encryption Key). Dla projektu/środowiska/najemcy. Zarządza cyklem życia DEK.

3. DEK (klucz szyfrowania danych). Na obiekt/plik/tabela/segment. Krótkotrwały, obracający się bez przerwy.

• Wszystkie operacje pakowania/wdrażania są za pośrednictwem interfejsu API KMS z audytem.
• Politycy: kto może „użyć” klucza i kto może „kontrolować” klucz.
• Kluczowy rozkład geograficzny: pin-to-region + podwójna kontrola międzyregionalna.
• Model „dwóch kontroli” (dwóch operatorów) jest możliwy w przypadku operacji wysokiego ryzyka.
• Aby wyizolować silny poziom - oddzielne klucze-pierścienie na najemcę.

6) Rotacja, wycofanie i zgodność

Rotacja DEK: przezroczysta i stała (ponowne szyfrowanie toczenia na poziomie obiektu/strony).
Rotacja KEK: okresowa (np. co 6-12 miesięcy) + natychmiastowe wycofanie, jeśli podejrzewa się narażenie.
Cofnięcie dostępu: poprzez politykę KMS; blokowanie operacji odblokowania = natychmiastowa „crypto-niszczalność” danych.
Dzienniki audytu: kto, kiedy, z jakimi prawami używali kluczy; przechowywać oddzielnie, a także szyfrować.
Przepisy i normy: skupiamy się na wymaganiach branżowych (na przykład RODO/zezwolenia PCI/lokalne regulatory), stosujemy certyfikowane moduły kryptograficzne (na przykład zgodność z poziomami certyfikacji).

7) Wzory według typu magazynu

7. 1 objętość bloku/pliku i VM/pojemniki

Pełne szyfrowanie dysku (XTS) + zarządzanie kluczem poprzez KMS (inicjalizacja głośności podczas montażu).
Chroń swap, porzucenia awarii, katalogi tmp, warstwy nakładki kontenera ,/obrazy AMI.
Migawki/migawki - zawsze zaszyfrowane oddzielnymi DEK.

7. 2 Przechowywanie obiektów

Szyfrowanie koperty: unikalny DEK na obiekt; nagłówki/metadane - brak przecieków PII.
Kontrola dostępu do klucza KMS przez najemców i środowiska.
Szyfrowanie po stronie serwera (SSE z własnym KMS) lub po stronie klienta (CSE) - wybierz według modelu zaufania.

7. 3 Bazy danych

Włącz TDE, jeśli jest dostępny; powiązać klucze bazy danych z KMS za pomocą wtyczki/rozszerzenia.
Dla szczególnie wrażliwych pól - szyfrowanie aplikacji (AEAD) przed wprowadzeniem bazy danych.
Redo dzienniki/dzienniki transakcji, dzienniki archiwów, dumps - szyfruj oddzielnie, klucze - oddzielne.

7. 4 kłody/szlaki/mierniki

Format dziennika - domyślnie bez danych wrażliwych (sanitarnych).
Archiwa dziennika - oddzielne klucze i krótka pamięć TTL.
Dostęp do dzienników czytania - poprzez usługę proxy z A&A i audytu.

7. 5 Kopie zapasowe i media offline

Zawsze szyfruj u klienta przed zapisem do taśmy/chmury.
Przechowywać klucze oddzielnie (poza pasmem), escrow z oddzielną kontrolą.
W przypadkach awaryjnych, dzielenie tajemnicy (na przykład m-of-n) w celu przywrócenia dostępu master.

8) Multi-najemca

Klucz do najemcy: KEK-per-najemca + DEK-per-dataset.
Izolacja polityk: obszary nazw KMS, granice IAM, poszczególne role IDP.
Usunięcie na życzenie klienta: „crypto-erase” - wycofać KEK najemcy i zniszczyć DEK.
Raportowanie klienta: artefakty zgodności, rejestry dostępu klucza, potwierdzenie rotacji.

9) Wydajność i działanie

Przyspieszenia sprzętowe (AES-NI/x86, ARMv8 rozszerzenia Crypto).
Profilowanie gorącej ścieżki: szyfrować na granicach I/O, unikać podwójnego szyfrowania niepotrzebnie.
Baseny sesji KMS, buforowanie zapakowanych DEK w pamięć (z TTL i zabezpieczeniem przed zrzutami).
SLO/metryki: odblokowanie opóźnienia, odsetek „ponownie zaszyfrowanych” obiektów, błędy KMS, prędkość szyfrowania kopii zapasowych.

10) Księga odniesienia

Krok 0 - Spis danych. Katalog wszystkich repozytoriów i ścieżek wycieków (tmp, dumps, eksport, wiadra analityczne).
Krok 1 - projekt hierarchii kluczy. Określamy poziomy KEK/DEK, granularność, regiony, role.
Krok 2 - wybierz tryby/biblioteki. Zatwierdzone algorytmy, biblioteki kryptograficzne, zasady wersji.
Krok 3 - integracja z KMS/HSM. Generacja/pakowanie/audyt, polityka IAM, geosiatka.
Krok 4 - szyfrowanie na zapisze. Domyślnie włącz migrację istniejących danych poprzez ponowne szyfrowanie w tle.
Krok 5 - scenariusze rotacyjne i awaryjne. Przepisy, testy „kluczowy kompromis”, „KMS nie jest dostępny”.
Krok 6 - monitorowanie i audyt. Deski rozdzielcze, wpisy, regularne raporty zgodności.
Krok 7 - szkolenie i "bezpieczne kodowanie. "Przewodniki dla inżynierów, zakaz wyświetlania tajemnic w logach/dumpsach.

11) Badanie i weryfikacja

Testy jednostek kryptograficznych: poprawność AEAD (kontrola znacznika), walidacja awarii w przypadku zmiany bajtu.
Testy awaryjne: wyłączenie KMS, przestarzałe wersje kluczy, wymuszone odwołanie KEK.
Testy czerwono-niebieskie: próby odczytu „surowego” dysku/migawki/kopii zapasowej.
Kontrola zgodności: migracja algorytmów/długości kluczy (krypto-zwinność).
Poświadczenie biblioteki: używać tylko zweryfikowanych modułów kryptograficznych; wersje commit.

12) Częste błędy i jak ich uniknąć

Podwójne szyfrowanie bez znaczenia. Dodatkowe opóźnienia i złożoność. Trzymaj warstwę, która daje pożądaną ziarnistość i izolację.
Zapisz klucze obok danych. Klucze są zawsze oddzielne, w innym modelu dostępu.
Zapomniane artefakty. Niezaszyfrowane pliki tymczasowe, eksport CSV, wsparcie dumps. Włącz monitorowanie w CI/CD i zapobieganie utracie danych.
Brak rotacji. Wykonaj część obrotową rurociągu/korony, a nie procedurę ręczną.
Dzienniki z wrażliwymi danymi. Wprowadź umowę na format dziennika i automatyczne urządzenia sanitarne.

13) Mini przepisy (pseudokoda)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) Listy kontrolne

• Domyślne szyfrowanie jest włączone we wszystkich typach pamięci.
• Kluczowa hierarchia została opisana i wdrożona; Role i zasady IAM są skonfigurowane.
• Zintegrowane KMS/HSM, włączony audyt kluczowych operacji.
• Rotacja DEK/KEK jest zautomatyzowana; wypracowane kompromisowe scenariusze.
• Kopie zapasowe, migawki, dzienniki i porzucenia - zaszyfrowane; klucze są przechowywane oddzielnie.
• Konfigurowane wpisy dla błędów KMS, odchylenia znaczników AEAD, odsetek niezaszyfrowanych artefaktów.
• Przeszedł niedostępność KMS i kluczowe testy odwołania.

• Miesięczne sprawozdanie na temat kluczowych prób wykorzystania i dostępu.
• Plan crypto-zwinność i okno dla bezbolesnej migracji algorytmu.
• Okresowy czerwony zespół do ekstrakcji danych z surowych mediów.

15) PYTANIA I ODPOWIEDZI (FAQ)

P: Czy pełne szyfrowanie dysku jest wystarczające?
Odp.: Dla ryzyka fizycznego - tak, ale dla izolacji najemców i elastycznego obracania lepiej kopertę z DEK-on-object/set.

P: Co robić w przypadku kompromisu KEK?
Odp.: Natychmiast przypomnij sobie KEK do KMS, ponownie zwolnij nowy, wrap wszystkie DEK, sprawdź dzienniki i uruchom RCA.

P: Jak szyfrować pola, których szukamy?
Odp.: Stosowanie programów deterministycznych lub FPE tylko w rygorystycznej ocenie ryzyka (pory wzoru). Lepiej jest zaprojektować zapytania, aby pola wrażliwe nie wymagały indeksowanego otwartego widoku.

P: Czy potrzebuję oddzielnego polecenia dla kluczy?
Odp.: Operator Crypto/KMS jest zalecany jako rola z odrębnymi prawami i procedurami.

• „Kluczowe zarządzanie i rotacja”
• „Uwierzytelnianie S2S”
• „Podpisz i zweryfikuj żądania”
• „Podłącz OAuth2/OpenID w jądrze”
• „Webhook gwarancji dostawy”