Bastion Host는 요새가 아니라 관리 접근 경로입니다

운영 서버는 외부에 열고 싶지 않지만, 관리자는 언젠가 접속해야 해요. 장애가 났을 때 로그를 봐야 하고, 설정을 확인해야 하고, 긴급 패치를 적용해야 할 수도 있어요. 문제는 그 접속을 위해 private subnet의 서버에 public IP를 붙이거나 SSH, RDP 포트를 인터넷에 열기 시작하면 공격면이 확 커진다는 점이에요.

Bastion Host는 이 상황에서 관리 접근 경로를 따로 만드는 방식이에요. 내부 서버를 인터넷에 직접 노출하지 않고, 먼저 Bastion Host에 들어온 뒤 그곳에서 내부 리소스로 이동하게 해요. 그래서 핵심은 "요새처럼 안전한 서버 하나"가 아니라 "관리 트래픽이 지나가는 좁은 문 하나"에 가까워요.

왜 Bastion Host가 필요한가요

클라우드에서 웹 서버, 데이터베이스, 배치 서버, 사내 관리 도구를 모두 인터넷에 노출할 필요는 없어요. 오히려 대부분의 서버는 사설 네트워크 안에 두고, 외부에는 로드 밸런서나 API Gateway처럼 필요한 입구만 열어두는 편이 안전해요.

그런데 운영자는 내부 서버에 접속해야 하는 순간이 있어요. 이때 선택지는 크게 세 가지예요.

1. 내부 서버마다 public IP와 관리 포트를 열어요.
2. VPN이나 전용망으로 내부망에 들어가요.
3. Bastion Host나 관리형 세션 서비스를 통해 제한된 경로로 들어가요.

첫 번째 방식은 간단하지만 위험해요. 서버가 늘어날수록 열려 있는 포트와 접근 정책도 같이 늘어나요. 누가 어떤 서버에 접근할 수 있는지 추적하기도 어려워져요. Bastion Host는 이 문제를 줄이기 위해 관리 접속 지점을 한곳으로 모아요.

이름은 요새지만 핵심은 경로를 모으는 일이에요

Bastion은 원래 성곽에서 바깥으로 돌출된 방어 구조물을 뜻해요. 성벽 전체를 한 번에 지키기보다, 공격이 들어올 가능성이 높은 지점을 더 잘 관찰하고 방어하기 위한 구조였어요.

인프라에서 Bastion Host라는 이름을 쓰는 이유도 비슷해요. 내부망 전체를 외부에 열어두는 대신, 외부와 내부 사이에 관찰하고 통제할 수 있는 접점을 하나 둬요. 다만 실제 운영에서는 "이 서버가 있으니 안전하다"보다 "관리 접근이 이 경로로만 흐르게 만든다"가 더 중요해요.

접근 흐름은 어떻게 바뀌나요

Bastion Host를 쓰면 관리 접속 흐름이 이렇게 바뀌어요.

1. 관리자는 Bastion Host에만 접속해요.
2. Bastion Host는 내부 서버가 있는 사설 네트워크에 접근할 수 있어요.
3. 내부 서버는 인터넷에서 직접 접근할 수 없고, Bastion Host에서 오는 관리 트래픽만 허용해요.

이 구조의 장점은 단순해요. 외부에 열리는 관리 지점이 줄어들고, 접근 정책을 한곳에서 좁힐 수 있어요. 예를 들어 내부 서버의 보안 그룹은 22/tcp를 인터넷 전체에 열지 않고, Bastion Host의 사설 IP나 보안 그룹에서 오는 트래픽만 허용할 수 있어요.

로그 관점에서도 이점이 있어요. 관리자가 내부 서버에 흩어져 접속하는 대신 Bastion Host를 거치면, 누가 언제 관리 경로에 들어왔는지 더 쉽게 모을 수 있어요. 여기에 MFA, 접속 승인, 세션 기록, 명령 감사 같은 장치를 붙이면 운영 추적성이 좋아져요.

좋아지는 점과 남는 위험

Bastion Host를 두면 보통 다음이 좋아져요.

