OAuth унутры VPN: якія ўчасткі ўсё яшчэ патрабуюць TLS

Прыватная маршрутызацыя вырашае, хто дасягае сервера; правілы пераносу OAuth вырашаюць, як падарожнічае кожнае паведамленне. Браўзер, сервер аўтарызацыі, канцавы пункт токена і сервер рэсурсаў могуць усе знаходзіцца за адным VPN і ўсё ж абменьвацца паведамленнямі праз розныя ўчасткі. Кожны ўчастак мае сваё патрабаванне да пераносу, і VPN не паслабляе ніводнага з іх. Мяжа VPN і мяжа пратакола — гэта розныя лініі.

Рашэнне прасцейшае, калі вы перастанеце пытацца, ці сетка давераная, і пачнеце пытацца, які абмен перасякае якую мяжу.

Вырашайце па ўчастку, а не па сетцы

Запішыце канцавыя пункты асобна: канцавы пункт аўтарызацыі, канцавы пункт токена, URI перанакіравання, URL сервера рэсурсаў, пункт завяршэння TLS і шлюз VPN. Затым адзначце, які бок пачынае кожны запыт і куды ідзе адказ.

VPN, які завяршаецца на шлюзе, шыфруе сегмент да гэтага шлюза. Запыт можа працягвацца як звычайны HTTP за ім, і гэты астатні ўчастак не стаў HTTPS таму, што папярэдні сегмент быў зашыфраваны. Менавіта гэтае працягванне і ёсць участак, які важны для пратакола. Шыфраванне першага кроку не робіць другі крок бяспечным.

Перанос таксама нясе праверку ідэнтычнасці сэрвісу. Браўзер правярае сертыфікат для URL праграмы; VPN не выконвае гэтую праверку за браўзер і не робіць неправераны канцавы пункт прымальным. Сертыфікат называе канцавы пункт, які кліент лічыць тым, да якога звяртаецца. Тунель да шлюза не пераймяноўвае гэты канцавы пункт і не правярае яго.

Адказ аўтарызацыі і URI перанакіравання

Найлепшая бягучая практыка бяспекі OAuth забараняе перадачу адказаў аўтарызацыі праз незашыфраваныя злучэнні. Гэта датычыцца перанакіравання, якое нясе код аўтарызацыі або токены назад кліенту, а не толькі пачатковага запыту.

Тыя ж рэкамендацыі забараняюць URI перанакіравання HTTP, акрамя пазначанага выпадку loopback для native-кліента. Унутранае імя хаста не стварае новага выключэння, а імя DNS, якое вырашаецца толькі ўнутры VPN, усё яшчэ з'яўляецца HTTP URL, калі схема так кажа. Правярайце схему ў зарэгістраваным URI, а не толькі імя хаста.

Зарэгіструйце дакладны URI перанакіравання HTTPS на серверы аўтарызацыі і трымайце праверку сертыфіката ўключанай на кліенце. Скарочаны шлях распрацоўкі, які заглушае патрабаванне HTTPS, стварае паток, які паводзіць сябе інакш, чым прадукцыйная канфігурацыя, якую ён павінен мадэляваць.

Канцавы пункт токена і запыты носьбітнага токена

Запыт токена нясе ўліковыя даныя або код, які можна абмяняць на доступ. Адпраўка яго праз незасцеражаны ўчастак адкрывае матэрыял, якому сервер рэсурсаў пазней будзе давяраць, нават калі навакольная сетка прыватная. Праксі, які можа прачытаць запыт, можа таксама прачытаць уліковыя даныя, якія ён нясе.

Для запытаў да рэсурсаў з носьбітным токенам RFC 6750 лічыць TLS абавязковым для рэалізацыі і выкарыстання ў гэтай спецыфікацыі. Называнне офіснай падсеткі даверанай не з'яўляецца агульным выключэннем пратакола, якое патрэбна разгортванню з адкрытым тэкстам носьбітных токенаў.

Выкарыстоўвайце дакументаваныя бяспечныя URL канцавых пунктаў для абодвух участкаў. Калі бібліятэка адмаўляецца выклікаць канцавы пункт токена HTTP, гэтае адмаўленне — гэта спецыфікацыя, якая працуе, а не памылка канфігурацыі, якую трэба абыходзіць. Запішыце гэты URL у канфігурацыі кліента, а не выводзьце яго ў час выканання.

Дзе завяршаецца TLS і што застаецца пасля

Калі TLS завяршаецца на ўпаўнаважаным фронтэндзе, назавіце гэты фронтэнд і перагледзьце шлях ад яго да праграмы. Фронтэнд становіцца адказным за перасылку, давер і канфідэнцыяльнасць на астатнім сегменце, і падтрыманая архітэктура сэрвісу павінна апісваць гэтае ўладкаванне.

VPN у іншым месцы шляху не вырашае гэтыя абавязкі. Ён таксама не кажа, ці URL праграмы, які бачыць браўзер, адпавядае сертыфікату, які паказвае фронтэнд.

Для ўнутранага разгортвання запішыце пункт завяршэння і ідэнтычнасць, якую ён паказвае. Фронтэнд, які завяршае TLS сертыфікатам для іншага імя, стварае папярэджанне браўзера, якое аператары часта заглушаюць замест таго, каб выправіць.

Выключэнне для native loopback вузкае

Выключэнне перанакіравання loopback датычыцца зваротнага выкліку на ўласнай прыладзе карыстальніка, дзе кліент і браўзер дзеляць гэтую прыладу. Гэтае ўладкаванне належыць зваротнаму выкліку на адной прыладзе і не дае права абслугоўваць звычайны сервер аўтарызацыі або API з токенамі праз HTTP для офіснай падсеткі.

Трымайце выключэнне ў межах тыпу кліента і зваротнага выкліку, які яно апісвае. Яго прымяненне да вэб-праграмы, агульнага ўнутранага сэрвісу або URI перанакіравання на іншым хасце змяняе разгортванне, а не выключэнне.

Праверце фактычны паток на кожнай мяжы і параўнайце яго з тыпам кліента. Працуючае перанакіраванне нічога не кажа пра тое, ці кожны ўчастак, які нёс токен, выкарыстаў патрабаваную ахову, а зялёная іконка VPN нічога не кажа пра схему наступнага запыту.