ㅍㅍㅋㄷ

AWS VPC를 디자인해보자(2) - ACL과 Security Group을 활용한 보안 강화 본문

IT/AWS

AWS VPC를 디자인해보자(2) - ACL과 Security Group을 활용한 보안 강화

물과같이 2016.06.13 18:15

VPC를 디자인해보자 (2) - Network ACL 과 Security Group, Flow log를 활용한 보안 강화








 VPC(Virtual Private Cloud) 서비스는 AWS 사용자가 직접 가상 네트워크 환경을 구성하는 서비스이다. 이 서비스를 이용하면 Public network 환경과 Private network 환경을 사용자가 원하는대로 디자인하고 구축할 수 있게 된다.

 또한 다양한 부가 기능을 통해 VPC 환경 내 네트워크 흐름을 제어할 수 있기 때문에 나만의 가상 데이터 센터를 구축하여 사용할 수 있게 된다.


 이번 포스팅에는 VPC의 보안 강화를 위해 Network ACL,  Security Group과 Flow log를 이용하는 방법을 알아보자.





1. Network ACL



  데이터 센터 구축시, 보안 강화를 위해 가장 많이 사용하는 방법은 Network 앞단에 방화벽 장비를 두고 데이터센터로 유입되는 트래픽을 제어하는 것이다. 방화벽 장비를 통해 패킷의 출발지 주소와 목적지 주소, Protocol 유형, 서비스 포트를 확인하여 inbound 또는 outbound 패킷을 허용하거나 차단하도록 설정한다. 혹은 Switch나 Router 장비에 ACL(Access Control List) 를 활용하여 구현하는 것도 가능하다. 하지만 이러한 방식을 구성하기 위해서는 고가의 방화벽 장비를 추가적으로 설치 하거나 Network 장비에 ACL 을 직접 설정해야 하는 부담이 있다. 




  AWS VPC를 사용하면 어떨까


  VPC 를 사용하면, 추가적인 비용 없이 Network ACL 설정을 사용자가 직접 VPC로 유입되는 트래픽을 제어할 수 있도록 제공해 준다. 기존 데이터 센터에서는 방화벽이나 Switch 마다 ACL 규칙을 설정하고 이 설정 내역을 관리 해야 했지만, VPC 에서는 AWS Console 을 통해 손쉽게 설정을 할 수 있으며 API도 제공하기 때문에 사용성이 매우 뛰어나다. 


 데이터 센터 구축시 어려운 점이었던 (1) 보안 장비 도입 비용 증가와 (2) 장비 운영 관리에 대한 부담을 해결해 주기 때문에 이를 잘 이용한다면 견고한 가상 데이터 센터를 구축할 수 있다. 

 

 ACL의 특징을 알아보면 아래와 같이 요약해 볼 수 있다. 



ACL의 특징


  • VPC의 Network ACL은 Subnet 단위로 적용 시킬 수 있다. 
  • 초기 ACL 설정은 All Deny 정책이다. 즉, 사용자가 ACL 정책을 추가해주지 않으면 해당 ACL이 적용된 Subnet 은 모든 통신이 두절된다. 
  • ACL은 여러 서브넷에 적용이 가능하다. 하지만, 서브넷은 한번에 한개의 ACL만 연결이 가능하다. 
  • ACL 규칙 목록은 번호가 낮은 것부터 우선으로 적용된다. 
  • VPC 당 최대 ACL 개수는 200개이다. 
  • ACL당 규칙 목록은 inbound 최대 20개, outbound 최대 20개까지 지정 가능하다.  
  • ACL은 stateless 이다. 


