要約

  • IDMEFv2 HTTPS transport revision 07は、受信者が永続保存するか、確認を返した次段へ引き渡すまで2xxを返さないよう求める。したがって204 No Contentは単なる通信成功より強い受領証になる。
  • アラートは1件ずつPOSTされる一方、再送の冪等性、重複を記憶する期間、最終的な調査結果は規定されない。送信者の身元と必須Alert IDを結ぶ台帳が別途必要だ。

書き込み成功と送信側の確信は同時ではない

Analyzerがアラートを送り、Managerがデータベースへのcommitを終えたとする。204を返す途中で接続が失われれば、Analyzerは結果を観測できない。同じPOSTを送り直せば、既に受理済みの事象が二重に相関され、二つの自動対応を起動するかもしれない。送り直さなければ、本当にcommit前だった場合に欠落する。

9月27日付の Transport of IDMEFv2 Messages over HTTPS は個人Internet-Draftである。Datatrackerはstreamなし、IETF標準化過程での正式な地位なしと明記する。revision 07の表紙はStandards Trackを意図し、承認された場合にだけRFC 4767を置き換えるとしている。現時点の文書は変更可能な提案にすぎない。

revision 07本文 は、1つのIDMEFv2メッセージを1つのPOSTに載せ、複数POSTの並行送信を認める。不正なメッセージには4xx、受信側の処理不能には5xxを使う。そしてHTTP codeをacknowledgementと位置付け、ディスクやDBへの保存、または確認済みの次段への中継が済むまで2xxを返さないよう求める。

付録の204例にbodyはないが、意味は空ではない。RFC 9110 が示す一般的な204は、要求された操作が成功し、返す内容がないことを表す。ドラフトはその「成功」に安全な取り扱いというアプリケーション固有の下限を加える。

必須IDは、重複ポリシーそのものではない

対になる IDMEFv2 data model revision 08 には、トップレベルのUUID IDとCreateTimeが必須である。送信者の証明書IDと組み合わせれば、有力な重複キーになる。しかしtransport draftは、IDを何日覚えるか、同一内容の再送に再び2xxを返すか、同じIDで異なる内容が来たら訂正と衝突のどちらにするかを決めていない。

POSTにも自動的な冪等性はない。RFC 9110 は、アプリケーションの意味が冪等だと分かるか、最初の要求が適用されなかったと検出できない限り、非冪等methodを自動再送しないよう述べる。RFC 9205 がHTTP上のprotocolに固有の意味設計を求める理由もここにある。

相互TLSは別の境界を守る。ドラフトは RFC 5280 と RFC 6125 を参照し、双方のX.509証明書、完全なpath validation、wildcardなしのDNS-ID、承認済みpeer証明書リストを求める。それは誰を受け入れたかの根拠であって、アラートの真偽、重複、調査完了の証明ではない。

連合の共通記録は三層に分けるべきだ。受領証にはpeer、Alert ID、payload hash、受信時刻と永続化時刻を残す。重複判断には初回・最終観測、完全一致、ID衝突、選んだ処置を残す。その後のdispositionが相関、却下、エスカレーション、終結を記録する。各組織が自分のSIEMを保ったままでも、この境界は共有できる。

Running-Code Primacy に従えば、証拠は仕様への賛同ではなく、実際の保存、再送判定、処置の列にある。Minimum Initial Specification, Localized Future Decision は共通受領証を小さく保ち、対応判断を各現場に残す設計を支える。On Authority, Belief, and the Internet’s Addressing System が示す通り、証明書、HTTP応答、インシデント判断は別の主体が発行する表現であり、権威を混ぜてはいけない。