®鍵管理
HSMが貴社のアプリケーションを保護できるのは、鍵が正しく生成、使用、更新、保管されて初めてです。アプリケーションと鍵サービスを接続し、運用担当と開発担当の双方が確実に扱えるようにライフサイクルを設計します。
OTOKO®へのご依頼内容
PKCS#11は、暗号トークン向けのインターフェースを規定しています。KMIPなどの鍵管理プロトコルは、これとは別の統合経路に対応します。貴社のアプリケーションが何をサポートしているか、HSM内でどの処理が行われる必要があるかを確認します。規格名が同じというだけでは、置き換え可能性は保証されません。メカニズム、オブジェクトの属性、セッション、プロバイダーの挙動は、実際の組み合わせの中でテストします。データの暗号化についても、鍵へのアクセスと大量データの処理を適切に分離できるよう、データ暗号化と鍵暗号化とを区別します。
具体的な範囲、貴社の関与、検収基準は、開始前に取り決めます。
技術を分かりやすく解説
新しい鍵ができたからといって、古い鍵をすぐに削除できるわけではありません。どのデータ、署名、バックアップが以前のバージョンにまだ依存しているかを把握します。アプリケーションには、鍵のバージョンへの一意な対応付けが必要です。生成、有効化、失効、アーカイブ、削除には、それぞれ別の状態と承認を設定します。セッションの枯渇、認証の期限切れ、接続の切断といったエラーは、目に見える形で処理します。再試行によって、意図しない鍵の重複や、業務上の重複処理が生じてはなりません。
テストでは、成功する呼び出しだけでなく、拒否されるべきロールや許可されていない操作も確認します。認証情報や秘密情報は、ソースコード、ログ、一般的なバックアップに含まれてはなりません。貴社のチームには、設定内容、サンプルシナリオ、診断手順をお渡しします。開始にあたっては、使用しているライブラリ、実行環境、既存の鍵の状況が重要になります。
PKCS #11は、暗号トークンとその機能へのアクセス方法を規定します。KMIPは、クライアントと鍵管理システムとの間での暗号オブジェクトの管理に対応します。一方、クラウドサービスは独自のREST APIを提供することもあります。これらの間に自動的な置き換え可能性はありません。OTOKO®は、ある処理がどこで実行されるか、あるインターフェースが実際にどの鍵材料を伝送するか、どの属性が保持されるかを文書化します。こうして、プロトコルの一覧が、明確な統合経路へと具体化されます。
階層型暗号化では、データ鍵が実際のデータを保護し、上位鍵がそのデータ鍵を保護します。これにより、大きなデータブロックをすべてHSMで処理する必要がなくなります。重要なのは、データ鍵がどこで平文として必要になり、そこでどのくらいの時間利用可能な状態が続くかです。アプリケーション内でのキャッシュの挙動、ローテーション、アクセスを明確にします。「鍵はHSM内にとどまる」という表現は、具体的に検討した鍵の役割とその属性についてのみ成り立ちます。
これまで複数のサービスが、それぞれ独自の鍵ファイルを使用してきました。OTOKO®はまず、所有者、目的、データの依存関係を整理します。次に、代表的な1つのサービスでサポートされている統合方式を試し、アプリケーションごとに権限を定義します。移行は段階的に行い、既存データの読み取りと新規データの書き込みを制御しながら進めます。保持、バックアップ、復旧の考慮が済むまでは、古い鍵を削除しません。成果として、テスト済みの利用手順と切り替え手順を備えた、文書化された鍵インベントリが得られます。
検証可能な成果
引き継ぎでは、実装とドキュメントを一体的に扱います。合意したケースを共に確認し、残る課題を記録します。
最初の一歩の前に
多くの場合、適切なプロバイダーと必要なメカニズムがサポートされていれば可能です。具体的なバージョンと、エラー発生時のアプリケーションの挙動を確認します。
許可された用途がなくなり、保持要件と復旧要件が明確になった時点で初めて削除します。ローテーションと削除は別々の手順です。
いいえ。新しい鍵は、まず新規の処理にだけ使用することもできます。既存データを再暗号化する必要があるか、データ鍵を再ラップする必要があるかは、方式と保護目標によって異なります。古いデータやバックアップの可読性は維持されなければなりません。
クライアントとサーバーの双方が、必要なバージョン、プロファイル、オブジェクトタイプ、操作をサポートしている必要があります。認証、オブジェクト属性、障害発生時の挙動については、実際の製品の組み合わせでテストします。
上位鍵はHSM内で保護される一方、データ鍵はラップされた形式で保存され、データ処理のためにアプリケーション内で一時的に使用されることがあります。画一的な説明をするのではなく、鍵の役割ごとにその境界を文書化します。
アプリケーションごとに独自のIDと厳格に制限された権限を割り当てます。鍵の目的、環境、責任の所在が承認範囲を決定します。ネガティブテストでは、他のアプリケーションの鍵や許可されていない操作が実際に拒否されるかどうかを確認します。
