* 콜아웃 내부의 요소는 네트워크 측면에서의 이해를 위해 작성한 예시입니다.
VPC
AWS에서 인프라를 구축할 때 필수적으로 생성해야 하는 네트워크 영역을 의미한다.
AWS 리소스를 구동할 수 있는 클라우드 상의 논리적인 격리 공간을 의미하며, 계정 당 각 리전에 5개씩 생성할 수 있다.
CIDR 블록 생성 시 추후 생성할 서브넷 영역까지 고려해서 지정해주는 것이 좋다.
my-vpc
IPv4 CIDR Block: 192.168.0.0/16
- 사설망 범위를 192.168.xxx.xxx로 지정한다.
Subnet
이 VPC를 한 번 더 논리적인 영역으로 분리해주는 역할을 한다. 주로 public 영역과 private 영역을 구분하기 위해 분리한다.
이로 인해 외부(인터넷)에서 접근할 수 있는 인프라 서비스들과 내부에서 내 서비스 간의 접근만 필요한 서비스들을 구분해 위치시킬 수 있으며 보안성을 챙길 수 있다.
my-public-subnet
IPv4 CIDR Block: 192.168.1.0/24
- 퍼블릭 서브넷의 영역을 192.168.1.xxx로 지정한다.
- 이 블록 영역은 VPC의 영역 안에 있어야 한다.
my-private-subnet
IPv4 CIDR Block: 192.168.2.0/24
- 프라이빗 서브넷의 영역을 192.168.2.xxx로 지정한다.
- 이 블록 영역은 VPC의 영역 안에 있어야 한다.
서브넷을 두 개로 나누었다고 해도 설정을 따로 해주지 않으면 어떤 클라우드 인프라는 어떤 서브넷이 퍼블릭이고 프라이빗인지 알 수 없다. 따라서 이를 지정해주는 설정 작업이 필요하다. 설정 작업 이전에 VPC에서 보안을 위한 몇 가지 수단을 알아보고자 한다.
Internet Gateway ( IG, IGW )
VPC는 독립된 가상 사설 망이기 때문에 일반적인 방법으로는 인터넷을 통해 외부와 통신할 수 없다. 하지만 배포와 서비스를 위해 통신이 필요하며, 이 통신을 가능하게 해주는 통로가 인터넷 게이트웨이이다.
내 VPC 내부의 서비스들이 인터넷을 통해 외부와 통신하기 위해선 인터넷 게이트웨이를 먼저 만들어 준 다음 VPC에 연결해주어야 한다. 이 때, 인터넷으로 통신을 하고자 하는 서비스만 연결해주면 된다.
my-ig
NAT Gateway ( Network Address Translation Gateway )
VPC에 있는 서비스들이 다른 서비스로 통신을 하고자 할 때 IP 주소를 사설 IP 주소에서 서로 이해할 수 있는 IP로 변환해주는 통로이다. 외부에서 들어오는 트래픽과 내부에서 나가는 트래픽을 정해진 규칙에 따라 조절한다.
Network ACL ( Network Access Control List )
VPC 내부 서비스들의 보안을 위한 방화벽이다. 서브넷의 경계에 위치하며 상태를 저장하지 않는 상태 비저장 방화벽이다.
VPC에 대한 인바운드 및 아웃바운드 규칙을 지정할 수 있다. 따로 설정하지 않으면 모든 접근에 대해 기본적으로 허용한다.
보안 그룹
인스턴스 레벨에서 작동하는 방화벽이다. NACL과 달리 상태를 저장하는 상태 저장 방화벽이다. 하위에 포함된 인스턴스에 대한 인바운드 - 아웃바운드 규칙을 정의할 수 있다. 생성은 EC2와 VPC에서 모두 생성할 수 있으나 VPC에서 생성하면 해당 VPC에 포함된 하위 서비스들과의 연결도 적용할 수 있고 하위 서비스들이 이 보안 그룹을 사용할 수 있기 때문에 주로 VPC에서 보안 그룹을 생성해서 인스턴스들이 그 보안 그룹을 사용하는 방법으로 이루어진다. 인바운드 규칙을 통해 해당 인스턴스로 들어오는 트래픽을 필터링할 수 있으며 아웃바운드 규칙을 통해 해당 인스턴스에서 내보는 목적지 주소 규칙을 지정할 수 있다.
인바운드 규칙에서 들어오는 source를 꼭 IP로만 특정하지 않아도 된다. 아래 예시 처럼 특정 서비스를 지정할 수도 있다.
my-web-sg
Inbound TCP/IP 80, 0.0.0.0/0
Inbound TCP/IP 22, 0.0.0.0/0
Inbound ICMP, 0.0.0.0/0
my-db-sg
Inbound TCP/IP 22, my-bastion-sg
Inbound TCP/IP 3306, my-web-sg
Inbound ICMP, my-web-sg
Inbound ICMP, my-bastion-sg
my-bastion-sg
Inbound TCP/IP 22, 0.0.0.0/0
Inbound ICMP, 0.0.0.0/0
my-web-sg는 외부에서 들어오는 80번 포트와 22번 포트에 대한 접근을 모두 허용한다. ICMP는 Ping을 위한 프로토콜이다.
즉, my-web-sg 보안그룹에 속한 인스턴스에는 SSH를 통한 접근과 HTTP를 통한 접근이 모두 허용된다.
my-bastion-sg도 마찬가지로 외부에서 들어오는 22번 포트에 대한 접근을 모두 허용한다. 하지만 my-web-sg와는 달리 80번 포트로 들어오는 접근은 일절 허용하지 않는다.
my-db-sg는 my-bastion-sg 그룹에 속한 인스턴스로 부터 22번 포트로 들어오는 접근은 허용한다. 또한, my-web-sg 그룹에 속한 인스턴스로 부터 3306 포트로 들어오는 접근도 허용한다. 하지만 my-web-sg 그룹에서 ssh를 통한 접근은 허용되지 않으며 반대로 my-bastion-sg에서 80번 포트를 통한 접근도 허용되지 않는다.
이 예시를 보았을 때, nginx 서버는 my-web-sg라는 보안 그룹에 속하고 bastion 서버는 my-bastion-sg라는 그룹에 속하며 MySQL 서버는 my-db-sg라는 그룹에 속할 것이다. 그렇게 되면 서로 필요한 포트와 접근만 허용된 이상적인 그림이 완성된다.
EC2를 만들어서 적절한 서브넷에 위치시키고 이에 맞는 적합한 작업을 진행한 뒤 로컬( MobaXterm, Putty, 크롬 등 )에서 접근하는 과정과 설정도 다음 글에서 진행해보고자 한다.