URLの利用 (Pro)

URLロケーションは、レガシーなエンドポイントモデルの機能的な後継です。使い慣れたURL形式のフィールド(protocol、host、port、path、query、fragment)を保持し、Webアプリケーションの検出事項がどこに存在するかを識別するという同じ役割を果たします。

このページでは、URLロケーションを日常的に使い始めた際に変わる点、新しいUIの画面、そしてレガシーエンドポイントAPIの代わりに使用するAPIエンドポイントについて説明します。

URLサブタイプ#

すべてのURLはロケーションです。つまり、URLは次の両方を持ちます。

• 構造化されたURLフィールド(protocol、user_info、host、port、path、query、fragment、および重複排除に使用される hash)。
• 共有のロケーションフィールド(location_type="url"、表示・検索用の正規 location_value 文字列、タグ、継承タグ、メタデータ、アセットおよび検出事項へのReferenceリンク)。

URLを作成またはアップロードすると、DefectDojoはそれを構造化フィールドに解析し、URLの行とその親ロケーションの行を単一のトランザクションで書き込みます。URLの重複排除は構造化フィールド全体での完全一致で行われます。すべての構成要素が一致すれば同じURLとみなされ、標準的なデフォルトポートの畳み込みも適用されます(http://example.com:80/ と http://example.com/ は同じURLとして解決されます)。

Pro UIでの表示#

ロケーション機能が有効になると、ナビゲーションに以下が表示されます。

• ロケーション / すべて — URLと依存関係の両方のサブタイプにまたがる、すべてのロケーションの一覧です。種別、ステータス、アセット、検出事項、タグでフィルタできます。
• ロケーション / URL — URLロケーションのみに絞った一覧です。これは旧エンドポイントページに最も近いものです。
• 新しいURL — 構造化フィールド、タグ、任意のアセット/検出事項の関連付けを指定して単一のURLを作成するフォームです。
• アセットのロケーション — 任意のアセットで、ロケーションタブにはそのアセットに紐付くURLと依存関係が、ステータスごとの件数やクイックアクションとともに表示されます。

エンドポイントUIにあった一般的なワークフローは維持されています。

• ステータスの一括更新。 複数のURLロケーションを選択し、1つの操作でその検出事項への参照にステータス(アクティブ、緩和済み、誤検知、リスク受容済み、対象外)を適用できます。
• 既存URLをアセットに追加。 アセットのロケーションタブにある既存を追加を使うと、重複を作成する代わりに、すでにシステムに存在するURLをリンクできます。
• タグ。 URLロケーションに付与されたタグは、以前のエンドポイントのタグと同様に、それを参照する検出事項に継承タグとして伝播します。

ステータスモデル#

URLロケーションは、他のすべてのロケーションと同じ単一ステータスのラベルを使用します。

従来のEndpoint Statusモデルでは、複数のフラグを同時に立てることができました(例: mitigated=True と false_positive=True)。ロケーションでは、一度に1つのステータスのみが適用されます。エンドポイントから移行した場合、最も具体的なフラグが保持されます(エンドポイントからの移行のマッピング表を参照してください)。

Asset Referenceは、より単純なステータスを使用します。アセットレベルのステータスには詳細な監査情報が不要なため、アクティブまたは緩和済みのみです。

REST API#

レガシーエンドポイントAPIの代わりに、以下のエンドポイントを使用してください。

/api/v2/urls/ のフィルタには、構造化されたURLフィールドに加えて tag(s)、has_tags、Asset、そして host、Asset、アクティブな検出事項数による並べ替えが含まれます。

レガシーの /api/v2/endpoints/ エンドポイントは、互換シムを通じて引き続き読み取りトラフィックを処理します。何が保持され、シムが元の動作とどこで異なるかについては、エンドポイントからの移行を参照してください。レガシーエンドポイントへの書き込みは 403 を返すため、上記のエンドポイントに移行する必要があります。

スキャンからのURLのインポート#

スキャナーのインポートは、URLロケーションを自動的に作成します。パーサーが(かつてエンドポイントを出力していたのと同じ方法で)検出事項に対してURLを出力すると、インポーターは次の処理を行います。

1. 構造化フィールドが一致する既存のURLを検索するか、新規に作成します。
2. 検出事項をURLにリンクするFinding Referenceを、ステータスアクティブで作成します。
3. URLが親アセットにも表示されるよう、Asset Referenceを作成(または再利用)します。

以前エンドポイントを作成していたDefectDojoのパーサーは、Proにおいてロケーションを自動的に作成するよう更新されています。

動作が異なる点#

いくつかの細かな動作の変更に注意してください。

• URL/検出事項のペアごとに1つのステータス。 上記のとおり、複数フラグのEndpoint_Statusモデルは単一のステータスに集約されます。個々のフラグを独立して切り替えていたワークフローでは、単一の遷移を選ぶ必要があります。
• タグはURLではなくロケーションに属します。 URLサブタイプはそれ自体のタグセットを持たず、タグは親のロケーションに属します。APIでURLを読み取ると、tags フィールドは location.tags に由来します。
• 重複排除は正規URL単位であり、アセット単位ではありません。 同じURLを持つ2つのアセットは、単一の基盤となるURLロケーションを共有し、それぞれ(1つずつのAsset Referenceで)2回参照します。これは意図的な設計であり、アセット横断のレポートを可能にしています。
• 検出事項の endpoints フィールド。 このフラグが有効な場合、検出事項APIのこのフィールドは引き続き行を返しますが、それはエンドポイントテーブルではなくURLロケーションから投影されたものです。これは読み取り専用として扱い、書き込みは代わりに /api/v2/location_findings/ を通じて行ってください。