効果的なキー管理は、Azure Cloud HSM のパフォーマンス、セキュリティ、効率性を最適化するために重要です。 この記事では、キーのストレージ制限、キーラッピングのセキュリティ、キー属性、キャッシュ戦略に関するベストプラクティスと推奨事項について説明します。
キー ストレージ制限を管理する
ハードウェア セキュリティ モジュール (HSM) には、1 回に格納できるトークンとセッション キーの最大数に制限があります。 これらの制限の詳細については、Azure Cloud HSM サービスの制限を参照してください。
Azure Cloud HSM サービスの制限を超えないようにするには、次の 1 つ以上の戦略を使用してキーを効率的に管理することを検討してください。
- キーのローテーション: キーを頻繁にローテーションして、古いキーが置き換えられ、新しいキーの領域が解放されるようにします。 頻繁なローテーションは、セキュリティを維持しながら HSM をstorage制限内に保つのに役立ちます。
- キー階層: 主キーを使用して他のキーを暗号化するキー階層を使用します。 この階層により、HSM に直接格納する必要があるキーの数が減ります。
- キーの共有と再利用: 複数のセッションまたはトークンを持つアプリケーションの場合は、キーを共有するか、再利用して格納される合計数を減らすことを検討してください。
- キーの削除: キーが不要になった後 (たとえば、セッションが終了した後)、新しいキーの領域を解放するために安全に削除されていることを確認します。
注
キーを作成してから 24 時間待って、Azure Cloud HSM デプロイ内の同期とバックアップが完了していることを確認します。
注意事項
キーが 1 つのノードにのみ存在し、そのノードがバックアップなしで失敗した場合は、回復オプションなしで暗号化されたデータから完全にロックアウトできます。 すべてのノード間でキーが同期されていることを常に確認し、定期的なバックアップを維持します。
ユーザーを作成するときは、Azure Cloud HSM クラスターのすべてのノードにユーザーが存在することを確認する必要があります。 詳細については、「 クラスターのすべてのノードで HSM ユーザーが使用できることを確認する」を参照してください。 不足しているキーを同期する手順については、「 Cloud HSM ノード間でユーザーとキー Azure同期するを参照してください。
キーラッピングを管理する
Azure Cloud HSM で EXTRACTABLE 属性を使用して、キーを抽出可能または nonextractable としてマークします。 既定では、HSM キーは抽出可能として設定されます。 HSM から抽出可能なキーをエクスポートするには、キーラップを使用してキーを暗号化します。 その後、キーを使用する前に、同じラッピング キーでラップ解除する必要があります。
これに対し、どのような状況でも、非トレース 可能なキーを Azure Cloud HSM からエクスポートすることはできません。 nonextractable としてキーを設定した後、キーを抽出可能に変更する方法はありません。 キーを抽出可能にする必要があるかどうかを慎重に検討し、それに応じてキー属性を設定することが重要です。
アプリケーションでキーの折り返しが必要な場合は、 信頼されたキー ラッピングを使用することをお勧めします。 この方法では、HSM ユーザーが、管理者が明示的に信頼済みとして指定したキーのみをラップおよびラップ解除することを制限します。
: 属性を に設定して作成されたキーは、マスクされたオブジェクト以外ではエクスポートできません。 HSM から一切出さないようにするキーに最適です。
WRAP_WITH_TRUSTED=1: 既定では、Azure Cloud HSM SDK を使用して作成された抽出可能なキーは、信頼されたキー ラッピングを使用します。 ただし、PKCS#11 に対応する仕様では、既定で が に設定されます。 信頼されたキー ラッピングを使用しない場合、暗号化ユーザーは承認なしでキーのプライベート マテリアルをエクスポートできます。 クライアント アプリケーションにaccessし、それらのキーを使用するすべてのユーザーは、プレーンテキストでエクスポートできます。
Azure Cloud HSM プロバイダーの主な属性のサポート
| Azure Cloud HSM プロバイダー | 秘密キーと対称キーの既定の属性 | EXTRACTABLE=0 をサポートしています | プロバイダー内でのWRAP_WITH_TRUSTEDの構成をサポートします | 既定の WRAP_WITH_TRUSTED 値 |
|---|---|---|---|---|
azcloudhsm_util |
、 | イエス | イエス | ( はパラメーターを使用して設定できます) |
| PKCS#11 | 、 | イエス | イエス | (PKCS#11 仕様で指定されていますが、API で に設定できます) |
| CNG/KSP | 、 | いいえ | いいえ | 1 |
| OpenSSL エンジン | 、 | いいえ | いいえ | 1 |
| JCE | 、、 | イエス | いいえ | 1 |
Cryptography API: Next Generation (CNG) プロバイダーを使用して作成するキーは、常に として設定されます。
CavImportKey.exe ツールを使用して、キー ハンドルを介して他の Azure Cloud HSM ツールから CNG プロバイダーにキーをインポートできます。 このインポートにより、既存のキー ハンドルからキー ストア プロバイダー (KSP) にキーが作成されます。
CNG または KSP をプロバイダーとして使用する証明機関の場合、CNG プロバイダー内で生成されたすべてのキーは引き続き抽出可能としてマークされます。 HSM でキーが としてマークされている場合 (ユーザーが生成したキー暗号化キーなど)、 変更後も、これらのキーの秘密キープレーンテキストを抽出するために使用される可能性があります。
このような状況で、キーが とマークされることを希望しない場合は、 を使用してキーを生成することをお勧めします。 を使用して、生成されたキーに目的の属性があることを確認することをお勧めします。
キー属性を使用してキーのアクセス許可を管理する
キー属性を使用して、アクセス許可などの主要な機能を管理します。 キーを生成するときは、キー属性を使用して、そのキーの特定の操作を許可または制限するアクセス許可を指定します。 目的に必要な属性のみを持つキーを生成することをお勧めします。
たとえば、暗号化に 使用される Advanced Encryption Standard (AES) キーでは、HSM の外部でキーをラップすることはできません。 Azure Cloud HSM SDK の属性の詳細については、integration guidesを参照してください。
キー オブジェクトをキャッシュして待機時間を最適化する
待機時間を短縮するには、可能な限りキー オブジェクトをキャッシュすることを検討してください。 キーを検索すると、Azure Cloud HSM クラスター内の各 HSM が照会されます。 この操作はコストがかかり、効率的にスケーリングされません。 キー検索の方法は、プロバイダーによって異なります。
- PKCS#11 の場合、キー検索では API が使用されます。
- Java Cryptography Extension (JCE) の場合、キー検索では 値を使用します。
最適なパフォーマンスを得るために、キー検索コマンド ( や など) は 、アプリケーションの起動時に 1 回だけ使用することをお勧めします。 返されたキー オブジェクトをアプリケーション メモリに格納します。 後でこのキー オブジェクトが必要な場合は、各操作でクエリを実行するのではなく、キャッシュから取得します。 クエリを実行すると、パフォーマンスに大きなオーバーヘッドが発生します。