Què pot significar una regla d’accés per nom d’amfitrió a cada capa de xarxa
Un nom de servei es pot aplicar a nivell de DNS, navegador, intermediari o tallafoc. Trieu la capa que veu la identitat que voleu governar.
Tres persones demanen el mateix amb les mateixes paraules: bloquejar l’accés a un nom de servei. Una vol dir que el navegador no ha d’obrir el lloc, una altra que un client de veu d’escriptori no ha d’arribar al seu servidor, i la tercera que un grup de contractistes no ha d’utilitzar una aplicació interna concreta. La frase és idèntica, i els mecanismes d’aplicació gairebé no tenen res en comú.
Trieu la capa per l’identificador que realment pot veure, i després pels clients que cobreix. Començar per una ordre de tallafoc que ja coneixeu és com les regles acaben no bloquejant res, o bloquejant massa.
Un nom no és una identitat que cada capa pugui comprovar
Netfilter i filtres de paquets similars veuen adreces, protocols i ports. No veuen noms d’amfitrió, i quan un paquet els arriba el nom ja s’ha resolt. Una regla escrita contra una adreça és una regla sobre aquesta adreça, sigui quin sigui el nom que un usuari hagi escrit per arribar-hi.
La política de DNS se situa abans al camí i veu la consulta, que és un objecte diferent de la connexió que segueix. Governa les respostes que retorna un resolutor controlat, no les connexions que ja estaven obertes, ni els clients configurats per evitar aquest resolutor. Una adreça resolta també pot canviar entre la revisió de la política i la petició següent, i per això una resposta DNS no és una declaració d’autorització duradora.
Les capes superiors veuen més context i cobreixen menys clients. Aquest intercanvi és tot el tema, i explica per què cap fila de la taula no és mai la resposta correcta. Trieu la fila que veu l’identificador del qual tracta realment la vostra política. Aleshores accepteu la cobertura que aquesta fila implica.
Què pot identificar cada capa
Llegiu la taula des de la columna central cap enfora: l’identificador que una capa pot veure dicta la política que pot aplicar honestament.
| 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 |
Una capa pertany a la política només quan l’identificador que veu coincideix amb l’identificador que governeu. La taula també explica per què una regla escrita en una capa poques vegades es trasllada a una altra sense decidir de nou què protegeix.
On falla la regla òbvia
Una regla d’adreça és exactament correcta per a un servei amb una adreça dedicada que controleu, i aquesta propietat s’ha d’escriure a la política. És exactament incorrecta per a qualsevol cosa darrere d’una adreça compartida de lliurament de contingut, on la mateixa regla toca serveis no relacionats i una resposta DNS actualitzada no converteix la regla en autorització per nom d’amfitrió.
Una política de navegador gestionat expressa una restricció web més directament que una llista d’adreces copiada, però s’aplica als navegadors i perfils que governa el sistema de gestió.
Aquesta regla de navegador no fa res per un client de veu que envia UDP a un amfitrió diferent, i els seus patrons els defineix aquest producte, no convencions de comodins manllevades d’un altre lloc. Un intermediari CONNECT també rep un amfitrió i un port per a una petició tunelitzada, i no pot llegir el camí dins de la sessió xifrada. Dissenyeu la regla al voltant del que exposa el protocol. Després escriviu què deixa sense cobrir, perquè aquest buit és d’on vindrà la petició següent.
Trieu pels clients, no per l’ordre
Pregunteu quins clients ha de cobrir la política i quins pot deixar fora. Una política de navegador gestionat cobreix el que arriba el sistema de gestió i s’atura a la frontera del navegador. Una política de resolutor cobreix tot el que utilitza el vostre resolutor, que és un conjunt més ampli, i falla obert per a qui no ho fa.
Per a un servei que opereu, l’autorització a l’aplicació és més forta que qualsevol frontera de xarxa, perquè segueix el compte i no el camí. Una ruta VPN és accessibilitat i res més: poder enviar un paquet a un servei no és permís per utilitzar-lo. On l’identificador que importa és un usuari o un permís de canal, apliqueu-lo allà i tracteu la regla de xarxa com una segona capa.
Escriviu la regla en termes del recurs
Una política defensable anomena el recurs, les identitats, les aplicacions dins l’abast i el camí que les porta, incloent-hi les dues famílies d’adreces en ús. També diu què passa amb la infraestructura compartida que la regla afectarà de passada.
Aquesta formulació produeix una decisió que algú pot auditar més endavant. Una regla justificada per l’adreça resolta d’avui produeix un incident la primera vegada que l’adreça canvia, i ningú no podrà explicar per què el bloqueig va ser mai correcte.