클라우드 네트워크 방화벽 규칙 설정은 서버 접속 장애를 줄이고 불필요한 노출을 막기 위한 운영의 기본입니다. 서버는 정상인데 SSH, RDP, 웹 접속, 데이터베이스 연결이 되지 않는다면 가장 먼저 인바운드 규칙과 아웃바운드 규칙을 확인해야 합니다.
방화벽은 단순히 “열고 닫는 장치”가 아니라 서로 다른 보안 수준의 네트워크 또는 호스트 사이에서 트래픽 흐름을 제어하는 정책입니다. NIST SP 800-41 Rev.1도 방화벽을 네트워크 트래픽 흐름을 제어하는 장치 또는 프로그램으로 설명합니다. 클라우드에서는 이 개념이 보안 그룹, 네트워크 ACL, NSG, VPC 방화벽 같은 서비스로 구현됩니다.
방화벽 규칙 하나가 접속 장애와 보안 사고를 좌우합니다
클라우드 방화벽 규칙은 접근 가능 여부를 즉시 바꿉니다. 웹 서버의 443 포트를 닫으면 정상 애플리케이션도 외부에서 보이지 않고, 반대로 데이터베이스 포트를 인터넷 전체에 열면 공격 표면이 커집니다. 그래서 규칙을 만들 때는 “누가, 어디로, 어떤 프로토콜과 포트로, 왜 접근해야 하는가”를 먼저 정리해야 합니다.
온프레미스 방화벽은 중앙 장비를 기준으로 네트워크 경계 트래픽을 제어하는 경우가 많습니다. 반면 클라우드는 리소스 단위, 네트워크 인터페이스 단위, 서브넷 단위, VPC 네트워크 단위 규칙이 함께 존재합니다. 같은 “방화벽”이라는 이름을 쓰더라도 적용 위치와 상태 저장 여부가 다르므로, 서비스별 차이를 이해해야 장애 분석이 빨라집니다.
방화벽 규칙을 구성하는 핵심 요소
초보 운영자가 가장 많이 헷갈리는 부분은 규칙의 구성 요소입니다. 규칙은 보통 방향, 소스, 대상, 프로토콜, 포트, 동작, 우선순위로 설명할 수 있습니다.
| 요소 | 의미 | 설정 시 확인할 점 |
|---|---|---|
| 방향 | 인바운드 또는 아웃바운드 | 접속 요청이 들어오는지, 서버가 밖으로 나가는지 구분 |
| 소스 | 접속을 시작하는 IP, CIDR, 보안 그룹, 서비스 태그 | 0.0.0.0/0은 전체 인터넷을 의미하므로 신중히 사용 |
| 대상 | 트래픽이 도착하는 리소스 또는 대역 | 웹 서버, DB 서버, 서브넷, 인스턴스 태그 등 적용 범위 확인 |
| 프로토콜 | TCP, UDP, ICMP 등 | 서비스가 실제로 사용하는 프로토콜과 일치해야 함 |
| 포트 | 22, 3389, 80, 443, 3306 등 | 필요한 단일 포트 또는 최소 범위만 허용 |
| 동작 | 허용 또는 거부 | 서비스별 기본 정책과 명시적 거부 규칙의 영향을 확인 |
| 우선순위 | 규칙 평가 순서 | 낮은 숫자가 먼저 처리되는 서비스가 많지만 제품별 기준 확인 |
AWS, Azure, Google Cloud의 방화벽 구조 차이
AWS Security Group은 연결된 VPC 리소스의 인바운드와 아웃바운드 트래픽을 제어하는 가상 방화벽입니다. 상태 저장 방식이므로 허용된 요청에 대한 응답 트래픽은 반대 방향 규칙과 관계없이 허용됩니다. AWS Security Group 문서에서도 SSH 22번과 RDP 3389번을 전체 인터넷에 열기보다 특정 IP 범위로 제한하도록 안내합니다.
AWS Network ACL은 서브넷 수준에서 인바운드와 아웃바운드 트래픽을 허용하거나 거부합니다. Security Group과 달리 상태 비저장 방식이므로 인바운드 요청을 허용해도 응답 아웃바운드가 자동으로 허용되지 않습니다. 또한 규칙 번호가 낮은 것부터 평가되고, 일치하는 규칙을 만나면 이후 규칙은 평가하지 않습니다.
Azure Network Security Group, 즉 NSG는 Azure Virtual Network 내 리소스 간 트래픽을 필터링합니다. 규칙에는 소스, 대상, 프로토콜, 방향, 포트 범위, 허용 또는 거부 동작이 포함됩니다. 우선순위는 100부터 4096 사이 숫자를 사용하며 낮은 숫자가 먼저 처리됩니다. Azure NSG는 상태 저장 방식이므로 허용된 아웃바운드 요청의 응답 인바운드를 별도로 열 필요가 없습니다.
Google Cloud VPC 방화벽 규칙은 VPC 네트워크에 정의되지만 연결 허용 또는 거부는 인스턴스 단위로 적용됩니다. 각 규칙은 인그레스 또는 이그레스 중 하나의 방향에만 적용되며 상태 저장 방식입니다. 따라서 한 방향 연결이 허용되면 해당 연결의 응답 트래픽도 허용됩니다. 설계 원칙은 기본적으로 차단하고 필요한 프로토콜과 포트만 여는 최소 권한 원칙에 가깝게 가져가는 것이 안전합니다.
안전한 규칙은 요구사항 정리에서 시작됩니다
방화벽 규칙을 만들기 전에 서비스 흐름을 먼저 적어야 합니다. 예를 들어 사용자는 인터넷에서 로드밸런서의 443 포트로 접근하고, 로드밸런서는 웹 서버의 8080 포트로 전달하며, 웹 서버만 DB 서버의 3306 포트에 접근한다는 식입니다. 이 흐름이 있어야 CIDR, 포트 허용, 대상 지정이 명확해집니다.
- 접근 주체를 정리합니다. 인터넷 사용자, 관리자 PC, VPN 대역, 애플리케이션 서버, 배치 서버를 구분합니다.
- 기본 차단 후 필요한 트래픽만 허용합니다. 모든 포트를 열어 테스트한 뒤 나중에 줄이는 방식은 운영 반영 전에 누락되기 쉽습니다.
- 관리 포트는 고정 IP 또는 VPN으로 제한합니다. SSH 22번, RDP 3389번은 0.0.0.0/0이나 ::/0로 열지 않는 것이 기본입니다.
- 우선순위와 이름을 운영 기준에 맞춥니다. allow-web-https, allow-admin-ssh-vpn처럼 목적이 보이는 이름과 설명을 남깁니다.
- 테스트와 로그 확인을 함께 진행합니다. 접속 성공 여부만 보지 말고 플로우 로그, NSG Flow Logs, 방화벽 로그 등으로 실제 경로를 확인합니다.
자주 사용하는 방화벽 규칙 예시
아래 예시는 실제 운영에 그대로 복사하기보다 설계 기준으로 활용해야 합니다. 회사의 IP 대역, VPN 구성, 로드밸런서 구조, 애플리케이션 포트에 맞춰 조정하고 변경 승인 절차를 거치는 것이 좋습니다.
| 목적 | 방향 | 소스 | 대상 | 프로토콜/포트 | 권장 기준 |
|---|---|---|---|---|---|
| 웹 서비스 공개 | 인바운드 | 0.0.0.0/0 | 로드밸런서 또는 웹 서버 | TCP 80, 443 | 가능하면 443 중심으로 운영하고 80은 리다이렉트 용도로 제한 |
| SSH 관리 | 인바운드 | 관리자 고정 IP 또는 VPN CIDR | 리눅스 서버 | TCP 22 | 전체 인터넷 개방 금지, MFA와 키 관리 병행 |
| RDP 관리 | 인바운드 | 관리자 고정 IP 또는 Bastion 대역 | 윈도우 서버 | TCP 3389 | Bastion, VPN, 점프 서버 사용 권장 |
| DB 접근 | 인바운드 | 애플리케이션 서버 보안 그룹 또는 내부 CIDR | DB 서버 | TCP 3306, 5432, 1433 | 인터넷 직접 접근 차단, 앱 계층에서만 허용 |
| 외부 업데이트 | 아웃바운드 | 서버 | 패키지 저장소, 보안 업데이트 엔드포인트 | TCP 443 | 무제한 아웃바운드가 필요하지 않다면 목적지 제한 검토 |
실무에서 자주 발생하는 설정 실수
가장 위험한 실수는 관리 포트를 전체 인터넷에 여는 것입니다. “잠깐만 열어두자”는 예외가 장기간 방치되면 자동 스캔과 무차별 대입 공격의 대상이 됩니다. 임시 규칙이라면 만료일, 요청자, 승인자, 삭제 예정일을 설명 필드나 변경 티켓에 남겨야 합니다.
두 번째 실수는 포트 범위를 넓게 허용하는 것입니다. TCP 1-65535처럼 넓은 범위는 장애 분석을 쉽게 만들 수는 있지만, 운영 환경에서는 불필요한 서비스까지 노출합니다. 테스트 목적이라면 격리된 환경에서만 사용하고 운영 반영 전에는 반드시 최소 포트로 줄여야 합니다.
세 번째는 우선순위 충돌입니다. Azure NSG나 Network ACL처럼 우선순위에 따라 평가가 멈추는 구조에서는 상단의 넓은 허용 규칙이 하단의 세부 거부 규칙을 무력화할 수 있습니다. 반대로 상단의 거부 규칙 때문에 정상 트래픽이 차단될 수도 있습니다. 규칙은 넓은 범위보다 구체적인 목적을 기준으로 정리하는 것이 좋습니다.
마지막으로 인바운드만 확인하고 아웃바운드를 놓치는 경우가 많습니다. 특히 상태 비저장 방식의 네트워크 ACL은 응답 트래픽을 위한 반대 방향 규칙이 필요할 수 있습니다. 로드밸런서 헬스 체크, 클라우드 메타데이터 서버, DNS, 시간 동기화, 패키지 업데이트처럼 플랫폼 운영에 필요한 예외도 함께 검토해야 합니다.
접속이 안 될 때는 경로 전체를 확인합니다
방화벽만 보고 결론을 내리면 원인을 놓칠 수 있습니다. 접속 장애는 보안 규칙, 라우팅 테이블, 로드밸런서 리스너, 대상 그룹 상태, 운영체제 방화벽, 애플리케이션 리슨 포트가 함께 맞아야 해결됩니다.
- 요청 방향이 인바운드인지 아웃바운드인지 확인합니다.
- 소스 IP가 실제 공인 IP인지, NAT 또는 프록시 이후 IP인지 확인합니다.
- CIDR 표기가 정확한지 확인합니다. 예를 들어 /32는 단일 IPv4 주소를 의미합니다.
- TCP와 UDP를 혼동하지 않았는지 확인합니다.
- 서비스가 실제로 해당 포트에서 리슨 중인지 확인합니다.
- 상태 저장 규칙인지, 상태 비저장 규칙인지 구분합니다.
- 우선순위가 높은 거부 규칙에 먼저 매칭되지 않는지 확인합니다.
- 라우팅 테이블, NAT 게이트웨이, 인터넷 게이트웨이, 피어링 경로를 함께 점검합니다.
- 플로우 로그에서 허용 또는 차단 기록을 확인해 실제 차단 지점을 좁힙니다.
운영 환경에서는 규칙도 자산처럼 관리해야 합니다
클라우드 네트워크 방화벽 규칙 설정의 핵심은 필요한 트래픽만 명확히 허용하는 것입니다. 최소 권한 원칙을 적용해 대상, 포트, 프로토콜, 소스 범위를 줄이고, 변경 이력과 승인 절차를 남겨야 합니다. 사용하지 않는 규칙은 정기적으로 삭제하고, 태그와 설명 필드를 활용해 소유자와 목적을 식별할 수 있어야 합니다.
방화벽은 IAM, 패치, 암호화, 취약점 관리, 로그 모니터링을 대체하지 않습니다. 다만 네트워크 접근의 첫 번째 통제선으로서 매우 중요합니다. 서비스 흐름을 문서화하고, 보안 그룹·네트워크 ACL·NSG·VPC 방화벽의 차이를 이해하며, 테스트와 로그 확인을 습관화하면 접속 장애와 과도한 노출을 동시에 줄일 수 있습니다.