온프레미스 DDoS 시대는 끝났다

PLURA

🛑 이제 온프레미스에서 DDoS를 막는 시대는 끝났습니다.

DDoS(분산 서비스 거부 공격)는 볼륨을 앞세운 대규모 트래픽(Volumetric)부터 애플리케이션 계층(L7) 공격까지 다양해지며, 주요 타겟은 웹 서비스가 되고 있습니다. 공개된 웹 서비스는 본질적으로 외부 트래픽을 받아야 하므로, 온프레미스에서 이를 전부 막아내기에는 물리적·비용적 한계가 더욱 커지고 있습니다.

✅ 결론부터 말하면, 대고객용 서비스(External-Facing)는 퍼블릭 클라우드로 전환하고, 내부 서비스(Internal-Facing)는 별도 망과 정책으로 철저히 분리해야 합니다. 클라우드 사업자가 보유한 대규모 DDoS 방어 인프라와 글로벌 CDN, 그리고 내부 망의 구조적 분리를 통해 공격이 아예 도달하지 못하게 설계하는 것이 핵심입니다.

DDoS, 온프레미스 방어의 한계

1. DDoS는 웹 서비스를 노린다.

DDoS 공격은 아래 두 가지 축으로 크게 나눌 수 있습니다.

  1. 볼륨 기반(Volumetric) 공격: 대규모 트래픽을 전송하여 네트워크 대역폭을 고갈시키거나 서버를 과부하 상태로 만들기.
  2. 애플리케이션 계층(L7) 공격: HTTP(S), DNS, API 요청 등을 악용해 상대적으로 적은 트래픽으로 서버 리소스를 점진적으로 소모시키기.

이 두 종류 모두 공개된 IP와 URL을 보유한 웹 서비스를 중심으로 발생합니다.
💡 즉, DDoS 방어의 핵심은 ‘누구나 접근 가능한 웹 서비스를 어떻게 보호할 것인가?’입니다.

2. 온프레미스 DDoS 방어의 한계

온프레미스에 자체 방어 장비(방화벽, IPS, DDoS 전용 장비 등)를 두고 막으려면, 다음 문제가 발생합니다.

  • 대규모 트래픽에 대한 물리적·회선적 한계: 공격량이 커지면 결국 ISP 측에서 트래픽을 차단하거나, 기업 회선 대역이 고갈되어 정상 트래픽도 제대로 받기 어려움.
  • 비용·운영 부담: 고성능 하드웨어나 라이선스 비용이 높고, 유지·관리에 드는 인력도 상당함.
  • 복합 공격(Volumetric + L7)이 지속될 경우 방어 장비가 오히려 병목(Bottleneck)이 되어 전체 서비스를 마비시킬 위험.

💡 따라서, 대고객 서비스를 위한 대규모 볼륨 방어는 클라우드에 위임하고, 내부 서비스와 외부 서비스를 물리·논리적으로 분리하는 것이 필수적입니다.

3. DDoS 대응 전략: 클라우드 기반·네트워크 분리

아래 원칙에 따라 방어 전략을 수립하면, 대규모 공격이라도 온프레미스로 유입되지 않도록 차단할 수 있습니다.

🛠 (1) 대고객용 서비스는 퍼블릭 클라우드에서 제공

  • Oracle OCI, AWS, Azure, GCP 등 글로벌 클라우드 사업자는 Anycast 기반의 대규모 DDoS 방어 인프라를 이미 갖추고 있습니다.
  • Naver Cloud의 DDoS 방어 시스템도 검토할 수 있습니다.
  • Cloudflare, Akamai, AWS Shield 등 전용 DDoS 보호 서비스를 통합 활용하면 공격 트래픽이 온프레미스까지 도달하기 전에 차단됩니다.
  • CDN(Content Delivery Network)을 적극 도입하여, 공격자가 특정 서버 IP를 직접 공격할 수 없도록 우회/캐시 구조를 만듭니다.

🔥 (2) 내부에서 대고객용 웹 서비스를 직접 운영하지 않는다

  • 온프레미스에서 웹 서버를 운영하면, 해당 서버가 가장 앞단에서 공격을 받게 되는 최전선이 됩니다.
  • 내부 데이터센터는 백엔드 API 서버, 내부 관리 시스템, 협업 시스템 등을 중심으로 두고, 외부 공개 웹 서비스는 클라우드로 이전하세요.

🛡 (3) 온프레미스에 남겨진 서비스는 ISP 협업과 Null Routing으로 보완

  • 일부 서비스나 특정 레거시 시스템을 완전히 클라우드로 이전하기 어려운 상황이라면, ISP(인터넷 서비스 제공자)와 협업하여 공격 발원 IP를 Null Routing으로 처리할 수 있습니다.
  • 단, Null Routing은 정상 트래픽까지 우발적으로 차단될 수 있으므로, 공격 패턴·소스 IP를 정확히 식별하는 관제(모니터링)가 필수입니다.

