아마존 서버 네트워크 망분리 구축하기 (VPC, DMZ)

HYEONG HWAN, MUN/ 10월 24, 2019/ 미분류/ 5 comments

https://blog.lael.be/post/9534

SA(솔루션 아키텍트)의 범위중 하나인 네트워크 망 설계에 대해 알아보도록 하자.

대기업의 보안 기준을 지키기 위하거나, ISMS 인증 등을 받기 위해 반드시 해야하는 작업이다.
그리고 굳이 이런게 아니어도 설정하면 좋다.

 

1. VPC 생성

Virtual Private Cloud 라고 한다.
적절히 해석하자면, 가상IP 네트워크 라고 볼 수 있다. 기존의 VPN(Virtual Private Network)이라는 단어가 있으므로, 어쩔 수 없이 VPC라는 단어를 선택한 것 같다.
아무튼 VPC = 가상IP 네트워크 이다.

VPC 내에 있는 PC끼리는 연결되어 있으며, Private IP(VPC IP)를 통해 서로 통신할 수 있다.

 

AWS 콘솔에서 VPC 메뉴로 이동하여, VPC를 생성해 보도록 하자.

* VPC 이름 : 프로젝트 이름  (이 글에서는 lael blog system 을 사용할 것이다.)

* VPC IPv4 CIDR : 10.100.0.0/16  - 이 값을 완전히 동일하게 입력하는 것을 권장합니다.

VPC IPv4 CIDR는 어느 범위의 IP든 입력가능하지만, IETF 에서 권장하는 사설망 IP 범위로 정하는 것이 좋습니다.

 

사설망 IP 범위
  • 10.*.*.*   (10.0.0.0/8)
  • 172.16.*.* ~ 172.31.*.* (172.16.0.0/12)
  • 192.168.*.* (192.168.0.0/16)

참고로 192.168.0.0/16 대역은 시중에 판매하는 대부분의 인터넷 공유기에서 사용하는 IP 네트워크 범위이다.

 

아무튼 우리는 10.100.*.* IPv4 CIDR 범위의 VPC 를 생성할 것이다.

(VPC는 계정당 5개까지 생성할 수 있다. 하지만 고객센터에 limit increase 를 요청하여 최대 100개의 VPC 를 생성할 수 있다.)

VPC 를 생성하면 편의를 위해서 기본 라우팅 테이블이 하나 생성된다.

 

2. 서브넷 생성

VPC의 IP대역을 쪼개서 구성하는 것을 서브넷 이라고 한다. (VPC 는 그냥 Network, 이것은 SubNetwork.)

서브넷을 사용하는 이유는 그 서브넷 안의 트래픽을 제어하기 위해서이다. (쉽게 이야기 하자면, 외부망과 연결된 네트워크 그룹과, 외부망과 직접 연결하지 않는 네트워크 그룹을 만들기 위해서 서브넷을 사용한다.)
(서브넷에서 라우팅 테이블을 설정하여 트래픽을 방향을 제어할 수 있고, ACL을 설정하여 네트워크 방화벽을 구성할 수 있다.)

지금은 이해가 안되겠지만, 이 글을 다 읽고 난 후에는 이해가 될 것이다.

 

서비스넷을 생성해보자.

서브넷이름 : <프로젝트단어>-public-subnet1

IPv4 CIDR : 10.100.50.0/24

역시나 위의 예제 값 그대로 입력하는 것을 권장한다.

생성한 다음에 바로 하나 추가로 생성한다.

 

서브넷이름 : <프로젝트단어>-private-subnet1

IPv4 CIDR : 10.100.200.0/24

역시나 예제 그대로 입력하는 것을 권장한다.

 


지금까지의 작업을 통해 아래의 네트워크가 구성되었다.

하나의 VPC 안에, 다수의 Subnet 을 만들 수 있다. (VPC당 최대 200개 subnet 생성가능)

subnet이 다르더라도 같은 VPC 내에 있는 PC끼리는 통신할 수 있다. (라우팅의 기본규칙인 local routing 때문)
(특별하게 ACL차단 설정을 하지 않았다면, 기본적으로 10.100.50.31(위 그림의 왼쪽 서브넷에 위치한 서버) 서버에서 10.100.200.55(위 그림의 오른쪽 서브넷에 위치한 서버) 서버로 접속이 가능하다.)


 

3. 라우팅 테이블 생성

라우팅 테이블은 IP 범위별로 트래픽 방향을 정해주는 안내표이다.

서브넷과 연결되어 사용하는 것이기 때문에, 서브넷 이름과 동일한 이름으로 생성하자. (public-subnet1, private-subnet1)

 

4. 서브넷이 생성한 라우팅 테이블을 사용하도록 설정

[서브넷 연결 편집] 버튼을 클릭하고 [라우팅 테이블]과 [서브넷]을 연결 설정하자.

