Regra do EC2 apenas para VPN: todo grupo de segurança anexado deve concordar

Você acrescenta uma regra de entrada para o pool de clientes VPN, não remove nada, e o serviço continua acessível a partir da internet. Nada está quebrado. Um grupo de segurança não tem sobreposição, prioridade ou negação final contra a qual a regra estreita possa vencer. Cada grupo anexado à instância contribui com as suas próprias permissões para um único conjunto combinado, e a regra ampla que você esqueceu continua nesse conjunto. Tornar a instância apenas-VPN significa auditar todos eles, não acrescentar uma regra que soe melhor a um deles.

Escreva o serviço antes de escrever a regra

Comece pelo destino exato, protocolo e porta, e pela interface de rede onde o serviço realmente escuta. Uma instância com várias interfaces ou vários serviços numa porta exige a auditoria por interface, porque os grupos anexados podem diferir. Depois determine qual endereço de origem essa interface realmente recebe para um utilizador de VPN, em vez do endereço que o cliente mostra na sua própria janela de ligação.

Esses dois endereços divergem mais vezes do que as pessoas esperam assim que a tradução e o encaminhamento entram em jogo.

Três modelos de origem, três regras diferentes

Com acesso privado encaminhado, a instância recebe o pool de clientes ou o intervalo corporativo, conforme a forma como o caminho é encaminhado e traduzido. Com um endpoint público alcançado através da saída corporativa, a instância vê, em vez disso, o endereço NAT corporativo, e só se esse destino realmente usar o caminho VPN, já que o túnel dividido o pode deixar numa ligação doméstica. Com um endpoint Client VPN gerido, aplica-se o modelo documentado de associação e rede de destino, e o endereço do cliente vem do CIDR de cliente configurado.

O que não funciona é referenciar um gateway VPN como origem de um grupo de segurança. As referências de grupo correspondem a interfaces de rede elásticas dentro da VPC ou de uma rede emparelhada, e um gateway que reencaminha pacotes não é uma delas.

Leia a união em todos os grupos anexados

Abra a instância, encontre a sua interface de rede e liste cada grupo de segurança anexado. Para cada um, verifique cada regra que cobre o seu protocolo e porta, incluindo intervalos de portas amplos e ambas as famílias de endereços. Uma regra IPv4 de 0.0.0.0/0 não o dispensa de verificar ::/0, e uma regra que permite todo o tráfego esconde por completo a questão da porta. Só depois desse inventário pode dizer qual é a permissão efetiva para o serviço.

A referência de regras da AWS descreve os grupos de segurança como apenas-permitir e afirma que as regras de todos os grupos anexados são agregadas, e é todo esse o mecanismo por trás desta falha.

As ACL de rede são uma política separada e sem estado, com entradas ordenadas de permissão e negação, e são avaliadas na sub-rede e não na instância.

Não responda com um muro de negações

Acrescentar uma negação NACL para toda a sub-rede, para imitar uma firewall a que está habituado, é a ferramenta errada e arriscada. As entradas NACL estão ordenadas e não têm estado, por isso uma negação colocada acima de uma permissão existente quebra silenciosamente tráfego não relacionado, incluindo o caminho de retorno das sessões que tentava manter. Corrija a permissão ampla do grupo de segurança no grupo que a possui e depois deixe a ACL em paz, a menos que faça realmente parte do desenho.

Remover um endereço público da instância é uma garantia mais forte, e é também uma alteração arquitetural com consequências administrativas e de aplicação, não uma caixa numa lista de permissões.

Teste com uma sessão nova e mantenha uma forma de entrar

Antes de retirar qualquer permissão existente, confirme um caminho de administração independente e aprovado, porque a regra que está prestes a eliminar pode ser aquela de que depende a recuperação da sua sessão. Depois teste uma nova ligação permitida a partir da VPN e uma nova ligação negada a partir de um caminho de teste autorizado que não seja VPN. As sessões rastreadas existentes sobrevivem às alterações de regras de formas que tornam as antigas shells abertas inúteis como prova de aceitação.

Por fim, mantenha a autorização própria da aplicação. Uma saída corporativa traduzida pode representar centenas de pessoas, e a admissão na rede nunca identificou um utilizador individual nem o seu dispositivo.