De ce o regulă VPN nu poate opri încărcarea unui singur fișier
A ajunge la un serviciu și a controla ce fișiere ies din el sunt două cerințe. Puneți regula acolo unde fișierul este vizibil: e-mail, aplicație sau agent de punct final.
O echipă mică cere acces de la distanță la sistemele sale de lucru și, în aceeași respirație, cere ca anumite atașamente să nu mai părăsească firma. Ambele cereri sună ca o singură schimbare de VPN. Sunt două cerințe cu puncte diferite de aplicare, iar o regulă care o satisface pe prima nu face nimic pentru a doua. Începeți prin a numi acțiunea și datele, apoi alegeți componenta care chiar le poate vedea.
O cerere, două cerințe
Prima cerință privește accesibilitatea: ce utilizatori și dispozitive pot deschide o conexiune către ce serviciu. A doua privește comportamentul după ce conexiunea există: ce documente pot fi atașate, lipite sau încărcate. Un tunel acționează asupra primei și este orb la a doua prin proiectare.
Un control la nivel de IP redirecționează pachete. Nu analizează o încărcare în mai multe părți, nu inspectează un PDF și nu decide dacă un tabel conține numere de cont. A aștepta asta de la el nu este o eroare de configurare; este o eroare de categorie.
Spuneți cerința cu voce tare în această formă înainte de a căuta un produs. „Utilizatorii pot ajunge la portalul de fișiere” și „utilizatorii nu pot încărca liste de clienți pe portalul de fișiere” sunt propoziții diferite, iar doar a doua descrie o politică de conținut.
Alegeți componenta care poate vedea fișierul
Aplicarea trebuie să aibă loc acolo unde fișierul este lizibil. Pentru e-mail, este de obicei platforma sau gateway-ul de poștă, care gestionează deja atașamentele și le poate evalua înainte de livrare. Pentru încărcările din browser către un serviciu aprobat, aplicația însăși poate fi singura parte care vede conținutul. Pentru un laptop administrat care copiază fișiere pe medii amovibile, un agent de punct final vede operațiunea.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
Unele pachete comerciale de acces la distanță reunesc un agent de punct final, un control web și un modul de prevenire a pierderii de date. Acele componente pot aplica politica de conținut, dar capacitatea aparține modulului și nu tunelării. Citiți ce include de fapt pachetul înainte de a promite rezultatul.
Un model util de comparație este prezentarea generală a prevenirii pierderii de date din Purview de la Microsoft: descrie politicile în termeni de tipuri de informații sensibile, locații și activități. Vocabularul acela este despre conținut și acțiuni, nu despre prefixe IP.
TLS supraviețuiește tunelului, așa că planificați pentru asta
Criptarea aplicației este negociată între client și serviciu, iar un tunel VPN transportă acei octeți fără a-i deschide. Un gateway pe traseu nu dobândește deci automat capacitatea de a clasifica un atașament, oricât de mult din rută ar deține.
Pentru a inspecta conținut în tranzit aveți nevoie de o componentă care termină TLS cu un certificat de încredere, iar aceasta este o decizie arhitecturală importantă, cu propriile consecințe de confidențialitate și operare. Nu este o bifă din profilul VPN. Clienții trebuie să aibă încredere în certificatul de inspecție, aplicațiile care fixează certificate se vor rupe, iar operatorul câștigă capacitatea de a citi trafic pe care înainte nu îl putea citi. Acestea sunt motivele pentru care decizia aparține unui responsabil de securitate și nu celui care operează tunelul.
De aceea răspunsul onest la „poate VPN-ul să blocheze această încărcare” este de obicei nu, urmat de o alternativă concretă. Alternativa poate fi restricții la nivel de aplicație, o regulă de e-mail sau o politică de punct final, iar fiecare are un responsabil care o poate schimba.
Scrieți testul de acceptare înainte de regulă
O regulă de conținut are nevoie de două exemple, nu de unul: o acțiune permisă care trebuie să continue să funcționeze și o acțiune interzisă care trebuie oprită. Testați ambele din aplicațiile și dispozitivele din scop, pentru că o politică ce funcționează doar într-un browser nu este politica pe care a cerut-o cineva.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadPrima cerere ar trebui refuzată de componenta care deține regula, iar a doua ar trebui să reușească. Dacă ambele reușesc, controlul nu este pe traseu. Dacă ambele eșuează, ați stricat serviciul în loc să îl protejați, ceea ce este rezultatul mai frecvent al unei reguli scrise fără un exemplu permis.
Decideți dinainte ce vede utilizatorul, cine poate acorda o excepție și unde un administrator confirmă decizia ulterior. O încărcare blocată fără mesaj produce un tichet de asistență, iar o regulă pe care nimeni nu o poate audita produce o dispută. Ambele pot fi evitate cu o propoziție de documentație scrisă înainte ca politica să intre în vigoare.
În final, țineți cele două cerințe în tichete separate cu responsabili separați. Gruparea lor sub „VPN” garantează că echipa de rețea va fi rugată să rezolve o problemă de conținut și că problema de conținut va fi declarată rezolvată când tunelul pornește.