Треба ли вам још VPN ако користите Identity-Aware Proxy?

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

Два пролаза ауторизирају различите ствари

Пролаз апликације одлучује смије ли овај захтјев, од овог идентитета, доћи до овог заштићеног ресурса. Гооглеов преглед Identity-Aware Proxy описује управо тај облик: средишњи слој ауторизације испред HTTPS апликација, којим управља IAM улога. Граница је ресурс, а јединица приступа је захтјев. Рутирани VPN ради нешто грубље и шире: пушта клијента у дефинирани мрежни обим, након чега апликација и даље одлучује шта тај клијент смије.

Ниједан модел не подразумијева други. Пролазак кроз пролаз не говори ништа о читању одређеног записа, а боравак на мрежи не говори ништа о допуштењу да се дјелује.

Шта прокси не покрива, а VPN покрива

SSH сесије, клијенти база података, брокери порука и интерна имена хостова која ниједан прегледник никад не отвори не постају доступни само зато што постоји веб прокси. Сваки говори свој протокол, и сваком треба или властита аутентифицирана путања или мрежа која га носи. То је празнина коју људи открију првог дана миграције, обично од дежурног инжењера с лаптопом који више не може разријешити име хоста.

Обрнута празнина је једнако стварна. VPN који пушта клијента у подмрежу не аутентифицира особу унутар ње, а компромитирани уређај на тој подмрежи насљеђује све што мрежа допушта. Ако је захтјев ауторизација по сваком захтјеву с ревизијски провјерљивим идентитетом, само рутирање то не може произвести. Већина организација на крају води обоје, а занимљиво питање је којим ресурсима је свакоме допуштено стајати на челу.

Ток рада клијента одлучује више од архитектонског дијаграма

Пријава у прегледнику с преусмјеравањем и повременим MFA изазовом добро је искуство за особу која кликне на забиљешку. Црон посао, CLI или буилд агент нема прегледник и не може одговорити на интерактивни упит, па му треба документирана неинтерактивна путања или тунел. Откриће тог захтјева обично се догоди након што је дизајн одобрен.

Пребројите клијенте прије него пребројите апликације. Једна надзорна плоча може служити стотину људи; један порт базе података може блокирати цијели тим.

Стање уређаја није својство ниједног пролаза

Инсталација VPN клијента није провјера усклађености, а дизајн темељен на прегледнику није аутоматски неспособан поштовати политику управљаних уређаја. Оба се могу интегрирати са сигналима стања, и оба се могу увести без њих. Питајте каква присила постоји, ко посједује политику и шта се догађа с уређајем који је прекрши, умјесто да то закључујете из облика производа.

Исти опрез вриједи и за уклањање приступа. Брисање чланства у групи на проксију и опозив цертификата за тунел различите су операције с различитим кашњењем, а једна од њих се обично заборави при оффбоардингу.

Пронађите алтернативне путање прије него било шта умировите

Незаштићени извор иза проксија, друго име хоста које га заобилази или широка приватна рута остала из ранијег дизајна одредит ће који пролаз заправо важи. Тестирајте допуштену и одбијену операцију кроз стварног клијента, не кроз конзолу, и тестирајте их с уређаја који никад није био уписан. Одбијени случај је онај који вам каже ради ли пролаз уопће икакав посао.

Затим напишите примопредају: упис, ажурирања, уклањање приступа и пут опоравка за некога закључаног у 2 сата ујутро. Уклањање упита или клијентске апликације премјешта одговорност међу тимовима; оно не брише одговорност.

Ако одлучујете овог тједна, почните с пописом операција, а не производа, означите које прегледник може извести, а остале нека оправдају мрежни приступ који преживи.