ほとんどの組織では、APIインベントリはアプリケーション文書、古いスキーマファイル、または個別チームが管理するリストに存在します。しかしアプリケーションはリリースのたびに変化します；新しいエンドポイントが追加され、古いものが忘れられ、テストパスが本番環境に残ります。セキュリティチームは通常、アプリケーションチームの後で実際のトラフィックでどのAPIがアクティブかを知ります。
このギャップはshadow APIとゾンビエンドポイントのリスクを拡大します。文書化されていないエンドポイントはWAFポリシーの範囲外に完全に置かれることがあります；使用されるべきでないエンドポイントがまだ到達可能かもしれません。攻撃者の視点からは、これらのエリアは低可視性、脆弱な保護であり、調査する価値があります。
外部から提供されたスキーマファイルだけに頼ることも不十分です。スキーマが最新でなければ実際のトラフィックと一致しません。アプリケーションチームはスキーマを更新せずにエンドポイントを変更したかもしれません、またはスキーマに現れないパスが本番環境で動作しているかもしれません。その場合、保護ポリシーは実際のアプリケーション動作ではなく、古い仮定に基づいています。
従来のネガティブセキュリティモデルだけではこの問題を解決できません。既知の攻撃パターンをブロックすることは重要ですが、APIセキュリティの実際の強みは許可されたメソッド、ヘッダー、パラメータ、MIMEタイプ、ボディフィールドを明示的に定義することにあります。ポジティブセキュリティなしに、未知だが一見有効な悪意のあるリクエストが問題なく通過する可能性があります。
TR7 API Discovery & Schemaはこのギャップを埋めます：実際のトラフィックからAPI動作を学習し、OpenAPIフローを通じてスキーマ生成またはスキーマからのルール生成をサポートし、ポジティブセキュリティコントロールをインラインに持ち込みます。
TR7はAPI discoveryをトラフィック学習、ポジティブスキーマ、サイズ・深さ制限、フィールドごとの検証と組み合わせて適用します。
TR7は実際のトラフィックからパスとメソッドの動作を学習し、エンドポイントパターンを構築できます。変数ID、日付、トークンを含むパスは、より読みやすいAPIインベントリに正規化されます。
メソッド、ヘッダー、クエリパラメータ、JSONキー、XMLエレメント、フォームフィールド、MIMEタイプのallow-listを定義できます。既知の悪いパターンを探すだけでなく、ポリシーは期待されるAPI動作を明示的に宣言します。
パス長、パス深さ、ヘッダー数、クエリ数、JSON深さ、XML深さ、rawボディサイズなどの制限を適用できます。これらの制限により、過大または過度に複雑なリクエストがバックエンドに到達する前に確認されます。
すべてのヘッダー、クエリパラメータ、フォームフィールド、ボディフィールドにregex検証を定義できます。メールアドレス、電話番号、ID、国コード、またはサービス固有の形式がフィールドレベルで確認されます。
API Discovery & Schemaは学習されたエンドポイントインベントリを適用可能なポジティブセキュリティルールに変換します。
TR7は受信リクエストからパスとメソッド情報を分析してエンドポイントパターンを導出できます。`/api/users/123`や`/api/users/456`のようなパスを単一の論理パターンにグループ化できます。このアプローチにより、文書にないが本番環境でアクティブに動作しているエンドポイントが可視化されます。APIインベントリは仮定ではなく、実際のトラフィック動作に基づきます。
TR7は学習されたAPI動作からOpenAPI互換スキーマを生成するワークフローをサポートするよう位置付けられています。逆方向では、ユーザーが提供したOpenAPIスキーマからTR7ルールを生成できます。この双方向モデルにより、実際のトラフィックと文書化されたAPIコントラクトのギャップが縮小されます。オペレーターはdiscoveryと適用の両方に同じプラットフォームを使用します。
各エンドポイントでGET、POST、PUT、DELETE、PATCHなどの許可されたメソッドのリストを定義できます。例えば、GETのみを期待するエンドポイントにPOSTが送信された場合、その動作をポリシー違反として扱うことができます。メソッドベースのallow-listはシンプルだが効果的なポジティブセキュリティ層です。不正またはサービス妨害目的のエンドポイント動作がより早期に検出されます。
許可されたヘッダーとクエリパラメータをエンドポイントごとに定義できます。各フィールドに名前、値の形式、regex検証を適用できます。予期しないヘッダーやパラメータはセキュリティスコア、アラート、ブロックに結び付けることができます。これによりAPIコントラクト外のデータが確認なしにバックエンドに渡されません。
TR7はJSONキー、XMLエレメント、フォームフィールドレベルでallow-listを構築できます。必須フィールドはmustArgsで定義でき、未知のフィールドはallowed listから除外できます。この構造は攻撃シグネチャを探すだけでなく、期待されるリクエストボディを記述します。APIエンドポイントは自身のコントラクトに近い形で保護されます。
フォームとrawボディの許可されたMIMEタイプのallow-listを定義できます。JSONを期待するエンドポイントに異なるコンテンツタイプでデータを送信することをポリシー違反として扱うことができます。このコントロールはファイルアップロードまたはフォームベースAPIで特に重要です。コンテンツタイプがセキュリティ決定への直接入力になります。
ヘッダー、クエリ文字列、フォーム、JSON、XML、rawボディの全体サイズ制限を適用できます。JSONとXMLのネスト深さコントロールにより、過度に深いペイロードがパーサーとバックエンドに負荷をかけるのを防ぎます。キー数、値数、フィールドごとの長さ、重複数などの制限も定義できます。これらのコントロールはセキュリティとパフォーマンスの両方に対する保護境界を作成します。
一部のエンドポイントはJSONまたはXMLボディをまったく受け入れる必要がない場合があります。TR7はエンドポイントごとにJSONまたはXMLボディの使用を完全に無効にするコントロールを提供できます。これにより予期しないボディ形式がバックエンドに到達するのを防ぎます。特に単純なGETエンドポイントやフォーム以外のトランザクションを受け入れないサービスに効果的です。
すべてのヘッダー、クエリパラメータ、フォームフィールド、ボディフィールドにregexベースの検証を適用できます。メールアドレス、電話番号、UUID、数値ID、国コード、または組織固有の形式をこの方法で確認します。形式外の値はアプリケーションに処理を任せるのではなく、エッジで検出されます。このモデルはAPIコントラクトのデータ形式の側面をセキュリティポリシーに取り込みます。
トラフィックから学習されたエンドポイントを既存の文書化されたAPIリストと比較できます。文書にないアクティブなエンドポイントはshadow API候補として、トラフィックを受けるべきでないがまだ受けているエンドポイントはゾンビエンドポイント候補としてフラグを立てることができます。これらの推奨事項は絶対的な実行決定としてではなく、オペレーターが確認する学習提案として提示されます。セキュリティチームはより素早く実際のAPI表面をマップできます。
時間の経過とともに、新しいJSONキー、新しいクエリパラメータ、または異なるメソッドの使用が現れる可能性があります。TR7は学習された動作と現在のスキーマポリシーの違いを可視化できます。これらの違いはアプリケーションバージョンの変更、誤動作するクライアント、または悪用の試みを示す可能性があります。オペレーターは変更を受け入れてスキーマに追加するか、ポリシー違反として扱うことができます。
API discoveryは特定の期間にどのエンドポイントがアクティブだったかを報告するのに役立ちます。「過去30日間にどのエンドポイントがトラフィックを受信しましたか？」などの質問はセキュリティとコンプライアンスチームにとって重要です。トラフィックベースのインベントリは静的文書よりも現実的な監査ベースラインを提供します。組織はAPI表面をライブの動作に対して監視します。
API discoveryとスキーマコントロールはパス、クエリ、ヘッダー、フォーム、JSON、XML、rawスコープにわたって動作します。
TR7スキーマコントロールはパス、クエリ、ヘッダー、フォーム、JSON、XML、rawフィールドをカバーします。各スコープは独自の制限、allow-list、検証ルールを持つことができます。したがってAPIセキュリティはボディだけでなく、完全なリクエスト表面で定義されます。
スキーマルールはcomplexInput、regex、numeric、boolean、enumSelectなどの異なるタイプで定義できます。シンプルなオン/オフコントロールと詳細なフィールドリストが同じDSL内で管理されます。オペレーターはAPI動作に基づいてルールタイプを選択します。
ルールはwebアプリケーション、apiエンドポイント、アプリケーションサーバーなど異なるターゲットレベルで適用できます。これにより一般的なサービスポリシーと単一エンドポイントに特化したスキーマの区別が可能です。適切なスコープを選択することで、繰り返しが少なく効果範囲が明確なポリシーが生成されます。
学習モデルはパスごとのノード、頻度カウント、子パス情報を保持できます。ホストまたはサービスグループごとのサマリー情報を抽出できます。この構造はAPI表面のどの部分がトラフィックが多い、少ない、または新しく現れているかを理解するのに役立ちます。
学習された変更は自動的に適用されるのではなく、管理者の承認に提出できます。オペレーターは新しいエンドポイント、新しいフィールド、新しいパターンの提案を確認し、適切なものをポリシーに変換します。このモデルは学習を制御なしの自動化ではなく、ガイド付きの意思決定サポートとして位置付けます。
過去のログファイルをバッチ処理して、遡及的にAPI動作を導出できます。これにより、discoveryプロセスがライブトラフィックのみに限定されません。以前のトラフィック期間、キャンペーンウィンドウ、またはインシデントの瞬間を別途調査できます。
セキュリティチームは実際のトラフィックから学習されたエンドポイントリストを既存のAPI文書と比較できます。文書にないアクティブなパスはshadow API候補として確認のために取り込まれます。
マイクロサービスチームは手動文書を待たずに、トラフィックから各サービスのエンドポイント動作を確認できます。TR7はパスとメソッドベースのインベントリをセキュリティポリシーに変換するのを支援します。
コンプライアンスチームは特定の期間にどのエンドポイントがアクティブだったかを報告できます。これにより、監査中にデータを処理するAPI表面がより明確に可視化されます。
テストまたはステージング用に開かれたエンドポイントが本番トラフィックに現れた場合、学習推奨事項の中で気づくことができます。運用チームはこれらのパスを閉じたり、制限したり、適切なセキュリティポリシーに配置したりできます。
トラフィックベースのエンドポイントインベントリ、shadow APIの可視性、ポジティブスキーマルール — お客様自身のサービスでのライブセットアップを一緒に確認しましょう。