Все още ли ви е нужен VPN, ако използвате Identity-Aware Proxy?

Предположението звучи така: щом пред вътрешните приложения застане прокси, което познава самоличността, VPN-ът е само украшение и клиентът може да си тръгне. Това важи за един тесен случай — интерактивно HTTPS приложение, което човек използва в браузър — и тихо се проваля навсякъде другаде. Проксито оторизира заявка спрямо ресурс; VPN-ът допуска клиент до мрежов обхват, и двете граници рядко съвпадат. Преди да пенсионирате тунел, сравнете операциите, които хората ви наистина извършват, а не продуктовите етикети на диаграмата.

Двете порти оторизират различни неща

Портата на приложението решава дали тази заявка, от тази самоличност, може да достигне този защитен ресурс. Прегледът на Identity-Aware Proxy на Google описва точно тази форма: централен слой за оторизация пред HTTPS приложения, управляван от IAM роля. Границата е ресурсът, а единицата за достъп е заявката. Маршрутизираният VPN прави нещо по-грубо и по-широко: допуска клиент до определен мрежов обхват, след което приложението все още решава какво може този клиент.

Нито един от двата модела не предполага другия. Преминаването през портата не казва нищо за четене на конкретен запис, а присъствието в мрежата не казва нищо за разрешение да се действа.

Какво не покрива проксито, а VPN-ът покрива

SSH сесии, клиенти за бази данни, брокери на съобщения и вътрешни имена на хостове, които никой браузър не отваря, не стават достъпни само защото съществува уеб прокси. Всеки говори своя протокол и всеки се нуждае или от собствен удостоверен път, или от мрежа, която го носи. Това е пропускът, който хората откриват в първия ден на миграция, обикновено от дежурен инженер с лаптоп, който вече не може да резолвне име на хост.

Обратният пропуск е също толкова реален. VPN, който допуска клиент до подмрежа, не удостоверява човека вътре в нея, а компрометирано устройство в тази подмрежа наследява каквото мрежата позволява. Ако изискването е оторизация за всяка заявка с одитируема самоличност, само маршрутизиране не може да го осигури. Повечето организации накрая поддържат и двете, а интересният въпрос е на кои ресурси всяко от тях е позволено да стои отпред.

Работният поток на клиента решава повече от архитектурната диаграма

Влизането в браузър с пренасочване и от време на време MFA предизвикателство е добро изживяване за човек, който натиска отметка. Задача по cron, CLI или агент за изграждане няма браузър и не може да отговори на интерактивна подкана, затова се нуждае от документиран неинтерактивен път или от тунела. Откриването на това изискване обикновено става след одобряване на дизайна.

Пребройте клиентите, преди да броите приложенията. Едно табло може да обслужва сто души; един порт на база данни може да блокира цял екип.

Състоянието на устройството не е свойство на нито една от портите

Инсталирането на VPN клиент не е проверка за съответствие, а дизайнът, базиран на браузър, не е автоматично неспособен да спазва политика за управлявани устройства. И двете могат да се интегрират със сигнали за състояние, и двете могат да бъдат внедрени без тях. Питайте какво прилагане съществува, кой притежава политиката и какво се случва с устройство, което я наруши, вместо да го извеждате от формата на продукта.

Същото внимание важи и за премахването на достъп. Изтриването на членство в група в проксито и отзоваването на сертификат за тунела са различни операции с различно закъснение и една от тях обикновено се забравя при освобождаване.

Намерете алтернативните пътища, преди да се откажете от нещо

Незащитен източник зад проксито, второ име на хост, което го заобикаля, или широк частен маршрут, останал от по-ранен дизайн, ще решат коя порта реално действа. Тествайте разрешена операция и отказана такава през реалния клиент, не през конзолата, и ги тествайте от устройство, което никога не е било регистрирано. Отказаният случай е този, който ви казва дали портата изобщо прави нещо.

След това напишете предаването: регистрация, актуализации, премахване на достъп и път за възстановяване за някого, заключен в 2 часа през нощта. Премахването на подкана или клиентско приложение премества отговорността между екипи; то не изтрива отговорността.

Ако решавате тази седмица, започнете със списък от операции, а не от продукти, отбележете кои от тях може да изпълни браузър и останалите нека оправдаят мрежовия достъп, който оцелее.