실습 목표 : VPC에서 보안 그룹과 네트워크 ACL을 생성하여 동작의 차이를 이해하고, VPC 플로우 로그를 통해 레코드를 수집하여 접속 허용과 거부를 확인한다.
기본 실습 환경은 CloudFormation을 통해 구성한다.
VPC 플로우 로그와 CloudWatch는 아직 생성하지 않았다.
보안 그룹을 통한 접근 제어
먼저, 보안 그룹을 통해 접근 제어를 해보자. 보안그룹은 Stateful 한 동작 제어를 한다.
이해를 돕기 위해 먼저 Server-SG의 보안 그룹에서 아웃바운드 규칙을 삭제 한 후 실습을 진행하겠다.
다음으로 사용자 PC에서 Server-EC2로 SSH 접근을 시도해보자. 아래와 같이 정상접속되는 것을 확인할 수 있다.
아주 당연한 결과처럼 보이지만, 현재 적용중인 Server-SG 보안 그룹의 인바운드 규칙과 아웃바운드 규칙을 대입하여 왜 통신이 이루어지고 있는가를 생각해보자.
- 사용자 PC에서 Server-EC2로 SSH 접근을 시도하면 보안 그룹에서 인바운드 규칙을 확인한다. 규칙에 허용되기 때문에 사용자 PC는 접근이 허용되고 EC2에 도달하게 된다.
- 보안 그룹은 Stateful 한 접근 제어 동작을 하므로 아웃바운드 규칙을 없앴지만, 사용자 PC로 응답을 돌려주게된다.
다음으로 EC2 서버에서 외부 인터넷 구간으로 HTTP 접근을 시도해보자.
아웃바운드 규칙이 없어 EC2 인스턴스에서 바깥으로 나가는 방향의 통신이 이루어 질 수 없는 것을 확인할 수 있다.
* ifconfig.me 는 접근한 사용자 단말의 공인 IP주소를 출력해주는 웹 서버 주소이다.
아웃바운드 규칙에 HTTP 규칙을 생성한 뒤 다시 시도해보자.
이전과 달리 통신이 되는 것을 확인할 수 있다.
방금 한 동작을 Stateful 하다는 관점에서 살펴보자.
- EC2에서 외부의 웹 서버로 HTTP 접근을 시도하면 보안 그룹의 아웃바운드 규칙을 확인하고, 규칙에 매칭되는 대상이므로 접근이 허용된다.
- 외부 웹 서버는 EC2로 응답을 주는데, 보안 그룹은 Stateful 동작을 하므로 인바운드 규칙을 무시하고 전달한다.
다음으로 VPC 플로우 로그를 생성해 보안 그룹에 의해 허용되거나 거부된 로그 정보들을 확인해보자.
생성을 완료하고, 대상을 선택해 CloudWatch 서비스로 넘어가 생성된 로그 정보를 확인할 수 있다.
사용자 PC에서 Server-EC2로 HTTP 접근을 시도해보자. 현재 인바운드 규칙에는 SSH 규칙만 있을 뿐 HTTP 규칙이 없으므로 보안 그룹에 의해 접속은 불가능할 것이다.
Server-EC2에 대한 ENI ID를 확인한 후 CloudWatch 서비스의 로그 스트림을 확인해보자.
일치되는 로그스트림이 나왔다.
이제 로그 스트림으로 접속해, 내 사용자 PC의 IP를 확인해 필터를 통한 검색을 해보자.
접속 거부가 된 것을 확인할 수 있다.
다음으로 네트워크 ACL을 통한 접근 제어를 해보자.
실습에 앞서 보안 그룹의 인바운드 규칙과 아웃바운드 규칙 모두 모든 트래픽을 허용하도록 변경하겠다.
그리고 신규 네트워크 ACL을 생성해 My-VPC와 연결하고 실습을 진행해보자.
VPC에 연결은 했지만, 서브넷 연결이 없는 상태이므로 퍼블릭 서브넷을 추가한다.
이후 인바운드 규칙과 아웃바운드 규칙을 보면
모두 위와 같이 기본값만 적용되어있는 상태이다.
본 실습에서는 사용자 PC에서 내부 인스턴스로 SSH 접속을 수행할 것이므로 인바운드 규칙에 SSH 접근을 허용하는 규칙을 추가한다.
추가 완료했다. 이후 사용자 PC에서 SSH 접속을 시도해보면 접속되지 않는다.
왜일까?
새로 생성한 인바운드 규칙에 의해 접근이 허용되고 서버에 도달할 수 있었지만, 네트워크 ACL은 Stateless 동작을 하기 때문에 아웃바운드 규칙도 확인한다. 기본값에 의해 거부 규칙에 매칭되므로 해당 트래픽은 차단된다.
* 참고사항으로 네트워크 ACL의 인바운드 규칙을 확인 한 후 보안 그룹 인바운드 규칙도 확인하고, 보안 그룹 아웃바운드 규칙을 확인 한 뒤 네트워크 ACL의 아웃바운드 규칙을 확인하는 절차를 따른다.
* 사용자가 전달하는 타깃인 목적지 포트는 SSH 접근을 하기 위해 22번을 사용한다. 출발지 포트는 임시 포트를 사용하고, 사용자의 OS 별로 사용하는 임시 포트의 범위가 다르며 그 중 랜덤하게 사용한다. 결국 아웃바운드 규칙을 설정 할 때 허용할 포트 번호 대상은 사용자의 출발지 포트 범위인 임시 포트 구간이 지정되어야 한다.
이제 아웃바운드 규칙을 생성해보자.
최종 동작을 확인해보면 아래의 그림과 같다.
* 참고사항으로 일반적인 접근 제어 보안은 보안 그룹을 통하여 대부분 필터링 하지만, IP 대역 레벨에서 차단이 필요할 경우 네트워크 ACL을 사용한다. 네트워크 ACL은 Stateless 이기 떄문에 인바운드 규칙과 아웃바운드 규칙 설정에 민감하여 잘 안 쓰는 편이다.
출처 : 따라하며 배우는 AWS 네트워크 입문
'AWS > 실습' 카테고리의 다른 글
| AWS WAF를 통한 웹 애플리케이션 보안 (0) | 2023.01.18 |
|---|---|
| AWS와 온프레미스 간 DNS 질의/응답 (2) | 2023.01.16 |
| AWS와 온프레미스 간 VPN 통신(S2S) (0) | 2023.01.11 |
| 서로 다른 두 VPC간 피어링 연결 (0) | 2022.11.13 |
| 글로벌 네트워크를 활용한 Global Accelerator (0) | 2022.11.13 |