1. AWS VPC - RDS, EC2, Mail 보안 그룹 및 탄력적 IP 생성

IT 개발/AWS

1. AWS VPC - RDS, EC2, Mail 보안 그룹 및 탄력적 IP 생성

미웡할꺼야 2020. 12. 18. 22:22

[참고] AWS>제품>Amazon VPC>요금

[참고] AWS>설명서>Amazon VPC>사용 설명서>보안>보안 그룹

[참고] AWS>설명서>Amazon VPC>사용 설명서>VPC 네트워킹 구성 요소 >탄력적인 IP 주소

[참고] AWS>설명서>Amazon VPC>사용 설명서>보안>데이터 보호>인터네트워크 트래픽 개인 정보 보호

[참고] [AWS] NetworkACL & SecurityGroup 개념 - 뚜기의 S 톨이

[참고] AWS VPC 기초 구성도 및 용어 설명 - Las 낙서장 - Tistory

[다음] 2. AWS RDS - DB인스턴스 생성 및 Oracle SQL Developer 접속

운영체제(OS) : Windows 10 64bit

AWS 프리 티어 범위에서 진행.

네트워크 ACL(Access Control List)

네트워크 ACL(액세스 제어 목록)은 1개 이상의 서브넷 내부와 외부의 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC를 위한 선택적 보안 계층입니다. 보안 그룹과 비슷한 규칙으로 네트워크 ACL을 설정하여 VPC에 보안 계층을 더 추가할 수 있습니다.

보안 그룹(Security Group)

보안 그룹은 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다. VPC에서 인스턴스를 시작할 때 최대 5개의 보안 그룹에 인스턴스를 할당할 수 있습니다. 보안 그룹은 서브넷 수준이 아니라 인스턴스 수준에서 작동하므로 VPC에 있는 서브넷의 각 인스턴스를 서로 다른 보안 그룹 세트에 할당할 수 있습니다.

Amazon EC2 API 또는 명령줄 도구를 사용하여 인스턴스를 시작하고 보안 그룹을 지정하지 않으면 인스턴스가 VPC의 기본 보안 그룹에 자동으로 할당됩니다. Amazon EC2 콘솔을 사용하여 인스턴스를 시작하는 경우 인스턴스에 대한 새 보안 그룹을 생성할 수 있는 옵션이 제공됩니다.

보안 그룹 및 네트워크 ACL 비교
보안 그룹	네트워크 ACL
인스턴스 레벨에서 운영	서브넷 레벨에서 운영
허용 규칙만 지원	허용 및 거부 규칙 지원
상태 저장: 규칙에 관계없이 반환 트래픽이 자동으로 허용됨	상태 비저장: 반환 트래픽이 규칙에 의해 명시적으로 허용되어야 함
트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가함	트래픽 허용 여부를 결정할 때 번호가 가장 낮은 규칙부터 순서대로 규칙을 처리합니다.
인스턴스 시작 시 누군가 보안 그룹을 지정하거나, 나중에 보안 그룹을 인스턴스와 연결하는 경우에만 인스턴스에 적용됨	연결된 서브넷의 모든 인스턴스에 자동 적용됨(보안 그룹 규칙이 지나치게 허용적일 경우 추가 보안 계층 제공)

탄력적(Elastic) IP

탄력적 IP 주소는 동적 클라우드 컴퓨팅을 위해 고안된 정적 IPv4 주소입니다. 탄력적 IP 주소를 사용하면 주소를 계정의 다른 인스턴스에 신속하게 다시 매핑하여 인스턴스나 소프트웨어의 오류를 마스킹할 수 있습니다. 탄력적 IP 주소는 AWS 계정에 할당되며 릴리스할 때까지 할당된 상태로 유지됩니다.

탄력적 IP 주소는 인터넷에서 연결 가능한 퍼블릭 IPv4 주소입니다. 인스턴스에 퍼블릭 IPv4 주소가 없는 경우 탄력적 IP 주소를 인스턴스에 연결하여 인터넷 통신을 활성화할 수 있습니다. 예를 들어 로컬 컴퓨터에서 인스턴스에 연결할 수 있습니다.

현재는 IPv6에 대한 탄력적 IP 주소를 지원하지 않습니다.

네트워크 ACL은 외부간 통신을 담당하는 보안 기능으로 서브넷 단위로 설정이 가능하며, 보안 그룹은 내부간 통신을 담당하며 서버 단위로 정책을 설정할 수 있다.

