FAQ: セキュリティーとコンプライアンス
ここでは、IBM Cloud® Hyper Protect Crypto Services のデータ・セキュリティーに関する疑問とそれに対する回答を掲載しています。
サービス・インスタンスへのユーザー・アクセスを管理するにはどうすればよいですか? 私のインスタンスに IBM がアクセスすることはできるのですか?
IBM もサード・パーティーのユーザーもお客様のサービス・インスタンスや鍵にはアクセスできません。 マスター鍵をサービス・インスタンスにロードすることで、クラウド HSM の所有権を取得し、 Hyper Protect Crypto Servicesによって管理されるリソースを排他的に制御できます。
Hyper Protect Crypto Services は、IBM Cloud の ID およびアクセス管理 (IAM) の規格に従っています。 より細かくアクセスを制御するために、さまざまな IAM 役割を割り当ててユーザー・アクセスを管理したり、特定の鍵に対するアクセス権限を付与したりできます。
サービスの初期設定のための固有で安全なプロセス (鍵セレモニー) を IBM はどのように提供していますか?
Hyper Protect Crypto Services は、サービスの初期設定プロセス時に暗号装置管理者向けの署名鍵をセットアップすることで、マスター鍵パーツが途中で不正に取得されることなく HSM にロードされるようにします。
マスター・キーは、2 つまたは 3 つのマスター・キー・パーツで構成されます。 マスター鍵の管理者は、暗号化されたマスター鍵のパーツをそれぞれ 1 つ所有します。 ほとんどの場合、マスター鍵の管理者は、暗号装置管理者が兼任します。 マスター鍵をサービス・インスタンスにロードするために、マスター鍵管理者は、独自の管理者署名鍵を使用して鍵パーツを個別にロードする必要があります。
署名鍵は、非対称の鍵ペアで構成されます。 署名鍵の非公開部分は暗号装置管理者が所有しますが、公開部分は、管理者を定義するために使用される証明書に入れられ、暗号装置を離れることはありません。
この設計によって、暗号装置管理者を含め、誰一人完全なマスター鍵を利用できない状態にしています。
140-2 FIPS レベル 4 認定とは何ですか? どうすれば確認できますか?
連邦情報処理標準 (FIPS) 公示 140-2 は、暗号モジュールの認定に使用される米国連邦政府のコンピューター・セキュリティー標準です。
- 暗号モジュールのセキュリティー要件。
- Cryptographic Module Validation Program。
- FIPS 140-2 では、FIPS 140-2 レベル 1、レベル 2、レベル 3、レベル 4 を含む 4 つのレベルのセキュリティーを定義しています。
FIPS 140-2 レベル 1、2、3 とレベル 4 との違いは何ですか?
-
レベル 1: 最低レベルのセキュリティー。 セキュリティー・レベル 1 の暗号モジュールでは、製品グレードのコンポーネントに対する基本要件の他には、具体的な物理的セキュリティー・メカニズムは要件とされていません。
-
レベル 2: レベル 1 の暗号モジュールの物理的セキュリティー・メカニズムを強化するために、不正操作の証拠を示すための機能を要件としています。例えば、モジュール内にある平文の暗号鍵やクリティカル・セキュリティー・パラメーター (CSP) に物理的にアクセスするためには破かなければならないコーティングやシール、不正な物理アクセスを防ぐためにカバーやドアに取り付けるピッキング防止ロックなどです。 セキュリティー・レベル 2 では、少なくとも役割ベースの認証が必要となります。つまり、オペレーターが特定の役割を担ってそれに対応した一連のサービスを実行する許可を、暗号モジュールで認証します。
-
レベル 3: 暗号モジュールへの物理アクセス、暗号モジュールの使用または変更の試行を、高い確率で検出して対処できることを要件としています。 物理的なセキュリティー・メカニズムには、強力な筐体の使用、および暗号モジュールの取り外し可能なカバーまたはドアが開かれたときにすべてのプレーン・テキスト CSP をゼロ化する改ざん検出および応答回路が含まれます。 セキュリティー・レベル 3 では、ID ベースの認証メカニズムが必要になります。これは、セキュリティー・レベル 2 で規定された役割ベースの認証メカニズムによるセキュリティーを強化するものです。
-
レベル 4: 最高レベルのセキュリティー。 このセキュリティー・レベルでは、すべての不正な物理アクセスの試行を検出して対応するという目的で、物理的セキュリティー・メカニズムにより暗号モジュールの周りに完全な保護エンベロープが提供されます。 いずれかの方向から暗号モジュール・エンクロージャーに侵入すると、検出される可能性が高く、すべてのプレーン・テキスト CSP が即時にゼロ化されます。
セキュリティー・レベル 4 の暗号モジュールは、物理的に保護されていない環境で運用する場合に役立ちます。 セキュリティー・レベル 4 はまた、環境条件や変動により電圧や温度がモジュールの通常運用の範囲外になっても、暗号モジュールからセキュリティー情報が漏えいしないように保護します。 攻撃者が通常運用の範囲外に意図的に逸脱させて、暗号モジュールの保護を妨害する可能性があります。
変動を検出すると CSP を削除するように設計した特殊な環境保護機能を暗号モジュールに組み込むか、暗号モジュールで環境障害テストを行って、通常運用の範囲を超える変動があっても、モジュールのセキュリティー侵害が可能になるような影響を受けないことを確認する必要があります。 このセキュリティー・レベルでは、すべての不正な物理アクセスの試行を検出して対応するという目的で、物理的セキュリティー・メカニズムにより暗号モジュールの周りに完全な保護エンベロープが提供されます。
Hyper Protect Crypto Services は、パブリック・クラウド市場で唯一、FIPS 140-2 レベル 4 認定の要件を満たすように設計された HSM をベースに構築されたクラウド HSM です。 認定は、 Cryptographic Module Validation Program(CVMP)Validated Modules Listにリストされています。
Hyper Protect Crypto Services KYOK の鍵階層をどのように理解すればよいですか?
以下の表に、Hyper Protect Crypto Services の Keep Your Own Key (KYOK) 機能に必要な鍵をリストします。
キー・タイプ | アルゴリズム | 関数 |
---|---|---|
署名キー | P521 楕円曲線 (EC) | Hyper Protect Crypto Services インスタンスを初期化してマスター鍵をロードする場合は、署名鍵を使用して暗号装置にコマンドを発行する必要があります。 署名鍵の非公開部分は、署名を作成するために使用されて、お客様側に保管されます。 公開部分は、暗号装置管理者を設定するためにターゲット暗号装置に保管されている証明書内に配置されます。 |
マスター・キー | 256 ビット AES | マスター鍵を暗号装置にロードすることで、クラウド HSM の所有権を取得して、暗号鍵の階層全体を暗号化する Root of Trust (信頼の基点) を所有する必要があります。これらの暗号鍵には、鍵管理鍵ストア内のルート鍵と標準鍵や、EP11 鍵ストア内の Enterprise PKCS #11 (EP11) 鍵が含まれます。 マスター鍵をロードするために使用する方法に応じて、マスター鍵は異なる場所に保管されます。 |
ルート鍵 | 256 ビット AES | ルート鍵は Hyper Protect Crypto Services 内の 1 次リソースであり、マスター鍵によって保護されます。 これは、データ・サービス内に保管されている他のデータ暗号鍵 (DEK) をラッピング (暗号化) およびアンラッピング (暗号化解除) するための信頼のルートとして使用される、対称鍵ラップ鍵です。 このルート鍵暗号化手法は、エンベロープ暗号化とも呼ばれます。 詳しくは、エンベロープ暗号化を使用したデータ保護を参照してください。 |
データ暗号化キー (DEK) | データ・サービスにより制御 | データ暗号鍵は、お客様が所有する他のアプリケーションやデータ・サービスによって保管および管理されるデータを暗号化するために使用されます。 Hyper Protect Crypto Services で管理するルート鍵は、DEK を保護するためのラッピング鍵として機能します。 エンベロープ暗号化のための Hyper Protect Crypto Services の統合をサポートするサービスについては、IBM Cloud サービスと Hyper Protect Crypto Services の統合を参照してください。 |
EP11 は PKCS #11 とどのように違いますか?
概念と関数という点では、Enterprise PKCS #11 (EP11) は PKCS #11 と同じです。 経験豊富な PKCS #11 開発者であれば、EP11 の関数は簡単に使用できます。 ただし、次のような大きな違いがあります。
- EP11 は、高可用性とスケーラビリティーを実現する目的で作られたものです。
- EP11 はステートレス・プロトコルですが、PKCS #11 はステートフルです。 EP11 のステートレスな設計によって、外部の鍵ストアを使用したり、複数のバックエンドにスケーリングしたりできるようになっています。
- EP11 over gRPC (GREP11) は、クラウド・アプリケーションで直接使用できるネットワーク・プロトコルを定義しています。
詳しくは、PKCS #11 API と GREP11 API の比較を参照してください。
GREP11 関数でサポートされている EP11 メカニズムは何ですか?
メカニズムは、暗号カードのファームウェアのレベルによって異なる場合があります。サポートされるメカニズムを参照してください。 EP11 メカニズムについて詳しくは、「 IBM 4768 Enterprise PKCS #11(EP11)Library structure guide 」および「 IBM 4769 Enterprise PKCS #11(EP11)Library structure guide」を参照してください。
Hyper Protect Crypto Services が満たしているコンプライアンス規格は何ですか?
Hyper Protect Crypto Services は、グローバル、業界、地域のコンプライアンス規格 (GDPR、HIPAA、ISO など) の規制に準拠しています。 Hyper Protect Crypto Servicesによって使用される HSM として、IBM 4768 または IBM 4769 暗号カードもコモン・クライテリア EAL4 および FIPS 140-2 レベル 4 で認定されています。 詳細については、セキュリティーとコンプライアンスを参照してください。
サービス・インスタンスはモニターできますか?
はい。IBM Cloud Activity Tracker を使用してサービス・インスタンスの状況をモニターできます。