Vad en åtkomstregel för värdnamn kan betyda på varje nätverkslager
Ett tjänstenamn kan genomdrivas på DNS-, webbläsar-, proxy- eller brandväggsnivå. Välj det lager som ser den identitet du vill styra.
Tre personer ber om samma sak med samma ord: blockera åtkomst till ett tjänstenamn. En menar att en webbläsare inte ska öppna webbplatsen, en annan att en skrivbordsröstklient inte ska nå sin server, och den tredje att en grupp entreprenörer inte ska använda en viss intern applikation. Meningen är identisk, och genomdrivandemekanismerna har nästan ingenting gemensamt.
Välj lagret efter den identifierare det faktiskt kan se, och sedan efter de klienter det täcker. Att börja med ett brandväggskommando du redan känner till är hur regler till slut blockerar ingenting, eller blockerar för mycket.
Ett namn är inte en identitet som varje lager kan kontrollera
Netfilter och liknande paketfilter ser adresser, protokoll och portar. De ser inte värdnamn, och när ett paket når dem är namnet redan upplöst. En regel skriven mot en adress är en regel om den adressen, vilket namn en användare än skrev för att nå den.
DNS-policy ligger tidigare i vägen och ser frågan, som är ett annat objekt än anslutningen som följer. Den styr svaren en kontrollerad resolver returnerar, inte anslutningar som redan var öppna, och inte klienter som konfigurerats att kringgå den resolvern. En upplöst adress kan också ändras mellan policygenomgången och nästa begäran, därför är ett DNS-svar inte ett varaktigt auktoriseringspåstående.
Högre lager ser mer sammanhang och täcker färre klienter. Det bytet är hela ämnet, och det förklarar varför ingen enskild rad i tabellen någonsin är rätt svar. Välj den rad som ser den identifierare din policy faktiskt handlar om. Acceptera sedan den täckning den raden innebär.
Vad varje lager kan identifiera
Läs tabellen från den mellersta kolumnen och utåt: den identifierare ett lager kan se avgör den policy det ärligt kan genomdriva.
| 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 |
Ett lager hör bara hemma i policyn när den identifierare det ser stämmer med den identifierare du styr. Tabellen förklarar också varför en regel skriven på ett lager sällan överförs till ett annat utan att man återigen beslutar vad den skyddar.
Där den uppenbara regeln misslyckas
En adressregel är exakt rätt för en tjänst med en dedikerad adress du kontrollerar, och det ägandet bör skrivas in i policyn. Den är exakt fel för allt bakom en delad innehållsleveransadress, där samma regel berör orelaterade tjänster och ett uppdaterat DNS-svar inte gör regeln till värdnamnsauktorisering.
En policy för hanterad webbläsare uttrycker en webbegränsning mer direkt än en kopierad adresslista, men den gäller för de webbläsare och profiler som hanteringssystemet styr.
Den webbläsarregeln gör ingenting åt en röstklient som skickar UDP till en annan värd, och dess mönster definieras av den produkten, inte av jokerteckenkonventioner lånade från annat håll. En CONNECT-proxy tar också emot en värd och port för en tunnlad begäran, och kan inte läsa vägen inne i den krypterade sessionen. Utforma regeln kring det protokollet avslöjar. Skriv sedan ned vad den lämnar otäckt, för det gapet är där nästa begäran kommer ifrån.
Välj efter klienterna, inte efter kommandot
Fråga vilka klienter policyn måste täcka och vilka den får missa. En policy för hanterad webbläsare täcker det hanteringssystemet når och stannar vid webbläsargränsen. En resolverpolicy täcker allt som använder din resolver, vilket är en bredare mängd, och den misslyckas öppet för alla som inte gör det.
För en tjänst du driver är auktorisering i applikationen starkare än någon nätverksgräns, eftersom den följer kontot och inte vägen. En VPN-rutt är nåbarhet och ingenting mer: att kunna skicka ett paket till en tjänst är inte tillstånd att använda den. Där den identifierare som betyder något är en användare eller en kanaltillstånd, genomdriv den där och behandla nätverksregeln som ett andra lager.
Skriv regeln i termer av resursen
En försvarbar policy namnger resursen, identiteterna, applikationerna inom omfånget och vägen som bär dem, inklusive båda adressfamiljerna i bruk. Den anger också vad som händer med delad infrastruktur som regeln påverkar tillfälligt.
Den formuleringen producerar ett beslut som någon kan granska senare. En regel som motiveras av dagens upplösta adress producerar en incident första gången adressen ändras, och ingen kommer att kunna förklara varför blockeringen någonsin var korrekt.