요청은 어디에서 통제되는가
각 통제는 막는 대상이 다릅니다. WAF는 요청이 규칙과 일치하는 알려진 HTTP 공격 패턴을 주로 걸러 냅니다. Rate Limit은 정해진 호출량·속도·Burst를 넘은 요청을 거부합니다. Schema Validation은 API 계약을 벗어난 필드·자료형·크기·범위를 차단합니다. 엄격한 JWT 검증은 서명이나 MAC이 잘못됐거나 Issuer·Audience·만료 조건이 맞지 않는 토큰의 수용을 막습니다. mTLS는 신뢰한 인증서와 그 개인키를 보유하지 않은 통신 상대의 연결을 막습니다. API Gateway는 이 정책들을 실행할 배치 지점이지만 모든 Gateway 제품이 동일한 보안 기능을 제공하지는 않습니다.[1]
여섯 가지를 모두 적용해도 API 보안이 완성되지는 않습니다. 사용자가 다른 사람의 주문을 조회하는 문제, 일반 사용자가 관리자 기능을 호출하는 문제, 정상적인 요청 모양으로 재고나 예약을 독점하는 문제는 여전히 Business Logic과 Authorization에서 판단해야 합니다. 알려지지 않은 API, 키·인증서 수명주기, 로그와 감사도 별도의 책임 영역입니다.[6] 따라서 "WAF를 붙였는가" 또는 "Gateway를 도입했는가"보다 먼저 확인할 것은 어떤 위협을 어느 지점에서 거부하며 그 뒤에 어떤 공백이 남는가입니다.
요청은 여섯 지점을 지납니다. 처음은 Client 또는 호출 서비스입니다. 여기서 JWT가 Claims와 Token Context를 실어 오고, mTLS를 쓴다면 Client Certificate가 개인키 보유를 증명합니다. JWT 자체가 사용자 인증이나 권한 판정을 수행하지는 않습니다. 다음은 Edge와 WAF입니다. HTTP Header·URI·Body를 규칙으로 검사하고 알려진 Injection·Traversal을 탐지하며 일부 Layer 7 이상 징후를 완화합니다. 그다음이 API Gateway 또는 Ingress입니다. Route와 Method를 고르고 제품과 구성에 따라 JWT·mTLS·Rate·Schema 정책을 실행하며 Routing과 Logging, Telemetry를 담당합니다. 이 기능이 모두 표준으로 내장된다고 가정해서는 안 됩니다. 네 번째는 Runtime과 API Handler입니다. 권위 있는 Parsing과 Schema Validation, Timeout·Payload·Query·Batch·Concurrency 제한, Service와 Token Context 확인이 여기 있습니다. 다섯 번째는 Business Logic과 Authorization입니다. Object·Property-level Authorization, Function-level Authorization, Business Flow와 상태 전이·금액·재고 규칙이 이 층의 몫입니다. 마지막은 Data와 Queue, Downstream API입니다. DB·Cache·Queue·외부 API·파일 저장소와 Downstream Credential, Egress, Data Policy가 여기 붙습니다. 여섯 층을 가로지르는 통제로 API Inventory, Secret·Key·Certificate Lifecycle, Logging, Monitoring, Audit이 따로 있습니다.
중요한 것은 Gateway와 Runtime 사이에 Direct-Origin이나 내부 우회 경로가 있으면 앞단 통제를 건너뛴다는 점입니다. NIST는 중앙 Gateway가 모든 요청을 통과한다는 전제가 깨지면 정책을 우회한다고 지적합니다. 내부 Service-to-Service 경로, 과거 Hostname, 직접 Origin 주소, 별도 Version이 같은 통제를 거치지 않는다면 "Gateway에서 설정했다"는 사실만으로 보호 범위가 증명되지 않습니다.[1]
무엇을 차단하고 무엇을 보조하며 무엇을 못 하는가
WAF 설명의 기준은 WAF 자체입니다. 일부 WAAP 제품이 Rate Limit, Bot Management, DDoS 방어, API Discovery를 함께 제공하더라도 그 기능을 WAF의 본질적인 능력으로 합치지 않았습니다. NIST는 WAF를 HTTP Payload와 Metadata에 대한 규칙 기반 통제로 설명합니다. OWASP CRS 역시 범용 탐지 규칙을 출발점으로 제공할 뿐 개별 API Schema나 업무 의미를 이해하지는 않습니다.[1][10]
API Gateway도 보안 표준의 단일 기능명이 아닙니다. Gateway가 JWT, mTLS, Rate Limit, Schema Validation을 지원하더라도 제품·배치 패턴·라이선스·정책 구성에 따라 실제 Enforcement 범위가 달라집니다. Gateway가 지원한다는 것과 해당 정책이 모든 Route에 강제된다는 것도 별개의 사실입니다.[1]
JWT 자체는 인증이나 권한이 아닙니다. RFC 7519가 정의하는 JWT는 Claims를 전달하는 표현 형식입니다. JWT는 JWS로 서명 또는 MAC 무결성을 보호하거나 JWE로 암호화합니다. 다만 JWT라는 이유만으로 내용이 암호화되지는 않습니다. Token을 수용하는 쪽은 Algorithm, 서명, Issuer, Audience, 시간 조건, Token Type을 검증해야 하며 검증된 Claims를 어떤 권한으로 해석할지는 별도의 정책입니다.[3]
mTLS는 TLS 연결 상대가 인증서에 대응하는 개인키를 보유했음을 증명합니다. RFC 8705의 Certificate-bound Access Token을 쓰면 탈취한 Bearer Token만 가진 공격자의 재사용도 제한됩니다. 그러나 인증서를 갖춘 서비스가 order/123을 읽어도 되는지, 그 서비스를 호출한 최종 사용자가 관리자 기능을 실행해도 되는지는 계속 Authorization이 판단합니다.[4]
OpenAPI나 JSON Schema 문서 자체도 요청을 차단하지 않습니다. Schema를 읽는 Validator가 Gateway나 Runtime에서 실제로 실행되고 불일치 요청을 거부해야 통제가 됩니다. 구조와 자료형이 올바르다는 것은 "이 사용자가 이 주문을 변경해도 된다"거나 "이 금액과 상태 전이가 업무상 타당하다"는 뜻이 아닙니다.[5]
- JWT
- JWT는 Claims를 전달하는 표현 형식이며 인증이나 권한 자체가 아닙니다. 수용하는 쪽이 Algorithm과 서명, Issuer, Audience, 시간 조건, Token Type을 검증해야 통제가 됩니다.
- mTLS
- mTLS는 TLS 연결 상대가 인증서에 대응하는 개인키를 보유했음을 증명하는 절차입니다. 그 상대가 어떤 자원을 다뤄도 되는지는 판정하지 않습니다.
- Schema Validation
- Schema Validation은 Gateway나 Runtime의 Validator가 계약에 어긋난 요청을 실제로 거부하는 동작입니다. OpenAPI 문서를 만들어 두는 일과는 다릅니다.
통제 | 주로 차단할 수 있음 | 완화 또는 보조함 | 직접 해결하지 못함 | 흔한 오구성 | Enforcement Point |
|---|---|---|---|---|---|
| WAF | Ruleset과 일치하는 SQL Injection, XSS, 경로 조작, 비정상 HTTP Payload | 반복되는 알려진 공격, 일부 Layer 7 이상 징후, Runtime 도달 전 공격면 축소 | Object·Function Authorization, 정상 형식의 Business Logic Abuse, Shadow API, 서비스 Identity | Detection-only 유지, 높은 차단 임계치, 과도한 Rule Exclusion, 오래된 CRS, 직접 Origin 우회 | CDN·Reverse Proxy·Load Balancer·Gateway 인접 Edge |
| API Gateway | 실제로 구성된 Route·Method 차단, TLS 정책, 내장 또는 연동된 인증·Rate·Schema 정책 | 정책 중앙화, Routing, 공통 로그, Token Context 전달 | 제품에 없는 기능, Gateway를 우회한 요청, 세밀한 Object Ownership과 Business 상태 판단 | Gateway니까 보호된다는 가정, Default-allow, 미등록 Route, 신뢰할 수 없는 Forwarded Identity Header, 환경별 정책 불일치 | API Ingress·Gateway·Service Mesh Ingress |
| Rate Limit | 같은 식별자와 정책 범위에서 설정한 호출량·속도·Burst 초과 | Brute Force, Scraping, Enumeration, Resource Abuse의 속도와 비용 | 전체 DDoS, 분산된 Low-and-slow, 임계치 이하의 Business Abuse, 한 번의 고비용 요청 | IP만 사용, 모든 Endpoint에 동일 임계치, 전체 트래픽 합계만 제한, 내부 호출 제외, Concurrency·비용 제한 부재 | Edge·Gateway·Runtime·Downstream 별도 적용 |
| Schema Validation | 계약에 없는 필드, 잘못된 자료형, 필수값 누락, 표현된 크기·범위 위반 | Parser 공격면 축소, Mass Assignment 가능성 저감, 과도한 Payload·응답 데이터 제어 | 사용자 권한, Object Ownership, 상태 전이, 가격·재고·예약 같은 Business 의미 | OpenAPI 문서만 만들고 강제하지 않음, 과도한 additionalProperties, format이 항상 검증된다는 가정, 역직렬화 후 검사 | Gateway Validator·Runtime·Serializer |
| JWT 검증 정책 | 위조·변조, 허용하지 않은 Algorithm, 잘못된 Issuer·Audience, 만료·사용시각 위반 Token | 검증된 Identity·Scope·Claims를 이후 Authorization 판단에 제공 | 사용자 인증 절차 자체, Object·Function Authorization, 일반 Bearer Token 탈취 후 Replay, Key Lifecycle | Decode만 하고 Verify하지 않음, iss·aud 생략, Algorithm 혼동, 공격자가 조작한 kid·jku 신뢰, 장기 Token, Token Logging | Gateway·Resource Server·Runtime |
| mTLS | 신뢰한 인증서를 제시하고 개인키 보유를 증명하지 못한 Peer의 TLS 연결 | Service Identity, B2B Client Authentication, Certificate-bound Token을 통한 탈취 Token Replay 저감 | 최종 사용자의 Object·Function Authorization, Business Intent, 정상 인증서를 갖춘 악성 Client | 같은 인증서 공유, 신뢰 CA 발급만 확인하고 Identity를 매핑하지 않음, Proxy 종료 후 위조 가능한 Header 사용, Token Binding 없이 Replay 방지 기대 | TLS Endpoint·Gateway·Service Mesh Sidecar·Runtime |
콘텐츠에 맞춰 전송 경로를 설계 — 파일의 갱신 방식에 맞춰 캐시를 나누고 엣지 전송 결과와 원본 부하를 함께 관측합니다.
위협별로 어느 통제가 직접 거부하는가
아래 표의 등급은 각 표준이 직접 제공하는 등급이 아닙니다. NIST SP 800-228의 API Protection Controls와 Gateway 패턴을 참고했습니다.[1] OWASP API Security Top 10 2023의 BOLA·Resource Consumption·BFLA·Sensitive Business Flows·Inventory도 참고했습니다.[2] RFC 7519의 JWT 표현과 검증 요구사항을 참고했습니다.[3] RFC 8705의 mTLS Client Authentication과 Certificate-bound Token도 참고했습니다.[4] OpenAPI 3.2.0과 JSON Schema의 계약·구조 검증 범위도 참고했습니다.[5] OWASP CRS의 일반 공격 탐지 규칙도 참고했습니다. 이 자료들이 설명한 능력·전제·한계를 이 글의 질문에 맞게 합성한 편집 판단입니다.
표에 세 가지 단서를 붙입니다. 첫째, mTLS가 일반 Bearer Token Replay를 막는 것은 Token이 RFC 8705 방식으로 인증서에 결합되고 Resource Server가 그 결합을 검증하는 경우에 한합니다. 둘째, Schema Validation은 선언되지 않은 속성이나 Mass Assignment 표면을 줄이지만 Object 소유권을 판단하지 않습니다. 셋째, Shadow API도 동일한 WAF를 실제로 통과한다면 일반 Ruleset의 보호를 받습니다. 다만 존재와 경로를 모르면 보호 여부가 증명되지 않습니다.
위협·오용 | WAF | Gateway | Rate | Schema | JWT | mTLS | 반드시 남겨야 할 통제 |
|---|---|---|---|---|---|---|---|
| Ruleset과 일치하는 알려진 HTTP 공격 패턴 | ● | △* | △ | △ | — | — | Secure Coding, Runtime Patch, Parameterized Query |
| API 계약을 벗어난 필드·자료형·크기·범위 | △ | △* | — | ● | — | — | Versioned Contract, Runtime Parser 일치 |
| 같은 Caller가 설정한 호출량·Burst 초과 | — | ●* | ● | — | △ | △ | 분산 Identity, Quota, 비용·Concurrency 제한 |
| 한 번의 고비용 요청, 과도한 Batch·Query·Concurrency | △ | △* | △ | △ | — | — | Timeout, Payload·Page·Query Bound, Circuit Breaker |
| Volumetric·분산 DDoS와 Upstream Saturation | △ | △* | △ | — | — | — | Network DDoS Mitigation, Capacity, Load Shedding |
| 위조·변조·잘못된 Issuer 또는 Audience·만료 JWT | — | ●* | — | — | ● | — | Issuer·Key 신뢰, Issuance·Revocation 정책 |
| 일반 Bearer Token 탈취 후 Replay | — | △* | △ | — | — | ● | 짧은 수명, Revocation, Sender-constrained Token |
| 신뢰하지 않은 Service·B2B Client의 연결 | — | ●* | — | — | △ | ● | Service Authorization, End-user Context |
| Object·Property-level Authorization 결함 | — | △* | △ | △ | △ | — | Runtime의 Object Ownership·Field Policy |
| Function-level Authorization 결함 | — | ●*/△ | △ | — | △ | — | Route·Method·Role·Business Function Policy |
| 정상 요청 형태의 Business Logic Abuse | — | △* | △ | — | △ | — | Flow별 Risk Rule, 상태 전이, Human Approval |
| Unknown·Shadow·Legacy API와 통제 우회 | △ | △* | — | — | — | — | API Inventory·Owner·Version·Retirement |
| Secret·Signing Key·인증서 수명주기 실패 | — | △* | — | — | — | — | KMS·PKI, Rotation, Revocation, Secret Management |
| Monitoring·Audit 공백 | △ | △* | △ | △ | △ | △ | 중앙 로그, Correlation, 보존, 경보, 정기 검토 |
여섯 통제가 남기는 Control Gap
OWASP는 BOLA를 각 Object를 다루는 Endpoint에서 검사해야 하는 코드·정책 문제로 분류합니다. JWT에서 사용자 ID를 읽는 것만으로는 요청한 Object에 대한 권한이 증명되지 않습니다.[2]
Function-level Authorization도 비슷합니다. Route가 존재하고 JWT가 유효하다는 사실과, 해당 사용자가 그 기능을 실행해도 된다는 사실은 다릅니다. Gateway에서 명시적인 Route·Method·Role 정책을 강제하더라도 제품 기능이나 정책 표현력이 부족하다면 Runtime에서 다시 확인해야 합니다.[7]
Business Logic Abuse는 더욱 업무 의존적입니다. OWASP가 예로 드는 재고 사재기, 예약 독점, Referral 자동화는 대개 형식이 정상이고 인증된 요청입니다. 따라서 Schema Validation이나 mTLS만으로는 악의와 업무 피해를 구분하지 못합니다.[8]
API Inventory는 이 글의 선행 조건이며 구체적인 구축 방법은 API Inventory 운영 문서가 다룹니다. 여기서는 보유 API, Version, Owner, 외부 노출과 Retirement 상태를 모르면 통제 적용 범위가 증명되지 않는다는 점까지만 씁니다. OWASP의 사례처럼 현행 API에만 Rate Limit을 적용하고 Beta Host를 남겨 두면 공격자는 보호되지 않은 경로를 고릅니다.[9]
Gap | 왜 여섯 통제로 끝나지 않는가 | 필요한 추가 통제 | 주 Enforcement Point |
|---|---|---|---|
| Object-level Authorization | 유효한 JWT를 가진 사용자가 다른 사용자의 Object ID를 요청합니다. WAF와 Schema는 Object 소유자를 알지 못합니다 | 호출 Identity, Tenant, Object Owner, Relationship을 매 요청마다 대조 | Runtime·Authorization Service·Data Access Layer |
| Function-level Authorization | 인증된 일반 사용자가 관리자 Route나 Method를 호출합니다 | Route·Method·Role·Scope와 실제 업무 기능을 이은 Default-deny 정책 | Gateway와 Runtime 양쪽 |
| Business Logic Abuse | 요청의 형식과 권한이 모두 정상이어도 재고 독점, 예약 선점, Referral 남용이 가능합니다 | 업무별 속도·순서·상태 전이·금액·재고·Device·Risk 규칙 | Business Logic·Fraud/Risk Engine |
| Unknown / Shadow API | 통제 대상 API를 모르면 WAF·Gateway·Rate·Schema 정책의 적용 여부도 증명하지 못합니다 | API Inventory, Owner, Version, Exposure, Retirement 상태 | API Governance·Platform·Security |
| Secret / Key Lifecycle | JWT와 mTLS는 Key·인증서의 안전한 생성·배포·회전·폐기·유출 대응을 대신하지 않습니다 | KMS·HSM·PKI·Secret Manager, Rotation, Revocation, Emergency Rollover | Identity·Platform·Security Operations |
| Monitoring / Audit | 개별 통제가 로그를 만들어도 사건 전체를 재구성하거나 책임 있는 변경을 증명하지는 못합니다 | 상관관계 ID, 중앙 로그, Decision Log, 보존 정책, 경보와 정기 검토 | 전 계층 횡단 |
전제조건과 흔한 오구성을 통제별로 점검합니다
공통 아키텍처에서는 다섯 가지를 봅니다. 외부·내부·Partner·Legacy API가 어느 Host와 Version에서 동작하는지 확인돼 있습니다. 모든 외부 요청이 의도한 Edge·Gateway를 통과하며 직접 Origin·과거 Hostname·별도 Port 우회가 차단돼 있습니다. 각 정책의 Authoritative Enforcement Point와 최종 책임 팀이 정해져 있습니다. Gateway와 Runtime의 정책이 충돌할 때 어느 쪽을 따를지 정해져 있습니다. 정책 변경을 코드·설정으로 Version 관리하고 환경별 Drift를 탐지합니다.
WAF에서는 사용 중인 HTTP Method와 Content-Type을 WAF가 실제로 해석하는지, 최신 지원 Ruleset과 Engine을 쓰는지, Detection Log와 실제 Blocking 동작을 따로 검증했는지 봅니다. Rule Exclusion은 Route·Parameter 단위로 최소화하고 사유·기한·Owner를 기록합니다. 정상 요청을 막는 False Positive와 응답 규칙에 의한 자기 서비스 거부 가능성을 시험했는지, WAF를 우회해 Backend로 직접 연결되지 않는지도 확인합니다.
API Gateway에서는 Route·Method가 명시적으로 등록되며 미등록 Route가 기본 거부되는지, "Gateway가 지원한다"가 아니라 JWT·mTLS·Rate·Schema 정책이 Route별로 강제되는지 확인합니다. Proxy가 전달하는 사용자·인증서 Header를 외부 Client가 직접 주입하지 못하게 막습니다. Gateway를 통과하지 않는 내부 호출에도 동등한 정책이나 별도 신뢰 경계를 둡니다. Gateway 장애와 정책 저장소 장애 시 Fail-open과 Fail-closed 동작을 미리 정합니다.
Rate Limit에서는 IP 외에 User·Client·Tenant·Route·Operation을 식별 기준으로 쓰는지, Login·검색·파일 업로드·결제처럼 비용과 위험이 다른 기능에 별도 정책을 두는지 봅니다. 초당 요청 수뿐 아니라 Burst, Concurrency, Batch Size, Page Size, 처리 시간과 외부 API 비용을 제한합니다. 분산 Gateway·Runtime 사이에서 Limit 상태가 일관되게 공유되어야 합니다. 내부 서비스와 특권 Client도 무제한으로 신뢰하지 않습니다. 제한 응답과 Retry 정책이 Client의 재시도 폭주를 만들지 않아야 합니다.
Schema Validation에서는 OpenAPI와 JSON Schema의 Version·Dialect를 명시했는지, 명세가 문서에만 있지 않고 Gateway 또는 Runtime Validator에서 강제되는지 봅니다. required, 자료형, 길이, 범위, 배열 크기, 추가 속성 정책을 정의합니다. format이 사용 중인 Validator에서 Assertion으로 동작하는지도 확인합니다. 역직렬화와 형 변환 전후에 검증 결과가 달라지지 않는지 시험합니다. 요청뿐 아니라 민감 정보가 과다 노출될 응답도 검증합니다. Schema 변경과 API Version·하위 호환성 정책은 서로 이어 둡니다.
JWT 검증에서는 허용 Algorithm을 Allowlist로 고정합니다. Token Decode와 Cryptographic Verification을 구분합니다. 서명과 iss·aud·exp, 필요하면 nbf와 Token Type까지 모두 검증합니다. kid·jku·x5u 같은 Header가 임의 Key 조회·SSRF·Injection 경로가 되지 않게 제한합니다. 서로 다른 Token 종류가 같은 Validation Rule로 혼동되지 않도록 명시적 Type을 둡니다. Access Token을 URL·Application Log·Error Report에 기록하지 않습니다. 짧은 Token 수명과 Key Rotation·Revocation·긴급 폐기 절차를 갖춥니다. JWT Claims를 최종 Object·Function Authorization 결과로 오인하지 않습니다.
mTLS에서는 신뢰 CA뿐 아니라 SAN 또는 인증서 속성을 실제 Client·Service Identity에 매핑합니다. Client·Service마다 식별 가능한 고유 인증서를 씁니다. 인증서 발급·갱신·폐기·유출 대응을 자동화하거나 운영 책임을 정합니다. Load Balancer에서 TLS가 종료될 때 Backend로 전달하는 인증서 Identity Metadata가 위조되지 않게 합니다. 모든 Hop에서 mTLS가 필요한지 Edge에서 한 번만 검증할지 Trust Boundary를 문서화합니다. Token Replay 방지가 목적이면 단순 mTLS가 아니라 Certificate-bound Token 검증까지 구성합니다. mTLS Identity와 최종 사용자 Identity를 같은 주체로 취급하지 않습니다.
Monitoring과 Audit에서는 각 거부 결정에 Control, Policy Version, Route, Client·User, 결과와 Reason Code가 남는지 봅니다. WAF·Gateway·Runtime·Authorization·Data 로그를 하나의 Correlation ID로 잇습니다. Token·Secret·개인정보가 로그에 남지 않도록 Redaction합니다. Block·Bypass·Policy Error·Fail-open 상태는 갈라서 경보합니다. 로그 보존 기간과 접근 권한, 무결성, 정기 검토 책임이 정해져 있고 통제 정책 변경과 예외 승인을 감사할 수 있어야 합니다.
서비스 앞단에서 요청을 분류하고 방어 — 요청과 차단 기록을 살펴 방어 규칙을 조정하고 인증서와 접근 통제를 함께 관리합니다.
공백은 열 가지 질문으로 검토합니다
아래 질문 중 하나라도 아니오라면 WAF·Gateway·JWT 도입 여부와 별개로 통제 공백이 남아 있습니다. 각 질문에는 답을 뒷받침할 Evidence가 붙습니다. 설정 화면의 스크린샷이 아니라 시험 결과와 로그가 Evidence입니다.
Gap | 검토 질문 | 필요한 Evidence |
|---|---|---|
| Object-level Authorization | Object ID와 속성마다 현재 사용자·Tenant·관계를 요청마다 검증하는가 | Authorization Test, Deny Log, Tenant 격리 Test |
| Function-level Authorization | 일반 사용자·관리자·Service Account별 허용 Route·Method·업무 기능이 Default-deny로 정의됐는가 | Route Policy, Role Matrix, Negative Test |
| Business Logic Abuse | 형식과 권한이 정상인 요청도 재고·예약·결제·쿠폰·Referral에 피해를 만드는 조건을 정의했는가 | Abuse Scenario, Flow Limit, 상태 전이 Test |
| Unknown / Shadow API | 모든 Host·Environment·Version·Owner·Exposure·Retirement 상태를 알고 있는가 | API Register 확인과 API Inventory 운영 문서 |
| Secret / Key Lifecycle | Signing Key·Client Secret·인증서의 생성·배포·회전·폐기·유출 대응 책임이 정해졌는가 | KMS·PKI Policy, Rotation Record, Emergency Runbook |
| Monitoring / Audit | 누가 어떤 Route와 Object에 어떤 결과를 냈는지 사후 재구성되는가 | Correlated Decision Log, Retention, Alert Test |
| Control Bypass | Direct Origin, 내부 Route, Beta·Legacy Host가 Edge·Gateway 정책을 우회하지 않는가 | Network Path Test, Route Inventory, Firewall Policy |
| Resource Bound | 호출 횟수 외에 처리 시간·Payload·Batch·Concurrency·외부 비용도 제한되는가 | Limit Configuration, Load·Abuse Test |
| Policy Failure | WAF·Gateway·Key Provider·Rate Store 장애 시 Fail-open 여부를 알고 있는가 | Failure Injection 결과, Break-glass Policy |
| Change Safety | 통제 정책 변경을 작은 범위에서 검증하고 되돌리는가 | Versioned Policy, Canary·Rollback Evidence |
통제 조합은 여섯 단계로 정합니다
먼저 보호해야 할 API가 식별돼 있다는 전제부터 확인합니다. 구체적인 구축법은 API Inventory 운영 문서가 다룹니다. 다음으로 Injection, 인증서 없는 Client, 탈취 Token Replay, BOLA, 재고 독점처럼 위협을 구체적인 문장으로 적습니다. 그다음 해당 위협을 가장 먼저 거부할 지점과 최종적으로 책임질 지점을 각각 정합니다. 그리고 WAF·Gateway·Rate·Schema·JWT·mTLS 중 직접 차단하는 통제와 보조 통제를 나눕니다. 이어서 Object·Function Authorization, Business Logic, Key Lifecycle, Monitoring처럼 여섯 통제로 해결되지 않는 항목에 Owner와 Evidence를 배정합니다. 마지막으로 정책이 실제 요청 경로에서 동작하는지 Negative Test와 우회 경로 Test로 확인합니다.
API 보안 통제는 많이 배치하는 것보다 각 통제가 어떤 요청을 어떤 조건에서 거부하는지 설명되는 상태가 중요합니다. 그 설명에서 Object Authorization, Business Logic, Shadow API, Key Lifecycle 또는 Audit이 빠져 있다면, 보안 제품이 여러 개 있어도 Architecture에는 아직 빈칸이 남아 있습니다.
