서브넷 및 네트워크 액세스 제어 목록 + 네트워크 ACL

VPC는 게이트웨이는 경계에만 적용되며 IT 전략의 일환으로 주력해야 하는 네트워크 보안의 구성 요소일 뿐입니다.

 

AWS에는 모든 보안 계층, 즉 네트워크 강화, 애플리케이션 보안, 사용자 ID, 인증 및 권한 부여, 분산 서비스 거부(DDoS) 방지, 데이터 무결성, 암호화 등을 처리하는 다양한 도구가 있습니다. 

 

VPC에서 서브넷을 사용하는 이유??

- 유일한 기술적인 이유는 게이트웨이에 대한 액세스 관리를 위함

- 서브넷은 트래픽 권한을 제어합니다. 

 

퍼블릭 서브넷은 인터넷 게이트웨이에 액세스할 수 있습니다. 프라이빗 서브넷은 그렇지 않죠.

서브넷의 역할

<예시>

일부 고객이 계산원을 건너 뛰고 바리스타에게 직접 주문하려 한다고 가정해 보십시오. 그러면 주문 흐름이 중단되고 고객이 커피숍의 제한 구역에 접근하게 됩니다.

이 문제를 해결하기 위해 커피숍 점주는 계산대와 바리스타를 별도의 워크스테이션에 배치하여 카운터 영역을 구분합니다. 계산원의 워크스테이션은 퍼블릭이고 고객을 응대하도록 설계되었습니다. 바리스타의 워크스테이션은 프라이빗입니다. 바리스타는 계산원으로부터 주문을 받을 수는 있지만 고객으로부터 직접 주문을 받을 수는 없습니다.

 

퍼블릭 서브넷에는 온라인 상점의 웹 사이트와 같이 누구나 액세스할 수 있어야 하는 리소스가 포함됩니다.

 

프라이빗 서브넷에는 고객의 개인 정보 및 주문 내역이 포함된 데이터베이스와 같이 프라이빗 네트워크를 통해서만 액세스할 수 있는 리소스가 포함됩니다. 

VPC 내에서 서브넷은 서로 통신할 수 있습니다. 예를 들어 퍼블릭 서브넷에 있는 Amazon EC2 인스턴스가 프라이빗 서브넷에 있는 데이터베이스와 통신하는 애플리케이션이 있을 수 있습니다.

 

 

VPC의 네트워크 트래픽

고객이 AWS 클라우드에서 호스팅되는 애플리케이션에 데이터를 요청하면 이 요청은 패킷으로 전송됩니다

패킷은 인터넷에서 보내는 메시지이며 서브넷 경계를 지나는 모든 패킷은 네트워크 액세스 제어 목록, 즉 네트워크 ACL에서 검사됩니다. 발신자와 통신 방식을 기준으로 패킷에 서브넷에 출입할 수 있는 권한이 있는지 확인하기 위함이죠.

<패킷은 인터넷 게이트웨이를 통해 VPC로 들어갑니다. 패킷이 서브넷으로 들어가거나 서브넷에서 나오려면 먼저 권한을 확인해야 합니다. 이러한 사용 권한은 패킷을 보낸 사람과 패킷이 서브넷의 리소스와 통신하려는 방법을 나타냅니다.
서브넷의 패킷 권한을 확인하는 VPC 구성 요소는 네트워크 ACL(액세스 제어 목록)입니다.>

패킷?

- 인터넷이나 네트워크를 통해 전송되는 데이터의 단위

 

네트워크 ACL, 액세스 제어 목록

- 발신자와 통신 방식을 기준으로 패킷에 서브넷에 출입할 수 있는 권한이 있는지 확인

- 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽

인바운드, 아웃바운드 트래픽?

<인바운드 트래픽>

- 클라이언트(사용자)가 서버에게 http request 등을 보내면서 시작되는 트래픽

- 서버 기준으로 보면 외부에서 부터 트래픽이 시작됐으니까

<아웃바운드 트래픽>

- 서버가 클라이언트(사용자)에게 먼저 요청을 보내면서 시작되는 트래픽

