nShield Security World

セキュリティチームが進化するコンプライアンス義務やデータ保護要件に適応するにつれ、暗号化の利用は加速し続けています。 

HSMは、現代のITインフラストラクチャの基盤となっています。 HSMは、暗号操作のために安全な鍵の生成、保管、管理を可能にします。 しかし、暗号化のユースケースが増えるにつれて、企業はコストや運用の複雑さを増大させることなく、HSM環境を拡張しなければならなくなります。

Security Worldアーキテクチャを基盤にするnShield HSMは、セキュリティと費用対効果を最適化しながら拡張できるツールを提供します。

Security Worldは、複数のHSMにまたがるアプリケーション鍵の管理を可能にし、鍵のセキュリティを損なうことなく、一貫したポリシーの整合性を確保します。

図1： Security Worldの導入により、セキュリティチームはHSMの論理グループを統合的に管理できます。

Security Worldの構築と管理

Security WorldのドメインはnShield HSM上で初期化され、マスター鍵を生成し、管理者カードセット（ACS）として知られるスマートカードのセットを作成します。

ACSは、同じSecurity Worldのマスター鍵を追加のnShield HSMにプログラムするために使用され、同じSecurity Worldドメインに効果的に登録されます。 これにより、セキュリティチームは以下のことが可能になります。

• 暗号処理能力を拡大
• 必要に応じてHSMを交換または再デプロイ

このような繊細な操作には、ACSの資格情報を持つセキュリティ担当者によるクォーラムの承認が必要です。

Security Worldのアーキテクチャは、ユーザアプリケーション内で使用される鍵を含む、機密鍵のセキュリティに特化しています。 アプリケーション鍵には以下のようなものがあります。

• 秘密署名鍵（電子請求書アプリケーションなど）
• TLS/SSLハンドシェイク鍵
• 対称暗号鍵（クレジットカードの暗号化など）
• 信頼の基点鍵（データベース暗号化、PKI認証局向けなど）
• 機器のID
• 特権アクセス管理鍵

アプリケーション鍵トークンは、以下のカテゴリーのコンポーネントで構成されます。

鍵の要素

鍵の要素は、暗号化されたアプリケーション鍵（AES 256ビット使用）で構成されます。 ユーザはどの暗号化鍵を使うかを選択でき、それによってアプリケーション鍵の認証方法が決まります。

国の証明書と記録

ハードウェア・セキュリティ・モジュールが鍵を生成する際、鍵生成証明書が作成され、これはアプリケーション鍵トークンにも含まれます。 鍵生成証明書の署名に使われた公開鍵も含まれます。

ハードウェア・セキュリティ・モジュールが鍵を生成した時点で、ハードウェア・セキュリティ・モジュールの状態が記録され、制御と所有権がきめ細かく記録されます。 状態情報は、鍵を生成したハードウェア・セキュリティ・モジュールのIDや発行元を含む全体像を提供します。

各nShield HSMには長期固定鍵 があり、この鍵はハードウェア・セキュリティ・モジュールの製造時に生成され、ハードウェア・セキュリティ・モジュールの寿命を通じて変更されることはありません。 この鍵は状態メッセージに署名し、証明書またはEntrustによって署名された「保証書」を含みます。 保証書に署名する鍵は常にEntrustの独占的管理下にあり、鍵を生成したハードウェア・セキュリティ・モジュールが本物のnShield HSMであることを証明します。

アクセス制御リスト（ACL）

ACLは、アプリケーション鍵トークンに含まれるメタデータの重要な構成要素です。 Security Worldでは、いくつかのメカニズムがACLの完全性とセキュリティを保証しています。

鍵の生成時に関連するACLは鍵とともにラップされ、鍵そのものと同様に安全であることが保証されます。 このACLは、ライフサイクルを通じて鍵とともに保存され、鍵が使われる場所にかかわらず一貫したポリシーを施行します。

重要な点として、このアプリケーションは鍵の生成時にACLを割り当て、この割り当ては1回限りの操作です。 鍵トークンに含める暗号化された鍵のコピーは、鍵が生成されたのと同じセッション中に一度だけ作成できるため、さらなるセキュリティが追加されます。

ACLは、鍵の権限の内容を定義します。 これらの能力には以下のようなものがあります。

• 鍵が暗号化/復号化できるか
• キーが他の鍵をラップできるか、他の鍵にラップされるか
• 特定の業務について、どのレベルの承認が必要か

