Má smysl vrstvit dvě VPN? Tři podmínky k ověření

Než k VPN přidáte druhou šifrovací vrstvu, poctivě odpovězte na jednu otázku: co pozorovateli zbývá poté, co obě vrstvy odvedly svou práci? Pokud je odpovědí vnitřní šifrovaný text, nezměněný, pak vnoření koupilo čas a nic jiného. Co následuje, je postup rozhodování, ne doporučení. Stejný diagram je v jednom nasazení vyplýtvaný procesor a v jiném správná odpověď, a obojí oddělují jen tři podmínky.

Zapište, co pozorovatel uchovává

Zapište objekt, který dnes protivník může uložit, a poté posloupnost odstranění, která by nakonec odhalila otevřený text. Vnější tunel vytváří šifrovaný text; když jeho ochrana skončí, zůstává šifrovaný text vnitřního tunelu, stále zapečetěný. Sundat obal není dešifrování. Tato věta popisuje vnoření a platí jen tehdy, dokud vnitřní klíč přežívá. Ve chvíli, kdy obě vrstvy cokoli sdílejí, se časová osa hroutí do jediné události.

Užitečným artefaktem je tedy časová osa, ne diagram krabic. Pro každou vrstvu zapište koncový bod, vlastníka klíče, kontrolu identity a rok, ve kterém se očekává selhání předpokladu.

Praktický způsob, jak ověřit vlastní tvrzení: předpokládejte, že pozorovatel vše zaznamenává a nikdy se nevzdá. Za tohoto předpokladu chrání návrh užitečné zatížení po celou požadovanou dobu? Pokud odpověď závisí na tom, že se pozorovatel rozhodne provoz neukládat, návrh žádnou odpověď nemá.

Podmínka první: končí vrstvy na různých místech?

Vnoření se vyplatí, když obě vrstvy končí v různých doménách důvěry, například brána IPsec spravovaná poskytovatelem před tunelem na aplikační úrovni, který končí uvnitř vaší sítě. Prolomení vnější vrstvy pak dá šifrovaný text, který otevře jen váš hostitel, a poskytovatel nikdy nevidí otevřený text. Dejte obě vrstvy na tutéž bránu a tato vlastnost zmizí. Kdo krabici kompromituje, čte provoz mezi oběma dešifrovacími operacemi, ať diagram ukazuje sebevíc obalů.

Ověřte to nainstalovaným stavem, ne návrhem. V Linuxu ip xfrm state vypisuje každou bezpečnostní asociaci a její koncové body, což určí, kde se každá vrstva skutečně zastaví.

Podmínka druhá: je klíčový materiál skutečně nezávislý?

Dvě vrstvy postavené z jednoho certifikátu, jednoho předem sdíleného klíče nebo jedné knihovny dodavatele jsou jedna vrstva s kroky navíc. Pak jeden kompromitovaný údaj odemkne obě a jedna chyba implementace odstraní obě najednou. Nezávislost musí být vidět v konfiguraci, ne tvrzená na slidu.

Zde hybridní ustavení klíčů překonává vrstvení tunelů. IKEv2 umí v jednom vyjednávání přenést několik výměn klíčů, takže klasická grupa i postkvantový KEM mohou oba napájet stejné klíče relace, místo aby byly navzájem obaleny. Výsledkem je jediná bezpečnostní asociace, jejíž klíče závisí na obou tajemstvích, a útočník musí prolomit obě. To je dokumentovaná konstrukce s definovaným složením, což podomácku sestavený stoh dvou VPN produktů není. V strongSwanu swanctl --list-sas vypíše vyjednaný návrh pro každou SA, a tak potvrdíte, co skutečně běželo, ne co jste nakonfigurovali.

Podmínka třetí: přežijí data vnější předpoklad?

Vrstva, která musí vydržet dvacet let, potřebuje dvacetiletý argument. Zaznamenat nyní a dešifrovat později je levné, a proto nelze klasickou vnější vrstvu považovat za dočasný obal kolem něčeho silnějšího.

Ptejte se, kdy se každý klíč stane obnovitelným, ne zda je šifra dnes prolomena. Statická výměna klíčů bez dopředného utajení selhává zpětně v den, kdy padne soukromý klíč. Efemérní dohoda o klíčích selhává jen u relací, které útočník může napadnout, dokud jsou živé, nebo když samotný algoritmus slábne. Tento rozdíl rozhoduje, zda vnitřní vrstva ještě v roce 2040 pomůže. Rozhoduje také, zda vnější vrstva vůbec něco mění, protože vnější vrstva se slabší životností klíče se prostě stane nejranějším bodem na časové ose.

Co místo toho postavit, když je odpověď ne

Pokud kterákoli ze tří podmínek selže, vnoření opusťte a úsilí věnujte vrstvě, která požadavek na životnost skutečně nese. Nakonfigurujte hybridní výměnu klíčů v protokolu, který už provozujete, udržujte implementaci aktuální a zapište složení, na které spoléháte. Uvést ML-KEM v návrhovém dokumentu není bezpečnostní vlastnost a FIPS 203 definuje mechanismus zapouzdření klíčů, ne váš tunel.

Tam, kde si druhá vrstva opravdu zaslouží své místo, popište ji jako obranu do hloubky, ne jako důkaz. Poté složení ověřte: který koncový bod drží který klíč, jakou identitu každá strana kontroluje a co může přečíst operátor s přístupem ke konzoli. Návrh, který těmito třemi otázkami projde, stojí za procesor navíc. Ten, který neprojde, je jen diagram.

Před oknem změny zaznamenejte aktuální tabulku SA a vyjednané návrhy, po něm je zaznamenejte znovu a porovnejte, protože jediný důkaz, na kterém záleží, je to, na čem se zařízení skutečně dohodla.