障害を織り込んだHSM運用。

ファームウェア、クライアントライブラリ、アプリケーションは、互いに依存し合う一つの運用チェーンを構成します。変更は、まず適切なテスト環境で検証します。承認の判断には、メーカーの注意事項と必要な認証モードを反映します。バックアップについては、ファイルが存在するだけでは十分ではありません。必要なアクセス手段、保管者、互換性のある機器、復旧手順が揃っている必要があります。合意した復旧手順をテストし、特定の鍵の複製やエクスポートが認められていない場合など、制約事項を文書化します。

世代交代は、機器の棚卸し、互換性の確認、鍵の対応付けから始まります。切り替えと切り戻しは、アプリケーションごとに計画します。承認された廃止作業は、移行が確認された後に、適切な鍵の破棄と証跡の記録とともに初めて実施します。引き継ぎには担当者の交代も含まれます。権限の取り消しやアクセス手段の交換は、組織を特定の1人に依存させることなく機能する必要があります。

クラスターは機器の障害を吸収できても、同じ設定ミスを複数のノードに抱えたままになることがあります。そのため、バックアップ、アクセス手段、復旧手順は、それぞれ独立して検討する必要があります。OTOKO®は貴社のチームとともに、どの障害まで対応すべきか、そしてどのくらいの速さで利用可能なアプリケーションを復旧させる必要があるかを計画します。テストはバックアップのインポートが成功した時点では終わりません。代表的な署名処理や復号処理が、再び正しく機能することも確認します。

運用には、目に見える兆候と、それに対応する権限を持つ担当者が必要です。機器のアラート、ログイン失敗、アプリケーションテストの結果を、具体的な対応策に結びつけます。ファームウェア、クライアント、権限の変更は、記録を残して承認します。合意したサポートについては、サービス時間、連絡体制、メーカーや他の運用パートナーへの引き継ぎを明記します。24時間稼働しているアプリケーションだからといって、24時間365日対応のサポート契約を自動的に締結していることにはなりません。

既存のHSMシリーズが、サポート終了の時期を迎えつつあります。OTOKO®は、使用中のメカニズム、エクスポート可能な鍵と不可能な鍵、そして残存する依存関係を把握します。そこから、テスト環境、並行運用、明確な中止基準を含む移行計画を作成します。切り替え後は、移行先プラットフォームでのアプリケーションテストとバックアップからの復旧を文書化します。業務面・技術面双方の要件が満たされて初めて、旧機器の制御された削除と廃止に進みます。