要約

  • RFC 5209 の assessment は、端末の特定機能から姿勢を集め、該当する検証器が準拠方針に照らして評価する過程である。判定には観測範囲、方針版、時刻が付く。
  • 再評価は例外処理ではない。利用者がファイアウォールを止めたり、方針が新しいパッチを要求したりすれば、以前の合格は現在を説明できなくなる。
  • 姿勢評価、認可判断、ネットワークでの強制は異なる権限面である。NEA の合格から、規則の導入や現在の準拠を自動的に導くことはできない。

正しかった判定が古くなる瞬間

9時、管理対象のノートPCが姿勢評価に応答する。ファイアウォール用 Collector は保護が有効だと報告し、更新用 Collector は必要なパッチ版を返す。各 Validator は方針42版で合格とし、Broker Server が全体判定を「準拠」にまとめる。外側のアクセス系は通常接続を許可した。

9時17分、利用者が試験のためホスト・ファイアウォールを無効にする。Collector は変化を検出して通知するが、Broker Client は再起動中で、通知は届かない。9時25分になっても管理画面は緑のままだ。9時の記録は改ざんされておらず、その時点の判断も誤りではない。

それでも「現在準拠」という表示には根拠がない。履歴である「9時に、応答した機能を42版で評価して準拠と判断した」が、時刻を失って現在形へ変換されたからである。

これは実在する導入事例や事故の記述ではなく、境界を示すための構成例である。ただし変化の種類は RFC 5209 自身が挙げている。文書は、以前準拠とされた端末でも、利用者が必要なホスト・ファイアウォールを止めれば非準拠になり得るため、再評価が必要だと説明する。

姿勢は端末そのものではない

2008年の RFC 5209 は Informational 文書であり、NEA の問題、用語、参照モデル、利用場面、後続プロトコルへの要件を記す。特定製品の完全な設計図でも、単一の万能プロトコルでもない。

Assessment の定義は限定的である。端末にある「一組の機能」について姿勢を集め、それを適切な Validator が準拠方針と比較する。「一組」は全機能を意味しない。姿勢とは方針に関係するハードウェアまたはソフトウェアの構成・状態であり、端末の現実を丸ごと複製したものでもない。

メッセージにも役割がある。Posture Attribute は観測した構成や稼働状態を表し、Request Attribute は情報を求める。Result Attribute は評価の結論を伝え、Remediation Attribute は修正方法を伝える。要求を送った事実は回答を得た証拠ではなく、修復指示を受けた事実は修復の完了証明ではない。

Result Attribute は通常、評価の最後に生成され、端末が準拠していると「みなされた」かを示す。この言葉を消してはいけない。判定は入力と方針から作られたものであり、機械に永久に埋め込まれた性質ではない。

部品を分けたモデルは、証拠も分ける

NEA Client には複数の Posture Collector、Posture Broker Client、Posture Transport Client がある。NEA Server 側には Posture Validator、Posture Broker Server、Posture Transport Server が置かれる。

Collector は特定の端末機能を観測し、要求に答え、結果や修復情報を受け取り、姿勢変化を Broker Client に知らせる。Broker Client は Collector の登録簿を持ち、メッセージを配り、応答を束ねる。Transport Client は保護された通信路を提供する。

Validator は受け取った属性を方針で評価し、必要なら追加情報を求め、機能別の結果や修復指示を作る。Broker Server は Validator を登録し、PA メッセージを振り分け、個別結果と方針から全体判定を計算する。Transport Server は対話を運ぶ。

この分離により、各部品が証明できる範囲も明確になる。通信路が安全でも、必要な Collector がすべて存在するとは限らない。Broker が四つの結果を正確に集約しても、応答しなかった五つ目の機能は見えない。Validator が規則を正しく実行しても、古い属性を新しくすることはできない。

したがって監査記録には、期待した Collector、実際に登録した Collector、応答したもの、観測時刻、取得属性、利用した Validator、方針版、欠落や不明を全体判定でどう扱ったかを残す必要がある。

空欄を合格に変換してはならない

後続の PA-TNC 仕様 RFC 5792 は、実装間で対応する vendor-specific attribute が異なっても相互運用するよう求める。未対応の要求にはエラーを返すことができ、条件によって Collector は要求された属性の全部、一部、または何も送らないことがある。版番号の一部には unknown や unavailable を表す値も用意されている。

これは拡張性のために妥当な設計である。一方、評価側は coverage を明示しなければならない。方針が五つの機能を要求し、四つだけが観測できた場合、四つの合格は五つ目の合格ではない。未対応、プライバシー上の非開示、機能不在、Collector の故障、設定漏れは別々の状態である。

どの状態を許容するかはローカル方針が決めてよい。拒否、隔離、限定接続、期限付きの assertion、責任者が承認した例外などがあり得る。しかし「許容した」と「観測して健全だった」は同じではない。例外を採用したなら、例外として記録すべきだ。

単純な compliant=true より、四機能合格／五機能必須／一件は10時まで例外 のほうが運用に強い。前者は美しいが再評価できず、後者は不完全さを次の行動へ変えられる。

再評価が時間をつなぐ

