O trânsito cifrado não concede acesso ao operador

Dois gateways aprovados transportam o tráfego de uma rede de menor confiança através de uma rede de transporte restrita. Cifrar a carga útil mantém-na ilegível para os observadores comuns do trânsito, e essa é a parte que as pessoas projetam primeiro e depois deixam de considerar. O que a cifragem não faz é definir quais recursos o lado de menor confiança pode alcançar. O projeto precisa de duas fronteiras: uma em torno da conversa transportada e outra em torno do acesso ao próprio operador.

Execute os passos abaixo em ordem e trate qualquer falha em qualquer passo como uma mudança de projeto, não como um ajuste de configuração.

Defina ambas as fronteiras antes de tocar numa configuração

A primeira fronteira é a conversa: quais pares de gateways podem estabelecer um túnel e qual tráfego interno pode passar por ele. A segunda é o operador: quais endereços e serviços os hosts de menor confiança podem alcançar fora do túnel. As equipes costumam construir a primeira e herdar a segunda de qualquer encaminhamento que já existisse, e é assim que um projeto restrito se torna silenciosamente amplo. Essa herança é a causa raiz habitual quando uma revisão encontra um host de menor confiança a falar com algo que ninguém aprovou.

Escreva ambas como listas de endereços, portas e direções. Se uma lista não puder ser escrita, a fronteira ainda não está definida.

Passo 1: restringir o túnel exterior

Na interface voltada para o operador, permita apenas o que o túnel precisa: IKE em UDP 500 e 4500 entre os dois endereços de gateway, e ESP onde não se utiliza a travessia NAT. Negue tudo o mais que chegue a essa interface, incluindo os protocolos de gestão. A especificação ESP abrange os serviços de proteção; não diz nada sobre quais serviços próprios do operador os gateways podem usar. Expresse isso como uma lista de permissões explícita, para que um serviço do operador publicado recentemente não se torne alcançável por defeito.

É o conjunto de regras que faz do projeto um projeto de trânsito e não um acordo de peering.

Verifique-o do lado de menor confiança, não da consola do gateway. Um host ali deveria falhar ao alcançar um servidor DNS do operador ainda antes de o túnel estar levantado.

Passo 2: decidir o que o gateway remoto entrega

Na extremidade remota, o tráfego recuperado tem de ir para um lugar específico. Defina quais serviços internos são permitidos, de que intervalos de origem e se se espera que as respostas sejam simétricas. Reveja o acesso de gestão em separado, porque o mesmo gateway expõe muitas vezes uma interface administrativa que nunca fez parte do plano de trânsito.

Um diagrama que para na decifragem bem-sucedida saltou a decisão que mais importa.

Passo 3: manter a propriedade por camada

O equipamento de trânsito continua a receber e a encaminhar pacotes exteriores, pelo que precisa de correções e de planeamento de capacidade. Os pontos finais do túnel processam o protocolo protegido e expõem o tráfego interno ao seu caminho de encaminhamento, pelo que precisam das suas próprias regras e da sua própria monitorização. As aplicações finais processam a carga útil, e uma carga opaca não é prova de que uma transferência decifrada seja inofensiva.

Atribua um proprietário a cada camada. As camadas sem proprietário são as que derivam.

Passo 4: verificar e depois entregar à autoridade

Verifique o caminho exterior com o túnel levantado e as regras do operador em vigor. Depois experimente cada recurso que o lado de menor confiança não deveria alcançar e confirme que a falha é uma negação e não um tempo limite que esconde uma rota. Verifique também a disponibilidade e os limites de recursos, porque uma ligação cifrada também pode ficar saturada.

Para ambientes regulados ou classificados, leve o projeto à autoridade de segurança responsável e utilize a sua arquitetura de separação aprovada. Uma configuração de VPN e uma explicação conceptual não estabelecem acreditação. Esse passo não é papelada; decide se o projeto pode sequer existir.