내부 ALB와 공개 DNS 이름: 정말 노출된 것인가?

내부 로드 밸런서에 공개 DNS 조회를 실행하면 사설 주소가 돌아올 수 있는데, 이는 레코드가 무엇을 위한 것인지 확인하기 전까지 설정 오류처럼 보인다. AWS는 내부 로드 밸런서 이름이 공개적으로 확인 가능하면서도 그 노드는 사설 주소만 보유한다고 문서화한다. 리졸버는 서비스가 어디 있는지 답했을 뿐, 경로를 만들지 않았고 보안 그룹을 열지 않았으며 누구도 인증하지 않았다. 그 답이 문제인지는 순서대로 확인할 수 있는 사실에 달려 있다.

첫 단계: IP가 아니라 스킴을 읽어라

스킴 필드는 로드 밸런서 자신이 자기 경계에 대해 한 진술이다. aws elbv2 describe-load-balancers --names app-internal은 internal 또는 internet-facing 값의 Scheme을 반환하며, IPv4 또는 이중 스택용 주소 유형도 함께 준다. 인터넷을 향한 로드 밸런서도 사설 대상으로 전달할 수 있으므로 사설 백엔드 주소가 보인다고 해서 프런트 엔드에 대해 증명되는 것은 없다.

다른 무엇을 보기 전에 스킴을 적어 두어라. 이후의 모든 판단이 그것에 달려 있으며, 보안 그룹과 리스너 규칙에서 그 로드 밸런서 유형의 기능 집합까지 어떤 제어가 존재하는지도 알려 준다. 오래된 콘솔 스크린샷에서 복사한 스킴은 아무 메모도 없는 것보다 나쁘다. API에서 다시 읽고 값을 티켓에 붙여 넣어라.

둘째 단계: 이름이 무엇으로 확인되는지 보라

VPC 밖에서 dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com으로 질의하고 응답이 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 중 어디에 있는지 기록하라. 공개 리졸버의 사설 응답은 내부 로드 밸런서 이름에 대해 예상되는 동작이며, 주소가 인터넷에서 라우팅 가능하다는 증거는 아니다.

같은 이름을 VPC 내부에서 확인하고 비교하라. 두 응답이 다르면 스플릿 호라이즌 작명을 보는 것이며, 그 차이는 설계 세부 사항이지 유출이 아니다.

셋째 단계: 도달할 수 있는 경로를 나열하라

사설 주소는 경로와 보안 규칙이 있는 곳이면 어디서든 도달할 수 있다. 그것들을 의도적으로 나열하라: 사이트 간 VPN, 클라이언트 VPN, VPC 피어링, 전송 게이트웨이 연결, Direct Connect, 그리고 VPC 내부의 모든 프록시나 배스천이다. 그중 하나가 의도된 경로이고 나머지는 공격자가 찾을 경로다.

그다음 각 경로의 제어를 확인하라: 로드 밸런서의 보안 그룹, 서브넷의 네트워크 ACL, 그리고 경로를 존재하게 하는 라우팅이다. 내부 서비스가 노출되었다는 보고 사례 대부분은 의도하지 않은 피어링이 있었거나, 경로는 의도된 것이고 애플리케이션에 인증이 없었거나 둘 중 하나로 여기서 풀린다.

넷째 단계: 리스너와 애플리케이션을 따로 시험하라

서비스에 닿으면 안 되는 네트워크에서 연결을 시도하고 닿지 않음을 확인하라. 다음으로 닿아야 하는 네트워크에서 시도하고 리스너에 도달함을 확인하라. 이 두 결과가 네트워크 도달성과 애플리케이션 동작을 구분하며, 노출 질문에 의미 있는 유일한 증거다.

도달 가능한 리스너는 접근 가능한 애플리케이션과 같지 않다. TLS 인증서와 프로토콜 정책을 확인하고, 다음으로 애플리케이션 자체의 인증과 권한 부여를 확인하라. 회사 VPN에서 아무 호출자나 받아들이는 내부 도구는 그 VPN의 침해된 모든 노트북에 노출되며, 이는 인터넷을 향한 위험과 다르지만 여전히 위험이다.

제어는 유형에 따라 다르다는 점을 기억하라. 애플리케이션 계층 방화벽은 한 로드 밸런서 계열에 붙고 다른 계열에는 붙지 않으므로, 동등하다고 가정하지 말고 눈앞의 스킴과 유형에 실제로 무엇이 가능한지 확인하라.

다섯째 단계: 이름 자체가 중요한지 결정하라

공개 확인 가능성은 서비스 이름, 리전, 주소 범위를 드러낼 수 있으므로, 정책적 답이 있는 정보 공개 질문으로 다루고 자동 사고로 보지 마라. 민감한 업무 용어를 리소스 이름에서 빼고, 작명 규칙이 원하는 것보다 많이 드러내면 위험 기록에 공개 사실을 적어라.

조직이 사설 작명 경험을 원하면 사설 호스팅 영역이 연결된 VPC 내부에서만 확인되는 별칭을 제공할 수 있다. 그것은 사용자가 보는 이름을 바꾸지만, 공급자가 생성한 이름을 비밀로 만들지 않고 네트워크 경로도 제거하지 않는다.

답을 숨기려고 주소를 고정하려 하지 마라. 로드 밸런서 주소는 바뀌고, 고정은 TLS 검증 습관을 깨뜨리며, 정말 필요한 제어는 누가 연결을 맺을 수 있는지와 애플리케이션이 그들에게 무엇을 요구하는지다. 네 가지 사실을 확인해 적으면 질문은 더 이상 모호하지 않다.