Security Groups & NACLs
- 예1) 요청이 EC2 인스턴스 내부로 들어올 때, 언제 보안 그룹이 연결된 EC2 인스턴스를 사용할지와 들어오는 요청의 NACL 역할
요청이 서브넷에 들어가기 전에 NACL로 이동하며,
NACL에는 몇 가지의 인바운드 규칙이 정의되며 요청이 허용되지 않으면 내부로 들어갈 수 없음
첫 번째 요청이 NACL을 통과해서 서브넷 내부에 도달한 후 보안 그룹 인바운드 규칙을 만나게 되는데
만약 그 요청이 명시적으로 허용 받지 못하면 거부가 됨
만약 요청이 보안 그룹의 인바운드 규칙을 통과해서 EC2 인스턴스에 도달하면
EC2 인스턴스는 그 응답으로 애플리케이션 관점에서 응답할 내용을 모두 회신되며
보안 그룹의 아웃바운드 규칙은 상태 유지이므로 아웃바운드 규칙은 자동으로 보안 그룹 수준에서 허용됨
그러므로 아래 그림에서는 평가되는 규칙이 없고 보안 그룹 아웃바운드 규칙은 중요하지 않음
그 후 NACL은 무상태이기 때문에 NACL 아웃바운드의 규칙이 평가되고 규칙에 통과하지 못하면 요청도 통과하지 못하게 됨
+) 즉, NACL의 Stateless (무상태) = 규칙 평가 O, 보안 그룹의 Stateful (상태 유지) = 규칙 평가 X
- 예2) 보안 그룹에서 EC2 인스턴스가 아웃바운드 요청을 하여 외부로 바인딩 된 요청을 할 때
EC2 인스턴스가 서브넷에 연결하기 위해 첫 번째로 평가될 규칙은 보안 그룹 아웃바운드 규칙이며
트래픽이 EC2 인스턴스에서 웹으로 나가도록 허용할지를 결정하므로 규칙이 적절하고 요청이 허가되면
그 후에 NACL 아웃바운드 규칙을 통과하여 서브넷에 도달한 후 다시 EC2 인스턴스로 돌아오게 됨
돌아올 때 NACL이 무상태라서 NACL 인바운드 규칙이 평가될 수 있으며
보안 그룹 수준에서는 인바운드 규칙이 상태 유지이므로 무조건 허용
Network Access Control List (NACL)
- 네트워크 액세스 제어 목록인 NACL은 서브넷을 오가는 트래픽을 제어하는 방화벽과 비슷하며
서브넷마다 하나의 NACL이 있고 새로운 서브넷에는 기본 NACL이 할당됨 - NACL 규칙 정의에서 규칙에는 숫자가 있고 범위는 1부터 32766까지 있으며
숫자가 낮을수록 우선순위가 높으므로 우선순위가 제일 높은 것은 1, 가장 낮은 것은 32766 - 첫 번째 규칙 비교로 결정이 나므로
예) CIDR에서 #100 ALLOW 10.0.0.10/32 를 정의하고 같은 CIDR인 특정 IP를 #200 DENY 10.0.0.10/32 로 정의하면
ALLOW가 100, DENY가 200이므로 이 IP 주소는 허용됨 - *의 경우 일치하는 규칙이 없으면 모든 요청을 거부
- AWS는 규칙을 100씩 추가하는 것을 권장
- 새로 만들어진 NACL은 기본적ㅇ로 모두를 거부
- 서브넷 수준에서 특정한 IP 주소를 차단하기 위해 NACL을 사용할 수 있음
NACLs
- NACL은 서브넷 수준에 있으므로 공용 서브넷 및 사설 서브넷 등에 위치해 있음
Default NACL
- 기본 NACL은 연결된 서브넷을 가지고 인바운드와 아웃바운드의 모든 요청을 허용하는 특수성을 가짐
- IPv4를 지원하는 기본 NACL은 모든 것이 나가고 모든 것이 들어올 수 있음
- NACL이 모두 허용하지 않으면 AWS를 시작할 때 심각한 디버깅을 해야 하므로 기본 NACL을 수정하지 않는 것을 추천하며
사용자 정의 네트워크 ACL이 필요하다면 따로 생성
Ephemeral Ports
- 클라이언트와 서버가 연결되면 포트를 사용해야 하므로 IP 주소와 포트가 필요
- 클라이언트트 규정된 포트의 서버에 연결
예) HTTP - 80, HTTPS - 443, SSH - 22 - 서버가 서비스를 올릴 때 클라이언트는 규정된 포트에 접속해야 함
다만 클라이언트가 서버에서 회신 받을 때는 제외 - 서버도 응답을 하려면 클라이언트에 연결해야 하며 클라이언트는 기본적으로 개방된 포트가 없어서
클라이언트가 서버에 접속할 때 자체적으로 특정한 포트를 열게 됨
이 포트는 임시이므로 클라이언트와 서버 간 연결이 유지되는 동안만 열려 있음 - 임시 포트는 OS에 따라 포트 범위가 달라짐
MS Windows 10 또는 IANA - 49152 ~ 65535
Linux = 32768 ~ 60999 이므로 OS 종류마다 서로 다른 포트 범위를 가짐 - 클라이언트가 웹 서버에 연결되며 웹 서버에는 고정 IP 및 고정 포트가 있으며
서버는 클라이언트의 한 번 요청 또는 연결에만 임시 포트 50105를 개방
클라이언트에서 서버로 전송된 요청에는 목적지 IP 정보와 서버가 연결한 목적지 포트, 요청과 관련된 페이로드 등이 존재
아래의 경우 소스 IP인 11.22.33.44는 응답을 위한 것이며 응답을 위한 소스 임시 포트인 50105가 존재
웹 서버가 다시 회신을 위해서 클라이언트와 연결될 때에는 소스 IP와 소스 포트 정보 등이 존재
아래의 경우 서버 포트 정보인 443과 목적지 IP인 11.22.33.44가 존재하며
포트가 필요하면 클라이언트가 전송하며 연결 수명을 위해서만 할당되는 임시 포트인 50105를 재사용
NACL with Ephemeral Ports
- 사설 및 공용 서브넷이 있고 각 서브넷에 연결된 NACL이 하나씩 있을 때 (웹 NACL, DB NACL),
클라이언트가 데이터베이스 인스턴스에 연결을 시작하면 NACL에 허용되어야 하는 규칙에는 4가지가 존재하며
임시 포트를 제대로 구성하는 것이 중요
1) 포트 3306을 통해 TCP부터 데이터베이스의 서브넷 CIDR까지 아웃바운드를 허용해야 요청이 서브넷을 떠날 수 있음
2) 데이터베이스 측에서 DB NACL가 웹 서브넷 CIDR에서 포트 3306으로 TCP를 인바운드 허용해야 함
3) 데이터베이스가 클라이언트가 요청에 회신할 때, 클라이언트에게는 임시 포트가 있으므로 무작위 포트가 할당되므로
DB NACL은 포트 및 임시 포트에서 1024 ~ 65535 범위의 아웃바운드 TCP를 허용
4) 웹 서브넷 CDIR로 아웃바운드 되면 웹 NACL은 DB 서브넷 CIDR의 임시 포트 범위에서 인바운드 TCP를 허용해야 함
Create NACL rules for each target subnets CIDR
- 다중 NACL 및 서브넷이 있다면 CIDR 사용 시, 서브넷이 고유의 CIDR을 가지므로 각 NACL 조합이 NACL 내에서 허용되어야 함
그러므로 NACL에 서브넷을 추가하면 NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야만 함
Security Group vs. NACLs
- 보안 그룹과 NACL의 차이점
- 보안 그룹은 인스턴스 수준에서 작동, NACL은 서브넷 수준에서 작동
- 보안 그룹은 허용 규칙을 지원하지만, NACL은 허용과 거부 규칙을 모두 지원하므로 특정 IP 주소를 거부할 수 있음
- 보안 그룹은 상태 유지이며 규칙과 무관하게 트래픽을 허용하고,
NACL은 무상태이기 때문에 인바운드와 아웃바운드 규칙이 매번 평가됨 - 보안 그룹에서는 모든 규칙이 평가되고 트래픽 허용 여부를 결정하지만,
NACL에서는 가장 높은 우선순위를 가진 것이 먼저 평가되며 첫 번째 비교로 결정됨 - 보안 그룹은 누군가 지정할 때 EC2 인스턴스에 적용되지만
NACL은 NACL에 연결된 서브넷의 모든 EC2 인스턴스에 적용됨
<NACL 및 보안 그룹 실습>
- NACL 콘솔
VPC의 서브에는 네트워크 ACL이 있고 기본 네트워크 ACL의 이름을 DefaultNACL로 설정
이는 기본 설정이기 때문에 서브넷 네 개와 연결되며
인바운드 규칙으로는 모든 포트에 대해 트래픽 전체를 허용하고
Allow에 먼저 효력이 생기기 때문에 Deny 상태인 마지막 열은 영향을 미치지 못하며이는 아웃 바운드 규칙의 경우에도 동일
즉, 기본 NACL은 항상 모든 트래픽에 인바운드와 아웃바운드 권한이 있고
모든 서브넷과 기본적으로 연결된 상태임을 알 수 있음
EC2 인스턴스로 이동하여 BastionHost로 HTTP 서버를 시작하여 연결하기 위해 HTTPD를 설치하여 웹 서버를 시작함
이후 공용 인스턴스인 BastionHost가 보안 그룹을 위해 HTTP가 활성화되었는지 확인하는데
포트 22만 있으므로 보안 그룹 규칙에서 HTTP를 선택하여 인바운드 규칙을 수정
그리고 BastionHost의 Public IP인 52.58.173.122를 입력하여 열게 되면 위에서 입력한 hello world가 나타나게 됨
다음으로는 기본 NACL의 인바운드 규칙탭에서 규칙을 수정하도록 함
현재는 모든 곳에서 모든 트래픽을 허용하는데 우선순위를 80으로 HTTP 유형을 추가하여 이 소스는 모든 곳으로 Deny를 선택
이를 통해 HTTP 트래픽을 차단하는 인바운드 규칙을 활성화하여 위의 페이지를 새로고침하면 무한 로딩이 발생
즉, 시간 초과가 있고 NACL이 방화벽처럼 요청을 차단하기 때문임
그 다음으로는 인바운드 규칙의 HTTP의 우선순위를 80에서 140으로 수정하게 되면
명시적인 거부 규칙이 있지만 규칙 번호 100이 더 우선이라서 모든 트래픽을 허용하게 되어 EC2 인스턴스에 액세스 가능하게 됨
NACL의 무상태를 보기 위해서는 아웃바운드 규칙에 모든 트래픽을 허용하는 규칙을 Deny로 수정하도록 함
그러면 NACL이 반환 트래픽을 허용하지 않기 때문에 인스턴스는 무한 로딩 상태로 바뀌게 됨
이는 EC2 인스턴스의 보안 그룹이 포트 80을 실제로 허용했는지에 대한 여부와는 무관하게 이루어짐
마지막으로 NACL과 보안 그룹은 함께 협력해서 작동하므로
BastionHost의 보안 그룹 인바운드 규칙에서는 HTTP를 유지하고
보안 그룹 아웃바운드 규칙에서의 모든 트래픽을 허용하는 규칙을 삭제하게 되면
보안 그룹은 상태를 유지하고 이는 트래픽이 외부에서 시작해서 인바운드로 허용된다면 거기에 대한 트래픽도 허용한다는 의미
그러므로 아웃바운드 규칙이 없지만 여전히 페이지가 작동하게 되어 EC2 인스턴스에 액세스할 수 있음
하지만 EC2 인스턴스가 연결을 시도하기 위해 Google 계정에 연결하려는 경우에는 아웃바운드 규칙이 없어 거부되게 됨
이때 아웃바운드 규칙을 허용으로 바꾼다면 보안 그룹은 상태 유지, NACL은 무상태이기 때문에 반환 트래픽을 허용하게 됨
'Cloud > AWS' 카테고리의 다른 글
| [SAA] Transcribe 개요 (0) | 2022.08.16 |
|---|---|
| [SAA] Rekognition 개요 (0) | 2022.08.16 |
| [SAA] 아키텍처의 예 (0) | 2022.06.02 |
| [SAA] ECS 서비스 및 작업, 로드 밸런싱 (0) | 2022.05.24 |
| [SAA] AWS Trusted Advisor 개요 (0) | 2022.05.07 |
