Ochrona danych klasyfikowanych w bazach HSM

Architektura ochrony tajnych danych w bazach

Tajne dane, takie jak numery kart płatniczych (PAN) i dane osobowe (DO), wymagają ochrony przed wyciekami poprzez backupy baz danych i dostęp administratorów. Główne wyzwania: przechowywanie zaszyfrowanych danych z zachowaniem możliwości wyszukiwania, bezpieczne zarządzanie kluczami oraz minimalizacja ryzyka kompromitacji. Analiza wskazuje na rozdzielność PCI DSS dla PAN i 152-FZ/RODO dla DO ze względu na różnice w wymaganiach, w tym całkowite usuwanie danych na żądanie.

Numer karty nie jest absolutną tajemnicą: pierwsze 6–8 cyfr to BIN banku, ostatnia to suma kontrolna, pozostaje 7–9 cyfr do przebrnięcia (10–1000 mln wariantów na BIN). Przechowywanie hashów PAN z solą w bazie jest podatne na ataki GPU, jeśli sól jest dostępna.

Szyfrowanie danych i warianty HSM

HSM (Hardware Security Module) to urządzenie do bezpiecznego przechowywania kluczy i operacji kryptograficznych. Sprzętowy HSM fizycznie chroni klucz przed wyodrębnieniem, oprogramowaniowy — organizacyjnie poprzez kontrole dostępu.

Dla oprogramowaniowego HSM stosuje się schemat Shamira: klucz główny dzielony na N części, do odtworzenia potrzeba K z N (K < N). Przykład: 5 części, 3 do aktywacji. To kompromis — przeniesienie ryzyka na organizację, obniżenie kosztów.

Warianty wyszukiwania po zaszyfrowanych danych:

• TDE (Transparent Data Encryption): Szyfruje pliki na dysku, dane w pamięci są jawne. Chroni przed kradzieżą dysków, ale nie przed DBA.
• Hash z solą: Przechowywany jest hash PAN + sól z HSM, indeks po hashu. Sól nie w bazie, bo inaczej możliwy jest brute force.
• Deterministyczne szyfrowanie: Bez IV, ten sam plaintext — ten sam ciphertext. Możliwy indeks, ale podatne przy kompromitacji klucza.

Optymalnie: baza zawiera zaszyfrowany PAN, kryptohash i ID klucza (do rotacji). Wyszukiwanie po hashu, serwisy pracują tylko z hashami. PCI DSS ogranicza hash w obwodzie PAN, alternatywa — tokeny w oddzielnym magazynie.

Zarządzanie kluczami: Vault i jego ograniczenia

HashiCorp Vault, Azure Key Vault, AWS Secrets Manager nadają się do zarządzania sekretami, ale nie do kluczy kryptograficznych. Chronią przed:

• Commitami sekretów do git.
• Wyciekami env.
• Nieautoryzowanym odczytem.

Nie chronią przed:

• Adminem Vault.
• Adminem serwera (memory dump).
• Właścicielem certyfikatu mTLS.

Wzmocnienia: mTLS z kluczami sprzętowymi, limit zapytań, audyt. Vault to nie HSM. Azure Key Vault Premium używa HSM w centrach danych Microsoft, klucz nieeksportowalny, API do operacji.

Sekrety Kubernetes: ryzyka konteneryzacji

Sekrety Kubernetes przechowywane są w etcd jako base64 (nie zaszyfrowane). Dostęp do serwera API daje wszystkie sekrety. Kontenery podatne:

• Root-host czyta FS kontenera.
• nsenter do procesu.
• Memory dump.
• Ruch sieciowy.

Dla usług kryptograficznych niedopuszczalne. Wzmocnienia (gVisor, Kata Containers, Confidential Computing) możliwe, ale skomplikowane.

Rozwiązania chmurowe i model odpowiedzialności

Chmury (AWS, Azure) certyfikowane PCI DSS na poziomie infrastruktury (centra danych, szyfrowanie dysków), ale klient odpowiada za klucze i dostępy. W chmurze ruch po sieci wirtualnej, admin dostawcy może przechwycić. Rekomendacja: dedykowana usługa kryptograficzna z izolacją fizyczną (oddzielny kabel), w chmurze — izolowany HSM.

Konsensusowa architektura

• Dedykowana usługa kryptograficzna poza kontenerami, minimum interfejsów.
• Niewyodrębnialny klucz w HSM (sprzętowy/oprogramowaniowy/chmurowy).
• Schemat Shamira bez sprzętowego HSM.
• Kryptohash do wyszukiwania, sól z HSM.
• Rozdzielność PAN/DO.
• Pełny audyt.
• Rotacja kluczy.

Co ważne:

• Przechowywać sól/klucze poza bazą, używać HSM.
• Wyszukiwanie po kryptohashu lub tokenach, unikać deterministycznego szyfrowania.
• Organizacyjne kompromisy (Shamir) obniżają koszty.
• Vault do sekretów, HSM do kluczy.
• Rozdzielać PCI DSS i DO zgodnie z regulacjami.

— Editorial Team