Notice
Recent Posts
Recent Comments
Link
byworld 님의 블로그
20260426 바스티온 서버 본문
1. Bastion Server란 무엇인가
Bastion 서버는 사설망 내부 서버에 접근하기 위한 유일한 진입 지점(jump host)이다. 외부에서 내부 시스템으로 직접 접근하는 것을 차단하고, 반드시 이 서버를 경유하도록 강제하는 보안 구조다.
구조는 단순하다:
운영자 → Bastion → 내부 서버
- Bastion: Public subnet + Public IP
- 내부 서버: Private subnet + Private IP only
- 내부 서버는 Bastion을 통해서만 접근 가능
즉, Bastion은 네트워크의 choke point(통제 지점) 역할을 한다.
2. 왜 필요한가
(1) 공격 표면 축소
내부 서버에 직접 SSH를 열면 외부 공격 대상이 된다. Bastion을 두면 외부에서 접근 가능한 서버는 하나로 제한된다.
(2) 역할 분리
- Bastion: 접근 통제
- 내부 서버: 워크로드 처리
하나의 서버가 “진입점 + 서비스” 역할을 동시에 가지지 않도록 분리한다.
(3) 감사(Audit) 중앙화
모든 접근이 Bastion을 통과하므로:
- 접속 로그를 한 곳에서 관리 가능
- 누가 언제 어떤 서버에 접근했는지 추적 가능
(4) 운영 편의성 (IP 관리)
운영자 IP가 변경될 때:
- Bastion SG만 수정하면 됨
- 내부 서버 SG는 변경 불필요
3. 동작 방식
핵심 흐름:
- 운영자는 Bastion에 SSH 접속
- Bastion에서 내부 서버로 SSH 점프
- 내부 서버는 외부에서 직접 접근 불가
Security Group 구조:
- Bastion SG: 운영자 IP만 허용
- 내부 서버 SG: Bastion SG만 허용
4. 선택지 비교 (실제 의사결정 관점)
Bastion은 하나의 선택지일 뿐이고, 실제로는 여러 접근 방식이 존재한다.
1 직접 노출 (비추천)
- 내부 서버에 직접 SSH 허용
- 가장 간단하지만 보안 취약
2 Bastion (표준 패턴)
- 접근 지점을 하나로 통제
- 실무에서 가장 많이 쓰는 구조
3 모든 서버 Public 노출
- 운영 편의성은 좋지만 공격 표면 증가
- 권장되지 않음
4AWS Systems Manager Session Manager
- SSH 없이 콘솔 기반 접근
- 가장 모던한 방식
- 대신 비용/구성 복잡도 존재
5. 내가 선택한 방식
Bastion + 전용 SG + 전용 EIP 구조를 선택했다.
이유는 명확하다:
- 비용 대비 학습 가치 높음
- 실무 표준 패턴
- 운영 편의성과 보안 균형
특히 운영자 IP가 자주 바뀌는 환경에서는 Bastion 구조가 관리 비용을 크게 줄여준다.
6. 구축 핵심 단계
Step 1. Bastion 전용 Security Group
- SSH 22 → 운영자 IP만 허용
Step 2. Bastion EC2 생성
- Public subnet
- 작은 인스턴스 (t3.nano 수준)
- SSH 전용 용도
Step 3. Elastic IP 할당
- Bastion IP 고정
- SSH 설정 단순화
Step 4. 내부 서버 접근 제한
- SSH 22 → Bastion SG만 허용
7. 실무에서 중요한 포인트
1 Bastion은 최소 기능만 가져야 한다
- 애플리케이션 절대 올리지 않음
- 오직 접근 통제 역할만 수행
2 Bastion이 뚫리면 내부 전체 위험
→ 따라서:
- MFA
- 접근 IP 제한
- 로그 수집 필수
3 대체 기술 고려 필요
- Bastion은 전통적인 방식
- 최근에는 SSM 기반 접근이 점점 표준화되는 추세
8. 배운 점
- Bastion은 단순한 서버가 아니라 보안 아키텍처 패턴이다
- 핵심은 “접근 경로를 강제한다”는 것
- 네트워크 설계에서 책임 분리 (separation of concerns)를 구현하는 수단이다
한 줄 정리
Bastion 서버는 외부에서 내부 시스템으로 접근할 때 반드시 거쳐야 하는 단일 진입점으로, 접근 통제·보안 분리·감사를 가능하게 하는 핵심 인프라 패턴이다.
'TIL' 카테고리의 다른 글
| 20260429 HTTP 상태 코드와 400 vs 422 사이에서의 고민 (0) | 2026.04.29 |
|---|---|
| 20260427 헥사고널이 이벤트 기반 구조에 유리한 이유와 트레이드오프 (0) | 2026.04.27 |
| 20260425 클린 vs 헥사고널 아키텍처 (1) | 2026.04.25 |
| 20260424 - Outbox DLT 상태 머신과 async 콜백 race — saveAndFlush 는 commit 이 아니다 (0) | 2026.04.24 |
| 20260423 공통 모듈 구축기 (0) | 2026.04.23 |