WAF는 어디에 붙어 있고, 어디까지 보호하는가

AWS 실전 운영 시리즈 12/12

WAF를 붙였다고 해서 시스템 전체가 자동으로 보호되는 것은 아니다.

WAF는 어디에 연결되어 있는지에 따라 보호 범위가 달라진다.

CloudFront에 WAF를 붙이면 CloudFront를 통과하는 요청은 검사할 수 있다. 하지만 CloudFront를 우회하는 API Gateway나 origin 직접 접근 경로는 별도 보안 정책이 필요하다.

이 차이를 이해하지 못하면 "WAF가 있으니 안전하다"고 착각할 수 있다.

문제 상황

운영 콘솔 앞단에는 CloudFront가 있었다.

프론트엔드 SPA는 CloudFront를 통해 S3에서 제공되었다.

API 일부도 CloudFront를 거쳐 origin API 서버로 전달되었다.

여기에 사무실 IP만 허용하는 WAF 정책을 붙일 수 있다.

구조를 단순화하면 이렇다.

이 경우 WAF는 CloudFront로 들어오는 요청을 보호한다.

하지만 모든 경로가 CloudFront를 지나지 않는다면 이야기가 달라진다.

그림에서 점선 경로는 CloudFront WAF를 통과하지 않을 수 있는 우회 경로다. WAF를 붙였다는 사실보다, 사용자가 실제로 도달할 수 있는 모든 진입점이 어디인지 확인하는 것이 먼저다.

WAF의 보호 범위

WAF는 연결된 리소스 앞단에서 동작한다.

CloudFront에 붙어 있다면 보호 범위는 CloudFront로 들어오는 요청이다.

예를 들어:

console.example.com
-> CloudFront + WAF
-> S3

이 경로는 WAF 보호를 받는다.

api.example.com
-> CloudFront + WAF
-> origin API server

이 경로도 API CloudFront에 WAF가 붙어 있다면 보호를 받는다.

하지만 다음 경로는 다를 수 있다.

execute-api...amazonaws.com
-> API Gateway
-> Lambda

또는:

origin-api.example.com
-> EC2 API server

이 경로들이 CloudFront를 거치지 않는다면 CloudFront WAF의 보호를 받지 않는다.

프론트엔드만 막고 API는 열려 있을 수 있다

운영 콘솔에서 흔한 착각이 있다.

프론트엔드 도메인에 WAF를 붙여 사무실 IP만 허용하면 전체 콘솔이 막힌 것처럼 느껴진다.

하지만 프론트엔드가 호출하는 API가 별도 도메인이고, 그 API가 WAF 없이 공개되어 있다면 API는 직접 호출될 수 있다.

즉:

console.example.com  # WAF 보호
api.example.com      # 별도 보호 필요

프론트엔드 접근 제어와 API 접근 제어는 별개다.

브라우저 화면을 못 열게 막았다고 API가 보호되는 것은 아니다.

API Gateway는 별도 정책이 필요하다

API Gateway를 직접 사용하는 경우 CloudFront WAF와 별개로 보호해야 한다.

선택지는 여러 가지다.

• API Key
• IAM 인증
• Lambda Authorizer
• Cognito Authorizer
• WAF를 API Gateway에 직접 연결
• resource policy
• usage plan과 throttling

어떤 방식을 쓸지는 API 성격에 따라 다르다.

내부 운영자만 쓰는 API인지, 외부 자동화 도구가 호출하는 API인지, 공개 페이지가 쓰는 API인지에 따라 달라진다.

origin 직접 접근도 확인해야 한다

API 앞에 CloudFront를 뒀더라도 origin 도메인이 직접 접근 가능하면 우회 경로가 된다.

예를 들어:

api.example.com
-> CloudFront + WAF
-> origin-api.example.com
-> EC2

여기서 사용자가 origin-api.example.com을 직접 호출할 수 있다면 WAF를 지나지 않는다.

따라서 origin 보호가 필요하다.

가능한 방법:

• security group으로 접근 제한
• CloudFront origin custom header 검증
• API 자체 인증
• origin 도메인 비공개화
• ALB security policy

CloudFront는 origin을 숨겨주지만, origin 접근이 열려 있으면 완전한 보호가 아니다.

IP allowlist의 한계

사무실 IP만 허용하는 WAF 정책은 내부 도구에 유용하다.

하지만 한계도 있다.

• 재택근무나 외부 접속이 필요할 때 불편하다.
• 사무실 IP가 바뀌면 갱신이 필요하다.
• API Gateway 직접 접근은 별도 보호가 필요하다.
• origin 직접 접근은 막지 못할 수 있다.
• IP 기반 보안은 사용자 인증을 대체하지 않는다.

IP allowlist는 좋은 1차 방어선이지만, 인증과 권한 모델을 대신할 수 없다.

WAF와 CORS는 다르다

CORS를 보안 기능처럼 생각하는 경우도 있다.

CORS는 브라우저 보안 모델이다.

브라우저가 다른 origin으로 API 호출을 제한하는 방식이다.

하지만 curl, server-side script, Postman 같은 클라이언트는 CORS의 영향을 받지 않는다.

WAF는 네트워크 요청 자체를 검사하고 차단할 수 있다.

따라서 CORS와 WAF는 역할이 다르다.

• CORS: 브라우저 기반 cross-origin 호출 제어
• WAF: HTTP 요청 검사와 차단
• 인증: 사용자가 누구인지 확인
• 권한: 무엇을 할 수 있는지 결정

이 네 가지를 혼동하면 안 된다.

운영 문서에 남길 보안 경계

보안 구성은 문서화해야 한다.

특히 "무엇이 보호되고 무엇이 보호되지 않는가"를 적어야 한다.

예시:

경로	보호 방식	비고
console.example.com	CloudFront WAF	프론트엔드
api.example.com	API CloudFront WAF	API proxy
origin-api.example.com	보안 그룹 또는 API 인증	직접 접근 제한 필요
API Gateway 직접 URL	API Key/IAM 등 검토	CloudFront WAF와 별도

이 표는 보안 착각을 줄인다.

정리

WAF는 중요한 보안 계층이다.

하지만 어디에 붙어 있는지 알아야 한다.

CloudFront에 WAF를 붙이면 CloudFront를 지나는 요청은 보호한다.

하지만 API Gateway 직접 URL, origin 직접 접근, 별도 API 도메인은 별도 보호가 필요할 수 있다.

운영 콘솔 보안에서는 다음 질문을 항상 해야 한다.

• 사용자는 어떤 도메인으로 들어오는가
• API는 어떤 도메인으로 호출되는가
• 모든 요청이 WAF를 지나는가
• origin을 직접 호출할 수 있는가
• CORS를 보안으로 착각하고 있지 않은가
• 인증과 권한은 어디서 처리하는가

WAF를 붙였다는 사실보다 중요한 것은 보호 경계를 정확히 아는 것이다.

함께 볼 GitHub 저장소

• aws-console-operations-notes