Pse një rregull VPN nuk mund të ndalojë ngarkimin e një skedari
Të arrish një shërbim dhe të kontrollosh cilat skedarë dalin prej tij janë dy kërkesa. Vendosni rregullin aty ku skedari është i dukshëm: postë, aplikacion ose agjent i pikës fundore.
Një ekip i vogël kërkon akses në distancë në sistemet e tij të punës dhe, në të njëjtën frymë, kërkon që disa bashkëngjitje të ndalojnë së lëni kompaninë. Të dyja kërkesat tingëllojnë si një ndryshim i vetëm VPN. Janë dy kërkesa me pika të ndryshme zbatimi, dhe një rregull që plotëson të parën nuk bën asgjë për të dytën. Filloni duke emërtuar veprimin dhe të dhënat, pastaj zgjidhni komponentin që vërtet mund t'i shohë ato.
Një kërkesë, dy kushte
Kërkesa e parë ka të bëjë me arritshmërinë: cilët përdorues dhe pajisje mund të hapin një lidhje me cilin shërbim. E dyta ka të bëjë me sjelljen pasi ekziston ajo lidhje: cilat dokumente mund të bashkëngjiten, të ngjiten ose të ngarkohen. Një tunel vepron mbi të parën dhe është i verbër ndaj të dytës sipas dizajnit.
Një kontroll në nivel IP përçon paketa. Ai nuk analizon një ngarkim me shumë pjesë, nuk inspekton një PDF dhe nuk vendos nëse një fletëllogaritëse përmban numra llogarie. Të presësh këtë prej tij nuk është gabim konfigurimi; është gabim kategorie.
Thuajeni kërkesën me zë të lartë në atë formë përpara se të kërkoni një produkt. «Përdoruesit mund të arrijnë portalin e skedarëve» dhe «përdoruesit nuk mund të ngarkojnë lista klientësh në portalin e skedarëve» janë fjali të ndryshme, dhe vetëm e dyta përshkruan një politikë përmbajtjeje.
Zgjidhni komponentin që mund të shohë skedarin
Zbatimi duhet të ndodhë aty ku skedari është i lexueshëm. Për emailin, zakonisht është platforma ose porta e postës, e cila tashmë trajton bashkëngjitjet dhe mund t'i vlerësojë ato përpara dorëzimit. Për ngarkimet nga shfletuesi në një shërbim të miratuar, vetë aplikacioni mund të jetë pala e vetme që sheh përmbajtjen. Për një laptop të menaxhuar që kopjon skedarë në media të lëvizshme, një agjent i pikës fundore e sheh veprimin.
| 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 |
Disa paketa komerciale të aksesit në distancë bashkojnë një agjent të pikës fundore, një kontroll web dhe një modul parandalimi të humbjes së të dhënave. Ata komponentë mund të zbatojnë politikën e përmbajtjes, por aftësia i takon modulit dhe jo tunelimit. Lexoni çfarë përfshin vërtet paketa përpara se të premtoni rezultatin.
Një model i dobishëm për krahasim është përmbledhja e Purview për parandalimin e humbjes së të dhënave nga Microsoft: përshkruan politikat në terma të llojeve të informacionit të ndjeshëm, vendndodhjeve dhe aktiviteteve. Ai fjalor ka të bëjë me përmbajtjen dhe veprimet, jo me prefikset IP.
TLS i mbijeton tunelit, prandaj planifikojeni
Kriptimi i aplikacionit negociohet midis klientit dhe shërbimit, dhe një tunel VPN i transporton ato bajt pa i hapur. Prandaj një portë në rrugë nuk fiton automatikisht aftësinë për të klasifikuar një bashkëngjitje, sado pjesë e rrugës që zotëron.
Për të inspektuar përmbajtjen gjatë transitit ju nevojitet një komponent që përfundon TLS me një certifikatë të besuar, dhe ky është një vendim i rëndësishëm arkitekturor me pasoja të vetat për privatësinë dhe operimin. Nuk është një kuti kontrolli në profilin VPN. Klientët duhet të besojnë certifikatën e inspektimit, aplikacionet që fiksojnë certifikatat do të thyhen, dhe operatori fiton aftësinë për të lexuar trafik që më parë nuk mund ta lexonte. Këto janë arsyet pse ky vendim i takon një pronari të sigurisë dhe jo atij që drejton tunelin.
Prandaj përgjigjja e sinqertë ndaj «a mund ta bllokojë VPN-ja këtë ngarkim» është zakonisht jo, e ndjekur nga një alternativë konkrete. Alternativa mund të jenë kufizime në nivel aplikacioni, një rregull poste ose një politikë e pikës fundore, dhe secila ka një pronar që mund ta ndryshojë.
Shkruani testin e pranimit përpara rregullit
Një rregull përmbajtjeje kërkon dy shembuj, jo një: një veprim të lejuar që duhet të vazhdojë të funksionojë dhe një veprim të ndaluar që duhet të ndalet. Provoji të dyja nga aplikacionet dhe pajisjet në fushëveprim, sepse një politikë që funksionon vetëm në një shfletues nuk është politika që kërkoi dikush.
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/uploadKërkesën e parë duhet ta refuzojë komponenti që zotëron rregullin, dhe e dyta duhet të ketë sukses. Nëse të dyja kanë sukses, kontrolli nuk është në rrugë. Nëse të dyja dështojnë, keni prishur shërbimin në vend që ta mbroshin, që është rezultati më i zakonshëm i një rregulli të shkruar pa një shembull të lejuar.
Vendosni para kohe çfarë sheh përdoruesi, kush mund të japë një përjashtim dhe ku administratori e konfirmon vendimin më pas. Një ngarkim i bllokuar pa mesazh prodhon një tiketë mbështetjeje, dhe një rregull që askush nuk mund ta auditojë prodhon një debat. Të dyja shmangen me një fjali dokumentacioni të shkruar përpara se politika të hyjë në fuqi.
Së fundi, mbani dy kërkesat në tiketa të veçanta me pronarë të veçantë. Bashkimi i tyre nën «VPN» garanton që ekipi i rrjetit do të kërkohet të zgjidhë një problem përmbajtjeje dhe që problemi i përmbajtjes do të shpallet i zgjidhur kur tuneli ngrihet.