Entrust

Entrust関連

  • カテゴリーなし

Entrust CSP Vault（Cryptographic Security Platform Vault）とは

Entrust CSP Vault（Cryptographic Security Platform Vault）は、Entrust社の統合セキュリティプラットフォーム「CSP」において、実際に暗号化や暗号鍵・シークレットの管理を行う仮想アプライアンス（金庫室・管理基盤）です。

主な役割と機能

  • 暗号鍵・シークレットの一元管理: オンプレミスやクラウド環境に分散する暗号鍵やパスワード、APIトークンなどのシークレット情報を安全に保管・制御します。
  • 用途別のVault構築: 機能ごとに専用のVault（金庫）を作成でき、管理用URLを発行して柔軟に運用できます。

    主な用途（Vaultの種類）
  • Vault for KMIP: 鍵管理の相互運用プロトコル「KMIP」に対応し、VMware等のKMS（鍵管理サーバー）として機能します。
  • Vault for VM Encryption: 仮想マシン（VM）の暗号化と鍵ライフサイクルを管理します。 [1]
  • Vault for Secrets: データベースやサーバー等にあるシークレット情報の管理や自動ローテーションを行います。
  • Vault for Cloud Keys: クラウド環境への暗号鍵の持ち込み（BYOK / HYOK）を管理し、クラウド上のデータを保護します。
  • Vault for Databases: Oracle DatabaseやMicrosoft SQL Serverなどの透過的データベース暗号化（TDE）の暗号鍵を管理します。
  • Vault for Cryptographic APIs (Tokenization): 機密データのトークナイゼーションやマスキング、紐づく鍵の管理をREST API経由で実行します。

もし特定の用途（VMwareの暗号化、クラウド鍵の管理、データベースの暗号化など）について詳しく知りたい場合は、対象のシナリオをお知らせください

Entrustが推進するPQCハイブリッド証明書や複合証明書（Composite Certificates）の仕組みと具体的な移行時のメリット

EntrustがIETFの標準化活動（X.509ドラフト等）を通じて主導しているPQCハイブリッド／複合（Composite）証明書は、現行暗号（RSAやECDSA）と耐量子暗号（ML-DSA/Dilithium等）を単一またはペアの証明書構造に組み込み、後方互換性を保ちながら量子耐性を獲得するアプローチです。

1. 仕組み（Composite / Hybrid のアプローチ）

主に以下の2つのアーキテクチャが定義・運用されています。

【複合証明書（Composite Certificates）の概念】

  +-------------------------------------------------------+
  |              X.509 v3 Composite Certificate           |
  |                                                       |
  |  公開鍵情報:                                          |
  |    [ RSA / ECDSA 公開鍵 ]  +  [ ML-DSA / PQC 公開鍵 ]  |
  |                                                       |
  |  署名値:                                              |
  |    [ 古典暗号の署名 ]      +  [ PQC の署名 ]           |
  +-------------------------------------------------------+
                             |
         +-------------------+-------------------+
         |                                       |
    [古典クライアント]                      [PQC対応クライアント]
  古典署名・公開鍵のみを検証              両方の署名・公開鍵を検証
  （通信断を回避）                        （量子耐性を即時確保）

① 複合暗号方式（Composite Cryptography）

  • 1つの証明書内に複数鍵・複数署名を埋め込む方式です。
  • Subject Public Key Info (SPKI) に「RSA + ML-DSA」などの組み合わせ鍵を1つの複合キーOIDとして格納し、CA署名も「両方の鍵アルゴリズムによる連続署名」として1つの複合署名OIDで付与します。
  • 判定ルール（AND条件）: PQC対応検証機は、古典署名とPQC署名の両方が正当である場合のみ認証をパスさせます。どちらか一方に未知の脆弱性が見つかっても、もう片方の暗号が破られない限り安全性が担保されます。

② デュアル証明書（Chameleon / Alternative X.509 拡張方式）

  • X.509の標準拡張フィールド（Non-critical拡張）にPQCの公開鍵や署名情報を埋め込む方式です。
  • PQC非対応の古い検証機: 拡張フィールドを単に無視（スキップ）し、従来のRSA/ECDSA証明書として問題なく検証・接続します。
  • PQC対応の新しい検証機: 拡張フィールドからPQC公開鍵・署名を読み出し、耐量子検証を行います。

2. 移行時における具体的なメリット