네트워크 ACL : Stateless 필터링 방식 / 보안 그룹 : Stateful 필터링 방식.

* Stateless와 Stateful의 차이점

Stateless : 요청 정보를 따로 저장하지 않기 때문에 응답하는 트래픽에 대한 필터링을 설정해야 함.

Stateful : 요청 정보를 저장하여 응답하는 트래픽 제어를 하지 않음.

외부에서 내부로 들어오는 경우

Case1. From External to AWS(외부로부터 AWS로)
외부에서 요청이 오면 인바운드(네트워크 ACL 정책 > 보안 그룹 정책)를 거치게 되며 서버 측 응답은 네트워크 ACL의 아웃바운드 정책만 거친 후 사용자에게 응답한다.
주의) 네트워크 ACL의 아웃바운드 정책에 1024-65535 정책이 없으면 응답을 할 수 없다.
Case2. Same Subnet(동일 서브넷)
같은 서브넷에 서버가 존재할 경우 보안 그룹의 인바운드 정책만 따른다.
Case3. Another Subnet(다른 서브넷)
통신할 서버가 다른 서브넷에 존재할 경우 Case1번과 같은 조건이기 때문에 Case1번과 동일하게 동작.

내부에서 외부로 나가는 경우

외부에서 내부로 들어오는 경우 Case 3개와 반대로 생각하면 된다.

Case4. From Internal to External(내부로부터 외부로)
서버에서 외부로 접속을 시도할 때 아웃바운드(보안 그룹 정책 > 네트워크 ACL 정책)를 거치게 되며 응답을 받을 때는 네트워크 ACL의 인바운드 정책만 적용된다.
주의) 네트워크 ACL의 인바운드 정책에 1024-65535 정책이 있어야 통신이 된다.
Case5. Same Subnet(동일 서브넷)
Case2번과 동일.
Case6. Another Subnet(다른 서브넷)
Case4번과 동일.

결론

서브넷이 다를 경우 : 네트워크 ACL 정책이 적용됨.
서브넷이 같을 경우 : 보안 그룹 정책만 적용됨.
네트워크 ACL : Stateless 기반으로 인바운드/아웃바운드 정책에 1024-65535 Port를 허용해야 통신이 가능.
보안 그룹 : 방화벽이라고 생각하면 됨.

보안 그룹은 RDS, EC2, Mail 3개 생성, 탄력적 IP는 1개만 생성.

네트워크 ACL은 개발의 편의를 위해 default로 인바운드/아웃바운드 규칙 : [유형=모두 트래픽, 포트 범위=모두]로 한다.

보안 그룹 생성

1) AWS Management Console > VPC 검색 또는 선택.

2) VPC Console > 보안 > 보안 그룹 > 보안 그룹 생성 클릭.

3.1) 보안 그룹 이름=[어디에 어떻게 쓰이는 무엇인지 + AWS 서비스] , 설명=[어떻게 쓰이는 무엇인지 + AWS 서비스] , VPC=[기존 VPC | 기본 VPC] 선택.

다른 서비스에서 참조할 때 서비스 이름 혹은 태그 값으로 나오기에 이름 및 설명 등은 [어디에 어떻게 쓰이는 무엇인지 + AWS 서비스]로 작성하는 것이 좋다.
보안 그룹 이름 : 한글 안됨. 보안 그룹을 생성한 후에는 이름을 편집할 수 없다.
설명 : 한글 안됨, 선택 사항.
VPC : VPC를 선택하지 않으면 EC2-Classic 보안 그룹이 생성됨. 이는 Classic 인스턴스에서만 사용할 수 있다.

3.2)

RDS=인바운드/아웃바운드 규칙 설정, 규칙 동일.(위 개념 설명 Case1, Case4 참고)

EC2=인바운드 규칙만 설정.(위 개념 설명 Case1 참고)

Mail=아웃바운드 규칙만 설정.(위 개념 설명 Case4 참고)

규칙 설정은 아래 그림 참고.

