AWS API Gateway(Protocol: HTTP)란?
AWS API Gateway는 HTTP와 REST 두 가지 프로토콜을 지원하며, 각각의 특징과 사용 사례가 다릅니다.
REST API는 기능이 풍부하고 복잡한 애플리케이션에 적합합니다. API Gateway REST API는 API 요청을 다양한 AWS 서비스와 통합할 수 있는 기능을 제공하며, 캐싱, 사용자 지정 권한 부여, 요청/응답 변환, 스테이지 관리 등 고급 기능을 지원합니다. 고도로 제어된 API 엔드포인트가 필요하거나, AWS 서비스와의 깊은 통합이 요구되는 경우에 REST API가 적합합니다.
HTTP API는 경량화된 API로, 비용 효율성과 낮은 지연 시간을 제공합니다. REST API에 비해 간단하게 설정할 수 있으며, 기본적인 인증, 라우팅, AWS Lambda 및 HTTP 엔드포인트 통합을 지원합니다. 성능이 중요하고, 간단한 API 요청 처리나 웹훅 설정과 같은 기본적인 API 엔드포인트가 필요한 경우 HTTP API가 적합합니다.
요약하자면, 복잡한 기능과 통합이 필요한 경우 REST API, 성능과 간단한 API가 필요한 경우 HTTP API를 사용하는 것이 좋습니다.
Datadog ASM(Application Seucirty Management)란?
Datadog Application Security Management(ASM)는 애플리케이션 레벨에서 보안 위협을 감지하고 대응하는 호스트/Container 기반 WAF 솔루션입니다. Java, Node.js 등 런타임에 Datadog Library를 통해 실시간으로 런타임 레벨에서 보안을 탐지하고 Context를 제공합니다.
실제 공격을 확인하고, 해당 IP에 대한 블로킹이나 사전에 미리 만들어져 있는 OWASP 룰을 통해 차단도 가능합니다. Proxy 기반 WAF와 다르게 호스트 기반의 WAF로 장점은 1) 실제 공격 Context를 확인할 수 있고, 2) 서비스 런타임 기반으로 동작하여 각 서비스 특성에 맞게 WAF Rule을 적용시킬 수 있으며, 3) 현재 WAF가 어디 서비스에 적용됐는 지 쉽게 가시성을 제공하며, 4) 기존 WAF 대비 비용 절감도 가져갈 수 있습니다. (APM은 기존에 사용한다는 전제)
또한 SCA(소프트웨어 구성 분석) 등을 통해 애플리케이션이 사용하고 있는 취약한 Library를 분석합니다. 이를 통해 개발자는 애플리케이션의 보안 상태를 실시간으로 모니터링하고, 잠재적인 공격을 신속하게 차단할 수 있습니다. 특히, Datadog의 모니터링 플랫폼과 통합되어 보안과 성능 데이터를 하나의 대시보드에서 관리할 수 있어 효율적입니다.
Datadog ASM 적용 시 AWS API Gateway Forwarded Header 이슈
제가 해당 서비스를 테스트 하기 위해 만든 아키텍처는 위와 같습니다. 사용자는 Amplify를 통해 정적페이지가 랜더링 되고, API Gateway로 요청을 날리면 그 요청은 API Gateway를 거쳐 ALB 그리고 각 EKS Pod에 전달됩니다.
이 때 이슈가 발생되는데요. ASM에서는 Client IP를 X-Forwarded-For 헤더를 기반으로 확인하고 동작합니다. 여기서 불행이 발생되는데, AWS API Gateway에서는 ALB에 X-Forwarded-For 헤더로 제공하지 않고, Forwared 헤더를 전달하게 됩니다.
위 이미지와 같이 사용자 요청이 API Gateway > ALB를 거쳐 들어오면 x-forwarded-for 헤더에는 ALB IP가 쓰여지고, forwarded 헤더에 for=Client IP;host=~~~com.;proto=https 구조로 들어오게 됩니다.
그러면 Datadog ASM에서는 사용자 IP를 x-forwarded-for 헤더의 IP로 인식하여 ALB IP를 사용자 IP로 인식합니다.
다행히 ASM에서는 사용자 IP를 커스텀헤더로 인식할 수 있는 옵션을 제공합니다. 그래서 API Gateway의 Parameter mapping을 통해 header.X-Client-IP로 커스텀 헤더를 새로 만들고, Client IP($context.identity.sourceIp)를 Value로 넣어 위 로그에 볼 수 있듯이 x-client-ip 헤더를 추가합니다.
그리고 아래와 같이 Deployment.yml에 API Gateway에서 설정한 커스텀헤더 x-client-ip를 등록합니다.
spec:
containers:
- name: login
image: xxx.dkr.ecr.ap-northeast-2.amazonaws.com/xxx
env:
- name: DD_DYNAMIC_INSTRUMENTATION_ENABLED
value: "true"
- name: DD_IAST_ENABLED
value: "true"
- name: DD_PROFILING_ENABLED
value: "true"
- name: DD_ENV
valueFrom:
fieldRef:
fieldPath: metadata.labels['tags.datadoghq.com/env']
- name: DD_SERVICE
valueFrom:
fieldRef:
fieldPath: metadata.labels['tags.datadoghq.com/service']
- name: DD_VERSION
valueFrom:
fieldRef:
fieldPath: metadata.labels['tags.datadoghq.com/version']
- name: DD_TRACE_CLIENT_IP_HEADER
value: x-client-ip
그러면 Datadog ASM에서는 실제 Client IP를 가져오게 되고, Datadog ASM에서 공격자 IP를 즉시 블로킹할 수 있게 됩니다. 3일 동안 삽질한 내용으로 여러분은 바로바로 해결하시길 바랍니다.