Mutarea unei aplicații web de firmă în spatele VPN-ului: ghid pentru tranziție

Imaginați-vă schimbarea din partea utilizatorului. Cineva dă clic pe un semn de carte, așteaptă pagina de autentificare cunoscută și primește în schimb o eroare de conexiune, pentru că numele de gazdă răspunde acum doar în interiorul tunelului. Acel singur moment conține tot ce trebuie să facă bine planul de migrare: numele, calea, certificatul, contul și operațiunea din spatele lor. Parcurgeți pașii de mai jos în această ordine și tranziția încetează să mai fie o săritură.

Pasul 1: notați ce fac utilizatorii astăzi

Începeți cu numele de gazdă din bara de adrese, portul, operațiunile pe care le fac oamenii și conturile pe care le folosesc. Dacă nu puteți numi cele trei operațiuni principale, nu sunteți pregătit să închideți intrarea publică, pentru că nu veți recunoaște una defectă în timpul acceptării.

Apoi decideți cine este publicul privat. Angajații din VPN-ul corporativ sunt un început, nu un răspuns. Contractorii, personalul de suport și echipa financiară pot avea toți nevoie de aplicație și este posibil să nu stea toți în spatele aceleiași porți de acces.

Pasul 2: separați tunelul de autentificare

Când utilizatorul ajunge la aplicație prin VPN, browserul deschide în continuare o conexiune TLS către punctul final propriu al aplicației. Certificatul trebuie să corespundă acelui nume, iar aplicația autentifică în continuare contul. Nimic din tunel nu înlocuiește niciuna dintre ele.

Aici migrările merg prost în liniște. Cineva decide că adresa privată nu mai are nevoie de un certificat valid, utilizatorii învață să dea clic printr-un avertisment, iar organizația a schimbat o expunere publică pe un program de instruire în ignorarea avertismentelor de securitate. Dacă aplicația are într-adevăr nevoie de un certificat intern, emiteți unul de la autoritatea internă și distribuiți încrederea corect. Aceasta este o schimbare controlată; o pagină de avertisment nu este.

Păstrați autorizarea acolo unde este deja. Rezumatul arhitecturii zero-trust al NIST spune lucrul acesta direct: locația în rețea nu este un motiv pentru a acorda o operațiune sensibilă. Faptul de a fi în interiorul tunelului nu ar trebui să transforme un cont doar-citire într-un administrator.

Pasul 3: găsiți apelanții care nu sunt angajați

Deschideți configurația aplicației și listați tot ce vorbește cu ea: URL-ul de apel invers al furnizorului de identitate, webhook-ul unui furnizor de plăți, un import programat, o sondă de monitorizare, clientul API al unui partener. Fiecare este o dependență cu un proprietar, și fiecare se va rupe într-un moment diferit.

Decideți o cale susținută pentru fiecare care trebuie să rămână. Un furnizor de webhook nu se poate alătura VPN-ului dumneavoastră de angajați, așa că fie expuneți un punct final de integrare strict delimitat cu propria autentificare, fie schimbați modelul de integrare. A lăsa întreaga aplicație publică pentru că există un apel invers este o alegere, și de obicei cea greșită.

Notați fiecare excepție cu destinație, operațiune permisă, autentificare și proprietar. Un cont VPN generic dat unei integrări este modul în care o excepție devine permanentă. Revizuiți lista la următoarea revizuire a accesului, pentru că integrările trăiesc mai mult decât proiectele care le-au adăugat. O excepție fără dată de expirare este o decizie de design permanentă pe care nimeni nu a luat-o.

Pasul 4: retrageți ruta publică, nu doar înregistrarea DNS

Parcurgeți lanțul de publicare: DNS, ascultătorii balansatorului de încărcare, regulile proxy-ului invers, firewall-ul gazdei și orice nume alternativ care mai indică adresa veche. Verificați ambele familii de adrese. Schimbarea înregistrării A principale nu demonstrează aproape nimic dacă un CNAME mai vechi sau un ascultător IPv6 mai servește aplicația.

În paralel, confirmați că numele privat se rezolvă în interiorul tunelului și că certificatul acoperă numele pe care utilizatorii îl vor tasta. Un utilizator care trebuie să lipească o adresă numerică a găsit un simptom, nu o soluție.

Limitați publicul VPN-ului la calea aplicației. Accesul larg la rețeaua de birou schimbă o decizie de expunere pe una mai mare, iar interfețele administrative au nevoie de propriile surse permise în loc să moștenească regula de utilizator.

Pasul 5: parcurgeți acceptarea singur

Conectați-vă ca utilizator aprobat, deschideți semnul de carte, verificați certificatul, autentificați-vă și executați o operațiune reală. Apoi încercați un cont care nu ar trebui să aibă acea operațiune și confirmați că este refuzat. Apoi încercați de pe un dispozitiv din afara VPN-ului și confirmați că aplicația este inaccesibilă.

Repetați pentru fiecare integrare păstrată și citiți jurnalul de livrare al furnizorului în loc să presupuneți că un 200 din propria unealtă de test este același lucru. O autentificare VPN reușită nu este dovadă pentru niciunul dintre aceste rezultate.

Pasul 6: exersați ziua proastă

Decideți ce se întâmplă în timpul unei întreruperi a tunelului: munca se oprește sau preia o altă metodă de acces aprobată. Orice ați alege, notați și testați o dată, pentru că redeschiderea publică de urgență ca mecanism de recuperare nedocumentat va fi executată în cele din urmă de cineva sub presiune.

Păstrați accesul de recuperare pentru administratorii care întrețin poarta de acces și aplicația, cu un proprietar și o dată de eliminare. Înregistrați schimbarea și condițiile ei de revenire în același loc, astfel încât o migrare eșuată să nu-i blocheze pe cei care ar repara-o.

După tranziție, aplicarea patch-urilor, ciclul de viață al conturilor, autorizarea aplicației și auditul rămân ale dumneavoastră. Tunelul a îngustat intrarea; nu a preluat niciuna dintre aceste sarcini.