보안정보

전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.

AWS(Amazon Web Services)와 관제방안

2016.08.02

14,667

보안관제사업부 보안분석팀 김지우

 


1. 개요

 

Amazon Web Services(이하 AWS)는 클라우드 컴퓨팅을 위한 원격 컴퓨팅 서비스의 모음으로 Amazone.com이 제공한다. AWS의 핵심은 잘 알려진 EC2와 S3이다. AWS는 물리적인 컴퓨터시스템과 네트워크 시스템과 같인 인프라를 "가상화"해서 제공하는데 유저는 이들 인프라를 마치 원격에 있는 소프트웨어를 제어하듯이, 자유롭게 만들고, 실행하고, 늘리고, 삭제할 수 있다.

 


2. AWS 보안기능


1) WAF(Web Application Filewall)


AWS에선 보안과 관련하여 총 7개의 기본 서비스를 제공한다. 이 가운데 침입방어와 직접적인 관련이 있는 기능은 “WAF”로 사용자가 직접 패턴을 설정하고 방어하는 서비스를 제공한다.

  

 번호

 서비스

설명 

 1

 IAM

 사용자 액세스 및 암호화 키관리

 2

 Certificate Manager

 SSL/TLS 인증서 생성과 관리

 3

 CloudHSM

 규제준수를 위한 하드웨어 기반 키 스토리지

 4

 Inspector

 어플리케이션 보안 분석 (개발보안관련)

 5

 Directory Service

 디렉토리 호스팅 및 관리

 6

 KMS

 암호화 키의 제어 및 생성관리

 7

 WAF

 악성 웹 트래픽 필터링

 


[표 4-1] AWS 보안관련 서비스


WAF는 CloudFront 앞 단에서 HTTP, HTTPS 요청을 필터링하는데 CloudFront Distribution에 하나의 Web ACL을 적용할 수 있다. 하나의 Web ACL은 하나 이상의 Rule을 포함시킬 수 있으며 또 하나의 Rule에는 여러 Condition을 적용할 수 있다. 현재 적용 가능한 Condition은 다음과 같다.

 

- Cross-site Scripting Match Conditions
- String Match Conditions
- Size Constraint Conditions
- SQL Injection Match Conditions
 -String Match Conditions​

 

위와 같은 Condition을 이용해 IP를 차단하거나 SQL 인젝션 공격과 같은 웹 공격을 방어할 수 있다.

 



[그림 1] AWS WAF 구성도


■ WAF의 사용 방법 

 

먼저 Web ACL에 하나 이상의 Rule을 등록한다. (Rule 등록방법은 생략)

 

 

 

[그림 2] WebACL에 Rule 등록


다음으로 CloudFront Distribution에 Web ACL을 등록하면 룰 적용이 끝난다.

 



[그림 3] CloudFront Distribution에 WebACL 등록


이 상태에서 SQL 공격 시도했을 때 403 에러메시지가 발생하며 공격을 방어함을 볼 수 있다.

 

.

 

[그림 4] SQL 인젝션 방어 확인

 

2) VPC 보안 (Security Group와 Network ACL)

 

VPC(Virtual Private Cloud)는 public cloud상에서 별도의 private한 Network를 구성할 수 있는 기능으로, rfc1918에서 정의한 Private subnet을 설정하여 독립된 네트워크 인프라를 쉽게 구축할 수 있어 보안 향상 및 용이한 운영이 가능하다. VPC는 서브넷을 통해 Public network와 private network를 분리할 수 있기는 하지만 일반적인 DMZ trust zone 설정과는 다르다. 일반적으로 DMZ를 구성하려면 두 개의 네트워크 사이에 트래픽을 필터링하기 위한 방화벽이 있어야 하지만 VPC에서 제공하는 라우터는 subnet 구성이 가능하게 해줄 뿐 방화벽을 제공하지는 않는다.

 



[그림 5] AWS VPC 구성도


