[신한투자증권 프로 디지털 아카데미] 클라우드 환경의 이해와 클라우드 보안(2)

 

 

1. VPC의 연결 옵션

VPC(Virtual Private Cloud) : AWS 상에서 내가 직접 구성하는 가상의 독립 네트워크, 퍼블릭 클라우드(AWS) 위에 내 사설망처럼 사용할 수 있는 환경을 제공하기 위해 사용

 

1) 인터넷 액세스 제한 : 서브넷 별로 다른 라우팅

- 인터넷 게이트웨이를 VPC에 연결한 후, 서브넷이 인터넷을 사용할 수 있도록 하려면 라우팅 테이블에 경로를 추가해 주어야 함 - 이게 라우터가 하는 역할

- 프라이빗 서브넷은 인터넷 게이트웨이와 연결되지 않아 외부 인터넷을 사용할 수 없음, 외부에서 격리되 형태이므로 apt update 와 같은 명령도 실행 불가

- but 프라이빗 서브넷에서도 소프트웨어 업데이트 등 외부 통신이 필요한 경우가 있음 - 그래서 NAT Gateway 사용

- NAT Gateway : 프라이빗 서브넷에서 인터넷으로 나가는 트래픽만 허용, 들어오는 트래픽은 차단하고 나가는 트래픽만 허용하는 방식으로 동작 = 인바운드는 불허, 아웃바운드는 허용

 

- 시큐리티 그룹 설정 여부와 상관 없이 프라이빗 서브넷은 인터넷 통신 자체가 불가함을 의미

- 그래서 나트 게이트웨이를 통해 인터넷 통신을 하고, 이렇게 통신이 가능하다는 전제 하에 시큐리티 그룹을 설정하는 것

→ 나트 게이트웨이 사용하는 경우 - VPC에 연결된 인터넷 게이트웨이와 라우팅 테이블을 설정해야 함 - 인터넷 통신 가능 - 시큐리티 그룹을 통해 포트와 프로토콜 기반의 접근 제어 설정

 

 

- 나트 게이트웨이는 퍼블릭 IP를 가지고, 프라이빗 서브넷 안의 인스턴스들은 이 퍼블릭 IP를 통해 인터넷과 통신하므로 외부에서는 하나의 퍼블릭 IP처럼 보임

• NAT Gateway는 퍼블릭 서브넷에 배치되고, 퍼블릭 IP가 할당
• 프라이빗 서브넷에 있는 EC2 인스턴스들은 자체적으로 퍼블릭 IP가 없음 → 직접 인터넷과 통신할 수 없음
• 하지만 라우팅 테이블에서 NAT Gateway를 경유하도록 설정하면,
  • EC2가 외부로 트래픽을 보낼 때, NAT Gateway가 대신 퍼블릭 IP를 사용해 요청을 보냄
  • 외부 서버는 이 NAT Gateway의 하나의 퍼블릭 IP만 인식
  • 즉, 여러 인스턴스가 NAT를 통해 나가도, 외부에서는 모두 같은 IP(=NAT의 IP) 로 보임

 

 

2) VPC 간 연결 : VPC peering

각 부서마다 vpc 를 만드는 경우가 있는데, 이 때마다 퍼블릭을 통해 연결하면 불편함이 있음

네트워크를 통해 통신하면 속도가 느려지거나 보안의 문제 → 그래서 VPC peering 사용 !

 

- VPC Peering : 서로 다른 두 VPC 간에 프라이빗 IP 주소를 사용한 통신이 가능하도록 연결해주는 기능

 

- VPC A - C 통신은 가능하지만 VPC C - D 는 통신 불가능

- Transit VPC = 여러 개의 VPC 가 서로 직접 피어링 하지 않고 중앙의 VPC 를 거쳐 간접적으로 연결되는 구조

 

- 한쪽 인스턴스가 다른 인스턴스로 패킷을 보내면, 그 인스턴스는 그 요청에 대한 응답 패킷을 되돌려 보낸다
→ 이건 AWS에서 Security Group이 stateful 하기 때문에 가능한 일

 

 

3) 회사 네트워크에 연결 : Virtual Private Network(VPN) & Direct Connect(DX)

- DX like 광케이블

- 인터넷으로 전송하면 안전하지 않기 때문에 vpn 사용 or direct connect

- 이렇게 연결을 하게 되면 데이터센터를 네트워크로 확장한 듯한 느낌 = 하이브리드 클라우드

 