メリット詳細
通信断ゼロでの段階的移行（後方互換性）古典暗号しか理解できないレガシー端末・OS・ミドルウェアが存在する環境でもエラーや通信遮断を起こさず、システム全体を一度に一斉更改（Big Bang移行）する必要がなくなります。
即時のHNDL攻撃（盗聴・将来解読）対策鍵交換（KEM）においてハイブリッド（ECDH + ML-KEM）を組み合わせることで、今収集されている暗号化通信が将来の量子コンピュータで復元されるリスクを直ちに無力化できます。
初期PQCアルゴリズムの未知の脆弱性リスクヘッジNIST標準化PQCは数学的に堅牢とされていますが、古典暗号（RSA/ECC）ほど長年の運用実績（暗号解読攻撃に対する耐性検証）がありません。古典暗号と組み合わせることで、「PQC側に万が一の不備が見つかった場合」も現行セキュリティが維持されます。
インフラ投資とPKI運用の平準化ルートCAや中間CA、末端エンティティをいきなりPure PQCに置き換えるのではなく、既存のPKI階層やHSM（nShield等）にCompositeポリシーをプラグインする形で段階的検証を進められます。

3. 実装上の考慮点（オーバーヘッド）

  • 証明書サイズとパケット断片化: PQCの鍵長および署名長はRSA/ECCに比べて大幅に大きいため、複合証明書のサイズは数KB〜十数KBに達します。TLSハンドシェイク時のTCPパケット分割（MTU超え）やメモリ使用量への影響を事前検証する必要があります。
  • CPU負荷: 2つの署名・検証処理が走るため、高スループットが求められるAPIゲートウェイやロードバランサー等ではハードウェアオフロードやHSMのサイジングが重要になります。

Entrust CSP（Cryptographic Security Platform）のPQC対応

Entrustの CSP（Cryptographic Security Platform / 暗号セキュリティプラットフォーム） は、暗号資産の棚卸しからポリシー統制、耐量子計算機暗号（PQC）への移行までを包括的に支援する統合プラットフォームとしてPQC対応を推進しています。

主なPQC対応機能と取り組みは以下のとおりです。

1. 暗号資産の可視化と棚卸し（Crypto Inventory & Discovery）

  • 自動ディスカバリとリスク評価: ネットワーク、サーバー、クラウド環境内に存在するSSL/TLS証明書、SSHキー、暗号鍵などの資産を自動スキャンし、暗号台帳（クリプト・インベントリ）を構築します。
  • 量子脆弱性の特定: どのシステムでRSAやECCといった量子コンピュータによって解読されるリスクがあるアルゴリズムが使われているかをスコアリング・可視化し、優先的に移行すべき箇所を特定します。

2. 暗号アジリティ（Crypto-Agility）とライフサイクル自動化

  • ポリシーに基づくアルゴリズム切替: アルゴリズムの変更や鍵長の拡張が必要になった際、個々のシステムを改修することなく中央管理画面からポリシーを一元適用・更新できます。
  • ライフサイクル運用の自動化:証明書の発行、更新、失効をACMEやESTなどのプロトコルを通じて自動化し、短有効期間化やPQC移行に伴う運用負荷を抑えます。

3. ハイブリッドおよび複合（Composite）証明書のサポート

  • 下位互換性を確保した移行: 従来の古典暗号（RSA/ECDSA）とNIST標準PQCアルゴリズム（ML-KEM/Kyber、ML-DSA/Dilithium等）を組み合わせたハイブリッド証明書／複合証明書（Composite Certificates）の発行・運用に対応しています。
  • 標準化への貢献:EntrustはIETFにおける複合証明書ドラフトの策定をリードしており、移行期間中も既存クライアントとの通信を遮断せずに段階的なPQC検証・導入が可能です。

4. ハードウェア（nShield HSM）およびPKI基盤との連携

  • PQC-ready HSM統合: ルートCAや中間CAの秘密鍵生成・保護において、耐量子暗号の拡張パック（nShield Post-Quantum Option Pack等）を備えたHSMとネイティブに連携します。
  • Pure PQC / Hybrid CA階層の構築: クラウド型PKI（PKIaaS）やオンプレミスPKIと連動し、純粋なPQC証明書階層だけでなくハイブリッド型認証局の構成・管理を一元的に実行できます。

導入検討における位置づけ

Entrust CSPは、「暗号の現状把握（どこにあるか）」から「PQCアルゴリズムへの移行・ハイブリッド運用の検証」、そして「継続的な統制」までを1つのコントロールプレーンでカバーできるため、金融機関や政府機関などが求める暗号移行ロードマップに適合する設計となっています。

金融庁のPQC（耐量子計算機暗号）への対応

金融庁は、将来的な量子コンピュータの実用化によりRSAや楕円曲線暗号などの現行公開鍵暗号が解読されるリスク（特に「今暗号化通信を盗聴・保存し、将来解読する」HNDL：Harvest Now Decrypt Later攻撃）を見据え、金融機関に対して早期かつ計画的なPQC（耐量子計算機暗号）への移行を求めています。

