Azure Bastion으로 VM 접속: VM의 공용 IP 없이 SSH가 되는 경로

관리용 VM의 SSH를 인터넷에 열어 두기 부담스럽다. 그렇다고 VM에서 공용 IP를 빼면 어떻게 접속할까? Azure Bastion은 접속하는 사람과 VM 사이의 관리 경로를 맡는다. 핵심은 ‘공용 IP가 세상에서 사라진다’가 아니라 대상 VM에 직접 공용 IP를 붙이지 않아도 된다는 점이다.

브라우저에서 VM까지 어떤 경로로 갈까?

도식의 외부 연결은 Bastion에서 끝나고, VM으로 향하는 다음 구간은 VNet의 사설 경로다. 따라서 관리 대상 VM에 공용 IP를 직접 붙이는 구성과는 경계가 다르다.

리눅스 VM 하나가 VNet 안에서 사설 IP만 사용한다고 가정하자. 관리자는 Azure 포털에서 VM의 Bastion 연결을 열고 인증한다. 일반적인 포털 기반 경로는 다음처럼 나뉜다.

관리자 브라우저 ─ HTTPS ─> Bastion 서비스
                              └─ VNet 사설 경로의 SSH ─> 대상 VM

VM에 공용 IP가 없으므로 인터넷에서 VM의 22번 포트를 직접 찾아 접속하는 경로는 줄어든다. 하지만 Bastion 쪽의 접속 지점은 별도로 존재한다. 따라서 “VM에 공용 IP 없음”을 “아무 공용 네트워크 접점도 없음”으로 읽으면 안 된다. Bastion의 구성 방식과 SKU에 따른 세부 요건은 바뀔 수 있으니 배포할 때 현재 제품 설정을 확인한다.

접속이 안 될 때 어디를 나눠 볼까?

첫째, 포털에서 Bastion 세션을 열 수 있는가를 본다. 사용자 권한, Bastion 배포 상태, 브라우저에서 서비스로 향하는 경로가 이 단계에 걸린다. 둘째, 세션은 열리는데 VM 로그인이 실패하는지 본다. 이때는 대상 VM의 계정·키 또는 암호, 게스트 OS의 SSH/RDP 서비스 상태가 원인일 수 있다. 셋째, Bastion에서 VM의 사설 IP로 가는 네트워크 규칙을 확인한다.

이 표는 원인을 확정하는 진단기가 아니라 어느 구간에서 실패했는지 분리하는 출발점이다. 포트가 막혔다고 VM 전체에 인터넷발 SSH를 열어 버리면 Bastion을 둔 이유가 흐려진다. 대상 VM으로 가는 SSH/RDP 허용 범위는 Bastion 경로에 맞춰 제한해야 한다. NSG에 필요한 방향과 서비스 규칙을 잘못 생략하면 Bastion 자체도 작동하지 않을 수 있으므로 현재 Azure의 Bastion NSG 규칙을 확인한다.

보안상 얻는 것과 남는 책임은 무엇일까?

VM의 공용 IP와 인터넷발 관리 포트를 없애면 VM을 직접 겨냥하는 접근 면은 줄어든다. 그러나 관리자 계정 탈취, 과도한 권한, VM 안의 약한 인증, 사설망의 넓은 허용 규칙까지 해결해 주지는 않는다. 접근 권한을 최소화하고 접속 기록을 확인하며, 실제 필요한 관리자만 대상 VM에 들어갈 수 있게 해야 한다.

Bastion은 관리형 서비스이므로 비용과 전용 네트워크 구성도 검토 대상이다. 작은 실습에서 접속 한 번을 위해 항상 켜 둘지, 여러 VM의 공통 관리 경로로 쓸지 판단이 달라진다. 이 글의 경로와 표는 구성을 설명하기 위한 예시이며 실제 Azure 계정에서 배포·접속에 성공했다는 기록이 아니다.

핵심 요약: VM의 공용 IP와 관리 접속 지점은 다르다

Azure Bastion을 이용하면 대상 VM에 직접 공용 IP를 붙이지 않고 사설 경로로 SSH·RDP 접속을 구성할 수 있다. 접속 실패는 브라우저→Bastion, Bastion→VM, VM 인증 순으로 나눠 확인한다. VM의 공용 포트를 닫는 것과 관리자 권한·사설망 규칙을 안전하게 유지하는 것은 함께 필요한 일이다.