NACL 은 왜 Stateless 이고, 보안 그룹은 왜 Stateful 일까?

 

 

AWS VPC 에는 NACL (Network ACL) 과 보안 그룹이라는 방화벽이 있는데

이 친구들은 서로 성격이 다른 방화벽이다.

 

 

AWS 공식 문서 참조

 

 

 

NACL 은

• 결합 기반(허용 및 거부 규칙) 으로 순서대로 규칙을 평가한다.
• 게다가 상태 비저장이라 요청이 들어와도, 나갈 때 다시 한 번 확인한다.

 

보안 그룹은

• 화이트리스트 기반(허용 규칙만 지원) 으로 규칙의 순서는 의미가 없다. (등록만 되어있으면 바로 허용임)
• 상태 저장이라 요청이 한번 들어오거나 나가면, 응답 패킷은 확인하지 않는다.

 

 

같은 방화벽 역할을 하는데도 이 둘은 왜 이렇게 다를까?

 

 

 

처음엔

 

1. NACL 은 서브넷 레벨에서 사용하면 외부 네트워크 또는 인터넷으로 나가는 트래픽이니까
   - 정교하게 Inbound/Outbound 를 검사할 필요가 있음.
2. 하지만 SG 는 인스턴스 레벨에서 사용하니 서브넷 내의 네트워크 통신이 일어날 수 있음.
   - 같은 서브넷에서 굳이 요청/응답을 확인하는 건 불필요한 일이라고 생각.

- 그래서 이렇게 설계해놓은 것 아닐까...? 라고 생각했는데

- 이건 사실 효과에 가깝다고...

- 차라리 "NACL 은 Stateful 할 순 없었을까?" 의 관점으로 생각해보라고...

 

 

 

답은 NACL과 SG 가 동작하는 계층 차이 때문이었다. ! !! !! ! ! ! !

 

NACL 은 네트워크 계층인 3계층에서 동작하고,

SG 는 세션 계층인 4계층에서 동작한다.

 

 

3계층 장비는 라우터로,

라우터는 단지 패킷을 "라우팅"하는 것만 가능하다.

- 패킷의 상태 정보 저장 불가함.

- 그래서 들어온 패킷의 "목적지"가 라우팅 테이블에 없으면 패킷을 버림ㅎㅎ;

 

NACL 은 3계층에서 동작하는 방화벽이고,

목적지 IP 만 확인할 수 있기 때문에 -> Stateful 은 물리적으로 불가능 ㄷㄷㄷㄷ

-> "왜 그렇게 설계했냐" 가 아닌, "이렇게 밖에 못 만듬" 인 것이다....

 

 

4계층 장비는 세션 장비로, 로드밸런서와 (우리가 아는 일반적인?)방화벽도 여기서 동작한다.

4계층 부터는 TCP 프로토콜과 세션을 사용하기 때문에 세션 테이블에 "상태 정보를 저장" 가능하다.

 

 

 

그럼 결론은 뭐다?

"이렇게 밖에 안 돼서 이렇게 만든 건데요..?" <<<< 이거였음 ㄷㄷㄷㄷㄷㄷㄷㄷ ㄷ ㄷㄷ ㄷ

 

 

 

내가 썼던 보안 문제도

NACL 은 서브넷 레벨에서 동작하니 -> 일단 해당 서브넷에서 허용하거나 불허하는 트래픽을 1차로 걸러낸 후 -> 그 중에서도 인스턴스마다 허용되는 IP 를 SG 로 2차로 거름 : "대규모 트래픽에 유리하고 쓸데없이 두번 거를 필요 없음"

이라고 생각했던 것도

 

전부

"이렇게 밖에 만들어질 수 없는 조건" 때문에 오는 부가적인 효과 였음 ㄷㄷㄷㄷㄷ

 

 

 

 

정말 정말 놀라움..

여기서 하나 교훈을 얻었는데 그건 바로

 

"내가 이런 것 밖에 할 수 없어도 결국 다 쓰임이 있고 이유가 있음."

 

 

결국..

모든 건 다 일어나는 이유가 있는 것이고...

내가 이것밖에 못한다고 해서 무력감에 너무 슬퍼하거나 힘들어 할 필요가 없다는 것임ㄷㄷㄷ.ㄷㄷㄷㄷㄷㄷ!!!!!!

 

 

NACL 은 Stateful 할 수 없지만

대신 대규모 트래픽을 1차 걸러낼 수 있고

또 인바운드 아웃바운드 검사를 둘 다 강제로 해야만 하니까 보안에 도움이 됨.ㄷㄷㄷ

 

SG 는 NACL 에서 한번 거른 트래픽이 있으니

진짜 믿을만한(?) 허용된 트래픽만 검사할 수 있음..!!

 

 

 

진짜 대단한 사실임...엄청나고 대단한 이슈임..!!!!!!

이걸 세상 사람들이 전부 전부 알게 되면 조을 텐데...