Hyper Protect Crypto Services移行するIBM Cloudダラスのクラシックデータセンター（DAL ）、ワシントンD.C（WDC ）、フランクフルト（FRA ） にIBM Cloudそれぞれの場所にある仮想プライベート クラウド (VPC) データ センターにより、VPC が提供する新しい製品の機能と機能を活用できるようになります。

現在のユーザーへの影響:

VPC データセンターへの移行は、ユーザー エクスペリエンスは変わらないまま、サービス/テクノロジーのアップグレードになります。 移行を完了するには、最小限の顧客とのやり取りが必要です。 クライアントへの影響は最小限です。

からの支援IBMチームはVPCデータセンターでのインスタンスの正常な展開を確実にするために利用可能です。地元の営業担当者に連絡するか、電子メールを送信してください。zaas.client.acceleration@ ibm.com 詳細については。

この移行の重要な日付:

• DAL と WDC の既存のインスタンスについては、顧客移行は 2024年8月22日～ 2025年1月31日となります。 移行プロセス全体を通じてサポートは中断されません。 後 2025年1月31日、のサービス DAL そして WDC データセンターは廃止され、利用できなくなります。 移行されていないインスタンスと既存のデータはすべて DAL そして WDC この日以降、データセンターは廃止されます。

• 既存のインスタンスの場合 FRA 顧客の移行は 2024年8月15日– 2025年1月31日。 移行プロセス全体を通じてサポートは中断されません。 後 2025年1月31日、のサービス FRA データセンターは廃止され、利用できなくなります。 移行されていないインスタンスと既存のデータはすべて FRA データセンターはこの日以降は廃止されます。

BYOHSM は、お客様のローカル・キー管理機能をクラウドに拡張し、規制対象ワークロードのためのスケーラブルで統一されたセキュアなハイブリッド・クラウド・エコシステムを作成します。 独自の HSM を Hyper Protect Crypto Services インスタンスに接続することで、データ主権の規制を満たすために鍵を完全に物理的に制御できます。

BYOHSM 機能を使い始めるには、以下のトピックを参照してください：

• Bring Your Own HSM の紹介
• IBM Cloud Hyper Protect Crypto ServicesのBYOHSMでキーを管理する
• BYOHSM のセットアップ
• BYOHSM を使用したインスタンスのプロビジョニング

Hyper Protect Crypto Services および Hyper Protect Virtual Servers for Classic は、 Sydney の IBM Cloud データ・センターから非推奨になります。 2023 年 11 月 30 日以降、Hyper Protect Services の新しいインスタンスを Sydney の IBM Cloud データ・センターにデプロイできなくなりました。シドニーの IBM Cloud データ・センターの既存の Hyper Protect サービスおよびサポートは廃止され、 2024 年 3 月 31 日に廃止されます。

この発表は、シドニーの IBM Cloud データ・センターで実行されている他のサービスや、Hyper Protect がサポートされている他のデータ・センターで実行されているその他の Hyper Protect Services (サポートを含む) には影響しません。

この非推奨については、以下の詳細を確認してください。

• 2023 年 11 月 30 日以降、 Hyper Protect Crypto Services または Hyper Protect Virtual Servers for Classic の新規インスタンスを Sydney にプロビジョンすることはできません。
• 2024 年 3 月 31 日以降、 Hyper Protect Crypto Services および Hyper Protect Virtual Servers for Classic はサポートされなくなり、サービスは Sydney の IBM Cloud データ・センターから廃止されます。 すべてのインスタンスとデータを IBM Cloud VPC データセンターに移行することをお勧めします。
• Sydney の IBM Cloud データ・センターにまだ存在する Hyper Protect Services インスタンスおよびデータは、この日に停止され、終了されます。 データ・センター・インフラストラクチャーは廃止され、データおよびサービスは使用できなくなります。 データ損失のリスクを回避するために、サービスが 2024 年 3 月 31 日に廃止される前に、必要なデータのバックアップまたは転送が行われていることを確認してください。

