Cloud Computing On Demand

두 번의 포스팅을 통해 VPC 와 Gateway 를 생성했습니다. 그럼 EC2 를 바로 만들면 되나요? 라고 생각하실 수 있겠습니다만 일단은 생성한 VPC 가 Gateway 를 통해 인터넷과 교감을 할 수 있도록 라우팅 테이블 Routing Table 을 설정하는 작업을 먼저 진행해 보겠습니다. 사실 순서는 큰 상관이 없지만 <네트워크에 대한 작업> 을 마무리하고 <서버에 대한 작업>을 한다고 생각하시면 좋겠습니다. 

 

AWS EC2 를 이용한 IPv6 지원 OpenVPN 구축 #1

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격

ondemand.tistory.com

 

AWS EC2 를 이용한 IPv6 지원 OpenVPN 구축 #2

9월에 첫 포스팅을 올리고 시간이 너무 많이 흘렀습니다. 기억이 더 가물가물 해지기 전에 OpenVPN 구축 포스팅을 마무리 해볼까 합니다. 지난 포스팅에서 우리는 `IPv6 대역을 갖고 있는 VPC 생성`

ondemand.tistory.com

AWS 환경 준비 IPv6 대역을 갖고 있는 신규 VPC 생성 ("OpenVPN 구축 #1" 포스팅) VPC 내에 Public Subnet 생성 ("OpenVPN 구축 #1" 포스팅) Gateway 구성 : Internet Gateway / Egress Only Internet Gateway ("OpenVPN 구축 #2" 포스팅) Routing Table 조정 (본 포스팅!) IPv6 주소를 갖는 EC2 배포 (본 포스팅!) OpenVPN 설치 및 구성 VPN 접속 시험 기타 라우팅 조정

---

1.4 Routing Table 조정

라우팅 테이블 Routing Table 은 VPC 로 들어오는 트래픽과 나가는 트래픽에 대한 경로를 지정해 주는 역할을 합니다. 물론 라우팅 테이블만 설정했다고 하여 모든 통신이 정상적으로 이루어지는 것은 아닙니다. 말 그대로 경로에 대한 지정일 뿐, 실제 트래픽을 허용할 것인지는 Network ACL 과 Security Group 을 통해 IP 주소 대역, 포트 단위로 결정됩니다.

라우팅 테이블을 설정하기 위해서는 VPC 제품 하위 메뉴에 위치한 <Route Tables> 를 통해 진행할 수 있습니다. 기본적으로 VPC 가 생성되면 VPC 에 대한 기본 라우팅 테이블이 자동으로 생성됩니다. 기본 라우팅 테이블은 VPC 에 할당된 IPv4, IPv6 주소를 대상으로 VPC 내에서 (=local) 통신이 가능하도록 하는 정책만 들어 있는 상태입니다.

우리가 해야하는 일은 위 이미지의 핑크색 상자에 들어 있는 내용과 같이 외부로 부터의 트래픽 송수신을 위한 정책을 추가하는 것입니다. IGW (Internet Gateway) 로는 SSH 접근을 위해 IPv4 에 대한 정책을 추가했고, EIGW (Egress Only Internet Gateway) 에는 실제 v6 주소 목적지에 대한 VPN 터널링을 위해 IPv6 주소에 대한 정책을 추가했습니다.

정책 추가를 위해 라우팅 테이블 목록에서 IPv6 용으로 만든 VPC 에 할당된 기본 라우팅 테이블을 선택합니다. Actions 버튼을 누르지 않아도 화면 아랫쪽에서 <Routes> 탭을 선택하면 라우팅 테이블에 대한 상세 정책 목록이 출력됩니다. 정책 추가를 위해 <Edit routes> 버튼을 누르겠습니다. 

IPv4 의 모든 주소를 나타내는 CIDR block 은 0.0.0.0/0 으로 표기되며, IPv6 의 모든 주소를 나타내는 CIDR block 은 ::/0 으로 표기합니다. 목적지 주소에 v4, v6 에 대한 CIDR block 을 추가하고 v4 는 IGW 로, v6 는 EIGW 를 이용하도록 대상(Target) 제품을 지정해 줍니다. 이미 생성한 IGW 와 EIGW 가 드롭 다운 목록에 노출되기 때문에 설정은 쉽게 하실 수 있습니다. 경로 입력이 끝나면 우측 하단의 <Save Routes> 버튼을 누릅니다. 

 

1.5 IPv6 주소를 갖는 EC2 인스턴스 배포

