Šifrovaný tranzit neposkytuje přístup k operátorovi

Dvě schválené brány přenášejí provoz sítě s nižší důvěrou přes omezenou transportní síť. Šifrování užitečného zatížení ho udržuje nečitelné pro běžné pozorovatele tranzitu, a to je část, kterou lidé navrhují jako první a pak o ní přestanou přemýšlet. Co šifrování nedělá, je určení, ke kterým zdrojům smí strana s nižší důvěrou přistupovat. Návrh potřebuje dvě hranice: jednu kolem přenášené konverzace a jednu kolem přístupu k samotnému operátorovi.

Proveďte níže uvedené kroky v pořadí a každé selhání v kterémkoli kroku berte jako změnu návrhu, ne jako úpravu konfigurace.

Definujte obě hranice, než se dotknete konfigurace

První hranice je konverzace: které dvojice bran mohou vytvořit tunel a který vnitřní provoz jím smí procházet. Druhá je operátor: které adresy a služby mohou hostitelé s nižší důvěrou dosáhnout mimo tunel. Týmy obvykle staví první a druhou dědí z jakéhokoli směrování, které už existovalo, a tak se omezený návrh tiše stává širokým. To dědictví je obvyklou hlavní příčinou, když revize zjistí, že hostitel s nižší důvěrou mluví s něčím, co nikdo neschválil.

Zapište obě jako seznamy adres, portů a směrů. Pokud seznam nelze zapsat, hranice ještě není definovaná.

Krok 1: omezme vnější tunel

Na rozhraní obráceném k operátorovi povolte jen to, co tunel potřebuje: IKE na UDP 500 a 4500 mezi dvěma adresami bran a ESP tam, kde se nepoužívá průchod NAT. Odmítejte vše ostatní, co na toto rozhraní přichází, včetně řídicích protokolů. Specifikace ESP pokrývá ochranné služby; nic neříká o tom, které vlastní služby operátora smějí brány používat. Vyjádřete to jako explicitní seznam povolení, aby nově zveřejněná služba operátora nebyla ve výchozím stavu dostupná.

Toto je sada pravidel, která z návrhu dělá tranzitní návrh, a ne uspořádání peeringu.

Ověřte to ze strany s nižší důvěrou, ne z konzoly brány. Hostitel tam by neměl dosáhnout na server DNS operátora ještě předtím, než je tunel zvednutý.

Krok 2: rozhodněte, co vzdálená brána doručuje

Na vzdáleném konci musí obnovený provoz jít na konkrétní místo. Definujte, které vnitřní služby jsou povolené, z kterých rozsahů zdrojů a zda se očekávají symetrické odpovědi. Projděte správu přístupu zvlášť, protože stejná brána často vystavuje administrativní rozhraní, které nikdy nebylo součástí tranzitního plánu.

Diagram, který končí u úspěšného dešifrování, vynechal rozhodnutí, na kterém záleží nejvíc.

Krok 3: zachovejte vlastnictví po vrstvách

Tranzitní zařízení stále přijímá a předává vnější pakety, takže potřebuje záplaty a plánování kapacity. Koncové body tunelu zpracovávají chráněný protokol a vystavují vnitřní provoz své předávací cestě, takže potřebují vlastní pravidla a vlastní monitoring. Koncové aplikace zpracovávají užitečné zatížení a neprůhledné zatížení není důkazem, že dešifrované stahování je neškodné.

Přiřaďte vlastníka každé vrstvě. Vrstvy bez vlastníka jsou ty, které se rozjíždějí.

Krok 4: ověřte a pak to předejte úřadu

Ověřte vnější cestu se zvednutým tunelem a pravidly operátora na místě. Pak zkuste každý zdroj, ke kterému by strana s nižší důvěrou neměla dosáhnout, a potvrďte, že selhání je odmítnutí, a ne timeout, který skrývá trasu. Zkontrolujte také dostupnost a limity zdrojů, protože i šifrované spojení lze nasytit.

Pro regulovaná nebo klasifikovaná prostředí vezměte návrh k odpovědnému bezpečnostnímu úřadu a použijte jeho schválenou architekturu oddělení. Konfigurace VPN a koncepční vysvětlení akreditaci nezakládají. Tento krok není papírování; rozhoduje o tom, zda návrh vůbec smí existovat.