인프라나 클라우드 환경을 운영하다 보면 네트워크 접근 제어와 관련된 여러 개념을 자주 접하게 됩니다. 대표적으로 방화벽, 보안그룹, NACL이 있습니다.
이 세 가지는 모두 트래픽을 허용하거나 차단한다는 점에서 비슷해 보입니다. 하지만 실제로는 적용 위치, 동작 방식, 관리 목적이 다르기 때문에 구분해서 이해하는 것이 중요합니다.
예를 들어 웹 서버의 443 포트가 보안그룹에서는 허용되어 있어도 NACL, 라우팅, OS 방화벽 설정에 따라 접속이 되지 않을 수 있습니다. 반대로 서비스는 정상 동작하더라도 SSH, RDP, DB 포트가 전체 대역에 열려 있다면 보안상 위험한 상태일 수 있습니다.
이번 글에서는 방화벽, 보안그룹, NACL의 차이를 정리하고, 실무에서 접근제어 설정을 점검할 때 확인해야 할 체크포인트를 함께 살펴보겠습니다.
핵심 정리
방화벽, 보안그룹, NACL은 모두 트래픽을 제어하지만, 적용 위치와 동작 방식이 다릅니다. 실무 점검에서는 "어디에서 허용 또는 차단되고 있는지"를 함께 확인해야 합니다.
목차
목차 항목을 클릭하면 해당 영역으로 이동하고, 본문 제목을 클릭하면 다시 목차로 돌아옵니다.
방화벽, 보안그룹, NACL이 헷갈리는 이유는 모두 "트래픽 제어"라는 공통된 역할을 가지고 있기 때문입니다. 하지만 세부적으로 보면 적용 위치와 동작 방식이 다릅니다.
방화벽은 네트워크 경계나 서버 내부 등 여러 위치에서 트래픽을 제어하는 장비 또는 기능을 의미합니다. 예를 들어 인터넷과 내부망 사이에서 동작하는 네트워크 경계 방화벽이 있고, 서버 내부에는 OS 방화벽이 적용될 수 있습니다. 보안그룹은 클라우드 환경에서 인스턴스 단위로 적용되는 가상 방화벽 성격의 접근제어 기능이며, NACL은 서브넷 단위로 적용되는 네트워크 접근 제어 목록입니다.
간단히 정리하면 다음과 같습니다.
| 구분 | 주요 역할 |
|---|
| 방화벽 | 네트워크 경계 또는 서버 내부에서 트래픽 허용/차단 |
| 보안그룹 | 인스턴스 단위로 접근 제어 |
| NACL | 서브넷 단위로 접근 제어 |
실무에서는 이 세 가지가 함께 동작하는 경우가 많습니다. 따라서 단순히 "포트가 열려 있다"는 사실만 확인하기보다는, 어느 계층에서 어떤 정책이 적용되고 있는지를 함께 확인해야 합니다.
네트워크 접근제어 정책은 여러 계층에서 함께 적용될 수 있습니다.
방화벽은 네트워크 보안에서 가장 기본적인 접근제어 기능입니다. 설정된 정책에 따라 외부에서 내부로 들어오는 트래픽과 내부에서 외부로 나가는 트래픽을 허용하거나 차단합니다.
방화벽은 온프레미스의 물리 장비뿐만 아니라 서버 내부의 OS 방화벽, 클라우드 방화벽, 웹 방화벽 등 다양한 형태로 구현될 수 있습니다. 클라우드 환경에서는 여기에 보안그룹과 NACL 같은 접근제어 기능을 함께 적용할 수 있습니다.
이러한 접근제어 기능은 서비스에 필요한 통신만 허용하고, 불필요한 접근은 차단하는 방식으로 운영합니다. 예를 들어 외부 사용자가 DB 서버의 3306 포트로 직접 접근하는 것은 일반적으로 차단해야 하며, SSH와 같은 관리 포트도 전체 대역이 아니라 관리자 IP, VPN 대역, Bastion Host 등 제한된 경로에서만 접근하도록 설정하는 것이 좋습니다.
보안그룹은 클라우드 환경에서 많이 사용하는 접근제어 기능입니다. AWS 기준으로는 EC2 인스턴스에 적용되는 가상 방화벽으로 볼 수 있습니다. Azure, GCP, NCP, SCP 등 다른 클라우드에서도 이름은 다르지만 유사한 접근제어 기능을 제공합니다.
보안그룹의 핵심은 인스턴스 단위로 트래픽을 제어한다는 점입니다. 예를 들어 웹 서버 인스턴스에는 80, 443 포트를 허용하고, 관리용 SSH 접속은 특정 관리자 IP에서만 허용하도록 설정할 수 있습니다.
| 방향 | 출발지 | 포트 | 설명 |
|---|
| Inbound | 0.0.0.0/0 | 80 | HTTP 접근 허용 |
| Inbound | 0.0.0.0/0 | 443 | HTTPS 접근 허용 |
| Inbound | 관리자 IP | 22 | SSH 접속 허용 |
보안그룹의 중요한 특징은 일반적으로 Stateful 방식으로 동작한다는 점입니다. 즉, 허용된 요청에 대한 응답 트래픽은 별도의 반대 방향 규칙을 세밀하게 지정하지 않아도 처리될 수 있습니다.
이 때문에 보안그룹은 비교적 관리가 쉬운 편입니다. 다만 관리가 쉽다고 해서 모든 포트를 넓게 열어두면 안 됩니다. 특히 SSH 22번, RDP 3389번, 데이터베이스 포트가 0.0.0.0/0으로 열려 있는지 여부는 반드시 확인해야 합니다.
NACL은 Network ACL의 약자로, 네트워크 접근 제어 목록을 의미합니다. 보안그룹이 인스턴스 단위로 적용된다면, NACL은 보통 서브넷 단위로 적용됩니다.
즉, 특정 서브넷으로 들어오고 나가는 트래픽을 제어하는 역할을 합니다.
| 구분 | 적용 단위 |
|---|
| 보안그룹 | 인스턴스 단위 |
| NACL | 서브넷 단위 |
NACL의 중요한 특징은 Stateless 방식으로 동작한다는 점입니다. 즉, 들어오는 트래픽과 나가는 트래픽을 각각 독립적으로 판단하기 때문에 Inbound와 Outbound 규칙을 함께 확인해야 합니다.
NACL은 서브넷 단위의 보조적인 접근제어 수단으로 활용할 수 있지만, 규칙을 잘못 설정하면 정상적인 서비스 트래픽까지 차단될 수 있으므로 주의가 필요합니다.
보안그룹과 NACL을 이해할 때 가장 중요한 개념 중 하나가 Stateful과 Stateless입니다.
| 구분 | Stateful | Stateless |
|---|
| 연결 상태 기억 | 기억함 | 기억하지 않음 |
| 응답 트래픽 처리 | 자동 허용 가능 | 별도 규칙 필요 |
| 대표 예시 | 보안그룹 | NACL |
| 관리 난이도 | 상대적으로 쉬움 | 상대적으로 주의 필요 |
예를 들어 사용자가 웹 서버의 443 포트로 HTTPS 요청을 보낸다고 가정해 보겠습니다.
사용자에서 웹 서버로 들어오는 요청은 Inbound 트래픽입니다. 웹 서버가 사용자에게 응답하는 트래픽은 Outbound 트래픽입니다.
보안그룹은 Stateful 방식이므로 사용자의 요청이 허용되면 응답 트래픽은 자동으로 허용될 수 있습니다. 반면 NACL은 Stateless 방식이므로 요청 방향과 응답 방향의 규칙을 각각 확인해야 합니다.
이 차이점을 놓치면 "분명히 인바운드 포트는 열려 있는데 접속이 되지 않는" 상황에서 원인을 찾기 어려울 수 있습니다.
실무에서는 방화벽, 보안그룹, NACL을 단순히 개념으로만 이해하는 것보다 실제 점검 상황과 연결해서 보는 것이 중요합니다.
첫 번째는 관리 포트 전체 공개입니다. SSH 22번, RDP 3389번과 같은 관리 포트가 0.0.0.0/0으로 열려 있으면 외부에서 누구나 접속을 시도할 수 있는 상태가 됩니다. 실제 접속에 계정과 비밀번호 또는 키가 필요하더라도, 공격 표면이 넓어지기 때문에 위험합니다. 관리 포트는 관리자 IP, VPN 대역, Bastion Host 등 제한된 경로에서만 접근할 수 있도록 설정하는 것이 좋습니다.
두 번째는 데이터베이스 포트 외부 노출입니다. MySQL 3306, PostgreSQL 5432, MSSQL 1433, Redis 6379와 같은 포트가 외부에 직접 공개되어 있으면 보안상 위험합니다. 데이터베이스는 일반적으로 애플리케이션 서버나 내부망에서만 접근하도록 제한하는 것이 바람직합니다.
세 번째는 보안그룹과 NACL의 정책 불일치입니다. 보안그룹에서는 443 포트를 허용했지만 NACL에서 Inbound 또는 Outbound가 차단되어 있으면 서비스 접속이 실패할 수 있습니다. 이 경우 보안그룹만 보고 정상으로 판단하면 원인을 놓칠 수 있습니다.
네 번째는 OS 내부 방화벽 설정입니다. 클라우드 보안그룹과 NACL이 모두 허용되어 있어도 서버 내부의 firewalld, iptables, Windows Defender Firewall 등에서 포트가 차단되어 있으면 접속이 되지 않을 수 있습니다. 따라서 접근 장애를 분석할 때는 클라우드 네트워크 정책과 OS 내부 방화벽을 함께 확인해야 합니다.
접근제어 설정을 점검할 때는 다음 항목을 중심으로 확인하는 것이 좋습니다.
| 점검 항목 | 확인 내용 |
|---|
| 관리 포트 공개 여부 | SSH, RDP가 0.0.0.0/0 또는 Any로 열려 있는지 확인 |
| 데이터베이스 포트 노출 여부 | DB 포트가 외부에 직접 공개되어 있는지 확인 |
| 불필요한 전체 공개 여부 | 서비스 목적과 무관한 포트가 전체 공개되어 있는지 확인 |
| Inbound/Outbound 정책 | 필요한 방향의 트래픽만 허용되어 있는지 확인 |
| NACL 양방향 규칙 | Stateless 특성상 요청과 응답 방향 규칙이 모두 적절한지 확인 |
| OS 방화벽 | 서버 내부 방화벽에서 포트가 차단되어 있지 않은지 확인 |
| 정책 설명 및 관리 이력 | 규칙의 목적, 담당자, 생성 사유가 관리되고 있는지 확인 |
특히 보안 점검에서는 "서비스가 정상적으로 동작하는지"만 보는 것이 아니라, "불필요하게 열려 있는 접근 경로가 없는지"를 함께 확인해야 합니다.
예를 들어 웹 서비스 제공을 위해 80, 443 포트를 전체 공개하는 것은 일반적인 구성일 수 있습니다. 하지만 SSH, RDP, DB 포트가 전체 공개되어 있다면 보안상 위험한 설정으로 볼 수 있습니다.
또한 접근제어 정책은 한 번 설정하고 끝나는 항목이 아닙니다. 서비스 변경, 운영자 변경, 테스트 환경 구성 이후 불필요한 허용 정책이 남아 있을 수 있으므로 주기적으로 검토하는 것이 필요합니다.
실무 점검 핵심
접근제어 점검의 핵심은 서비스에 필요한 통신만 허용하고, 불필요한 접근 경로는 제거하는 것입니다.
방화벽, 보안그룹, NACL은 모두 네트워크 트래픽을 제어하는 기능이지만 적용 위치와 동작 방식이 다릅니다. 방화벽은 네트워크 경계 또는 서버 내부에서 트래픽을 제어하고, 보안그룹은 인스턴스 단위의 Stateful 접근제어, NACL은 서브넷 단위의 Stateless 접근제어로 이해할 수 있습니다.
핵심만 정리하면 다음과 같습니다.
| 구분 | 한 줄 정리 |
|---|
| 방화벽 | 네트워크 경계 또는 서버 내부에서 트래픽을 허용하거나 차단하는 보안 기능 |
| 보안그룹 | 인스턴스 단위로 적용되는 Stateful 접근제어 |
| NACL | 서브넷 단위로 적용되는 Stateless 접근제어 |
접근제어 점검의 핵심은 필요한 통신은 허용하고, 불필요한 접근 경로는 차단하는 것입니다. 단순히 포트 개방 여부만 확인하는 것이 아니라, 각 정책이 어느 위치에서 어떤 역할을 하는지 함께 보는 것이 중요합니다.
 김창식 | kcs@cela.kr |
