Que pode significar unha regra de acceso por nome de host en cada capa de rede
Un nome de servizo pódese aplicar a nivel de DNS, navegador, proxy ou devasa. Escolla a capa que ve a identidade que quere gobernar.
Tres persoas piden o mesmo coas mesmas palabras: bloquear o acceso a un nome de servizo. Unha refírese a que un navegador non debe abrir o sitio, outra a que un cliente de voz de escritorio non debe chegar ao seu servidor, e a terceira a que un grupo de contratistas non debe usar unha aplicación interna concreta. A frase é idéntica, e os mecanismos de aplicación non teñen case nada en común.
Escolla a capa polo identificador que realmente pode ver, e despois polos clientes que cobre. Empezar por un comando de devasa que xa coñece é como as regras acaban sen bloquear nada, ou bloqueando demasiado.
Un nome non é unha identidade que cada capa poida comprobar
Netfilter e os filtros de paquetes similares ven direccións, protocolos e portos. Non ven nomes de host, e cando un paquete lles chega o nome xa se resolveu. Unha regra escrita contra unha dirección é unha regra sobre esa dirección, sexa cal sexa o nome que un usuario escribise para chegar a ela.
A política de DNS sitúase antes na ruta e ve a consulta, que é un obxecto distinto da conexión que segue. Goberna as respostas que devolve un resolvedor controlado, non as conexións que xa estaban abertas, nin os clientes configurados para eludir ese resolvedor. Unha dirección resolta tamén pode cambiar entre a revisión da política e a seguinte petición, polo que unha resposta DNS non é unha declaración de autorización duradeira.
As capas superiores ven máis contexto e cobren menos clientes. Ese intercambio é todo o asunto, e explica por que ningunha fila da táboa é nunca a resposta correcta. Escolla a fila que ve o identificador do que trata realmente a súa política. Logo acepte a cobertura que esa fila implica.
Que pode identificar cada capa
Lea a táboa desde a columna central cara a fóra: o identificador que unha capa pode ver dita a política que pode aplicar con honestidade.
| 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 |
Unha capa pertence á política só cando o identificador que ve coincide co identificador que vostede goberna. A táboa tamén explica por que unha regra escrita nunha capa raramente se traslada a outra sen decidir de novo que protexe.
Onde falla a regra obvia
Unha regra de dirección é exactamente correcta para un servizo cunha dirección dedicada que vostede controla, e esa propiedade debería escribirse na política. É exactamente incorrecta para calquera cousa detrás dunha dirección compartida de entrega de contido, onde a mesma regra toca servizos non relacionados e unha resposta DNS actualizada non converte a regra en autorización por nome de host.
Unha política de navegador xestionado expresa unha restrición web máis directamente que unha lista de direccións copiada, pero aplícase aos navegadores e perfís que goberna o sistema de xestión.
Esa regra de navegador non fai nada cun cliente de voz que envía UDP a outro host, e os seus patróns defíneos ese produto e non convencións de comodíns tomadas doutro lugar. Un proxy CONNECT tamén recibe un host e un porto para unha petición tunelizada, e non pode ler a ruta dentro da sesión cifrada. Deseñe a regra arredor do que expón o protocolo. Despois anote o que deixa sen cubrir, porque ese oco é de onde virá a seguinte petición.
Escolla polos clientes, non polo comando
Pregunte que clientes debe cubrir a política e cales pode deixar fóra. Unha política de navegador xestionado cobre o que alcanza o sistema de xestión e detense na fronteira do navegador. Unha política de resolvedor cobre todo o que usa o seu resolvedor, que é un conxunto máis amplo, e falla en aberto para quen non o fai.
Para un servizo que vostede opera, a autorización na aplicación é máis forte que calquera fronteira de rede, porque segue a conta e non a ruta. Unha ruta VPN é accesibilidade e nada máis: poder enviar un paquete a un servizo non é permiso para usalo. Onde o identificador que importa é un usuario ou un permiso de canle, aplíqueo alí e trate a regra de rede como unha segunda capa.
Escriba a regra en termos do recurso
Unha política defendible nomea o recurso, as identidades, as aplicacións no ámbito e a ruta que as transporta, incluídas ambas as familias de direccións en uso. Tamén declara que ocorre coa infraestrutura compartida que a regra afectará de forma incidental.
Esa formulación produce unha decisión que alguén pode auditar máis adiante. Unha regra xustificada pola dirección resolta de hoxe produce un incidente a primeira vez que a dirección cambie, e ninguén poderá explicar por que o bloqueo foi algunha vez correcto.