金融庁の主な動向と公表物

  1. 検討会の設置と報告書の公表（2024年11月）「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会報告書」を公表。暗号危殆化の技術動向やリスクを整理し、金融機関の経営層およびシステム責任者向けに対応指針や推奨事項を示しました。
  2. ITレジリエンス分析レポートへの反映（2025年6月）「金融分野におけるITレジリエンスに関する分析レポート」において、サイバーレジリエンス確保の必須要素としてPQC対応の要諦を再提示し、監督上の着眼点にも位置づけました。

金融庁が金融機関に求める主要対策（要点）

  • クリプト・インベントリ（暗号資産台帳）の作成自社管理システムだけでなく、委託先（サードパーティ）の重要システムも含めて、どこでどのような暗号技術が使われているかを網羅的に可視化・棚卸しすること。
  • ITベンダーとの早期連携暗号の洗い出しや影響範囲の特定には専門知識を要するため、初期検討の段階から委託先ベンダーやSIerと緊密に連携すること。
  • リスクベースアプローチとロードマップ策定外部接続や認証・鍵交換など、量子危殆化の影響が大きい重要システムから優先順位をつけて移行計画（マイルストーンや体制）を策定すること。
  • クリプト・アジリティ（暗号の俊敏性）の確保将来の暗号アルゴリズムの脆弱性発覚や進化に合わせて、暗号モジュールや方式を容易に切り替えられるアーキテクチャ（ハイブリッド方式の採用など）を設計に組み込むこと。
  • 経営陣のコミットメントPQC対応を単なる現場のIT改修ではなく「中長期的な全社経営課題」と位置づけ、予算や人材などの経営資源を適切に配分すること。

AWS KMS External Key Store (XKS) と Entrust CSP Vault を接続する際の具体的なアーキテクチャ要件と設定手順

AWS KMS External Key Store（XKS）と Entrust CSP Vault（旧 KeyControl / nShield HSM 連携） を接続することで、暗号化マスター鍵（Root of Trust）を完全にオンプレミスまたは自社管理環境に保持したまま、AWS サービス（EBS, S3, RDS 等）のエンベロープ暗号化を実行できます。

1. 接続アーキテクチャ要件

XKS と外部キーストアプロバイダー（Entrust CSP Vault）間の接続には、主に2つの通信方式が存在します。本番環境ではセキュリティ要件に応じて AWS Direct Connect / VPN + VPC エンドポイントサービス（AWS PrivateLink） 経由の接続が推奨されます。