既存のお客様には、IBM Cloud VPC データセンターへの移行をお勧めします：

• Hyper Protect Crypto Services を引き続き使用するには、IBM Cloud VPC データセンターに移行することをお勧めします。 APAC 内でのマイグレーションに推奨されるリージョンは、 Tokyo です。
• Hyper Protect Virtual Servers for Classic インスタンスについては、IBM Cloud VPC データセンターに移行し、サービスの最新バージョンである Hyper Protect Virtual Servers for VPC (Hyper Protect Virtual Servers for Classic は、IBM Cloud VPC データセンターでは利用できません)。 APAC 内でのマイグレーションに推奨されるリージョンは、 Tokyo です。
• IBM Cloud VPC データセンターに移行する場合は、IBM チームからのサポートをご利用いただけます。 詳しくは、地域の営業担当員にお問い合わせいただくか、 zaas.client.acceleration@ibm.com 宛てに E メールを送信してください。

以下の表に、 Hyper Protect Crypto Services でサポートされる IBM Cloud VPC データ・センターと Hyper Protect Virtual Servers for Classic をリストします。

表 1. サポートされる IBM Cloud VPC データ・センター

データセンター	Hyper Protect Crypto Services	Hyper Protect Virtual Servers for Classic
東京 (APAC 内の推奨地域) jp-tok
サン・パウロ br-sao
ロンドン eu-gb
トロント ca-tor
マドリッド eu-es
ワシントン DC us-east	該当なし

これで、作成する管理対象鍵のプロパティーを指定する鍵テンプレートを作成できます。 鍵テンプレートを作成した後、鍵テンプレートで定義されているものと同じ鍵プロパティーを使用して、管理対象鍵のグループを作成できます。

以下のトピックは、主要なテンプレートを使い始めるのに役立ちます：

• 鍵テンプレートの作成
• 主要なテンプレートのリストの表示
• キー・テンプレートの詳細の編集
• 鍵テンプレートのアーカイブとアーカイブ解除
• 鍵テンプレートの削除
• キー・テンプレートを使用したキーの位置合わせ

Unified Key Orchestratorの価格設定プランが更新されました。 詳しくは、 サービス・カタログ・ページを参照してください。

詳細な料金設定のサンプルについては、 How am I ートル for my use of Hyper Protect Crypto Services with Unified Key Orchestrator? を参照してください。

Unified Key Orchestrator サービス・プランを使用している場合、またはサポートされるすべての地域で EP11 鍵ストアが有効になっているサービス・インスタンスを使用している場合に、マスター鍵をローテートできるようになりました。 以前は、ドイツのフランクフルトでのみ使用可能でした。

サポートされているリージョンのリストについては、リージョンとロケーションを参照してください。 マスター鍵のローテーションの仕組みについて詳しくは、 マスター鍵のローテーションの概要 を参照してください。

Hyper Protect Crypto Services キー管理サービス API がバージョン 22.11 に更新されました。 以下の機能が追加されました。

• ソート付きリストキー含めるlastRotateDate並べ替え。
• 高度なフィルタリングによるキーのリスト含むlastRotateDateフィルタリング。
• ポリシー・オーバーライドを使用して鍵を作成 して、管理者役割を持つユーザーが 1 回の呼び出しでポリシーを使用して鍵を作成し、インスタンス・レベルのポリシーをオーバーライドできるようにします。
• 鍵のローテーション・ポリシーを無効にする と、自動鍵ローテーション・ポリシーを一時的に一時停止することができます。

最新のイベント名とマッピングについては、 イベントに関する履歴情報 を参照してください。

スマート・カードを使用してマスター鍵を管理するために、既にサポートされている Red Hat Enterprise Linux 8.0 オペレーティング・システムに加えて、スマート・カード・リーダー・ドライバー Identiv SPR332 V2 を Red Hat Enterprise Linux 9.0 および Ubuntu 22.04.1 LTS にインストールできるようになりました。 詳しい手順については、 スマート・カード・リーダー・ドライバーのインストール を参照してください。

