Kto naprawdę ma klucz do dokumentów?
Zero-Knowledge nie oznacza, że system musi być zainstalowany na serwerze w kancelarii.
Ochrona zależy przede wszystkim od tego, kto posiada klucz pozwalający odczytać dokumenty.
W Bezpiecznej Kancelarii operator nie przechowuje stałego klucza do oryginalnych plików.
Agent AI uzyskuje dostęp w ramach aktywnej sesji użytkownika albo jednorazowego pozwolenia do konkretnego zadania.
Czy system dla kancelarii jest bezpieczny tylko wtedy, gdy działa na serwerze stojącym w jej własnym biurze? Nie. O bezpieczeństwie dokumentów nie rozstrzyga adres serwerowni. Znacznie ważniejsze jest to, kto posiada klucz pozwalający odczytać pliki.
Właśnie na tym polega architektura Zero-Knowledge. Dostawca może przechowywać zaszyfrowane dokumenty, wykonywać kopie zapasowe i zapewniać dostęp do systemu, a jednocześnie nie posiadać stałego klucza, którym mógłby samodzielnie otworzyć akta klienta.
Zero-Knowledge nie opisuje miejsca, w którym stoi serwer. Odpowiada na znacznie ważniejsze pytanie: kto ma klucz do dokumentów?
Co naprawdę oznacza Zero-Knowledge?
Pojęcie Zero-Knowledge ma ścisłe znaczenie w kryptografii. Oznacza możliwość potwierdzenia określonego faktu bez ujawniania samej tajemnicy. Tak opisuje je między innymi amerykański instytut NIST.
W usługach przechowywania danych termin ten jest używany nieco szerzej. Oznacza najczęściej, że usługodawca przechowuje zaszyfrowane informacje, ale nie posiada klucza koniecznego do ich odczytania. Taki model stosują również usługi działające w chmurze, między innymi 1Password i Proton.
Najłatwiej wyjaśnić to na przykładzie szafy z aktami. W zwykłym systemie dostawca stawia solidną szafę, zamyka ją i zapewnia kancelarię, że zapasowego klucza użyje tylko w uzasadnionej sytuacji. W architekturze Zero-Knowledge dostawca udostępnia szafę i pilnuje pomieszczenia, lecz sam nie posiada stałego klucza.
Dostawca chroni dokumenty, ale zachowuje klucz pozwalający mu je odszyfrować. Kancelaria musi zaufać, że klucz nie zostanie użyty bez potrzeby.
Dostawca przechowuje zaszyfrowane pliki, ale nie posiada stałego klucza pozwalającego samodzielnie otworzyć akta kancelarii.
Serwer w kancelarii nie oznacza automatycznie większego bezpieczeństwa
System zainstalowany lokalnie bywa przedstawiany jako jedyna bezpieczna możliwość. Fizyczna lokalizacja urządzenia nie mówi jednak jeszcze nic o sposobie zabezpieczenia dokumentów. Lokalny serwer może przechowywać pliki możliwe do odczytania przez administratora albo mieć wspólny klucz zapisany na tym samym dysku co zaszyfrowane dane.
W takim przypadku osoba, która przejmie serwer, otrzymuje jednocześnie sejf i klucz do sejfu. Instalacja lokalna przenosi również na kancelarię obowiązek stałego utrzymywania bezpieczeństwa całego środowiska.
- aktualizowanie systemu i jego składników
- zabezpieczenie sieci oraz komputerów pracowników
- kontrola kont administracyjnych
- prawidłowe wykonywanie i ochrona kopii zapasowych
- wykrywanie prób włamania
- reagowanie na awarie, ransomware i inne incydenty
Przy kilku lub kilkunastu użytkownikach, komputerach przenośnych, telefonach i dostępie zdalnym nie jest to jednorazowa konfiguracja. To stały proces wymagający wiedzy, czasu i nadzoru. Dobrze zarządzana kancelaria może stworzyć bezpieczne środowisko lokalne, ale samo ustawienie serwera w biurze nie daje takiej gwarancji.
Możliwa jest również sytuacja odwrotna: system działa w profesjonalnej serwerowni, ale dokumenty są zaszyfrowane kluczem, którego operator nie posiada. Kradzież dysku, kopii bazy danych albo magazynu plików nie wystarcza wtedy do poznania treści akt.
Jak chronione są dokumenty w Bezpiecznej Kancelarii?
W Bezpiecznej Kancelarii każda wersja dokumentu otrzymuje własny, losowo wygenerowany klucz. Plik jest szyfrowany przy użyciu standardu AES-256-GCM. Nie tworzymy własnego algorytmu szyfrowania. Korzystamy z uznanych mechanizmów kryptograficznych i biblioteki Google Tink.
Każda kancelaria posiada odrębny zestaw kluczy. Klucz jednej organizacji nie pozwala otworzyć dokumentów należących do innej. Przejęcie pojedynczego pliku albo całego magazynu zaszyfrowanych danych nie wystarcza więc do ich odczytania.
Klucz prywatny kancelarii nie jest przechowywany przez operatora w postaci pozwalającej go użyć. W trwałej formie istnieje wyłącznie w zaszyfrowanych kopiach przeznaczonych dla uprawnionych użytkowników oraz w mechanizmie odzyskiwania opartym na 24-wyrazowej frazie odzyskiwania, nazywanej również frazą seed. Sama fraza nie jest zapisywana w Bezpiecznej Kancelarii.
Bezpieczna Kancelaria przechowuje zaszyfrowane dokumenty, ale nie przechowuje własnego klucza, którym mogłaby je samodzielnie otworzyć.
Co dzieje się po zalogowaniu użytkownika?
Uprawniony użytkownik odblokowuje swój klucz podczas logowania. Dopiero wtedy system może na jego żądanie otworzyć dokument, do którego użytkownik ma dostęp.
Odblokowany klucz nie jest zapisywany na dysku ani w pamięci podręcznej. Istnieje czasowo w pamięci operacyjnej procesu obsługującego aktywną sesję. Wylogowanie użytkownika, zakończenie sesji albo restart procesu usuwa tę możliwość. Aby ponownie odczytać dokumenty, uprawniony użytkownik musi ponownie odblokować klucz.
Najprecyzyjniejsze określenie tego modelu brzmi: Zero-Knowledge dla oryginalnych dokumentów w spoczynku oraz dostęp sesyjny uruchamiany przez uprawnionego użytkownika. Nie twierdzimy, że system nigdy nie przetwarza jawnej treści. Musi ją przetworzyć wtedy, gdy zalogowany prawnik otwiera dokument albo poleca agentowi wykonanie zadania.
Odzyskanie konta nie oznacza odzyskania dokumentów
W wielu usługach przycisk „nie pamiętam hasła” pozwala dostawcy przywrócić dostęp do całej zawartości konta. Jest to wygodne, ale oznacza również, że usługodawca zachował techniczną drogę do danych.
W Bezpiecznej Kancelarii możemy pomóc użytkownikowi odzyskać konto, lecz nie daje nam to możliwości odszyfrowania jego plików. Do odzyskania dokumentów potrzebna jest fraza seed otrzymana podczas tworzenia zabezpieczeń. Jeżeli wszyscy uprawnieni użytkownicy utracą swoje hasła, a kancelaria nie zachowa frazy seed, zaszyfrowanych dokumentów nie odzyska również operator systemu.
To najprostszy test prawdziwości deklaracji o braku klucza. Jeżeli dostawca może odzyskać wszystkie dokumenty bez udziału klienta, oznacza to, że pozostawił sobie techniczną możliwość ich odszyfrowania.
Agent AI zna drogę do akt, ale nie ma własnego klucza
Wokół agentów AI łatwo zbudować wyobrażenie, że sztuczna inteligencja przez całą dobę swobodnie czyta wszystkie dokumenty kancelarii. W Bezpiecznej Kancelarii agent nie otrzymuje takiego stałego dostępu.
Indeks wykorzystywany do wyszukiwania działa jak katalog w archiwum. Przechowuje wskazówki pozwalające ustalić, w którym dokumencie należy szukać odpowiedzi. Nie zastępuje oryginalnych akt i nie daje samodzielnej możliwości otwarcia zaszyfrowanego pliku.
Agent może sięgnąć do dokumentu dopiero wtedy, gdy uprawniony użytkownik jest zalogowany, odblokował klucz i zlecił określone działanie. Po zakończeniu sesji agent traci zwykły dostęp do dokumentów razem z użytkownikiem.
Jeżeli określone przetwarzanie ma być wykonane po zapisaniu pliku, wymaga osobnego, jednorazowego pozwolenia. Pozwolenie wskazuje cel oraz czas ważności i może zostać wystawione wyłącznie podczas sesji osoby posiadającej dostęp do dokumentu. Nie jest to stała furtka pozwalająca agentowi wracać do akt w dowolnym momencie.
Każde wykonane przez system odblokowanie klucza dokumentu pozostawia zapis: kto uzyskał dostęp, do której wersji pliku i kiedy to nastąpiło. Audyt nie zastępuje szyfrowania, ale pozwala kancelarii kontrolować wykorzystanie przyznanego dostępu.
Integracja może dostarczyć dokument, nie mogąc go przeczytać
Niektóre narzędzia muszą przesyłać do systemu nowe materiały bez aktywnej sesji prawnika. Przykładem może być agent dyktafonu albo integracja pobierająca dokument z zewnętrznego źródła.
Takie narzędzie otrzymuje wyłącznie klucz publiczny kancelarii. Pozwala on zaszyfrować i zapisać nowy plik, ale nie pozwala odszyfrować dokumentów już znajdujących się w systemie. Jest to odpowiednik otworu wrzutowego w sejfie: można włożyć kolejną kopertę, ale nie można wyjąć ani przeczytać wcześniejszych.
Ten tryb zapisu jest wymuszony kryptografią, a nie tylko rolą przypisaną w panelu administracyjnym. Nawet przejęte narzędzie integracyjne nie otrzymuje w ten sposób dostępu do archiwum kancelarii.
Czy cały system SaaS z agentem AI może być Zero-Knowledge?
Może, ale wymagałoby to znacznie więcej niż zaszyfrowania bazy danych. W najściślejszym modelu dokument powinien zostać zaszyfrowany na urządzeniu użytkownika jeszcze przed wysłaniem go do dostawcy. Klucz prywatny nie powinien opuszczać tego urządzenia. Agent AI musiałby działać na komputerze lub telefonie użytkownika albo wykonywać obliczenia bez otrzymywania jawnej treści dokumentu.
Jeżeli agent działający na zwykłym serwerze dostawcy otrzymuje odszyfrowany tekst, nie można uczciwie twierdzić, że całe przetwarzanie jest Zero-Knowledge. Można natomiast precyzyjnie wskazać, że Zero-Knowledge albo zero-access dotyczy przechowywania oryginalnych dokumentów, a dostęp do ich treści jest czasowy i kontrolowany przez sesję użytkownika.
Istnieją również specjalne, izolowane środowiska obliczeniowe, które potrafią potwierdzić, jaki kod został w nich uruchomiony. Ograniczają one zaufanie do operatora, ale nadal są innym rozwiązaniem niż sytuacja, w której odszyfrowana treść nigdy nie opuszcza urządzenia użytkownika.
Deklaracje o Zero-Knowledge AI należy czytać bardzo uważnie. Najważniejsze jest to, gdzie dokument jest odszyfrowywany, kto posiada klucz i czy agent może pracować bez aktywnej zgody użytkownika.
Certyfikat Zero-Knowledge nie rozwiązuje problemu
Nie istnieje jeden powszechny certyfikat, który raz na zawsze potwierdzałby, że dowolny system jest Zero-Knowledge. Możliwe są niezależne audyty architektury, kodu oraz sposobu zarządzania kluczami. Ich wynik zawsze ma jednak określony zakres i dotyczy systemu w zbadanej postaci.
Rzetelny raport powinien wskazywać wersję sprawdzonego kodu, datę badania, zakres audytu, identyfikator gotowej kompilacji oraz założenia i wyjątki przyjęte przez audytorów.
Podpis cyfrowy może potwierdzić, że konkretna kompilacja pochodzi z określonego źródła i nie została później zmieniona. Nie potwierdza jednak samodzielnie, że właśnie ta kompilacja nadal działa na serwerze dostawcy.
Można to porównać do opinii technicznej dotyczącej sejfu. Opinia zachowuje znaczenie tak długo, jak długo badany model zamka pozostaje niezmieniony. Jeżeli po badaniu producent doda drugi klucz albo zmieni mechanizm zamykania, poprzednia opinia nie opisuje już nowego rozwiązania.
W oprogramowaniu taką zmianą może być nawet jedna linia kodu zapisująca odblokowany klucz w logach albo wysyłająca odszyfrowaną treść do dodatkowej usługi. Nie każda zmiana unieważnia całą ocenę, ale każda zmiana dotycząca kluczy, odszyfrowywania i przepływu danych powinna zostać ponownie przeanalizowana.
- przegląd zmian w kodzie
- kontrolowane tworzenie kolejnych wersji
- podpisywanie gotowych kompilacji
- rejestrowanie wdrożeń
- ponowna ocena zmian wpływających na dostęp do dokumentów
O co zapytać dostawcę systemu dla kancelarii?
Zamiast pytać wyłącznie, czy system jest Zero-Knowledge, warto uzyskać odpowiedzi na bardziej konkretne pytania.
- Kto posiada klucz pozwalający odszyfrować dokumenty?
- Czy pracownik dostawcy może otworzyć plik bez udziału kancelarii?
- Czy odzyskanie hasła automatycznie przywraca dostęp do dokumentów?
- Gdzie klucz znajduje się podczas aktywnej sesji i co dzieje się z nim po wylogowaniu?
- Czy kopia bazy danych, backup albo obraz serwera wystarczą do odczytania akt?
- Co dokładnie przechowuje indeks używany przez agenta AI?
- Czy agent może czytać dokumenty, gdy żaden uprawniony użytkownik nie jest zalogowany?
- Jakie informacje są przekazywane zewnętrznym modelom AI?
- Czy każde odblokowanie dokumentu jest rejestrowane?
- Jakiej wersji systemu dotyczył ostatni niezależny audyt?
Zero-Knowledge nie oznacza stuprocentowego bezpieczeństwa
Żadna architektura nie usuwa wszystkich zagrożeń. Jeżeli napastnik przejmie komputer zalogowanego użytkownika, może próbować działać z jego uprawnieniami. Jeżeli prawnik sam udostępni dokument niewłaściwej osobie, szyfrowanie również nie cofnie tej decyzji.
Ochrona kluczy musi być uzupełniona zabezpieczeniem sesji, drugim składnikiem logowania, kontrolą urządzeń, ograniczeniem dostępu do osób, które rzeczywiście pracują przy danej sprawie, oraz rejestrowaniem operacji wykonywanych na dokumentach.
Zero-Knowledge rozwiązuje jednak bardzo ważny problem: ogranicza zaufanie, które kancelaria musi pokładać w operatorze systemu. Dostawca nie otrzymuje zapasowego klucza do wszystkich akt tylko dlatego, że utrzymuje aplikację i przechowuje zaszyfrowane pliki.
Kto ma klucz, ten naprawdę kontroluje dokumenty
Spór pomiędzy systemem lokalnym a usługą chmurową często koncentruje się na niewłaściwym pytaniu. Serwer stojący w kancelarii może być źle zabezpieczony i dostępny dla wielu administratorów. Serwer w centrum danych może natomiast przechowywać pliki, których operator nie potrafi odczytać.
Dlatego nie pytamy wyłącznie, gdzie znajdują się dane. Pytamy przede wszystkim, kto posiada klucz, kiedy może go użyć i jaki ślad pozostawia każde odszyfrowanie.
W Bezpiecznej Kancelarii oryginalne dokumenty są przechowywane w modelu Zero-Knowledge w spoczynku. Operator nie posiada stałego klucza do ich odczytania. Dostęp pojawia się podczas aktywnej sesji uprawnionego użytkownika, w zakresie wynikającym z jego uprawnień. Wyjątkiem może być konkretne zadanie uruchomione przez użytkownika na podstawie jednorazowego pozwolenia z określonym celem i terminem ważności.
Nie jest to obietnica, że nie będziemy zaglądać do akt. Jest to architektura zaprojektowana po to, aby poza kontrolowaną sesją kancelarii nie mieć czym ich otworzyć.