Hvad en adgangsregel for værtsnavne kan betyde på hvert netværkslag
Et tjenestenavn kan håndhæves på DNS-, browser-, proxy- eller firewalniveau. Vælg det lag, der ser den identitet, du vil styre.
Tre personer beder om det samme med de samme ord: bloker adgang til ét tjenestenavn. Den ene mener, at en browser ikke må åbne webstedet, den anden mener, at en desktop-taleclient ikke må nå sin server, og den tredje mener, at en gruppe entreprenører ikke må bruge en bestemt intern applikation. Sætningen er identisk, og håndhævelsesmekanismerne har næsten intet til fælles.
Vælg laget efter den identifikator, det faktisk kan se, og derefter efter de klienter, det dækker. At starte med en firewallkommando, du allerede kender, er hvordan regler ender med at blokere intet eller blokere for meget.
Et navn er ikke en identitet, som hvert lag kan kontrollere
Netfilter og lignende pakkefiltre ser adresser, protokoller og porte. De ser ikke værtsnavne, og når en pakke når dem, er navnet allerede opløst. En regel skrevet mod en adresse er en regel om den adresse, uanset hvilket navn en bruger skrev for at nå den.
DNS-politik ligger tidligere på vejen og ser forespørgslen, som er et andet objekt end den forbindelse, der følger. Den styrer de svar, en kontrolleret resolver returnerer, ikke forbindelser, der allerede var åbne, og ikke klienter, der er konfigureret til at omgå den resolver. En opløst adresse kan også ændre sig mellem politikeftersynet og den næste anmodning, og derfor er et DNS-svar ikke en varig autorisationserklæring.
Højere lag ser mere kontekst og dækker færre klienter. Den byttehandel er hele emnet, og den forklarer, hvorfor ingen enkelt række i tabellen nogensinde er det rigtige svar. Vælg den række, der ser den identifikator, din politik faktisk handler om. Acceptér derefter den dækning, den række indebærer.
Hvad hvert lag kan identificere
Læs tabellen fra den midterste kolonne og udad: den identifikator, et lag kan se, bestemmer den politik, det ærligt kan håndhæve.
| 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 kun hjemme i politikken, når den identifikator, det ser, matcher den identifikator, du styrer. Tabellen forklarer også, hvorfor en regel skrevet på ét lag sjældent overføres til et andet uden at beslutte igen, hvad den beskytter.
Hvor den indlysende regel fejler
En adresseregel er præcis rigtig for en tjeneste med en dedikeret adresse, du kontrollerer, og det ejerskab bør skrives ind i politikken. Den er præcis forkert for alt bag en delt indholdsleveringsadresse, hvor den samme regel berører urelaterede tjenester, og et opdateret DNS-svar ikke gør reglen til værtsnavneautorisation.
En administreret browserpolitik udtrykker en webbegrænsning mere direkte end en kopieret adresseliste, men den gælder for de browsere og profiler, som administrationssystemet styrer.
Den browserregel gør intet ved en taleclient, der sender UDP til en anden vært, og dens mønstre defineres af det produkt snarere end af jokertegnskonventioner lånt fra et andet sted. En CONNECT-proxy modtager også en vært og port til en tunelleret anmodning og kan ikke læse stien inde i den krypterede session. Design reglen omkring det, protokollen afslører. Skriv derefter ned, hvad den efterlader udækket, for det hul er, hvor den næste anmodning kommer fra.
Vælg efter klienterne, ikke efter kommandoen
Spørg, hvilke klienter politikken skal dække, og hvilke den må overse. En administreret browserpolitik dækker det, administrationssystemet når, og stopper ved browsergrænsen. En resolverpolitik dækker alt, der bruger din resolver, hvilket er et bredere sæt, og fejler åbent for alle, der ikke gør.
For en tjeneste, du driver, er autorisation i applikationen stærkere end nogen netværksgrænse, fordi den følger kontoen frem for stien. En VPN-rute er nåbarhed og intet mere: at kunne sende en pakke til en tjeneste er ikke tilladelse til at bruge den. Hvor den identifikator, der betyder noget, er en bruger eller en kanaltilladelse, håndhæv den der, og behandl netværksreglen som et andet lag.
Skriv reglen i resursens termer
En forsvarlig politik navngiver ressourcen, identiteterne, applikationerne i omfang og den sti, der bærer dem, inklusive begge adressefamilier i brug. Den angiver også, hvad der sker med delt infrastruktur, som reglen vil påvirke utilsigtet.
Den formulering producerer en beslutning, som nogen kan revidere senere. En regel begrundet i dagens opløste adresse producerer en hændelse, første gang adressen ændres, og ingen vil kunne forklare, hvorfor blokeringen nogensinde var korrekt.