You can also find the latest Management Utilities installation files in Github.

Go Software Development Kit (SDK) を有効にした Unified Key Orchestrator API を使用して、鍵を管理できるようになりました。 Go のコード例について詳しくは、 Unified Key Orchestrator API リファレンス を参照してください。

Unified Key Orchestratorの Terraform サポートにより、Terraform を使用して、ボールト、鍵ストア、鍵テンプレート、鍵の管理などのアクションを自動化できるようになりました。 詳しくは、 Setting up Terraform for Hyper Protect Crypto Services with Unified Key Orchestrator を参照してください。

Hyper Protect Crypto Services 標準プランの料金設定モデルが、月単位の請求から時間単位の請求に変更され、暗号装置ごとに 1 時間当たり $2.13 USD が課金されるようになりました。

最初の 5 つのキー・ストア (KMS 鍵リングと EP11 キー・ストアを含む) は無料です。 追加の鍵リングまたは EP11 キー・ストアごとに、月額 $225 USD から始まる段階的な料金が課金されます。 キー・ストアが作成、接続されて 1 か月に満たない場合は、コストは当該月の実際の使用日数で日割計算されます。

詳しくは 料金プランをご覧ください。 請求例 も参照用に用意されています。

スマート・カードおよびスマート・カード・リーダーを注文するために、IBM (zcat@ibm.com@ibm.com) に E メールを送信し、必要な情報を提供できるようになりました。 詳細なステップについては、スマート・カードおよび管理ユーティリティーのセットアップを参照してください。

Unified Key Orchestrator は、マルチクラウドとハイブリッド・クラウドのキー・オーケストレーションのためのパブリック・クラウド・コントロール・プレーンです。 IBM Cloud® Hyper Protect Crypto Services の一部として、NIST の推奨事項に従ってキーのライフサイクル管理を行い、サービス・インスタンスの内部キー・ストアか、または外部キー・ストアにキーを安全に転送します。

Unified Key Orchestrator を使用すると、サービス・インスタンスを IBM Cloud およびサード・パーティーのクラウド・プロバイダーのキー・ストアに接続して、統一システムでキーをバックアップ、管理し、複数のクラウド全体にわたってキーをオーケストレーションできます。

以下のトピックは、Unified Key Orchestrator の使用を開始する一助となります。

• Unified Key Orchestrator の紹介
• FAQ: Unified Key Orchestrator を使用した Hyper Protect Crypto Services
• Hyper Protect Crypto Services
• Unified Key Orchestrator での暗号キーのライフサイクルのモニタリング
• ボールトの作成
• 内部キー・ストアの作成
• 外部キー・ストアへの接続
• マネージド・キーの作成およびインストール

Unified Key Orchestrator は、マルチクラウドとハイブリッド・クラウドのキー・オーケストレーションのためのパブリック・クラウド・コントロール・プレーンです。 IBM Cloud® Hyper Protect Crypto Services の一部として、NIST の推奨事項に従ってキーのライフサイクル管理を行い、サービス・インスタンスの内部キー・ストアか、または外部キー・ストアにキーを安全に転送します。

Unified Key Orchestrator を使用すると、サービス・インスタンスを IBM Cloud およびサード・パーティーのクラウド・プロバイダーのキー・ストアに接続して、統一システムでキーをバックアップ、管理し、複数のクラウド全体にわたってキーをオーケストレーションできます。

以下のトピックは、Unified Key Orchestrator の使用を開始する一助となります。

• Unified Key Orchestrator の紹介
• FAQ: Unified Key Orchestrator を使用した Hyper Protect Crypto Services
• Hyper Protect Crypto Services
• Unified Key Orchestrator での暗号キーのライフサイクルのモニタリング
• ボールトの作成
• 内部キー・ストアの作成
• 外部キー・ストアへの接続
• マネージド・キーの作成およびインストール

