보안을 위한 AWS network 구성하기

AWS Community Day Online 2021 세션 수강!

 

 

인터넷 기반의 컴퓨팅을 Cloud라고 정의한다

1. AWS Network

VPC (virtual Private Cloud)

• AWS 계정 전용의 가상 데이터 센터 (네트워크가 분리되어 있는 개인의 사설 network 센터 개념)
• region에 종속적
  • region 당 다수의 vpc 생성 가능
  • 계정당 생성 가능한 vpc의 개수는 한정이 되어 있음
• enterprise 환경에서는 다수의 vpc를 이용하는 경우가 다수
• 소규모 app의 경우 단일 vpc가 유리할 수도 있다!
  

1. 사용할 IP 범위 대역 구하기

• CIDR notation 사용
• ex) 172.16.0.0/16 (IP/subnet)

2. VPC 내부의 subnet 생성

• subnet은 AZ에 종속적
• 각 AZ에는 default subnet이 존재
• VPC 생성 시, default routing table이 생성됨
  • network traffic rule을 포함하고 있음
  • VPC내의 모든 resource에 대한 통신 경로 정보
• 하나의 subnet은 하나의 routing table에 연결이 되어 있어야 함
  • 최초로는 default routing table에 연결
  • 추가 routing table을 생성하여 명시적으로 연결하는 것 가능
• VPC 내부에서의 통신은 가능, 외부(internet)과의 통신은 불가
  

  

  • 외부에서 VPC내부의 instance에는 접근할 수 없다는 의미!
  • VPC 자체가 private ip 대역을 가지는 network망이므로

• VPC의 instance와 internet간의 통신을 허용해주는 igw(internet gateway) 사용
  

  

  

  • subnet routing table에 igw에 대한 inbound/outbound access rule을 허용해줌으로서 사용 가능
  • public ip 또는 elastic ip를 별도로 할당해주어야 함
    
• 요즘은 auto-scaling등으로 ip, resource를 유연하게 관리하는 것이 추세!

igw와 연결된 subnet을 public subnet이라고 한다

internet에서 직접 access할 수 없는 subnet은 private subnet이라고 한다

• batch 처리를 위한 instance, db 등
• private subnet을 public의 것보다 약 4배 정도 크게 구성하는 것이 일반적

 

Network ACL, Security Group

• in-outbound 통신을 지원하는 firewall 기능 지원
  

  

NACL	Security Group
subnet을 기준으로 적용	instance를 기준으로 적용
외부 통신의 경우에만 NACL을 거침	외부, 내부 통신 모두에서 Security Group을 거침
access 및 deny rule 모두 적용 가능	모두 deny인 상태에서 access rule만 별도로 적용 가능
등록한 규칙의 순서에 따른 정책 생성	추가한 rule에 대하여 일괄적으로 정책을 생성
stateless 하다	stateful 하다

 

---

❓ ec2를 하나 생성한다면, 해당 instance는 어디에 위치할까? (별도의 subnet을 설정하지 않는 경우)

• default VPC내의 default subnet에 위치하게 됨
• default subnet은 default routing table에 연결되어 있음

 

 

 

 

2. Private Subnet의 instance에 접근하기

Bastion Host + SSH Tunneling

• 내부에 존재하는 각각의 instance에 모두 ip(public/elastic)를 부여해 줄 수는 없다
  • 비용, 보안 issue 발생
    

Bastion Host

• public network에 위치하여 외부-내부 네트워크 사이의 proxy 역할을 하는 instance
  1. 외부에서 ssh로 bastion host에 접속
  2. ssh tunneling을 통해 각 vpc내의 server들에 private ip로 접근
• 각종 보안 이슈 handling 및 log 관리 등을 중앙화 시킬 수 있다
• instance를 별도로 생성하고 key pair를 관리해야 한다는 번거로움 발생
• private instance에서 internet으로 나가는 outbound 연결은 불가
  • dependency, os 업데이트 등

NAT(Network Address Translation)

• public subnet에 위치하는 EC2 instanceNAT가 내부의 traffic을 public gateway를 통해 internet으로 연결
•  
• instance를 사용하기 때문에 병목 현상에 취약, 의존성 높음

NAT Gateway

• 별도의 AWS 서비스로 NAT traffic handling에 최적화 되어있다
• 각 AZ에 이중화로 구현되므로 고가용성 보장

로그인은 bastion host로 inbound 접속을 하고,
internet access는 NAT gateway로 통신하도록 구성하는 것이 보편적

 

SSM Session Manager

• server에 로그인하지 않고 instance를 안전하게 원격으로 관리할 수 있는 기능 제공
• inbound port를 열거나 ssh key를 관리할 필요 없이 바로 private instance에 연결할 수 있다
• https protocol을 사용하므로
  • key pair를 생성할 필요가 없다
  • security group에 별도의 rule을 등록할 필요가 없다
  • ssh port를 외부에 개방해야 할 필요도 없다
• inbound port를 닫아도 내부적으로 ssh port에 접근 가능
• AWS IAM Credential을 사용(instance에서 수동으로 user들을 관리)하는 것 대신, SSM Session Manager를 사용!
• instance의 action을 monitoring하여 log를 bucket에서 관리하는 것도 가능

 

AWS Client VPN(Virtual Private Network)

• 인터넷과 암호화된 터널을 이용하여 두 개 이상의 물리적 네트워크 사이에 가상 네트워크를 생성하여 마치 하나의 네트워크인 것처럼 이용
• 외부의 클라이언트가 마치 VPC network안에 있는 host인것처럼 관리 (=vpc내의 instance인것처럼)
• 직접 private instance에서 app을 돌리고 web에 접속하는 등 관리가 용이
• VPN 서버를 직접 구축하여 사용하는 경우, VPN server의 public 노출/인증 요소 직접 생성/패치 지속 업데이트 등 여러 고려사항들이 많아진다
• VPN 서버는 숨겨져 있고, 접근이 가능한 endpoint가 주어지는 방식
• VPN 서버 인증서는 AWS Certificate Manager에 업로드 후 참조하는 방식으로 간편하게 사용 가능

1. VPC에 client VPN endpoint 생성
2. VPN client가 할당받을 ip대역을 CIDR로 등록 (최소 크기 flash20?)
3. 할당받은 endpoint를 원하는 subnet에 연결
   • VPN network interface가 생성됨
   • routing table에 외부 client에서 vpc network에 들어올 수 있는 권한/규칙을 추가해야 함
4. client에서 open VPN을 지원하는 client SW를 사용하여 연결
   • SSL/TLS(443)