설명 : 한글 안됨, 선택 사항, 설명은 어디에 어떻게 쓰이는 무엇인지로 명시하는 것이 좋음.
인바운드 규칙(클라이언트 -> 서버 방화벽 허용), 아웃바운드 규칙(서버 -> 클라이언트 방화벽 허용). IPv4=0.0.0.0/0, IPv6=::/0이다.
Oracle SQL Developer로 접속하기 위해 인바운드 규칙 설정. EC2 사용 시 RDS> Server> Client로 원활한 데이터 이동을 위해 아웃바운드 규칙 설정.
SSH : Linux Server 접속, 내 PC의 IP주소에서만 세팅된 Linux Server에 접속할 수 있도록 하기 위함.
HTTP : 사용자들이 Linux Server 위에 세팅된 Web Server에 접속하기 위함.
HTTPS : 사용자들이 Linux Server 위에 세팅된 SSL이 적용된 Web Server로 접속하기 위함.
사용자 지정 TCP(8080) : 사용자들이 Linux Server 아래 세팅된 Tomcat Server로 접속하기 위함.
Mail 보안 그룹에서 인바운드 규칙=수신 측, 아웃바운드 규칙=발신 측이다.
유형, 소스에서 SMTP(Non-Encrypted, SSL), IMAP(Non-Encrypted, TLS, SSL), POP3(Non-Encrypted, SSL)는 제공하지만 SMTP(TLS)는 없기에 사용자 지정 TCP로 따로 만들어야 한다.

3.3) 태그 추가 > 키=Name , 값=[어디에 어떻게 쓰이는 무엇인지 + AWS 서비스] > 보안 그룹 생성 클릭 > 보안 그룹 생성 완료.

태그(선택 사항). 보안 그룹이 여러 개일 경우 다른 서비스에서 참조 시 태그 값으로 구분하기에 편의상 태그를 추가하는 것이 좋다.
키 : "Name"으로 작성해야 보안 그룹 목록에서 태그 값으로 나와 구분이 가능하다. 키를 다른 이름으로 작성 시 공백으로 나온다.

탄력적 IP 생성

4) VPC Console > 가상 프라이빗 클라우드 > 탄력적 IP > 탄력적 IP 주소 할당 클릭.

5) 네트워크 경계 그룹=현재 리전 위치 > 태그 추가 클릭 > 키=Name , 값=[어디에 어떻게 쓰이는 무엇인지 + AWS 서비스] > 할당 클릭 > 탄력적 IP 주소 할당 완료.

마무리

요약 : 네트워크 ACL는 default로 고정 > RDS, EC2, Mail 보안 그룹 생성 > 탄력적 IP 생성.

VPC Console 혹은 다른 서비스 Console에서 보안 그룹 및 탄력적 IP를 생성해도 전체 공유가 된다.

계정 생성 시 기본 보안 그룹이 주어지지만 구분을 위해 RDS, EC2, Mail 보안 그룹을 만듦.

Mail 보안 그룹은 Mail을 사용하지 않을 경우 생성하지 않아도 된다.

EC2 인스턴스 생성 시 보안 그룹 사항에서 사용자 지정 TCP/위치 무관 규칙 추가 시 AWS에서 보안상 인스턴스 생성을 못하게 한다. 따로 설정해야 하기에 처음부터 보안 그룹부터 만드는 것이 편하다.

탄력적 IP는 인스턴스 생성 후 할당해도 되지만 보안 그룹 생성을 하면서 같이 진행했다.

네트워크 ACL과 보안 그룹의 관계에 대해 숙지하고 있어야 두 서비스에 있는 인바운드/아웃바운드 규칙을 설정할 때 혼란이 생기지 않는다. 네트워크 ACL의 인바운드/아웃바운드 규칙이 방화벽 역할을 하여 입출력 트래픽을 제어하고, 이를 거쳐 인스턴스에 도달하면 보안 그룹의 인바운드/아웃바운드 규칙 또한 네트워크 ACL과 똑같은 행동을 하여 인스턴스에 접근하는 것이다. 즉, 네트워크 ACL은 Router의 방화벽 역할을 하고 보안 그룹은 인스턴스의 방화벽 역할을 한다.

결론적으로 아래 그림과 같은 흐름이 형성된다.

처음 개념을 접할 때 많이 어려우므로 Client<=>네트워크 ACL<=>보안 그룹<=>인스턴스<=>보안 그룹<=>네트워크 ACL<=>Server 로 생각하면 쉬울 것 같다.

[다음] 2. AWS RDS - DB인스턴스 생성 및 Oracle SQL Developer 접속