여기서 마지막 특징인 stateless 에 대해 좀 더 자세히 알아보자. 

 stateless 는 트래픽에 대한 상태를 저장하지 않는다는 의미로, 요청과 응답은 트래픽의 상태와 상관없이 각각 inbound 와 outbound 규칙을 따른다는 것이다. 즉, 허용되는 inbound 트래픽에 대한 응답의 경우에는 inbound 규칙과 상관 없이 outbound 규칙을 따르게 된다는 것이다. 

 예를 들어, ACL 의 inbound 규칙에 80 포트 접근 허가를 추가해 놓았다고 해보자.

 외부에서 HTTP 요청(80)을 하였을 경우, ACL의 inbound 규칙 80을 허용하였으므로 트래픽이 들어오게 된다. 
 하지만 해당 요청에 대한 응답의 경우는 ACL의 outbound 규칙을 따르게 된다. 

 즉, ACL의 outbound 규칙에 HTTP 요청에 대한 응답 포트를 오픈하지 않을 경우, 
 ACL에 의해 deny되며 최종적으로 client에게 요청 결과가 전송되지 않게 된다. 

 그렇기 때문에 inbound / outbound 규칙 관리의 중요성이 크다. 
 이 부분에서 한가지 신경써 줘야 할 부분이 Ephemeral Port 에 대한 허용 규칙이다. 

 Ephemeral Port 는 TCP Connection 시에 커널이 임의로 port를 binding 하는 경우가 있는데 이런 port를 Ephemeral port 라고 부른다. 
 여기서 임의로 할당되는 port 의 범위를 커널에서 관리하기 때문에 설정마다 다르다. 

 AWS에서 제공하는 Amazon Linux AMI 인 경우 Ephemeral port range 가 32768 ~ 60999 로 설정되어 있다. 
 

root@~~# cat /proc/sys/net/ipv4/ip_local_port_range 

32768 60999

따라서 Network ACL의 inbound/outbound 규칙에 해당 포트 범위에 허용 시켜주는것이 좋다. 
아래는 VPC 에서 권장되는 ACL 규칙 관련 가이드 문서이니 참고.  
 





위 그림은 ACL을 지정한 VPC 예이다. 


  • Public Subnet 2개와 Private Subnet 2개 이루어진 VPC 이다.
  • Public/Private 에 속한 subnet은 고가용성을 고려해 두개의 AZ에 분산 배치되어 있다.  
  • Public Subnet 에는 Public용 ACL 이 적용되었고, Private Subnet에는 Private용 ACL을 각각 적용하였다.



아래는 public subnet에 적용한 ACL의 inbound 규칙의 예이다. public subnet 에는 Web 서비스가 생성될 것이라고 가정해보았다. 


  • SSH 는 서버에 접속하는 경로이므로 Source IP를 반드시 개발자의 IP에 한정지어 설정하도록 한다. 
  • 80/443 은 HTTP/HTTPS 서비스를 위한 포트이므로 everywhere 오픈으로 설정하였다. 
  • Ephemeral Port를 위해 32768~60999 포트까지 오픈으로 설정하였다.
  • 나머지 모든 트래픽은 All deny 이다. 



아래는 Private ACL의 inbound 규칙이다. private subnet 에는 MySQL 서버가 배포될 것을 가정하였다.

  • Private Subnet의 경우 외부 통신이 불가하다. SSH 접속이 필요한 경우 Public Subnet에 배포된 instance를 경유해 들어오도록 가정하여, source IP 대역을 public subnet 대역인 10.10.0.0/16 대역으로 설정하였다. 
  • MySQL 서비스 포트인 3306 또한 public subnet 에서 접속할 것으로 간주하여, source IP 대역을 10.10.0.0/16 대역으로 설정하였다.
  • 나머지 모든 트래픽은 All deny 이다. 





2. Security Group



 Security Group은 인스턴스에 대한 inbound 와 outbound 트래픽을 제어하는 방화벽 역할을 한다. Network ACL 과의 차이라고 한다면, ACL의 경우 Network 레벨에서의 방화벽이라면, Security Group은 인스턴스 레벨의 방화벽이라고 생각하면 된다. 

 Security Group 의 특징을 알아보면 아래와 같다.



