メニュー

お問い合わせ
Logo
プレス

PKIと証明書

保護された鍵によるPKIと署名。

証明書は、ID情報と鍵とを結び付けます。証明書階層を設計し、CA鍵と署名鍵をHSM内で保護し、発行、更新、失効を貴社の環境に統合します。ソフトウェアのリリースについては、自由に使える鍵ファイルの代わりに、統制された署名プロセスを構築します。

光るノートパソコンのキーボードの接写、イメージ画像
PKIおよび署名アーキテクチャ・OTOKO®による計画と実装

OTOKO®へのご依頼内容

私たちが貴社のために担うこと。

証明書を誰が申請、承認、発行できるか、そこでどのIDが証明されるかを定めます。ルートCA、発行CA、ステータスサービスにはそれぞれ別の役割を割り当てます。有効期間、更新のタイミング、失効手続きは、利用者と機器に合わせて選定します。自動更新であっても監視は必要です。正常に開始されたプロセスが、すべての対象システムに証明書がインストールされたことを意味するわけではありません。

想定されるサービス範囲

  • 信頼モデルとロールモデルを踏まえて、ルートCAと発行CAを設計する
  • サポートされているインターフェースを通じてCAまたは署名アプリケーションを接続する
  • 証明書プロファイル、更新、失効情報を設定する
  • 鍵セレモニーとオフライン手順を準備する
  • コード署名の承認を配布チェーンと連携させる

具体的な範囲、貴社の関与、検収基準は、開始前に取り決めます。

技術を分かりやすく解説

私たちはこのように課題に取り組みます。

01

鍵は保護されたまま、判断はアプリケーションが行う

HSMは、想定された範囲内で署名鍵を保護しますが、ソフトウェアパッケージをリリースすべきかどうかを自ら判断するわけではありません。そのため、署名の呼び出しは、識別されたアプリケーション、権限、承認と結び付けます。コード署名では、成果物と承認とを紐づけることで、後からの改変を検知できるようにします。CAソフトウェアとHSMプロバイダーは、使用するアルゴリズムと鍵アクセスの方式に共に対応している必要があります。トラストストア、ステータス確認、更新については、代表的な接続先システムでテストします。

02

失効と復旧の手順を訓練する

管理者カードの紛失、証明書の期限切れ、発行CAの侵害は、それぞれ異なる事象です。適切な手順を策定し、合意した復旧経路をテストします。検収では、発行、更新、失効、不備のある申請などを文書化します。既存の証明書プロファイル、機器の分類、信頼関係は、移行期間中の並行運用を計画する助けになります。

03

Microsoft AD CS、Javaアプリケーション、独自の署名サービス

それぞれの製品がサポートする接続方式を確認します。例えば、CNG Key Storage Provider、PKCS #11、Javaプロバイダーなどです。アルゴリズム名が同じであるだけでは互換性は保証されません。メカニズム、鍵の属性、パディング、プロバイダーのバージョンも一致している必要があります。既存の認証局については、許可された鍵の移送が可能か、それとも移行期間を設けた新しいCAが必要かを明確にします。接続されているシステムの信頼関係も、テストの中で明示的に考慮します。

04

ビルドパイプライン内のコード署名を管理する

パイプラインが、自由に使える本番用の鍵を常時保持しているべきではありません。ビルドと署名承認とを分離し、依頼を識別されたシステムに紐づけ、どの成果物をどの鍵で署名してよいかを定めます。タイムスタンプ、成果物のハッシュの証跡、ログの記録は、署名形式に合わせて計画します。HSMはあくまで保護のための構成要素です。コードの検証と公開の判断は、引き続き開発プロセスと承認プロセスが担います。

05

例:既存の企業PKIをモダナイズする

ある組織が、すでに機器、利用者、社内サービス向けの証明書を運用しています。OTOKO®は証明書プロファイル、配布方法、信頼チェーンを把握し、想定しているHSM接続をまず本番環境の外で検証します。その後、更新、失効情報、切り戻しが可能な範囲を含めて移行を計画します。引き継ぎの前には、具体的な接続先システムで検証を行います。発行された証明書は、想定されたシステムでログイン、サービスアクセス、署名検証が機能して初めて成功と言えます。

OTOKO®ケルンオフィスのミーティングルーム

検証可能な成果

貴社がこの先活用できる成果です。

  1. PKIおよび署名アーキテクチャ
  2. テスト証跡を伴う実装済みの接続
  3. セレモニー・運用マニュアル

引き継ぎでは、実装とドキュメントを一体的に扱います。合意したケースを共に確認し、残る課題を記録します。

最初の一歩の前に

PKIと証明書に関するご質問。

既存のPKIを置き換える必要がありますか?

自動的にそうなるわけではありません。HSM接続、既存の鍵、信頼チェーンを確認します。段階的な拡張や並行階層のほうが、全面的な置き換えよりも適している場合があります。

これによって、すべての署名が適格電子署名になるのですか?

いいえ。HSMだけでは適格電子署名(QES)にはなりません。そのためには、具体的なサービス、手続き、該当する要件を別途確認する必要があります。

オフラインのルートCAにもHSMは有効ですか?

長期間使用するルート鍵を保護するという観点では、有効な選択肢になり得ます。ただし、この方式には、分離された保管、明確に定義された起動手続き、文書化されたセレモニーの手順、実証済みの復旧経路も同様に含まれます。機器だけでは、これらの手続きの代わりにはなりません。

Microsoft AD CSとの接続は可能ですか?

使用する組み合わせに対応したプロバイダーを介して、接続を検証し実装します。重要になるのは、WindowsおよびCAのバージョン、HSMファームウェア、クライアントライブラリ、必要なアルゴリズムです。既存の鍵については、別途移行検証が必要です。

HSMは、改ざんされたソフトウェアへの署名を防いでくれますか?

HSMは、想定された範囲で鍵材料を保護します。ある成果物を公開してよいかどうかは、署名プロセスが判断します。そのため、HSM接続をID、制限された権限、後から確認できる承認と組み合わせます。

PKI接続の検収には何が含まれますか?

発行、使用、更新、失効、および許可されない申請に対するテストを合意します。これに加えて、復旧やHSM障害時の挙動も対象とします。範囲と代表的な接続先システムは、事前に定めます。

貴社のプロジェクト

解決したい課題をお聞かせください。

現状と望む成果をご記入ください。選択したサービスは、お問い合わせ内容に反映されます。

このサービスについて問い合わせる

パートナー

  • Microsoft
  • Microsoft Azure
  • Amazon AWS
  • Google Cloud
  • Thales Group
  • Arrow ECS
  • Vodafone
  • IBM
  • Veeam
  • Atlassian
  • JetBrains
  • NinjaOne
  • OPSWAT
  • Utimaco
  • Eviden

アクセシビリティ

表示をご自身のニーズに合わせて調整できます。

このページには、まだやさしい日本語版がありません。

設定は現在、今回の閲覧にのみ適用されます。永続的な保存は「Cookie設定」で許可できます。