때문에 VPC는 gateway가 필요하다. 이 gateway를 IGW(Internet gateway)라고 한다. Public subnet과 Private subnet의 유일한 차이는 IGW로 라우팅이 가능한지 여부다. 단지 IGW를 라우팅 테이블에 넣고 빼는 정도로 Public subnet과 Private subnet으로 전환할 수 있다.

 



[그림 6] IGW를 이용한 Public과 Private 네트워크 분리


Private subnet을 따로 구성하는 이유는 외부로 부터의 직접적인 접근을 막기 위해서다. Web server, WAS, Database로 구성된 인터넷 서비스를 만든다면, 인스턴스들을 Private subnet에 구성해서 트래픽을 분리할 수 있다. 그리고 이들 사이에 security group이나 subnet acl을 적용하면 DMZ을 구성할 수 있다.

 

Security group는 인스턴스에 방화벽을 제공하며 방화벽 정책은 하나 이상의 인스턴스 또는 그룹단위로 적용할 수 있다. EC2와 VPC는 Inbound와 Outbound 모두에 대한 방화벽 설정이 가능하며 방화벽 정책을 만들기 위해서 제어할 수 있는 요소들은 다음과 같다.

 

- 프로토콜 : TCP, UDP, ICMP
- TCP, UDP의 경우 허용할 포트의 범위
- ICMP의 경우 ICMP 타입과 코드


Subnet은 network access control list(ACL)을 관리할 수 있다. IP와 Port 기반으로 트래픽을 제어한다는 점에서 Security group과 작동방식은 같다고 할 수 있지만, 작동범위와 영역에 있어서 다음과 같은 차이점이 있다.

즉, Network ACL은 전선을 방어하는 1차 방어선, Security Group는 각 분대를 방어하는 2차 방어선 정도로 생각하면 된다.

 

 Security Group

 Network ACL

 인스턴스 레벨로 첫 단계 방어

 Subnet 레벨로 두 번째 단계 방어

 Allow 룰만 지원

 Deny룰도 지원

 Stateful: 허용하는 트래픽에 대해서는 리턴트래픽을 자동으로 허용한다.

 stateless: 응답 트래픽도 따로 허용 정책을 세워야 한다.

 인스턴스에 대해서 SG를 설정해야지만 적용

 따로 설정을 하지 않더라도 subnet에 포함된 인스턴스는 Network ACL의 제어를 받음

 

 

즉, Network ACL은 전선을 방어하는 1차 방어선, Security Group는 각 분대를 방어하는 2차 방어선 정도로 생각하면 된다. 


3. AWS를 통한 보안관제 방안


AWS에서 자체적으로 제공하는 서비스들은 보안적인 측면을 고려하여 서비스 운용이 가능하도록 하고 있으나 이를 통해 보안관제 업무를 수행하기는 제한적이라고 말할 수 있다. 예를 들어 WAF 기능만 하더라도 XSS, SQL Injection 외에는 사용자 본인이 악성 IP를 등록하거나 사용자 정의 패턴을 통해 방어해야 하기 때문이다. 물론 지금 현재에도 AWS의 기능은 계속 개발되고 있고 API를 통해서 사용자 본인의 커스텀 역량에 따라 보안의 질도 올라갈 수 있다.

 

AWS는 어플리케이션 개발단계에서 보안 검토성을 통해 취약점을 제거하고 네트워크적으론 과도한 트래픽이 발생하거나 CPU 부하가 발생하면 그 로그를 남기지만 이 로그는 Auto-Scaling을 제공하려는 목적으로 수집하는 정보가 대부분이다. 즉, AWS는 서비스 안정성을 목적으로 운영을 하고 있고 실제 보안과 관련된 기능은 사용자 본인이 방어하거나 파트너 사에서 개발한 서비스를 통해 보완하는 방식을 택하고 있다고 볼 수 있다.

 

 그렇다면 생각해 볼 수 있는 관제방안은 다음의 4가지 정도로 판단된다.

 