• 내부 서버에 public IP를 붙이지 않아도 돼요.
• 인터넷에 노출되는 SSH, RDP 엔드포인트 수가 줄어요.
• 관리 접근 정책과 로그를 한곳에서 다루기 쉬워요.
• 내부 서버의 방화벽 규칙을 더 좁게 잡을 수 있어요.

하지만 Bastion Host가 접근 제어 전략 전체를 대신하지는 못해요. Bastion Host 자체가 뚫리면 내부망으로 가는 발판이 될 수 있고, 운영 방식이 느슨하면 위험은 그대로 남아요.

특히 이런 상태라면 Bastion Host를 둬도 효과가 작아요.

• 여러 사람이 같은 계정이나 같은 SSH 키를 공유해요.
• MFA 없이 비밀번호나 키 파일만으로 접속해요.
• Bastion Host에서 내부망 전체로 이동할 수 있어요.
• 접속 기록은 남지만 세션 내용이나 명령은 추적하지 않아요.
• Bastion Host 패치, 하드닝, 접근 권한 회수가 늦어요.

결국 Bastion Host는 "직접 접근을 줄이는 장치"예요. 인증, 권한, 로깅, 네트워크 분리, 패치 관리가 함께 붙어야 의미가 커져요.

관리형 접근도 같이 봐야 해요

요즘은 직접 Bastion Host를 운영하지 않는 선택지도 많아요. 직접 서버를 세우면 자유도는 높지만, 그 서버를 안전하게 운영하는 책임도 같이 생겨요. 반대로 관리형 접근 서비스를 쓰면 SSH 포트를 열지 않거나 public IP 없이 접속하는 모델을 만들 수 있어요.

AWS Systems Manager Session Manager는 인스턴스에 인바운드 포트를 열지 않고 세션을 시작하는 방식으로 관리 접속을 제공해요. Azure Bastion은 브라우저 기반으로 VM에 RDP나 SSH 접속을 제공하고, VM의 public IP 노출을 줄이는 방향으로 설계되어 있어요. Google Cloud의 IAP TCP forwarding도 IAM을 통해 VM으로 가는 TCP 접속을 제어하는 접근 모델을 제공해요.

이런 서비스가 항상 Bastion Host를 대체한다는 뜻은 아니에요. 조직의 네트워크 구조, 감사 요구사항, 운영 도구, 클라우드 의존도에 따라 답이 달라져요. 중요한 질문은 "Bastion Host가 익숙한가"가 아니라 "관리 접근을 누가, 어떤 권한으로, 어떤 기록을 남기며 수행하는가"예요.

언제 Bastion Host가 맞을까요

다음 조건에 가깝다면 Bastion Host는 여전히 현실적인 선택이에요.

• 내부 서버에 public IP를 붙이고 싶지 않아요.
• 관리 접속을 한 경로로 모아야 해요.
• SSH, RDP 접근을 네트워크 규칙으로 명확히 제한할 수 있어요.
• Bastion Host 자체의 패치, 계정 관리, 로그 수집을 운영할 수 있어요.
• 기존 운영 절차가 SSH 기반이고, 관리형 세션 서비스로 곧장 옮기기 어려워요.

반대로 새로 만드는 환경이라면 관리형 세션 접근부터 검토하는 편이 좋아요. Bastion Host를 직접 운영하는 순간, 그 서버도 중요한 보안 자산이 되기 때문이에요.

정리

Bastion Host는 내부망을 지키는 마법의 요새가 아니에요. 내부 서버를 인터넷에 직접 열지 않기 위해 관리 접근 경로를 좁히는 장치예요. 그래서 도입 여부를 판단할 때는 "Bastion Host가 있나"보다 "관리 접근이 필요한 사람에게만 열리고, 기록되고, 회수될 수 있나"를 봐야 해요.

내부 서버에 public IP를 붙이려는 순간이 오면 한 번 멈춰보면 좋아요. 이 서버를 외부에 직접 열어야 하는지, 아니면 관리 접근 경로를 분리할 수 있는지부터 확인하는 것이 Bastion Host를 이해하는 가장 실용적인 출발점이에요.

참고

• AWS Systems Manager Session Manager
• Azure Bastion overview
• Google Cloud IAP TCP forwarding