Porta VPN sinalizada por um benchmark? Verifique o escopo do controle

O scanner sinaliza a porta VPN, o ticket parafraseia isso como um listener público, e a discussão que segue é sobre se a exposição é real. O achado raramente diz o que o leitor presume. Ele cita um controle de benchmark com escopo fixo, e o número da porta é apenas uma entrada nesse escopo.

Leia o controle antes de defender a porta. Um achado que se lê como veredito costuma ser um predicado aplicado a um único recurso.

O que a linha do achado realmente cita

Cada achado de benchmark carrega quatro coisas que vale a pena separar: o documento e a revisão de onde veio, o recurso avaliado, o predicado que acionou o resultado e a cobertura que a auditoria realmente alcançou. As equipes costumam citar apenas o recurso — um grupo de segurança, uma ACL de rede ou um host — e então discutem sobre a porta. É o predicado que decide se o seu listener estava sequer no escopo. Sem ele, você debate um número em vez de uma regra.

A documentação do Amazon Security Hub mantém essa separação visível sem PDF pago:a página de controles do EC2 lista verificações de grupos de segurança para acesso irrestrito nas portas 22 e 3389, e trata as ACLs de rede como um recurso diferente com condições próprias. Mesmas portas administrativas, outro objeto, outro teste. É a granularidade que um achado herda.

aws ec2 describe-security-groups --group-ids sg-0d1f8a2c4b6e9f3a1 --output json
aws ec2 describe-network-acls --filters Name=entry.port-range.from,Values=22 --output table

Separe o listener público do acesso administrativo

Um listener VPN que aceita UDP 1194 da internet e um serviço SSH acessível só após admissão são caminhos de exposição diferentes. A verificação que cobre o primeiro pode não dizer nada sobre o segundo, e a que cobre o segundo pode ignorar o primeiro. Um resultado aprovado em um não é uma afirmação sobre o outro, por mais parecidos que soem numa reunião de status.

Trate cada caminho como sua própria linha na revisão.

Depois verifique o que o próprio gateway autoriza. Aceitar um túnel não é o mesmo que conceder direitos administrativos no gateway, e nenhum dos dois equivale a alcançar um servidor atrás dele. Divida a pergunta em quem pode conectar, quem pode administrar e o que o túnel pode alcançar. Essas três respostas vêm de sistemas diferentes e são rotineiramente fundidas numa frase sobre a qual ninguém consegue agir.

O recurso decide se a porta está sequer no escopo

Uma regra de grupo de segurança, uma entrada de ACL de sub-rede e uma regra de firewall de host podem todas permitir tráfego, mas só uma delas pode ser o objeto que o controle avalia. Permissão efetiva significa combinar grupos paralelos, as duas famílias de endereços e qualquer regra de negação à frente deles. Uma porta que falha numa verificação de nível de grupo ainda pode estar inalcançável, e uma porta que passa ainda pode estar bloqueada mais adentro.

É aqui que o transplante das regras de outro ambiente dá errado. ACLs de rede não têm estado e são avaliadas em ordem; grupos de segurança têm estado e só permitem. Um modelo de regras emprestado de um não descreve o outro, e traduzi-lo produz uma resposta confiante sobre o objeto errado.

Registre a decisão para que a próxima auditoria a reutilize

Quando o escopo é genuinamente ambíguo, anote a revisão do controle, o identificador do recurso, o predicado conforme citado e a evidência que o resolveu. Inclua o que você excluiu e por quê. Esse registro é o que permite a um segundo revisor chegar à mesma conclusão sem reler o benchmark inteiro, e é a única coisa que sobrevive à rotatividade de pessoal.

Uma nota dizendo «porta VPN revisada» garante que a discussão volte no próximo trimestre. Nomeie, em vez disso, o avaliador, a revisão e a evidência.