클라우드·상용으로 같은 그림 그리기

아프로·2026년 10월 30일

해킹 시도를 몇 초 안에 잡는 서버: 실시간 탐지·차단 실전

목록 보기

12/18

클라우드·상용으로 같은 그림 그리기 표지

직접 만드는 대신 사서 쓰면 어떨까요? 방어선 2(엣지)는 상용 서비스가 훨씬 잘합니다. 전 세계 트래픽을 보고 봇 점수를 매기는 일은 혼자서 할 수 없습니다. 하지만 방어선 0과 방어선 1의 핵심, "이 주문의 주인이 이 사용자인가"는 어떤 제품도 대신 알아 주지 않습니다. 이번 글은 대표 제품 셋을 네 방어선에 놓아 봅니다. 모든 내용은 2026-10-30에 공식 문서로 확인했고, 요금제와 기능은 자주 바뀌니 도입 전에 다시 확인하세요.

한 장 지도

Cloudflare, AWS, Datadog을 방어선 0~3에 놓은 대응표

Cloudflare: 엣지를 통째로

WAF 관리형 규칙. 무료 관리형 규칙 묶음은 모든 요금제에 있습니다. Cloudflare 관리형 규칙과 Cloudflare OWASP Core Ruleset(OWASP CRS를 Cloudflare가 구현한 것, 누적 위협 점수를 기준값과 비교)은 Pro 이상입니다.

속도 제한 규칙. 요금제마다 차이가 큽니다.

요금제	규칙 수	무엇으로 세나	최대 기간
Free	1	IP	10초
Pro	2	IP	1분
Business	5	IP, NAT를 고려한 IP	10분
Enterprise	100	IP, NAT를 고려한 IP	65,535초
Enterprise + Advanced Rate Limiting	100	쿼리, 헤더, 쿠키, ASN, 경로, JA3/JA4, JSON 필드 등	65,535초

이 시리즈의 주장인 "신원 기준으로 세라"를 엣지에서 하려면, 세션 쿠키나 API 키 헤더로 세는 Advanced Rate Limiting(Enterprise)이 필요합니다. 그 아래 요금제에서는 IP로만 셉니다. 8편의 CGNAT 문제가 그대로 남습니다.

봇 점수. 1~99점이며 1은 자동화, 2~29는 자동화일 가능성이 높고, 30~99는 사람일 가능성이 높다는 뜻입니다. 세부 점수는 Enterprise Bot Management에서 보입니다.

챌린지. 대부분의 WAF 규칙에 관리형 챌린지를 권합니다. 챌린지 페이지는 AJAX 호출을 깨뜨리므로, API에는 Turnstile 사전 통과(pre-clearance) 같은 방법을 따로 씁니다.

AWS: WAF와 GuardDuty는 하는 일이 다르다

AWS WAF 관리형 규칙 그룹. 핵심 규칙(Core rule set), 알려진 나쁜 입력, SQL·Linux·PHP 같은 용도별 규칙, Amazon IP 평판 목록과 익명 IP 목록, Bot Control, 계정 탈취 방지(ATP)와 계정 생성 사기 방지(ACFP)가 있습니다. 어떤 그룹에 추가 요금이 붙는지는 이 글에서 확인하지 않았습니다(확인 필요).

비율 기반 규칙(rate-based rule).

평가 기간: 60, 120, 300(기본), 600초.
최소 한도: 10.
세는 기준: 출발지 IP, 헤더 속 IP(앞단 프록시), ASN, 또는 사용자 지정 키(헤더, 쿠키, 쿼리 인자, URI 경로, JA3/JA4, 라벨 등). 헤더나 쿠키로 세면 신원 기준에 가까워집니다. 단, 키가 없는 요청은 세지 않습니다.
즉시가 아닙니다. AWS 문서는 비율 기반 규칙이 정밀한 속도 제한용이 아니며, 한도를 넘은 뒤 조치까지 보통 30초 이내, 길게는 몇 분 걸릴 수 있다고 적습니다. 4편의 앱 안 윈도우는 바로 다음 요청부터 반응했습니다.

