[공통] Security Group[ACG], NACL

2022.06.20 - [IT/Cloud Service] - [NCP 207] VM <-> CDB 통신 문제

[NCP 207] VM <-> CDB 통신 문제

이거를 적다가 ACG / NACL에 대해서 아주 짧게 이야기 했었는데,

어떻게 다른지 비교해보고자 한다.

NCP 에서는 ACG [ Access Control Group ] 이라 하고 AWS에서는 Security Group 이라고 한다.

EC2 / VM / instance 라 불리우는 서버의 방화벽 같은 존재

이 녀석을 이야기 할때 중요한 단어가 있으니 그거슨 stateful 상태저장 이 말을 이해하는 데에는 꽤 오랜 시간이 걸렸는데

알고보면 너무나 단순하고 아 그래서 상태 저장이구나 싶다.

VPC 안에 subnet 을 생성하여 외부로 나가면 public zone 이고 외부로 안나가면 private zone

NACL은 서브넷 안에 있는 모든 인스턴스에서 사용하는 방화벽 같은 존재다. 같은 서브넷 안에 있다면 모두 적용된다

이 녀석을 이야기 할때 중요한 단어가 있으니 그거슨 stateless 상태 비저장 이 말은 stateful [결국 ACG/SG] 만 제대로 이해하면 어렵지 않다.

이제 상태 저장과 비저장에 대해서 이야기 하기에 선행해서 알아야 할 내용이 있다.

웹 서버가 하나 있다. 웹서버는 보통 80 port 를 LISTEN 하게 된다.

이렇게 LISTEN 상태에서 client 가 웹서버에 80 포트로 접근을 시도 한다.

OSI 7 layer 의 L4 전송 계층은 TCP / UDP의 포트 통신을 한다.

이때 사용되는 것이 포트 다.

client 가 웹서버에 80으로 통신을 시도 할때 client 또한 랜덤하게 port 를 사용해야 한다.

단지 OS가 알아서 랜덤하게 사용하기에 사용자 입장에서는 서비스를 제공하는 녀석이 어떤 포트를 사용하는지 정도만 알면 되는 것이다.

물론 웹 서버와 같이 익스플로러, 크롬, 사파리, 파이어폭스 처럼 웹 서버에 접근하기 위해 사용하는 전용 툴은 80 이라는 포트를 안붙여도 알아서 그 포트로 접속해주는 것 일뿐 (이거슨 마치 ssh 로 접속할 때 22라는 포트를 지정하지 않는 것과 같다)

출발지IP:출발지port - 목적지IP:목적지port
client(123.123.123.123):42304 - 웹서버(21.21.21.21):80

여기서 패킷이 들어오는 것을 inbound, 패킷이 나가는 것을 outbound 라고 한다.

그런데 이게 주체에 따라 상대적으로 개념이 작용한다.

웹 서버 입장에서는 80 포트로 패킷이 들어 왔기에 클라이언트의 패킷은 inbound 패킷이 된다.

웹 서버 입장에서 80으로 들어온 패킷에 대해서 클라이어트의 42304(위의 예시를 이렇게 사용하였다) 로 나가는 패킷을 outbound 패킷이라 한다.

클라이언트 입장에서 웹서버로 나간 80포트는 outbound 패킷이고, 웹 서버에서 들어온 42304 포트 패킷은 inbound 패킷이 된다.

그런데 상태 저장이라는 의미가 여기에 중요한 부분이다.

클라이언트에서 웹서버로 들어온 80 포트 인바운드 된 패킷은 그 상태가 저장되어, 그 정보를 기억하고 있다가 나갈때에 특별한 설정 없이 패킷이 아웃바운드 될 수 있다.

즉, ACG / Security Group 을 웹 서버가 사용할 때에는 inbound 로 0.0.0.0/0 80 만 하면 outbound 설정이 없어도 통신에 전혀 문제가 되지 않는다.

반대로 웹서버에서 클라이언트 22번 포트로 접속하는 outbound 패킷이 설정이 되어 있다면 inbound로 들어오는 랜덤한 포트에 대해서는 설정하지 않아도 된다.

NACL은 VPC에서 사용하는 subnet에 사용되는 방화벽이다. 이 녀석은 앞서 설명한 ACG/SG 보다 더 큰 범위에 대해서 접근제어를 한다.

그리고 stateless 다, 상태를 저장하지 않는다. ACG/SG와 반대 라는 것이다.

80 포트로 inbound 처리를 한다해도, 웹서버에서 클라이언트로 나가는 42304 포트에 대해서 outbound 처리를 해줘야 한다.

그런데 앞서도 이야기 했지만, 서비스를 제공하고 있어서 LISTEN으로 사용하고 있는 고정된 포트에 접속하는 클라이언트는 OS에서 랜덤하게 부여받은 포트로 통신을 하게 된다.

NACL을 특정 포트로 고정해서 허용 및 거부를 한다는 것은 매우 어려운 일이다.

그러다 보니 NACL의 outbound는 매우 큰 범위로해서 포트를 지정한다. 자세한 이야기는 하지 않겠지만 이러한 랜덤한 포트 영역은 보통 30000~65535 사이를 사용한다(OS에서 해당 범위는 조절할 수 있다)
(뭐 엄밀히 따져서 ACG/SG 도 outbound에 대해서 랜덤하게 부여 받은 포트이기 때문에 outbound 설정도 범위로 해야할 것 처럼 생각이 되겠지만, 상태를 저장하는 형태이기에 inboud로 정상적으로 들어왔다면 outbound 설정은 의미가 없다.)

NACL과 ACG/SG 가 어쩌면 유사한 기능을 한다.

그럼 둘다 써야 할까? 하나만 써야 할까?

둘다 써도 좋다. 그런데 이걸 한번 생각해보자.

방화벽을 구축하지 않은 환경에서 OS 자체 방화벽을 사용해서 보안을 강화하였다.

그런데 여건이 되어 방화벽을 구축했다고 치자, OS 자체 방화벽을 여전히 사용할 것인가?

NACL도 구성하고 ACG/SG 를 구성하고 운영체제 자체 방화벽까지 구성하였다고 치자.

엄청난 보안성이다. 아주 미묘해서 티도 안나겠지만 3차례에 거쳐가는 step이 생기고 이에 따른 아메바 똥 만한 지연이 발생할 수 있다.

그리고 엄청많은 관리포인트가 생긴다.

네트워크 장애가 발생했을 때 이 관리포인트로 인해 처리하는데 매우 어려움을 겪게 될 것이다.

그렇다면 클라우드 환경에서 최소한의 보안은 무엇일까?

그것은 VM/EC2/instance에서 사용하는 ACG/SG 일 것이다.

그래서 NACL을 선택적 보안 계층이라고 AWS를 말하고 있다.

그래 보안을 강화하려면 쓸테면 쓰라 이거다. 하지만 필수는 아니다.

ACG/SG	NACL
stateful	statelss
허용 정책만 있다(기본적으로 정책이 없다면 거부 된다)	허용과 거부 정책이 있다
instance level 의 접근 제어	subnet level의 접근 제어
	특정 IP를 차단하는데 효과적임
같은 리전내에서 보안 그룹을 참조할 수 있다