Załóż, że serwery są przejęte

Zanim wpis w ogóle trafi do magazynu, jego payload jest szyfrowany kluczem symetrycznym (AES-256-GCM). To szyfrowanie należy do modelu danych, nie do transportu. Serwer, który przechowuje wpisy, nie przeczyta ich treści — widzi tylko zaszyfrowane bajty.

Odpowiadając na żądanie synchronizacji, serwer zawija payloady wpisów w dodatkową warstwę szyfrowania RSA, kluczem publicznym pytającego użytkownika. Nawet kto przechwyci odpowiedź HTTP, nie odszyfruje jej bez prywatnego klucza RSA odbiorcy.

Cała komunikacja idzie po TLS. Chroni to metadane (identyfikatory wpisów, znaczniki czasu, parametry żądań), których warstwy payloadu nie obejmują. Razem te trzy warstwy zabezpieczają dane w spoczynku, w drodze i na łączu.

Wszystkie dokumenty są szyfrowane domyślnym kluczem AES-256 tenanta, o ile nie podano innego. Każdy zarejestrowany użytkownik dostaje ten klucz przy dołączaniu. Dobry do ogólnych danych w całym tenancie.

Do wrażliwych dokumentów utwórz nazwany klucz szyfrujący i udostępnij go tylko uprawnionym użytkownikom. Klucze rozprowadza się poza systemem (zaszyfrowany klucz mailem, hasło przez telefon albo osobiście) albo przez politykę, bez wglądu administratora: ten, kto klucz już ma, pakuje go dla każdego odbiorcy jego osobistym kluczem publicznym (RSA), więc administrator rozsyła go, nigdy go nie czytając. Odszyfruje je tylko ten, kto ma klucz.

Specjalny klucz, który szyfruje wyłącznie wpisy kontroli dostępu w katalogu (rejestracje użytkowników, odwołania, grupy). Serwery sprawdzają nim, którym kluczom podpisującym można zaufać — nie widząc nazw użytkowników ani danych biznesowych. Nazwy użytkowników leżą jako skróty SHA-256; prawdziwe nazwy są zaszyfrowane kluczem RSA administratora.

Każda sesja synchronizacji zaczyna się uzgodnieniem challenge-response:

• Klient wysyła serwerowi swój publiczny klucz podpisujący
• Serwer wyszukuje klucz w katalogu i wysyła losowe wyzwanie
• Klient podpisuje wyzwanie swoim kluczem prywatnym
• Serwer sprawdza podpis, kontroluje status odwołania i wystawia krótkotrwały token JWT

Żadnych haseł ani baz sesji na serwerze. Użytkownik z odwołanym dostępem nie zacznie nawet procedury uwierzytelniania.

Nowi użytkownicy dołączają w trzech krokach, w których klucze prywatne nigdy nie opuszczają urządzenia:

• Prośba o dołączenie — Nowy użytkownik generuje klucze lokalnie i tworzy prośbę zawierającą wyłącznie klucze publiczne. Można ją bezpiecznie przesłać dowolnym kanałem.
• Zatwierdzenie przez administratora — Administrator rejestruje użytkownika w katalogu i szyfruje klucze symetryczne jednorazowym hasłem udostępnienia.
• Wymiana dwoma kanałami — Odpowiedź na prośbę idzie mailem lub czatem; hasło udostępnienia przekazuje się osobno przez telefon albo osobiście.

• Podpisy: Ed25519 (bezpieczeństwo 128-bitowe, krzywa eliptyczna)
• Szyfrowanie payloadu: AES-256-GCM (bezpieczeństwo 256-bitowe)
• Szyfrowanie transportu: RSA-OAEP z SHA-256 (klucze 3072-bitowe)
• Wyprowadzanie kluczy: PBKDF2 z osobną solą dla każdego typu klucza
• Podpisywanie tokenów: HMAC-SHA256
• Hashowanie: SHA-256 (adresowanie treścią, ochrona nazw użytkowników)

• Poufność: szyfrowanie AES-256-GCM — przeczyta tylko ten, kto ma klucz
• Autentyczność: podpisy Ed25519 — dowodzą, kto utworzył każdą zmianę
• Integralność: łańcuch skrótów — manipulacja rozrywa łańcuch i jest wykrywalna w każdym punkcie
• Niezaprzeczalność: podpisów nie da się podrobić — autorstwo jest dowodliwe
• Prywatność: nazwy użytkowników zahaszowane i zaszyfrowane — serwer nie zidentyfikuje użytkowników

