Desenhe o caminho decifrado: onde um appliance VPN aplica a política

Os diagramas dos fornecedores costumam terminar no listener cifrado, porque essa é a parte com um endereço público. A pergunta que decide a postura de segurança é o que acontece após a decifragem, quando o pacote se torna IP comum e pode alcançar tudo o que a tabela de rotas permite. Se ninguém desenhou esse trecho, ninguém é dono dele. O runbook abaixo o desenha primeiro e depois compara os posicionamentos pelo que a solicitação decifrada realmente atravessa.

Desenhe o pacote depois da decifragem, não antes

O caminho externo é a parte que os fornecedores documentam: um endpoint público, uma política de transporte que admite a conexão e um serviço que a termina. O caminho interno começa no momento em que o pacote perde o cabeçalho do túnel, e a partir daí é governado por regras de roteamento e filtragem que nada têm a ver com o túnel. Coloque ambos na mesma página, porque um diagrama só com o primeiro sugere que admissão e autorização são uma única decisão. Não são, e a lacuna entre elas é onde a maioria dos posicionamentos erra.

Escreva o trecho interno como uma sequência numerada com tipos de dispositivo nomeados, não como uma seta. Uma seta esconde se a solicitação atravessa um filtro, e atravessar ou não é toda a questão. Cada salto abaixo nomeia o dispositivo e o conjunto de regras que age ali, de modo que um filtro ausente aparece como uma lacuna em vez de ser sugerido por uma linha.

1. Cliente remoto: o dispositivo do usuário que origina o túnel.
2. Política de borda: o conjunto de regras que admite o transporte externo ao listener público.
3. Appliance de terminação: o endpoint VPN que desencapsula e entrega o pacote ao IP comum.
4. Filtro interno: o conjunto de regras de encaminhamento ou de grupos de segurança que limita o tráfego de cliente para serviço.
5. Host da aplicação: o serviço que recebe a solicitação decifrada.

Duas políticas, dois donos

A política externa responde quem pode estabelecer um túnel, e é expressa nas regras que admitem o transporte até o serviço de terminação. A política interna responde a qual serviço um usuário autenticado pode chegar, e vive em regras de encaminhamento, grupos de segurança ou na própria aplicação. Um único dispositivo pode abrigar as duas, e um projeto com vários dispositivos continua tendo as duas. É nomeá-las separadamente que permite dizer qual falhou quando um usuário não chega a uma aplicação.

Os controles de admissão, como certificados e autenticação multifator, respondem à identidade e a nada mais. Não decidem o posicionamento e não concedem permissão por recurso depois que o usuário está dentro.

O posicionamento decide qual fronteira a solicitação atravessa

Três posicionamentos são comuns, e cada um muda qual fronteira a solicitação decifrada atravessa. Compare-os pelo que termina ali, o que pode ver texto claro, qual controle ainda pode negar a solicitação e o que falha junto com o appliance. A tabela abaixo usa essas quatro colunas em vez de uma pergunta genérica, porque cada resposta é uma decisão de projeto separada.

O terceiro posicionamento é o que remove a aplicação em silêncio, porque um trecho no segmento protegido dá ao appliance um caminho direto que o diagrama talvez não mostre. Inspecione as interfaces e as rotas em vez da imagem: ip route get 10.20.5.10 informa por qual interface o pacote sairia, e a resposta muitas vezes não é a que o projeto supôs. O papel clássico do firewall de controlar o tráfego entre posturas, como descrito emNIST SP 800-41, é um teste útil aqui, porque um dispositivo com um trecho sem restrições para a rede protegida não controla muita coisa. Uma consulta de rota é um diagrama mais honesto que o da apresentação.

A administração pertence ao seu próprio caminho explicitamente permitido. Permitir que os usuários cheguem a uma aplicação nunca exige permitir que cheguem à interface de controle do appliance, e as duas permissões devem ser concedidas por regras diferentes. Audite os dois caminhos separadamente, porque uma regra compartilhada esconde qual foi aberto.

A tradução muda o que as regras a jusante podem ver

A tradução da origem é conveniente e destrói informação. Depois do masquerade cada cliente parece o appliance, então uma regra a jusante escrita para distinguir usuários já não consegue fazê-lo. Não é só um problema de log, é um problema de política: uma regra baseada no endereço do cliente torna-se silenciosamente uma regra baseada no gateway. Se a política por usuário importa, preserve a origem ou aplique a política antes da tradução.

O caminho de resposta merece o mesmo escrutínio. Registre qual rota o destino escolhe para o pacote de volta, porque um retorno assimétrico contorna a inspeção com estado e produz uma conexão que se estabelece e depois trava. As duas direções precisam cruzar a fronteira que você desenhou, ou a fronteira é decoração.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

Aceite uma operação permitida e uma negada

Teste a partir do cliente remoto real e não de um host de gestão, porque o host de gestão costuma ficar onde o usuário nunca estará. Uma operação permitida prova que o caminho funciona, e uma negada prova que a política faz alguma coisa. Execute as duas após cada mudança de posicionamento e registre a identidade de origem e o destino usados. Um teste que só prova sucesso não distingue uma regra correta de uma ausente.

Depois teste os casos que mudam de estado: uma reconexão, uma sessão que sobrevive a uma rotação de chaves e uma falha do próprio appliance. Compare atualizações, capacidade e recuperação como parte do mesmo desenho, porque um appliance que sustenta vários controles lógicos é um único domínio de falha com vários rótulos. Uma segunda caixa também não é independente quando uma credencial administrativa compartilhada ou uma rota sem restrições derrota a fronteira que ela deveria criar.

Documente o endpoint, o caminho decifrado e o controle que o restringe. Essas três linhas continuam significativas qualquer que seja o nome da implementação.