GuardDuty. 위협 탐지 서비스입니다. 기본 데이터 출처는 CloudTrail 관리 이벤트, VPC 흐름 로그, DNS 로그이고, 보호 계획으로 S3, EKS 감사 로그, 런타임 모니터링, RDS 로그인 활동, Lambda 네트워크 로그 등이 더해집니다. 결과는 탐지 결과(finding)로 나오고, 대응은 EventBridge로 연결합니다. 데이터 출처 목록에 HTTP 요청 내용은 없습니다. 원문이 "AWS WAF + GuardDuty"를 한 덩어리로 쓴 것과 달리, GuardDuty는 IDOR이나 열거를 보는 도구가 아닙니다. 침해된 인스턴스, 이상한 API 호출, 악성 주소와의 통신을 봅니다.

둘을 잇는 공식 블로그 패턴이 있습니다. GuardDuty 결과 → EventBridge 규칙 → Lambda가 WAF IP 집합을 갱신하고, 만료된 항목은 예약된 Lambda가 지웁니다. 6편의 "결정 API + TTL"을 AWS 부품으로 만든 모양입니다.

Datadog App and API Protection: 앱 안으로 들어가는 쪽

Datadog의 ASM은 이제 App and API Protection(AAP)이라고 부릅니다. 추적(APM) 라이브러리 안에서 동작해서, APM을 쓰고 있다면 환경 변수 하나로 켭니다.

In-App WAF: IP, User-Agent, 헤더로 막습니다.
Exploit Prevention(RASP): SSRF, 로컬 파일 포함, SQL 주입, 명령 주입을 막습니다. 언어마다 지원 범위가 다릅니다(예: Go와 PHP는 명령 주입 미지원, Ruby는 LFI·명령 주입 미지원).
계정 탈취·크리덴셜 스터핑 탐지와 차단을 쓰임새로 듭니다.
API 보안 상태 점검: OWASP API Top 10에 맞춘 규칙이 있고, "예측 가능한 ID를 쓰는 경로에서 인증이 감지되지 않음" 같은 탐지 규칙이 있습니다.

그런데 Datadog 문서에서 BOLA·IDOR을 탐지한다고 명시한 곳은 찾지 못했습니다. 원문의 "Datadog ASM이 IDOR을 실시간으로 추적한다"는 확인되지 않은 주장입니다(확인 필요). 앱 안에 들어가더라도, 주문의 주인을 아는 것은 여전히 우리 코드입니다. 대신 3편처럼 인가 거부를 사용자 정의 보안 이벤트로 보내면 이런 플랫폼의 탐지 규칙과 대시보드에서 엮어 볼 수 있습니다.

무엇을 사고 무엇을 만들까

	사서 쓰기 좋은 것	만들어야 하는 것
방어선 0	API 보안 상태 점검(빠진 인증, 예측 가능한 ID 표시)	객체 인가, 스키마 검증, 불투명 ID
방어선 1	추적 라이브러리 안 WAF·RASP(주입 범주)	인가 거부 이벤트, 신원 윈도우, 미끼 객체
방어선 2	관리형 WAF 규칙, 봇 점수, 챌린지, IP 평판	서비스에 맞는 제외 규칙
방어선 3	로그 수집·SIEM, GuardDuty 같은 인프라 탐지	앱 이벤트를 엮는 규칙

상용 제품은 범용 공격과 양에 강하고, 우리 서비스의 업무 의미는 모릅니다. 그래서 방어선 0과 1은 어느 제품을 고르든 우리가 만듭니다.

정리

Cloudflare와 AWS WAF는 방어선 2를 맡기기 좋습니다. 다만 신원 기준으로 세려면 상위 요금제나 사용자 지정 키가 필요하고, AWS 비율 기반 규칙은 즉시 반응하지 않습니다.
GuardDuty는 HTTP 요청을 보지 않는 인프라 위협 탐지입니다. EventBridge와 Lambda로 WAF 차단 목록과 이을 수 있습니다.
Datadog AAP는 앱 안에서 주입 범주를 막고 계정 탈취를 봅니다. BOLA·IDOR 탐지를 명시한 문서는 찾지 못했습니다.
객체 인가와 인가 거부 이벤트는 어떤 제품을 쓰든 우리 코드의 몫입니다.