テストおよび本番システムで使用されるHSMのベストプラクティス
テスト/デモ/非製品システムで本番環境と同じHSMを使用することを禁止する必要がありますか？テストと製品の両方で同じマスターキーが使用されるため、眉を上げることができるようですが、このトピックに関する具体的なガイダンスは見つかりません。
はい。
複数の環境（開発、テスト、本番稼働、本番など）で同じHSMを共有することは、複数のWebサイトで同じパスワードを使用することと同じです。
多くの大企業は定期的に本番データをQA /テスト環境にコピーしています。これらの低い環境では、通常、それほど厳格でないデータアクセス制御が導入されています。つまり、同じHSMが両方の場所で使用されている場合、実稼働環境で適切に保護されていたデータが、非実稼働環境で不適切にアクセスされ、外部に漏洩（または「漏洩」）する可能性があります。これを見つけるためにGoogleを使用している人）。したがって、これに対する防御策は、非プロダクションシステムが、プロダクションシステムがデータを保護するために使用したキーにアクセスできないようにすることです。つまり、本番用と非本番用に別々のHSMインフラストラクチャがあります。
また、PCIの観点から、非本番環境では本番データを保護するために使用されるキーにアクセスする方法がないということを監査人に簡単に言えば、追加のHSMのコスト以上の節約になります。
大きなことはこれです：
HSMは多くの管理をあなたに代わって行いますが、それはあなたが取り組んでいる標準で概説されている義務からあなたを解放しません。
あなたが取り組んでいる他の標準にも同じような言い回しがあると思います。
PCI-DSSの観点から：
PCI-DSS 2.0規格のセクション3.5.1および3.5.2b：
3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary.
3.5.2.b Identify key storage locations to verify that keys are stored in the fewest possible locations and forms.
一般的に言えば、QA環境には、システムにアクセスできる人がはるかに多く、3.5.1に違反します。 QAシステムの違反が本番環境での違反を許した場合、3.5.2.bも削除されると確信しています。
さまざまな環境で単一のHSMを使用する場合の1つの懸念は、開発/テスト環境の主要な管理要件が、実稼働環境の要件と一致しない可能性があることです。
たとえば、私の理解では、一部のHSMを「開発またはテスト」モードにして、HSMからキーマテリアルを取得できる場合があります。
これは、開発者にとって望ましいかもしれません。デバッグ目的の環境ですが、実稼働環境では非常に望ましくありません。
したがって、私の結論は、HSMが運用HSMとして管理されている場合は常にであれば、特に問題はないはずですが、テスト/デモHSMとしての有用性が低下する可能性があるということです...