SEC02-BP02 使用臨時憑證
當進行任何類型的驗證時，最好是使用臨時憑證，而不是長期憑證，以降低或消除風險，例如憑證遭到意外洩露、共用或遭竊。
預期成果：為了降低長期憑證的風險，對於人員和機器身分，請盡可能使用臨時憑證。長期憑證會產生許多風險，例如，可能在程式碼中將它們上傳至公有 GitHub 儲存庫。透過使用臨時憑證，您可大幅降低憑證遭到入侵的可能性。
常見的反模式：
-
開發人員使用取自 IAM users 的長期存取金鑰，而不是使用聯合從 CLI 取得臨時憑證。
-
開發人員將長期存取金鑰內嵌在程式碼中，並將該程式碼上傳到公有 Git 儲存庫。
-
開發人員將長期存取金鑰內嵌在行動應用程式中，之後在應用程式商店中提供該行動應用程式。
-
使用者與其他使用者共用長期存取金鑰，或是擁有長期存取金鑰的離職員工仍持有金鑰。
-
對機器身分可以使用臨時憑證時，卻使用長期存取金鑰。
未建立此最佳實務時的風險暴露等級：高
實作指引
對所有 AWS API 和 CLI 請求使用臨時安全憑證，而不是長期憑證。幾乎在任何情況下，對 AWS 服務的 API 和 CLI 請求都必須使用 AWS 存取金鑰簽署。您可以使用臨時或長期憑證簽署這些請求。您唯一應該使用長期憑證 (又稱為長期存取金鑰) 的時候是在使用 IAM 使用者或 AWS 帳戶 根使用者時。當您聯合至 AWS 或透過其他方法擔任 IAM 角色時，系統會產生臨時憑證。每當您使用登入憑證存取 AWS Management Console 時，系統會為您產生臨時憑證以呼叫 AWS 服務。在幾種情況下，您將需要長期憑證，並能夠使用臨時憑證完成幾乎所有任務。
避免使用長期憑證而改用臨時憑證，同時實行減少使用 IAM 使用者並支持聯合和 IAM 角色的策略。雖然對人類和機器身分過去以來都是使用 IAM 使用者，我們現在建議不要使用它們以避免使用長期存取金鑰的風險。
實作步驟
對於人類身分，例如員工、管理員、開發人員、操作員和客戶：
-
您應該仰賴集中式身分提供者並要求人類使用者以聯合搭配身分提供者，使用臨時憑證存取 AWS。您可以直接聯合至各個 AWS 帳戶
或使用 AWS IAM Identity Center (AWS IAM Identity Center 的後繼者) 和自選的身分提供者，為您的使用者進行聯合。與使用 IAM 使用者相比，聯合除了可消除長期憑證外，還提供一些優勢。您的使用者也可以從命令列進行直接聯合 ，或使用 IAM Identity Center 請求臨時憑證。這表示有少數使用案例會需要 IAM 使用者，或使用者需要長期憑證。 -
當授權讓第三方 (例如軟體即服務 (SaaS) 提供者) 存取 AWS 帳戶中的資源時，您可以使用跨帳戶角色和以資源為基礎的政策。
-
如果您需要授權應用程式供消費者或客戶存取您的 AWS 資源，您可以使用 Amazon Cognito 身分集區或 Amazon Cognito user pools 來提供臨時憑證。憑證的許可透過 IAM 角色設定。 您還可以對未驗證的訪客使用者另外定義一個具有限制許可的 IAM 角色。
對於機器身分，您可能需要使用長期憑證。在這些情況下，您應該要求工作負載使用臨時憑證，並以 IAM 角色存取 AWS。
-
對於 Amazon Elastic Compute Cloud
(Amazon EC2)，您可以使用適用於 Amazon EC2 的角色。
-
AWS Lambda
可讓您設定 Lambda 執行角色，授予服務許可以使用臨時憑證執行 AWS 動作。有許多其他類似的模型可供 AWS 服務使用 IAM 角色授予臨時憑證。 -
對於 IoT 裝置，您可以使用 AWS IoT Core 憑證提供者來請求臨時憑證。
-
對於內部部署系統或是在 AWS 之外執行並需要存取 AWS 資源的系統，您可以使用 IAM Roles Anywhere。
有些情況無法使用臨時憑證，而您可能需要使用長期憑證。在這些情況下，定期稽核和輪換憑證並針對需要長期憑證的使用案例定期輪換存取金鑰。有些可能需要長期憑證的例子包括 WordPress 外掛程式和第三方 AWS 用戶端。在您必須使用長期憑證的情況下，或是對於 AWS 存取金鑰以外的憑證，例如資料庫登入，您可以使用專為管理機密而設計的服務，例如 AWS Secrets Manager
資源
相關的最佳實務：
相關文件：
相關影片：