ACLはまた、複雑さに幅があります。

• 単純なシナリオでは、データの暗号化のような基本的な操作を承認する可能性がある
• 一方で高度なセットアップでは、階層的な鍵の関係を定義でき、特定の操作が許可される前に複数の鍵がそれぞれのトークンを介して読み込まれる必要がある

さらに、ACLは次のような使用制約を強制できます。

• 操作のタイムアウト
• 許可された操作数の制限

ACLによって、Security Worldは、鍵の使用方法、共有方法、管理方法をきめ細かく制御し、セキュリティを微調整することができます。

認証トークン

Security World環境では、特定のアプリケーション鍵へのアクセスを制御するために認証トークンが使用されます。 アプリケーション鍵が生成されると、認証トークンと関連付けることができます。 その結果、正しい認証トークンが提示され、検証に成功しない限り、その鍵をHSMに読み込むことはできません。

Security Worldには次の3種類の認証トークンがあります。

1. スマートカードセット： スマートカードセットは、多要素でクォーラムベースの認証を提供します。 セキュリティチームは、1セットに何枚のスマートカードがあり、特定のアクションを承認するために何枚必要かを定義できます。

たとえば、管理者用スマートカードが5枚ある環境では、Security Worldドメインへの新しいHSMの追加を承認するために、管理者は少なくとも3枚のカードの提示を要求するよう設定できます。

Security Worldドメインには、次の2種類のスマートカードセットがあります。

• 管理者カードセット（ACS）： 災害復旧作業などの管理作業を承認するために使用されます
• オペレーターカードセット（OCS）： ハードウェア・セキュリティ・モジュールがアプリケーション鍵にアクセスし、使用するのを承認するために使用されます。

2. ソフトカード： ソフトカードは、一要素認証を提供するソフトウェアベースのトークンです。 HSMスマートカードリーダーへの物理的なアクセスが現実的でない環境で、特に役立ちます。

3. モジュール保護鍵： ハードウェア・セキュリティ・モジュールを使用して鍵を保護する場合に適しています。また、アプリケーション鍵を使用する際に人間の介在を必要としないため、 24時間稼動および自動化が必要なアプリケーションに適しています。

鍵の使用権限を付与する方法（スマートカード、ソフトカード、モジュール保護鍵）は鍵の作成時に選択され、Security Worldに保存されます。

カスタマイズ可能な認証ポリシー

Security Worldは、鍵の使用権限ポリシーを導入する際に、管理者に優れた柔軟性を提供します。

• アプリケーション鍵ごとにOCSまたはソフトカードによる保護を選択可能
• OCSを使用する場合、管理者は次の設定が可能です。
  • セット内のカードの枚数
  • クォーラム要件（操作を承認するために何枚のカードが存在しなければならないか）
  • 各カードのパスフレーズ、またはパスフレーズが必要かどうか
  • カードがnShield HSMのスマートカードリーダーに挿入されたままでなければならないか、使用後に取り外すことができるか

これらの機能は、使いやすさ、コンプライアンス、強力なセキュリティ制御のバランスを取りながら、暗号鍵のアクセスポリシーを実施するための非常に多用途で安全なフレームワークを提供します。

上記の機能により、アプリケーション鍵はセキュリティを損なうことなく、安全に暗号化され、安全に分散され、ハードウェア・セキュリティ・モジュールの外部に保存されます。

スマートカード、ハードウェア・セキュリティ・モジュールレベルのポリシー、ACL、その他の組み込みメカニズムを含む堅牢なポリシー制御を活用することで、セキュリティチームは、環境全体に統一されたセキュリティポリシーを適用できる一方で、特定のHSM、テクノロジースタック、ユーザグループなどにきめ細かい制御を適用する柔軟性を維持できます。

Security Worldの環境では、生の鍵材料は常に認証されたnShield HSMによって保護されています。アプリケーション鍵トークンをハードウェア・セキュリティ・モジュール外のストレージに保存する場合、標準的なバッ クアップ手順を使用して、安全にバックアップおよび復元できます。

その後、承認済みクライアントアプリケーションが、これらのトークンを同じSecurity Worldドメイン内のどのハードウェア・セキュリティ・モジュールにも読み込んで暗号処理を実行できるため、セキュリティ、ポータビリティ、運用の継続性が確保されます。