1. 削除されたキーのパージ: 削除されたキーはデフォルトで、削除から 90 日後に自動的にパージされます。 キーを手動でパージして、90 日を待たずにインスタンスからキーを完全削除できるようになりました。 キーが削除されてから最大 4 時間の待機期間が経過すると、このアクションを実行できます。 キーをパージする前に、必ず_「KMS キー・パージ」_ロールを割り当ててください。 詳細については、手動によるキーのパージを参照してください。
2. キーのキー・リングを更新します。 キーを作成すると、そのキーを別のキー・リングに移動できます。 詳細については、別のキー・リングへのキーの転送を参照してください。

鍵パーツ・ファイルの使用やリカバリー用暗号装置の使用によるマスター鍵のローテーションに加えて、スマート・カードと管理ユーティリティーを使用している場合にもマスター鍵をローテーションできるようになりました。

詳しい手順については、スマート・カードと管理ユーティリティーを使用したマスター鍵のローテーションを参照してください。 マスター鍵のローテーションの仕組みについて詳しくは、鍵パーツ・ファイルを使用したマスター鍵のローテートを参照してください。

鍵素材を提供しなくても、30 日以内に削除された鍵を復元できるようになりました。 すべてのルート鍵および標準鍵は、Hyper Protect Crypto Services によって生成されるか、ユーザーによってインポートされるかに関係なく、復元できます。 詳しくは、 鍵の復元を参照してください。

鍵リングを作成して、Hyper Protect Crypto Services インスタンスの鍵をグループ化できるようになりました。 この場合は、鍵リングのレベルで、鍵の管理とアクセス制御を行うことができます。 鍵リングの使用方法について詳しくは、鍵リングの管理を参照してください。

スマート・カードと Hyper Protect Crypto Services 管理ユーティリティーを使用する方法と、鍵パーツ・ファイルを使用する方法に加えて、ダラス (us-south) リージョンとワシントン DC (us-east) リージョンでは、リカバリー用暗号装置を使用してサービス・インスタンスを初期設定できるようになりました。

ダラスまたはワシントン DC のどちらかのリージョンでサービス・インスタンスをプロビジョニングすると、リカバリー・ユニット 2 台が追加料金なしで自動的に割り当てられます。マスター・キーのランダムな値がリカバリー暗号化ユニットで自動的に生成され、そのサービス・インスタンスの他の暗号化ユニットにコピーされます。 マスター鍵値が HSM の外部に露出することは決してありません。

サービス・インスタンスの初期設定方法の違いについて詳しくは、サービス・インスタンスの初期設定方法の概要を参照してください。

詳しい手順については、リカバリー用暗号装置を使用したサービス・インスタンスの初期設定を参照してください。

マスター鍵をローテートするには、リカバリー用暗号装置を使用したマスター鍵のローテートを参照してください。

PKCS #11 API を使って Enterprise PKCS #11 (EP11) の鍵ストアと鍵を管理する以外に、UI を使って EP11 の鍵ストアと鍵を表示、作成、削除できるようになりました。 詳細については、UIでEP11キーストアを管理する および UIでEP11キーを管理する を参照してください。

鍵の別名は、鍵を識別するために使用できる、人間が理解できる固有の名前です。 鍵を認識しやすくするために、1 つの鍵に対して最大 5 つの別名を作成できるようになりました。 鍵の別名の使用方法について詳しくは、鍵の別名の管理を参照してください。

ルート鍵の状態が変わると、ルート鍵に関連付けられている保護リソースに対してその鍵ライフサイクル・イベントが通知され、適切な対応処理を行うように促されます。 リソースが鍵ライフサイクルの通知に応えて対応処理を行っていない場合に、それらの関連クラウド・サービスへの再通知を手動で開始できるようになりました。 詳しくは、関連付けられているリソースの同期化を参照してください。

IBM Cloud の Virtual Private Cloud (VPC) インスタンス用の仮想プライベート・エンドポイント (VPE) を作成して、お客様の VPC のネットワーク内部で Hyper Protect Crypto Services にアクセスできるようになりました。 詳しくは、VPC の仮想プライベート・エンドポイントの使用方法を参照してください。

