MINI PROJECT · CDN·웹 보안 적용

장하영

제품을 먼저 경험하고, 고객의 언어로 전하는 영업

고객에게 설명하기 전에, 고객이 도입할 때와 같은 순서로 CDN·웹 보안 서비스를 직접 적용해 보았습니다. Cloudflare로 구성하고, 실제 유입된 공격을 분석한 결과를 이 페이지에 담았습니다.

요약

3개직접 설계한 WAF 규칙
1,440건연결 후 하루 동안 유입된 요청
원본 보호차단된 요청은 원본 서버에 도달하지 않음

2026.10.12 – 10.13 · AWS Route 53 · GitHub Pages · Cloudflare Free

구성

기존 서버는 그대로 두고, 앞에 보안 계층을 한 겹 얹었습니다.

적용 전: 방문자 → Fastly → GitHub Pages. 적용 후: 방문자 → Cloudflare → Fastly → GitHub Pages
적용 전후 구성도

알게 된 것

1. 위험은 연결되는 순간부터 시작됩니다

주소를 알리지 않은 이 사이트에, 연결 다음 날 새벽 한 해외 IP가 1~2초 사이 서버 비밀번호와 API 키가 담긴 설정 파일(.env, .ssh, .terraform 등)을 연달아 찾았습니다. 로그를 근거로 숨김 파일 경로를 막는 규칙을 추가하고, 인증서 발급에 쓰이는 /.well-known/ 경로는 예외로 두어 정상 동작까지 확인했습니다.

민감 파일 스캔 요청 로그
민감 파일 스캔 요청 로그 (IP 일부 가림)

2. "빨라집니다"는 항상 맞는 말이 아닙니다

적용 전 응답 헤더를 보니, 원래 서버는 이미 다른 CDN(Fastly)을 거쳐 서비스되고 있었습니다. Cloudflare를 연결한 뒤 얻은 것은 속도가 아니라 보안 규칙, 차단 기록, SSL 정책에 대한 통제권이었습니다. 이미 CDN을 쓰는 고객이라면, 대체할지 보안 계층으로만 더할지부터 함께 정해야 한다는 것을 배웠습니다.

직접 확인해 보세요

  1. 이 페이지는 Cloudflare를 거쳐 전달되고 있습니다. 개발자 도구(F12) → Network → 새로고침 → 응답 헤더에서 server: cloudflare와 cf-ray를 확인할 수 있습니다. style.css를 선택하면 두 번째 새로고침부터 cf-cache-status: HIT가 보입니다.
  2. 제가 만든 차단 규칙이 동작합니다. hayoung.dev/admin에 접속하면 원본 서버에 닿기 전에 Cloudflare가 요청을 차단합니다. 차단 화면 아래의 Ray ID로 어떤 규칙에 걸렸는지 추적할 수 있습니다.