Má zmysel vrstviť dve VPN? Tri podmienky na overenie

Skôr než k VPN pridáte druhú šifrovaciu vrstvu, poctivo odpovedzte na jednu otázku: čo pozorovateľovi zostáva po tom, čo obe vrstvy odviedli svoju prácu? Ak je odpoveďou vnútorný šifrovaný text, nezmenený, potom vnorenie kúpilo čas a nič iné. Čo nasleduje, je postup rozhodovania, nie odporúčanie. Ten istý diagram je v jednom nasadení premrhaný procesor a v inom správna odpoveď, a obe oddeľujú len tri podmienky.

Zapíšte, čo pozorovateľ uchováva

Zapíšte objekt, ktorý dnes protivník môže uložiť, a potom postupnosť odstránení, ktorá by napokon odhalila otvorený text. Vonkajší tunel vytvára šifrovaný text; keď sa jeho ochrana skončí, zostáva šifrovaný text vnútorného tunela, stále zapečatený. Zložiť obal nie je dešifrovanie. Tá veta opisuje vnorenie a platí len dovtedy, kým vnútorný kľúč prežíva. Vo chvíli, keď obe vrstvy čokoľvek zdieľajú, sa časová os zrúti do jedinej udalosti.

Užitočným artefaktom je teda časová os, nie diagram škatúľ. Pre každú vrstvu zapíšte koncový bod, vlastníka kľúča, kontrolu identity a rok, v ktorom sa očakáva zlyhanie predpokladu.

Praktický spôsob, ako overiť vlastné tvrdenie: predpokladajte, že pozorovateľ všetko zaznamenáva a nikdy sa nevzdá. Za tohto predpokladu, chráni návrh užitočné zaťaženie po celý požadovaný čas? Ak odpoveď závisí od toho, že sa pozorovateľ rozhodne prevádzku neukladať, návrh nemá odpoveď.

Podmienka prvá: končia vrstvy na rôznych miestach?

Vnorenie sa vyplatí, keď obe vrstvy končia v rôznych doménach dôvery, napríklad brána IPsec spravovaná poskytovateľom pred tunelom na aplikačnej úrovni, ktorý končí vo vašej vlastnej sieti. Prelomenie vonkajšej vrstvy potom dá šifrovaný text, ktorý otvorí len váš hostiteľ, a poskytovateľ nikdy nevidí otvorený text. Dajte obe vrstvy na tú istú bránu a táto vlastnosť zmizne. Kto kompromituje škatuľu, číta prevádzku medzi oboma dešifrovacími operáciami, nech diagram ukazuje akokoľvek veľa obalov.

Overte to nainštalovaným stavom, nie návrhom. V Linuxe ip xfrm state vypisuje každú bezpečnostnú asociáciu a jej koncové body, čo určuje, kde sa každá vrstva skutočne zastaví.

Podmienka druhá: je kľúčový materiál skutočne nezávislý?

Dve vrstvy postavené z jedného certifikátu, jedného vopred zdieľaného kľúča alebo jednej knižnice dodávateľa sú jedna vrstva s krokmi navyše. Potom jeden uniknutý údaj odomkne obe a jedna chyba implementácie odstráni obe naraz. Nezávislosť musí byť viditeľná v konfigurácii, nie tvrdená na slide.

Tu hybridné ustanovenie kľúčov prekonáva vrstvenie tunelov. IKEv2 dokáže v jednom vyjednávaní preniesť viacero výmen kľúčov, takže klasická grupa aj postkvantový KEM môžu obe napájať tie isté reláčné kľúče, namiesto toho, aby boli navzájom obalené. Výsledkom je jediná bezpečnostná asociácia, ktorej kľúče závisia od oboch tajomstiev, a útočník musí prelomiť obe. To je dokumentovaná konštrukcia s definovaným zložením, čo podomácky zostavený stoh dvoch VPN produktov nie je. V strongSwan swanctl --list-sas vypíše vyjednaný návrh pre každú SA, a tak potvrdíte, čo skutočne bežalo, nie čo ste nakonfigurovali.

Podmienka tretia: prežijú dáta vonkajší predpoklad?

Vrstva, ktorá musí vydržať dvadsať rokov, potrebuje dvadsaťročný argument. Zaznamenať teraz a dešifrovať neskôr je lacné, a preto klasickú vonkajšiu vrstvu nemožno považovať za dočasný obal okolo niečoho silnejšieho.

Pýtajte sa, kedy sa každý kľúč stane obnoviteľným, nie či je šifra dnes prelomená. Statická výmena kľúčov bez dopredného utajenia zlyháva spätne v deň, keď padne súkromný kľúč. Efemérna dohoda o kľúčoch zlyháva len pri reláciách, ktoré útočník môže napadnúť, kým sú živé, alebo keď samotný algoritmus slabne. Tento rozdiel rozhoduje, či vnútorná vrstva ešte v roku 2040 pomôže. Rozhoduje aj o tom, či vonkajšia vrstva vôbec niečo mení, pretože vonkajšia vrstva so slabšou životnosťou kľúča sa jednoducho stane najskorším bodom na časovej osi.

Čo namiesto toho postaviť, keď je odpoveď nie

Ak ktorákoľvek z troch podmienok zlyhá, vnorenie opustite a úsilie venujte vrstve, ktorá požiadavku na životnosť skutočne nesie. Nakonfigurujte hybridnú výmenu kľúčov v protokole, ktorý už prevádzkujete, udržiavajte implementáciu aktuálnu a zapíšte zloženie, na ktoré sa spoliehate. Uviesť ML-KEM v návrhovom dokumente nie je bezpečnostná vlastnosť a FIPS 203 definuje mechanizmus zapuzdrenia kľúčov, nie váš tunel.

Tam, kde si druhá vrstva naozaj zaslúži svoje miesto, opíšte ju ako obranu do hĺbky, nie ako dôkaz. Potom overte zloženie: ktorý koncový bod drží ktorý kľúč, akú identitu kontroluje každá strana a čo môže prečítať operátor s prístupom ku konzole. Návrh, ktorý prejde týmito tromi otázkami, stojí za procesor navyše. Ten, ktorý neprejde, je len diagram.

Pred oknom zmien zaznamenajte aktuálnu tabuľku SA a vyjednané návrhy, po ňom ich zaznamenajte znova a porovnajte, pretože jediný dôkaz, na ktorom záleží, je to, na čom sa zariadenia skutočne dohodli.