読めない通信と持たない記録、二つの「中身が無い」状態における運用可視性の測定
研究計画。読めない通信と、あえて持たない記録。二つの「中身が無い」状態で運用がどこから壊れるかを測る
通信の中身が読めない場合と、privacy のためにあえて記録を持たない場合を、一つの計画として扱う。前者は TLS 1.3 と QUIC の普及で境界から意味が消えた状況、後者は詳細な記録を無期限に貯めない設計である。どちらも「中身が無い」状態から出発して、どの仕事がどこまでできるかを問う。全部保存するか何も保存しないかという二択を捨て、情報を一段ずつ削りながら、壊れる順番を測る。本ページは計画であり、実験はまだ行っていない。以下に実測値は無い。
| 方法 | 暗号化通信では、隔離したクライアントとサーバーの間で正常な Web・API のやりとりを反復し、通信量の急増、異常な反復、普段と違う接続の周期といった安全な異常を作る。payload と credential はデータに残さない。観測できる情報をフローだけ、フロー＋時間、フロー＋時間＋protocol のメタデータ、端末側の記録を最小限足したもの、の四段階にして同じ検知器にかける。記録の削減では、研究用ネットワークから取ったフロー、DNS の分類、サービスの識別子、遅延、状態を元データとし、そこから精度の違う三つの組を作る。時刻をそのまま持つ組、時刻をまとめて識別子を定期的に入れ替える組、集約した統計だけを短期間だけ持つ組である。個人の実通信は対象にしない。それぞれの組で、停止の検知、遅延の悪化の特定、容量の見通し、依存関係の地図、出来事の時系列の再構成という五つの仕事を実際に行い、どこまで正しくできるかを測る。 |
|---|---|
| 結果 | 実験前である。本ページに実測値は無い。「予想」として書いたものは検証前の仮説であって、測定の結果ではない。 |
| 知見 | 二つの研究に共通する問いは、「中身が無い」を一語で片づけないことにある。暗号化は privacy を守るために中身を隠し、記録の削減は privacy を守るために中身を捨てる。動機は同じで、残るものも似ている。通信量、向き、間隔、失敗率、粗い時刻。違うのは、前者は外から与えられた制約で、後者は自分で選んだ設計だという点である。だからこそ後者では「どこまで削れるか」を設計できる。その境目を、単一の privacy 得点に押し込めず、何が露出するかの軸ごとに記述する。 |
| 限界 | 小さなテスト環境と実環境の差。データの量と偏り。ソフトウェアとプロトコルの版に結果が左右されること。正常そのものが時間とともに変わること。記録の欠落と、機器ごとの時計のずれ。研究用に作った異常が未知の異常を代表しているとは限らないこと。運用の仕事として選んだ五つが、現場の仕事の全体を代表しているとは限らないこと。研究チームが2名であるため、初めに扱う対象を絞る必要があること。 |
状態：実験前。この記事は研究の目的と方法を先に公開するための記録である。数値はまだ一つも出ていない。以下に「予想」と書いたものはすべて検証前の仮説であり、実測値として扱わない。
二つの「中身が無い」
ネットワークの記録から中身が失われる道筋は二つある。
一つは、外から与えられるものである。TLS 1.3、QUIC、HTTP/3 が広がったことで、境界に置いた装置から読み取れる意味は減った。要求した URL、ヘッダー、本文、エラーの文面は、もう境界には来ない。これは誰かが決めた設計ではなく、すでに起きたことである。
もう一つは、自分で選ぶものである。ネットワークを運用する側は、詳しい記録があるほど障害を追いやすい。しかし IP、ホスト名、細かい時刻、フローの並びを期限なく貯めれば、必要以上の行動の記録が積み上がる。だから削る。これは制約ではなく設計である。
この二つを別々の研究にすると、同じ問いを二度解くことになる。どちらも出発点は「中身が無い」で、問いは「それでも何ができるか」だからである。残るものも似ている。通信量、向き、到着の間隔、接続の長さ、失敗率、粗い時刻。違うのは選べるかどうかだけで、選べる側では「どこまで削れるか」を設計できる。だから一つの計画にまとめた。
読めない通信から
復号を前提にせず、フローの長さ、方向ごとのバイト数、パケットの到着間隔、接続の継続時間、再接続、HTTP/3 の使われ方から、異常をどこまで見分けられるかを調べる。ここで言う異常は攻撃のラベルに限らない。普段の分布、決めた方針、身元、状態の移り変わり、想定される依存関係から外れた状態を含める。
検証したい見立ては四つある。
- 暗号化された通信でも、フローと時間の特徴から一部の異常は検知できる。
- 単純な通信量よりも、時系列と方向性を含めた特徴のほうが成績を上げる。
- 意味の上では異常だが通信の形は正常、という場合は、通信だけを見る方式の取りこぼしが増える。
- privacy を保ったメタデータと端末側の記録を最小限つなぐと、成績が上がる。
三番目が、この研究でいちばん見たいところである。外形だけを見る方式が弱くなる場所が分かれば、どこから先は端末の記録が要るのかが言える。強い検知器を作ることより、その境目を示すことを成果にしたい。
あえて持たない記録から
元のデータから、精度の違う三つの組を作る。
| 組 | 時刻 | 識別子 | 相手の分類 | 保存期間 |
|---|---|---|---|---|
| A | 細かいまま | 変えずに持つ | 細かい | 長い |
| B | まとめて粗く | 定期的に入れ替える | 粗い | 中くらい |
| C | 集約した統計だけ | 持たない | 持たない | 短い |
そのうえで、実際の運用の仕事を五つ決めて、組ごとに本当にやれるかを測る。サービスの停止に気づけるか。遅延の悪化を特定できるか。容量の見通しを立てられるか。どのサービスが何に依存しているかの地図を描けるか。障害が起きたとき、出来事の順番を後から組み立て直せるか。
ここで大事なのは、privacy の側を一つの得点にまとめないことである。まとめた瞬間に、何が守られて何が守られていないかが見えなくなる。代わりに、識別子がどれだけ長く同じままか、時刻がどの細かさで残るか、場所やネットワークがどの粒度で分かるか、相手の分類がどこまで細かいか、どれだけの期間残るか、という軸ごとに書き出す。
何を測るか
| 読めない通信 | あえて持たない記録 |
|---|---|
| 見つけた中で正しかった割合 | 五つの仕事それぞれの正しさ |
| 取りこぼさなかった割合と、その調和平均 | 原因にたどり着けた割合 |
| 正常を誤って異常と呼んだ割合 | 容量の見通しの誤差 |
| 異常が起きてから気づくまでの時間 | 時間の分解能 |
| 記録を集めるために増える CPU と保存量 | 保存量と、問い合わせにかかる時間 |
主要な結果は点だけでなく、複数の乱数の種と複数回の実行から出る散らばりも併せて示す。正常と異常の比率は必ず記録し、偏りが大きいときは正解率だけで評価しない。
提案する組から手がかりを一つずつ抜いて成績の差も測る。複雑にしたから強くなったのか、その情報が効いたのかを分けるためである。
記録の形
二つの研究は、実験 ID、シナリオ ID、時刻、正解ラベル、特徴量、検知器の出力、検知した時刻を最低限持つ共通の形にそろえる。正解は実験を回す側が持ち、検知器には渡さない。password、token、秘密鍵、個人のデータ、必要のない payload はデータに残さない。
結果の表は、実験を回す仕組みが出した機械生成の数値から組み立てる。文章を書くモデルが測定値を埋めることはしない。記録を言語モデルに渡すこと自体が追加の開示になり得るため、手元での処理、伏せ字、最小限の文脈を設計に含め、モデルを使わない場合の対照を必ず残す。
雑音を足すのは、削り終えてから
記録を守る手立てとして、値に雑音を加える方法がよく挙がる。統計として使える範囲を保ちながら、個々の記録を特定しにくくする考え方で、理論としては確立している。
ただし本研究では、これを後半の追加実験に置く。理由は測定の都合である。雑音を足すと、運用の仕事が壊れる原因が二つ混ざる。欄を削ったから壊れたのか、雑音のせいで壊れたのかが分けられなくなる。
そこでまず、削る・粗くする・入れ替えるという単純な操作だけで三つの組を作り、五つの仕事が壊れる順番を測る。順番が分かった後で、同じ仕事に対して雑音を加える方法を重ねる。効果の分からない対策を先に入れると、何が効いたのか永久に分からなくなる。
予想（まだ測っていない）
外形だけで見分けられる異常の種類と、意味の情報なしでは難しい種類が、はっきり分かれると予想している。最終的に出したいのは高い成績そのものではなく、暗号化された通信で何を観測すべきかという最小の設計である。
記録の削減については、削るほど一律に悪くなるのではなく、仕事によって壊れる段が違うと考えている。容量の見通しのように集約で足りる仕事は C でも残り、出来事の時系列の再構成のように順番が要る仕事は B で既に苦しくなるかもしれない。もしそうなら、成果は「どの欄を削ると、どの仕事が壊れるか」という一枚の対応表になる。
この節は仮説である。実験の後に、実測値、図表、区間推定、誤りの分析へ置き換える。
思った通りにならなくても価値がある結果
端末の記録を足しても成績が変わらなかった場合、それは失敗ではない。外形だけで足りるという意味になり、集める記録を減らす根拠になる。逆に、記録をどれだけ削っても五つの仕事が全部できてしまった場合も、貯めている記録が過剰だったという結果になる。どちらに転んでも、何を集めるべきかについて言えることが増える。
限界
- 小さなテスト環境と実環境の差
- データの規模と偏り
- ソフトウェアとプロトコルの版に依存すること
- 正常そのものが時間とともに変わること
- 記録の欠落と、機器ごとの時計のずれ
- 研究用に作った異常が、未知の異常を代表しているとは限らないこと
- 運用の仕事として選んだ五つが、現場の仕事の全体を代表しているとは限らないこと
- 研究チームが2名であるため、初めに扱う対象を絞る必要があること
参考文献
- Thomson, M., Iyengar, J. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC 9000, 2021. DOI: 10.17487/RFC9000.
- Bishop, M. HTTP/3. RFC 9114, 2022. DOI: 10.17487/RFC9114.
- NIST. NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management. 2020. DOI: 10.6028/NIST.CSWP.01162020.
- Dwork, C., McSherry, F., Nissim, K., Smith, A. Calibrating Noise to Sensitivity in Private Data Analysis. TCC, 2006. DOI: 10.1007/11681878_14.
- NIST, Trustworthy Intelligent Networks.
上の四件は実物の書誌を確認した。