🔒 (4) 방화벽 정책을 ‘기본 차단(Default Deny)’으로 운영

  • 수신(Inbound) 트래픽은 기본적으로 차단하고, 반드시 필요한 서비스(포트)만 예외적으로 오픈합니다.
  • SSH, RDP 등 관리 포트는 VPN 등 내부 전용 경로를 통해서만 접근하도록 하는 Zero Trust 방식이 권장됩니다.

4. 네트워크 아키텍처 변화: 단순화와 분리

DDoS를 막으려면, 단순히 클라우드 이전만이 아니라 전체 네트워크의 아키텍처도 ‘서비스 분리’ 중심으로 개편해야 합니다.

🌐 (5) 고객용 서비스망과 내부 네트워크 완전 분리

  • VLAN/VXLAN, 물리적 네트워크 분리, Zero Trust Network Architecture(ZTNA) 적용 등을 고려해 외부 트래픽이 내부 시스템에 직접 닿지 못하도록 설계합니다.
  • 고객 트래픽은 클라우드(CDN·WAF) → 내부망 경로로 한정해서 들어오게 하며, 외부 IP가 직접 내부 서비스 서브넷으로 접근하는 경우가 없게끔 합니다.

📌 (6) 방화벽 및 보안 장비 룰을 단순화(100개 이하 관리 지향)

  • 정책이 복잡해질수록 정책 충돌 및 관리 실수가 잦아집니다.
  • 외부 공개 서비스와 내부망을 분리하면, 각 방화벽(또는 보안 그룹) 룰셋을 훨씬 단순화하여 관리하기 쉬워집니다.

🏗 (7) 중요도별 네트워크 분리로 DDoS 파급 최소화

  • 중요 시스템(데이터베이스, 주요 서비스 등)과 비교적 중요도가 낮은 시스템(테스트 서버 등)을 서로 다른 서브넷·VPC로 격리해 두면, 특정 서브넷이 공격받더라도 다른 곳으로 확산되는 것을 막을 수 있습니다.
  • 외부에 노출해야 하는 서비스라도, 별도 네트워크 세그먼트로 구성해 메인 인프라와 논리적으로 차단하는 방식이 필요합니다.

5. 하이브리드·규제 준수 환경을 위한 고민도 필요

일부 금융·공공·제조업 등은 규제나 데이터 주권 문제로 인해 모든 서비스를 퍼블릭 클라우드로 옮기기 어려울 수 있습니다. 이 경우에도 공개 서비스 트래픽을 최대한 클라우드 Scrubbing Center나 CDN을 통해 우선 필터링하고, 정제된 트래픽만 온프레미스로 전달하는 하이브리드 방식을 고려할 수 있습니다.

  • 클라우드 기반 DDoS Scrubbing + 전용 선로를 통한 트래픽 전달
  • On-prem WAF와 Cloud WAF를 이중화해 공격을 순차적으로 걸러내기

이러한 방식으로도 대규모 트래픽이 바로 사내망에 유입되지 않게 설계하는 것이 핵심입니다.

6. 결론: ‘온프레미스 DDoS 방어’만으로는 부족하다

💡 이제 DDoS는 단순한 대역폭 소모를 넘어 L7까지 파고들며 계속 진화하고 있습니다. 이를 온프레미스에서만 전부 막으려다 보면 비용·운영 부담이 폭증하고, 공격 규모가 커지면 결국 대역 자체가 마비될 수밖에 없습니다.

✅ DDoS 대응 전략 요약

  1. 대고객 서비스(External-Facing)는 퍼블릭 클라우드에서 운영
  2. 내부 시스템과 외부 서비스를 망·정책적으로 완전히 분리
  3. 이전이 어려운 온프레미스 서비스는 Null Routing, ISP 협업, 하이브리드 스크러빙
  4. 방화벽 정책은 Default Deny(거부) 원칙
  5. 네트워크 아키텍처는 단순화하고, 중요도별로 격리
  6. 규제·컴플라이언스 이슈가 있다면, 하이브리드 클라우드 기반의 DDoS Scrubbing Center 고려

⏳ 공격은 끊임없이 진화하지만, 방어 전략도 발 빠르게 변화해야 합니다. ‘온프레미스 DDoS 방어’라는 과거 방식에만 의존하기보다는, 클라우드의 대규모 방어 인프라 + 네트워크 단순화·분리가 새로운 표준이 되어야 합니다.

📖 함께 읽기

Tags