RFC 5209 は、接続時評価に続く主要用途として posture reassessment を置く。準拠方針も端末姿勢も時間とともに変わり、当初準拠していたシステムが後で非準拠になるからである。利用者が保護機能を無効にする例に加え、パッチ公開後に方針が更新され、従来版が条件を満たさなくなる例も示す。

端末側では Collector が変化を Broker Client に通知し、再評価を起動できる。サーバ側では Validator が帯域外の方針・脅威情報の更新を知り、Broker Server へ通知できる。導入環境によっては時刻、重要サービスへのアクセス、管理操作も契機になる。

つまり現在の準拠を主張するなら、評価結果だけでなく trigger path の健全性も必要である。変化の購読は有効だったか。再起動中の通知は永続化されたか。再評価は待ち行列に入り、開始し、終わったか。新しい方針は全 Validator に届いたか。

成功した評価だけを長期保存し、失敗した通知を捨てる仕組みは、証拠を緑へ偏らせる。過去の合格は残り続ける一方、それを現在へ延長してはいけない理由だけが消える。

Assertion Attribute による過去評価の再利用も同じである。日付と署名を持つ assertion を一定期間受け入れることは通信量を減らせる。しかし発行者、端末との結び付き、対象方針・機能、有効期限、署名検証、再評価を強制する変更条件が必要だ。既知の姿勢変化を無視する受入規則は、署名が強くても弱い。

安全な通信路は、観測範囲を広げない

NEA のプロトコル群は対話と属性を保護し、改変、リプレイ、盗難などの脅威を扱う。古い合格属性が新しいものとして再生されないことは、現在の判断に欠かせない。

しかし新鮮なメッセージでも内容は限定される。Collector が一機能だけを見るなら、今届いた属性も一機能だけの証拠である。認証済みの端末が、完全な観測能力を持つとは限らない。暗号は発言者と内容、順序を信頼モデルの中で守れるが、欠けた観測を生成できない。

証拠連鎖は次のように分けるべきだ。

端末・会話を結ぶ → 必要 Collector を決める → 属性を時刻付きで観測する → Broker が配送する → Validator が評価する → 全体判定を作る → 認可を決める → 規則を強制する → 変化を監視する → 再評価を終える。

矢印ごとに所有者が変わる。ある段で記録が途切れたら、その先は unknown である。前段の緑をコピーして埋めてはいけない。

評価とゲートは別の装置である

RFC 5209 は、評価結果がアクセス判断に影響し、その判断がネットワークや端末の enforcement mechanism に設定され得ると述べる。同時に、強制の仕組みとプロトコルを仕様範囲外とし、NEA 結果をアクセス技術へ伝える表現も範囲外とする。

これは責任の切り分けである。NEA は姿勢を評価する。認可系は、その結果をアクセスへどう反映するか決める。実行点は規則を導入し維持する。パケットとアプリケーションの観測が効果を示す。

従って、準拠判定からアクセス許可を断定できない。他の認可条件が拒否するかもしれない。逆に、接続できた事実から全姿勢検査の合格も断定できない。限定アクセス、例外、別の認証情報による判断があり得る。Remediation を受信しただけで修復済みとも言えない。

「強制した」と報告するには、判断を受け取った系、入力、決定規則、対象端末・会話、実行点、規則ID、導入応答、生効時刻、観測効果が要る。それがなければ「評価結果がこの境界まで届いた」と表現するのが正確である。

現在形を支える運用レシート

評価記録には assessment ID、session ID、端末との結び付き、ネットワーク接続、開始・終了時刻、契機を含める。期待・登録・応答した Collector と Validator、版、設定の指紋を列挙し、要求属性、観測時刻、未対応、不明、非開示、処理エラーを保存する。

機能別結果には Validator、方針版、使った入力、規則、理由を付ける。全体結果には集約方針、例外、不明値の処理を付ける。Assertion を使ったなら発行者、範囲、有効期間、失効条件を残す。

その後は外側の系が独自に証明した場合だけ、認可決定、実行規則、修復実行、再測定を書き足す。最後に、関連する姿勢変化、方針変更、最終再評価、失敗した契機、証拠年齢を記す。

構成例なら、正しい現在表示はこうなる。「9時に合格。9時17分にファイアウォール変更。再評価通知は未達。現在の準拠は不明。以前のアクセス規則は継続中」。一つの緑より長いが、どの担当者が何を直すかが分かる。

合格を尊重するには、期限を隠さない

RFC 5209 を狭く読むことは NEA を軽視することではない。姿勢情報を運び、検証し、集約し、修復を促す機能は重要である。RFC 5792、RFC 5793、RFC 6876、RFC 7171 はその交換の層を具体化した。

問題は保証画面が歴史的な判断を端末の恒久的な身分へ変える時に生じる。時刻、coverage、方針版を失った「準拠」は象徴として強くなり、稼働中の現実を否定し始める。現在のファイアウォールが記録と違うとき、疑うべきは機械ではなく、まず記録の鮮度である。

running code、現在の Collector、再評価待ち、方針世代、実行確認を優先する。過去の合格は消す必要がない。境界と日付を戻せばよい。

9時25分の答えは、必ずしも不合格ではない。「関連する変化の後に再評価されていないため、現在は不明」である。不明を表示できる仕組みこそ、次の正しい評価へ進める。

出典