

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# AWS CloudHSM 應用程式整合最佳實務
<a name="bp-application-integration"></a>

遵循本節中的最佳實務，以最佳化應用程式與 AWS CloudHSM 叢集的整合方式。

## 引導您的用戶端 SDK
<a name="bp-integration-bootstrapping"></a>

在用戶端 SDK 可以連線至叢集之前，必須先將其引導。將 IP 地址引導至叢集時，建議您盡可能使用 `--cluster-id` 參數。此方法會將叢集中的所有 HSM IP 地址填入您的組態，而不需要追蹤每個個別地址。如果 HSM 正在進行維護或在可用區域中斷期間，這樣做會增加應用程式初始化的額外彈性。如需詳細資訊，請參閱[引導用戶端 SDK](cluster-connect.md#connect-how-to)。

## 驗證以執行 操作
<a name="w2aab9c13b7"></a>

在 中 AWS CloudHSM，您必須先向叢集進行身分驗證，才能執行大多數操作，例如密碼編譯操作。

**使用 CloudHSM CLI 驗證**：您可以使用 CloudHSM CLI 的[單一命令模式](cloudhsm_cli-modes.md#cloudhsm_cli-mode-single-command)或[互動式模式](cloudhsm_cli-modes.md#cloudhsm_cli-mode-interactive)進行驗證。使用 [使用 CloudHSM CLI 登入 HSM](cloudhsm_cli-login.md)命令在互動式模式下進行身分驗證。若要在單一命令模式中進行驗證，您必須設定環境變數 `CLOUDHSM_ROLE`和 `CLOUDHSM_PIN`。如需執行此操作的詳細資訊，請參閱 [單一命令模式](cloudhsm_cli-modes.md#cloudhsm_cli-mode-single-command)。 AWS CloudHSM 建議在應用程式未使用時安全地存放 HSM 登入資料。

**使用 PKCS \$111 驗證**：在 PKCS \$111 中，您在使用 C\$1OpenSession 開啟工作階段後，使用 C\$1Login API 登入。每個插槽 （叢集） 只需要執行一個 C\$1Login。成功登入後，您可以使用 C\$1OpenSession 開啟其他工作階段，而不需要執行其他登入操作。如需驗證為 PKCS \$111 的範例，請參閱 [AWS CloudHSM 用戶端 SDK 5 的 PKCS \$111 程式庫程式碼範例](pkcs11-samples.md)。

**使用 JCE 驗證**： AWS CloudHSM JCE 提供者支援隱含和明確登入。適合您的方法取決於您的使用案例。我們建議您盡可能使用隱含登入，因為如果您的應用程式與叢集中斷連線且需要重新驗證，開發套件會自動處理身分驗證。使用隱含登入也可讓您在使用無法控制應用程式程式碼的整合時，提供登入資料給應用程式。如需登入方法的詳細資訊，請參閱 [步驟 2：提供登入資料給 JCE 供應商](java-library-install_5.md#java-library-credentials_5)。

**使用 OpenSSL 驗證**：使用 OpenSSL 動態引擎，您可以透過環境變數提供登入資料。 AWS CloudHSM 建議在應用程式未使用時安全地存放 HSM 登入資料。如果可能，您應該將環境設定為系統性地擷取和設定這些環境變數，而無需手動輸入。如需使用 OpenSSL 驗證的詳細資訊，請參閱 [安裝適用於 AWS CloudHSM 用戶端 SDK 5 的 OpenSSL 動態引擎](openssl5-install.md)。

**使用 KSP 驗證**：您可以使用 Windows 登入資料管理員或環境變數向金鑰儲存提供者 (KSP) 進行驗證，請參閱 [安裝 AWS CloudHSM 用戶端 SDK 5 的金鑰儲存提供者 (KSP)](ksp-library-install.md)。

## 有效管理應用程式中的金鑰
<a name="bp-manage-application"></a>

**使用金鑰屬性來控制金鑰可以執行的動作**：產生金鑰時，請使用金鑰屬性來定義一組許可，以允許或拒絕該金鑰的特定操作類型。我們建議使用完成其任務所需的最少屬性來產生金鑰。例如，也不應允許用於加密的 AES 金鑰將金鑰包裝出 HSM。如需詳細資訊，請參閱下列用戶端 SDKs的屬性頁面：
+ [PKCS \$111 金鑰屬性](pkcs11-attributes.md)
+ [JCE 金鑰屬性](java-lib-attributes_5.md)

**盡可能快取金鑰物件以將延遲降至最低**：金鑰尋找操作將查詢叢集中的每個 HSM。此操作非常昂貴，不會隨著叢集中的 HSM 計數進行擴展。
+ 透過 PKCS \$111，您可以使用 `C_FindObjects` API 找到金鑰。
+ 透過 JCE，您可以使用 KeyStore 找到金鑰。

為了獲得最佳效能， AWS 建議您在應用程式啟動期間僅使用金鑰尋找命令 （例如 [使用 KMU 依屬性搜尋 AWS CloudHSM 索引鍵](key_mgmt_util-findKey.md)和 [使用 CloudHSM CLI 列出使用者的金鑰](cloudhsm_cli-key-list.md)) 一次，並快取應用程式記憶體中傳回的金鑰物件。如果您稍後需要此金鑰物件，您應該從快取擷取物件，而不是查詢每個操作的此物件，這會增加大量的效能額外負荷。

## 使用多執行緒
<a name="w2aab9c13c11"></a>

AWS CloudHSM 支援多執行緒應用程式，但多執行緒應用程式需要謹記某些事項。

**使用 PKCS \$111** 時，您只能初始化 PKCS \$111 程式庫 （呼叫 `C_Initialize`) 一次。每個執行緒都應指派自己的工作階段 (`C_OpenSession`)。不建議在多個執行緒中使用相同的工作階段。

**使用 JCE** 時， AWS CloudHSM 供應商只能初始化一次。請勿跨執行緒共用 SPI 物件的執行個體。例如，Cipher、Signature、Digest、Mac、KeyFactory 或 KeyGenerator 物件只能在自己的執行緒內容中使用。

## 處理調節錯誤
<a name="w2aab9c13c13"></a>

在下列情況下，您可能會遇到 HSM 限流錯誤：
+ 您的叢集未正確擴展以管理尖峰流量。
+ 在維護事件期間，您的叢集大小不會有 \$11 備援。
+ 可用區域中斷會導致叢集中可用 HSMs 的數量減少。

如需如何處理此案例的詳細資訊[HSM 調節](troubleshoot-hsm-throttling.md)，請參閱 。

為了確保您的叢集大小適當且不會受到調節， AWS 建議您使用預期的尖峰流量在環境中載入測試。

## 整合叢集操作的重試
<a name="w2aab9c13c15"></a>

AWS 可能會因為操作或維護原因而取代您的 HSM。為了讓您的應用程式適應這類情況， AWS 建議您在路由至叢集的所有操作上實作用戶端重試邏輯。因取代而失敗操作的後續重試預期會成功。

## 實作災難復原策略
<a name="w2aab9c13c17"></a>

為了回應事件，您可能需要將流量移離整個叢集或區域。下列各節說明執行此操作的多種策略。

**使用 VPC 對等互連從另一個帳戶或區域存取叢集**：您可以使用 VPC 對等互連從另一個帳戶或區域存取 AWS CloudHSM 叢集。如需如何設定的詳細資訊，請參閱[《VPC 對等互連指南》中的什麼是 VPC 對等互連？](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)。 **建立互連連線並適當設定安全群組後，您可以像平常一樣與 HSM IP 地址通訊。

**從相同的應用程式連線至多個叢集**：用戶端 SDK 5 中的 JCE 提供者、PKCS \$111 程式庫和 CloudHSM CLI 支援從相同的應用程式連線至多個叢集。例如，您可以有兩個作用中的叢集，每個叢集位於不同的區域，而您的應用程式可以一次連線到這兩個叢集，並在兩者之間進行負載平衡，做為正常操作的一部分。如果您的應用程式未使用用戶端 SDK 5 （最新的 SDK)，則您無法從相同的應用程式連線到多個叢集。或者，您可以讓另一個叢集保持正常運作，如果發生區域中斷，請將流量轉移到另一個叢集，以將停機時間降至最低。如需詳細資訊，請參閱個別頁面：
+ [適用於 的 PKCS \$111 程式庫的多個槽組態 AWS CloudHSM](pkcs11-library-configs-multi-slot.md)
+ [使用 JCE 提供者連線至多個 AWS CloudHSM 叢集](java-lib-configs-multi.md)
+ [使用 CloudHSM CLI 連線至多個叢集](cloudhsm_cli-configs-multi-cluster.md)

**從備份還原叢集**：您可以從現有叢集的備份建立新的叢集。如需詳細資訊，請參閱[中的叢集備份 AWS CloudHSM](manage-backups.md)。

## 交錯您的應用程式部署
<a name="bp-stagger-deployment"></a>

遵循交錯的部署策略，例如漸進式波型部署、單箱部署，以及用戶端應用程式部署和重新啟動的滾動部署。此方法可將變更的潛在影響降至最低，同時確保在部署期間有足夠的容量來提供生產流量。