アウトバウンドを開けたのになぜ通らないのか

한 줄 요약

보안그룹은 상태를 기억하고(stateful), NACL 은 기억하지 않습니다(stateless). 이 한 가지 차이에서 나머지 모든 차이가 나옵니다.

왜 이게 필요했나

보안그룹에서 인바운드 80만 열어 두면 응답은 알아서 나갑니다. 요청이 들어온 것을 기억했다가 그 응답을 자동으로 허용하기 때문입니다.

NACL 은 다릅니다. 들어온 것을 기억하지 않으므로, 응답이 나가는 것도 따로 허용해야 합니다. 그리고 응답은 임시 포트(1024~65535)로 나가므로 그 범위를 아웃바운드에 열어야 합니다.

이걸 모르면 "인바운드는 열었는데 응답이 안 온다" 는 현상을 몇 시간 봅니다.

나란히 놓고 보기

	보안그룹	네트워크 ACL
적용 대상	인스턴스(ENI)	서브넷 전체
상태	저장 — 응답 자동 허용	비저장 — 양방향 각각 필요
규칙	허용만	허용 + 거부
평가	모든 규칙을 본 뒤 허용 하나면 통과	번호 순서대로, 처음 맞는 규칙 적용
기본값	인바운드 전부 차단, 아웃바운드 전부 허용	기본은 전부 허용
개수	인스턴스당 여러 개 적용 가능	서브넷당 하나

NACL 의 순서 규칙이 만드는 함정

번호  타입      동작
100   전체      ALLOW
200   TCP 22    DENY      ← 절대 적용되지 않는다

100번에서 이미 허용되어 끝났기 때문에 200번은 볼 일이 없습니다. 보안그룹처럼 "거부가 우선" 이 아닙니다. 번호가 작은 것부터, 처음 맞는 규칙에서 끝입니다.

그래서 NACL 규칙 번호는 100, 200, 300 처럼 띄어서 매깁니다 — 나중에 사이에 끼워 넣을 자리를 남기기 위해서입니다.

보안그룹의 강력한 기능 — 그룹 참조

보안그룹 규칙의 출발지에 다른 보안그룹을 지정할 수 있습니다.

DB 보안그룹 인바운드:
  5432 ←  sg-app  (앱 서버 보안그룹)

IP 를 쓰지 않았다는 점이 중요합니다. 앱 서버가 몇 대든, 오토스케일링으로 늘고 줄든, IP 가 바뀌든 규칙을 고칠 필요가 없습니다. 역할로 규칙을 쓰는 것이라 클라우드에서 가장 실용적인 패턴입니다.

어떻게 나눠 쓰나

실무에서는 대개 이렇게 정리됩니다.

• 보안그룹을 주력으로 씁니다. 세밀하고, 그룹 참조가 되고, 실수가 적습니다.
• NACL 은 서브넷 전체에 거는 넓은 가드레일로만 씁니다. 예: 특정 악성 IP 대역 차단, 데이터 서브넷에서 인터넷으로 나가는 것 자체를 봉쇄.

NACL 로 세밀한 제어를 하려 들면 임시 포트와 순서 규칙 때문에 곧 엉킵니다.

흔한 실수 다섯 가지

1. 0.0.0.0/0 에 22번(SSH) 개방 — 스캐너가 몇 분 안에 찾습니다.
2. 아웃바운드를 전부 열어 둠 — 침해 후 데이터 반출 경로가 됩니다.
3. NACL 에서 임시 포트 아웃바운드를 안 열어 응답이 막힘.
4. NACL 규칙 번호를 1, 2, 3 으로 붙여 나중에 끼워 넣을 자리가 없음.
5. 보안그룹 설명(description)을 안 적어 6개월 뒤 아무도 이유를 모름.

5번이 의외로 아픕니다. 지워도 되는지 알 수 없어서 규칙이 계속 쌓입니다.

현장에서 만나는 모습

• 인바운드는 되는데 응답이 안 옴 → NACL 아웃바운드 임시 포트.
• 오토스케일링 후 DB 접속 실패 → IP 로 규칙을 썼다. 그룹 참조로 바꿔야 한다.
• 보안그룹이 40개까지 늘어남 → 정리 기준이 없었다. 설명을 필수로.

규칙이 늘어나는 것을 막는 방법

앞에서 보안그룹이 40개까지 늘어난 사례를 들었다. 이것은 게으름의 문제가 아니라 지울 근거를 만들지 않은 구조의 문제다. 몇 가지 규칙만 처음에 정해 두면 이 상태에 도달하지 않는다.

이름과 설명을 형식으로 강제한다. 어떤 서비스의 어떤 역할인지가 이름에서 읽히고, 규칙마다 왜 열었는지와 언제까지 필요한지가 설명에 적혀 있으면, 6개월 뒤에 지울지 말지를 판단할 수 있다. 설명이 비어 있으면 만들지 못하게 검사에서 막는 편이 낫다.

역할로 쓰고 주소로 쓰지 않는다. 그룹 참조를 쓰면 규칙 수가 자원 수와 무관해진다. 반대로 IP 로 쓰기 시작하면 서버가 늘 때마다 규칙이 늘고, 서버가 사라져도 규칙은 남는다. 어느 날 그 주소를 다른 사람이 쓰게 되면 의도치 않은 접근이 열리는 것도 IP 규칙의 위험이다.

임시로 연 것에 만료를 적어 둔다. 조사를 위해 잠시 여는 일은 늘 있다. 그때 설명에 날짜를 적는 규칙만 있어도, 나중에 만료가 지난 규칙을 기계적으로 뽑아낼 수 있다.

정기적으로 실제로 쓰이는지 본다. 흐름 로그를 켜 두면 어떤 규칙으로 실제 트래픽이 지나갔는지 알 수 있다. 몇 달간 한 번도 쓰이지 않은 허용은 지울 후보다.

그리고 규칙을 손으로 고치지 않는 것이 이 모든 것의 전제다. 콘솔에서 급하게 연 규칙은 코드에 없으므로 다음 배포에서 사라지거나, 반대로 코드와 실제가 어긋난 채로 남는다. 어느 쪽이든 나중에 "이 규칙이 왜 여기 있지" 를 아무도 답하지 못하는 상태로 이어진다.

다음에 볼 것

프라이빗 자원이 밖으로 나가는 세 가지 길과 각각의 값.