Zapisane hasło VPN: kto może je odszyfrować i kiedy

Klient VPN, który pokazuje zaszyfrowane hasło w swoim XML, nie powiedział ci prawie nic. Szyfrogram odpowiada tylko na to, że wartość nie jest w tej reprezentacji zapisana jako zwykły tekst. Kto może ją odszyfrować, jakim kluczem i w jakim kontekście użytkownika — to pytania, które decydują, czy przechowywanie pomaga. Odpowiedz na nie, zanim nazwiesz plik bezpiecznym albo niebezpiecznym.

Ustal, jaki obiekt jest przechowywany

Zacznij od udokumentowanego modelu przechowywania produktu. Klient może przechowywać hasło możliwe do odzyskania, token albo odwołanie do magazynu poświadczeń, a każde z nich ma inne ryzyko ujawnienia. Nazwa elementu XML nie jest projektem, a ciąg wyglądający jak base64 też nie jest dowodem szyfrowania.

Zapytaj dostawcę lub administratora, który komponent odczytuje wartość w momencie połączenia.

Następnie ustal interfejs API ochrony, jeśli jest udokumentowany. W systemie Windows CryptProtectData chroni dane kluczem wyprowadzonym z poświadczeń logowania użytkownika szyfrującego, a opcja na poziomie komputera zmienia to, kto może odszyfrować. To konkretny przykład tego, dlaczego zakres ma znaczenie. Nie jest to dowód, że jakikolwiek klient VPN używa tego interfejsu.

Oddziel skradzioną kopię od użycia w czasie działania

Klient, który łączy się ponownie bez pytania cię, potrzebuje obsługiwanego sposobu odzyskania poświadczenia. Ochrona kopii zapasowej nie odbiera tej możliwości. Dowolny program działający we właściwym kontekście użytkownika może użyć tej samej ścieżki, dlatego sam punkt końcowy leży wewnątrz granicy zaufania. Uprawnienia plików i przywileje procesów zawężają tę granicę; nie usuwają jej.

To właśnie to rozróżnienie zwykle mylą twierdzenia o pliku offline. Szyfrowanie w spoczynku może powstrzymać kogoś, kto kopiuje jeden plik bez konta. Nie powstrzyma kodu, który działa jako to konto.

Oba stwierdzenia mogą być prawdziwe jednocześnie, a to drugie ma znaczenie podczas reagowania na incydent.

Przeczytaj mechanizmy kontroli dostępu, które naprawdę obowiązują

Sprawdź listę ACL pliku oraz katalogu nad nim, nie tylko tryb pliku. W systemie Windows porównaj efektywne uprawnienia profilu użytkownika z uprawnieniami usługi klienta lub zadania harmonogramu. Sekret chroniony dla jednego użytkownika nie jest automatycznie chroniony przed administratorem i nie jest też automatycznie przed nim odsłonięty.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Zapisz, jaka tożsamość uruchamia klienta, ponieważ ta tożsamość jest podmiotem odszyfrowania.

W zarządzanej flocie właściwą kontrolą może być zarządzanie urządzeniami, a nie plik. Zapytaj, czy poświadczenie jest deponowane, czy można je unieważnić zdalnie i jaka jest procedura przy utracie urządzenia.

Planuj ujawnienie, zamiast testować odszyfrowanie

Nie uruchamiaj nieznanego narzędzia do wyodrębniania na pliku, żeby coś udowodnić. Może zadziałać, może uszkodzić profil, a w obu przypadkach zmienia dowody. Korzystaj z udokumentowanego projektu i autoryzowanej oceny, jeśli weryfikacja jest naprawdę potrzebna.

Jeśli ujawnienie zostanie stwierdzone, zmień poświadczenie u właściciela tożsamości.

Usunięcie zapisanego wpisu nie jest unieważnieniem. Może powstrzymać tego klienta przed ponownym podaniem wartości i nic nie robi z kopią już zabraną ani z sesją już autoryzowaną. Wymień poświadczenie, zakończ sesje, które właściciel może zakończyć, i zapisz, co i kiedy zmieniono.

Pytania do przeglądu dostawcy

Zapytaj, jaki sekret jest przechowywany, który komponent go używa, który klucz użytkownika lub komputera go chroni, jakie kontrole dostępu obowiązują dla normalnego użycia i kopii zapasowych oraz jak obsługiwane są zasady zapisywania i unieważnianie zdalne. Te pięć odpowiedzi opisuje projekt; XML tego nie robi.

Zachowaj odpowiedzi wraz z zapisem wdrożenia, aby następny recenzent nie powtarzał tego ćwiczenia.

Zapisane poświadczenie to wymiana między wygodą a ryzykiem ujawnienia. Dokonaj tej wymiany świadomie i zapisz, kto ją zaakceptował.