각 통제는 막는 대상이 다르다. WAF는 요청이 규칙과 일치하는 알려진 HTTP 공격 패턴을 주로 걸러낸다. Rate Limit은 정해진 호출량·속도·Burst를 넘은 요청을 거부한다. Schema Validation은 API 계약을 벗어난 필드·자료형·크기·범위를 차단한다. 엄격한 JWT 검증은 서명이나 MAC이 잘못됐거나 Issuer·Audience·만료 조건이 맞지 않는 토큰의 수용을 막는다. mTLS는 신뢰한 인증서와 그 개인키를 보유하지 않은 통신 상대의 연결을 막는다. API Gateway는 이 정책들을 실행할 수 있는 배치 지점이지만 모든 Gateway 제품이 동일한 보안 기능을 제공하는 것은 아니다. (NIST Publications)
이 여섯 가지를 모두 적용해도 API 보안이 완성되지는 않는다. 사용자가 다른 사람의 주문을 조회하는 문제, 일반 사용자가 관리자 기능을 호출하는 문제, 정상적인 요청 모양으로 재고나 예약을 독점하는 문제는 여전히 Business Logic과 Authorization에서 판단해야 한다. 알려지지 않은 API, 키·인증서 수명주기, 로그와 감사도 별도의 책임 영역이다. (OWASP Foundation)
따라서 “WAF를 붙였는가” 또는 “Gateway를 도입했는가”보다 먼저 확인할 것은 어떤 위협을 어느 지점에서 거부하며 그 뒤에 어떤 공백이 남는가다.
요청은 어디에서 통제되는가
구조 다이어그램
Client / Calling Service
│
├─ JWT
│ └─ Claims와 Token Context
│ ※ JWT 자체가 사용자 인증·권한 판정을 수행하는 것은 아님
│
└─ Client Certificate
└─ mTLS에서 인증서 개인키 보유 증명
│
│ HTTPS / optional mTLS
▼
┌──────────────────────────────────────────────┐
│ Edge / WAF │
│ │
│ · HTTP Header·URI·Body 규칙 검사 │
│ · 알려진 Injection·Traversal 등 탐지 │
│ · 일부 Layer 7 이상 징후 완화 │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ API Gateway / Ingress │
│ │
│ · Route·Method 선택 │
│ · 제품과 구성에 따라 JWT·mTLS·Rate·Schema │
│ 정책 실행 │
│ · Routing·Logging·Telemetry │
│ │
│ ※ 위 기능이 모두 표준 내장된다고 가정하지 않음 │
└──────────────────────────────────────────────┘
│
│ Direct-Origin·내부 우회 경로가
│ 있으면 앞단 통제를 건너뛸 수 있음
▼
┌──────────────────────────────────────────────┐
│ Runtime / API Handler │
│ │
│ · Authoritative 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 · AuditNIST는 중앙 Gateway가 모든 요청을 통과한다는 전제가 깨지면 정책을 우회할 수 있다고 지적한다. 내부 Service-to-Service 경로, 과거 Hostname, 직접 Origin 주소, 별도 Version이 동일한 통제를 거치지 않는다면 “Gateway에서 설정했다”는 사실만으로 보호 범위를 증명할 수 없다. (NIST Publications)
Can / Assist / Cannot
| 통제 | 주로 차단할 수 있음 | 완화 또는 보조함 | 직접 해결하지 못함 | 필요한 전제조건 | 흔한 오구성 | Enforcement Point |
|---|---|---|---|---|---|---|
| WAF | Ruleset과 일치하는 SQL Injection, XSS, 경로 조작, 비정상 HTTP Payload | 반복되는 알려진 공격, 일부 Layer 7 이상 징후, Runtime 도달 전 공격면 축소 | Object·Function Authorization, 정상 형식의 Business Logic Abuse, Shadow API, 서비스 Identity | 모든 대상 트래픽이 WAF를 통과하고 TLS·Content-Type을 검사할 수 있어야 함. 최신 Ruleset과 애플리케이션별 Tuning 필요 | 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 상태 판단 | 모든 Route와 Backend가 등록되고 직접 접근이 차단돼야 함. Default-deny와 정책 배포·Drift 관리 필요 | “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, 한 번의 고비용 요청 | User·Client·Route·Operation·비용 특성에 맞는 Key와 Window 필요. 분산 환경의 일관된 상태 필요 | IP만 사용, 모든 Endpoint에 동일 임계치, 전체 트래픽 합계만 제한, 내부 호출 제외, Concurrency·비용 제한 부재 | Edge·Gateway·Runtime·Downstream 별도 적용 |
| Schema Validation | 계약에 없는 필드, 잘못된 자료형, 필수값 누락, 표현된 크기·범위 위반 | Parser 공격면 축소, Mass Assignment 가능성 저감, 과도한 Payload·응답 데이터 제어 | 사용자 권한, Object Ownership, 상태 전이, 가격·재고·예약 같은 Business 의미 | 정확하고 Version된 Schema와 실제 Validator가 필요. 요청·응답, Gateway·Runtime 간 Dialect 일치 필요 | OpenAPI 문서만 만들고 강제하지 않음, 과도한 additionalProperties, format이 항상 검증된다고 가정, 역직렬화 후 검사 |
Gateway Validator·Runtime·Serializer |
| JWT 검증 정책 | 위조·변조, 허용하지 않은 Algorithm, 잘못된 Issuer·Audience, 만료·사용시각 위반 Token | 검증된 Identity·Scope·Claims를 이후 Authorization 판단에 제공 | 사용자 인증 절차 자체, Object·Function Authorization, 일반 Bearer Token 탈취 후 Replay, Key Lifecycle | Algorithm Allowlist, 서명 검증, iss·aud·exp·nbf·Token Type 검증, 신뢰할 Key Source와 TLS 필요 |
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 | Trust Anchor, 인증서 Identity Mapping, 고유 인증서, Rotation·Revocation, 모든 Hop의 검증 필요 | 같은 인증서 공유, “신뢰 CA 발급”만 확인하고 Identity를 매핑하지 않음, Proxy 종료 후 위조 가능한 Header 사용, Token Binding 없이 Replay 방지 기대 | TLS Endpoint·Gateway·Service Mesh Sidecar·Runtime |
WAF 설명의 기준은 WAF 자체다. 일부 WAAP 제품이 Rate Limit, Bot Management, DDoS 방어, API Discovery를 함께 제공하더라도 그 기능을 WAF의 본질적인 능력으로 합치지 않았다. NIST는 WAF를 HTTP Payload와 Metadata에 대한 규칙 기반 통제로 설명하며 OWASP CRS 역시 범용 탐지 규칙을 출발점으로 제공할 뿐 개별 API Schema나 업무 의미를 이해하지는 않는다. (NIST Publications)
API Gateway도 보안 표준의 단일 기능명이 아니다. Gateway가 JWT, mTLS, Rate Limit, Schema Validation을 지원할 수는 있지만 제품·배치 패턴·라이선스·정책 구성에 따라 실제 Enforcement 범위가 달라진다. Gateway가 지원한다는 것과 해당 정책이 모든 Route에 강제된다는 것도 별개의 사실이다. (NIST Publications)
JWT 자체는 인증이나 권한이 아니다. RFC 7519가 정의하는 JWT는 Claims를 전달하는 표현 형식이다. JWT는 JWS를 통해 서명 또는 MAC으로 무결성을 보호하거나 JWE로 암호화할 수 있지만 JWT라는 이유만으로 내용이 암호화되는 것은 아니다. Token을 수용하는 쪽은 Algorithm, 서명, Issuer, Audience, 시간 조건, Token Type을 검증해야 하며 검증된 Claims를 어떤 권한으로 해석할지는 별도의 정책이다. (RFC Editor)
mTLS는 TLS 연결 상대가 인증서에 대응하는 개인키를 보유했음을 증명한다. RFC 8705의 Certificate-bound Access Token을 사용하면 탈취한 Bearer Token만 가진 공격자가 Token을 재사용하는 것도 제한할 수 있다. 그러나 인증서를 가진 서비스가 order/123을 읽어도 되는지, 그 서비스를 호출한 최종 사용자가 관리자 기능을 실행할 수 있는지는 계속 Authorization에서 판단해야 한다. (RFC Editor)
OpenAPI나 JSON Schema 문서 자체도 요청을 차단하지 않는다. Schema를 읽는 Validator가 Gateway나 Runtime에서 실제로 실행되고 불일치 요청을 거부해야 통제가 된다. 구조와 자료형이 올바르다는 것은 “이 사용자가 이 주문을 변경해도 된다”거나 “이 금액과 상태 전이가 업무상 타당하다”는 뜻이 아니다. (OpenAPI Initiative Publications)
Threat × Control Capability Matrix
표의 등급은 각 표준이 직접 제공하는 등급이 아니다. 공식 원문이 설명한 능력·전제·한계를 이 글의 질문에 맞게 합성한 Editorial Assessment다.
- ● 주로 차단: 조건에 맞는 요청을 해당 통제가 직접 거부할 수 있음
- △ 보조·완화: 가능성이나 영향을 낮추거나 다른 통제에 판단 재료를 제공함
- — 직접 해결 못함
- *: Gateway 제품에 해당 기능이 존재하고 모든 대상 Route에서 정책이 실제로 강제되는 경우
| 위협·오용 | WAF | API Gateway | Rate Limit | Schema Validation | JWT 검증 | mTLS | 반드시 남겨야 할 통제 |
|---|---|---|---|---|---|---|---|
| Ruleset과 일치하는 알려진 HTTP 공격 패턴 | ● [S1,S6] | △* [S1] | △ [S1] | △ [S1,S5] | — | — | Secure Coding, Runtime Patch, Parameterized Query |
| API 계약을 벗어난 필드·자료형·크기·범위 | △ [S1] | △* [S1] | — | ● [S1,S5] | — | — | Versioned Contract, Runtime Parser 일치 |
| 같은 Caller가 설정한 호출량·Burst 초과 | — | ●* [S1] | ● [S1,S2] | — | △ [S1,S3] | △ [S1,S4] | 분산 Identity, Quota, 비용·Concurrency 제한 |
| 한 번의 고비용 요청, 과도한 Batch·Query·Concurrency | △ [S1] | △* [S1] | △ [S1,S2] | △ [S1,S5] | — | — | Timeout, Payload·Page·Query Bound, Circuit Breaker |
| Volumetric·분산 DDoS와 Upstream Saturation | △ [S1] | △* [S1] | △ [S1,S2] | — | — | — | Network DDoS Mitigation, Capacity, Load Shedding |
| 위조·변조·잘못된 Issuer/Audience·만료 JWT | — | ●* [S1,S3] | — | — | ● [S3] | — | Issuer·Key 신뢰, Issuance·Revocation 정책 |
| 일반 Bearer Token 탈취 후 Replay | — | △* [S4] | △ [S1] | — | — [S3,S4] | ●¹ [S4] | 짧은 수명, Revocation, Sender-constrained Token |
| 신뢰하지 않은 Service·B2B Client의 연결 | — | ●* [S1,S4] | — | — | △ [S1,S3] | ● [S4] | Service Authorization, End-user Context |
| Object·Property-level Authorization 결함 | — [S2] | △* [S1,S2] | △ [S2] | △² [S1,S2] | △ [S1,S3] | — | Runtime의 Object Ownership·Field Policy |
| Function-level Authorization 결함 | — [S2] | ●*/△ [S1,S2] | △ [S2] | — | △ [S1,S3] | — | Route·Method·Role·Business Function Policy |
| 정상 요청 형태의 Business Logic Abuse | — [S2] | △* [S2] | △ [S2] | — [S2,S5] | △ [S2,S3] | — | Flow별 Risk Rule, 상태 전이, Human Approval |
| Unknown·Shadow·Legacy API와 통제 우회 | △³ [S1,S2] | △* [S1,S2] | — | — | — | — | API Inventory·Owner·Version·Retirement |
| Secret·Signing Key·인증서 수명주기 실패 | — | △* | — | — | — [S3] | — [S4] | KMS·PKI, Rotation, Revocation, Secret Management |
| Monitoring·Audit 공백 | △ [S1] | △* [S1] | △ [S1] | △ [S1] | △ [S3] | △ [S4] | 중앙 로그, Correlation, 보존, 경보, 정기 검토 |
- mTLS가 일반 Bearer Token Replay를 막는 것은 아니다. Token이 RFC 8705 방식으로 인증서에 결합되고 Resource Server가 결합을 검증하는 경우에 해당한다.
- Schema Validation은 선언되지 않은 속성이나 Mass Assignment 표면을 줄일 수 있지만 Object 소유권을 판단하지 않는다.
- Shadow API도 동일한 WAF를 실제로 통과한다면 일반 Ruleset의 보호는 받을 수 있다. 그러나 존재와 경로를 모르면 보호 여부를 증명할 수 없다.
Matrix Source Key
- [S1] NIST SP 800-228 Update 1: API Protection Controls, Gateway 패턴, WAF·Schema·Rate·Authorization 분리. (NIST CSRC)
- [S2] OWASP API Security Top 10 2023: BOLA, Resource Consumption, BFLA, Sensitive Business Flows, Inventory. (OWASP Foundation)
- [S3] RFC 7519·8725: JWT 표현과 검증 요구사항. (RFC Editor)
- [S4] RFC 8705: mTLS Client Authentication과 Certificate-bound Token. (RFC Editor)
- [S5] OpenAPI 3.2.0·JSON Schema Draft 2020-12: 계약과 구조 검증 범위. (OpenAPI Initiative Publications)
- [S6] OWASP CRS: 일반 공격 탐지 규칙, Anomaly Scoring과 Tuning. (OWASP Foundation)
여섯 통제가 남기는 Control Gap
| 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, 보존 정책, 경보와 정기 검토 | 전 계층 횡단 |
OWASP는 BOLA를 각 Object를 다루는 Endpoint에서 검사해야 하는 코드·정책 문제로 분류한다. JWT에서 사용자 ID를 읽는 것만으로는 요청한 Object에 대한 권한이 증명되지 않는다. (OWASP Foundation)
Function-level Authorization도 비슷하다. Route가 존재하고 JWT가 유효하다는 사실과, 해당 사용자가 그 기능을 실행해도 된다는 사실은 다르다. Gateway에서 명시적인 Route·Method·Role 정책을 강제할 수 있지만 제품 기능이나 정책 표현력이 부족하다면 Runtime에서 다시 확인해야 한다. (OWASP Foundation)
Business Logic Abuse는 더욱 업무 의존적이다. OWASP가 예로 드는 재고 사재기, 예약 독점, Referral 자동화는 일반적으로 형식이 정상이고 인증된 요청이다. 따라서 Schema Validation이나 mTLS만으로는 악의와 업무 피해를 구분할 수 없다. (OWASP Foundation)
API Inventory는 이 글의 선행 조건이며 구체적인 구축 방법은 「운영 중인 API를 모두 모르면 어떤 보안 문제가 생길까」에서 다룬다. 여기서는 보유 API, Version, Owner, 외부 노출과 Retirement 상태를 모르면 통제 적용 범위를 증명할 수 없다는 점까지만 사용한다. OWASP의 사례처럼 현행 API에만 Rate Limit을 적용하고 Beta Host를 남겨두면 공격자는 보호되지 않은 경로를 선택할 수 있다. (OWASP Foundation)
Prerequisite / Misconfiguration Checklist
공통 아키텍처
- 외부·내부·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 상태를 구분해 경보한다.
- 로그 보존 기간, 접근 권한, 무결성, 정기 검토 책임이 정해져 있다.
- 통제 정책 변경과 예외 승인을 감사할 수 있다.
Control Gap Review Checklist
아래 질문 중 하나라도 아니오라면 WAF·Gateway·JWT 도입 여부와 별개로 통제 공백이 남아 있다.
| 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에는 아직 빈칸이 남아 있다.