성문지기의 마지막 임무: 아웃바운드 통제 🏰👮

By PLURA

🏰옛날, 성문지기의 가장 중요한 일은👮
들어오는 자를 살피는 것이었습니다.

하지만 진짜 위기는
세작이 정보를 품고 다시 ‘나갈 때’ 찾아옵니다.

오늘의 시스템도 같습니다.
우리는 인입을 막는 데 익숙하지만,
유출(아웃바운드) 을 통제하지 못하면 전투는 결국 패합니다.

Protect the Castle

1) 우화로 보는 현실: “들어오는 적보다, 나가는 정보가 더 무섭다”

  • 성문 = 80/443 웹 서비스(정문)
  • 세작 = 웹셸·백도어·권한 탈취 후 설치된 지속화 도구
  • 성문지기의 마지막 임무 = 나가는 사람도 조사해 무기·전리품, 즉 데이터를 확인하는 일

적은 성 안에 들어오는 순간만 노리지 않습니다.
실제로 더 중요한 것은, 그가 무엇을 들고 나가느냐입니다.

침입한 세작은
반드시 밖과 연결하고,
반드시 정보를 내보내고,
반드시 흔적을 남깁니다.

침입한 세작은 정보를 품고 반드시 다시 나갑니다.
따라서 아웃바운드 통제는 인입만큼, 아니 어떤 경우에는 그 이상 중요합니다.

2) 왜 우리는 ‘나가는 트래픽’을 놓치나?

아웃바운드 통제는 중요하다고 말하면서도
현장에서는 자주 뒤로 밀립니다.
그 이유는 대체로 다음과 같습니다.

1. 인증·점검의 사각

많은 제도와 점검 체계가
여전히 인입과 접근통제 중심으로 설계되어 있습니다.
그 결과 아웃바운드 거버넌스는 상대적으로 약합니다.

2. 운영 편의의 유혹

“서버가 외부로 나갈 일도 많다”
“업데이트도 해야 하고 API도 호출해야 한다”
이런 이유로 allow-by-default 습관이 생깁니다.

3. TLS 암호화·클라우드 확산

내용과 목적지가 점점 더 가려진 채
타사 서비스와 클라우드로 트래픽이 흐릅니다.
보이지 않는 통신은 곧 통제 불능이 됩니다.

4. 정량 지표의 부재

세션·사용자·프로세스 단위의
송신량, 속도, 신규 목적지, 반복 주기를
측정하고 경보하는 체계가 부족합니다.

즉, 많은 조직은
“들어오는 것”은 보고 있지만
“나가는 것”은 거의 설명하지 못하는 상태입니다.

3) ISMS-P 2.6.7 해석과 보완 — ‘주요 시스템’에서 DMZ 전체로

기준 요지는 비교적 분명합니다.

“주요 정보시스템(DB 서버 등)에서 불필요한 외부 인터넷 접속을 통제하고,
인터넷 접속 모니터링 정책을 수립·이행한다.”

이 문장은
서버·단말의 아웃바운드 통제를 요구하는 조항으로 해석할 수 있습니다.

하지만 현장에서는 자주 이렇게 좁게 받아들여집니다.

  • “DB 같은 핵심 시스템만 막으면 된다”
  • “웹서버나 API 서버는 어차피 밖으로 나가야 한다”
  • “DMZ는 서비스 구간이니 예외로 두자”

바로 이 해석이 문제입니다.

실제 유출 시나리오의 다수는
DMZ(웹/앱/API/배치/프록시/관리 게이트웨이)에서 시작됩니다.
가장 자주 외부와 통신하는 영역이 DMZ인데,
바로 그 DMZ가 통제 사각이 되면 방어는 무너집니다.

보완 원칙: ‘주요 시스템’이 아니라 ‘DMZ 전체’

  • 대상: DB 등 일부 핵심 시스템 → DMZ 상주 전체 시스템
  • 기본값: Default Deny + Explicit Proxy Mandatory
  • 허용 방식: FQDN/카테고리 기반 허용목록, 직접 80/443 차단
  • 가시성: SNI/FQDN 로깅, 내부 DNS만 허용, DoH/DoT 차단, TLS 종단 위치 명시
  • 상관 분석: 웹 이벤트 ↔ 호스트 프로세스 ↔ 프록시 송신량 급증을 하나의 스토리라인으로 운영

