Адміністрацыйная зона SaaS за VPN: якому адрасу давяраць?

Крынічны сервер бачыць выходны адрас вашага 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. Гэтае раздзяленне і ёсць дызайн, а не яго абмежаванне.

Падобныя артыкулы