署名鍵を生成する暗号アルゴリズムがRivest-Shamir-Adleman 2048 (RSA 2048)からP521 Elliptic Curve (P521 EC)に更新されました。 P521 EC 鍵の暗号強度は RSA 15360 と同等です。つまり、更新された署名鍵は、以前の署名鍵より高いレベルのセキュリティーを提供できます。 以前の RSA 2048 署名鍵も引き続き有効であり、使用可能です。

Hyper Protect Crypto Services インスタンスに保管されている鍵に改ざんが行われていないことを PKCS #11 API で確認できるように、Hyper Protect Crypto Services に保管されている鍵オブジェクトを検査するための鍵検証メカニズムが導入されました。 鍵オブジェクトの検証方法については、鍵が暗号装置によって保護されていることの確認を参照してください。

AES、DES2、DES3鍵のチェックサム値を取得する方法の例と、鍵のチェックサムの検証については、コードサンプルを参照のこと。

Hyper Protect Crypto Services で、デジタル署名を生成する署名スキームとして使用できる Schnorr アルゴリズムがサポートされるようになりました。 これは、Bitcoin システムにおける暗号署名用の楕円曲線 DSA (ECDSA: Elliptic Curve Digital Signature Algorithm) の代替アルゴリズムとして提案されています。 Schnorr アルゴリズムを使用するには、その前に Schnorr アルゴリズムの有効化の手順に従って、この機能を有効化してください。

Hyper Protect Crypto Services インスタンスをセットアップした後に、鍵の作成とインポートのアクセス・ポリシーを有効にして更新することによって、ルート鍵と標準鍵のアクション許可を制御できます。 詳しくは、鍵の作成とインポートのアクセス・ポリシーの管理を参照してください。

セキュリティーを向上させるために、サービス・インスタンスへのネットワーク・アクセスを private-only ネットワークのみに制限できるようになりました。 サービス・インスタンスをプロビジョンするときに許可されるネットワークを選択することもできますし、インスタンスをセットアップした後にネットワーク・アクセス・ポリシーを更新することもできます。

ネットワーク・アクセス・ポリシーを更新する前に、まずサービス・インスタンスを初期設定する必要があります。 手順については、IBM Cloud TKE CLI プラグインを使用したサービス・インスタンスの初期設定または スマート・カードと管理ユーティリティーを使用したサービス・インスタンスの初期設定を参照してください。

GREP11 API が ReencryptSingle 関数のサポート対象となり、オリジナル・キーを使用してデータを復号し、クラウド HSM のたった 1 回の呼び出しで別のキーで raw データを暗号化できます。 大量のデータを異なる鍵で再暗号化する必要がある状況では、この関数を 1 回呼び出すことが 1 つの有効な選択肢となります。これを使用すると、再暗号化する必要があるデータ項目ごとに DecryptSingle 関数と EncryptSingle 関数を組み合わせて実行する手間が省かれます。 詳しくは、GREP11 API リファレンス - ReencryptSingle 関数を参照してください。

仮想プライベート・エンドポイント (VPE) ゲートウェイを介して IBM CloudVirtual Private Cloud (VPC) インスタンスを Hyper Protect Crypto Services インスタンスに接続できるようになったので、プライベート・ネットワークで Hyper Protect Crypto Services を使用して鍵を管理することができます。 詳しくは、VPC の仮想プライベート・エンドポイント (VPE) を使用した Hyper Protect Crypto Services へのプライベート接続を参照してください。

Hyper Protect Crypto Services は、秘密鍵と公開鍵のペアを導出するために、階層的決定論的ウォレットのための SLIP10 メカニズムをサポートするようになりました。 また、デジタル署名についてはエドワーズ曲線 (ED) 25519 アルゴリズムもサポートするようになりました。 ED アルゴリズムを使用するには、その前にエドワーズ曲線デジタル署名アルゴリズムの有効化の手順に従って、この機能を使用できるようにしてください。