인프라나 클라우드 환경을 운영하다 보면 네트워크 접근 제어와 관련된 여러 개념을 자주 접하게 됩니다. 대표적으로 방화벽, 보안그룹, NACL이 있습니다.
이 세 가지는 모두 트래픽을 허용하거나 차단한다는 점에서 비슷해 보입니다. 하지만 실제로는 적용 위치, 동작 방식, 관리 목적이 다르기 때문에 구분해서 이해하는 것이 중요합니다.
예를 들어 웹 서버의 443 포트가 보안그룹에서는 허용되어 있어도 NACL, 라우팅, OS 방화벽 설정에 따라 접속이 되지 않을 수 있습니다. 반대로 서비스는 정상 동작하더라도 SSH, RDP, DB 포트가 전체 대역에 열려 있다면 보안상 위험한 상태일 수 있습니다.
이번 글에서는 방화벽, 보안그룹, NACL의 차이를 정리하고, 실무에서 접근제어 설정을 점검할 때 확인해야 할 체크포인트를 함께 살펴보겠습니다.
핵심 정리
방화벽, 보안그룹, NACL은 모두 트래픽을 제어하지만, 적용 위치와 동작 방식이 다릅니다. 실무 점검에서는 "어디에서 허용 또는 차단되고 있는지"를 함께 확인해야 합니다.
목차
목차 항목을 클릭하면 해당 영역으로 이동하고, 본문 제목을 클릭하면 다시 목차로 돌아옵니다.
1. 방화벽, 보안그룹, NACL이 헷갈리는 이유
방화벽, 보안그룹, NACL이 헷갈리는 이유는 모두 "트래픽 제어"라는 공통된 역할을 가지고 있기 때문입니다. 하지만 세부적으로 보면 적용 위치와 동작 방식이 다릅니다.
방화벽은 네트워크 경계나 서버 내부 등 여러 위치에서 트래픽을 제어하는 장비 또는 기능을 의미합니다. 예를 들어 인터넷과 내부망 사이에서 동작하는 네트워크 경계 방화벽이 있고, 서버 내부에는 OS 방화벽이 적용될 수 있습니다. 보안그룹은 클라우드 환경에서 인스턴스 단위로 적용되는 가상 방화벽 성격의 접근제어 기능이며, NACL은 서브넷 단위로 적용되는 네트워크 접근 제어 목록입니다.
간단히 정리하면 다음과 같습니다.
실무에서는 이 세 가지가 함께 동작하는 경우가 많습니다. 따라서 단순히 "포트가 열려 있다"는 사실만 확인하기보다는, 어느 계층에서 어떤 정책이 적용되고 있는지를 함께 확인해야 합니다.
네트워크 접근제어 정책은 여러 계층에서 함께 적용될 수 있습니다.
2. 방화벽이란?
방화벽은 네트워크 보안에서 가장 기본적인 접근제어 기능입니다. 설정된 정책에 따라 외부에서 내부로 들어오는 트래픽과 내부에서 외부로 나가는 트래픽을 허용하거나 차단합니다.
방화벽은 온프레미스의 물리 장비뿐만 아니라 서버 내부의 OS 방화벽, 클라우드 방화벽, 웹 방화벽 등 다양한 형태로 구현될 수 있습니다. 클라우드 환경에서는 여기에 보안그룹과 NACL 같은 접근제어 기능을 함께 적용할 수 있습니다.
이러한 접근제어 기능은 서비스에 필요한 통신만 허용하고, 불필요한 접근은 차단하는 방식으로 운영합니다. 예를 들어 외부 사용자가 DB 서버의 3306 포트로 직접 접근하는 것은 일반적으로 차단해야 하며, SSH와 같은 관리 포트도 전체 대역이 아니라 관리자 IP, VPN 대역, Bastion Host 등 제한된 경로에서만 접근하도록 설정하는 것이 좋습니다.
3. 보안그룹이란?
보안그룹은 클라우드 환경에서 많이 사용하는 접근제어 기능입니다. AWS 기준으로는 EC2 인스턴스에 적용되는 가상 방화벽으로 볼 수 있습니다. Azure, GCP, NCP, SCP 등 다른 클라우드에서도 이름은 다르지만 유사한 접근제어 기능을 제공합니다.
보안그룹의 핵심은 인스턴스 단위로 트래픽을 제어한다는 점입니다. 예를 들어 웹 서버 인스턴스에는 80, 443 포트를 허용하고, 관리용 SSH 접속은 특정 관리자 IP에서만 허용하도록 설정할 수 있습니다.
보안그룹의 중요한 특징은 일반적으로 Stateful 방식으로 동작한다는 점입니다. 즉, 허용된 요청에 대한 응답 트래픽은 별도의 반대 방향 규칙을 세밀하게 지정하지 않아도 처리될 수 있습니다.
이 때문에 보안그룹은 비교적 관리가 쉬운 편입니다. 다만 관리가 쉽다고 해서 모든 포트를 넓게 열어두면 안 됩니다. 특히 SSH 22번, RDP 3389번, 데이터베이스 포트가 0.0.0.0/0으로 열려 있는지 여부는 반드시 확인해야 합니다.
4. NACL이란?
NACL은 Network ACL의 약자로, 네트워크 접근 제어 목록을 의미합니다. 보안그룹이 인스턴스 단위로 적용된다면, NACL은 보통 서브넷 단위로 적용됩니다.
즉, 특정 서브넷으로 들어오고 나가는 트래픽을 제어하는 역할을 합니다.
NACL의 중요한 특징은 Stateless 방식으로 동작한다는 점입니다. 즉, 들어오는 트래픽과 나가는 트래픽을 각각 독립적으로 판단하기 때문에 Inbound와 Outbound 규칙을 함께 확인해야 합니다.
NACL은 서브넷 단위의 보조적인 접근제어 수단으로 활용할 수 있지만, 규칙을 잘못 설정하면 정상적인 서비스 트래픽까지 차단될 수 있으므로 주의가 필요합니다.
5. Stateful과 Stateless 차이
보안그룹과 NACL을 이해할 때 가장 중요한 개념 중 하나가 Stateful과 Stateless입니다.
예를 들어 사용자가 웹 서버의 443 포트로 HTTPS 요청을 보낸다고 가정해 보겠습니다.
사용자에서 웹 서버로 들어오는 요청은 Inbound 트래픽입니다. 웹 서버가 사용자에게 응답하는 트래픽은 Outbound 트래픽입니다.
보안그룹은 Stateful 방식이므로 사용자의 요청이 허용되면 응답 트래픽은 자동으로 허용될 수 있습니다. 반면 NACL은 Stateless 방식이므로 요청 방향과 응답 방향의 규칙을 각각 확인해야 합니다.
이 차이점을 놓치면 "분명히 인바운드 포트는 열려 있는데 접속이 되지 않는" 상황에서 원인을 찾기 어려울 수 있습니다.
6. 실무에서 자주 보는 점검 사례
실무에서는 방화벽, 보안그룹, NACL을 단순히 개념으로만 이해하는 것보다 실제 점검 상황과 연결해서 보는 것이 중요합니다.
첫 번째는 관리 포트 전체 공개입니다. SSH 22번, RDP 3389번과 같은 관리 포트가 0.0.0.0/0으로 열려 있으면 외부에서 누구나 접속을 시도할 수 있는 상태가 됩니다. 실제 접속에 계정과 비밀번호 또는 키가 필요하더라도, 공격 표면이 넓어지기 때문에 위험합니다. 관리 포트는 관리자 IP, VPN 대역, Bastion Host 등 제한된 경로에서만 접근할 수 있도록 설정하는 것이 좋습니다.
두 번째는 데이터베이스 포트 외부 노출입니다. MySQL 3306, PostgreSQL 5432, MSSQL 1433, Redis 6379와 같은 포트가 외부에 직접 공개되어 있으면 보안상 위험합니다. 데이터베이스는 일반적으로 애플리케이션 서버나 내부망에서만 접근하도록 제한하는 것이 바람직합니다.
세 번째는 보안그룹과 NACL의 정책 불일치입니다. 보안그룹에서는 443 포트를 허용했지만 NACL에서 Inbound 또는 Outbound가 차단되어 있으면 서비스 접속이 실패할 수 있습니다. 이 경우 보안그룹만 보고 정상으로 판단하면 원인을 놓칠 수 있습니다.
네 번째는 OS 내부 방화벽 설정입니다. 클라우드 보안그룹과 NACL이 모두 허용되어 있어도 서버 내부의 firewalld, iptables, Windows Defender Firewall 등에서 포트가 차단되어 있으면 접속이 되지 않을 수 있습니다. 따라서 접근 장애를 분석할 때는 클라우드 네트워크 정책과 OS 내부 방화벽을 함께 확인해야 합니다.
7. 접근제어 점검 체크포인트
접근제어 설정을 점검할 때는 다음 항목을 중심으로 확인하는 것이 좋습니다.
특히 보안 점검에서는 "서비스가 정상적으로 동작하는지"만 보는 것이 아니라, "불필요하게 열려 있는 접근 경로가 없는지"를 함께 확인해야 합니다.
예를 들어 웹 서비스 제공을 위해 80, 443 포트를 전체 공개하는 것은 일반적인 구성일 수 있습니다. 하지만 SSH, RDP, DB 포트가 전체 공개되어 있다면 보안상 위험한 설정으로 볼 수 있습니다.
또한 접근제어 정책은 한 번 설정하고 끝나는 항목이 아닙니다. 서비스 변경, 운영자 변경, 테스트 환경 구성 이후 불필요한 허용 정책이 남아 있을 수 있으므로 주기적으로 검토하는 것이 필요합니다.
실무 점검 핵심
접근제어 점검의 핵심은 서비스에 필요한 통신만 허용하고, 불필요한 접근 경로는 제거하는 것입니다.
8. 마무리
방화벽, 보안그룹, NACL은 모두 네트워크 트래픽을 제어하는 기능이지만 적용 위치와 동작 방식이 다릅니다. 방화벽은 네트워크 경계 또는 서버 내부에서 트래픽을 제어하고, 보안그룹은 인스턴스 단위의 Stateful 접근제어, NACL은 서브넷 단위의 Stateless 접근제어로 이해할 수 있습니다.
핵심만 정리하면 다음과 같습니다.
접근제어 점검의 핵심은 필요한 통신은 허용하고, 불필요한 접근 경로는 차단하는 것입니다. 단순히 포트 개방 여부만 확인하는 것이 아니라, 각 정책이 어느 위치에서 어떤 역할을 하는지 함께 보는 것이 중요합니다.
참고 자료
김창식 | kcs@cela.kr