- AWS VPN 을 실시간 서비용 네트워크로 사용하기에는 어려움이 있음
→ 시큐어 하는 건 가능하지만, 인터넷을 연결해서 통신하는 것이기 때문에 원활한 레이턴시를 보장받기 어려움

- 결국, IPSec 을 연결하는 것이지 전용망을 사용하는 것이 아니기 때문에 DX 를 사용하는 것 !

 

 

2. VPC 및 다른 AWS 서비스

 

1) VPC Endpoinsts for Amazon S3

- VPC 엔드 포인트에 내가 가진 버킷들 중 특정 버킷만 통신할 수 있도록 설정 - S3를 보안적으로 내부망처럼 보호하고, 오직 내가 만든 앱에서만 안정적이고 저렴하게 접근하도록 하기 위해서

- 인터넷에서 오는 버킷 모두 차단, 내 애플리케이션에서만 오는 것만 허용

 

 

3. VPC : your private network in AWS

 

- AWS에서 EC2 인스턴스를 만들면, 외부와 통신하기 위해 IP 주소가 필요함

- 이를 위해 사용자는 퍼블릭 IP/프라이빗 IP 설정, Security Group을 통해 포트 개방을 해줘야 함

- 그러나 사용자가 많아지고 요구사항이 복잡해지면서 보안성 문제, 인터넷과 완전히 분리된 내부망 요청 발생

- 그런데 프라이빗에서도 외부 요청은 하고 싶다? 그래서 NAT Gateway 사용

• NAT Gateway : 프라이빗 서브넷의 인스턴스가 인터넷으로 나가는 것만 허용
• IGW : 퍼블릭 서브넷에 연결되어 있어야 NAT가 외부와 통신 가능
• 라우팅 테이블 : 프라이빗 서브넷 → NAT → 인터넷 게이트웨이로 연결 경로 설정 필요

- 정리) NAT는 퍼블릭 서브넷에 존재해야 하며, 프라이빗 서브넷의 인스턴스가 외부와 통신하려면 반드시 퍼블릭 서브넷에 NAT Gateway가 있어야 함

 

 

1) 네트워크를 어떻게 구성할 것인가

- 서로 다른 가용영역에 만든다 – 왜 ?

• 가용영역마다 서브넷을 나누는 이유는 물리적 장애를 격리하고, 고가용성과 탄력성 있는 구조를 설계하기 위해서
• 이를 통해 AZ 하나에 장애가 발생해도 다른 AZ를 통해 서비스를 지속할 수 있음

 

 

4. ElastiCache

 

- 엘라스틱캐시는 메모리 안에서 돌아가는 캐시로, 저장장치에 비해서 굉장히 빠르고 성능이 좋음 – 왜냐면 물리적인 거리가 매우 가깝기 때문

- 엘라스틱캐시는 퍼블릭 서브넷을 생성하더라도 퍼블릭 아이피가 할당되지 않음 – 왜? 보안의 이유

• 캐시는 보통 내부 시스템(웹/애플리케이션 서버)만 접근해야 함, 외부 노출은 보안 리스크

 

1) 방화벽 호스트 Bastion Host

 

- 퍼블릭 아이피가 없는 인스턴스를 호출해야 한다면 ? 바스티온 호스트를 통해 프라이빗 서브넷에 있는 인스턴스와 통신할 수 있도록 함

 

- Blue Server가 Red Server에 SSH 터널(포트 22)을 통해 접속하면, 그 터널을 통해 Red Server가 내부망에 있는 Green Server의 80번 포트로 요청을 전달 - 외부에서 직접 Green Server에 접근하는 것이 아니라, Red Server를 우회(터널링)하는 구조

- SSH 는 22번 포트를 사용함, 8080 포트를 이용해서 22번 포트로 터널을 뚫는다고 생각하면 됨

- Red Server, Green Server 컴퓨터는 하나의 네트워크 안에 있어서 프라이빗 통신이 가능함

 

 

- 포트 번호는 변경 가능 – 보안을 위해서, 포트 번호를 통해 어떤 소프트웨어인지 알고 취약점을 알 수 있기 때문에

- 인스턴스가 같은 vpc 안에 있어야 한다 - EC2 인스턴스 간에 프라이빗 IP로 통신하려면 반드시 같은 VPC 안에 있어야 함, VPC가 다르면 서로 프라이빗 네트워크가 격리되기 때문에 직접 통신할 수 없음

- 만약 다른 VPC에 있다면 VPC Peering이나 Transit Gateway 같은 연결 수단이 필요