Ce poate însemna o regulă de acces după numele gazdei la fiecare nivel de rețea
Numele unui serviciu poate fi impus la nivel de DNS, browser, proxy sau firewall. Alegeți nivelul care vede identitatea pe care vreți să o guvernați.
Trei persoane cer același lucru cu aceleași cuvinte: blocarea accesului la un nume de serviciu. Una se referă la faptul că un browser nu trebuie să deschidă site-ul, alta la faptul că un client vocal de birou nu trebuie să ajungă la serverul său, iar a treia la faptul că un grup de contractori nu trebuie să folosească o anumită aplicație internă. Propoziția este identică, iar mecanismele de aplicare nu au aproape nimic în comun.
Alegeți nivelul după identificatorul pe care îl vede cu adevărat, apoi după clienții pe care îi acoperă. Pornirea de la o comandă de firewall pe care o cunoașteți deja este felul în care regulile ajung să nu blocheze nimic sau să blocheze prea mult.
Un nume nu este o identitate pe care fiecare nivel o poate verifica
Netfilter și filtrele de pachete similare văd adrese, protocoale și porturi. Nu văd nume de gazdă, iar când un pachet ajunge la ele numele a fost deja rezolvat. O regulă scrisă împotriva unei adrese este o regulă despre acea adresă, indiferent ce nume a tastat un utilizator ca să ajungă la ea.
Politica DNS stă mai devreme pe traseu și vede interogarea, care este un obiect diferit de conexiunea ce urmează. Ea guvernează răspunsurile returnate de un resolver controlat, nu conexiunile care erau deja deschise și nici clienții configurați să ocolească acel resolver. O adresă rezolvată se poate schimba și între revizuirea politicii și cererea următoare, de aceea un răspuns DNS nu este o declarație de autorizare durabilă.
Nivelurile superioare văd mai mult context și acoperă mai puțini clienți. Acest schimb este întreaga temă și explică de ce niciun rând al tabelului nu este vreodată răspunsul corect. Alegeți rândul care vede identificatorul despre care este de fapt politica dumneavoastră. Apoi acceptați acoperirea pe care o implică acel rând.
Ce poate identifica fiecare nivel
Citiți tabelul de la coloana din mijloc spre exterior: identificatorul pe care un nivel îl poate vedea dictează politica pe care o poate aplica onest.
| 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 |
Un nivel aparține politicii doar când identificatorul pe care îl vede corespunde identificatorului pe care îl guvernați. Tabelul explică și de ce o regulă scrisă la un nivel se transferă rar la altul fără a decide din nou ce protejează.
Unde eșuează regula evidentă
O regulă de adresă este exact corectă pentru un serviciu cu o adresă dedicată pe care o controlați, iar acea proprietate ar trebui scrisă în politică. Este exact greșită pentru orice se află în spatele unei adrese partajate de livrare a conținutului, unde aceeași regulă atinge servicii nelegate și un răspuns DNS reîmprospătat nu transformă regula în autorizare după numele gazdei.
O politică de browser gestionat exprimă o restricție web mai direct decât o listă de adrese copiată, dar se aplică browserelor și profilelor pe care le guvernează sistemul de gestionare.
Acea regulă de browser nu face nimic pentru un client vocal care trimite UDP către altă gazdă, iar modelele sale sunt definite de acel produs, nu de convenții cu caractere joker împrumutate de altundeva. Un proxy CONNECT primește de asemenea o gazdă și un port pentru o cerere tunelată și nu poate citi calea din interiorul sesiunii criptate. Proiectați regula în jurul a ceea ce expune protocolul. Apoi notați ce lasă neacoperit, pentru că acea lipsă este de unde va veni cererea următoare.
Alegeți după clienți, nu după comandă
Întrebați ce clienți trebuie să acopere politica și pe care îi poate rata. O politică de browser gestionat acoperă ce ajunge sistemul de gestionare și se oprește la granița browserului. O politică de resolver acoperă tot ce folosește resolverul dumneavoastră, un set mai larg, și eșuează deschis pentru cine nu o face.
Pentru un serviciu pe care îl operați, autorizarea în aplicație este mai puternică decât orice graniță de rețea, pentru că urmează contul, nu calea. O rută VPN este accesibilitate și nimic mai mult: a putea trimite un pachet către un serviciu nu este permisiunea de a-l folosi. Acolo unde identificatorul care contează este un utilizator sau o permisiune de canal, aplicați-o acolo și tratați regula de rețea ca pe un al doilea nivel.
Scrieți regula în termenii resursei
O politică defendabilă numește resursa, identitățile, aplicațiile din scop și calea care le transportă, inclusiv ambele familii de adrese în uz. Ea arată și ce se întâmplă cu infrastructura partajată pe care regula o va afecta incidental.
Această formulare produce o decizie pe care cineva o poate audita mai târziu. O regulă justificată de adresa rezolvată de azi produce un incident la prima schimbare a adresei, și nimeni nu va putea explica de ce blocarea a fost vreodată corectă.