- 서버에서 요청을 보내 사용자가 푸쉬와 같은 응답을 받는 경우

 

<예시>

여권 심사관이라 생각하시면 됩니다. 승인 목록에 있다면 통과할 수 있죠. 승인 목록에 없거나 입국 금지 목록에 있다면 차단당합니다. 네트워크 ACL은 여권 심사대처럼 서브넷을 출입하는 트래픽을 검사합니다. 입국 또는 출국할 때 목록을 확인하는 식이죠. 그리고 입국에 성공했다고 해서 출국이 반드시 허용되지는 않습니다. 승인된 트래픽은 나갈 수 있지만 관리자 요청을 통해 시스템 제어 권한 획득을 시도하는 등의 유해할지도 모르는 트래픽은 대상을 건드리기도 전에 차단됩니다. 건드릴 수 없다면 해킹할 수도 없죠.

 

<AWS 예시>

각 AWS 계정에는 기본 네트워크 ACL이 포함됩니다.

VPC를 구성할 때 계정의 기본 네트워크 ACL을 사용하거나 사용자 지정 네트워크 ACL을 생성할 수 있습니다.

계정의 기본 네트워크 ACL은 기본적으로 모든 인바운드 및 아웃바운드 트래픽을 허용하지만 사용자가 자체 규칙을 추가하여 수정할 수 있습니다. 사용자 지정 네트워크 ACL은 사용자가 허용할 트래픽을 지정하는 규칙을 추가할 때까지 모든 인바운드 및 아웃바운드 트래픽을 거부합니다. 또한 모든 네트워크 ACL에는 명시적 거부 규칙이 있습니다. 이 규칙은 패킷이 목록의 다른 모든 규칙과 일치하지 않으면 해당 패킷이 거부되도록 합니다. 

<문제점>

- 네트워크 ACL은 상태 비저장 패킷 필터링을 수행합니다. 즉, 아무것도 기억하지 않고 각 방향(인바운드 및 아웃바운드)으로 서브넷 경계를 통과하는 패킷만 확인합니다. 

- 패킷이 특정 EC2 인스턴스에 도달할 수 있는지는 평가하지 않습니다. 같은 서브넷에 여러 EC2 인스턴스가 존재할 때도 있지만 메시지 전송자와 메시지를 전송할 수 있는 포트에 관해서는 다른 규칙이 적용됩니다. 따라서 인스턴스 수준의 네트워크 보안도 필요= <보안 그룹>

 

보안 그룹

- 패킷이 서브넷에 들어간 후에는 서브넷 내의 리소스(예: Amazon EC2 인스턴스)에 대한 권한이 평가되어야 합니다. 

- 패킷에서 Amazon EC2 인스턴스에 대한 권한을 확인하는 VPC 구성 요소는 보안 그룹

- 모든 EC2 인스턴스는 시작되면 자동으로 보안 그룹으로 이동
- Amazon EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽

- 보안 그룹은 상태 저장 패킷 필터링을 수행합니다. 즉, 들어오는 패킷에 대한 이전 결정을 기억합니다.

 

기본적으로 보안 그룹은 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽을 허용합니다. 사용자 지정 규칙을 추가하여 허용 또는 거부할 트래픽을 구성할 수 있습니다.

<예시>

로비에서 방문객을 안내하는 경비원이 있는 아파트 건물을 생각해 보십시오. 방문객을 패킷으로 생각할 수 있으며 경비원을 보안 그룹으로 생각할 수 있습니다. 방문객이 도착하면 경비원은 방문객 목록을 보고 해당 방문객이 건물 안으로 들어갈 수 있는지 확인합니다. 그러나 방문객이 건물에서 나갈 때는 경비원이 목록을 다시 확인하지 않습니다.

서브넷 내에 여러 Amazon EC2 인스턴스가 있는 경우 동일한 보안 그룹에 연결하거나 각 인스턴스마다 서로 다른 보안 그룹을 사용할 수 있습니다. 

 

네트워크 ACL과 보안 그룹을 모두 사용하면 VPC에서 트래픽에 대한 사용자 지정 규칙을 구성할 수 있습니다.