身份是指在云環境中執行操作的實體。云上主要有兩種身份類型：人員身份和程序身份。

人員身份通常代表組織中的個人，比如企業中的安全管理員、運維管理員、應用開發者。通常通過阿里云的控制臺、CLI、特定場景下的客戶端等方式對云上的資源進行操作。

程序身份則代表應用程序或服務，往往是通過阿里云的 OpenAPI 來訪問云上的資源和數據。

在阿里云上，針對兩種類型的身份管理，基于安全的最小化原則，核心有兩大原則：縮小暴露時長和縮小暴露面積。

縮小暴露時長指盡可能使用臨時身份或憑據替代固定身份或憑據，即使使用固定身份或憑據，也建議定期輪轉。

縮小暴露面積指盡可能安全保管密鑰或憑據，避免在不同身份類型之間混用憑據或身份。

基于這兩大核心原則，針對不同類型的身份管理，在阿里云上有以下最佳實踐可以參考。

人員身份

避免使用 Root 身份

在阿里云上，注冊完一個阿里云賬號后，即可通過用戶名和密碼的方式登錄到阿里云控制臺，登錄成功后，即獲得了 Root 身份。該身份具有該賬號下所有的權限，一旦賬號密碼泄漏，風險極高。另外，如果多人共用該身份，每個人都保有該賬號的用戶名和密碼，會增加泄漏的可能。同時，多人共享的情況下，在云上的操作日志中無法區分出是組織中哪個人使用了該身份進行了操作，也無法進行進一步溯源。因此，除了極個別場景，應該盡可能的使用阿里云 RAM（Resource Access Management，訪問控制）身份進行云上資源的訪問，避免使用阿里云賬號的 Root 身份。對于 Root 身份的使用，參考下述“建立更安全的登錄機制”一節中的最佳實踐，提升 Root 身份的安全性。

實現人員身份的統一認證

通過集中化的身份提供商（Identity Provider，簡稱 IdP）來進行人員身份的統一認證，能夠簡化人員身份的管理，確保組織內在云上、云下的人員身份的一致性。當人員結構變更、人員入、離職時，能夠在一個地方完成人員身份的配置。 對于云環境的使用者來說，也無需為其頒發額外的用戶名和密碼（如 RAM 用戶名和密碼），只需要保管好其在組織內的 IdP 中的身份和憑據即可。對于一些組織而言，通過一些網絡上的訪問控制措施，使其 IdP 僅能夠在企業內網訪問，給人員身份的認證過程增加了額外一個限制條件，進一步保障了企業人員身份的安全。

阿里云支持基于 SAML 2.0 協議的單點登錄（Single Sign On，簡稱 SSO）。在阿里云上，我們建議通過 RAM SSO的方式跟組織內的 IdP 進行集成，實現人員身份的統一認證。對于云上有多個阿里云賬號的復雜組織，還可以通過云SSO進行多賬號下的 SSO 集中化配置，進一步實現多賬號下的人員身份統一管理，提升管理效率。

建立更安全的登錄機制

對于人員身份的登錄方式，往往是通過用戶名和密碼的方式進行。一旦用戶名和密碼泄漏，攻擊者極有可能通過該身份登錄阿里云，造成一些不可挽回的損失。因此，對于人員身份來說，保護好用戶名和密碼顯得尤為重要?？梢詮囊韵聨追N方式提升登錄方式的安全性：

1. 提升密碼強度。如增加密碼位數、混合使用數字、大小寫字母、特殊字符等。針對阿里云 RAM 用戶，管理員可以設置密碼強度規則，強制 RAM 用戶使用更復雜的密碼，降低密碼泄漏和被破解的風險。

2. 避免密碼混用。在不同的服務、站點，或不同的用戶共用一個密碼，增加了密碼的暴露面積，會增加密碼泄漏的可能性。如果其中一個服務或用戶的密碼泄漏，那攻擊者就可以通過嘗試登錄的方式，找到共用密碼的其他服務。因此，確保不同服務、不同用戶使用不同的密碼，能夠降低密碼泄漏的風險。

3. 定期輪轉密碼。密碼存在的時間越長，泄漏風險越高。通過定期重設密碼，降低單個密碼存在的時長，能夠進一步降低密碼泄漏風險。針對阿里云 RAM 用戶，管理員可以在密碼強度規則中設置密碼有效期，來實現密碼定期輪轉。