Terraform は、クラウド・リソースのプロビジョニングと管理を構成および自動化するためのオープンソース・ソフトウェアです。 Terraform CLI と Hyper Protect Crypto Services Provider プラグインを使用して、IBM Cloud インスタンスのプロビジョンと初期化や、ルート鍵と標準鍵の管理を行うことが可能になりました。 詳しくは、 Terraform を使用した鍵管理サービス・リソースの管理 および Hyper Protect Crypto Servicesを参照してください。

Hyper Protect Crypto Services キー管理サービス API が更新され、以下の変更が加えられました。

• 更新: 以下の鍵の操作を行うための API メソッドが、個別の要求パスに移されました。 汎用パス・フォーマット (キーをリストアするアクションを除く) は /api/v2/keys/<key_ID>/actions/<action> です。ここでは、key_ID はキーの UUID、action は実行するアクション名を指します。

  • 鍵をラップする。
  • 鍵をアンラップする。
  • 鍵を再ラップする。
  • 鍵をローテートする。
  • 二重許可ポリシーが設定された鍵の削除を許可する。
  • 二重許可ポリシーが設定された鍵の許可を削除する。
  • 鍵の操作を有効にする。
  • 鍵の操作を無効にする。
  • 鍵を復元にする。

• 更新: 以下の 2 つの方式を使用して、許可されたネットワーク・ポリシーと、鍵の作成とインポートのアクセス・ポリシーを管理できるようになりました。

  • インスタンス・ポリシーを設定する。
  • インスタンス・ポリシーをリストする。

• 非推奨: 鍵に対してアクションを呼び出す。

  この方式は、キーに対してアクション (ラップ、アンラップ、ローテートなど) を実行するために当初使用されていました。 現在では、アクションごとに個別の要求パスを使用するように置換されています。

API更新の詳細については、Hyper Protect Crypto Services 鍵管理サービスAPIリファレンスを参照してください。

業界標準や暗号のベスト・プラクティスに合わせるために、IBM Cloud® Trusted Key Entry CLI プラグインを使用してオンデマンドでマスター鍵をローテートできるようになりました。 仕組みについて詳しくは、マスター鍵のローテートの概要を参照してください。

詳しい手順については、マスター鍵のローテートを参照してください。

Hyper Protect Crypto Services で、標準 Public-Key Cryptography Standards (PKCS) #11 の API を使用して暗号操作を実行できるようになりました。

PKCS #11 の API がサポートされるので、PKCS #11 標準を使用している既存のアプリケーションを、Hyper Protect Crypto Services のクラウド HSM 環境で実行するために変更する必要はありません。 PKCS #11 ライブラリーが、そのアプリケーションからの PKCS #11 API 要求を受け入れ、リモートからクラウド HSM にアクセスして、対応する暗号関数を実行してくれます。

PKCS #11 の API ユース・ケースについて詳しくは、PKCS #11 HSM として Hyper Protect Crypto Services を使用する方法を参照してください。

PKCS #11 の API について詳しくは、PKCS #11 の概要および PKCS #11 の API リファレンスを参照してください。

ライター または管理者 のアクセス権限を持っている場合は、インポート・トークンを作成して、Hyper Protect Crypto Services にアップロードする暗号鍵のセキュリティーを強化できるようになりました。

鍵のインポートのオプションについて詳しくは、インポート・トークンの作成を参照してください。 ガイド付きチュートリアルについては、チュートリアル: 暗号鍵の作成とインポートを参照してください。

FIPS 140-2 レベル 4 準拠 HSM をベースに構築された Hyper Protect Crypto Services で、Key Protect と同じレベルの鍵管理機能を使用できるようになりました。 追加された機能は以下のとおりです。