• Włamanie na serwer — Atakujący dostaje tylko szyfrogram i klucze publiczne. Żadnego tekstu jawnego, żadnych kluczy prywatnych, żadnych nazw użytkowników.
• Podsłuch w sieci — Trzy warstwy szyfrowania chronią dane nawet wtedy, gdy TLS zostanie przełamany.
• Nieuprawnione zmiany — Każda zmiana jest podpisana; zmiany niepodpisane albo źle podpisane są odrzucane.
• Manipulacja — Łańcuch skrótów sprawia, że każda modyfikacja jest wykrywalna.
• Dostęp odwołanego użytkownika — Odwołanie działa przy wyzwaniu i przy sprawdzaniu tokenu; blokuje synchronizację natychmiast.
• Podsłuch na relayu — Węzły relay przechowują i przekazują dalej zaszyfrowane wpisy, których nie potrafią odszyfrować.

Treść payloadu jest zawsze zaszyfrowana, ale część metadanych serwer widzi z założenia. To świadomy kompromis: protokół synchronizacji potrzebuje metadanych, żeby uzgadniać wpisy.

• Widoczne: znaczniki czasu wpisów, skróty treści, struktura dokumentu (ile wpisów na dokument), wzorce dostępu (kiedy użytkownicy się synchronizują)
• Niewidoczne: treść dokumentów, nazwy użytkowników, klucze szyfrujące, treść załączników

Skróty treści zdradzają, że dwa wpisy zawierają identyczne zaszyfrowane dane (na potrzeby deduplikacji). To przyjęty kompromis na rzecz oszczędności miejsca.

Odwołanie użytkownika blokuje każdą dalszą synchronizację i odrzuca jego przyszłe zmiany. Dane już zsynchronizowane na jego urządzeniu pozostają jednak dostępne — żaden system nie zagwarantuje usunięcia na urządzeniu, które nigdy się nie połączy. Środek zaradczy: używaj nazwanych kluczy do wrażliwych dokumentów (mniejszy promień rażenia) i rotuj klucze, gdy ktoś odchodzi. Haven Enterprise dodaje do tych samych polityk nadzoru podpisane przez administratora zdalne czyszczenie urządzenia: tenant zostaje usunięty ze skradzionego lub porzuconego urządzenia przy jego następnym połączeniu.

Wiele kluczy na użytkownika (podpisujący, szyfrujący, nazwane klucze symetryczne) trzeba bezpiecznie rozdystrybuować. Środek zaradczy: jedno hasło odblokowuje wszystkie klucze przez PBKDF2 z różnymi solami. KeyBag daje jednolity magazyn kluczy. Wymianę kluczy dla nowych użytkowników obsługuje przebieg prośby o dołączenie i odpowiedzi. Haven Enterprise automatyzuje bieżącą pracę: podpisane przez administratora polityki dystrybucji kluczy przydzielają klucze użytkownikom i grupom — i odbierają je z powrotem — zapakowane osobno dla każdego odbiorcy, a każdy klient uzgadnia swój KeyBag przy następnej synchronizacji.

Domyślnie serwer nie może odpytywać treści dokumentów, bo widzi tylko szyfrogram. Całe odpytywanie dzieje się na kliencie, przez przyrostowe indeksowanie. Jeśli jednak Twój przypadek wymaga przetwarzania po stronie serwera (na przykład system rezerwacji online albo publiczna witryna), możesz dać procesowi serwera klucz deszyfrujący albo udostępnić mu wycinek danych. To świadoma decyzja architektoniczna dla każdego wdrożenia — domyślnie obowiązuje poufność, a dostęp serwera włącza się tam, gdzie jest potrzebny.

Pełny audyt bezpieczeństwa wskazał obszary do wzmocnienia: ograniczanie liczby żądań na endpointach, odwoływanie tokenów JWT i rotację klucza administratora. Antydatowanym zmianom od użytkowników z odwołanym dostępem zapobiegają już poświadczenia świadka z zaufanym czasem (zobacz model kontroli dostępu). Fundament kryptograficzny (Ed25519, AES-256-GCM, RSA-OAEP) jest solidny. Wzmacnianie strony operacyjnej trwa.