Security Group의 특징


  • Security Group은 instance 단위로 적용 시킬 수 있다. 
  • 동일 Subnet 내에서 통신일 경우, ACL 규칙과 상관없이 Security Group 의 규칙을 적용 받게 된다. 
  • Security Group의 규칙은 Allow 지정 방식이며, Deny 지정은 불가하다.
  • 기본적으로 Inbound 트래픽의 경우 All Deny 이다. 
  • Outbound 트래픽의 경우 기본적으로 All Allow 상태이며, All Allow 규칙은 삭제가 가능하고 원하는 Allow 규칙만 추가 가능하다.
  • Security Group은 Stateful 하기 때문에 허용된 inbound 트래픽에 대한 응답은 outbound 규칙에 관계없이 허용된다. 



Security group 은 Network ACL 과 다르게 State를 기억하기 때문에 outbound 나 Ephemeral Port 에 대한 고민을 하지 않아도 된다. 





 위 그림은 VPC에 Security Group을 추가한 예이다. Security Group은 Instance 별로 지정이 가능하다. 위 예제에서는 Public Subnet에 배포된 Instance를 위한 Security Group 과 Private 에 배포된 Instance를 위한 Security Group을 지정한 모습이다. 


 Network ACL 과 Security Group 을 함께 사용하는 경우, 오히려 트래픽 제어가 복잡해 질 수 있고, 갑자기 통신이 두절된 경우 Trouble shooting 이 복잡해 질 수 있으므로 주의하도록 해야 한다. 






3. Flow Log



  Flow log는 VPC 내 트래픽에 대한 로그 정보를 수집하는 기능이다. Flow log는 instance에게로 유입되는 트래픽을 모니터링을 할 수 있으므로 보안을 위한 추가 도구로 유용하게 사용 가능하다. 또한 Network ACL 로 인한 얘기치 않은 통신 두절 상황에서 Trouble shooting 도구로도 사용이 가능하다. 


  Flow log를 설정하면 로깅 데이터는 CloudWatch Log를 사용하여 저장하게 된다. 그렇기 때문에 AWS Console 에서 UI로 손쉽게 확인이 가능한 점도 큰 장점이다. 



 VPC 에서 Flow log 적용 방법


 VPC 에 Flow log를 설정하는 방법을 소개한다.  

 한가지 안타까운 점은 아직 서울 리전에서는 Flow log 기능을 지원하지 않는다. 

 2016. 6. 30일 부로 서울 리전에서도 Flow log 를 지원한다. 

 

 Flow log를 사용하려면 먼저 두가지를 설정해야 한다. 


  • VPC Flow log를 위한 CloudWatch의 Log group 생성
  • 생성한 Log group에 log stream을 사용할 수 있는 IAM role 권한 지정

먼저 Log group을 생성하려면 CloudWatch에 Log 메뉴를 선택하고 Create log group 을 선택한다. 





Log group에 기록하기 위한 IAM role은 아래와 같은 권한이 필요하다. 


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}   



이제 VPC에 Flow log를 설정해 보자.


VPC를 클릭한 후 Flow logs 탭을 선택해 Create Flow log 버튼을 클릭한다. 



  • Filter를 설정해 VPC 로 유입되는 트래픽 중 허용된 것 / 거부된 것 / 모두 기록 할지를 선택할 수 있다. 위에서는 거부된 것만 기록하도록 설정하였다.
  • Role은 위에서 만든 IAM role을 설정한다. 
  • Log group은 CloudWatch에서 만든 log group 명을 선택한다.  


설정을 완료 하고 CloudWatch의 Log stream 기록을 보면 아래와 같이 reject log 를 볼 수 있다. 




참고로 Log Record 필드의 의미는 아래와 같다. 


version, account, eni, source, destination, srcip, destip="22", protocol="6", packets, bytes, windowstart, windowend, action="REJECT", flowlogstatus





다음 포스팅에는 VPC 의 Private 환경에서도 외부로 접속할 수 있도록 해주는 NAT Gateway 와 Bastion host 에 대해서 알아보자. 


AWS VPC를 디자인해보자(3) - NAT Gateway 와 Bastion host




[참고]


  • http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
  • http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_ACLs.html
  • http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/flow-logs.html
  • http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html


저작자 표시
신고
2 Comments
댓글쓰기 폼