要点： ILM 2.19.0では、署名とタイムスタンプがプラットフォームの第一級の機能となり、証明書を要求する人からPKIの複雑さを取り除きます。内部では、証明書ステータス処理が、分散した更新処理の集まりではなく、明示的なステートマシンになりました。

多くのリリースは機能を追加します。今回はむしろ、何かに署名するため、時刻をスタンプするため、あるいは「動く証明書が欲しいだけ」の開発者にPKIを説明するために、プラットフォーム外へ出る理由を減らすリリースです。

リリースノートはプルリクエストの一覧です。しかし、それが日々の働き方をどう変えるかまではほとんど伝えません。そこで変更履歴を繰り返す代わりに、ILM 2.19.0の日常利用を実際に形作る4つのテーマを取り上げ、それぞれの背景にある具体的な変更を示します。

完全な変更履歴はGitHubのCore 2.19.0リリースで公開されています。以下の内容はすべてそこに基づいています。

署名操作は、実行されるだけでなく記録されるようになった

ILM 2.18.0では署名プロファイル管理が導入され、署名方法を定義する場所ができました。しかし、「何が、いつ、誰のために起きたのか？」という明白な問いが残っていました。

2.19.0はその問いに答えます。すべての署名操作が署名記録を生成するようになりました。さらに各署名プロファイルには記録一覧を返すエンドポイントがあり、ダッシュボードには既存の証明書・鍵の数値と並んで署名統計が表示されます。

これは見た目以上に重要です。監査証跡のない署名機能は運用が難しく、レビュー時に説明するのはさらに困難です。実務上、「誰が何に署名したか」は監査担当者が最初に聞く問いであり、後付けの署名サービスが最後まで答えにくい問いでもあります。

実際に呼び出せるタイムスタンプ

タイムスタンプは段階的に追加されました。TSPプロファイル管理は2.18.0で入り、2.19.0で実用可能なサービスへの経路が完成しました。

3つの変更が中心です。第1に、管理されたTSPタイムスタンプ・エンジンが操作そのものを処理します。第2に、呼び出し可能なRFC 3161エンドポイントが、すでに標準を話すクライアントへ機能を公開します。第3に、TSPプロファイルへ認証方式とBasic認証情報が追加され、タイムスタンプ・エンドポイントの前段に専用認証フィルターが置かれました。

エンドポイントはRFC 3161に準拠しているため、既存ツールを変更せずに利用できます。またTSPプロファイル・キャッシュにより、要求処理経路から検索処理を外せます。これはタイムスタンプがビルドパイプラインに入る場合に重要です。

リクエスト属性が、難しさを要求者から取り除く

これは今回のリリースで最大のテーマで、単独の記事にする価値があります。ただし、ここでも全体像は説明しておきます。

RAプロファイルは、値の取得元バインディングを持つリクエスト属性設定を保持できるようになりました。そのためプラットフォームは、どの値を収集し、どの値を導出でき、どの値をクライアントから決して受け取るべきでないかを把握できます。その属性マッピングは生成されるPKCS#10要求へ反映されるため、証明書署名要求は推測ではなくポリシーを表します。

アップロードされた要求も対象です。ILMは持ち込まれたCSRを同じリクエスト属性ポリシーで検証し、以前に登録した要求から証明書を発行することもできます。さらにポリシー違反は、不透明な内部エラーではなく、ACME、EST、SCEP、CMPそれぞれのネイティブエラーとして返されます。

運用担当者が実感するのは最後の点です。正しいプロトコルエラーを受け取ったクライアントは、その情報を使って対処できます。内部エラーしか受け取れなければ、そうはいきません。

証明書ライフサイクルがステートマシンになった

以前は証明書ステータスが複数の場所から更新されていました。そのためエッジケースで意図しない状態が生まれ、修正も局所的になりがちでした。

2.19.0では、ライフサイクル遷移のための証明書ステートマシンを導入し、v3の証明書登録をそこへ通すようになりました。その周辺では、同期的に待つ代わりに非同期の証明書ステータス・ポーリングを行い、事前登録完了時にCERTIFICATE_REGISTEREDイベントが発火します。Authorityインスタンスは、ライフサイクル操作とプロバイダー操作の両方でv3に対応しました。

これはリリース内で最も目立たない一方、アーキテクチャ上は最も重要な変更です。明示的なステートマシンは、不正な遷移を「起きにくくする」のではなく「起こせなくする」からです。

その他に知っておくべき変更

いくつかの小さな変更は、特定のチームにとって重要です。

領域 変更 重要な理由
ガバナンス Auditorシステムロール、書き込みおよびロール割当て認可の強化 運用権限を与えずに読み取り専用の監督を実現
拡張 CERTIFICATE_EXTENSIONカスタムOIDレジストリ、システムOID一覧エンドポイント、登録済みシステム拡張 カスタム拡張をコードではなく設定として扱える
命名 EMAILなどのプラットフォームRDNコードをSubject DNで受け入れ、RDNコードの競合を解消 一般的なSubject名による要求却下を削減
性能 Connectorの往復処理を発行トランザクション外へ移動し、Discoveryインポート時の冗長なメタデータ再書き込みを省略 トランザクションを短縮し、大規模Discoveryを高速化
プロトコル チャレンジパスワードなしのSCEP更新、ECクライアント鍵へのSCEP配信、複数のCMP正当性修正 実運用でプロトコルが行き止まりになるケースを削減
4つの主要テーマ以外に含まれるILM 2.19.0の主な変更。

このリリースでは、通知、Discovery、CMP処理にまたがる長年の細かな不具合も多数修正されています。そのいずれかを回避策でしのいでいたなら、完全な変更履歴を読む価値があります。

この変更がILMという製品をどう変えるか

ILMは証明書ライフサイクル・プラットフォームとして始まりました。その後、鍵、シークレット、暗号部品表を追加してきました。2.19.0もその方向を進めますが、今回追加されたものは単なる隣接機能ではありません。署名とタイムスタンプは、多くの組織が別製品で運用する独立した分野です。

それらを統合する意味は、マーケティングではなく実務にあります。1つのプラットフォームなら、証明書、鍵、シークレット、署名、タイムスタンプを横断して、1つのインベントリ、1つの認可モデル、1つの監査証跡を持てます。そのため「先月どの暗号操作が行われたか」という問いに、4つの部分回答ではなく1つの回答を返せます。

適用範囲については明確にしておきます。ILMはHSMを置き換えませんし、暗号ポリシーを代わりに決めるものでもありません。そうした判断を置く場所を一つにし、適用された記録を一つにするものです。

主なポイント

  • すべての署名操作が署名記録を残し、署名プロファイルごとに一覧化でき、ダッシュボード統計でも確認できます。
  • タイムスタンプはRFC 3161経由で呼び出せ、管理エンジンと認証付きTSPプロファイルによって支えられます。
  • RAプロファイルは値の取得元バインディングを含むリクエスト属性ポリシーを保持し、違反時にはACME、EST、SCEP、CMPのネイティブエラーを返します。
  • 証明書ライフサイクル遷移は明示的なステートマシンを通り、その背後で非同期ステータス・ポーリングが行われます。
  • AuditorロールとカスタムOIDレジストリにより、監督と証明書拡張をカスタム作業ではなく設定として扱えます。

ILMはオープンソースなので、このリリースのすべての変更を自分で確認できます。導入前にプラットフォームの対象範囲を知りたい場合は、ILMで構築できる10のことから始めるか、ILMをオープンソース化した理由をご覧ください。具体的な導入については、お問い合わせください。