(1) EC2에서 동작하는 어플리케이션에서 자체적으로 남기는 로그 수집을 통한 모니터링
(2) 호스트 레벨의 보안제품(오픈소스)을 통한 시스템 감시 및 로그 모니터링
(3) VPC와 ELB 기능을 활용해 패킷 포워딩을 통한 네트워크 패킷 감시 및 로그 모니터링
(4) 파트너 사의 클라우드 기반의 보안솔루션 사용을 통해 로그 수집

 

(1), (2), (3)의 방안은 아직 테스트 해보진 않았으나 오프라인과 비슷한 방식으로 구축한다면 어렵지 않게 구현이 가능할 것으로 보인다. 다만 (4)의 방안은 현재 AWS에서 파트너 사로 등록된 업체의 서비스를 다 운용해보고 사용방법과 로그 특성을 조사해봐야 하기 때문에 시간소요가 크고 자사 제품이 아니라 서비스 이용비용도 발생한다는 문제가 있을 것으로 보인다.

 

 

4. AWS 아키텍쳐 구조 : 대표적인 것만 정리

 

 Layer 1

 Region(리전)

- 전 세계를 대상으로 클라우드 서비스를 제공하는 글로벌 서비스로 원할한 서비스 제공을 위해서 주요 지역별로 물리적인 데이터 센터

 Avaliability zone(가용영역)

- Region을 구성하는 물리적인 네트워크 단위
- 유저는 인스턴스를 AVzone에 분산해서 배치하는 것으로 가용성(avaliability)를 높임

 Edge Location

- CDN(content delivery network) 서비스인 CloudFront를 위한 캐시서버
- 콘텐츠(HTML, 이미지, 동영상 등)를 사용자들이 빠르게 받을 수 있도록 전 세계 곳곳의 캐시서버에 복제

 

 

 Layer 2

 EC2

- Xen 기반으로 Computing resource(CPU, Memory, Disk)를 할당하여 가상머신(VM)을 제공
- CloudWatch와 ELB를 이용하여, VM을 자동으로 scale-out & scale-in할 수 있는 Auto-scaling 기능​

 S3

- 오브젝트 스토리지, Data를 Object 단위로 저장하여 EC2 및 외부에서 RESTful API를 통해 Access할 수 있음
- CloudFront를 이용하여 S3의 데이터를 CDN 서비스 이용 가능

 EBS

 (Elastic Block Storage)

- EC2 Instance에 볼륨을 제공
- EC2 생성 때 OS 부팅 영역으로 만들어지는 ephemeral volume과 달리 인스턴스 종류 후에도 사용 가능

 VPC

- 가상 네트워크를 만들어 다양한 네트워크 토폴로지를 구성
- 지역별로 AWS 계정당 최대 5개의 Amazon VPC를 생성할 수 있음 (aws 티켓을 발급하여 늘릴 수 있음)

 ELB

- 로드밸런싱 서비스 (Auto-scaling + CloudWatch + LB 기술 셋의 조합)
- CloudWaatch + ELB를 조합하여 AutoScaling 기능 구현

 Route 53

- DNS 서비스

 

 

 Layer 3

 Parallel processing

 Workforce

-

 messaging

-

 

 

 Layer 4

 IAM

- Identity and Access Management)
- 사용자의 AWS 서비스와 리소스에 대한 접근과 권한을 제어하는 서비스

 Monitoring

- AWS에서 제공하는 모니터링은 모니터링 자체 보다는 오토스케일링을 지원이 목적
- CPU, Memory, Disk I/O, Network Traffic, SQS 요청 수 등을 모니터링 하면서 조건을 만족하면 자동으로 scale-out, scale-in을 수행
- CPU, Memory, Disk I/O, Network Traffic, SQS 요청 수 등을 모니터링 하면서 조건을 만족하면 자동으로 scale-out, scale-in을 수행​

 

5. 참고자료


[1] Amazon Web Services Korea
http://www.slideshare.net/awskorea

[2] Qiita
http://qiita.com/tags/AWS

[3] Amazon Web Services 한국 블로그
https://aws.amazon.com/ko/blogs/korea/