O que uma regra de acesso por nome de anfitrião pode significar em cada camada de rede
Um nome de serviço pode ser aplicado ao nível de DNS, navegador, proxy ou firewall. Escolha a camada que vê a identidade que quer governar.
Três pessoas pedem a mesma coisa com as mesmas palavras: bloquear o acesso a um nome de serviço. Uma quer dizer que um navegador não deve abrir o sítio, outra que um cliente de voz de secretária não deve chegar ao seu servidor, e a terceira que um grupo de empreiteiros não deve usar uma determinada aplicação interna. A frase é idêntica, e os mecanismos de aplicação não têm quase nada em comum.
Escolha a camada pelo identificador que ela consegue realmente ver e, depois, pelos clientes que abrange. Começar por um comando de firewall que já conhece é a forma como as regras acabam por não bloquear nada, ou por bloquear demasiado.
Um nome não é uma identidade que todas as camadas consigam verificar
O Netfilter e filtros de pacotes semelhantes veem endereços, protocolos e portas. Não veem nomes de anfitrião, e quando um pacote lhes chega o nome já foi resolvido. Uma regra escrita contra um endereço é uma regra sobre esse endereço, seja qual for o nome que um utilizador escreveu para lá chegar.
A política de DNS está mais cedo no caminho e vê a consulta, que é um objeto diferente da ligação que se segue. Governa as respostas devolvidas por um resolvedor controlado, não ligações que já estavam abertas, nem clientes configurados para contornar esse resolvedor. Um endereço resolvido também pode mudar entre a revisão da política e o pedido seguinte, e por isso uma resposta DNS não é uma declaração de autorização duradoura.
As camadas superiores veem mais contexto e abrangem menos clientes. Essa troca é todo o assunto, e explica porque nenhuma linha da tabela é alguma vez a resposta certa. Escolha a linha que vê o identificador de que a sua política realmente trata. Depois aceite a cobertura que essa linha implica.
O que cada camada consegue identificar
Leia a tabela da coluna central para fora: o identificador que uma camada consegue ver dita a política que ela pode aplicar com 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 |
Uma camada pertence à política apenas quando o identificador que vê corresponde ao identificador que governa. A tabela explica também porque é que uma regra escrita numa camada raramente se transfere para outra sem voltar a decidir o que protege.
Onde a regra óbvia falha
Uma regra de endereço está exatamente certa para um serviço com um endereço dedicado que controla, e essa propriedade deve ser escrita na política. Está exatamente errada para tudo o que esteja atrás de um endereço partilhado de entrega de conteúdos, onde a mesma regra toca serviços não relacionados e uma resposta DNS atualizada não transforma a regra em autorização por nome de anfitrião.
Uma política de navegador gerido exprime uma restrição web mais diretamente do que uma lista de endereços copiada, mas aplica-se aos navegadores e perfis que o sistema de gestão governa.
Essa regra de navegador não faz nada quanto a um cliente de voz que envia UDP para outro anfitrião, e os seus padrões são definidos por esse produto, não por convenções de wildcard emprestadas de outro lugar. Um proxy CONNECT também recebe um anfitrião e uma porta para um pedido em túnel, e não consegue ler o caminho dentro da sessão cifrada. Desenhe a regra em torno do que o protocolo expõe. Depois escreva o que ela deixa sem cobertura, porque essa lacuna é a origem do pedido seguinte.
Escolha pelos clientes, não pelo comando
Pergunte que clientes a política tem de abranger e quais pode deixar de fora. Uma política de navegador gerido abrange o que o sistema de gestão alcança e para na fronteira do navegador. Uma política de resolvedor abrange tudo o que usa o seu resolvedor, que é um conjunto mais amplo, e falha em aberto para quem não o faz.
Para um serviço que opera, a autorização na aplicação é mais forte do que qualquer fronteira de rede, porque segue a conta e não o caminho. Uma rota VPN é alcançabilidade e nada mais: poder enviar um pacote a um serviço não é permissão para o usar. Onde o identificador que importa é um utilizador ou uma permissão de canal, aplique-o aí e trate a regra de rede como uma segunda camada.
Escreva a regra em termos do recurso
Uma política defensável nomeia o recurso, as identidades, as aplicações no âmbito e o caminho que as transporta, incluindo ambas as famílias de endereços em uso. Diz também o que acontece à infraestrutura partilhada que a regra afetará incidentalmente.
Essa formulação produz uma decisão que alguém pode auditar mais tarde. Uma regra justificada pelo endereço resolvido de hoje produz um incidente na primeira vez que o endereço mudar, e ninguém conseguirá explicar porque é que o bloqueio foi alguma vez correto.