Laptop de serviciu pe un VPN personal: ce traversează de fapt

Conectarea unui laptop de firmă la un VPN de acasă îl plasează în două locuri simultan, iar întrebarea interesantă este mai mică și mai utilă decât cea alarmantă. Nimeni nu a tras un cablu Ethernet între birou și casă, iar nicio rută nu face din rețeaua de acasă o extensie a subrețelei corporative. Ce există este un singur punct final cu acces la ambele medii, iar trei mecanisme separate decid ce poate circula de fapt între ele. Parcurgerea acestor trei, de la punctul final spre exterior, produce un răspuns pe care un administrator poate acționa în locul unei dezbateri despre etichete.

Începeți de la punctul final, nu de la diagrama rețelei

Punctul final este locul unde se întâlnesc ambele conexiuni, deci acolo începe analiza: ce procese rulează, la ce pot ajunge și cine le controlează. O diagramă care arată doi nori conectați la un laptop este exactă și inutilă, pentru că implică o legătură care poate să nu existe. Înlocuiți-o cu o listă a aplicațiilor care pot vorbi cu fiecare mediu și notați sub ce cont rulează fiecare. Acest cadru menține și analiza proporțională, fiindcă un laptop cu două tuneluri nu este același obiect ca două rețele unite.

Acea listă este inventarul din care lucrează restul analizei. Dacă include un client de sincronizare, un profil de browser conectat în ambele medii și un agent de compilare cu credențiale, analiza are deja subiectele ei.

Trei puncte de traversare, analizate separat

Accesul aplicațiilor este primul punct de traversare și nu necesită nicio redirecționare. O filă de browser, un client de sincronizare sau un agent de compilare de pe punctul final pot citi dintr-o resursă dintr-un mediu și pot trimite date către o resursă din celălalt. Această capacitate există indiferent dacă sistemul de operare redirecționează pachete între interfețe, și exact acesta este mecanismul pe care oamenii îl ratează când concluzionează că lipsa unui pod înseamnă lipsa riscului. De aceea citirea listei aplicațiilor este mai informativă decât citirea listei interfețelor.

Identitatea și datele formează al doilea punct de traversare. Credențialele corporative, cookie-urile de sesiune, documentele descărcate și drepturile de administrare trăiesc pe punctul final, iar alăturarea la o altă rețea nu le dezvăluie de la sine. Ce se schimbă este mulțimea părților care ar putea influența punctul final cât timp acesta deține acele credențiale, iar aceasta este o întrebare despre fiabilitatea rețelei personale, nu despre rutare. Este o judecată pe care proprietarul punctului final nu o poate face singur, și la ea nu răspunde absența unei reguli de redirecționare.

Redirecționarea de rețea este a treia și singura care poate transforma laptopul într-un dispozitiv de tranzit. Redirecționarea IP, partajarea conexiunii la internet, un proxy sau o funcție de punte pot face asta, iar fiecare este o configurație care este fie activată, fie nu. Inspectați starea respectivă direct în loc să o deduceți din prezența unui client VPN. Pe o mașină administrată răspunsul este de obicei nu, iar verificarea lui transformă o presupunere într-un fapt care merită înregistrat.

Cereți o resursă, nu două rețele

Majoritatea cerințelor reale sunt mai înguste decât par la început: o consolă, o partajare de fișiere, o aplicație web internă. Formulați cerința astfel și lăsați proprietarul resursei să decidă dacă aparține acestui punct final. O cerere formulată ca unire a două rețele este greu de aprobat și ușor de refuzat; o cerere pentru un serviciu numit are un răspuns.

Dacă răspunsul este da, preferați calea acceptată cea mai îngustă și țineți-o în controalele existente ale organizației. Un al doilea profil administrat sau o intrare de aplicație cu sferă limitată păstrează monitorizarea și politica; o configurație personală concurentă le înlocuiește în tăcere, iar nimeni nu știe care câștigă după următoarea actualizare.

Includeți efectele DNS și de rutare

Rezolvarea numelor se schimbă în momentul în care un al doilea profil este activ. Un client personal poate impune propriul resolver, un browser poate folosi propriul DNS criptat, iar un tabel de politici poate direcționa numele interne către un alt server decât cel așteptat de configurația corporativă. Niciuna dintre acestea nu necesită redirecționare, și oricare poate trimite un nume de gazdă intern în locul greșit.

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

Capturați cele trei ieșiri înainte și după conectarea celui de-al doilea profil. Diferența dintre ele este efectul care ajunge efectiv la utilizator și este adesea mai mare decât schimbarea de rutare descrisă în tichet. Păstrați ambele capturi ca un recenzent ulterior să vadă ce s-a schimbat, nu ce s-a intenționat.

Verificați și păstrați o ieșire

Testați aplicația aprobată din procesul și contextul de utilizator reale, nu dintr-un shell de administrator pe aceeași mașină. Apoi confirmați că destinațiile nelegate rămân inaccesibile acolo unde proiectul o cere: o graniță pe care nimeni nu a testat-o este o graniță pe care nimeni nu o poate revendica. Deconectarea tunelului personal ar trebui să restaureze starea anterioară, iar acea restaurare merită verificată cât timp cineva încă privește.

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

Îndrumarul NIST despre arhitectura de încredere zero este util aici pentru că elimină locația în rețea ca sursă automată de încredere, iar aceasta este exact presupunerea în discuție. Întrebarea nu este dacă rețeaua de acasă este de încredere prin natura ei; ci cine poate ajunge la ce resursă, de la ce punct final și prin ce punct de aplicare. Răspundeți la aceste trei și păstrați dovezile împreună cu decizia.