Админ зона на SaaS зад VPN: на кой адрес да вярвате?

Публичните SaaS страници могат да останат отворени за всички, докато административните операции зад тях отказват на всеки извън VPN. Механизмът, който прави това възможно, не е скрито меню или отделна страница за вход; това е проверка на мрежовия път, който е доставил заявката. Сгрешете ли доказателството за адреса, проверката или блокира истинските администратори, или допуска всеки, който може да напише заглавок. Започнете с това, което източникът действително получава.

Какво действително получава източникът след тунела

Когато браузър достигне публичния сайт през VPN, който пренася и интернет трафик, шлюзът преобразува връзката преди тя да излезе. SaaS вижда публичния изходящ адрес на шлюза, обикновено един адрес или малък диапазон, и никога не вижда тунелния адрес на лаптопа. Ето защо добавянето на 10.90.0.42 в списъка с разрешени се проваля, и защо добавянето на целия RFC 1918 се проваля още по-шумно: второто допуска всяка частна мрежа, която може да ви достигне. Единственият адрес, за който си струва да поставяте условие, е този, който организацията ви действително притежава на изхода.

curl -s https://ifconfig.me
dig +short admin.example.com

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

Спрете и поправете маршрутизацията, преди да напишете каквато и да е политика, ако изходящият адрес се различава за всеки потребител. Условие, което съвпада само с част от администраторите, е по-лошо от липса на условие, защото крие проблема до инцидент.

Вярвайте само на проксито, което пренаписва адреса

Повечето публични сайтове стоят зад CDN или обратно прокси, затова адресът на сокета на източника принадлежи на този фронтенд, а не на посетителя. Фронтендът обикновено препраща оригиналния адрес в заглавок, и този заглавок се контролира от нападателя, освен ако източникът не го приема само от известни проксита. Конфигурирайте списъка с доверени източници изрично и направете източника недостъпен от всякъде другаде. Без тази втора половина нападателят заобикаля проксито и изпраща заглавка директно.

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

Същото съображение важи за протокола PROXY: той е надежден само когато слушателят е свързан към интерфейс, до който проксито има достъп и никой друг. Липсващият контекст на адреса трябва да провали защитената проверка, а не да премине към разрешение по подразбиране. Липсващият заглавок не е доказателство за доверен път.

Прикрепете условието към всяка защитена операция

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

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

Същата граница трябва да покрива JSON API, експорти, подписани URL адреси за изтегляне и ръкостискането на WebSocket, тъй като нито едно от тях не се нуждае от HTML страницата да бъде заявена първо. Връзка за изтегляне, създадена, докато VPN е бил включен, остава валидна след това, освен ако крайната точка за изтегляне не проверява отново. Дълготрайните сесии също се нуждаят от правило за преоценка, иначе една удостоверена заявка става постоянно изключение. Отказът по подразбиране е единствената настройка, която оцелява при смяна на персонала.

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

Тествайте заобикалянията, които току-що затворихте

Упражнете матрицата, а не щастливия път: администратор през VPN, същият администратор без него, неадминистратор през него и подправен заглавок за адрес. Добавете заявка директно към източника и заявка с кеширан отговор, защото точно тези две напълно заобикалят фронтенда.

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

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

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