권고 문구(문서용 요약)

“ISMS-P 2.6.7의 ‘주요 정보시스템’을 DMZ 전체로 확장 적용한다.
DMZ는 아웃바운드 기본 거부를 원칙으로 하고,
프록시 경유·FQDN 허용목록·TLS 가시성으로
‘허용은 좁게, 가시성은 넓게’ 설계한다.”

DMZ 아웃바운드 체크(추가)

  • DMZ VLAN/보안그룹에 아웃바운드 기본 거부 적용
  • 프록시 강제 및 직접 인터넷 80/443 차단
  • 업데이트/필수 외부 API 도메인만 허용하고 승인·만료 이력 관리
  • 내부 DNS만 허용, DoH/DoT 차단, SNI/FQDN 로깅
  • TLS 종단 위치를 명시하고, 필요한 범위에서 헤더·본문 검사 가능하도록 설계

한 줄 메시지:
“주요 시스템만 막아서는 부족합니다.
가장 많이 밖으로 나가는 DMZ 전체가 아웃바운드 거버넌스의 주무대입니다.”

4) 공격자는 어떻게 ‘나가나’? — MITRE ATT&CK 맵

공격자는 밖으로 나갈 때
굳이 이상한 프로토콜만 쓰지 않습니다.
오히려 가장 평범한 길을 택합니다.

Exfiltration

  • T1041: 네트워크를 통한 유출
    HTTP(S) POST, Chunked 전송, WebSocket 등
  • T1048: 대체 프로토콜 사용
    ICMP, SMTP, FTP 등
  • T1567: 클라우드 저장소 업로드
    공개 오브젝트 스토리지, 코드 저장소, 협업 서비스 악용

Command & Control

  • T1071: 웹 프로토콜 기반 C2
    정상 서비스 위장, 프론팅, SNI 위장 등

전형적인 패턴은 대개 다음과 같습니다.

웹셸 실행 → 압축/암호화 → 조각내기(작게·자주) → 프록시 또는 정상 서비스로 송신

즉, 나가는 길은
조용하고 정상적으로 보일수록 성공 확률이 높습니다.

5) 실전 원칙 — “Egress Zero Trust”

아웃바운드 통제는
차단 규칙 몇 개 추가하는 문제가 아닙니다.
운영 철학 자체를 바꾸는 일에 가깝습니다.

5.1 정책 3대 원칙

1) 기본 거부(Default Deny)

서버에서 인터넷으로의 직접 통신은
원칙적으로 금지해야 합니다.

2) 프록시 강제(Explicit Proxy)

허용은 도메인/FQDN·카테고리 기반으로
프록시를 통해서만 이루어져야 합니다.

3) 가시성 우선(See Before Allow)

목적지, 콘텐츠, 프로세스 주체를
확인할 수 있는 로그와 검사 체계가 있어야 합니다.

5.2 최소 허용(역할 기반)

역할 기반 아웃바운드 허용 정책은
최소한 다음 수준까지 내려와야 합니다.

웹서버

  • OS/패키지 업데이트 리포지토리만 프록시 경유 허용
  • 승인된 외부 API 도메인만 허용
  • 직접 인터넷 연결 금지

앱서버

  • 내부 DB/캐시/메시지 브로커 우선
  • 인터넷 직접 통신 원칙적 금지
  • 외부 SaaS/API가 꼭 필요하면 도메인 단위 예외 승인

배치/ETL 서버

  • 전용 전송 게이트웨이 또는 전용 프록시만 허용
  • 일반 브라우징 금지
  • 대량 전송은 승인된 목적지와 시간대 기준 통제

관리서버 / Jump Host

  • 외부 접속 허용 가능하되 MFA·세션 기록·명령 감사 필수
  • 일반 운영 서버와 정책 분리
  • 원격 접속 도구와 파일 반출 경로 별도 통제

개발/빌드 서버

  • 패키지 저장소, CI/CD 필수 도메인만 허용
  • 임의 Git/패키지/바이너리 다운로드 차단
  • 서드파티 의존성은 승인된 미러 또는 레지스트리 우선