4. 使用多因素驗證。多因素認證 MFA（Multi Factor Authentication）是一種簡單有效的安全實踐，在用戶名和密碼之外再增加一層安全保護，用于登錄阿里云或進行敏感操作時的二次身份驗證，以此保護您的賬號更安全。阿里云支持虛擬 MFA、U2F 安全密鑰等多種二次驗證方式。建議為云上的人員身份都啟用二次驗證。對于使用云下 IdP 進行統一身份認證的組織，也建議在 IdP 側提供二次驗證的選項。

通過角色扮演代替固定身份

基于縮小暴露面積的原則，使用臨時身份替代固定身份，能極大降低身份泄漏風險，同時對于人員身份來說，也能夠抽象人員權限模型，如按人員職能進行角色劃分，有利于規范化人員權限設置，提升管理效率。

在云上，建議通過單點登錄（Single Sign-on，簡稱 SSO），基于角色扮演的方式，實現人員身份的管理。

程序身份

不使用云賬號 AccessKey

云賬號 AccessKey 等同于阿里云賬號的 Root 權限，也就是該賬號內的完全管理權限，而且無法進行條件限制（例如：訪問來源IP地址、訪問時間等），也無法縮小權限，一旦泄漏風險極大。對于程序訪問的場景，請使用 RAM 用戶的 AccessKey 來進行阿里云 API 的調用。

避免共用 AccessKey

多個程序身份共用 AccessKey，或程序身份、人員身份共用 AccessKey 的情況下，AccessKey 所關聯的權限需要包含所有身份的使用場景，導致權限擴大。另外，共用場景下，一處泄漏會導致所有應用都受到影響，風險擴大，同時增加了泄漏后的止血難度。對于同一個應用的不同環境，如生產環境、測試環境，往往需要訪問不同的資源，同時，測試環境代碼往往不夠穩定和健壯，更容易有泄漏風險，如果共用同一個 AccessKey，測試環境 AccessKey 泄漏后也極容易造成對生產環境的影響，導致業務安全風險。

因此，針對不同應用、大型應用的不同模塊、同一個應用（或模塊）的不同環境（如生產環境、測試環境等），都建議創建不同的 AccessKey 供程序身份使用，每個 AccessKey 只有該場景下所需要的權限，避免共用 AccessKey 的情況。

定期輪轉 AccessKey

同人員身份的用戶名密碼一樣，AccessKey 創建和使用時間越長，泄漏的風險越高。每隔一段時間，通過創建新的 AccessKey，替換掉應用在使用的 AccessKey，并將舊 AccessKey 進行禁用和刪除，實現 AccessKey 的定期輪轉。另外，也可以通過阿里云密鑰管理服務（Key Management Service，簡稱 KMS）的憑據管家功能，實現 AccessKey 的集中管控和自動化定期輪轉。

除了 AccessKey，其余類型的程序訪問憑據，都應該進行定期輪轉，降低憑據泄漏風險。

使用臨時憑據代替固定憑據

通過給 RAM 用戶或云賬號的 Root 身份創建 AccessKey 供程序調用，都屬于固定憑據類型。一旦創建出來，在刪除之前，就是由固定的 AccessKey ID 和 AccessKey Secret 組成了該憑據。使用固定憑據會造成很多風險，比如應用研發人員將固定 AccessKey 寫入了代碼中，并將其上傳到了 Github 等公開倉庫，造成了 AccessKey 泄漏，最終導致業務受損。在阿里云上，我們建議盡可能通過角色扮演的方式獲取臨時憑據 STS Token，代替固定 AccessKey 的使用。每個 STS Token 生成后，在超過角色最大會話時間（小時級）后，自動失效，從而降低了因固定憑據泄漏導致的風險。

針對不同類型的云上應用部署方式，阿里云提供了相應的功能，集成了 STS Token 憑據的使用：

1. 針對在 ECS 實例上部署的應用，通過ECS實例角色實現臨時憑證的獲取和使用，將 RAM 角色跟實例進行綁定，應用程序中即可通過實例元數據服務獲取臨時授權Token。

2. 針對在 ACK 上部署的應用，通過容器服務RRSA功能，實現 RAM 角色和指定 ServiceAccount 進行綁定，在 Pod 維度即可扮演對應角色實現 STS Token 的獲取。

3. 針對在函數計算中部署的 Serverless 應用，可以通過FC函數角色實現臨時憑證的獲取和使用。

無論哪種部署方式，在應用代碼中通過阿里云官方提供的 SDK，根據部署類型設置相應的身份驗證（Credentials）配置，都可以便捷的直接獲取 STS Token，無需關心具體的憑據緩存以及過期更新邏輯。