Potřebujete ještě VPN, když používáte Identity-Aware Proxy?

Předpoklad zní takto: jakmile před interními aplikacemi stojí proxy znající identitu, je VPN jen dekorace a klient může odejít. To platí pro jeden úzký případ, interaktivní aplikaci HTTPS, kterou člověk používá v prohlížeči, a jinde tiše selhává. Proxy autorizuje požadavek vůči prostředku; VPN pustí klienta do síťového rozsahu a ty dvě hranice se málokdy kryjí. Než tunel vyřadíte, porovnejte operace, které vaši lidé skutečně provádějí, ne názvy produktů na diagramu.

Dvě brány autorizují různé věci

Brána aplikace rozhoduje, zda tento požadavek od této identity může dosáhnout tohoto chráněného prostředku. Přehled Identity-Aware Proxy od Googlu popisuje přesně tento tvar: centrální autorizační vrstvu před aplikacemi HTTPS, řízenou rolí IAM. Hranicí je prostředek a jednotkou přístupu je požadavek. Směrovaná VPN dělá něco hrubšího a širšího: pustí klienta do definovaného síťového rozsahu, načež aplikace stále rozhoduje, co tento klient smí.

Ani jeden model neimplikuje druhý. Projít branou nic neříká o čtení konkrétního záznamu a být v síti nic neříká o povolení jednat.

Co proxy nepokrývá a VPN ano

Relace SSH, klienti databází, broker zpráv a interní názvy hostitelů, které žádný prohlížeč nikdy neotevře, se nestanou dostupnými jen proto, že existuje webová proxy. Každý mluví svým protokolem a každý potřebuje buď vlastní autentizovanou cestu, nebo síť, která ho nese. To je mezera, kterou lidé objeví první den migrace, obvykle od pohotovostního inženýra s notebookem, který už nedokáže přeložit název hostitele.

Opačná mezera je stejně skutečná. VPN, která pustí klienta do podsítě, neověřuje osobu uvnitř a kompromitované zařízení v této podsíti zdědí, co síť dovolí. Pokud je požadavkem autorizace na každý požadavek s auditovatelnou identitou, samotné směrování to nedokáže. Většina organizací nakonec provozuje obojí a zajímavá otázka je, kterým prostředkům je čemu dovoleno stát v čele.

Pracovní postup klienta rozhoduje víc než diagram architektury

Přihlášení v prohlížeči s přesměrováním a občasnou výzvou MFA je dobrý zážitek pro člověka, který klikne na záložku. Úloha cron, CLI nebo build agent nemá prohlížeč a nemůže odpovědět na interaktivní výzvu, takže potřebuje zdokumentovanou neinteraktivní cestu, nebo tunel. Objevení tohoto požadavku obvykle přijde poté, co je návrh schválen.

Počítejte klienty dřív než aplikace. Jeden dashboard může obsloužit sto lidí; jeden databázový port může zablokovat celý tým.

Stav zařízení není vlastností ani jedné brány

Instalace klienta VPN není kontrola shody a návrh založený na prohlížeči není automaticky neschopný ctít politiku spravovaných zařízení. Oba se mohou integrovat se signály stavu a oba lze nasadit bez nich. Ptejte se, jaké vynucení existuje, kdo vlastní politiku a co se stane se zařízením, které ji nesplní, místo abyste to odvozovali z tvaru produktu.

Stejná opatrnost platí pro odebrání přístupu. Smazání členství ve skupině v proxy a odvolání certifikátu pro tunel jsou různé operace s různým zpožděním a jedna z nich se při odchodu obvykle zapomene.

Najděte alternativní cesty, než něco vyřadíte

Nezabezpečený původ za proxy, druhé jméno hostitele, které ji obchází, nebo široká privátní trasa zbylá z dřívějšího návrhu rozhodnou, která brána je fakticky v platnosti. Otestujte povolenou operaci a jednu zamítnutou skutečným klientem, ne konzolí, a otestujte je ze zařízení, které nikdy nebylo zapsáno. Zamítnutý případ je ten, který vám řekne, zda brána vůbec něco dělá.

Pak napište předání: zápis, aktualizace, odebrání přístupu a cestu obnovy pro někoho zamčeného ve 2 hodiny ráno. Odebrání výzvy nebo klientské aplikace přesouvá odpovědnost mezi týmy; nemaže ji.

Pokud se rozhodujete tento týden, začněte seznamem operací, ne seznamem produktů, označte, které zvládne prohlížeč, a zbytek ať ospravedlní síťový přístup, který přežije.