API 보안 / 인프라 아키텍처
마이데이터 표준 API 의무화 이후 드러난 레거시 웹 방화벽의 구조적 한계와, 파이오링크 WEBFRONT-K 기반 WAAP 아키텍처가 실제로 해결하는 것들.
현장에서 가장 자주 듣는 질문 중 하나가 이것이다. "WAF 있는데 WAAP까지 왜 필요합니까?" 틀린 질문이 아니다. 보안 예산도 운영 공수도 이미 충분히 올라가 있다. 하지만 이 질문이 전제하는 것, 즉 WAF가 API를 보호하고 있다는 믿음에는 구조적인 오류가 있다. 문제는 장비 성능이 아니라 탐지 가능한 위협의 종류 자체가 다르다는 점이다.
2022년 1월부터 국내 오픈뱅킹과 마이데이터 서비스에서 웹 스크래핑이 전면 금지되고 표준 API 기반 데이터 교환이 법적으로 의무화되었다. 금융권을 중심으로 모든 서비스 간 통신이 JSON 페이로드를 주고받는 API 엔드포인트로 재편된 것이다. 마이크로서비스 아키텍처(MSA) 확산으로 단일 애플리케이션이 수백 개의 엔드포인트를 노출하는 구조도 이제 일반적이다. 공격 표면이 단순히 넓어진 것이 아니라, 위협이 발생하는 계층 자체가 달라졌다.
WAF가 보지 못하는 것
레거시 WAF의 탐지 모델은 HTTP 요청의 구문적 이상, 즉 URL 파라미터의 SQL 인젝션 패턴이나 XSS 스크립트 삽입처럼 시그니처로 정의 가능한 위협에 최적화되어 있다. 브라우저를 통해 인간이 발생시키는 트래픽, HTML 폼 데이터, 알려진 페이로드 패턴이 주된 방어 대상이다.
API 트래픽은 성격이 다르다. 요청은 인증된 사용자의 JWT를 달고 들어오고, 페이로드는 정상적인 JSON 구조를 유지한다. SQL 인젝션 패턴도 없고, XSS 코드도 없다. GET /api/accounts/1001/statements를 GET /api/accounts/1002/statements로 바꾸는 것, 혹은 분당 수천 건의 정상적인 형태의 요청을 특정 엔드포인트에 몰아넣는 것은 시그니처 기반 탐지로 포착되지 않는다. OWASP가 2019년에 별도의 API Security Top 10을 발행한 것도 이 때문이다.
레거시 WAF vs WAAP — 보호 범위와 탐지 방식 비교
항목 | 레거시 WAF | WAAP |
보호 대상 | 웹 페이지, HTML 폼, URL 파라미터 | 웹 + 마이크로서비스 + 표준 API 엔드포인트 |
탐지 기반 | 알려진 공격 시그니처 (OWASP Web Top 10) | OWASP API Top 10, 행위 분석, 논리 계층 검증 |
페이로드 분석 | HTML, 폼 데이터, URL 쿼리 위주 | JSON 스키마 검증, JWT 서명 검사, XML 심층 분석 |
봇 탐지 | IP 블랙리스트, 기본 rate limit | 클라이언트 행위 프로파일링, 크리덴셜 스터핑 탐지 |
인증 레이어 | 없음 (애플리케이션 책임) | mTLS 상호 인증 게이트웨이 + JWT 에지 검증 |
OWASP API Top 10에서 실무적으로 중요한 위협들
OWASP API Security Top 10 전체를 순서대로 설명하는 것보다, 실제 운영 환경에서 탐지와 대응이 가장 어려운 네 가지에 집중하는 편이 낫다.
BOLA (Broken Object Level Authorization, A01)는 수년째 1위다. 인증은 통과했지만 다른 사용자의 객체에 접근 가능한 구조적 허점이다. GET /api/loans/5847에서 5847을 5848, 5849로 순차 변조하는 요청은 정수형 값의 정상 API 호출처럼 보인다. 시그니처 탐지를 통과하는 것은 당연하다.
JWT 기반 인증 우회(A02)도 마찬가지다. 공격자가 JWT 헤더의 알고리즘 필드를 "none"으로 조작하거나, 페이로드의 role 값을 "user"에서 "admin"으로 변조해도, 변조된 토큰 자체가 서버에 도달하기 전에 서명 검증이 이루어지지 않으면 통과된다. 수백 개의 마이크로서비스 각각이 이 검증을 정확히 구현하리라고 기대하는 것은 현실적이지 않다.
과도한 데이터 노출(A03)은 개발 프로세스 압박이 만들어내는 문제다. 프레임워크의 자동 직렬화 로직이 응답 JSON에 내부 관리자 ID, 주민등록번호 전체, 스택 트레이스를 포함해 반환하는 경우가 있다. 이미 운영 중인 서비스에서 사후에 이를 잡는 것은 매우 어렵다.
자원 고갈 DoS(A04)는 대역폭을 소진하는 전통적 DDoS와 다르다. 데이터베이스 복잡 조인을 유발하는 특정 API 엔드포인트에 소수의 요청을 집중시키는 방식으로 CPU와 DB 커넥션 풀을 고갈시킨다. 네트워크 트래픽 수준에서는 이상이 없어 보인다는 점이 핵심 문제다.
OWASP API Security Top 10 — 위협 메커니즘과 에지 대응
위협 | 공격 메커니즘 | 에지 계층 대응 방식 |
A01 - BOLA | 객체 식별자 순차 변조를 통한 타 사용자 데이터 불법 접근 | 식별 정보 위장(Cloaking) — 내부 ID를 난수 토큰으로 마스킹, 매핑 테이블 에지 보유 |
A02 - 인증 파괴 | JWT 알고리즘 무효화, 권한 필드 변조, 크리덴셜 스터핑 봇 | mTLS 상호 인증 게이트웨이 + JWT 서명 에지 검증 오프로딩 |
A03 - 과도한 데이터 노출 | 응답 JSON에 PII, 내부 ID, 스택 트레이스 평문 포함 | WISE Filter™ 아웃바운드 분석 + JSON 응답 클로킹 및 비식별화 |
A04 - 자원 고갈 | 고비용 로직의 특정 엔드포인트 집중 호출로 DB 커넥션 풀 고갈 | API · HTTP 메소드별 Rate Limiting / QoS 임계치 제어 |
A07 - 보안 설정 오류 | 비정상 데이터 타입 삽입, Mass Assignment, JSON Bomb | JSON 요청 OpenAPI 스키마 검증 + JSON Bomb 방어 로직 |
WEBFRONT-K가 이 문제에 접근하는 방식
파이오링크 WEBFRONT-K는 API 특화 위협들을 에지 계층에서 처리하기 위해 여섯 가지 분석 엔진을 내재화하고 있다. 각각의 설계 의도를 살펴보면 이렇다.
식별자 위장(Cloaking)과 BOLA 차단
BOLA를 에지에서 막는 접근법은 공격자가 내부 식별자 구조를 알 수 없게 만드는 것이다. WEBFRONT-K는 백엔드 API URI에 포함된 실제 객체 ID를 외부 클라이언트에게 전달할 때 추상화된 난수 토큰으로 치환한다. 클라이언트가 받는 경로는 /api/accounts/1000이 아닌 /api/accounts/aB3x9Y 형태가 되며, 이 매핑은 장비 내부 상태 테이블에서만 유지된다. 임의로 변조한 토큰값은 테이블에 존재하지 않으므로 백엔드에 도달하기 전 인가 오류로 차단된다.
JWT 에지 검증과 서버 부하 경감
애플리케이션 서버가 모든 API 요청의 JWT 서명을 직접 검증하는 것은 CPU 부하가 상당하다. 수백 개의 마이크로서비스가 각자 이 검증 로직을 정확히 구현하고 유지하는 것도 현실적으로 어렵다. WEBFRONT-K는 백엔드의 시크릿 키 또는 퍼블릭 키를 사전에 공유받아 내장하고, 유입되는 모든 Authorization 헤더의 JWT 서명을 에지에서 실시간 검증한다. 서명이 유효하지 않거나 알고리즘이 "none"으로 설정된 토큰은 애플리케이션 계층에 도달하기 전에 폐기된다. 이 구조는 검증 연산을 백엔드에서 장비로 오프로딩하는 효과도 겸한다.
WISE Filter™와 아웃바운드 응답 클로킹
일반 WAF는 인바운드 요청만 검사한다. WEBFRONT-K의 WISE Filter™는 백엔드 서버가 외부로 내보내는 응답 본문의 JSON 콘텐츠도 실시간으로 분석한다. 사전에 정의한 패턴과 일치하는 민감 정보, 주민등록번호 형식이나 전체 계좌번호가 응답에 포함된 경우, 해당 세션 자체를 차단하거나 해당 필드만 *** 형태로 비식별화하여 전송한다. 백엔드 코드 수정 없이 네트워크 에지에서 개인정보 유출 통제선을 구현하는 방식이다.
API별 Rate Limiting과 자원 고갈 방어
단순 IP 기반 차단보다 한 계층 아래로 내려간 제어가 필요하다. WEBFRONT-K는 API 트랜잭션 단위, 그리고 HTTP 메소드 단위의 임계치 제어를 지원한다. GET /api/v1/account_balance는 초당 500건을 허용하되, POST /api/v1/wire_transfer는 출발지당 초당 10건으로 제한하는 방식이다. 초당 연결 수(CPS), 동시 세션 수, 인바운드 대역폭을 교차 적용할 수 있어 인증된 사용자라도 오동작 코드나 의도적 요청으로 자원을 독점하는 상황을 통제한다.
Technical Note
HTTP/2 Rapid Reset 공격은 프로토콜의 멀티플렉싱 특성을 악용해 스트림 요청을 전송하자마자 즉각 RST_STREAM 프레임을 고속 반복 전송하여 서버 스레드만 소모하게 만드는 방식이다. 네트워크 대역폭 소모가 거의 없어 전통적인 DDoS 탐지를 우회한다. WEBFRONT-K는 이 패턴에 대한 전용 완화 로직을 내재화하고 있다.
성능이 병목이 되지 않으려면
보안 장비를 API 트래픽 경로에 인라인으로 배치할 때 가장 실질적인 위험은 지연(latency)이다. 특히 SSL/TLS 암복호화는 컴퓨팅 부하가 높고, 범용 CPU 소프트웨어 연산에 의존하는 장비는 트래픽이 폭증하는 구간에서 응답 속도가 불안정해진다. RSA 2048bit 이상의 키 사이즈가 표준화된 지금은 더욱 그렇다.
WEBFRONT-K는 이 문제를 하드웨어 단에서 해결한다. 독립적인 하드웨어 SSL 전용 칩셋이 암복호화 연산을 전담(SSL Offloading)함으로써 웹 보안 프로세서의 연산 자원을 검사 로직에만 집중시킨다. 주식 거래 시스템이나 수강신청처럼 트래픽이 예측 불가능하게 폭증하는 구간에서도 응답 지연 없이 처리가 유지되는 이유가 이 아키텍처에 있다.
트래픽 선별 구조도 다르다. 파이오링크의 특허 기술인 Smart Selector™는 물리 패킷 처리 포트 단에서 HTTP/HTTPS 트래픽만을 하드웨어 레벨로 필터링해 웹 보안 전용 엔진으로 전달한다. FTP, SSH 등 검사가 불필요한 나머지 트래픽은 시스템 자원 소모 없이 즉시 우회 처리되고, 관리 및 모니터링 트래픽은 완전히 분리된 전용 엔진이 처리한다. 모든 트래픽을 단일 보안 엔진에서 일괄 처리하는 범용 장비와는 아키텍처가 근본적으로 다르다.
패킷 처리 계층에서는 DAP(Dynamic Application Proxy) 기술이 네트워크 스택의 병목을 제거한다. 기존 프록시 방식에서 발생하는 커널-유저 레벨 간 다중 컨텍스트 스위칭과 메모리 복사 연산을 아키텍처 설계 단계에서 원천 제거하는 방식이다. 처리 대역폭은 라이선스 기반으로 600Mbps에서 최대 40Gbps까지 확장 가능하다.
하이브리드 클라우드 환경에서의 배포 현실
지금 대부분의 운영 환경은 온프레미스 데이터센터와 퍼블릭 클라우드가 혼재한 형태다. WEBFRONT-K 시리즈는 이 두 축을 같은 정책 체계 안에서 커버한다. 데이터센터의 핵심 백본 구간에는 전용 하드웨어 어플라이언스인 WEBFRONT-K를, NHN 클라우드나 AWS 등 퍼블릭 클라우드 또는 프라이빗 클라우드 환경에는 가상화 모델인 WEBFRONT-KS를 배포한다. KS는 QAT 및 SRIOV 가속 아키텍처를 채택해 가상화 환경에서도 물리 장비에 준하는 처리 성능을 낸다. 두 모델은 동일한 듀얼 탐지 엔진과 관리 환경을 공유한다.
도입 초기의 오탐(False Positive) 위험을 줄이기 위해 하이브리드 모드 배포가 권장된다. 코어 스위치의 포트 미러링을 활용해 트래픽 복제본을 받아 대역 외(out-of-path)에서 분석하는 미러링 모드와, 실제 차단 개입이 필요할 때 즉각 전환 가능한 Rapid In-line 모드를 조합한 구조다. 초기 2~4주는 강제 차단 없이 모니터링 전용으로 운영하며 API 트래픽 패턴을 학습한 뒤 단계적으로 차단 정책을 활성화한다.
운영 자동화 측면에서는 Full REST-API와 Ansible 플레이북 연동을 공식 지원한다. MSA 환경에서 하루에도 수십 차례 이루어지는 마이크로서비스 배포 사이클에 맞춰, 신규 API 엔드포인트의 JSON 스키마 검증 룰과 임계치 정책을 CI/CD 파이프라인에서 자동 프로비저닝하는 구성이 가능하다. 전체 노드의 중앙 관제는 Analyzer V2가 담당하며, 분산된 K/KS 노드들의 공격 로그를 단일 콘솔에서 수집하고 위협 이벤트 상관 분석과 시각화 대시보드를 제공한다.
API 보안이 까다로운 이유는 위협이 논리 계층에 있기 때문이다. 인증을 통과한 요청이, 정상적인 JSON 구조를 유지한 채로, 다른 사용자의 데이터를 조회하거나 서버 자원을 고갈시킨다. 이 종류의 위협은 시그니처로 정의되지 않는다. 에지 계층의 보안 도구가 애플리케이션 비즈니스 로직을 이해하고 검증할 수 있는 수준까지 내려오지 않으면, 방어선은 결국 각 마이크로서비스의 코드 안으로 후퇴한다. WAAP 논의가 단순 제품 교체가 아닌 아키텍처 레벨의 결정이어야 하는 이유가 거기에 있다.
Subscribe to 'BLOGGER'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'BLOGGER'!
Join Slashpage and subscribe to 'BLOGGER'!
Subscribe
