主要領域
セキュリティ
主要領域 の観点では、「セキュリティ」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
北米のクラウドサービス
ProofpointのVaronis買収案、脅威検知とデータ権限の連携を試す
セキュリティ警告が実務で役立つには、誰またはどの AI エージェントが動いたか、どのデータに届いたか、どの権限が行為を可能にしたか、そして対処によって露出が変わったかを結び付ける必要がある。Proofpoint は Varonis の買収で、その距離を縮めようとしている。取引はまだ完了しておらず、統合された製品も計画段階だ。
記事
CEDIA、LACNIC 46併催のFIRSTでDALIAの人間判断を示す予定
10月21日の講演では、DALIA による CSIRT のトリアージや信号の相関・優先順位付けを紹介する一方、重要な判断と封じ込めは人が担うと説明される。公開要旨からは、その境界をどう実装するかは分からない。
IETF
本文は一つではなかった。抽出器が本文を作っていた
同じメールと同じ Sieve スクリプトでも、移行後に判定が変わり得る。RFC 5173 の `:raw`、`:content`、`:text` は、一つの本文を別名で呼ぶ機能ではない。比較器へ渡す文字列を、それぞれ異なる規則で作る入口である。
IETF
子トークンは有効だった。それでもチェーン全体の承認が必要だった
委任を各段階で中央承認に戻さない設計は、エージェントに速度と自律性を与える。その代わり、末端の署名ではなく、信頼されたルートから資源サーバーのローカル判断までを一つずつ検証しなければならない。
IETF
メーカーは新しい信頼アンカーに署名した。それでも配信サーバーは未認証だった
工場出荷時の鍵を使えば、機器は将来の運用 CA を知らないまま署名済み証明書束を受け取れる。しかし、署名が保証するのは束の内容だけだ。サーバーの身元、信頼ストアの変更、次の接続、証明書登録、稼働結果は別々に立証しなければならない。
IETF
値は同じでも、元の表記には戻らない
ある値を CDN で書き出し、別のツールで読み、もう一度テキストに戻す。データモデル上の値が保たれていても、差分には別の表記が現れる。レビュー担当者が「改変」と呼ぶ前に問うべきなのは、文字列の同一性ではなく、どの解釈系がどの値を作り、その後どの符号化を選んだかである。
IETF
引用符は直った。それでも変更権限は生まれない
手入力で引用符が別の文字に置き換わり、DNS レコードが壊れる問題は、構造化されたコピー＆ペーストで減らせる。だが、転記ミスをなくすことと、その変更を誰が命じられるかを決めることは別の仕事である。
IETF
検証できた署名を、誰が取引相手の声にしたのか
証明書の更新日に必要なのは、新しい公開鍵だけではない。正確な AS2 名、通信方向、取引関係、承認者を一本の記録に結ぶことだ。その記録がなければ、署名は正しくても、誰の権限を検証したのかが残らない。
ケースファイル
同じ番号に、二つの判定が存在した
署名検証画面に「41」と表示されたとき、その番号は何を証明するのか。2026年10月1日の時点では、OpenPGP の作業草案は41を ML-DSA と ECDSA の複合署名として記述していた。一方、IANA の公開レジストリは37から99までを未割り当てとしていた。番号を読めたこと、二つの暗号計算を終えたこと、そしてアプリケーションが結果を採用したことは、それぞれ別の判定である。
IETF
ACME鍵をローテーションしても、昨日のDNS認可は残る
ACME の永続 DNS チャレンジ案は、鍵の更新と権限の撤回が別の操作であることを鮮明にした。古い秘密鍵はもう要求を署名できなくても、その公開鍵の指紋に結び付いた認可は期限まで生き得る。
IETF
証明が通ったあと、ラベルの責任は誰に残るのか
鍵透明性は、ディレクトリの応答が履歴と整合することを証明できる。しかし、変更権限、検索の根拠、後日の監視責任までは決めない。IETF の最新レビューは、暗号学の成功表示の背後に残る役割の空白を突いた。
インターネット史
「G & R for Security Incident Processing」— ガイダンスは執筆組織より長く生きる
1998年に公開されたコンピュータセキュリティインシデント対応の期待水準を定める RFC 2350(BCP 21)は、今日に至るまで現行のベストカレントプラクティスであり続けている。しかし、その文書を生み出した IETF ワーキンググループ「GRIP」は2001年12月に終了している。本稿は、インシデント処理に関する制度的期待を誰が所有し、その執筆組織が存在しなくなった今、検証可能性と是正がどこで担保されるのかを、一次記録のみに基づいて検証する。
ケースファイル
値は同じだった。再構成したバイト列は一致しなかった
署名側と検証側が表示した CBOR マップは、キーも値も同一だった。それでも署名入力のハッシュは違った。攻撃者が値を書き換えたのではない。二つのエンコーダーが、規格上許された別々の表現を選び、プロトコルがその選択を未定のまま残していた。欠けていたのは、正確なバイト列を誰がどう決めるかという合意だった。
ケースファイル
証明は結び付かなかった。それでも封筒が同じ人を示した：BBS署名
BBS の証明値だけを比べれば、二つの提示が同じ署名から作られたとは分からない。ところが、同じ希少なヘッダー、十個というメッセージ数、同じ開示インデックス、十二人にしか配られていない署名者鍵が外側に残っていた。暗号は約束を守った。「提示全体も追跡不能だ」と読み替えた運用が境界を越えた。
ケースファイル
`co` は登録された。ハンドシェイクで使われたとは限らない：RFC 9952
二文字に短縮した理由は、制約の厳しいリンクでフラグメントを一つでも減らすためだった。しかし短い識別子が IANA 表に載ったことと、実際の ClientHello に載ったことは別である。RFC 9952は、その差を埋める規則をあえて書かなかった。
ケースファイル
AEGISという名は同じでも、再利用規則は役割で変わる：RFC 10032
テストベクトルのダッシュボードはすべて緑だった。ところが障害時のトレースには、どの API がどのバイトを返したかが残っていない。暗号コアの一致は確認できても、タグを捨てたストリームなのか、検証後の平文なのか、再利用例外を持つ MAC なのかは証明できなかった。
IETF
IDMEFv2の204は受領証になるが、再送の意味までは決めない
アラートを保存した直後に応答経路だけが切れたら、送信側には失敗、受信側には成功が残る。IDMEFv2 の HTTPS ドラフトは2xx を堅い受領証に近づけた。次の POST を重複と見るかは、連合側の仕事である。
ケースファイル
署名は検証できた。それでも承認者は分からない：RFC 9591
障害後に残ったのは、対象メッセージ、グループ公開鍵、そして有効な Schnorr 署名だけだった。署名能力がしきい値を超えて使われたことは分かる。だが、どのメンバーが参加し、何を確認し、どの権限で同意したかは復元できない。RFC 9591の FROST は複数の署名シェアを一つの通常署名へ畳み込む。帰属を必要とする組織は、その前段の証拠を別に保持しなければならない。
ケースファイル
EdDSA対応と書いてあっても、曲線はまだ決まっていなかった：RFC 9864
能力表に同じアルゴリズム名が並んでも、同じ処理を実行できるとは限らない。`EdDSA` だけでは Ed25519 と Ed448 のどちらを扱えるか分からないからだ。RFC 9864は曲線とハッシュを含む名前へ進める。だが新しい名前は、実装や有効化、鍵の拘束、相互運用の成功まで保証しない。
ケースファイル
バックアップは鍵と一緒に昨日の状態まで戻した：RFC 9802
復旧した署名装置が正しい秘密鍵を持ち、有効な署名を返した。それだけでは復旧成功とは言えない。別の装置が同じワンタイム索引をすでに使っていれば、検証に通る二つの署名が安全性の前提を壊す。RFC 9802は X.509 に HSS と XMSS を識別させるが、署名者の状態履歴までは証明しない。