Aceitar o acesso remoto por VPC exige testes de recusa

A aceitação do acesso remoto é uma tabela de resultados esperados, não uma captura de ecrã de uma página funcional. Para cada grupo, escreva o que deve funcionar e o que deve falhar e, em seguida, execute ambos com identidades de teste dedicadas numa janela controlada. As recusas são a parte que prova a fronteira; um login bem-sucedido prova apenas que o túnel existe. Tudo isto funciona com o produto VPN já escolhido.

Use contas separadas para os testes e etiquete-as de modo a que ninguém confunda uma identidade de teste com uma exceção real.

Escreva a fronteira como resultados esperados

Comece pelas funções e não pelos componentes: quem precisa de que serviço, a partir de onde e com que identidade. Considere uma VPC ilustrativa: um grupo precisa do ambiente de teste por HTTPS, outro precisa de uma base de dados de produção e um terceiro grupo, mais pequeno, administra o próprio gateway. Cada linha recebe uma autorização esperada e uma recusa esperada, incluindo o serviço vizinho e a conta vizinha que não deveriam funcionar. Essa tabela é o critério de aceitação, e as pessoas que não executam os testes podem revê-la.

Teste o login na base de dados separadamente do caminho de rede. Uma porta TCP acessível não deve fazer com que uma conta de base de dados não aprovada tenha sucesso, e a pertença à VPN não deve criar uma função IAM na nuvem nem conceder acesso administrativo à API. São três controlos independentes, e falham de forma independente.

Uma rota não é autorização

Uma rota torna um caminho possível; não concede permissão. Reter uma rota é um substituto fraco de uma restrição aplicada no destino, uma vez que um cliente pode sempre acrescentar a sua própria rota. O grupo de segurança, a concessão da base de dados e a própria autorização da aplicação continuam a ser os controlos que decidem. Quando um teste tem sucesso inesperadamente, olhe primeiro para a política do destino e não para a tabela de encaminhamento que pretendia dar ao cliente.

É também por isso que os testes de recusa visam o lado do servidor: esses resultados não podem ser alterados editando o cliente.

Que origem vê o controlo na realidade?

O endereço de origem que um controlo avalia depende da arquitetura do gateway. Um gateway alojado em EC2 pode encaminhar um conjunto encaminhado, traduzi-lo para o seu próprio endereço ou apresentar outro endereço após o NAT; um Client VPN gerido associa-se a uma sub-rede e segue o seu próprio modelo. Os grupos de segurança e as ACL de rede veem o que chega após esse processamento. Inspecionar uma regra com uma suposição de origem errada é uma forma comum de construir uma fronteira que parece correta e admite o tráfego errado.

Correlacione cada resultado com o evento útil mais pequeno: identidade e sessão, recurso, operação, hora e a decisão. Uma chamada à API do CloudTrail, um registo de fluxo de VPC e um registo de sessão VPN respondem a perguntas diferentes, e nenhum deles por si só é uma auditoria da aplicação.

Retire uma identidade e teste-a novamente

Inclua a retirada na mesma tabela. Remova uma identidade de teste, confirme que uma nova sessão é recusada e, em seguida, confirme separadamente como são tratadas as sessões existentes, porque são comportamentos diferentes com proprietários diferentes. Verifique o que acontece após um reinício ou substituição do gateway, para que uma exceção adicionada à mão não desapareça em silêncio nem regresse mais ampla. Uma fronteira que só dura até à próxima implementação não é uma fronteira.

Nada disto substitui o trabalho de correções, recuperação ou ciclo de vida das credenciais. Torna mensurável uma promessa mais estreita: as pessoas certas chegam aos serviços certos, enquanto rotas, contas e superfícies de gestão próximas ficam fora da concessão.

Mantenha a tabela junto da implementação e volte a executá-la quando o gateway mudar. Os testes são baratos; as suposições por trás deles não.