VPN 포트가 벤치마크에 표시됐나? 통제 범위를 확인하라

스캐너가 VPN 포트를 표시하고, 티켓은 그것을 공용 리스너로 바꿔 말하며, 이어지는 논쟁은 노출이 실제인지에 관한 것이다. 발견은 독자가 가정하는 것을 거의 말하지 않는다. 고정된 범위를 가진 벤치마크 통제를 인용하며, 포트 번호는 그 범위에 대한 입력 중 하나일 뿐이다.

포트를 옹호하기 전에 통제를 읽어라. 판결처럼 읽히는 발견은 보통 하나의 리소스에 적용된 술어다.

발견 행이 실제로 인용하는 것

모든 벤치마크 발견은 그것이 나온 문서와 리비전, 평가된 리소스, 결과를 촉발한 술어, 감사가 실제로 달성한 범위라는, 분리해 볼 가치가 있는 네 가지를 담고 있다. 팀은 보통 리소스만 인용하며 — 보안 그룹이나 네트워크 ACL 또는 호스트 — 그다음포트를 두고 논쟁한다. 당신의 리스너가 애초에 범위 안에 있었는지는 술어가 결정한다. 그것이 없으면 규칙이 아니라 숫자를 논하는 것이다.

Amazon Security Hub 문서는 유료 PDF 없이도 그 분리를 눈에 보이게 유지한다:EC2 통제 페이지는 포트 22와 3389의 무제한 접근에 대한 보안 그룹 점검을 나열하고, 네트워크 ACL을 자체 조건을 가진 별개의 리소스로 취급한다. 같은 관리 포트, 다른 객체, 다른 테스트. 발견이 물려받는 세밀함이 바로 이것이다.

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

공용 리스너와 관리 접근을 분리하라

인터넷에서 UDP 1194를 받아들이는 VPN 리스너와 승인 후에만 도달할 수 있는 SSH 서비스는 서로 다른 노출 경로다. 전자를 다루는 점검이 후자에 대해 아무 말도 하지 않을 수 있고, 후자를 다루는 점검이 전자를 무시할 수 있다. 한쪽의 통과 결과는 다른 쪽에 대한 진술이 아니며, 상태 회의에서 둘이 아무리 비슷하게 들려도 마찬가지다.

검토에서 각 경로를 별도의 행으로 다루라.

그다음 게이트웨이 자체가 무엇을 허용하는지 확인하라. 터널을 받아들이는 것은 게이트웨이에서 관리 권한을 부여하는 것과 같지 않고, 둘 중 어느 것도 그 뒤의 서버에 도달하는 것과 같지 않다. 질문을 누가 연결할 수 있는지, 누가 관리할 수 있는지, 터널이 무엇에 도달할 수 있는지로 나누라. 이 세 답은 서로 다른 시스템에서 나오며, 아무도 행동할 수 없는 한 문장으로 일상적으로 합쳐진다.

포트가 범위 안에 있는지를 결정하는 것은 리소스다

보안 그룹 규칙, 서브넷 ACL 항목, 호스트 방화벽 규칙은 모두 트래픽을 허용할 수 있지만, 통제가 평가하는 객체는 그중 하나일 수 있다. 실효 허용이란 병렬 그룹, 두 주소 체계, 그리고 그 앞에 있는 모든 거부 규칙을 결합하는 것을 뜻한다. 그룹 수준 점검에 실패한 포트도 여전히 도달 불가능할 수 있고, 통과한 포트도 더 안쪽에서 차단될 수 있다.

다른 환경의 규칙을 이식할 때 잘못되는 지점이 여기다. 네트워크 ACL은 상태가 없고 순서대로 평가되며, 보안 그룹은 상태를 유지하고 허용만 한다. 한쪽에서 빌린 규칙 모델은 다른 쪽을 설명하지 못하며, 그것을 번역하면 잘못된 객체에 대해 자신만만한 답을 낸다.

결정을 기록해 다음 감사가 재사용하게 하라

범위가 정말 모호할 때는 통제 리비전, 리소스 식별자, 인용된 술어, 그리고 그것을 해결한 증거를 적어라. 무엇을 제외했고 왜 그랬는지도 포함하라. 그 기록이야말로 두 번째 검토자가 전체 벤치마크를 다시 읽지 않고 같은 결론에 도달하게 하며, 직원 교체를 견디는 유일한 것이다.

«VPN 포트 검토됨»이라고 적은 메모는 다음 분기에 논쟁이 돌아올 것을 보장한다. 대신 평가자, 리비전, 증거를 명시하라.