Hva en tilgangsregel for vertsnavn kan bety på hvert nettverkslag
Et tjenestenavn kan håndheves på DNS-, nettleser-, proxy- eller brannmurnivå. Velg laget som ser identiteten du vil styre.
Tre personer ber om det samme med de samme ordene: blokkere tilgang til ett tjenestenavn. Den ene mener at en nettleser ikke skal åpne nettstedet, den andre at en desktop-taleclient ikke skal nå serveren sin, og den tredje at en gruppe entreprenører ikke skal bruke en bestemt intern applikasjon. Setningen er identisk, og håndhevingsmekanismene har nesten ingenting til felles.
Velg laget etter identifikatoren det faktisk kan se, og deretter etter klientene det dekker. Å begynne med en brannmurkommando du allerede kjenner, er hvordan regler ender med å blokkere ingenting, eller blokkere for mye.
Et navn er ikke en identitet som hvert lag kan kontrollere
Netfilter og lignende pakkefiltre ser adresser, protokoller og porter. De ser ikke vertsnavn, og når en pakke når dem, er navnet allerede slått opp. En regel skrevet mot en adresse er en regel om den adressen, uansett hvilket navn en bruker skrev for å nå den.
DNS-policy ligger tidligere i banen og ser spørringen, som er et annet objekt enn tilkoblingen som følger. Den styrer svarene en kontrollert resolver returnerer, ikke tilkoblinger som allerede var åpne, og ikke klienter som er satt opp for å omgå den resolveren. En oppslått adresse kan også endre seg mellom policygjennomgangen og den neste forespørselen, og derfor er et DNS-svar ikke en varig autorisasjonserklæring.
Høyere lag ser mer kontekst og dekker færre klienter. Den byttehandelen er hele emnet, og den forklarer hvorfor ingen enkelt rad i tabellen noen gang er det riktige svaret. Velg raden som ser identifikatoren policyen din faktisk handler om. Godta deretter dekningen den raden innebærer.
Hva hvert lag kan identifisere
Les tabellen fra den midterste kolonnen og utover: identifikatoren et lag kan se, bestemmer policyen det ærlig kan håndheve.
| 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 |
Et lag hører bare hjemme i policyen når identifikatoren det ser, samsvarer med identifikatoren du styrer. Tabellen forklarer også hvorfor en regel skrevet på ett lag sjelden overføres til et annet uten å bestemme på nytt hva den beskytter.
Der den åpenbare regelen svikter
En adresseregel er nøyaktig riktig for en tjeneste med en dedikert adresse du kontrollerer, og det eierskapet bør skrives inn i policyen. Den er nøyaktig feil for alt bak en delt innholdsleveringsadresse, der den samme regelen berører urelaterte tjenester, og et oppdatert DNS-svar ikke gjør regelen til vertsnavnautorisasjon.
En policy for administrert nettleser uttrykker en webbegrensning mer direkte enn en kopiert adresseliste, men den gjelder for nettleserne og profilene administrasjonssystemet styrer.
Den nettleserregelen gjør ingenting med en taleclient som sender UDP til en annen vert, og mønstrene defineres av det produktet, ikke av jokertegnkonvensjoner lånt fra et annet sted. En CONNECT-proxy mottar også vert og port for en tunellert forespørsel, og kan ikke lese banen inne i den krypterte sesjonen. Utform regelen rundt det protokollen avdekker. Skriv deretter ned hva den lar stå udekket, for det gapet er der den neste forespørselen kommer fra.
Velg etter klientene, ikke etter kommandoen
Spør hvilke klienter policyen må dekke, og hvilke den kan overse. En policy for administrert nettleser dekker det administrasjonssystemet når, og stopper ved nettlesergrensen. En resolverpolicy dekker alt som bruker resolveren din, som er et bredere sett, og den svikter åpent for alle som ikke gjør det.
For en tjeneste du drifter, er autorisasjon i applikasjonen sterkere enn noen nettverksgrense, fordi den følger kontoen og ikke banen. En VPN-rute er nåbarhet og ingenting mer: å kunne sende en pakke til en tjeneste er ikke tillatelse til å bruke den. Der identifikatoren som betyr noe er en bruker eller en kanaltillatelse, håndhev den der, og behandle nettverksregelen som et andre lag.
Skriv regelen i termer av ressursen
En forsvarlig policy navngir ressursen, identitetene, applikasjonene i omfang og banen som bærer dem, inkludert begge adressefamiliene i bruk. Den angir også hva som skjer med delt infrastruktur som regelen vil påvirke tilfeldig.
Den formuleringen produserer en beslutning noen kan revidere senere. En regel begrunnet med dagens oppslåtte adresse produserer en hendelse første gang adressen endres, og ingen vil kunne forklare hvorfor blokkeringen noen gang var riktig.