• ポリシー・ベースの鍵のローテーション。
• ルート鍵のバージョンの表示。
• ルート鍵の無効化と有効化。
• Hyper Protect Crypto Services インスタンスおよび鍵の二重許可ポリシー。
• 暗号鍵に関する詳細の表示。
• ルート鍵と IBM Cloud リソースの間の関連付けの表示。
• 削除された鍵の復元。

ワシントン DC (米国東部) のリージョンで Hyper Protect Crypto Services リソースを作成できるようになりました。 詳しくは、地域とロケーションを参照してください。

IBM Cloud Trusted Key Entry (TKE) のコマンド・ライン・インターフェース (CLI) プラグインと Hyper Protect Crypto Services の管理ユーティリティーで、クォーラム認証がサポートされるようになりました。

クォーラム認証とは、設定した人数の暗号装置管理者が操作を承認するという手法です。 機密性の高い操作を行うには、十分な人数の暗号装置管理者が資格情報を入力する必要があります。 最低必要署名数を 1 より大きい値に設定すると、クォーラム認証が有効になります。

TKE の CLI でサービス・インスタンスを初期設定してクォーラム認証を有効にする方法について詳しくは、IBM Cloud TKE CLI プラグインを使用したサービス・インスタンスの初期設定を参照してください。

管理ユーティリティーでサービス・インスタンスを初期設定してクォーラム認証を有効にする方法について詳しくは、スマート・カードと管理ユーティリティーのセットアップおよびスマート・カードと管理ユーティリティーを使用したサービス・インスタンスの初期設定を参照してください。

Enterprise PKCS #11 サービスのプライベート・エンドポイントをターゲットに設定することで、Hyper Protect Crypto Services プライベート・ネットワークを介して IBM Cloud に接続できるようになりました。

始めるには、インフラストラクチャ・アカウントで virtual routing and forwarding(VRF)と service endpoints を有効にします。 詳しくは、プライベート・エンドポイントの使用を参照してください。

Hyper Protect Crypto Services では、サービス・インスタンスを初期設定するために、スマート・カードからのマスター鍵パーツと署名鍵のロードがサポートされるようになりました。 これにより、マスター鍵パーツと署名鍵に対する最高レベルの保護が保証されます。

管理ユーティリティーは、スマート・カードを使用してサービス・インスタンスを構成する 2 つのアプリケーションです。 スマート・カード・ユーティリティー・プログラムは、使用するスマート・カードをセットアップして管理します。 Trusted Key Entry (TKE) アプリケーションは、それらのスマート・カードを使用してサービス・インスタンスを構成します。 管理ユーティリティーを使用するには、IBM がサポートするスマート・カードとスマート・カード・リーダーを注文する必要があります。

詳しくは、管理ユーティリティーについておよびスマート・カードと管理ユーティリティーを使用したサービス・インスタンスの初期設定を参照してください。

Hyper Protect Crypto Services を、さらに以下の IBM Cloud サービスと統合できるようになりました。

• Hyper Protect DBaaS for MongoDB
• Hyper Protect DBaaS for PostgreSQL
• HyTrust DataControl
• IBM Cloud Kubernetes Service
• Red Hat OpenShift on IBM Cloud

詳しくは、サービスの統合を参照してください。

サービスのプライベート・エンドポイントをターゲットに設定することで、Hyper Protect Crypto Services プライベート・ネットワークを介して IBM Cloud に接続できるようになりました。

始めるには、インフラストラクチャ・アカウントで virtual routing and forwarding(VRF)と service endpoints を有効にします。 詳しくは、サービス・エンドポイントを使用した Hyper Protect Crypto Services へのプライベート接続を参照してください。

マネージドのクラウドのハードウェア・セキュリティー・モジュール (HSM) は Enterprise Public-Key Cryptography Standards (PKCS) #11 をサポートしているので、Enterprise PKCS#11 (EP11) API を使用してデジタル署名や検証などの暗号操作をアプリケーションに組み込むことができます。 EP11 ライブラリーには、業界標準の PKCS #11 API とよく似たインターフェースが用意されています。

