要求はどこで統制されるのか
それぞれの統制は防ぐ対象が異なります。WAFは要求が規則に一致する既知のHTTP攻撃パターンを主に取り除きます。Rate Limitは定めた呼び出し量・速度・Burstを超えた要求を拒みます。Schema ValidationはAPI契約から外れたField・型・大きさ・範囲を遮断します。厳格なJWT検証は、署名やMACが誤っている、あるいはIssuer・Audience・期限の条件が合わないTokenの受け入れを防ぎます。mTLSは、信頼した証明書とその秘密鍵を保持しない通信相手の接続を防ぎます。API Gatewayはこれらの方針を実行できる配置地点ですが、すべてのGateway製品が同じ保安機能を提供するわけではありません。[1]
この六つをすべて適用してもAPIの保安は完成しません。利用者が他人の注文を照会する問題、一般利用者が管理者機能を呼び出す問題、正常な要求の形で在庫や予約を独占する問題は、依然として業務ロジックと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の確認がここにあります。五つ目は業務ロジックと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、正常な形の業務ロジック濫用、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と業務状態の判断 | 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、閾値以下の業務濫用、一度の高費用要求 | IPのみを使用、全Endpointに同一閾値、全体量だけを制限、内部呼び出しの除外、Concurrency・費用制限の不在 | Edge・Gateway・Runtime・Downstreamで個別に適用 |
| Schema Validation | 契約にないField、誤った型、必須値の欠落、宣言された大きさ・範囲の違反 | Parser攻撃面の縮小、Mass Assignment可能性の低減、過大なPayload・応答データの制御 | 利用者の権限、Object Ownership、状態遷移、価格・在庫・予約のような業務的意味 | OpenAPI文書だけ作り強制しない、過剰なadditionalProperties、formatが常に検証されるという前提、逆直列化後の検査 | Gateway Validator・Runtime・Serializer |
| JWT検証方針 | 偽造・改変、許可しないAlgorithm、誤ったIssuer・Audience、期限切れや使用時刻違反のToken | 検証済みのIdentity・Scope・Claimsを後続のAuthorization判断へ提供 | 利用者認証の手続きそのもの、Object・Function Authorization、一般Bearer Token窃取後のReplay、鍵の生存期間 | Decodeのみで検証しない、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、業務上の意図、正当な証明書を備えた悪性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契約から外れたField・型・大きさ・範囲 | △ | △* | — | ● | — | — | 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・鍵の信頼、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・業務機能の方針 |
| 正常な形の要求による業務ロジック濫用 | — | △* | △ | — | △ | — | Flowごとのリスク規則、状態遷移、人の承認 |
| 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]
業務ロジックの濫用はさらに業務に依存します。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、関係を要求ごとに照合 | Runtime・Authorization Service・Data Access Layer |
| Function-level Authorization | 認証済みの一般利用者が管理者用のRouteやMethodを呼び出します | Route・Method・Role・Scopeと実際の業務機能を結んだDefault-deny方針 | GatewayとRuntimeの両方 |
| 業務ロジックの濫用 | 要求の形式と権限が正常でも、在庫の買い占め、予約の先取り、Referralの濫用が可能です | 業務ごとの速度・順序・状態遷移・金額・在庫・Device・リスク規則 | 業務ロジック・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は鍵・証明書の安全な生成・配布・回転・廃棄・漏えい対応を代替しません | 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が任意の鍵照会・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 |
| 業務ロジックの濫用 | 形式と権限が正常な要求でも在庫・予約・決済・クーポン・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の再利用、BOLA、在庫の独占のように脅威を具体的な文で書きます。そのうえで、その脅威を最初に拒む地点と最終的に責任を負う地点をそれぞれ決めます。そしてWAF・Gateway・Rate・Schema・JWT・mTLSのうち直接遮断する統制と補助の統制を分けます。続いてObject・Function Authorization、業務ロジック、鍵の生存期間、Monitoringのように六つでは解決しない項目にOwnerとEvidenceを割り当てます。最後に、方針が実際の要求経路で動くかをNegative Testと迂回経路Testで確認します。
APIの保安統制は多く配置することより、各統制がどの要求をどの条件で拒むかを説明できる状態が重要です。その説明からObject Authorization、業務ロジック、Shadow API、鍵の生存期間、あるいはAuditが抜けているなら、保安製品がいくつあってもArchitectureにはまだ空欄が残っています。
