要点： ILMは、署名プロファイル、操作ごとの記録、認証付きタイムスタンプ・エンドポイントを備え、署名とRFC 3161タイムスタンプを自ら実行できるようになりました。これにより、証明書、鍵、シークレット、署名、タイムスタンプを横断して、1つのインベントリ、1つの認可モデル、1つの監査証跡を実現できます。

署名とタイムスタンプは通常、別の誰かが管理するシステムです。だからこそ、組織が先月どの暗号操作を実行したかを1回の問い合わせで答えられないのです。

セキュリティチームに証明書の場所を聞けば、通常は明確な答えが返ります。署名鍵はどこにあるか、先週誰が使ったか、どのタイムスタンプ局が結果にスタンプを付けたかを聞くと、答えは断片的になります。証明書はあるプラットフォーム、署名は別の場所、タイムスタンプは何年も前に誰かが設定したURLです。

それぞれのシステム単体が間違っているわけではありません。しかし、その境界部分でガバナンスが静かに崩れます。各システムは独自のアイデンティティモデル、ログ形式、オペレーターに許される操作の考え方を持っているからです。

ILMは数回のリリースにわたって、その境界を埋めてきました。最初は証明書、次に暗号鍵、シークレット、暗号部品表へと広がり、最新が署名とタイムスタンプです。そしてこの2つこそ、プラットフォーム外に置かれがちな機能です。

署名プロファイルが「方法」を定義し、署名記録が「実際」を証明する

ILMの署名は署名プロファイルから始まります。どの鍵を、どのトークン・プロファイルの下で、どの制約で使うかという設定は、ここに置かれます。プロファイルは管理対象オブジェクトなので、独自の認可モデルを定義するのではなく、プラットフォームの認可モデルを継承します。

次に、運用可能にするための重要な仕組みがあります。すべての署名操作は署名記録を生成します。各署名プロファイルには、その記録一覧を返すエンドポイントがあり、プラットフォームのダッシュボードには、既存の証明書・鍵の統計と並んで署名統計も表示されます。

その結果、「誰が、何を、いつ、どの鍵で署名したか」は調査ではなく照会で確認できます。この違いは監査で重要であり、インシデント時にはさらに重要です。実際、自ら履歴を示せない署名機能は、正当性を説明できない機能でもあります。

ILMはCloud Signature Consortium APIも別コンポーネントとして実装しているため、CSCを話すリモート署名クライアントには標準的な接続方法があります。

既存ツールがそのまま理解できる標準準拠のタイムスタンプ

信頼できる時刻がない署名は、見た目ほど強くありません。署名証明書の有効期限が切れた後、その証明書が有効だった期間中に署名が存在していたことを確認するのは難しくなります。したがってタイムスタンプは署名の任意の付加機能ではなく、署名を長期的に有効にするための一部です。

ILMはTSPプロファイルと管理されたタイムスタンプ・エンジンを使ってタイムスタンプを処理します。エンジンが操作を実行し、呼び出し可能なRFC 3161エンドポイントがそれを公開します。標準に従っているため、既存のクライアントやビルドツールを変更せずに利用できます。

アクセス制御はネットワーク上の位置ではなく、適切な認証で行われます。TSPプロファイルは認証方式とBasic認証情報を保持し、専用の認証フィルターがタイムスタンプ・エンドポイントの前段に置かれます。また、TSPプロファイル・キャッシュにより、要求処理経路で毎回プロファイルを検索する必要がありません。これは、パイプラインが何千もの成果物にスタンプを付ける場合に重要です。

統合によって実際に得られるもの

「プラットフォーム統合」は簡単に言えますし、過大に売り込むのも簡単です。そこで、形容詞ではなく具体的な違いとして示します。

観点 別々のシステム 1つのプラットフォーム
インベントリ 証明書はここ、署名鍵は別、タイムスタンプ設定はさらに別 証明書、鍵、シークレット、署名、タイムスタンプを網羅する1つのインベントリ
認可 各システムが独自のロールとオペレーター定義を持つ 読み取り専用監査ロールを含む、1つの認可モデル
監査証跡 複数のログ形式を、事後に手作業で突き合わせる 証明書履歴と同じ場所に署名記録とイベント履歴を保持
鍵の保管 署名サービスへ届かせるために鍵を複製またはエクスポートする 鍵はトークン・プロファイル配下に留まり、署名処理がそれを参照する
レポーティング システムごとの部分的な回答 複数の操作を横断したダッシュボード統計
すでに鍵を保持するプラットフォームの内部へ署名とタイムスタンプを移したときに何が変わるか。

特に注目したいのは鍵の保管です。署名サービスが鍵管理システムの外にある場合、何かが境界を越えなければなりません。多くの場合、それは鍵そのもの、または鍵のコピーです。署名を鍵管理のそばに置けば、その移動は不要になります。

現実的な限界

統合は、あらゆるものを置き換えることと同じではありません。そこは正確に説明したい点です。

ILMはハードウェア・セキュリティ・モジュール（HSM）を置き換えません。鍵は引き続きポリシーで定めた場所に保存され、ILMはトークン・プロファイルを通じて参照します。同様に、ILMが署名ポリシーや暗号アルゴリズムの選択を決めるわけでもありません。そうした判断を1か所で設定し、適用された記録を1か所に残せるようにします。

規制上、適格トラストサービスが必要な場合、署名をプラットフォーム内へ移したからといって、その必要性がなくなるわけでもありません。ユースケースで適格プロバイダーによる適格タイムスタンプが必要なら、プラットフォーム自体にタイムスタンプ機能があっても、その要件は変わりません。

傘が便利なのは空を置き換えるからではなく、一度に全体を覆えるからです。

始め方

すでにILMを運用している場合、どちらの機能も新規導入ではなく設定で利用できます。既存のトークン・プロファイルを使って署名プロファイルを作成し、認証方式を指定したTSPプロファイルを作成します。次にクライアントをRFC 3161エンドポイントへ向け、署名記録が作成されることを確認します。

ILMを評価中なら、署名とタイムスタンプは通常別システムに分かれているからこそ、試すのに適した機能です。少数の証明書と一緒に設定し、これまで3つのシステムが必要だった問いに1つのダッシュボードで答えられるかを確認してください。

主なポイント

  • 署名プロファイルが設定を保持し、署名記録がエビデンスを保持します。記録はプロファイルごとに一覧表示でき、ダッシュボードで集計されます。
  • タイムスタンプは、呼び出し可能なRFC 3161エンドポイントの背後にある管理エンジンで実行されるため、既存ツールを変更せずに利用できます。
  • TSPプロファイルは認証方式とBasic認証情報を保持し、エンドポイントの前段には認証フィルターがあります。
  • 署名を鍵管理の隣に置くことで、署名サービスへ鍵を移動させる必要がなくなります。
  • ILMはHSMを置き換えず、暗号ポリシーを決定せず、適格トラストサービスに関する規制要件をなくすものでもありません。

署名とタイムスタンプは2.18.0と2.19.0のリリースにまたがって追加されました。その他の変更は2.19.0で何が変わったかをご覧ください。プラットフォーム全体の対象範囲については、ILMで構築できる10のこととトラスト・ライフサイクル管理にシークレットを含める必要がある理由をご覧ください。署名やタイムスタンプの導入について相談するには、お問い合わせください。