[ AWS Cloud (Region) ]
  AWS KMS (XKS) 
      │
      ▼ (VPC エンドポイント)
  AWS VPC ── (AWS PrivateLink / Direct Connect / VPN) ──> [ オンプレミス / データセンター ]
                                                              │
                                                              ▼ (HTTPS / TLS 1.2 or 1.3)
                                                        [ ロードバランサー / リバースプロキシ ]
                                                              │
                                                              ▼ (XKS Proxy API / HMAC-SHA256 署名検証)
                                                        [ Entrust CSP Vault 集約クラスタ ]
                                                              │ (PKCS#11 / Security World)
                                                              ▼
                                                        [ Entrust nShield HSM ]

主な技術・インフラ要件

  • プロトコル & 仕様:
    • AWS KMS XKS Proxy 仕様に準拠した RESTful API（暗号化・復号、キーのステータス取得など）。
    • トランスポート層: TLS 1.2 または TLS 1.3（パブリック認証局またはプライベート CA 証明書）。
  • 認証・認可メカニズム:
    • HMAC-SHA256 認証: AWS KMS と CSP Vault 間で事前共有された「Access Key ID」と「Secret Access Key」を使用して、各リクエストヘッダーに SigV4 形式の署名を付与・検証。
  • ネットワーク & レイテンシ要件:
    • タイムアウト値: AWS KMS XKS のリクエストタイムアウトは 250 ミリ秒（ms） 以内。ネットワーク往復および HSM 処理時間を含めてこの制約を満たす必要があります。
  • 可用性・冗長性:
    • CSP Vault ノード最低2台以上のクラスタ構成、および nShield HSM の Security World による鍵共有プーリング。

2. 具体的な設定・構築手順

接続設定は大きく「CSP Vault 側の準備」と「AWS KMS 側の設定」の4つのフェーズで実施します。

フェーズ 1: Entrust CSP Vault / nShield HSM 側の準備

  1. 暗号鍵の生成:
    • CSP Vault 管理コンソールにて、AWS XKS 用の外部マスターキー（AES-256 対称鍵）を生成します。
    • バックエンドの nShield HSM（Security World）で保護されるストレージプールに鍵を割り当てます。
  2. XKS Proxy インスタンスの有効化:
    • CSP Vault の「Cloud Keys / KMS」設定で AWS XKS Proxy サービスを有効化します。
  3. 認証クレデンシャルの発行:
    • AWS KMS との相互認証用として、XKS Proxy Credential（Access Key ID / Secret Access Key） を生成し、安全に退避します。
  4. 接続エンドポイントとパスの確認:
    • リバースプロキシや LB 経由で公開される Base URL（例: [https://xks.corp.example.com/kms/xks/v1](https://xks.corp.example.com/kms/xks/v1)）および XKS キー ID（URN / 鍵識別子）を控えます。

フェーズ 2: ネットワークと PrivateLink の構成（VPC 接続の場合）

  1. AWS 側 VPC にターゲットグループ作成:
    • オンプレミス側の CSP Vault / リバースプロキシの IP アドレスをターゲットに指定。
  2. VPC エンドポイントサービス（PrivateLink）の作成:
    • Network Load Balancer（NLB）を作成し、エンドポイントサービスを構成。
    • AWS KMS サービスプリンシパル（kms.<region>.amazonaws.com）に対して接続許可ポリシーを付与します。

フェーズ 3: AWS KMS 側で External Key Store を作成・接続

  1. 外部キーストアの作成:
    • AWS マネジメントコンソール（または AWS CLI: aws kms create-custom-key-store）を開きます。
    • キーストアタイプ: External key store (XKS) を選択。
    • 接続タイプ: VPC endpoint service name（PrivateLink 経由）または Public endpoint を指定。
    • XKS Proxy エンドポイントパス: CSP Vault の Base URL を入力。
    • XKS Proxy 認証情報: フェーズ 1 で取得した Access Key ID と Secret Access Key を入力。
  2. キーストアの接続（Connect）:
    • 作成した外部キーストアを選択し、「Connect」を実行します。
    • AWS KMS が自動的にヘルスチェックリクエスト（GetHealthStatus / DescribeKey 等）を CSP Vault に送信し、ステータスが Connected になることを確認します。

フェーズ 4: KMS キーの作成と動作確認

  1. XKS キーの作成:
    • KMS 管理画面から「キーの作成」を選択。
    • キータイプ: 対称 (Symmetric)
    • キーの使用方法: 暗号化/復号
    • キーストア: 先ほど作成・接続した「外部キーストア（XKS）」を選択。
    • 外部キー ID: フェーズ 1 で CSP Vault 側に登録した外部鍵 ID をマッピングします。
  2. 疎通・暗号化テスト:
    • AWS CLI を使用してテストデータを暗号化・復号し、CSP Vault の監査ログ（Compliance Manager）にリクエストが正しく記録されているか検証します。

3. 設計・運用時の注意点

  • 250ms タイムアウト超過の回避:
    • 地理的に離れたリージョンからオンプレミスへ接続する場合、ネットワーク遅延のみで 200ms 近く消費することがあります。AWS リージョンと同一都市または低遅延な専用線（Direct Connect）内に CSP Vault / HSM を配置することが推奨されます。
  • キルスイッチ機能（即時アクセス遮断）:
    • AWS 側の設定を変更せずとも、CSP Vault 側で該当の XKS クレデンシャルを無効化、または HSM 側の鍵アクセス権を剥奪するだけで、AWS 上の全暗号化データへのアクセスを即時に遮断できます。

Microsoft 365 DKEとEntrust CSP Vaultを連携する際の認証フロー、可用性・冗長化設計のポイント

Microsoft 365 の Double Key Encryption（DKE）と Entrust CSP Vault（旧 KeyControl / nShield HSM 連携） を連携させる構成では、クラウド（Microsoft Entra ID / Purview）と自社管理インフラ（CSP Vault / HSM）の間でセキュアな認証チェーンを確立し、単一障害点（SPOF）を排除した可用性設計が不可欠です。

1. 認証・認可フローの詳細

DKE では、Office クライアント（Word、Excel 等）が Microsoft Entra ID（旧 Azure AD） で発行された JWT トークンを用いて、オンプレミス側の DKE サービス（CSP Vault）へアクセスします。

[クライアント端末] ────── 1. ユーザー認証・トークン要求 ─────> [Microsoft Entra ID]
       │         <───── 2. JWT アクセストークン返却 ──────┘
       │
       ├─────── 3. Key 1 復号要求 (RMS) ──────────> [Azure Rights Management]
       │
       └─────── 4. Key 2 復号要求 (JWT + TLS相互認証) ──> [リバースプロキシ / WAF]
                                                                  │
                                                                  ▼
                                                      [Entrust CSP Vault DKE API]
                                                                  │ (署名/復号検証)
                                                                  ▼
                                                          [nShield HSM]

認証・認可ステップ

  1. ユーザー認証 & トークン取得:
    • クライアント端末が Microsoft Entra ID に対して認証を行い、DKE サービス用に登録された Enterprise Application（App ID）を対象（Audience）とする OAuth 2.0 / JWT アクセストークンを取得します。
  2. 暗号化要求時の公開鍵取得:
    • 暗号化時、クライアントは CSP Vault の DKE パブリックエンドポイント（例: [https://dke.example.com/api/v1/keys/](https://dke.example.com/api/v1/keys/)...）から暗号化用公開鍵を取得します（公開鍵取得は通常トークン認証なし、または組織トークンで許可）。
  3. 復号要求時のトークン検証:
    • ドキュメント閲覧時、クライアントは取得した JWT トークンを Bearer トークンとして Authorization ヘッダーに付与し、CSP Vault の復号 API へ HTTPS リクエストを送信します。
  4. CSP Vault 側でのポリシー・ID 検証:
    • トークン署名検証: Entra ID のパブリック署名鍵を用いて JWT の完全性を確認。
    • クレーム検証: iss（発行者テナント ID）、aud（登録アプリ ID）、有効期限（exp）、ユーザーの UPN / グループ所属を検証。
    • 認可判定: CSP Vault で事前定義されたアクセス制御リスト（ACL）と照合し、許可されたユーザー/ロールのみ復号処理を nShield HSM へ委任します。

2. 可用性・冗長化設計のポイント

DKE では、オンプレミスの CSP Vault が停止すると、正規ユーザーであっても保護されたファイルを一切開けなくなります（即座の業務停止）。そのため、高可用性（HA）とディザスタリカバリ（DR）が最重要要件となります。

① アプライアンス層（CSP Vault クラスタリング）

  • アクティブ/アクティブ クラスタ:
    • CSP Vault を最低 2 台（推奨 3 台以上）でクラスタ化し、ステート同期を常時維持します。
    • 前段にロードバランサー（F5 BIG-IP、HAProxy 等）を配置し、ヘルスチェック（/health エンドポイント監視）による自動切り離しと負荷分散を実施します。
  • マルチアベイラビリティゾーン / マルチデータセンター:
    • メインサイトと DR サイトに Vault ノードを分散配置し、DNS フェイルオーバー（Route 53、GSLB 等）を構成します。

② ハードウェア層（nShield HSM の Security World 構成）

  • Security World による安全な鍵同期:
    • 複数台の nShield HSM 間でマスターキーや DKE ルートキーを暗号化された状態で自動同期・共有します。
    • オフラインバックアップ（スマートカードによる M of N クォーラム管理: 例「5 枚中 3 枚で復元可能」）を確立し、ハードウェア全損時にも別機体への迅速なリストアを可能にします。
  • HSM プーリング:
    • 各 CSP Vault ノードが複数の nShield Connect（ネットワーク HSM）に接続可能なプール構成を採用し、HSM 単体の故障・保守時も無瞬断で稼働を継続します。

③ ネットワーク・エッジ層の設計

  • リバースプロキシ & WAF 冗長化:
    • 外部（在宅勤務者や外部拠点）から DKE エンドポイントに安全に到達できるよう、DMZ に冗長構成の WAF/リバースプロキシを配置し、DDoS 攻撃緩和と TLS 終端を行います。
  • 冗長回線 & 低遅延化:
    • ドキュメント閲覧ごとにオンプレミスへの API 呼び出し（数十〜数百 ms）が発生するため、帯域だけでなく低遅延な専用線（ExpressRoute / Direct Connect）または高品質インターネット回線をマルチキャリアで確保します。

3. 障害・運用のリスク対策マトリクス

障害シナリオ影響度対策・リカバリ設計
インターネット回線/拠点停電致命的 (ファイル閲覧不可)DR サイトへの GSLB 自動切り替え、または クラウド（Azure IaaS 等）上への冗長ノード分散配置。
単一 Vault ノード障害軽微 (無影響)ロードバランサーによる自動フェイルオーバー、クラスタ内同期による復旧。
Entra ID 側のトークン遅延中 (新規認証遅延)クライアント側のトークンキャッシュ活用、ネットワークタイムアウト値の最適化。
HSM ハードウェア故障軽微 (冗長時)Security World でペアリングされた予備 HSM への自動フェイルオーバー。

Entrust CSPのVault for Cloud KeysにおけるHYOKおよびDKE（二重暗号化）の連携アーキテクチャと仕組みを詳しく解説

Entrust CSP（Cryptographic Security Platform）の Vault for Cloud Keys は、マルチクラウド環境におけるデータ主権の確保、暗号鍵の完全なコントロール、クラウド事業者によるデータ復号の防止（ゼロトラスト暗号化）を実現するためのモジュールです。

ここでは、HYOK（Hold Your Own Key / 外部鍵管理） および DKE（Double Key Encryption / 二重鍵暗号化） の連携アーキテクチャと動作メカニズムを解説。

1. 鍵管理方式の前提整理（BYOK vs HYOK vs DKE）

方式鍵の生成場所鍵の稼働・復号場所クラウド事業者のアクセス可否特徴・CSPでの位置づけ
BYOK (Bring Your Own Key)オンプレミス (HSM/CSP)パブリッククラウド側鍵・平文へのアクセス可能性あり（メモリ等）クラウドネイティブな暗号化。CSPからクラウドKMSへ鍵をエクスポートする。
HYOK / XKS (Hold Your Own Key / 外部鍵管理)オンプレミス (HSM/CSP)オンプレミス (CSP Vault) 内クラウド側は鍵を持たないクラウドKMSが暗号・復号リクエストをオンプレミスのCSPへリレーする。
DKE (Double Key Encryption / 二重鍵暗号化)クラウド & オンプレミス (CSP)クライアント端末 + 各鍵基盤クラウド事業者は絶対に復号不可2つの独立した鍵で二重に暗号化。Microsoft 365 / Purview等で活用。

2. HYOK（外部鍵管理 / XKS）の連携アーキテクチャ

HYOKは、クラウド事業者のKMS（AWS KMS XKS、Google Cloud EKM、Azure Key Vault MHSMなど）と連携し、暗号化・復号のマスター鍵をクラウド外（自社管理下のCSP Vault / nShield HSM）に保持し続ける仕組みです。

[ クラウド側サービス (S3, EBS, GCS, etc.) ]
              │
              ▼ (データ暗号化リクエスト)
     [ クラウド KMS ] (AWS KMS / Google Cloud EKM)
              │
              ▼ (REST / TLS 相互認証)
[ CSP Vault for Cloud Keys ] ── (ハードウェア保護) ── [ nShield HSM ]

動作フロー（エンベロープ暗号化の例）

  1. データ暗号化時:
    • クラウドサービスがデータ暗号化鍵（DEK）を生成します。
    • クラウドKMSはDEKの保護（ラッピング）をオンプレミスの CSP Vault にリクエストします。
    • CSP Vaultは、バックエンドの nShield HSM 内で保護されたキールート（KEK）を用いてDEKを暗号化し、クラウドへ返却します。
  2. データ復号時:
    • クラウドサービスが暗号化されたDEKをクラウドKMSへ送信します。
    • クラウドKMSがCSP Vaultへアンラッピング（復号）要求を送信します。
    • CSP Vaultがアクセス制御ポリシー（ロール、送信元IP、承認フロー等）を検証し、許可された場合のみ復号したDEKをクラウドへ返却します。

HYOKのメリット

  • キルスイッチ機能: 法的差押えやコンプライアンス上の緊急事態が発生した場合、CSP Vaultへのネットワーク経路遮断や鍵の無効化を行うだけで、クラウド上の全データへのアクセスを即座にブロックできます。

3. DKE（Double Key Encryption / 二重鍵暗号化）の仕組み

DKEは、主に Microsoft 365（Purview Information Protection） などの極めて機密性の高い文書やデータを保護するために設計されたアーキテクチャです。データを2つの鍵で二重に暗号化し、片方の鍵をクラウド（Microsoft Azure）、もう片方をオンプレミスの CSP Vault（DKEサービスエンドポイント） が保持します。

                    [ ユーザー端末 (Word, Excel, Outlook等) ]
                                    │
            ┌───────────────────────┴───────────────────────┐
            ▼                                               ▼
 [ 鍵 1: Azure Rights Management ]              [ 鍵 2: CSP Vault (DKE Endpoint) ]
    (Microsoft クラウドが管理)                      (自社管理下の nShield HSM で保護)

暗号化とアクセスの流れ

  1. 文書の作成・暗号化:
    • 端末上のOfficeアプリが、MicrosoftのAzure RMS から公開鍵（Key 1）を、CSP Vault から公開鍵（Key 2）をそれぞれ取得します。
    • 文書データはこれら2つの鍵で階層的に二重暗号化されます。
  2. 文書の閲覧・復号:
    • 閲覧者が文書を開く際、端末はまずAzure RMSへ認証してKey 1の復号要求を行います。
    • 次に端末は、自社管理下の CSP Vault のDKEサービスへ直接TLS相互認証でアクセスし、Key 2の復号を要求します。
    • CSP Vault側でID検証（Microsoft Entra IDトークン等）とポリシーチェックを通過した場合にのみ、復号許可が下りて端末側で平文化されます。

DKEのメリット

  • 完全なゼロトラスト暗号化: クラウド事業者（Microsoft）は Key 2 を決して保持しないため、クラウド事業者自身であっても、政府機関からの召喚令状等があっても、データを復号することが技術的に不可能です。
  • 物理的な鍵分離: CSP VaultとnShield HSMによって、Key 2の生成・保管・使用がFIPS 140-3の改ざん耐性境界内で完結します。

4. CSP Vault が提供するエンタープライズ統合の強み

  • マルチクラウド横断のポリシー統合: AWS XKS、GCP EKM、Azure/M365 DKEで異なるインターフェースやプロトコルを、CSP Vaultが一手に吸収し、単一のガバナンスポリシーで管理できます。
  • 監査とアクセス証跡の自社保持: クラウド側のログだけでなく、鍵への復号要求ログがすべてCSP Compliance Manager側に記録されるため、不正なクラウドアクセス試行の検知が容易になります。
  • クリプトアジリティ: 将来的な暗号アルゴリズム更新や耐量子暗号（PQC）への移行時にも、クラウド側の設定を大幅に変えることなく、オンプレミス側のCSP/HSMレベルで段階的に移行可能です。

Entrust Cryptographic Security Platform のモジュールとその機能概要

Entrust Cryptographic Security Platform（CSP）は、オンプレミスやマルチクラウド環境に分散する暗号鍵・デジタル証明書・シークレットを一元的に可視化・制御し、耐量子暗号（PQC）への移行やコンプライアンス準拠を支援する暗号セキュリティ基盤です。

主に3つのコアアプライアンス（モジュール）と、それを支えるハードウェアRoot of Trust（HSM）で構成されています。

主要モジュールとその機能概要

モジュール名概要・役割主な機能・ユースケース
CSP Vault暗号化・鍵・シークレット実行アプライアンス

分散型のVaultアーキテクチャを採用し、用途ごとに柔軟な暗号処理環境を提供。		KMIP鍵管理: VMware vSphere/vSAN、ストレージ、DBなどの暗号鍵を一元管理。Vault for Secrets: APIキー、トークン、DB/アプリのパスワード保管とローテーション。Vault for Cloud Keys: AWS/Azure/GCP等へのBYOK（持ち込み鍵）やHYOK/DKE（外部鍵管理・二重暗号化）の制御。データ・ファイル暗号化: VMのディスク/パーティションやファイル階層の暗号化。トークナイゼーション: REST APIを介した機密データのトークン化（FPE、部分マスキング、マルチ言語対応）。
PKI HubPKI & 証明書ライフサイクル管理（CLM）

オールインワンアーキテクチャで企業全体のPKI基盤を提供。		証明書ライフサイクル自動化: 証明書の発行・更新・失効プロセスの自動化。マルチCA統合: 社内プライベートCAやパブリックCA、サードパーティ製CAを統合管理。有効期限短縮への対応: 有効期限の短縮トレンド（90日化等）に伴う更新漏れ・システム停止リスクの低減。
CSP Compliance Manager統合可視化 & ガバナンスGUI

プラットフォーム全体の暗号資産と運用状況を一元監視する管理アプライアンス。		クリプトインベントリ（棚卸）: 組織内に存在するすべての鍵・証明書・シークレットの所在と利用状況を可視化。コンプライアンス・監査レポート: PCI DSS、NIST SP 800-130などの規制要件に対する証明・監査ログ収集。PQC移行診断: 量子コンピューティング時代に向け、どのシステムが脆弱な暗号を用いているかを特定し、移行優先度を提示。
Entrust nShield HSM

(ハードウェア基盤)		高信頼ルート・オブ・トラスト（Root of Trust）

物理的改ざん耐性を備えたFIPS 140-3適合のハードウェアセキュリティモジュール。		マスターキー保護: CSP全体のマスター鍵を改ざん耐性のある境界内で生成・保護。ハードウェア暗号アクセラレーション: 署名や鍵生成処理の高速化（Post-Quantumアルゴリズム対応）。Security Worldアーキテクチャ: 複数拠点・アプライアンス間で安全な鍵共有とシームレスなフェイルオーバーを実現。

全体アーキテクチャの特徴

  • 分散型かつ一元管理:データプレーン（CSP Vault）を拠点やクラウドごとに分散配置しつつ、コントロールプレーン（Compliance Manager）で統合的にポリシー適用や監視を行うことが可能です。
  • クリプトアジリティ（暗号の俊敏性）: クラウドやアプリの仕様変更、暗号アルゴリズムの寿命、PQC（耐量子暗号）への移行要請に対して、システム全体を改修することなく柔軟に対応できるよう設計されています。

Entrust PKI製品とランサムウェア対策について

Entrustの公開鍵暗号基盤（PKI）製品群（PKIaaS、CSP PKI、マネージドPKIなど）は、ランサムウェア攻撃の一連の流れ（侵入・ラテラルムーブメント・データ暗号化・二重脅迫）を根本から阻止・無力化するための基盤インフラとして機能します。

主な対策効果は以下の通りです。

1. 「なりすまし侵入」の防止（証明書ベースの強力な認証）

ランサムウェア攻撃者の多くは、フィッシングや認証情報の漏洩によって盗まれたパスワードを使ってVPNやリモートデスクトップ（RDP）経由でネットワークに侵入します。

  • パスワードレス / クライアント証明書認証: ユーザーや正規端末に対してEntrust PKIからデジタル証明書を発行し、厳格な端末認証・相互認証（mTLS）を強制することで、盗まれたID/パスワードだけによる不正侵入を遮断します。
  • 耐フィッシングMFAの確立: FIDO2やスマートカードなど、証明書を組み合わせた多要素認証の信頼基盤となります。

2. ネットワーク内部の「横展開（ラテラルムーブメント）」の阻止

ランサムウェアが1台のエンドポイントに侵入した後、Active Directoryやファイルサーバー、管理サーバーへ感染を拡大させようとします。

  • ゼロトラスト・アーキテクチャの基盤: 内部通信のすべて（サーバー間、マイクロサービス間、管理アクセスなど）をPKIによる暗号化通信（TLS/mTLS）と相互認証で保護します。
  • 不正端末・不正通信の排除: 正規の証明書を持たない侵入端末や侵害されたプロトコルによる内部リソースへの接続要求を拒絶し、被害の局所化（ブラストレーディアスの縮小）を実現します。

3. 「暗号化鍵・特権資格情報の窃取」の防御（HSMおよびCSPとの統合）

攻撃者は正規の暗号化ツール（BitLockerなど）を乗っ取ったり、システム内の鍵やシークレットを盗んでバックアップや重要システムをロック・暗号化します。

  • 鍵管理の厳格化とHSM（ハードウェア・セキュリティ・モジュール）連携: EntrustのPKIは同社のHSMやCSP（Cryptographic Security Platform）と緊密に連携し、秘密鍵や暗号化鍵を耐タンパー性ハードウェア内に隔離します。攻撃者がOSやメモリを侵害しても、復号鍵や署名鍵を直接持ち出すことはできません。

4. 二重脅迫（データ流出・持ち出し）の無効化

現在のランサムウェアは「身代金を払わなければデータを公開する」という二重脅迫型が主流です。

  • 透過的なファイル暗号化連携: Entrustの暗号プラットフォームおよびPKIと連携したファイル暗号化（File-Level Encryption）を施しておくことで、万が一データそのものが外部に持ち出されても、鍵がなければ平文を復元できないため情報漏洩の脅威を最小化します。

5. バックアップデータの保護・不変性の確保

ランサムウェアは復旧を阻止するためにバックアップデータを標的にして暗号化・削除します。

  • デジタル署名による完全性保証: バックアップストレージ（VeeamやVeritas等との連携ソリューション）において、バックアップの不変性（イミュータブル）確保やアクセス制御にPKIによる電子署名・鍵管理を用いることで、攻撃者によるバックアップの改ざんや破壊を防ぎます。

6. 不正なコード実行（サプライチェーン攻撃）の防止

  • コードサイニング（コード署名）の保護: 社内アプリケーションや配布パッケージ、ファームウェアに対して信頼された署名を付与し、未署名の不正なランサムウェアバイナリや改ざんされたスクリプトの実行をOS/エンドポイント側でブロックします。

まとめ

Entrust PKIは、「盗まれた認証情報による侵入を塞ぎ、内部での横展開を止め、重要データやバックアップの暗号鍵を保護する」という、ゼロトラスト型ランサムウェア防御の土台を提供する製品です。

Entrust DataControl はランサムウェア対策に活用できますか？

Entrust DataControlはランサムウェア対策に活用できます。🛡️

Entrust DataControl（現在はEntrust KeyControlの一部として提供されることが多い）は、主にデータの暗号化と鍵管理を通じてランサムウェアの被害を軽減します。

 

ランサムウェア対策への活用点

機能 ランサムウェア対策における役割
データの透過的な暗号化 データが暗号化されているため、ランサムウェアによってファイルが不正に暗号化された場合でも、その元データ自体はすでにEntrustによって強力に保護されています。また、ランサムウェアによる侵害が成功した場合でも、復号鍵がなければ機密データは読み取れません。🔑
厳格なアクセス制御 仮想環境（VM）やクラウドインスタンスへのアクセスを制御し、ルートユーザーやシステム管理者であっても機密データへのアクセスを制限することで、不正な操作やランサムウェアによるデータの窃取や改ざんのリスクを低減します。
統合キー管理 暗号化に用いる鍵を一元的に安全に管理し、鍵のライフサイクルを制御します。これにより、鍵の漏洩リスクを減らし、鍵がない状態でのデータの不正利用を防ぎます。

Entrust DataControlは、ランサムウェアによる侵害が成功した場合の被害の最小化（事後対策）、特に機密データの保護に非常に有効なソリューションです。