[클라우드 보안 실무 #6] AWS WAF, CAPTCHA·Challenge 룰로 사용자 검증하기

cloudindovi 2025. 4. 22. 09:30

🤔 허용과 차단 사이, 사용자 검증이 필요할 때

AWS WAF를 설정하다 보면 단순한 허용(Allow) 또는 차단(Block)만으로는 대응하기 애매한 요청을 마주하게 됩니다. 예를 들어, 로그인 페이지에서 반복적인 접근이 있는데 IP 자체는 처음 보는 경우, 혹은 게시판에 하루 수십 건씩 게시글을 등록하는 비정상적인 접근 같은 상황이죠.

이럴 때 가장 유용한 기능이 바로 CAPTCHA와 Challenge 액션입니다. 봇인지 사람인지 확인하면서도 사용자 경험을 해치지 않는 대응이 가능하죠.

🔐 CAPTCHA와 Challenge, 뭐가 다를까?

CAPTCHA는 사용자의 브라우저에 테스트를 띄워 사람인지 확인하는 전통적인 방식입니다. 구글 리캡차처럼 이미지를 클릭하거나 글자를 입력하는 과정을 요구하죠.

반면 Challenge는 CAPTCHA 없이 브라우저의 행동이나 헤더 정보를 검사해서 정상 사용자인지 판단하는 방식입니다. 유저 입장에서는 아무것도 하지 않아도 통과될 수 있는 자동 검증 구조예요.

따라서 Challenge는 CAPTCHA보다 UX에 덜 부담스러운 방식으로, 최근에는 이 방식을 먼저 적용한 뒤 실패 시 CAPTCHA로 넘기는 흐름도 많이 사용됩니다.

📍 적용 위치와 조건 설정 팁

AWS WAF 콘솔에서 웹 ACL → 룰 그룹 → 새 룰 추가 → 액션을 “Challenge” 또는 “CAPTCHA”로 설정하면 됩니다.

추천 적용 위치:

로그인 또는 회원가입 페이지
댓글/게시판/문의 글 작성 엔드포인트
검색 API 또는 자주 요청되는 GET URI

조건은 URI Path, 쿠키 유무, User-Agent 필드, GeoIP 등을 조합해서 설정하면 좋습니다. 예: 동일 IP에서 하루 10회 이상 /login 요청 → Challenge 적용

🛠 실무에서의 사용 팁

1. CAPTCHA만 단독 적용하지 않기 → 초기에는 Challenge로 1차 필터링 후, 의심되거나 2회 이상 접근 시 CAPTCHA로 전환하는 게 오탐 방지에 효과적입니다.

2. CAPTCHA 도입 시 사용자 흐름 고려 → 너무 빈번하게 CAPTCHA가 나오면 유저 이탈이 생길 수 있어요. 로그인 시 1회, 이후 일정 시간 동안은 면제하는 방식 추천.

3. CAPTCHA 성공/실패 로그 CloudWatch로 연동 → 향후 정책 수정 시 근거 자료로 활용 가능하고, 의심되는 요청 패턴을 탐지하는 데도 도움이 됩니다.

📈 CAPTCHA & Challenge 도입 전후 차이

실제 운영 중인 서비스에서 CAPTCHA를 도입한 뒤, 비정상 요청이 약 70% 이상 감소한 사례도 있습니다.

특히 게시판 도배, 로그인 시도, 검색 요청 남용 등 반자동/수동 봇 활동을 차단하는 데 큰 효과를 보였습니다.

단, 잘못된 설정은 정상 유저에게도 CAPTCHA를 반복 노출할 수 있기 때문에 초기 테스트와 로그 기반 조정은 필수입니다.

✅ 마무리 정리

CAPTCHA와 Challenge는 단순한 차단을 넘어서 사용자와 봇을 구분하고, 실사용자 경험을 지키는 전략적 요소입니다.

허용도 차단도 애매한 요청에는 이 검증 계층을 도입해보세요. AWS WAF의 룰셋이 더욱 유연하고 똑똑하게 작동할 것입니다.