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: тој е доверлив само кога слушателот е врзан за интерфејс што проксито може да го достигне и ништо друго не може. Контекстот на адресата што недостасува мора да ја собори заштитената проверка наместо да падне во стандардно дозволување. Заглавие што недостасува не е доказ за доверлив пат.

Прикачете го условот на секоја заштитена операција

Ставете ја проверката на границата за авторизација низ која поминува секоја заштитена операција, а не во страницата што го рендерира менито. Групите рути, middleware или слојот за политики сите работат; копија по обработувач не, бидејќи обработувачот што некој ќе го додаде следниот квартал нема да ја има.

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. Тоа разделување е дизајнот, а не негово ограничување.