Hyper Protect Crypto Services には、一連の Enterprise PKCS #11 (EP11) over gRPC (別名 GREP11) の API 呼び出しが用意されています。これらの API を使用すると、すべての暗号関数をクラウド HSM 内で実行できます。 GREP11 は、クラウド・プログラム用のステートレス・インターフェースです。

GREP11 API について詳しくは、EP11 over gRPC の概要と GREP11 の API リファレンスを参照してください。

フランクフルト地域で Hyper Protect Crypto Services リソースを作成できるようになりました。 詳しくは、地域とロケーションを参照してください。

Hyper Protect Crypto Services を以下の IBM Cloud サービスに統合できるようになりました。

• IBM Cloud Object Storage
• IBM Cloud Block Storage for Classic for Virtual Private Cloud
• IBM Cloud Virtual Servers for Virtual Private Cloud
• IBM Cloud の Key Management Interoperability Protocol (KMIP) for VMware®

詳しくは、サービスの統合を参照してください。

2019 年 3 月 29 日以降、新しい Hyper Protect Crypto Services のベータ・インスタンスのプロビジョニングができなくなります。 既存のインスタンスは、ベータ・サポートの終了日 (2019 年 4 月 30 日) までサポートされます。

Hyper Protect Crypto Services オファリングについて詳しくは、 IBM Cloud Hyper Protect Crypto Services ホーム・ページを参照してください。

IBM Cloud Hyper Protect Crypto Services で、選択された地域の 3 つのアベイラビリティー・ゾーンがサポートされるようになりました。 これは高度に使用可能なサービスであり、アプリケーションを保護して作動させるための自動機能を備えています。

Hyper Protect Crypto Services リソースは、サポートされている IBM Cloud 地域に作成できます。これらの地域は、Hyper Protect Crypto Services の要求が扱われて処理される地理上のエリアを表します。 IBM Cloud の各地域には、その地域のローカル・アクセス権限、低遅延、セキュリティーに関する要件を満たすために 複数のアベイラビリティー・ゾーンが用意されています。

詳しくは、高可用性と災害復旧を参照してください。

パフォーマンス要件を満たすために、サービス・インスタンスは最大 6 台の暗号装置までスケールアウトできます。 実稼働環境では、高可用性を確保するために 2 台以上の暗号装置を選択することをお勧めします。 3 つ以上の暗号装置を選択すると、それらの暗号装置は、選択した地域の 3 つのアベイラビリティー・ゾーンに分散されます。

詳しくは、サービスのプロビジョニングを参照してください。

Hyper Protect Crypto Services ベータ版がリリースされました。 Hyper Protect Crypto Services サービスに**「カタログ」>「セキュリティー」**から直接アクセスできるようになりました。

2019 年 2 月 5 日以降、新しい Hyper Protect Crypto Services Experimental インスタンスのプロビジョニングができなくなります。 既存のインスタンスは、試験サポートの終了日 (2019 年 3 月 5 日) までサポートされます。

Key Protect API は、鍵を生成して保護するために、Hyper Protect Crypto Services と統合されるようになりました。 Key Protect API は、Hyper Protect Crypto Services から直接呼び出すことができます。

詳しくは、 鍵管理サービス API のセットアップ および Hyper Protect Crypto Services 鍵管理サービス API リファレンスを参照してください。

Hyper Protect Crypto Services は Keep Your Own Key (KYOK: 自分の鍵の保持) をサポートするようになったので、保持、制御、管理を行える暗号鍵を使用して、データに対する制御権と権限をさらに強化することができます。 IBM Cloud® コマンド・ライン・インターフェース (CLI) でサービス・インスタンスを初期化して管理することができます。

詳しくは、鍵ストレージを保護するためのサービス・インスタンスの初期設定を参照してください。

現段階では、Advanced Cryptography Service Provider (ACSP) クライアントによる Hyper Protect Crypto Services へのアクセスは非推奨になっています。 以前のサービス・インスタンスを使用している場合は、引き続き ACSP を使用して Hyper Protect Crypto Services を利用することができます。