(public subnet 과 private subnet 둘 다 생성한 routing table 을 사용하도록 연결해주세요.)

이제 각 subnet의 통신은 routing table을 따릅니다.

 

5. 인터넷 게이트웨이 생성

현재 VPC 가 외부(인터넷)와 연결되어 있지 않습니다. 웹 서비스의 경우 외부 인터넷 연결이 되어야 하므로 인터넷을 연결해줍시다.

이름 : <프로젝트명>-internet-gateway

생성 후 VPC 와 연결해줍시다.

 


 

VPC 와 외부 Internet 을 연결하는 경로이기 때문에 VPC 의 경계에 그리는 것이 맞습니다.

 

6. public subnet 와 internet gateway 연결

public subnet 에서 local network(10.100.0.0/16) 이외의 IP 에 대해서 Internet gateway 로 가도록 설정합니다.

public-subnet1 이름의 서브넷의 Routing table의 Routing 규칙을 편집합니다.

Destination: 0.0.0.0/0

Target : Internet Gateway 선택

 

이제 public subnet1 에 속한 PC 는 local network IP 이외의 대상과 통신할 경우 Internet Gateway 로 트래픽을 보냅니다.

하지만 인터넷 통신은 Public IP 를 필요로 하기 때문에, public subnet1 의 PC는 public ip 를 가지고 있어야만 인터넷 통신을 할 수 있습니다.

외부와 직접 연결할 수 있는, Public IP 통신이 가능한 곳을 Public Subnet 또는 DMZ 라고 부릅니다.
비록 외부에서 연결 가능한 DMZ(public subnet)내의 PC이지만, ACL이나 Security Group 을 통해 접근제어를 설정 할 수 있습니다.

(아무튼 외부와 연결가능한 곳을, 비무장지대, DMZ 라고 부른다. 외부와 handshake를 해야하는 곳이다.)

 

7. NAT Gateway 생성

public subnet 안에 통신-게이트웨이를 하나 만들것입니다. 이것을 NAT Gateway 라고 부릅니다.

 

8. private subnet 와 NAT gateway 연결

private subnet 에서 local network 이외의 IP 에 대해서 NAT gateway 로 트래픽이 가도록 설정합니다.

private-subnet1 이름의 서브넷의 Routing Table의 Routing 규칙을 편집합니다.

 

Destination: 0.0.0.0/0

Target : NAT Gateway 선택

 

이제 private subnet1 에 속한 PC 는 로컬IP 이외의 대상과 통신할 경우 NAT Gateway 로 트래픽을 보냅니다.

private subnet1 에 속한 PC 는 NAT Gateway 를 통해 인터넷 연결을 할 수 있으며, 이 때 사용하는 IP 는 NAT Gateway 에 할당된 IP 입니다.

이해하기 쉬운, 예제를 들어보자면, 일반적으로 사용하는 IPTIME 공유기의 경우 NAT Gateway 역할을 하며, 연결된 PC는 private subnet 에 속해 있는 것 입니다.

 

private subnet 에 속한 PC는 Public IP를 할당하더라도 사용할 수 없습니다. (네트워크 구조상 사용할 수 없음)

외부에서 private subnet 에 직접접근은 불가능합니다.
이것은 Security Group 설정을 통한 접근제어와 달리, 물리적으로 접근이 불가능하기 때문에 이것을 망분리라고 합니다.

 


망 분리가 된 네트워크 구성도

private subnet 에 접근하기 위해서는, 외부와 접근 가능한 public subnet 에 서버를 하나 만들고, 그 서버에 접속하여, Tunneling, VPN, Port forwarding 기법등을 통해 private subnet 에 속한 서버에 연결하여야 합니다.

서버 접속 방법이 약간 불편해지지만, 망분리가 되었기 때문에 private subnet 의 서버 Instance 에 대한 보안이 매우 강화 됩니다.

 

 

9. Network ACL 설정하기

ACL은 “접근 제어 목록” 이라고 한다. (Access Control List)

각 서버 인스턴스에 방화벽을 설정할 수 있는게 Security Group 이라면, 각 Subnet 에 대해서 방화벽(접근제어 설정)을 하는 것이 ACL 이다.

ACL 은 서비스 구성도에서 Firewall 의 역할로 그려진다. 별도로 설정하지 않았다면, 하나의 ACL 을 여러 서브넷이 사용한다.

Network ACL = Network Firewall

Instance 나 ELB 등의 위치에서 동작하는 Security Group 보다 더 우선하여 동작한다. (인스턴스 레벨이 아니라 네트워크 레벨이기 때문.)
굳이 구분하자면, Network ACL 은 망관리자나 보안관리자의 범위이고, Security Group 은 서버관리자의 범위이다.

위의 그림을 three-legged network model 이라고도 부른다.

 

