Wat 'n gasheernaam-toegangsreël op elke netwerklaag kan beteken
'n Diensnaam kan op DNS-, blaaier-, volmag- of firewallvlak afgedwing word. Kies die laag wat die identiteit sien wat jy bedoel om te bestuur.
Drie mense vra dieselfde ding in dieselfde woorde: blokkeer toegang tot een diensnaam. Die een bedoel dat 'n blaaier nie die werf mag oopmaak nie, 'n ander bedoel dat 'n rekenaarstemkliënt nie sy bediener mag bereik nie, en die derde bedoel dat 'n groep kontrakteurs nie 'n bepaalde interne toepassing mag gebruik nie. Die sin is identies, en die handhawingsmeganismes het amper niks gemeen nie.
Kies die laag op grond van die identifiseerder wat dit werklik kan sien, en dan op grond van die kliënte wat dit dek. Om by 'n firewall-bevel te begin wat jy reeds ken, is hoe reëls uiteindelik niks blokkeer nie, of te veel blokkeer.
'n Naam is nie 'n identiteit wat elke laag kan nagaan nie
Netfilter en soortgelyke pakketfilters sien adresse, protokolle en poorte. Hulle sien nie gasheername nie, en teen die tyd dat 'n pakket hulle bereik, is die naam reeds opgelos. 'n Reël wat teen 'n adres geskryf is, is 'n reël oor daardie adres, ongeag watter naam 'n gebruiker ingetik het om dit te bereik.
DNS-beleid sit vroeër in die pad en sien die navraag, wat 'n ander objek is as die verbinding wat daarop volg. Dit beheer die antwoorde wat 'n beheerde resolver terugstuur, nie verbindings wat reeds oop was nie, en nie kliënte wat ingestel is om daardie resolver te omseil nie. 'n Opgeloste adres kan ook verander tussen die beleidsoorsig en die volgende versoek, en daarom is 'n DNS-antwoord nie 'n duursame magtigingsverklaring nie.
Hoër lae sien meer konteks en dek minder kliënte. Daardie ruil is die hele onderwerp, en dit verduidelik waarom geen enkele ry van die tabel ooit die regte antwoord is nie. Kies die ry wat die identifiseerder sien waaroor jou beleid werklik gaan. Aanvaar dan die dekking wat daardie ry impliseer.
Wat elke laag kan identifiseer
Lees die tabel van die middelste kolom af uitwaarts: die identifiseerder wat 'n laag kan sien, bepaal die beleid wat dit eerlik kan handhaaf.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
'n Laag hoort net in die beleid wanneer die identifiseerder wat dit sien ooreenstem met die identifiseerder wat jy bestuur. Die tabel verduidelik ook waarom 'n reël wat op een laag geskryf is, selde na 'n ander oorgedra kan word sonder om weer te besluit wat dit beskerm.
Waar die ooglopende reël faal
'n Adresreël is heeltemal reg vir 'n diens met 'n toegewyde adres wat jy beheer, en daardie eienaarskap behoort in die beleid geskryf te word. Dit is heeltemal verkeerd vir enigiets agter 'n gedeelde inhoudleweringsadres, waar dieselfde reël onverwante dienste raak en 'n verfrisde DNS-antwoord nie die reël in gasheernaam-magtiging omskep nie.
'n Bestuurde blaaierbeleid druk 'n webbeperking meer direk uit as 'n gekopieerde adreslys, maar dit geld vir die blaaiers en profiele wat die bestuurstelsel beheer.
Daardie blaaierreël doen niks aan 'n stemkliënt wat UDP na 'n ander gasheer stuur nie, en sy patrone word deur daardie produk gedefinieer eerder as deur wildcard-konvensies wat elders geleen is. 'n CONNECT-volmag ontvang ook 'n gasheer en poort vir 'n tonnelversoek, en kan nie die pad binne die versleutelde sessie lees nie. Ontwerp die reël rondom wat die protokol blootlê. Skryf dan neer wat dit onbedek laat, want daardie gaping is waar die volgende versoek vandaan sal kom.
Kies volgens die kliënte, nie volgens die bevel nie
Vra watter kliënte die beleid moet dek en watter dit mag mis. 'n Bestuurde blaaierbeleid dek wat die bestuurstelsel bereik en stop by die blaaiergrens. 'n Resolverbeleid dek alles wat jou resolver gebruik, wat 'n breër versameling is, en dit faal oop vir enigiemand wat dit nie doen nie.
Vir 'n diens wat jy bedryf, is magtiging by die toepassing sterker as enige netwerkgrens, omdat dit die rekening volg eerder as die pad. 'n VPN-roete is bereikbaarheid en niks meer nie: die vermoë om 'n pakket na 'n diens te stuur is nie toestemming om dit te gebruik nie. Waar die identifiseerder wat saak maak 'n gebruiker of 'n kanaaltoestemming is, handhaaf dit daar en behandel die netwerkreël as 'n tweede laag.
Skryf die reël in terme van die hulpbron
'n Verdedigbare beleid noem die hulpbron, die identiteite, die toepassings binne die bestek en die pad wat hulle dra, insluitend albei adresfamilies wat in gebruik is. Dit sê ook wat gebeur met gedeelde infrastruktuur wat die reël terloops sal raak.
Daardie formulering lewer 'n besluit op wat iemand later kan oudit. 'n Reël wat deur vandag se opgeloste adres geregverdig word, lewer 'n voorval op die eerste keer dat die adres verander, en niemand sal kan verduidelik waarom die blokkade ooit korrek was nie.