Porto VPN marcado por un benchmark? Comproba o alcance do control

O teu escáner marca o porto VPN, o ticket parafrasea iso como un listener público e a discusión que segue trata de se a exposición é real. O achado raramente di o que supón o lector. Cita un control de benchmark cun alcance fixo, e o número de porto só é unha entrada dese alcance.

Le o control antes de defender o porto. Un achado que se le como un veredicto adoita ser un predicado aplicado a un só recurso.

Que cita realmente a fila do achado

Cada achado de benchmark leva catro cousas que paga a pena separar: o documento e a revisión dos que procede, o recurso que se avaliou, o predicado que desencadeou o resultado e a cobertura que a auditoría logrou realmente. Os equipos adoitan citar só o recurso — un grupo de seguridade, unha ACL de rede ou un host — e despois discuten sobre o porto. O predicado é o que decide se o teu listener estaba sequera dentro do alcance. Sen el, debates un número en lugar dunha regra.

A documentación de Amazon Security Hub mantén esa separación visible sen un PDF de pago:a páxina de controis de EC2 enumera comprobacións de grupos de seguridade para acceso sen restricións nos portos 22 e 3389, e trata as ACL de rede como un recurso distinto coas súas propias condicións. Os mesmos portos de administración, outro obxecto, outra proba. Esa é a granularidade que herda un achado.

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

Separa o listener público do acceso administrativo

Un listener VPN que acepta UDP 1194 desde internet e un servizo SSH accesible só tras a admisión son camiños de exposición distintos. A comprobación que cobre o primeiro pode non dicir nada do segundo, e a comprobación que cobre o segundo pode ignorar o primeiro. Un resultado favorable nun non é unha afirmación sobre o outro, por moito que se parezan nunha reunión de estado.

Trata cada camiño como a súa propia fila na revisión.

Despois verifica que autoriza a propia pasarela. Aceptar un túnel non é o mesmo que conceder dereitos administrativos na pasarela, e ningunha das dúas cousas equivale a chegar a un servidor detrás dela. Divide a pregunta en quen se pode conectar, quen pode administrar e que pode acadar o túnel. Esas tres respostas veñen de sistemas distintos e fusiónanse rutinariamente nunha frase sobre a que ninguén pode actuar.

O recurso decide se o porto está sequera dentro do alcance

Unha regra de grupo de seguridade, unha entrada de ACL de subrede e unha regra de firewall de host poden permitir tráfico, pero só unha delas pode ser o obxecto que avalia o control. O permiso efectivo significa combinar grupos paralelos, as dúas familias de enderezos e calquera regra de denegación diante deles. Un porto que falla unha comprobación a nivel de grupo pode seguir sendo inalcanzable, e un porto que a supera pode seguir bloqueado máis adentro.

Aquí é onde falla trasplantar as regras doutro entorno. As ACL de rede non teñen estado e avalíanse en orde; os grupos de seguridade teñen estado e só permiten. Un modelo de regras tomado dun non describe o outro, e traducilo produce unha resposta confiada sobre o obxecto equivocado.

Rexistra a decisión para que a próxima auditoría a reutilice

Cando o alcance é genuinamente ambiguo, anota a revisión do control, o identificador do recurso, o predicado tal como se citou e a evidencia que o resolveu. Inclúe que excluíches e por que. Ese rexistro é o que permite a un segundo revisor chegar á mesma conclusión sen reler todo o benchmark, e é o único que sobrevive á rotación de persoal.

Unha nota que diga «porto VPN revisado» garante que a discusión volva o próximo trimestre. Nomea no seu lugar o avaliador, a revisión e a evidencia.