Network ACL 을 2개 생성해보자.

Public-subnet1 에서 사용할 ACL과, Private-subnet1 에서 사용할 ACL 이다.

이름 : blog-public-subnet1-acl (이 글에서는 blog-public-subnet1-acl)
이름 : blog-private-subnet1-acl (이 글에서는 blog-private-subnet1-acl)

 

생성을 마쳤으면 네트워크 ACL을 사용할 subnet 을 지정하자.
헷갈리지 않게 생성했으므로, 잘 연결 지정할 수 있을 것이라 생각한다.

기초 ACL 설정

위와 동일한 값으로, inbound, outbound 에 대해서 public, private 모두 설정하자. (그러니까 같은 작업을 4번 반복해야함)

규칙은 우선순위를 뜻하며 1이 가장 최우선이고 99999 가 가장 우선순위가 낮다.
기본 규칙으로 100 을 선택한 이유는, 적당히 앞뒤로 규칙 넣기가 좋기 때문이다.

규칙 숫자는 중복할 수 없다.

 

위의 작업까지 마무리 되었으면 현재 네트워크는 아래 그림과 같이 된 것이다.

< 이중 방화벽을 사용하는 일반적인 네트워크 다이어그램 >

그림 출처 : https://en.wikipedia.org/wiki/DMZ_(computing)

 

* 사용 목적에 맞게 ACL 설정

사용 목적에 맞게 알아서 설정하면 된다. 하지만 일반적으로 아래의 하나는 설정한다.
private 의 ssh 포트(tcp 22) 에 대해서 inbound 허용 고정.

private subnet 의 서버들은, 위에서 설계한 네트워크 구조상 public subnet 에서만 접근이 가능하고,
또한 private subnet 의 network ACL 에 의해, public subnet 의 10.100.50.31 서버에서만 private subnet 의 ssh 에 접속할 수 있다. 이렇게 되면 internet 과 맞닿아있는 public subnet 의 다른 instance 가 장악되더라도 private 영역을 보호할 수 있게 된다.

10.100.50.31가 유일한 경로가 되며, 이 서버의 접근제어만 최우선적으로 관리하면 된다. 10.100.50.31 서버를 Bastion Host 라고 부르기도 한다.

 


서버 생성 및 테스트

VPC 간, 또는 Subnet 간에 EC2 이동이 불가능하기 때문에, 서버 인스턴스를 처음 생성시 잘 선택해 주어야 합니다.

< private subnet instance >

 

< public subnet instance >

이 인스턴스를 통해서 private subnet 에 접근하여야 한다.


다중 가용 영역 (Multi availability zone) 이 필요할 경우 subnet 을 추가로 생성하여야 한다.

subnet 생성에 대해서만 availability zone 선택 옵션이 있다.
똑같이 public-subnet2 와 private-subnet2 를 생성하자.
internet gateway 나 nat gateway, routing table, access control list 등은 availability zone 과 무관하게 재사용할 수 있으니 따로 생성해 주지 않아도 된다.

MultiZone까지 작업하면 위와 같은 구성이 되는데, 이 정도 되면 대기업 납품(대기업 보안팀의 요구수준 준수)이나 글로벌 표준에 맞게 된다.

물론 위의 상태에서 Outer elb, Inner elb, 침입탐지, 감사, Cloudwatch Log, Application Firewall, Code commit 등을 더 붙일 수 있지만, 위의 정도만 구성해도 충분히 훌륭한 구성이 된다.

이러한 보안 구축에 관심이 있다면 ISMS 라는 것을 더 알아보도록 하여라.

https://isms.kisa.or.kr/main/isms/intro/index.jsp

 

이 블로그 글 작성하려고 꼼지락 거리면서 5만원 정도 쓴 것 같네요.

완성!


참고 문서

https://wiki.openstack.org/wiki/Blueprint-VPC - OpenStack VPC BluePrint

https://en.wikipedia.org/wiki/Private_network - Private Network

https://en.wikipedia.org/wiki/DMZ_(computing) - DMZ

https://aws.amazon.com/ko/architecture/icons/ - AWS Architecture Icons

5 Comments

  1. 감사합니다. 너무 자세히 알려주셔서 구성을 쉽게 했네요

    1. 안녕하세요. 세번정도 반복해보시고 개념을 정리하시면 많은 도움이 될 것입니다!

  2. NAT 사용시 요금이 부과되는데 , NAT 말고 다른 사용방법은 없을까요?

    1. ec2를 사용해서 nat을 직접 구축하면 됩니다. 이 경우 트래픽 요금은 절약되지만 관리이슈가 생겨요.
      만약 구축한다면 ec2 의 network 세팅에 source/destination check 옵션을 disable 로 설정하세요.

Leave a Comment

작성하신 댓글은 관리자의 수동 승인 후 게시됩니다.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
*
*