컨테이너 워커 / 쿠버네티스 노드

  • 이미지 레지스트리, 모니터링, 필수 컨트롤 플레인 통신만 허용
  • Pod 단위 Egress 정책(NetworkPolicy 등) 적용
  • 워커 노드의 직접 인터넷 연결 최소화

백업/복구 서버

  • 백업 저장소 및 복구 테스트 목적지 외 외부 연결 최소화
  • 클라우드 백업은 전용 엔드포인트·전용 계정으로 분리
  • 유출과 백업이 혼동되지 않도록 데이터 흐름 구분

핵심은 단순합니다.

모든 서버가 인터넷에 나갈 이유는 없습니다.
나가야 하는 서버도, 어디로·왜·얼마나 나가는지를 설명할 수 있어야 합니다.

6) 탐지·차단 플레이북 (운영 절차)

A. 네트워크 / 방화벽

  • 서버 VLAN·보안그룹 단위로 아웃바운드 기본 차단 규칙 적용
  • 프록시 강제 리다이렉션 + 직접 80/443 차단
  • 내부 DNS만 허용, DoH/DoT 차단
  • 목적지 FQDN/SNI 로깅
  • 프록시 또는 게이트웨이에서 TLS 종단 위치 명시

B. 호스트 / 프로세스 (EDR/XDR)

  • 웹 프로세스(w3wp, php-fpm, java, nginx 연계 프로세스 등)의 선발신(initiated outbound) 탐지
  • 자식 프로세스 체인(cmd, powershell, rundll32, curl, wget, ssh) 경보 또는 차단
  • 압축·암호화 도구(7z, rar, openssl) 실행 후 대량 파일 접근 + 외부 송신 상관 경보
  • 신규 목적지 연결, 비정상 시간대 송신, “작게·자주” 패턴 탐지

C. 상관·자동화 (SIEM/SOAR/XDR)

  • 스토리라인 규칙: 웹루트 변경 + 비정상 자식 프로세스 + 신규 외부 연결 ⇒ 고위험 티켓
  • 플레이북: 세션 차단 → 파일 격리 → 계정 잠금/비밀번호 재설정 → 증거 보존
  • 사건 타임라인을 웹 ↔ 호스트 ↔ 프록시 로그 기준으로 재구성

힌트: IIS 환경이라면 Sysmon EID 1/3/11/12를 이용해
w3wp.exe의 자식 생성·네트워크 선발신·파일 쓰기를 연결하면
실무 가시성이 크게 올라갑니다.

7) 계측이 없으면 방어도 없다 — 꼭 모아야 할 로그

7.1 웹/프록시

  • 요청/응답 본문 샘플링 또는 필터링 로그
  • 세션·URI·사용자 단위 송신 바이트/초
  • URL·SNI·FQDN·카테고리
  • 허용/차단 사유

7.2 호스트

  • 프로세스 트리 / 명령행 / 실행 사용자
  • 네트워크 목적지 / 포트 / 연결 시간
  • 바이너리 해시
  • 웹루트·민감경로 파일 생성·수정 이벤트

7.3 상관 키

  • 웹 업로드/다운로드 ↔ 호스트 파일 이벤트 ↔ 프록시 송신량 급증
  • 정상 시간대 대비 송신량 편차
  • 신규 목적지 / 신규 프로세스 / 신규 인증 연쇄

8) 운영 체크리스트 ✅

  • 기본 거부 아웃바운드 정책이 적용되어 있다
  • 프록시/게이트웨이 경유만 인터넷 허용, 직접 80/443은 차단되어 있다
  • 내부 DNS만 허용, DoH/DoT 차단 중이다
  • 웹 본문 로그(PII 마스킹·보존정책 포함)를 운영 중이다
  • 웹 프로세스 아웃바운드/자식 프로세스 탐지 규칙이 있다
  • 클라우드 스토리지 업로드 행위와 도메인 카테고리를 감시한다
  • 릴리스·블루/그린·DR 전환 시 보안 룰 동기화 절차가 있다
  • 월간 Egress 리뷰(상위 목적지/신규 목적지/비인가 프로세스)를 수행한다
  • 클라우드 환경에서도 보안그룹/NSG/방화벽의 Egress Drift를 점검한다

