온프레미스 DDoS 시대는 끝났다
🛑 이제 온프레미스에서 DDoS를 직접 막는 시대는 사실상 끝났습니다.
DDoS(분산 서비스 거부 공격)는
대규모 트래픽을 앞세운 볼륨 공격에서,
애플리케이션 계층(L7) 공격까지 빠르게 진화해 왔습니다.
특히 오늘날 공격의 주요 표적은
대부분 공개 웹 서비스입니다.
공개된 웹 서비스는 본질적으로 외부 요청을 받아야 합니다.
즉, 공격 표면을 완전히 닫을 수 없습니다.
그래서 핵심 질문은 바뀌어야 합니다.
“온프레미스 장비로 어떻게 다 막을까?”
가 아니라
“어떻게 공격이 우리 온프레미스까지 도달하지 못하게 설계할까?”
✅ 결론부터 말하면, 대고객용 서비스(External-Facing)는 퍼블릭 클라우드 기반으로 운영하고, 내부 서비스(Internal-Facing)는 별도 망과 정책으로 철저히 분리해야 합니다.
클라우드 사업자가 보유한 대규모 DDoS 방어 인프라와 글로벌 CDN, 그리고 내부망의 구조적 분리를 통해 공격이 온프레미스까지 도달하기 전에 흡수되도록 설계하는 것이 핵심입니다.
1. DDoS는 이제 거의 항상 ‘웹 서비스’를 노립니다
오늘날 DDoS는 크게 두 축으로 나눌 수 있습니다.
1) 볼륨 기반(Volumetric) 공격
대규모 트래픽을 한꺼번에 밀어 넣어
네트워크 대역폭, 라우터, 방화벽, 로드밸런서를 먼저 마비시키는 방식입니다.
2) 애플리케이션 계층(L7) 공격
HTTP(S), DNS, API 요청 등을 악용해
상대적으로 적은 트래픽으로도 웹서버, 애플리케이션 서버, 백엔드 리소스를 서서히 소모시키는 방식입니다.
예를 들면 다음과 같습니다.
- 로그인 페이지 반복 요청
- 검색 API 과호출
- 비싼 연산을 유도하는 쿼리 반복
- Bot 기반 정상 사용자 위장
- 캐시 미스 유도
- 동적 페이지 집중 타격
즉, 공격량이 많지 않아도
서비스가 실제로 느려지고 장애가 나는 구조를 만들 수 있습니다.
💡 그래서 DDoS 방어의 핵심은
결국 누구나 접근 가능한 웹 서비스를 어떻게 보호할 것인가입니다.
2. 왜 온프레미스 DDoS 방어는 한계에 부딪히는가
온프레미스에
방화벽, IPS, DDoS 전용 장비, 로드밸런서를 두고
직접 막으려는 방식은 여전히 많이 사용됩니다.
하지만 이 방식은 구조적으로 한계가 있습니다.
1) 물리적·회선적 한계
공격량이 커지면
장비 성능보다 먼저 회선 자체가 포화됩니다.
이 경우 장비가 살아 있어도
정상 트래픽 자체가 들어오지 못합니다.
2) 비용과 운영 부담
고성능 네트워크 장비, 전용 DDoS 장비, 라이선스, 우회 회선, 전문 인력까지 감안하면
온프레미스 단독 방어는 매우 비쌉니다.
3) 복합 공격에 취약
현실의 공격은 종종
볼륨 공격 + L7 공격 + Bot 우회 + 지역 분산을 함께 사용합니다.
이 경우 방어 장비가 오히려 병목이 되어
서비스 전체를 느리게 만들거나 마비시킬 수 있습니다.
4) 공개 서비스가 최전선이 됨
온프레미스에서 웹 서비스를 직접 운영하면
그 서버와 회선이 공격의 최전선에 서게 됩니다.
즉, 공격이 클라우드에서 흡수되는 것이 아니라
우리 인프라가 직접 충격을 받는 구조가 됩니다.
따라서 대고객 웹 서비스를 온프레미스에서 직접 끝까지 버티겠다는 전략은
점점 더 비효율적이고 비싸며 위험해지고 있습니다.
3. 대응 전략의 핵심 — 클라우드 기반 + 네트워크 분리
현실적인 전략은
“온프레미스 장비를 더 사는 것”보다
아예 공격 경로를 바꾸는 것에 가깝습니다.
🛠 1) 대고객용 서비스는 퍼블릭 클라우드에서 제공
- OCI, AWS, Azure, GCP 같은 글로벌 클라우드 사업자는
이미 Anycast 기반의 대규모 분산 방어 인프라를 갖추고 있습니다. - Cloudflare, Akamai, AWS Shield 같은 전용 보호 서비스를 결합하면
공격 트래픽은 온프레미스에 닿기 전에 먼저 걸러질 수 있습니다. - CDN을 적극 도입하면
공격자가 원 서버 IP를 직접 겨냥하기 어렵게 만들 수 있습니다.
즉, 중요한 것은
“잘 막는 장비를 두는 것”보다
공격을 받아도 버틸 수 있는 규모의 앞단을 두는 것입니다.
🔥 2) 내부에서 대고객용 웹 서비스를 직접 운영하지 않는다
온프레미스에서 공개 웹 서버를 직접 운영하면
그 서버가 항상 공격의 첫 번째 타격점이 됩니다.
더 안전한 구조는 다음과 같습니다.
- 외부 공개 웹 서비스: 클라우드
- 내부 데이터, 핵심 시스템, 관리 시스템: 온프레미스 또는 별도 보호망
- 외부에서 내부로 들어오는 경로: 최소화
- 내부에서 외부로 나가는 경로: 통제
즉,
온프레미스는 더 이상 “인터넷 정면”에 서 있지 않아야 합니다.
🛡 3) 온프레미스에 남아야 하는 서비스는 ISP 협업과 Null Routing으로 보완
모든 것을 당장 클라우드로 옮길 수 없는 경우도 많습니다.
이럴 때는 다음이 필요합니다.
- ISP와의 사전 협업 체계
- 공격 발원·목적지에 대한 신속한 Null Routing
- 우회 회선 또는 스크러빙 센터 연계
- 정상 트래픽 피해를 최소화하는 관제 체계
단, Null Routing은
정상 트래픽까지 함께 끊을 수 있기 때문에
임시 응급 처치에 가깝습니다.
그래서 가장 중요한 것은
사전에 어떤 서비스는 어디서 흡수하고, 어디서 차단하고, 어디서 우회할 것인지를 정해 두는 것입니다.
🔒 4) 방화벽 정책은 Default Deny를 기본으로
온프레미스에 남아 있는 서비스는
더 엄격한 정책이 필요합니다.
- 수신(Inbound) 기본 차단
- 필요한 포트만 예외 오픈
- SSH, RDP, 관리 포트는 VPN 또는 전용 관리망을 통해서만 접근
- 외부에서 내부 서비스 서브넷으로 직접 접근 불가
즉,
클라우드 앞단으로 공개 서비스를 옮긴 뒤에는
온프레미스 정책을 더 단순하고 보수적으로 가져갈 수 있어야 합니다.
4. DDoS 방어의 무게중심은 이제 L3/L4 장비만이 아니라 L7 운영으로 이동합니다
많은 조직이 DDoS를 여전히
“대역폭 문제”로만 생각합니다.
하지만 현실에서는
L7 계층의 서비스 소진형 공격이 훨씬 더 골치 아픈 경우가 많습니다.
왜 L7이 더 어려운가
- 정상 브라우저처럼 보임
- 트래픽 총량이 크지 않을 수 있음
- Bot이 실제 사용자 행동을 흉내 냄
- 캐시를 피하고 동적 요청만 노림
- 로그인, 검색, 결제, API를 골라 공격
그래서 필요한 것
- WAF의 L7 룰 최적화
- Bot 관리
- Rate Limiting
- Challenge/JS Challenge/CAPTCHA
- API Gateway와 인증·쿼터 설계
- 캐시 전략
- 백엔드 리소스 보호
- 애플리케이션 레벨의 타임아웃/쿼리 제한
즉, DDoS는 더 이상
네트워크팀만의 문제가 아닙니다.
클라우드, WAF, CDN, 앱 아키텍처, API 설계, 보안팀이 함께 다뤄야 하는 운영 문제가 되었습니다.
5. 네트워크 아키텍처는 더 단순하고 더 분리되어야 합니다
DDoS를 잘 막는 조직은
장비가 많아서가 아니라
구조가 단순합니다.
🌐 1) 고객용 서비스망과 내부망의 완전 분리
- 고객 트래픽은 클라우드/CDN/WAF를 거쳐서만 들어오게 설계
- 내부 서비스 서브넷은 외부에 직접 노출되지 않도록 구성
- 외부 공개 시스템과 내부 핵심 시스템의 신뢰 관계를 최소화
📌 2) 방화벽과 보안그룹 룰 단순화
정책이 많아질수록
충돌과 운영 실수가 늘어납니다.
그래서
외부 공개망과 내부망을 분리한 뒤
룰은 가능한 한 짧고 단순하게 유지해야 합니다.
룰 100개 이하 관리 지향 같은 원칙은
실제 운영에서 매우 유용할 수 있습니다.
🏗 3) 중요도별 네트워크 격리
- DB, 인증, 핵심 업무 시스템
- 고객 서비스 구간
- 테스트/개발 구간
- 운영 관리 구간
이런 식으로 중요도에 따라 분리하면
특정 구간이 공격받더라도 전체 확산을 줄일 수 있습니다.
6. 하이브리드·규제 준수 환경에서는 어떻게 해야 할까
일부 금융·공공·제조업은
규제, 데이터 주권, 산업 특성 때문에
모든 서비스를 퍼블릭 클라우드로 옮기기 어렵습니다.
이 경우에도 결론은 크게 다르지 않습니다.
핵심은
공격 트래픽을 최대한 앞단에서 먼저 정제한 뒤, 정제된 트래픽만 내부로 들이는 것입니다.
예를 들어:
- 클라우드 기반 DDoS Scrubbing Center 사용
- 전용선 또는 터널을 통한 정제 트래픽 전달
- Cloud WAF + On-prem WAF 이중화
- 외부 트래픽은 클라우드에서 먼저 흡수, 내부는 최소 표면만 유지
- 중요 데이터는 온프레미스에 남기되, 공개 서비스는 별도 보호 계층에서 운영
즉, 하이브리드 환경에서도
“온프레미스가 정면으로 맞는다”는 구조만 피하면 됩니다.
이 환경에서 특히 중요한 질문
- 어디까지를 외부 공개 구간으로 둘 것인가
- 어디서 TLS를 종단할 것인가
- 어떤 구간에서 Scrubbing을 적용할 것인가
- 어떤 데이터는 절대 클라우드 밖으로 못 나가게 할 것인가
- 클라우드와 온프레미스 간 신뢰 경계를 어떻게 줄일 것인가
이 질문에 답하지 못하면
하이브리드는 전략이 아니라 단순 혼합 상태가 됩니다.
7. 그래서 실무적으로 무엇을 해야 하나 — 현실 점검 항목
아래는 보안 아키텍트와 인프라 팀이
실제로 바로 점검해 볼 수 있는 질문들입니다.
공개 서비스 구조
- 대고객 웹 서비스가 여전히 온프레미스 최전선에 있는가
- CDN/WAF/DDoS 보호 계층이 앞단에 있는가
- 원 서버 IP가 직접 노출되지 않도록 설계되었는가
네트워크 분리
- 고객용 서비스망과 내부 관리망이 분리되어 있는가
- 외부에서 내부 서브넷으로 직접 접근 가능한 경로가 없는가
- 관리 포트는 전용 경로를 통해서만 접근 가능한가
L7 대응
- 로그인/API/검색 등 고비용 요청에 대한 Rate Limit가 있는가
- Bot 관리 또는 비정상 자동화 요청 제어 체계가 있는가
- WAF 룰이 단순 OWASP 차단을 넘어 API/L7 운영 특성을 반영하는가
운영 체계
- ISP와 Null Routing 또는 긴급 대응 절차가 사전 정의되어 있는가
- Scrubbing Center 연계 여부가 검토되었는가
- 공격 시 의사결정 기준(우회, 차단, 축소 운영)이 문서화되어 있는가
8. 결론: 온프레미스 DDoS 방어만으로는 더 이상 충분하지 않습니다
💡 지금의 DDoS는 단순한 대역폭 공격이 아니라, 웹과 API를 겨냥한 운영 파괴 공격으로 진화했습니다.
이것을 온프레미스에서만 끝까지 막겠다는 접근은
점점 더 비싸고, 복잡하고, 취약해집니다.
다시 정리하면
- 대고객 서비스는 퍼블릭 클라우드 앞단에서 보호
- 내부 서비스는 외부와 망·정책적으로 분리
- 온프레미스에 남은 서비스는 Scrubbing, ISP 협업, Null Routing으로 보완
- 방화벽 정책은 Default Deny
- 아키텍처는 단순화하고 중요도별로 격리
- 하이브리드 환경도 ‘정제 후 유입’ 원칙으로 설계
결국 중요한 것은
온프레미스 장비를 더 늘리는 것이 아니라,
공격이 온프레미스까지 도달하지 못하게 하는 구조를 만드는 것입니다.
⏳ 공격은 계속 진화합니다.
방어 전략도 과거 방식에 머물러 있을 수 없습니다.
이제 표준은
“온프레미스에서 버틴다”가 아니라,
클라우드의 대규모 방어 인프라를 활용하고,
내부망은 더 좁고 단순하고 분리된 구조로 설계하는 것
입니다.
그 점에서
온프레미스 DDoS 시대는 끝났습니다.