네트워크의 구성이 끝났으니 이제 실제 OpenVPN 바이너리가 구동되고 목적이 v6 주소까지 터널링을 해줄 EC2 인스턴스를 생성해 보도록 하겠습니다. 사용자가 얼마나 많은지, 트래픽 규모가 어떠한지에 따라 인스턴스 타입이 결정되어야 하겠지만, 이 포스팅에서는 AWS 무료 티어에서도 사용할 수 있는 t2.micro 타입의 인스턴스를 사용하도록 하겠습니다. 소규모의 사용량이라면 이 인스턴스로도 큰 문제가 없습니다. 

EC2 인스턴스의 생성은 많이들 해보셨을 작업이기 때문에 주의할 점을 중심으로 설명드리겠습니다. EC2 생성 마법사의 세번째 단계에는 IP 주소 할당에 대한 정책을 선택하도록 되어 있습니다. 우리가 진행하는 OpenVPN 은 단일 인스턴스 환경이기 때문에, 해당 서버가 사용자들로부터 IPv4 를 통해 VPN 연결을 시도할 수 있어야 하고, IPv6 주소를 보유하여 v6 주소를 갖고 있는 목적지 서버와 연결할 수 있어야 합니다. 

 

이 목적을 달성하기 위해서는 <3. Configure Instance> 단계에서 하단에 있는 <Auto-assign Public IP> 와 <Auto-assign IPv6 IP> 를 Enable 로 선택하여 v4 와 v6 를 통해 공인 IP 를 사용할 수 있도록 해야 합니다. 그런데 IPv6 는 왜 <Public> 이라는 말이 없을까요? 기본적으로 IPv6 주소 체계는 Private / Public 를 가지고 있지 않습니다. 따라서 옵션의 이름도 단순히 <Auto-assign IPv6 IP> 라고 되어 있다는 점 참고하시기 바랍니다!

EC2 생성 마법사를 완료하고 인스턴스 생성을 기다립니다. 생성이 완료되면 위와 같은 화면을 볼 수 있게 됩니다. 다른 기본적인 사항은 특별히 확인할 내용이 없고, 네트워킹 Networking 탭을 중심으로 살펴보면 됩니다. 설명했던 것처럼 v4 는 Private, Public 의 주소가 할당되지만 v6 는 하나의 주소만 할당된 것이 보입니다. 이제 인프라의 준비가 끝났습니다. 

---

 

다음 포스팅에서는 OpenVPN 을 인스턴스에 설치하는 작업을 해보도록 하겠습니다. 

클라우드는 그 개념이 등장한지 꽤 오랜 시간이 지났지만 여전히 명쾌한 정의를 내릴 수 있는 사람이 드물다. 그나마 가장 합리적인 정의를 내려보자면 하드웨어, 소프트웨어, 네트워크를 추상화하여(가상화) 다수의 사용자가 함께 사용할 수 있는(멀티 테넌시) 유연한 플랫폼을 일컫는 정도가 될 것 같습니다.

아마존 웹 서비스(AWS)를 비롯하여 우리나라의 SK텔레콤 T cloud biz, KT 의 uCloud 등을 통해 특정 데이터센터 기반의 서비스 인프라에 대한 클라우드 서비스는 많이 대중화가 되었습니다. 그런데 이런 인프라의 가상화가 커버하기 힘든 영역이 있으니 그것은 바로 네트워크 영역입니다. 클라우드 서비스를 사용하거나 제공하는 사람들의 공통적인 고민은 늘 네트워크로 귀결됩니다

 
네트워크는 데이터센터 내부 뿐만이 아니라 공용 인터넷 망에 대한 고민을 함께 해야 하기 때문에 어렵습니다. 아마존, SK텔레콤, KT와 같은 클라우드 사업자들이 유연한 듯 하면서도 결국 Region 이나 서비스 존에 대한 제약이 발생하는 이유는 바로 네트워크 때문이기도 합니다. 클라우드 자원과 네트워크의 이슈는 다른 포스팅에서 한번 이야기 하기로 하구요, 오늘은 보안 관점에서 클라우드 기반 보안 서비스를 이야기 해보고자 합니다.

많은 하드웨어 기반 네트워크 보안 장비를 개발하는 회사들은 최근 클라우드 기반의 서비스를 많이 출시하고 있습니다. 설치된 하드웨어를 정기적인 펌웨어 업데이트로 성능을 개선하고 업데이트 하는 것이 아니라 실시간으로 하드웨어들이 찾아내는 새로운 위험 요소들을 중앙의 분석 서버로 보내어 이슈를 확인하고 문제의 심각도에 따라 해당 하드웨어 벤더의 제품을 사용하는 전세계 유저들에게 바로 배포하는 등의 일이 바로 그것입니다. 

보안 장비 벤더들의 초기 움직임은 자사의 장비를 이용하는 고객들만을 대상으로 서비스를 제공하는 수준이었지만 최근 DDoS 방어 전문 기업인 아르보(Arbor)는 유관 업계들과 함께 클라우드 시그널링 연합(CSC)이라는 것을 구축하고 회원사의 장비를 이용하는 고객사들을 지역 단위의 네트워크로 묶어 효과적으로 DDoS 공격을 방어하고 악의적인 트레픽을 차단하는 솔루션을 내놓았습니다.
 

