鍵セレモニーは計画された作業手順
セレモニーでは、前提条件、役割、統制手順、中止条件をあらかじめ定めます。鍵の構成要素とアクセス手段は、合意した手続きに従って、それぞれ別の保管者が管理します。記録は、秘密の構成要素を明らかにすることなく、実施内容を文書化します。TR-31やTR-34などによる鍵ブロックの交換では、双方が形式、鍵の用途、許可された操作について一致してサポートしている必要があります。本番用の鍵や決済経路に影響が及ぶ前に、合成データを用いたテストでこれらの取り決めを確認します。
決済用HSM
決済においては、鍵の受け渡し、PIN処理、システムの切り替えが統制された形で連動する必要があります。貴社の責任者とともに、技術的なHSM接続と関連する手続きを計画します。役割、承認、文書化されたセレモニーは実装の一部です。

OTOKO®へのご依頼内容
貴社のシステムが決済プロセスの中でどのような役割を担い、実際にどの暗号処理を必要とするかを把握します。鍵の用途、参加者、受け渡しのポイントを文書化します。汎用のHSMが、決済コマンドに自動的に適しているわけではありません。選定にあたっては、貴社が接続しているネットワークやパートナーの要件、既存の処理システムが対応している方式を考慮します。
具体的な範囲、貴社の関与、検収基準は、開始前に取り決めます。
技術を分かりやすく解説
セレモニーでは、前提条件、役割、統制手順、中止条件をあらかじめ定めます。鍵の構成要素とアクセス手段は、合意した手続きに従って、それぞれ別の保管者が管理します。記録は、秘密の構成要素を明らかにすることなく、実施内容を文書化します。TR-31やTR-34などによる鍵ブロックの交換では、双方が形式、鍵の用途、許可された操作について一致してサポートしている必要があります。本番用の鍵や決済経路に影響が及ぶ前に、合成データを用いたテストでこれらの取り決めを確認します。
移行計画には、時間枠、パートナーの対応可能状況、切り戻しが可能な範囲、取引照合を含めます。すでに実行された決済のすべてが、技術的なロールバックで取り消せるわけではありません。そのため、切り戻し手順と手動での確認方法は業務側とすり合わせます。文書化されたテスト結果、責任分担、貴社の審査プロセス向けに合意した証跡をお渡しします。正式な認証はこれとは別のものです。
PIN処理、カードのパーソナライゼーション、端末の鍵処理は、企業向けPKIとは異なる要件を持ちます。必要なコマンド、鍵の用途、形式を、利用している決済プラットフォームと照合します。これには、ホスト接続、テスト用アクセス、関係するパートナーの要件も含まれます。汎用HSMの高い暗号処理性能は、対応済みの決済機能の代わりにはなりません。逆に、決済用HSMを、確認のないまま任意のアプリケーション向けの汎用鍵プラットフォームにすべきではありません。
鍵の受け渡しでは、送信側と受信側が同じ鍵長に対応しているだけでは足りません。用途への紐づけ、アルゴリズム、許可された操作、転送時の保護が、互いに整合している必要があります。想定している鍵ブロックおよび配送方式を文書化し、非本番用の鍵で対応形式をテストし、エラー応答を確認します。その際、TR-31鍵ブロックとTR-34による配送は、任意に置き換え可能な形式としてではなく、それぞれ別の作業として扱います。
機器を切り替える前に、OTOKO®は貴社の運用チームとともに、使用しているコマンドと鍵ゾーンの棚卸しを行います。テスト計画では、技術的な応答コードと業務上の期待値とを結び付けます。切り替えにあたっては、接続先パートナーの窓口、承認、統制照合をあらかじめ確保しておきます。テストが成功し、切り替え計画について合意して初めて、本番の作業枠に移ります。最終報告書には、どの鍵と手順を移行したか、どの既存資産が引き続き必要かを記録します。

検証可能な成果
引き継ぎでは、実装とドキュメントを一体的に扱います。合意したケースを共に確認し、残る課題を記録します。
最初の一歩の前に
これは、鍵の属性、セキュリティ規則、対応している移行手順によって異なります。許可された受け渡しのみを計画します。エクスポートできない鍵には、別の移行方法が必要になる場合があります。
役割分担は、貴社が承認した統制モデルに従います。必要な関係者と分離された責任は事前に定めるものであり、技術的なサービス提供によって解消されるものではありません。
必要な決済機能と要件の証明がなければ、代わりにはなりません。決済コマンド、鍵処理方式、具体的な検証状況が、処理チェーンに適合している必要があります。機器を推奨する前に、私たちがこれらの点を確認します。
統合テストやエラーテストには、非本番のテストデータとテスト用の鍵を用います。本番用のセレモニーは別途承認を受け、合意した統制モデルに従って実施します。秘密の鍵材料は、チケットやテスト記録に含めません。
統制を分離するのは、一人だけで重要な操作を実行できないようにするためです。Split Knowledgeは、想定された手続きに従って、秘密に関する知識を分散させます。どの役割と技術的な仕組みが必要かは、具体的なプロセスごとに定めます。
技術的な統合は、環境全体に対する正式な証明ではありません。OTOKO®は、合意した技術的な証跡と運用資料を準備します。担当する監査人、評価範囲、正式な承認は別途調整します。