시작하면서
이번 실습은 AWS의 네트워크 보안 구성 요소인 보안 그룹(Security Group) 과 네트워크 ACL(Network ACL) 이 실제로 어떻게 동작하는지를 깊이 있게 이해하고자 한 과정이었다. 둘 모두 트래픽을 제어하는 기능을 제공하지만, 실제 구성 환경에서 어떤 방식으로 서로 다르게 작동하며, 어떤 순서로 트래픽을 처리하는지를 명확히 알기 위해 직접 설정하고, 테스트하고, 하나씩 비교해보며 실험을 반복하였다.
1단계: VPC와 기본 구성 요소 생성 – 인터넷 연결의 전제 조건
먼저 CloudFormation 템플릿을 이용하여 하나의 VPC와 그 안에 퍼블릭 서브넷을 만들고, 인터넷 게이트웨이(IGW)를 연결하였다. 해당 서브넷에 EC2 인스턴스 두 개를 배치하고, 각 인스턴스에 퍼블릭 IP가 자동 할당되도록 설정하였다. 인스턴스의 보안 그룹에서는 TCP 22번 포트(SSH)와 TCP 80번 포트(HTTP)를 명시적으로 허용하였다.
MyPublicDefault:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref MyPublicRouting
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref MyIGW이 구성 이후, 외부 환경에서 해당 인스턴스의 퍼블릭 IP로 curl 요청을 보내면 웹 서버의 응답이 정상적으로 반환되는 것을 확인할 수 있었다. 퍼블릭 서브넷 구성과 인터넷 게이트웨이 연결, 보안 그룹 설정만으로 기본적인 인터넷 통신이 이루어진 것이다.
2단계: 네트워크 ACL을 새로 만들고 서브넷에 연결한 후 발생한 변화
실습을 위해 새롭게 MyACL을 생성하고 EC2가 존재하는 MypublicSubnet 서브넷에 명시적으로 연결하였다. 이 ACL은 아무런 규칙이 정의되지 않은 상태였으며, AWS에서는 명시적인 규칙이 없을 경우 모든 트래픽을 거부하는 기본 동작을 따른다.
이 설정 이후, 이전까지 정상적으로 응답되던 웹 요청이 모두 실패하기 시작했다. 외부에서 curl 요청을 보냈을 때, 브라우저나 터미널에서는 아무런 응답도 받을 수 없었다.
이러한 결과의 원인은 보안그룹보다 ACL이 먼저 평가되기 때문이다. 그러므로 요청이 ACL에 의해 차단되거나 응답 트래픽이 ACL의 규칙에 의해 반환되지 못한다면, 아무리 보안 그룹에서 허용하고 있더라도 통신은 이루어지지 않는다.
3단계: ACL 인바운드 규칙만 추가했을 때 느낀 한계
실습을 계속 진행하며 인바운드 방향의 ACL 규칙에 다음 항목을 추가하였다.
이 규칙을 적용한 이후에도, 예상과 달리 트래픽은 여전히 통과하지 않았다. 요청을 허용하는 인바운드 규칙만으로는 충분하지 않으며, 응답을 반환하기 위해서는 아웃바운드 방향에 대한 규칙도 반드시 설정되어야 한다는 것을 확인하였다.
이러한 경험을 통해, 보안 그룹의 편리함과는 달리 ACL은 양방향 모두에 대해 명시적으로 규칙을 구성해야 하는 엄격한 구조를 가진다는 점을 체감할 수 있었다.
4단계: 아웃바운드 응답 포트 열고 정상 통신 확인
ACL의 아웃바운드에 다음과 같은 규칙을 추가하였다.
웹 요청의 응답은 주로 ephemeral 포트(1024~65535)를 통해 반환되기 때문에, 이 포트를 명시적으로 허용해주어야 한다. 규칙을 추가한 이후, 다시 curl 명령어를 통해 테스트해본 결과 정상적으로 웹 페이지 응답을 받을 수 있었다.
ACL은 응답을 따로 기억하거나 허용하지 않기 때문에, 반드시 양방향의 트래픽을 동시에 고려해야 한다. ACL 구성 시 하나라도 빠진다면, 문제는 곧바로 발생하며 그 원인을 찾는 데 시간이 소요될 수 있다.
5단계: ACL 우선순위 규칙 실험 – 범위와 규칙 번호의 관계
다음으로 실험한 부분은 ACL 규칙의 평가 순서였다. ACL은 규칙 번호가 낮을수록 우선적으로 평가되며, 첫 번째로 일치하는 규칙이 적용된다. 이를 확인하기 위해 다음 두 가지 시나리오를 실험하였다.
시나리오 1 (정상 동작)
| Rule # | CIDR | Action |
|---|---|---|
| 100 | 100.1.1.0/24 | DENY |
| 200 | 100.1.0.0/16 | ALLOW |
이 경우, 좁은 범위를 먼저 차단하고, 이후 넓은 범위에 대해 허용하는 형태로 규칙이 동작한다.
시나리오 1: 좁은 범위 차단이 먼저 평가되는 경우
전체 IP 공간 (100.1.0.0/16)
┌────────────────────────────────────────────────────────────┐
│ -------- (차단) 특정 IP 대역: 100.1.1.0/24 │
│ +++++++++++++++++++++ (허용) │
└────────────────────────────────────────────────────────────┘
[Client IP: 100.1.1.10] → Rule 100 매칭 (100.1.1.0/24, DENY)
→ 평가 종료, 차단 적용결과적으로 100.1.1.0/24 대역은 차단되고, 나머지 대역은 허용된다.
시나리오 2 (의도대로 동작하지 않음)
| Rule # | CIDR | Action |
|---|---|---|
| 100 | 100.1.0.0/16 | ALLOW |
| 200 | 100.1.1.0/24 | DENY |
이 경우에는 넓은 범위가 먼저 평가되어 허용되었기 때문에, 이후의 차단 규칙은 적용되지 않는다.
시나리오 2: 넓은 범위 허용이 먼저 평가되는 경우
전체 IP 공간 (100.1.0.0/16)
┌────────────────────────────────────────────────────────────┐
│ +++++++++++++++++++++ (허용) │
│ -------- (차단) 특정 IP 대역: 100.1.1.0/24 │
└────────────────────────────────────────────────────────────┘
[Client IP: 100.1.1.10] → Rule 100 매칭 (100.1.0.0/16, ALLOW)
→ 평가 종료, 차단 규칙은 무시됨ACL은 단순히 규칙을 나열하는 것이 아니라, 설계 순서가 실질적인 동작 결과에 직접적인 영향을 준다. 범위가 좁은 규칙은 항상 더 앞서서 평가되어야 하며, 그렇지 않으면 차단이 이루어지지 않는다.
