클라우드 NSG와 보안 그룹 인바운드 규칙: 포트를 열기 전 정할 것

인바운드 규칙은 '포트를 연다'는 한 줄보다 구체적이다. 누가, 어떤 프로토콜로, 어느 포트에 들어올 수 있는지를 정하는 접근 제어다. Azure NSG에는 규칙 우선순위가 있지만 AWS 보안 그룹에는 같은 방식의 우선순위가 없다.

네 가지 값을 먼저 적는다

웹 서비스라면 보통 인터넷 사용자가 HTTPS 포트에 접근해야 할 수 있다. 반면 관리용 SSH나 원격 데스크톱은 특정 관리자 네트워크나 VPN에서만 접근하도록 제한하는 것이 기본이다. 0.0.0.0/0은 모든 IPv4 출발지를 뜻하므로 편의상 관리 포트에 쓰면 안 된다.

예를 들어 공개 웹 서버라면 TCP 443은 사용자에게, TCP 22는 승인된 관리 네트워크에만 허용한다. 데이터베이스 포트는 인터넷이 아니라 애플리케이션 계층에서만 접근하게 한다. 출발지와 목적지를 먼저 정한 뒤 규칙을 만들면 '일단 전체 개방'이라는 위험한 지름길을 피할 수 있다.

관리용 VM의 SSH 규칙을 적어 보면 범위가 더 분명해진다. 아래 주소는 설명용 예약 주소이며 실제 규칙에는 승인된 접속 지점의 주소를 사용한다.

허용 지점에서는 접속하고 다른 지점에서는 실패하는지 확인한다. 두 지점 모두 실패한다면 규칙을 전면 개방하기 전에 SSH 리스너·OS 방화벽·라우팅을 차례로 확인한다.

규칙은 서비스 경로와 함께 설계한다

공개 로드 밸런서는 사용자 트래픽을 받고, 애플리케이션 서버는 로드 밸런서에서만 받도록 분리할 수 있다. 데이터베이스는 애플리케이션 서브넷이나 보안 그룹에서만 접근하게 한다. 각 계층을 모두 인터넷에 열어두면 한 규칙의 실수가 전체 공격면이 된다.

Azure NSG는 숫자가 작은 규칙을 먼저 평가하고 일치하면 멈춘다. 따라서 허용 규칙보다 앞선 거부 규칙이 있는지 확인한다. AWS 보안 그룹은 허용 규칙을 모아 평가하며 거부 규칙이나 우선순위를 만들지 않는다. 둘을 같은 규칙표로 해석하지 말자.

변경 뒤에는 연결과 로그를 확인한다

규칙을 저장했다고 서비스가 자동으로 정상화되지는 않는다. 서버 프로세스의 리스닝, 라우팅, 운영체제 방화벽도 함께 확인한다. 임시 규칙에는 만료와 소유자를 남기고, 문제 해결 뒤 더 넓게 연 규칙을 회수하자. 관리 경로는 가능하면 Bastion이나 사설망으로 제한한다.

핵심 요약

인바운드 규칙은 출발지·프로토콜·포트의 조합이다. Azure NSG에서는 우선순위를 추가로, AWS 보안 그룹에서는 허용 규칙의 합집합을 확인한다. 관리 포트는 좁게 열고 변경 뒤에는 실제 연결과 로그로 검증하자.