要点： PKI Maturity Model 2.0.0は拡張フレームワークを導入しました。リスクプロファイルや業界固有の事情に応じて、モデルをフォークせずに重点項目を追加できます。最初の拡張であるPQC Readinessは公開されており、開発中であることも明示されています。

組織が現在のすべての要件で最高成熟度に達していても、重大な暗号リスクを抱えている可能性があります。それでも、量子攻撃に脆弱な基盤はスコアには表れません。

すべての成熟度モデルは同じ圧力を受けます。ある組織は自分たちの業界、規制当局、特有のリスクについてもっと記述するよう求めます。その結果、モデルが膨張して誰にも合わなくなるか、非公開でフォークされて比較不能になります。

PKI Maturity Model 2.0.0は第3の道を採用しました。任意のオーバーレイのためのフレームワークを定義し、コア定義に触れることなく重点項目や追加基準を加えられるようにします。

拡張の仕組み

拡張はモデル本体と同じ階層、つまりモジュール、カテゴリ、要件の順で構成されます。そのため、すでにモデルを知っている人ならそのまま読めます。

拡張には3つのことができます。既存カテゴリに拡張固有の成熟度基準を追加する。既存の要件やカテゴリに重み付けオーバーレイを適用する。そして、標準レポートを維持しながら独自のスコアリングとレポートを定義することです。

スコアリングの考え方を簡単に言うと、拡張は「Relevance」という追加の成熟度シグナルを導入し、「Overlays」によって重要度を調整します。基準となる成熟度は、そのシグナルと、拡張が重視する重みに基づいて組み合わされます。

設計原則 保証されること
非破壊 拡張はベースモデルの定義を決して変更しない
組み合わせ可能 複数の拡張を共存させ、同じベースラインに対してそれぞれ独立して評価できる
一貫したスコアリング 完全な要件ベース評価でも、カテゴリベースの自己評価でも、スコアリング方法は同じ
モデルと同じ形 拡張は同じモジュール、カテゴリ、要件の階層を使用する
拡張フレームワークを支える4つの設計原則。

残りを安全にするのが「非破壊」という原則です。拡張はコアを変更できません。そのため拡張を有効にしてもベースライン評価が無効になることはなく、取り外しても何かを再計算する必要はありません。

機械可読な契約もあります。フレームワークは拡張定義のJSON Schemaを公開しています。したがって、ツールは拡張を無条件に信頼するのではなく、検証できます。

PQC Readiness拡張

最初に公開された拡張は、量子安全への移行を扱います。主張は上のコールアウトと同じです。量子脅威によって成熟度の意味が変わります。プログラムが高いスコアを獲得していても、脆弱な基盤の上に成り立っている可能性があるからです。

これは未来の問題ではなく、現在の問題です。「今収集し、後で復号する」攻撃により、長期間の機密性は今日すでにリスクにさらされています。移行スケジュールがどうであっても、その事実は変わりません。

この拡張は、ベースラインのカテゴリにPQC固有の基準を追加し、移行に最も関係する要件へ重み付けオーバーレイを適用します。主な対象は認証局とトラストサービス・プロバイダーの運用者です。エンタープライズPKIアーキテクト、監査担当者、コンサルタントも対象に含まれます。

完成している部分と、まだの部分

この拡張には「開発中」と明記されており、ワーキンググループは完成部分との境界を具体的に示しています。プレビューを完成品のように読まれてしまうより、ここは明確に繰り返しておきたい点です。

範囲 状態
ガバナンス・モジュール、カテゴリ1〜4 完了 — レベル1〜5の完全な基準、評価者向けガイダンス、エビデンス例、オーバーレイ重みを含む
管理、運用、リソースの各モジュール 概要のみ — PQCで重要な考慮事項は特定済みだが、レベル1〜5の基準は未開発
バージョン 開発中。すべてのモジュールが完成し、ワーキンググループが内容を承認した時点で1.0.0へ移行予定
PQC Readiness拡張の現在の開発状況。

設計上、まだ決まっていない本質的な問いも一つあります。オーバーレイを置く場所には2つの候補があります。一つはガバナンス中心の倍率をGovernanceカテゴリに適用する方法。もう一つは、能力中心の倍率を暗号アジリティやPQCトレーニングへ適用する方法です。現在の定義はガバナンス中心の設計を採用しており、現行の自己評価ツールもそれを使っています。最終決定はワーキンググループが行います。

カバレッジの不足も文書化されています。証明書を利用する組織、ソフトウェアベンダー、AIシステム層での暗号ガバナンスについては、ペルソナのカバーが不完全です。重要なのは、3つすべてが将来の改訂で対応する既知のギャップとして記録されていることです。現時点でこれらの問いに答えられると期待する場合は、まずステータス注記を確認してください。

未完成の部分を明示するプレビューは、それを隠すプレビューより有用です。

各要素の配置場所

フレームワーク、その構造とスコアリングのドキュメント、JSON Schemaはコアモデルと一緒に置かれます。公開拡張は別のカタログに置かれるため、コアリポジトリは個別の拡張内容を含まなくなりました。

この分離には実務上の利点があります。拡張はコアのリリースを待つことなく独自のペースで反復でき、対応するモデルバージョンを自ら宣言できます。

この形が適切だと考える理由

OmniTrustはPKI Maturity Modelワーキンググループに貢献しており、2.0.0の中で私たちが最も興味深いと考えているのが拡張です。

一つのモデルで認証局、銀行、デバイスメーカーすべてに同じように対応することはできません。しかし3つのフォークされたモデルでは、互いに比較できません。それでは成熟度を測る目的が失われます。オーバーレイなら、比較可能な1つのベースラインを維持しつつ、業界ごとに重要な点を強調できます。

フレームワークは新しく、最初の拡張も未完成です。つまり、今はフィードバックを反映するコストが最も低い時期です。PKIプログラムを評価しているなら、未解決のオーバーレイ配置の問いは良い出発点です。

主なポイント

  • 2.0.0は拡張フレームワークを追加し、コアモデルを変更せずに基準や重みを追加する任意のオーバーレイを提供します。
  • 拡張は非破壊で、組み合わせ可能で、一貫してスコアリングされ、モデルと同じ形を持ち、JSON Schemaという契約があります。
  • スコアリングは、ベースライン成熟度と拡張のRelevanceシグナルを、拡張のOverlaysで重み付けして組み合わせます。
  • PQC Readinessは最初に公開された拡張で、バージョン0.2.0、現在も開発中です。
  • Governanceモジュールは完成していますが、Management、Operations、Resourcesは概要段階です。
  • また、オーバーレイ配置はワーキンググループで未解決の問いとして残っています。

このフレームワークの背景にあるコアモデルの変更については、PKI Maturity Model 2.0.0で何が変わったかをご覧ください。モデルが初めてなら、場当たり的な運用から統制された運用へから始めてください。PQC対応は、何を運用しているかを把握するところから始まります。そのため暗号資産インベントリの構築が実務上の第一歩です。評価について相談するには、お問い合わせください。