Zergatik VPN arau batek ezin duen fitxategi bat igotzea eragotzi
Zerbitzu batera iristea eta hura zein fitxategik uzten duten kontrolatzea bi baldintza dira. Jarri araua fitxategia ikusgai dagoen tokian: posta, aplikazioa edo muturreko agentea.
Talde txiki batek urruneko sarbidea eskatzen du bere lan-sistemetara, eta arnasa berean eskatzen du zenbait eranskin enpresak uzteari uztea. Bi eskaerek VPN aldaketa bakar bat dirudite. Bi baldintza dira, betearazpen-puntu ezberdinekin, eta lehena betetzen duen arauak ez du ezer egiten bigarrenerako. Hasi ekintza eta datuak izendatzen, eta gero aukeratu benetan haiek ikus ditzakeen osagaia.
Eskaera bat, bi baldintza
Lehen baldintza irisgarritasunari buruzkoa da: zein erabiltzailek eta gailuk zein zerbitzutara konexioa ireki dezaketen. Bigarrena konexioa existitzen ondorengo jokabideari buruzkoa da: zein dokumentu erantsi, itsatsi edo igo daitezkeen. Tunelak lehenengoan eragiten du eta diseinuz itsua da bigarrenerako.
IP mailako kontrol batek paketeak birbidaltzen ditu. Ez du zatianitzeko igoera bat aztertzen, ez du PDF bat ikuskatzen, ez eta kalkulu-orri batek kontu-zenbakiak dituen erabakitzen. Hori harengandik espero izatea ez da konfigurazio-akatsa; kategoria-akatsa da.
Esan baldintza ozen forma horrekin produktu bat bilatu aurretik. «Erabiltzaileek fitxategi ataria iritsi dezakete» eta «erabiltzaileek ezin dituzte bezero-zerrendak fitxategi atarira igo» esaldi ezberdinak dira, eta bigarrenak soilik deskribatzen du eduki-politika bat.
Aukeratu fitxategia ikus dezakeen osagaia
Betearazpena fitxategia irakurgarria den tokian gertatu behar da. Postarentzat, normalean posta-plataforma edo atebidea da, dagoeneko eranskinak kudeatzen dituena eta bidalketa aurretik ebalua ditzakeena. Zerbitzu baimendu batera nabigatzailez egindako igoeretarako, aplikazioa bera izan daiteke edukia ikusten duen alderdi bakarra. Kudeatutako ordenagailu eramangarri batek fitxategiak euskarri aldagarrietara kopiatzen dituenean, muturreko agente batek ikusten du eragiketa.
| 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 |
Komer-talde batzuek muturreko agentea, web-kontrola eta datu-galeraren prebentzio modulua batera ematen dituzte. Osagai horiek eduki-politika betearaz dezakete, baina gaitasuna moduluarena da, ez tunelarena. Irakurri paketeak zer biltzen duen benetan emaitza agindu aurretik.
Microsoft-en Purview datu-galeraren prebentzioaren ikuspegi orokorra konparatzeko eredu erabilgarria da: politikak informazio sentikorraren moten, kokapenen eta jardueren arabera deskribatzen ditu. Hiztegi hori edukiaz eta ekintzez ari da, ez IP aurrizkiez.
TLS-k tunela bizirik gainditzen du, beraz planifikatu horretarako
Aplikazioaren zifratzea bezeroaren eta zerbitzuaren artean negoziatzen da, eta VPN tunelak byte horiek eramaten ditu ireki gabe. Beraz, bideko atebide batek ez du automatikoki eranskin bat sailkatzeko gaitasuna lortzen, ibilbidearen zatirik handiena berarena izan arren.
Bidean edukiak ikuskatzeko TLS ziurtagiri fidagarri batekin amaitzen duen osagai bat behar duzu, eta hori arkitektura-erabaki garrantzitsua da, pribatutasun eta eragiketa ondorio propioekin. Ez da VPN profileko kontrol-lauki bat. Bezeroek ikuskapen-ziurtagirian fidatu behar dute, ziurtagiriak finkatzen dituzten aplikazioak hautsi egingo dira, eta operadoreak lehen ezin zuen trafikoa irakurtzeko gaitasuna lortzen du. Hori da erabaki hau segurtasun-arduradun batena izateko arrazoia, tunela kudeatzen duenarena izan beharrean.
Horregatik «VPN-ak igoera hau blokea dezake» galderaren erantzun zintzoa ez da izaten, normalean, eta ondoren alternatiba zehatz bat dator. Alternatiba aplikazio mailako murrizketak, posta-arau bat edo muturreko politika bat izan daiteke, eta bakoitzak aldatu dezakeen arduradun bat du.
Idatzi onarpen-proba araua baino lehen
Eduki-arau batek bi adibide behar ditu, ez bat: funtzionatzen jarraitu behar duen ekintza baimendua eta gelditu behar den ekintza debekatua. Probatu biak eskura dauden aplikazioetatik eta gailuetatik, nabigatzaile bakarrean funtzionatzen duen politika ez baita inork eskatutako politika.
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/uploadLehen eskaera araua duen osagaiak ukatu behar du, eta bigarrenak arrakasta izan behar du. Biak arrakastatsuak badira, kontrola ez dago bidean. Biak huts egiten badute, zerbitzua hautsi duzu babestu beharrean, eta hori da baimendutako adibiderik gabe idatzitako arau baten emaitza ohikoena.
Erabaki aldez aurretik erabiltzaileak zer ikusten duen, nork eman dezakeen salbuespen bat eta non berretsiko duen administratzaileak erabakia geroago. Mezurik gabeko igoera blokeatuak laguntza-txartel bat sortzen du, eta inork auditatu ezin duen arauak eztabaida bat. Biak saihestu daitezke politika indarrean jarri aurretik idatzitako dokumentazio-esaldi batekin.
Amaitzeko, eduki bi baldintzak txartel bereizietan arduradun bereiziekin. «VPN» azpian biltzeak bermatzen du sare-taldeari eduki-arazo bat konpontzeko eskatuko zaiola, eta eduki-arazoa konpondutzat joko dela tunela altxatzen denean.