9) 클라우드 환경에서는 어떻게 적용할까?

온프레미스보다 클라우드가 더 쉬울 것 같지만,
현실은 반대인 경우가 많습니다.
이유는 빠르게 자원이 늘고, 정책 드리프트가 더 자주 생기기 때문입니다.

AWS

  • Security Group / NACL의 Outbound Rule 최소화
  • 프라이빗 서브넷 우선, NAT 경유 통제
  • VPC Endpoint 우선 사용
  • Route Table과 Proxy 정책 일치 여부 확인

Azure

  • NSG 아웃바운드 룰 최소화
  • Azure Firewall / Proxy 경유 구조 정리
  • Private Endpoint 우선 검토
  • 서비스 태그 남용 방지

GCP

  • Egress Firewall Rule 최소 허용
  • Cloud NAT 경유 구조 명확화
  • Private Google Access와 일반 인터넷 경로 구분
  • 프로젝트/네트워크 단위 Drift 점검

핵심은 같습니다.

클라우드든 온프레미스든
아웃바운드는 허용이 아니라 설명 가능성으로 관리해야 합니다.

10) 현장 스케치(익명화)

사례 A — 웹셸 이후 조용한 유출

DMZ 웹서버에 웹셸이 설치된 뒤,
공격자는 외부 정상 서비스로 작게·자주 데이터를 내보냈습니다.

초기에는 일반 HTTPS 트래픽처럼 보였지만,
나중에 보면 다음이 함께 나타났습니다.

  • 웹 프로세스의 비정상 자식 프로세스 실행
  • 압축 도구 호출
  • 신규 목적지 연결
  • 짧은 간격의 반복 송신

결국 차단은
웹 이벤트 + 호스트 프로세스 + 프록시 송신량을 연결해서 이루어졌습니다.

사례 B — 클라우드 저장소를 이용한 반출

배치 서버가 평소와 다르게
인가되지 않은 외부 클라우드 저장소로 접속했습니다.

처음에는 “업무상 업로드”로 보였지만,
실제 조사 결과는 달랐습니다.

  • 허용 목록에 없는 목적지
  • 승인되지 않은 계정 사용
  • 야간 시간대 대량 송신
  • 직전 권한 상승 이벤트 존재

이 사례는
단순 방화벽 룰보다
역할 기반 허용 정책 + 목적지 분류 + 상관 분석이 더 중요하다는 점을 보여 줍니다.

11) 자주 틀리는 반론과 답변

Q. 아웃바운드를 막으면 운영이 느려집니다.

A. 막는 것이 아니라 경유하게 하는 것입니다.
프록시/게이트웨이로 통로를 좁히고, 보이게 하고, 설명 가능하게 만드는 것입니다.

Q. 개발·배포가 불편해집니다.

A. 역할 기반 허용목록을 IaC와 함께 관리하고,
CI/CD 파이프라인에 도메인 등록·승인 절차를 넣으면 됩니다.

Q. TLS를 종단하면 보안이 약해지지 않나요?

A. 종단·재암호화 설계와 민감정보 마스킹으로 균형을 맞춰야 합니다.
완벽한 비가시성은 보안이 아니라 무지에 가깝습니다.

12) 결론 — 성문지기의 마지막 질문

“그대가 들고 나가는 것은 무엇인가?”

AI 시대의 방어는
아웃바운드를 보는 순간부터 시작됩니다.

문을 보듯 본문을 보고,
성 안의 속삭임을 기록하고,
웹 ↔ 호스트 ↔ 네트워크를
하나의 사건으로 엮어 자동 대응해야 합니다.

인바운드만 보는 보안은
절반의 방어에 불과합니다.

진짜 성문지기의 마지막 임무는
들어오는 적을 막는 것만이 아니라,
나가는 정보와 나가는 세작을 끝까지 확인하는 것입니다.

📖 함께 읽기

PLURA-XDR는 웹 본문 로그와 호스트 감사로그를 상관 분석하고,
아웃바운드 이상 행위를 스토리라인으로 가시화 → 격리 → 증거화합니다.
“들어온 세작”뿐 아니라 나가는 세작을 잡아내는 것이
이제 방어의 핵심입니다.

Tags