아르보가 이와 같은 접근 방식을 선택한 것은 DDoS 를 비롯하여 현대의 악의적인 공격들은 공격의 시작점부터 접근 루트 등을 명확하게 한정짓는 것이 힘들기 때문입니다. 공격은 악성 코드에 감염된 수십대에서 수천대, 수만대에 이르는 사용자 단말(PC, 스마트폰 등)에서 시작되고 이들이 서버를 공격하는 루트는 다양할 수 밖에 없습니다. 이런 공격을 서버 바로 앞단에서 하드웨어 장비로 막는 것은 한계가 있습니다. 하드웨어 장비들은 소화할 수 있는 트레픽의 총량이 정해져있고, 이 한계를 넘어 장비가 폭주하는 수준에 이르면 네트워크 전체의 다운을 막기 위해 바이패스(By-Pass)하는 것이 일반적입니다.

이런 현상을 막기 위해서는 공격이 시작되는 지점을 찾아서 서버 근처로 접근하지 못하도록 하는 것이 중요합니다. 이를 위해서는 전세계에 퍼져있는 공격 차단점을 확보하는 것이 중요하며 아르보는 자사와 경쟁 보안 업체들이 가지고 있는 장비를 이용하여 글로벌 풋 프린트(Foot Print)를 확보하는 방법으로 접근을 하고 있습니다. 이런 형태의 클라우드 기반 보안을 가장 진일보시켜 서비스하고 있는 곳은 사실 아카마이입니다.

 
1990년대 후반부터 아카마이가 집중해왔던 사업은 CDN(Content Delivery Network)입니다. 엔드유저에게 보다 가까운 위치에 캐시서버를 배치하여 원본 서버가 가지고 있는 컨텐츠를 보다 빠르게 전달하는 것이 CDN 의 기본 원리입니다. 사용자의 대규모 트레픽을 수용하고 서비스 하기 위해서는 전세계에 가능한 많은 서버를 배치해야 하는데, 아카마이는 CDN 을 위해 전세계에 14만대에 이르는 서버를 배치하고 서비스를 제공하고 있습니다.

아카마이가 최근 강하게 시장에 어필하고 있는 보안 상품인 코나 사이트 디펜더(KSD, Kona Site Defender)는 바로 이런 글로벌 풋 프린트를 이용한 보안 서비스입니다. 아르보와 같은 하드웨어 기반 기업들은 악성 트레픽 차단 지점을 늘리기 위해 제조사들과 연합했다면 아카마이는 단일 플랫폼 위에서 서비스를 제공하기 때문에 사용자 관점에서 더 나은 경험을 제공할 수 있다는 장점이 있습니다.

악의적인 공격을 막는 방법은 정말 다양합니다. 아르보의 CSC나 아카마이 코나 사이트 디펜더는 기본적으로 넓은 커버리지를 이용하여 악성 트레픽의 인입 자체를 막겠다는 컨셉입니다. CSC의 경우 기술적인 스펙을 조금 더 확인해봐야 겠지만, 아카마이의 경우 악성 공격으로 인해 접점의 서버가 다운되더라도 해당 지역에서 동일한 역할을 수행하는 서버가 트레픽을 분산 처리할 수 있기 때문에 가용성이 상당히 높은 것이 장점입니다
 

DDoS 와 같은 대규모 공격을 막는 또다른 방법 중 하나는 악성 트레픽 발생시 이를 처리하는 전담 서버쪽으로 데이터의 흐름을 변경한 뒤 정상적인 트레픽을 필터링해 서버로 전달하는 방법입니다. 이같은 방식의 서비스를 스크러빙(Scrubbing) 서비스라고 하고 시장에서 가장 큰 규모의 마켓을 쥐고 있는 업체가 바로 PROLEXIC 입니다. 아카마이는 최근 PROLEXIC 에 대한 인수를 발표하며 기존 코나 사이트 디펜더에 더하여 클라우드 기반 보안 시장을 수성하겠다는 의지를 표명한바 있습니다.

방화벽이나 DDoS 하드웨어를 이용한 인프라의 보호는 보안의 시작입니다. 하지만 이것 만으로는 소화할 수 없는 이슈들이 많이 있습니다. 아카마이, 아르보는 악성 공격을 근원적으로 차단하는 방법에 대한 가이드를 기업들에게 던지고 있습니다. 제대로 된 악성 공격 방어를 고민하고 있다면 이런 기업들이 제공하는 서비스의 개념을 잘 이해하는 것이 중요할 것 같습니다.

 
- NoPD -