Uložené heslo VPN: kdo ho může dešifrovat a kdy

Klient VPN, který ve svém XML zobrazuje šifrované heslo, vám nesdělil téměř nic. Šifrovaný text odpovídá jen na to, že hodnota není v tomto zobrazení uložena jako prostý text. Kdo ho může dešifrovat, jakým klíčem a v jakém uživatelském kontextu, jsou otázky, které rozhodují, zda úložiště pomáhá. Odpovězte na ně, než soubor označíte za bezpečný nebo nebezpečný.

Určete, který objekt se ukládá

Začněte dokumentovaným modelem ukládání daného produktu. Klient může ukládat obnovitelné heslo, token nebo odkaz na úložiště přihlašovacích údajů a každá z těchto možností má jinou expozici. Název elementu XML není design a řetězec vypadající jako base64 také není důkazem šifrování.

Zeptejte se dodavatele nebo správce, která komponenta čte hodnotu v okamžiku připojení.

Poté určete ochranné API, pokud je dokumentované. Ve Windows chrání CryptProtectData data klíčem odvozeným z přihlašovacích údajů šifrujícího uživatele a jeho volba v rozsahu počítače mění, kdo může dešifrovat. To je konkrétní příklad toho, proč na rozsahu záleží. Není to však důkaz, že nějaký konkrétní klient VPN toto API používá.

Oddělte ukradenou kopii od použití za běhu

Klient, který se připojuje znovu, aniž by se vás ptal, potřebuje podporovaný způsob obnovy přihlašovacích údajů. Ochrana záložní kopie tuto schopnost neodstraňuje. Libovolný program běžící ve správném uživatelském kontextu může použít stejnou cestu, a proto je koncový bod sám uvnitř hranice důvěry. Oprávnění souborů a oprávnění procesů tuto hranici zužují; neodstraňují ji.

Právě v tomto rozlišení se tvrzení o offline souboru obvykle mýlí. Šifrování v klidu může zastavit někoho, kdo kopíruje jeden soubor bez účtu. Nezastaví kód, který běží pod účtem.

Obě tvrzení mohou platit současně a to druhé je důležité při reakci na incident.

Přečtěte si řízení přístupu, které skutečně platí

Zkontrolujte ACL souboru i nadřazený adresář, nejen režim souboru. Ve Windows porovnejte efektivní oprávnění uživatelského profilu s oprávněními služby klienta nebo naplánované úlohy. Tajemství chráněné pro jednoho uživatele není automaticky chráněno před správcem a není mu ani automaticky vystaveno.

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

Zaznamenejte, která identita klienta spouští, protože tato identita je subjektem dešifrování.

U spravované flotily může být příslušnou kontrolou správa zařízení, nikoli soubor. Zeptejte se, zda jsou přihlašovací údaje uloženy do úschovy, zda je lze na dálku zneplatnit a jaký je postup při ztrátě zařízení.

Plánujte expozici místo testování dešifrování

Nespouštějte proti souboru neznámý nástroj pro extrakci, abyste něco dokázali. Může fungovat, může poškodit profil a v každém případě mění důkazy. Použijte dokumentovaný design a autorizované posouzení, pokud je ověření skutečně nutné.

Pokud je expozice prokázána, vyměňte přihlašovací údaje u vlastníka identity.

Smazání uloženého záznamu není odvolání. Může zabránit tomu, aby klient hodnotu znovu nabídl, a nic neřeší u kopie, která už byla pořízena, ani u relace, která už byla autorizována. Nahraďte přihlašovací údaje, ukončete relace, které vlastník ukončit může, a zaznamenejte, co bylo vyměněno a kdy.

Otázky pro revizi dodavatele

Zeptejte se, jaké tajemství se ukládá, která komponenta je používá, který uživatelský nebo počítačový klíč je chrání, jaká pravidla přístupu platí pro běžné použití a zálohy a jak se řeší zásada ukládání a vzdálené zneplatnění. Těchto pět odpovědí popisuje design; XML ne.

Odpovědi uchovejte u záznamu o nasazení, aby další recenzent cvičení neopakoval.

Uložené přihlašovací údaje jsou výměnou mezi pohodlím a expozicí. Udělejte tuto výměnu vědomě a zapište, kdo ji přijal.