トピック
セキュリティ自動化
「トピックの観点から見たセキュリティ自動化トピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
記事
APNIC 62で見えた、失効記録とブラウザーの判断の距離
証明書は失効リストに載っていた。それでも接続を止めるかどうかは、最後に証拠を扱うクライアント次第だった。Geoff Huston が APNIC 62で示した三つの結果は、認証局の記録を利用者の保護と同一視できないことを具体的に示す。
グローバルのクラウドサービストレンド
Coreroの売上高42％増とARR12％増は、別々の時間を映す
DDoS 防御の需要拡大は実績に表れた。ただし、当期に計上された売上高と、将来に続く契約の年換算額を同じ成長率で読むことはできない。
IETF
IESG承認は発行ではない：Composite ML-KEM CMSを止めるコンパニオン依存
2026年9月18日、IESG は`draft-ietf-lamps-cms-composite-kem-03`を Proposed Standard として承認した。これは Composite ML-KEM を CMS で扱うための標準化が重要な関門を越えたことを意味する。しかし、運用上もっと重要なのは、何がまだ終わっていないかである。文書は RFC ではなく、RFC Editor では参照待ちでブロックされ、IANA 作業も進行中だ。さらに、その CMS…
IETF
セキュリティ通知をまとめて送っても、対処は一件ずつ証明する
IETF で最終意見募集に入った multi-SET push 案は、複数のセキュリティイベントを一度の HTTPS 通信で運ぶ。通信の効率と、受信先でアカウントを停止したという証拠は別のものだ。その間の記録を誰が持つかが導入時の焦点になる。
IETF
片方だけ設定が終わったとき、ACTNは何を「完了」と呼べるか
パケット網と光網を一つの指揮系統で扱う ACTN の適用草案に、IETF のセキュリティと運用の両レビューが「Not ready」と記した。問われているのは接続図の整合性より、通知が欠け、制御器が再起動し、一方の層だけ変更された時の判断権限である。
IETF
SAVNETの最終意見募集、問われるのはフィルター以前の判断
送信元のプレフィックスが経路表にある。それでも、その隣接ネットワークがこの境界からそのアドレスのパケットを送ってよいとは限らない。IESG の最終意見募集は、この推論の限界を整理した文書を対象とする。10月1日の期限は、新しいフィルタリング方式の承認日ではない。
インターネット史
Version 3のまま、serviceは変わった――RFC 2126が増やした証拠
二本目の TCP connection が開いたとして、何が証明されたのか。RFC 2126の答えは狭い。同じ host pair の一つの Transport Connection に expedited path が結び付いた。それだけでは、同期も delivery も証明されない。
ケースファイル
RFC 9647が可視化するBabel運用証拠チェーン――YANGモデルの外側に残る検証責任
Babel の経路表に「selected」と表示されても、それだけで通信経路の完全な証明にはならない。YANG データストア上の設定意図から、実際に適用されたインターフェース方針、認証済み近隣交換、転送状態、障害復旧、そして外部から観測された到達性までの証拠連鎖が欠けていれば、管理面の可視性は完成したネットワーク保証とは異なる。RFC 9647は Babel を運用管理可能なデータモデルとして整理するが、何を確認できるようにしたのか、そして何を運用者自身が証明し続ける必要があるのかを明確に分ける必要がある。
IETF
IESGが確認したのは第12版、RFC制作が受け取ったのは第14版だ
Safe-IOC の文書名は同じでも、判断の対象となったバイト列は同じではない。第12版に対する無衝突判断の後に第13版と第14版が提出され、ISE、IANA、RFC Production Center が別々の状態を残した。必要なのは「進行中」という一語ではなく、版・コメント・決定・差分を結ぶ受け渡し記録である。
インターネット史
許可の後に回線はつながったのか：RFC 2125の二段階判断
追加回線への同意は、追加帯域そのものではない。RFC 2125は、要求への応答と実際の発呼結果を別のメッセージにし、許可・実行・member 変化・通信実績を一つの成功表示にまとめなかった。
インターネット史
FASが裁定しても、スイッチの仕事は終わらなかった
RFC 2124は接続受付ポリシーを外部サービスへ切り出した。しかし、サービスの回答と実際の接続状態を同じものにはしなかった。LFAP が残したのは、判断、実行、照合、計量を別々に検証するためのメッセージ列である。
IETF
再起動後に失われる「非トランジット」意図――BGP-SPF Status 2の責任境界
コールドリスタート後の運用引き継ぎで、サービス担当者が「到達性は回復した」と承認しても、ルーティング担当者が Node SPF Status 2 の存続をまだ確認していないなら、復旧判定は一つの事実しか確定していない。RFC 9815 が分離したのは、ノードやそのプレフィックスに到達できることと、そのノードをトランジット経路として展開してよいことだ。Status 2 が再広告されず省略されれば、以前の非トランジット指定は暗黙に撤回される。ただし、それによって戻るのは候補としての適格性であり、実際に経路へ採用されるかはトポロジー、メトリック、SPF…
欧州・中東のクラウドサービストレンド
PCI Palの契約済みARR2790万ポンドは、なお監査済み売上高ではない
PCI Pal は二つの営業ランレートを上方修正する一方、FY26 決算の公表を延期した。両者は相殺しない。契約、導入、会計認識、監査完了は、それぞれ別の時計で進むからだ。
インターネット史
リセットは次のパケットに載った：RFC 2118におけるMPPCの回復境界
RFC 2118の Microsoft Point-to-Point Compression は、両端が連続した履歴を共有する方式だった。損失でその履歴がずれると受信側は Reset-Request を送る。しかし新しい復号開始点を実際に示すのは、独立した Reset-Ack ではなく、その後に届く`FLUSHED`付きデータパケットである。
IETF
送る前の言葉は誰のものか――RFC 9787の下書き暗号化とコミットメント境界
これは仮想の場面だ。一台の端末で書きかけた文章が自動保存され、数分後、別の端末で同じメールボックスを開くと、その続きが現れる。しかし、その同期が成功したからといって予定受信者が文章を読めるわけではないし、著者が書かれた内容にすでに責任ある意思表示をしたことにもならない。RFC 9787 が下書き暗号化について引く重要な線は、まさにこの途中状態にある。保存と送信は同じメッセージの前後ではあっても、権限、可視性、そしてコミットメントの状態は同じではない。
インターネット史
「1か所」「複数」「観測なし」——RFC 2108が曖昧さを消さなかった理由
管理装置が送信元アドレスを探したとき、答えは常に一つのポートになるわけではなかった。RFC 2108は `single`、`multiple`、`none` を別の状態として残し、測れたことと断定できることの境界を MIB の中に組み込んだ。
IETF
二度目の救済を拒む権利――RFC 9791とNFFRRが作るFast Rerouteの責任境界
期限切れの NFFRR ドラフトに、示唆的な EVPN active-active の事故再構成がある。CE2 が停止すると、PE2 には link1 障害、PE3 には link2 障害に見える。PE2 は PE3 へ退避し、PE3 も局所判断に従って PE2 へ戻す。二つの合理的な修復が結合し、パケットは TTL 切れまで往復する。これは実測された本番障害ではなく文書上の例だ。それでも問いは鋭い。一度 FRR されたパケットに対し、誰が「二度目の救済は危険だから拒め」と命じられるのか。
ケースファイル
RFC 9682の公開だけでは、パーサは届かない
標準の公開は、新しいパーサを配送しない。CDDL の文法が修復されても、その規則が生成バリデータを経て受信側に届いたかは別の問いだ。「対応済み」という一語を解き、標準本文から実行時の電文まで、引き渡しの記録を追う。
インターネット史
2回のハッシュ処理がMACを再利用可能にした。しかし信頼判断までは代行しなかった：RFC 2104
RFC 2104は、既存の反復型ハッシュ関数を内側と外側の2段で包み、再利用できるメッセージ認証コードを定めた。下層のハッシュを交換できる設計は長く残ったが、一致するタグが示す範囲は鍵・アルゴリズム・正確なバイト列に限られる。人物やホストの同一性、権限、鮮度、配送、運用の正しさまで自動的に証明するものではない。
IETF
見えるネットワークは誰を結び付けるのか――RFC 9686と相関能力の統治
アーキテクチャ／プライバシー審査で、自己生成 IPv6 アドレスの登録は二つの顔を持つ。SLAAC や静的設定で選ばれたアドレスを運用者から見えるようにする一方、Client Identifier、アドレス、接続点を横断的に結び付ける能力も強めるからだ。RFC 9686を安全に導入する鍵は、収集できる情報、相関してよい情報、相関結果に基づいて実行できる対応を、同じ権限として扱わないことにある。